Traffic Flow Template (TFT), GBR and QoS

Location Services in LTE Networks

Recently made a combined architecture of LTE with LCS and MBMS and posted it here. This document from MSF below looks at the LoCation Services (LCS) in detail.

MSF Whitepaper on Location Services in LTE Networks

View more documents from Zahid Ghadialy

LTE deployment and optimisation challenges

Presented in the 3G, HSPA, LTE Optimisation conference, April 2012 by Ljupco Jorguseski. The ICIC presentation referred to in this presentation is available in an earlier post here.

LTE deployment and optimisation challenges

View more presentations from Zahid Ghadialy

LTE 'Antenna Ports' and their Physical mapping

People who work with LTE Physical layer and maybe higher layers would be aware of this term called 'Antenna Ports'. I have always wondered how these antenna ports are mapped to physical antennas.

The following is from R&S whitepaper:

The 3GPP TS 36.211 LTE standard defines antenna ports for the downlink. An antenna port is generally used as a generic term for signal transmission under identical channel conditions. For each LTE operating mode in the downlink direction for which an independent channel is assumed (e.g. SISO vs. MIMO), a separate logical antenna port is defined. LTE symbols that are transmitted via identical antenna ports are subject to the same channel conditions. In order to determine the characteristic channel for an antenna port, a UE must carry out a separate channel estimation for each antenna port. Separate reference signals (pilot signals) that are suitable for estimating the respective channel are defined in the LTE standard for each antenna port. 

Here is my table that I have adapted from the whitepaper and expanded. 

The way in which these logical antenna ports are assigned to the physical transmit antennas of a base station is up to the base station, and can vary between base stations of the same type (because of different operating conditions) and also between base stations from different manufacturers. The base station does not explicitly notify the UE of the mapping that has been carried out, rather the UE must take this into account automatically during demodulation (FIG 2).

If there is another way to show this physical mappings, please feel free to let me know.

The R&S Whitepaper is available here if interested.

Radio relay technologies in LTE-Advanced

The following is from NTT Docomo Technical journal: 

Three types of radio relay technologies and their respective advantages and disadvantages are shown in Figure 1. 

A layer 1 relay consists of relay technology called a booster or repeater. This is an Amplifier and Forward (AF) type of relay  technology by which Radio Frequency (RF) signals received on the downlink from the base station are amplified and transmitted to the mobile station. In a similar manner, RF signals received on the uplink from the mobile station are amplified and transmitted to the base station. The equipment functions of a layer 1 relay are relatively simple, which makes for low-cost implementation and short processing delays associated with relaying. With these  features, the layer 1 relay has already found widespread use in 2G and 3G mobile communication systems. It is being deployed with the aim of improving coverage in mountainous regions, sparsely populated areas and urban areas as well as in indoor environments.


The RF performance specifications for repeaters have already been specified in LTE, and deployment of these repeaters for the same purpose is expected. The layer 1 relay, however, amplifies intercell interference and noise together with desired signal components thereby deteriorating the received Signal to Interference plus Noise power Ratio (SINR) and reducing the throughput enhancement gain.


The layer 2 relay, meanwhile, is a Decode and Forward (DF) type of relay technology by which RF signals received on the downlink from the base station are demodulated and decoded and then encoded and modulated again before being sent on to the mobile station. This demodulation and decoding processing performed at the radio relay station overcomes the drawback in layer 1 relays of deteriorated received SINR caused by amplification of intercell interference and noise. A better throughput-enhancement effect can therefore be expected compared with the layer 1 relay. At the same time, the layer 2 relay causes a delay associated with modulation/demodulation and encoding/decoding processing. In this type of relay, moreover, radio functions other than modulation/demodulation and encoding/decoding (such as mobility control, retransmission control by Automatic Repeat request (ARQ), and user-data concatenation/segmentation/reassembly) are performed between the base station and mobile station transparently with respect to the radio relay, which means that new radio-control functions for supporting this relay technology are needed. 

The layer 3 relay also performs demodulation and decoding of RF signals received on the downlink from the base station, but then goes on to perform processing (such as ciphering and user-data concatenation/segmentation/reassembly) for retransmitting user data on a radio interface and finally performs encoding/modulation and transmission to the mobile station. Similar to the layer 2 relay, the layer 3 relay can improve throughput by eliminating inter-cell interference and noise, and additionally, by incorporating the same functions as a base station, it can have small impact on the standard specifications for radio relay technology and on implementation. Its drawback, however, is the delay caused by user-data processing in addition to the delay caused by modulation/demodulation and encoding/decoding processing.


In 3GPP, it has been agreed to standardize specifications for layer 3 relay technology in LTE Rel. 10 because of the above features of improved received SINR due to noise elimination, ease of coordinating standard specifications, and ease of implementing the technology. Standardization of this technology is now moving forward.


Layer 3 radio relay technology is shown in Figure 2. In addition to performing user-data regeneration processing and modulation/demodulation and encoding/ decoding processing as described above, the layer 3 relay station also features a unique Physical Cell ID (PCI) on the physical layer different than that of the base station. In this way, a mobile station can recognize that a cell provided by a relay station differs from a cell provided by a base station.


In addition, as physical layer control signals such as Channel Quality Indicator (CQI) and Hybrid ARQ (HARQ) can terminate at a relay station, a relay station is recognized as a base station from the viewpoint of a mobile station. It is therefore possible for a mobile station having only LTE functions (for example, a mobile station conforming to LTE Rel. 8 specifications) to connect to a relay station. Here, the wireless backhaul link (Un) between the base station and relay station and the radio access link (Uu) between the relay station and mobile station may operate on different frequencies or on the same frequency. In the latter case, if transmit and receive processing are performed simultaneously at the relay station, transmit signals will cause interference with the relay station’s receiver by coupling as long as sufficient isolation is not provided between the transmit and receive circuits. Thus, when operating on the same frequency, the wireless backhaul-link and radio-access-link radio resources should be subjected to Time Division Multiplexing (TDM) so that transmission and reception in the relay station are not performed simultaneously.

Scenarios in which the introduction of relay technology is potentially useful have been discussed in 3GPP. Deployment scenarios are shown in Table 1. Extending the coverage area to mountainous and sparsely populated regions (rural area and wireless backhaul scenarios) is an important scenario to operators. It is expected that relay technology can be used to economically extend coverage to such areas as opposed to deploying fixed-line backhaul links. Relay technology should also be effective for providing temporary coverage when earthquakes or other disasters strike or when major events are being held (emergency or temporary coverage scenario), i.e., for situations in which the deployment of dedicated fixed-line backhaul links is difficult. In addition, while pico base stations and femtocells can be used for urban hot spot, dead spot, and indoor hot spot scenarios, the installation of utility poles, laying of cables inside buildings, etc. can be difficult in some countries and regions, which means that the application of relay technology can also be effective for urban scenarios. Finally, the group mobility scenario in which relay stations are installed on vehicles like trains and buses to reduce the volume of control signals from moving mobile stations is also being proposed.


In 3GPP, it has been agreed to standardize the relay technology deployed for coverage extension in LTE Rel. 10. These specifications will, in particular, support one-hop relay technology in which the position of the relay station is fixed and the radio access link between the base station and mobile station is relayed by one relay station.



References
[1] 3GPP TS36.912 V9.1.0: “Feasibility study for Further Advancement for E-UTRA (LTE-Advanced),” 2010.
[2] 3GPP TS36.323 V9.0.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Packet Data Convergence Protocol (PDCP) specification,” 2009
[3] 3GPP TS36.322 V9.1.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Link Control (RLC) protocol specification,” 2010.
[4] 3GPP TS36.321 V9.2.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Medium Access Control (MAC) protocol specification,” 2010.
[5] 3GPP TS36.331 V9.2.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification,” 2010.
[6] 3GPP TS36.413 V9.2.1: “Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP),” 2010.
[7] 3GPP TR36.806 V9.0.0: “Evolved Universal Terrestrial Radio Access (E-UTRA); Relay architectures for E-UTRA (LTEAdvanced),” 2010.
[8] IETF RFC4960: “Stream Control Transmission Protocol,” 2007.
[9] 3GPP TS29.281 V9.2.0: “General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U),” 2010.

Video: TD-LTE: A separation from LTE FDD

'Mapped Security' Concept in LTE

When a UE registers on a network in 2G/3G or LTE, it has to perform Authentication. The Authentication Vectors are located in the USIM for the device and in Authentication Center (AuC) in the network. Once the Authentication is performed successfully, then the Keys for Ciphering and Integrity are derived and used during the call.

As I showed in my earlier post here, It is possible that the same AuC is used for 2G/3G and LTE networks. In this case if the UE has recently performed Authentication in one network then unless the keys are old, there is no need to perform the Authentication again in the other radio access technology (RAT). The Security keys (Ciphering and Integrity key) would be derived based on the keys in the previous RAT. 3GPP TS 33.102 and 3GPP TS 33.401 gives the details on how to derive the key from the previous RAT while in the new RAT using this mapped security concept.

R&S Whitepaper: LTE Transmission Modes and Beamforming

Interesting technical whitepaper from R&S:

LTE Transmission Modes and Beamforming

View more documents from Zahid Ghadialy

Available to download from here or here.

Overview of LTE Handovers

From the NTT Docomo Technical journal:


The LTE handover is broadly divided into a backward handover (PS handover) and forward handover. In the former, the network performs cell switching and notifies the mobile terminal of the destination cell, and in the latter, the mobile terminal performs autonomous switching to pick up the destination cell.


To control packet loss due to a momentary cutoff at the time of radio switching, PS handover supports a data forwarding process that transfers undelivered data from the switching-source eNodeB to the switching-destination eNodeB and a reordering process that corrects sequencing mistakes between forwarded data and new data.


The forward handover can be classified into Release with Redirection triggered by a cutoff signal from the network and Non Access Stratum (NAS) Recovery in which the mobile terminal autonomously performs a NAS recovery, either of which is accompanied by data loss due to a momentary cutoff. From a different perspective, handover can be classified in the following two ways according to whether it is accompanied by Radio Access Technology (RAT) or frequency switching or by eNodeB or EPC switching (Figure 7).


1) Intra-RAT handover: This is a handover that occurs within the LTE system in which node transition occurs between sectors within an eNodeB, between eNodeBs within an EPC switch, or between EPC switches. 


A handover between eNodeBs within an EPC switch may be an X2 or S1 handover. In an X2 handover, signal processing is performed by the X2 logical interface between eNodeBs, while in an S1 handover, signal processing is performed by the S1 logical interface between an eNodeB and the EPC switch. There is a tradeoff between the cost of maintaining an X2 link and the cost incurred by an S1 handover, and operations are configured accordingly.


Handover can also be classified by whether the center frequency is the same before and after handover, that is, whether the handover occurs within the same frequency or between frequencies.


2) Inter-RAT handover: This is a handover that occurs between RATs either as a transition from LTE to 3G or from 3G to LTE.

A detailed post on LTE to 3G Inter-RAT handover is available here.

Reducing CSFB Timing with RRC R9 Optimisations

While in the initial testing CSFB timing used to be between 6-8 seconds, most Rel-8 phones can complete the CSFB procedure between 4-4.5 seconds. Unfortunately this is still a lot in terms of signalling. To reduce this in Rel-9 there is a simple optimisation that has been done.

In the RRC Connection Release message, there is a possibility to add UTRAN/GERAN System Information messages. In the picture above, I have only shown UTRA System Information but a similar picture can be drawn for GERAN.

Once all the Mandatory SIB's are sent to the UE then it can immediately camp on without the need to read any other additional system info. This will reduce the CSFB time between 1-2 seconds.

The lesser the CSFB time, the better the Quality of end user experience

Quick update on LTE Release 11 Work and Study Items

LTE Release 11 Work and Study Items

View more documents from Zahid Ghadialy

Nice work by Nomor. Available to download from here.

RRC Signalling in Rel-10 for MDT

Last year I wrote about Minimization of Drive Testing (MDT) and mentioned about the possibility of enhancements. Now looking at the new RRC specs I can see a new message LoggedMeasurementsConfiguration has been added,

When the UE is in RRC_CONNECTED mode, this message can be sent and the UE be informed about the measurements to be performed. The message contents are as follows:

LoggedMeasurementConfiguration-r10 ::= SEQUENCE {

criticalExtensions CHOICE {

c1 CHOICE {

loggedMeasurementConfiguration-r10 LoggedMeasurementConfiguration-r10-IEs,

spare3 NULL, spare2 NULL, spare1 NULL

},

criticalExtensionsFuture SEQUENCE {}

}

}

LoggedMeasurementConfiguration-r10-IEs ::= SEQUENCE {

traceReference-r10 TraceReference-r10,

traceRecordingSessionRef-r10 OCTET STRING (SIZE (2)),

tce-Id-r10 OCTET STRING (SIZE (1)),

absoluteTimeInfo-r10 AbsoluteTimeInfo-r10,

areaConfiguration-r10 AreaConfiguration-r10 OPTIONAL, -- Need OR

loggingDuration-r10 LoggingDuration-r10,

loggingInterval-r10 LoggingInterval-r10,

nonCriticalExtension SEQUENCE {} OPTIONAL -- Need OP

}

Once the UE has done the measurements, it can inform the network in one of the following messages, RRCConnectionSetupComplete, RRCConnectionReestablishmentComplete, RRCConnectionReconfigurationComplete and UEInformationResponse that it has the required information available. This is done by including the following new Enum:

logMeasAvailable-r10 ENUMERATED {true} OPTIONAL,

Finally, the network can request the logged Measurements information in the UE Information Request Message. The new fields for that are:


UEInformationRequest-v1020-IEs ::= SEQUENCE {
logMeasReportReq-r10 ENUMERATED {true} OPTIONAL,
nonCriticalExtension SEQUENCE {} OPTIONAL
}

The UE would send the following information in the response message:

LogMeasInfo-r10 ::= SEQUENCE {
locationInfo-r10 LocationInfo-r10 OPTIONAL,
relativeTimeStamp-r10 INTEGER (0..7200),
servCellIdentity-r10 CellGlobalIdEUTRA,
measResultServCell-r10 SEQUENCE {
rsrpResult-r10 RSRP-Range,
rsrqResult-r10 RSRQ-Range
},
measResultNeighCells-r10 SEQUENCE {
measResultListEUTRA-r10 MeasResultList2EUTRA-r9 OPTIONAL,
measResultListUTRA-r10 MeasResultList2UTRA-r9 OPTIONAL,
measResultListGERAN-r10 MeasResultList2GERAN-r10 OPTIONAL,
measResultListCDMA2000-r10 MeasResultList2CDMA2000-r9 OPTIONAL
} OPTIONAL,
...
}


MeasResultList2GERAN-r10 ::= SEQUENCE (SIZE (1..maxCellListGERAN)) OF MeasResultListGERAN


LocationInfo-r10 ::= SEQUENCE {
locationCoordinates-r10 CHOICE {
ellipsoid-Point-r10 OCTET STRING,
ellipsoidPointWithAltitude-r10 OCTET STRING,
...
},
horizontalVelocity-r10 OCTET STRING OPTIONAL,
gnss-TOD-msec-r10 OCTET STRING OPTIONAL,
...
}

New 4G Americas whitepaper on HSPA evolution in 3GPP standards

Some forecasts put HSPA at over 3.5 billion subscribers by the end of 2016. Operators with HSPA and LTE infrastructure and users with HSPA and LTE multi-mode devices will be commonplace. There are 412 commercial deployments of HSPA in 157 countries, including 165 HSPA+ networks. Thus, with the continued deployment of LTE throughout the world, and the existing ubiquitous coverage of HSPA in the world, HSPA+ will continue to be enhanced through the 3GPP standards process to provide a seamless solution for operators as they upgrade their networks. While LTE, with 33 commercial deployments to date and over 250 commitments worldwide, will be the mobile broadband next generation technology of choice for HSPA, EV-DO, WiMAX and new wireless operators, HSPA will continue to be a pivotal technology in providing mobile broadband to subscribers.

The white paper explains that as 3GPP specifications evolve, their advanced features help to further the capabilities of today’s modern mobile broadband networks. With each release there have been improvements such as better cell edge performance, increased system efficiencies, higher peak data rates and an overall improved end-user experience. 3GPP feature evolution from Rel-7 to Rel-10 has pushed possible HSPA peak data rates from 14 Mbps to 168 Mbps. Continued enhancements in 3GPP Rel-11 will again double this capability to a possible peak data rate of 336 Mbps:

• Rel-7: 64QAM or 2X2 MIMO => 21 or 28 Mbps
• Rel-8: DC + 64QAM or 2X2 MIMO + 64QAM => 42 Mbps
• Rel-9: DC + 2X2 MIMO + 64QAM => 84 Mbps
• Rel-10: 4C + 2X2 MIMO + 64QAM => 168 Mbps
• Rel-11: (8C or 4X4 MIMO) + 64QAM => 336 Mbps

“If operators are able to gain new additional harmonized spectrum from governments, they will no doubt deploy LTE, However, it is clear that HSPA+ technology is still exceptionally strong and will continue to provide operators with the capability to meet the exploding data usage demands of their customers in existing spectrum holdings,” Pearson said.

The paper is embedded as follows:

The Evolution of HSPA

View more documents from All About 4G

This paper and other similar papers are available to download from the 3G4G website here.

Donor eNB (DeNB) and Relay Node (RN)

Extracted from 3GPP 36.300:

The eNB hosts the following functions:

- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling);

- IP header compression and encryption of user data stream;

- Selection of an MME at UE attachment when no routing to an MME can be determined from the information provided by the UE;

- Routing of User Plane data towards Serving Gateway;

- Scheduling and transmission of paging messages (originated from the MME);

- Scheduling and transmission of broadcast information (originated from the MME or O&M);

- Measurement and measurement reporting configuration for mobility and scheduling;

- Scheduling and transmission of PWS (which includes ETWS and CMAS) messages (originated from the MME);

- CSG handling;

- Transport level packet marking in the uplink.

The DeNB hosts the following functions in addition to the eNB functions:

- S1/X2 proxy functionality for supporting RNs;

- S11 termination and S-GW/P-GW functionality for supporting RNs.

E-UTRAN supports relaying by having a Relay Node (RN) wirelessly connect to an eNB serving the RN, called Donor eNB (DeNB), via a modified version of the E-UTRA radio interface, the modified version being called the Un interface. The RN supports the eNB functionality meaning it terminates the radio protocols of the E-UTRA radio interface, and the S1 and X2 interfaces. From a specification point of view, functionality defined for eNBs, e.g. RNL and TNL, also applies to RNs unless explicitly specified. RNs do not support NNSF. In addition to the eNB functionality, the RN also supports a subset of the UE functionality, e.g. physical layer, layer-2, RRC, and NAS functionality, in order to wirelessly connect to the DeNB.

The architecture for supporting RNs is shown in Figure 4.7.2-1. The RN terminates the S1, X2 and Un interfaces. The DeNB provides S1 and X2 proxy functionality between the RN and other network nodes (other eNBs, MMEs and S GWs). The S1 and X2 proxy functionality includes passing UE-dedicated S1 and X2 signalling messages as well as GTP data packets between the S1 and X2 interfaces associated with the RN and the S1 and X2 interfaces associated with other network nodes. Due to the proxy functionality, the DeNB appears as an MME (for S1-MME), an eNB (for X2) and an S-GW (for S1-U) to the RN.

For more details see - 3GPP TS 36.300 : Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 (Release 10)

Enhanced Voice Service (EVS) Codec for LTE Rel-10

Its been a while we talked about codecs.

The traditional (narrowband) AMR (Adaptive Multi-Rate) codec operates on narrowband 200-3400 Hz signals at variable bit rates in the range of 4.75 to 12.2 kbps. It provides toll quality speech starting at 7.4 kbps, with near-toll quality and better robustness at lower rates and better reproduction of non-speech sounds at higher rates. The AMR-WB (Wideband) codec provides improved speech quality due to a wider speech bandwidth of 50–7000 Hz compared to narrowband speech coders which in general are optimized for POTS wireline quality of 300–3400 Hz. Couple of years back Orange was in news because they were the first to launch phones that support HD-Voice (AMR-WB).

Extended Adaptive Multi-Rate – Wideband (AMR-WB+) is an audio codec that extends AMR-WB. It adds support for stereo signals and higher sampling rates. Another main improvement is the use of transform coding (transform coded excitation - TCX) additionally to ACELP. This greatly improves the generic audio coding. Automatic switching between transform coding and ACELP provides both good speech and audio quality with moderate bit rates.

As AMR-WB operates at internal sampling rate 12.8 kHz, AMR-WB+ also supports various internal sampling frequencies ranges from 12.8 kHz to 38.4 kHz. AMR-WB uses 16 kHz sampling frequency with a resolution of 14 bits left justified in a 16-bit word. AMR-WB+ uses 16/24/32/48 kHz sampling frequencies with a resolution of 16 bits in a 16-bit word.

Introduction of LTE (Long Term Evolution) brings enhanced quality for 3GPP multimedia services. The high throughput and low latency of LTE enable higher quality media coding than what is possible in UMTS. LTE-specific codecs have not yet been defined but work on them is ongoing in 3GPP. The LTE codecs are expected to improve the basic signal quality, but also to offer new capabilities such as extended audio bandwidth, stereo and multi-channels for voice and higher temporal and spatial resolutions for video. Due to the wide range of functionalities in media coding, LTE gives more flexibility for service provision to cope with heterogeneous terminal capabilities and transmission over heterogeneous network conditions. By adjusting the bit-rate, the computational complexity, and the spatial and temporal resolution of audio and video, transport and rendering can be optimised throughout the media path hence guaranteeing the best possible quality of service.

A feasibility study on Enhanced Voice Service (EVS) for LTE has recently been finalised in 3GPP with the results given in Technical Report 22.813 ‘‘Study of Use Cases and Requirements for Enhanced Voice Codecs in the Evolved Packet System (EPS)”. EVS is intended to provide substantially enhanced voice quality for conversational use, i.e. telephony. Improved transmission efficiency and optimised behaviour in IP environments are further targets. EVS also has potential for quality enhancement for non-voice signals such as music. The EVS study, conducted jointly by 3GPP SA4 (Codec) and SA1 (Services) working groups, identifies recommendations for key characteristics of EVS (system and service requirements, and high level technical requirements on codecs).

The study further proposes the development and standardization of a new EVS codec for LTE to be started. The codec is targeted to be developed by March 2011, in time for 3GPP Release 10.

Fig. above illustrates the concept of EVS. The EVS codec will not replace the existing 3GPP narrowband and wideband codecs AMR and AMR-WB but will provide a complementing high quality codec via the introduction of higher audio bandwidths, in particular super wideband (SWB: 50–14,000 Hz). It will also support narrowband (NB: 200–3400 Hz) and wideband (WB: 50–7000 Hz) and may support fullband audio (FB: 20–20,000 Hz).

More details available in the following whitepapers by Nokia [PDF]:

• Media coding for the next generation mobile system LTE
• 3GPP Enhanced Voice Services (EVS) codec

Multipoint HSDPA / HSPA

The following is from 3GPP TR 25.872 - Technical Specification Group Radio Access Network; HSDPA Multipoint Transmission:

HSPA based mobile internet offerings are becoming very popular and data usage is increasing rapidly. Consequently, HSPA has begun to be deployed on more than one transmit antenna or more than one carrier. As an example, the single cell downlink MIMO (MIMO-Physical layer) feature was introduced in Release 7. This feature allowed a NodeB to transmit two transport blocks to a single UE from the same cell on a pair of transmit antennas thus improving data rates at high geometries and providing a beamforming advantage to the UE in low geometry conditions. Subsequently, in Release-8 and Release-9, the dual cell HSDPA (DC-HSDPA) and dual band DC-HSDPA features were introduced. Both these features allow the NodeB to serve one or more users by simultaneous operation of HSDPA on two different carrier frequencies in two geographically overlapping cells, thus improving the user experience across the entire cell coverage area. In Release 10 these concepts were extended so that simultaneous transmissions to a single UE could occur from four cells (4C-HSDPA).

When a UE falls into the softer or soft handover coverage region of two cells on the same carrier frequency, it would be beneficial for the non-serving cell to be able to schedule packets to this UE and thereby improving this particular user’s experience, especially when the non-serving cell is partially loaded. MultiPoint HSDPA allows two cells to transmit packets to the same UE, providing improved user experience and system load balancing. MultiPoint HSDPA can operate on one or two frequencies.

Click to enlarge

There is also an interesting Qualcomm Whitepaper on related topic that is available to view and download here. The following is from that whitepaper:

The simplest form of Multipoint HSPA, Single Frequency Dual Cell HSPA (SFDC-HSPA), can be seen as an extension to the existing DC-HSPA feature. While DC-HSPA allows scheduling of two independent transport blocks to the mobile device (UE) from one sector on two frequency carriers, SFDC-HSPA allows scheduling of two independent transport blocks to the UE from two different sectors on the same carrier. In other words, it allows for a primary and a secondary serving cell to simultaneously send different data to the UE. Therefore, the major difference between SFDC-HSPA and DC-HSPA operation is that the secondary transport block is scheduled to the UE from a different sector on the same frequency as the primary transport block. The UE also needs to have receive diversity (type 3i) to suppress interference from the other cell as it will receive data on the same frequecny from multiple serving cells.Figure 1 llustrates the high-level concept of SFDC-HSPA.

In the case where the two sectors involved in Multipoint HSPA transmission belong to the same NodeB (Intra-NodeB mode), as illustrated in Figure 2, there is only one transmission queue maintained at the NodeB and the RNC. The queue management and RLC layer operation is essentially the same as for DC-HSPA.

In the case where the two sectors belong to different NodeBs (Inter-NodeB mode), as illustrated in Figure 2, there is a separate transmission queue at each NodeB. RLC layer enhancements are needed at the RNC along with enhanced flow control on the Iub interface between RNC and NodeB in order to support Multipoint HSPA operation across NodeBs. These enhancements are discussed in more detail in Section 4. In both modes, combined feedback information (CQI and HARQ-ACK/ NAK) needs to be sent on the uplink for both data streams received from the serving cells. On the uplink, the UE sends CQIs seen on all sectors using the legacy channel structure, with timing aligned to the primary serving cell.

When two carriers are available in the network, there is an additional degree of freedom in the frequency domain. Dual Frequency Dual Cell HSPA (DFDC-HSPA) allows exploiting both frequency and spatial domains by scheduling two independent transport blocks to the UE from two different sectors on two different frequency carriers. For a DC-HSPA capable UE, this is equivalent to having independent serving cells on the two frequency carriers. In Figure 3, UE1 is in DC-HSPA mode, whereas UE2 is in DFDC-HSPA mode.

Dual Frequency Four-Cell HSPA (DF4C-HSPA) can be seen as a natural extension of DFDC-HSPA, suitable for networks with UEs having four receiver chains. DF4C-HSPA allows use of the four receiver chains by scheduling four independent transport blocks to the UE from two different sectors on two different frequency carriers. DF4C-HSPA is illustrated in Figure 4.

Like SFDC-HSPA; DFDC-HSPA and DF4C-HSPA can also be intra-NodeB or inter-NodeB, resulting in an impact on transmission queue management, Iub flow control and the RLC layer.

Advantages of Multipoint transmission:

* Cell Edge Performance Improvement

* Load balancing across sectors and frequency carriers

* Leveraging RRU and distributed NodeB technology

Multipoint HSPA improves the performance of cell edge users and helps balance the load disparity across neighboring cells. It leverages advanced receiver technology already available in mobile devices compatible with Release 8 and beyond to achieve this. The system impact of Multipoint HSPA on the network side is primarily limited to software upgrades affecting the upper layers (RLC and RRC).

See also: FS_HSDPA_MP_TX: Study on HSDPA Multipoint Transmission

A look at "Idle state Signalling Reduction" (ISR)

The following is from 3GPP TS 23.401, Annex J:

General description of the ISR concept

Idle state Signalling Reduction (or ISR) aims at reducing the frequency of Tracking Area Updates (TAU, in EUtran) and Routing Area Updates (RAU, in UTRAN/GERAN) procedures caused by UEs reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially the update signalling between UE and network is reduced. But also network internal signalling is reduced. To some extent the reduction of network internal signalling is also available when ISR is not used or not activated by the network.

UMTS described already RAs containing GERAN and UTRAN cells, which also reduces update signalling between UE and network. The combination of GERAN and UTRAN into the same RAs implies however common scaling, dimensioning and configuration for GERAN and UTRAN (e.g. same RA coverage, same SGSN service area, no GERAN or UTRAN only access control, same physical node for GERAN and UTRAN). As an advantage it does not require special network interface functionality for the purpose of update signalling reduction.

ISR enables signalling reduction with separate SGSN and MME and also with independent TAs and RAs. Thereby the interdependency is drastically minimized compared with the GERAN/UTRAN RAs. This comes however with ISR specific node and interface functionality. SGSN and MME may be implemented together, which reduces some interface functions but results also in some dependencies.

ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional for the network. ISR requires special functionality in both the UE and the network (i.e. in the SGSN, MME and Serving GW) to activate ISR for a UE. For this activation, the MME/SGSN detects whether S-GW supports ISR based on the configuration and activates ISR only if the S-GW supports the ISR. The network can decide for ISR activation individually for each UE. Gn/Gp SGSNs do not support ISR functionality. No specific HSS functionality is required to support ISR.

NOTE. A Release 7 HSS needs additional functionality to support the 'dual registration' of MME and SGSN. Without such an upgrade, at least PS domain MT Location Services and MT Short Messages are liable to fail.

It is inherent functionality of the MM procedures to enable ISR activation only when the UE is able to register via E-UTRAN and via GERAN/UTRAN. For example, when there is no E-UTRAN coverage there will be also no ISR activation. Once ISR is activated it remains active until one of the criteria for deactivation in the UE occurs, or until SGSN or MME indicate during an update procedure no more the activated ISR, i.e. the ISR status of the UE has to be refreshed with every update.

When ISR is activated this means the UE is registered with both MME and SGSN. Both the SGSN and the MME have a control connection with the Serving GW. MME and SGSN are both registered at HSS. The UE stores MM parameters from SGSN (e.g. P-TMSI and RA) and from MME (e.g. GUTI and TA(s)) and the UE stores session management (bearer) contexts that are common for E-UTRAN and GERAN/UTRAN accesses. In idle state the UE can reselect between E-UTRAN and GERAN/UTRAN (within the registered RA and TAs) without any need to perform TAU or RAU procedures with the network. SGSN and MME store each other's address when ISR is activated.

When ISR is activated and downlink data arrive, the Serving GW initiates paging processes on both SGSN and MME. In response to paging or for uplink data transfer the UE performs normal Service Request procedures on the currently camped-on RAT without any preceding update signalling (there are however existing scenarios that may require to perform a RAU procedure prior to the Service Request even with ISR is activated when GERAN/UTRAN RAs are used together, as specified in clause 6.13.1.3 of TS 23.060 [7]).

The UE and the network run independent periodic update timers for GERAN/UTRAN and for E-UTRAN. When the MME or SGSN do not receive periodic updates MME and SGSN may decide independently for implicit detach, which removes session management (bearer) contexts from the CN node performing the implicit detach and it removes also the related control connection from the Serving GW. Implicit detach by one CN node (either SGSN or MME) deactivates ISR in the network. It is deactivated in the UE when the UE cannot perform periodic updates in time. When ISR is activated and a periodic updating timer expires the UE starts a Deactivate ISR timer. When this timer expires and the UE was not able to perform the required update procedure the UE deactivates ISR.

Part of the ISR functionality is also available when ISR is not activated because the MM contexts are stored in UE, MME and SGSN also when ISR is not active. This results in some reduced network signalling, which is not available for Gn/Gp SGSNs. These SGSNs cannot handle MM and session management contexts separately. Therefore all contexts on Gn/Gp SGSNs are deleted when the UE changes to an MME. The MME can keep their MME contexts in all scenarios.

Note:

Gn = IP Based interface between SGSN and other SGSNs and (internal) GGSNs. DNS also shares this interface. Uses the GTP Protocol.

Gp = IP based interface between internal SGSN and external GGSNs. Between the SGSN and the external GGSN, there is the border gateway (which is essentially a firewall). Also uses the GTP Protocol.

"Temporary Identity used in Next update" (TIN)

The UE may have valid MM parameters both from MME and from SGSN. The "Temporary Identity used in Next update" (TIN) is a parameter of the UE's MM context, which identifies the UE identity to be indicated in the next RAU Request or TAU Request message. The TIN also identifies the status of ISR activation in the UE.

The TIN can take one of the three values, "P-TMSI", "GUTI" or "RAT-related TMSI". The UE sets the TIN when receiving an Attach Accept, a TAU Accept or RAU Accept message as specified in table 4.3.5.6-1.

"ISR Activated" indicated by the RAU/TAU Accept message but the UE not setting the TIN to "RAT-related TMSI" is a special situation. By maintaining the old TIN value the UE remembers to use the RAT TMSI indicated by the TIN when updating with the CN node of the other RAT.

Only if the TIN is set to "RAT-related TMSI" ISR behaviour is enabled for the UE, i.e. the UE can change between all registered areas and RATs without any update signalling and it listens for paging on the RAT it is camped on. If the TIN is set to "RAT-related TMSI", the UE's P-TMSI and RAI as well as its GUTI and TAI(s) remain registered with the network and valid in the UE.

When ISR is not active the TIN is always set to the temporary ID belonging to the currently used RAT. This guarantees that always the most recent context data are used, which means during inter-RAT changes there is always context transfer from the CN node serving the last used RAT. The UE identities, old GUTI IE and additional GUTI IE, indicated in the next TAU Request message, and old P-TMSI IE and additional P-TMSI/RAI IE, indicated in the next RAU Request message depend on the setting of TIN.

The UE indicates also information elements "additional GUTI" or "additional P-TMSI" in the Attach Request, TAU or RAU Request. These information elements permit the MME/SGSN to find the already existing UE contexts in the new MME or SGSN, when the "old GUTI" or "old P-TMSI" indicate values that are mapped from other identities.

ISR activation

The information flow in Figure below shows an example of ISR activation. For explanatory purposes the figure is simplified to show the MM parts only.

The process starts with an ordinary Attach procedure not requiring any special functionality for support of ISR. The Attach however deletes any existing old ISR state information stored in the UE. With the Attach request message, the UE sets its TIN to "GUTI". After attach with MME, the UE may perform any interactions via E-UTRAN without changing the ISR state. ISR remains deactivated. One or more bearer contexts are activated on MME, Serving GW and PDN GW, which is not shown in the figure.

The first time the UE reselects GERAN or UTRAN it initiates a Routing Area Update. This represents an occasion to activate ISR. The TIN indicates "GUTI" so the UE indicates a P-TMSI mapped from a GUTI in the RAU Request. The SGSN gets contexts from MME. When the MME sends the context to the SGSN, the MME includes the ISR supported indication only if the involved S-GW supports the ISR. After the ISR activated, both CN nodes keep these contexts because ISR is being activated. The SGSN establishes a control relation with the Serving GW, which is active in parallel to the control connection between MME and Serving GW (not shown in figure). The RAU Accept indicates ISR activation to the UE. The UE keeps GUTI and P-TMSI as registered, which the UE memorises by setting the TIN to "RAT-related TMSI". The MME and the SGSN are registered in parallel with the HSS.

After ISR activation, the UE may reselect between E-UTRAN and UTRAN/GERAN without any need for updating the network as long as the UE does not move out of the RA/TA(s) registered with the network.

The network is not required to activate ISR during a RAU or TAU. The network may activate ISR at any RAU or TAU that involves the context transfer between an SGSN and an MME. The RAU procedure for this is shown in Figure above. ISR activation for a UE, which is already attached to GERAN/UTRAN, with a TAU procedure from E-UTRAN works in a very similar way.

Reference: 3GPP TS 23.401: General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access

Benefits of Self Optimizing Networks in LTE

Self Optimizing Networks : Benefits of SON in LTE - July 2011

View more documents from Zahid Ghadialy

Mobility Robustness Optimization to avoid Handover failures

The following is from 4G Americas Whitepaper on SON:

Mobility Robustness Optimization (MRO) encompasses the automated optimization of parameters affecting active mode and idle mode handovers to ensure good end-user quality and performance, while considering possible competing interactions with other SON features such as, automatic neighbor relation and load balancing.

There is also some potential for interaction with Cell Outage Compensation and Energy Savings as these could also potentially adjust the handover boundaries in a way that conflicts with MRO. While the goal of MRO is the same regardless of radio technology namely, the optimization of end-user performance and system capacity, the specific algorithms and parameters vary with technology.

The objective of MRO is to dynamically improve the network performance of HO (Handovers) in order to provide improved end-user experience as well as increased network capacity. This is done by automatically adapting cell parameters to adjust handover boundaries based on feedback of performance indicators. Typically, the objective is to eliminate Radio Link Failures and reduce unnecessary handovers. Automation of MRO minimizes human intervention in the network management and optimization tasks.

The scope of mobility robustness optimization as described here assumes a well-designed network with overlapping RF coverage of neighboring sites. The optimization of handover parameters by system operators typically involves either focused drive-testing, detailed system log collection and postprocessing, or a combination of these manual and intensive tasks. Incorrect HO parameter settings can negatively affect user experience and waste network resources by causing HO ping-pongs, HO failures and Radio Link Failures (RLF). While HO failures that do not lead to RLFs are often recoverable and invisible to the user, RLFs caused by incorrect HO parameter settings have a combined impact on user experience and network resources. Therefore, the main objective of mobility robustness optimization should be the reduction of the number of HO-related radio link failures. Additionally, sub-optimal configuration of HO parameters may lead to degradation of service performance, even if it does not result in RLFs. One example is the incorrect setting of HO hysteresis, which may results in ping-pongs or excessively delayed handovers to a target cell. Therefore, the secondary objective of MRO is the reduction of the inefficient use of network resources due to unnecessary or missed handovers.

Most problems associated with HO failures or sub-optimal system performance can ultimately be categorized, as either too-early or too-late triggering of the handover, provided that the required fundamental network RF coverage exists. Thus, poor HO-related performance can generally be categorized by the following events:

* Intra-RAT late HO triggering

* Intra-RAT early HO triggering

* Intra-RAT HO to an incorrect cell

* Inter-RAT too late HO

* Inter RAT unnecessary HO

Up to Release 9, a UE is required to send RLF report only in case of successful RRC re-establishment after a connection failure. Release 10 allows support for RLF reports to be sent even when the RRC reestablishment does not succeed. The UE is required to report additional information to assist the eNB in determining if the problem is coverage related (no strong neighbors) or handover problems (too early, too late or wrong cell). Furthermore, Release 10 allows for precise detection of too early / wrong cell HO.

HSPA evolution – beyond 3GPP Release 10

HSPA evolution – beyond 3GPP Release 10, Ericsson, Jul. 2011

View more documents from Zahid Ghadialy

This and other HSPA/HSPA+ presentations are available to download here.