SC-FDMA Modulation

Modulation symbol mapping

The transmitter of an SC-FDMA system converts a binary input signal to a sequence of modulated subcarriers. Todo so, it performs the signal processing operations shown in the Figure. Signal processing is repetitive in a few different time intervals. Resource assignment takes place in transmit time intervals (TTIs). In 3GPP LTE, a typical TTI is 0.5 ms. The TTI is further divided into time intervals referred to as blocks. A block is the time used to transmit all of subcarriers once.

At the input to the transmitter a baseband modulator transforms the binary input to a multilevel sequence of complex numbers Xn in one of several possible modulation formats including Binary Phase Shift Keying (BPSK), quaternary PSK (QPSK), 16-level Quadrature Amplitude Modulation (16-QAM) and 64-QAM. The system adapts the modulation format, and thereby the transmission bit rate, to match the current channel conditions of each terminal.

The type of modulation format used often depends on the signal-to-noise level of the received signal and the receiver ability to decode them correctly. These modulated symbols are then mapped to subcarriers. An inverse-FFT (IFFT) is used to transform the modulated subcarriers in frequency domain to time domain samples.

In general, the same modulation format is used in all the subcarriers to keep the control information overhead small. However, it is possible to have different modulation formats over multiple subcarriers, and it is in fact advantageous in harsh and time varying channel conditions. In a broadband system, the channel is frequency selective over its large system bandwidth, meaning the signal fading on each subcarrier is independent. The interference level on each subcarrier can also be different and vary uniquely with time. It results in a different signal-to-impairment level on each of the subcarriers. Hence, having an appropriate modulation format on these subcarriers would help to maximize the overall system throughput. OFDM system inherits an adaptation of modulation formats to each of the subcarriers depending on channel conditions, and this is called Channel-dependent scheduling.

A cyclic prefix block copies a portion of the samples at the end of the time domain samples block (at the IFFT output) to the beginning. Since the DFT/FFT outputs are periodic in theory, copying the samples to the beginning will make the signal continuous. The length of the cyclic prefix depends on the channel delay spread, and is preferably longer than the length of the channel response. At the receiver, the prefix part of the symbol is thrown away as it may contain ISI from its previous symbol. Hence, it removes the effect of ISI caused by the multipath signal propagation. However, the prefix is the overhead in an OFDM system, as it does not carry any useful information.

PAPR analysis SC-FDMA offers similar performance and complexity as OFDM. However, the main advantage of SC-FDMA is the low PAPR (peak-average-power ratio) of the transmit signal. PAPR is defined as the ratio of the peak power to average power of the transmit signal. As PAPR is a major concern at the user terminals, low PAPR makes the SC-FDMA the preferred technology for the uplink transmission. PAPR relates to the power amplifier efficiency at the transmitter, and the maximum power efficiency is achieved when the amplifier operates at the saturation point. Lower PAPR allows operation of the power amplifier close to saturation resulting in higher efficiency. With higher PAPR signal, the power amplifier operating point has to be backed off to lower the signal distortion, and thereby lowering amplifier efficiency.

As SC-FDMA modulated signal can be viewed as a single carrier signal, a pulse shaping filter can be applied to transmit signal to further improve PAPR. PAPR comparison between OFDM and SC-FDMA variations such as interleaved SC-FDMA and localized SC-FDMA has been done in [2]. With no pulse shaping filters, interleavedSC-FDMA shows the best PAPR. Compared to OFDM PAPR, the PAPR of interleaved SCFDMA with QPSK is about 10 dB lower, whereas that of localized SC-FDMA is only about 3 dB lower. With 16-QAM, these levels are about 7 dB and 2 dB lower respectively. Therefore, interleaved SC-FDMA is a preferred modulation technique for lower PAPR. Pulse shape filtering of SC-FDMA in fact degrades the PAPR level of interleaved SC-FDMA whereas it shows no effect with localized SC-FDMA.

LTE SC-FDMA

For the LTE uplink, a different concept is used for the access technique. Although still using a form of OFDMA technology, the implementation is called Single Carrier Frequency Division Multiple Access (SC-FDMA).

Single carrier frequency division multiple access (SC-FDMA) has been adopted by the third generation partnership project (3GPP) for uplink transmission in technology standardized for long term evolution (LTE) of cellular systems.SC-FDMA was chosen because it combines the low PAPR techniques of single-carrier transmission systems, such as GSM and CDMA, with the multi-path resistance and flexible frequency allocation of OFDMA.

One of the key parameters that affects all mobiles is that of battery life. Even though battery performance is improving all the time, it is still necessary to ensure that the mobiles use as little battery power as possible. With the RF power amplifier that transmits the radio frequency signal via the antenna to the base station being the highest power item within the mobile, it is necessary that it operates in as efficient mode as possible. This can be significantly affected by the form of radio frequency modulation and signal format. Signals that have a high peak to average ratio and require linear amplification do not lend themselves to the use of efficient RF power amplifiers. As a result it is necessary to employ a mode of transmission that has as near a constant power level when operating. Unfortunately OFDM has a high peak to average ratio. While this is not a problem for the base station where power is not a particular problem, it is unacceptable for the mobile. As a result, LTE uses a modulation scheme known as SC-FDMA - Single Carrier Frequency Division Multiplex which is a hybrid format. This combines the low peak to average ratio offered by single-carrier systems with the multipath interference resilience and flexible subcarrier frequency allocation that OFDM provides.

SC-FDMA is a modified form of OFDM with similar throughput performance and complexity. This is often viewed as DFT-coded OFDM where time-domain data symbols are transformed to frequency-domain by a discrete Fourier transform (DFT) before going through the standard OFDM modulation. Thus, SC-FDMA inherits all the advantages of OFDM over other well-known techniques such as TDMA and CDMA.

The major problem in extending GSM TDMA and wideband CDMA to broadband systems is the increase in complexity with the multipath signal reception. The distinguishing feature of SC-FDMA is that it leads to a singlecarrier transmit signal, in contrast to OFDMA which is a multi-carrier transmission scheme which makes it suitable for broadband systems.

In SC-FDMA as well as OFDM, equalization is achieved on the receiver side after the FFT calculation, by multiplying each Fourier coefficient by a complex number. The advantage is that FFT and frequency domain equalization requires less computation power than the conventional timedomain equalization.

QoS Class Identifier (QCI)

The need for supporting a broader variety of applications requiring higher bandwidth and lower latency led 3GPP to alleviate the existing QoS principles with the introduction for EPS of a QoS Class Identifier (QCI).

The QCI is a scalar denoting a set of transport characteristics (bearer with/without guaranteed bit rate, priority, packet delay budget, packet error loss rate) and used to infer nodes specific parameters that control packet forwarding treatment (e.g., scheduling weights, admission thresholds, queue management thresholds, link-layer protocol configuration, etc.).

Each packet flow is mapped to a single QCI value (nine are defined in the Release 8 version of the specifications) according to the level of service required by the application. The usage of the QCI avoids the transmission of a full set of QoS-related parameters over the network interfaces and reduces the complexity of QoS negotiation.

The QCI, together with Allocation-Retention Priority (ARP) and, if applicable, Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR), determines the QoS associated to an EPS bearer. A mapping between EPS and pre-Release 8 QoS parameters has been defined to allow proper interworking with legacy networks.

The QoS architecture in EPC enables a number of important capabilities for both operators and users:

• VoIP support with IMS. QoS is a crucial element for providing LTE/IMS voice service. 
• Enhanced application performance. Applications such as gaming or video can operate more reliably. 
• More flexible business models. With flexible, policy-based charging control, operators and third-parties will be able to offer content in creative new ways. For example, an enhanced video stream to a user could be paid for by an advertiser. 
• Congestion control. In congestion situations, certain traffic flows (e.g., bulk transfers, abusive users) can be throttled down to provide a better user experience for others.

IP address allocation

A UE performs the address allocation procedures for at least one IP address (either IPv4 address or IPv6 prefix) after the default bearer activation if no IPv4 address is allocated during the default bearer activation.

One of the following ways is used to allocate IP addresses for the UE:

a) The HPLMN allocates the IP address to the UE when the default bearer is activated (dynamic or static HPLMN address);

b) The VPLMN allocates the IP address to the UE when the default bearer is activated (dynamic VPLMN address); or

c) The PDN operator or administrator allocates an (dynamic or static) IP address to the UE when the default bearer is activated (External PDN Address Allocation).

The IP address allocated for the default bearer is used for the dedicated bearers within the same PDN connection. IP address allocation for PDN connections, which are activated by the UE requested PDN connectivity procedure, is handled with the same set of mechanisms as those used within the Attach procedure.

PDN types IPv4, IPv6 and IPv4v6 are supported. An EPS Bearer of PDN type IPv4v6 may be associated with one IPv6 prefix only or with both one IPv4 address and one IPv6 prefix. PDN type IPv4 is associated with an IPv4 address. PDN type IPv6 is associated with an IPv6 prefix. PDN types IPv4 and IPv6 are utilised for the UE and/or the PDN GW support IPv4 addressing only or IPv6 prefix only; or operator preferences dictate the use of a single IP version only, or the subscription is limited to IPv4 only or IPv6 only for this APN. In addition, PDN type IPv4 and IPv6 are utilised for interworking with nodes of earlier releases.

The way that the UE sets the requested PDN type may be pre-configured in the device per APN. Unless otherwise configured (including when the UE does not send any APN), the UE sets the PDN type during the Attach or PDN Connectivity procedures based on its IP stack configuration as follows:

- A UE which is IPv6 and IPv4 capable shall request for PDN type IPv4v6.

- A UE which is only IPv4 capable shall request for PDN type IPv4.

- A UE which is only IPv6 capable shall request for PDN type IPv6.

- When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT), the UE requests for PDN type IPv4v6.

The HSS stores one or more PDN types per APN in the subscription data. During the Attach or UE requested PDN connectivity procedure MME compares the requested PDN type to the PDN type in the subscription records for the given APN and sets the PDN type as follows:

- If the requested PDN type is allowed by subscription, the MME sets the PDN type as requested.

- If the requested PDN type is IPv4v6 and subscription data only allows PDN type IPv4 or only allows PDN type IPv6, the MME sets the PDN type according to the subscribed value. A reason cause shall be returned to the UE indicating that only the assigned PDN type is allowed. In this case the UE shall not request another PDN connection to the same APN for the other IP version.

- If the requested PDN type is IPv4 or IPv6, and neither the requested PDN type nor PDN type IPv4v6 are subscribed, the PDN connection request is rejected.

- If the requested PDN type is IPv4v6, and both IPv4 and IPv6 PDN types are allowed by subscription but not IPv4v6, the MME shall set the PDN type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation specific. The UE should then initiate the UE requested PDN connectivity procedure to this APN in order to activate a second PDN connection with the other single address PDN type which was not allocated by the network.

NOTE 1: If the MT and TE are separated, the UE might not be able to use reason cause "single address bearers only" as a trigger for activating a second single-stack EPS bearer.

The PDN GW may restrict the usage of a PDN type IPv4v6 as follows.

- If the PDN GW receives a request for PDN type IPv4v6, but the PDN GW operator preferences dictate the use of IPv4 addressing only or IPv6 prefix only for this APN, the PDN type shall be changed to a single address PDN type (IPv4 or IPv6) and a reason cause shall be returned to the UE indicating that only the assigned PDN type is allowed. In this case the UE shall not request another PDN connection to the same APN for the other IP version.

- If the PDN GW receives a request for PDN type IPv4v6, but the MME does not set the Dual Address Bearer Flag due to the MME operator using single addressing per bearer to support interworking with nodes of earlier releases the PDN type shall be changed to a single IP version only and a reason cause shall be returned to the UE indicating that only single IP version per PDN connection is allowed. In this case the UE should request another PDN connection for the other IP version using the UE requested PDN connectivity procedure to the same APN with a single address PDN type (IPv4 or IPv6) other than the one already activated.

During inter-RAT mobility between E UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4v6 is mapped one-to-one to PDP type IPv4v6.

During inter-RAT mobility between E-UTRAN and UTRAN/GERAN, an EPS bearer with PDN type IPv4 is mapped one-to-one to a PDP context of PDP type IPv4. An EPS bearer with PDN type IPv6 is mapped one-to-one to a PDP context of PDP type IPv6.

It is the HPLMN operator that should define in the subscription whether a dynamic HPLMN or VPLMN address may be used.

The EPS UE may indicate to the network within the Protocol Configuration Options element that the UE wants to obtain the IPv4 address with DHCPv4:

- the UE may indicate that it prefers to obtain an IPv4 address as part of the default bearer activation procedure. In such a case, the UE relies on the EPS network to provide IPv4 address to the UE as part of the default bearer activation procedure.

- the UE may indicate that it prefers to obtain the IPv4 address after the default bearer setup by DHCPv4. That is, when the EPS network supports DHCPv4 and allows that, it does not provide the IPv4 address for the UE as part of the default bearer activation procedures. The network may respond to the UE by setting the PDN Address to 0.0.0.0. After the default bearer establishment procedure is completed, the UE uses the connectivity with the EPS and initiates the IPv4 address allocation on its own using DHCPv4. However, if the EPS network provides IPv4 address to the UE as part of the default bearer activation procedure, the UE should accept the IPv4 address indicated in the default bearer activation procedure.

- if the UE sends no Address Allocation Preference, the PDN GW determines whether to use DHCPv4 or not based on per APN configuration

Both EPS network elements and UE shall support the following mechanisms:

a. IPv4 address allocation via default bearer activation, if IPv4 is supported.

b. IPv6 prefix allocation via IPv6 Stateless Address autoconfiguration according to RFC 4862 [18], if IPv6 is supported;

Furthermore, the Protocol Configuration Options may be used during bearer activation to configure parameters which are needed for IP address allocation. Both EPS network elements and UE may support the following mechanisms:

a. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039 [25];

b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736 [20].

c. Allocation of IPv6 prefixes using DHCPv6 according to RFC 3633 [21].

EPS network elements may support the following mechanism:

a. Allocation of a static IPv4 address and/or a static IPv6 prefix based on subscription data in the HSS.

If the static IP address/prefix is not stored in the HSS subscription record, it may be configured on a per-user per-APN basis in the DHCP/Radius/Diameter server and the PDN GW retrieves the IP address/prefix for the UE from the DHCP/Radius/Diameter server. In this case, static IP address/prefix is allocated by the same procedures as the dynamic IP address/prefix allocation.

The following clauses describe how the above listed IP address allocation mechanisms work when GTP based S5/S8 is used. The way of working of the IP address allocation mechanisms for PMIP based S5/S8 can be found in TS 23.402 [2].The procedures can be used both for PLMN (VPLMN/HPLMN) or external PDN based IP address allocation.

NOTE 2: It is transparent to the UE whether the PLMN or the external PDN allocates the IP address and whether the IP address is static or dynamic.

In order to support DHCP based IP address configuration, the PDN GW acts as the DHCP server for HPLMN assigned dynamic and static and VPLMN assigned dynamic IP addressing. When DHCP is used for external PDN assigned addressing and parameter configuration, the PDN GW shall act as the DHCP server towards the UE and it shall act as the DHCP client towards the external DHCP server. The Serving GW does not have any DHCP functionality. It forwards packets, including DHCP packets, between the UE and the PDN GW.

IPv6 Stateless Address autoconfiguration specified in RFC 4862 [18] is the basic mechanism to allocate /64 IPv6 prefix to the UE.

During default bearer establishment, the PDN GW sends the IPv6 prefix and Interface Identifier to the S GW, and then the S GW forwards the IPv6 prefix and Interface Identifier to the MME or to the SGSN. The MME or the SGSN forwards the IPv6 Interface Identifier to the UE. The MME does not forward the IPv6 prefix to the UE. If the UE receives the IPv6 prefix from the SGSN during PDP Context Activation procedure, it ignores it.

NAS Attach Request

The UE initiates the Attach procedure by the transmission, to the eNodeB, of an Attach Request. Following parameters are included in this message.

IMSI or old GUTI, last visited TAI (if available), UE Core Network Capability, UE Specific DRX parameters, Attach Type, ESM message container (Request Type, PDN Type, Protocol Configuration Options, Ciphered Options Transfer Flag), KSIASME, NAS sequence number, NAS-MAC, additional GUTI, P-TMSI signature, Voice domain preference and UE's usage setting) message together with RRC parameters indicating the Selected Network and the old GUMMEI.

The old GUTI may be derived from a P TMSI and RAI.

IMSI is included

• if the UE does not have a valid GUTI or
• if the UE does not have a valid P TMSI available, or
• if the UE is configured to perform Attach with IMSI at PLMN change and is accessing a new PLMN. 

The UE stores the TIN in detached state.

• If the UE's TIN indicates "GUTI" or "RAT-related TMSI" and the UE holds a valid GUTI then the old GUTI indicates this valid GUTI. 
• If the UE's TIN indicates "P TMSI" and the UE holds a valid P TMSI and related RAI then these two elements are indicated as the old GUTI. Mapping a P TMSI and RAI to a GUTI 
• If the UE holds a valid GUTI and the old GUTI indicates a GUTI mapped from a P-TMSI and RAI, then the UE indicates the GUTI as additional GUTI. If the old GUTI indicates a GUTI mapped from a P-TMSI and RAI and the UE has a valid P-TMSI signature associated to it, the P-TMSI signature shall be included.

The UE sets the voice domain preference and UE's usage setting according to its configuration. If available, the last visited TAI shall be included in order to help the MME produce a good list of TAIs for any subsequent Attach Accept message. Selected Network indicates the PLMN that is selected for network sharing purposes. The RRC parameter "old GUMMEI" takes its value from the "old GUTI" contained in the Attach Request.

If the UE has valid security parameters, the Attach Request message is integrity protected by the NAS-MAC in order to allow validation of the UE by the MME. KSIASME, NAS sequence number and NAS-MAC are included if the UE has valid EPS security parameters. NAS sequence number indicates the sequential number of the NAS message. If the UE does not have a valid EPS security association, then the Attach Request message is not integrity protected.

The UE network capabilities indicate also the supported NAS and AS security algorithms. PDN type indicates the requested IP version (IPv4, IPv4/IPv6, IPv6). Protocol Configuration Options (PCO) are used to transfer parameters between the UE and the PDN GW, and are sent transparently through the MME and the Serving GW. The Protocol Configuration Options may include the Address Allocation Preference indicating that the UE prefers to obtain an IPv4 address only after the default bearer activation by means of DHCPv4.

If the UE intends to send PCO which require ciphering (e.g., PAP/CHAP usernames and passwords) or send an APN, or both, the UE shall set the Ciphered Options Transfer Flag and send PCO or APN or both only after authentication and NAS security setup have been completed (see below). If the UE has UTRAN or GERAN capabilities, it sends the NRSU in the PCO to indicate the support of the network requested bearer control in UTRAN/GERAN.

Request Type is included in the ESM message container and indicates "Handover" when the UE has already an activated PDN GW/HA due to mobility with non-3GPP accesses. Attach Type indicates whether it is an EPS attach or a combined EPS/IMSI attach or an Emergency Attach.

For an Emergency Attach the UE sets both the Attach Type and the Request Type to "Emergency" and the IMSI shall be included if the UE does not have a valid GUTI or a valid P-TMSI available. The IMEI shall be included when the UE has no IMSI, no valid GUTI and no valid P-TMSI.

UE Radio Capability Handling

The UE Radio Capability information contains information on RATs that the UE supports (e.g. power class, frequency bands, etc). Consequently, this information can be sufficiently large (e.g. >50 octets) that it is undesirable to send it across the radio interface at every transition from ECM IDLE to ECM CONNECTED. To avoid this radio overhead, the MME stores the UE Capability information during ECM IDLE state and the MME shall, if it is available, send its most up to date UE Radio Capability information to the E UTRAN in the S1 interface INITIAL CONTEXT SETUP REQUEST message unless the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" or for a "UE radio capability update".

If the UE is performing an Attach procedure or a Tracking Area Update procedure for the "first TAU following GERAN/UTRAN Attach" or for "UE radio capability update", the MME shall delete (or mark as deleted) any UE Radio Capability information that it has stored, and, if the MME sends an S1 interface INITIAL CONTEXT SETUP REQUEST message during that procedure, the MME shall not send any UE Radio Capability information to the E UTRAN in that message. This triggers the E UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION message.

If the UE is performing a Service Request (or other) procedure and the MME does not have UE Radio Capability information available (or it is available, but marked as "deleted"), then the MME sends an S1 interface INITIAL CONTEXT SETUP REQUEST message to the E UTRAN without any UE Radio Capability information in it. This triggers the E UTRAN to request the UE Radio Capability from the UE and upload it to the MME in the S1 interface UE CAPABILITY INFO INDICATION message.

NOTE 2: This use of the INITIAL CONTEXT SETUP REQUEST message means that for a signalling only procedure such as a periodic Tracking Area Update, the UE Radio Capability would not be sent to the E UTRAN.

NOTE 3: If a "first TAU following GERAN/UTRAN Attach" Tracking Area Update is performed during ECM-CONNECTED mode, e.g. after an inter RAT handover, no INITIAL CONTEXT SETUP REQUEST is sent and the UE Radio Capability information in the MME will remain deleted until the next ECM-IDLE to ECM-CONNECTED transition (or later, e.g. if the next activity from the UE is another Tracking Area Update).

The UE Radio Capability is not provided directly from one CN node to another. It will be uploaded to the MME when the E-UTRAN requests the UE Radio Capability information from the UE. During handover via the MME (both intra RAT and inter RAT), the radio capability information for the source and target 3GPP RATs (with the possible exception of UTRAN) are transferred in the "source to target transparent container". Information on additional 3GPP RATs is optionally transferred in the "source to target transparent container". Transfer of the radio capability information related to the source and/or additional RATs is beneficial as it avoids the need for the target RAT to retrieve the information from the UE prior to a subsequent inter-RAT handover.

To allow for the addition of future radio technologies, frequency bands, and other enhancements, the MME stores the UE Radio Capability Information even if it is larger than specified in TS 36.331 [37], up to a maximum size of 510 octets.

NOTE 4: The 510 octet value comes from the information element encoding rules described in TS 24.007 [45] and the assumption that the information contained within this UE Radio Capability Information Element stored by the MME is the equivalent of information signalled in two information elements in the GERAN NAS signalling for the case of GERAN to E UTRAN PS handover.

The E UTRAN stores the UE Radio Capability information, received in the S1 interface INITIAL CONTEXT SETUP REQUEST message or obtained from the UE, for the duration of the RRC connection for that UE. Before any handover attempt from E UTRAN to UTRAN, the E UTRAN retrieves the UE's UTRAN Radio Capabilities from the UE.

If the UE's non-UTRAN UE Radio Capability information changes while in ECM-IDLE state (including cases of being in GERAN/UTRAN coverage), the UE shall perform a Tracking Area Update indicating "UE radio capability update" when it next returns to E UTRAN coverage.

Functions of various CSFB architectural elements

Mobility Management Entity (for GERAN/UTRAN CSFB)
o Multiple PLMN selection and reselection for the CS domain
o Deriving a VLR number and LAI from the TAI of the current cell and based on the selected PLMN for CS domain, or using a default VLR number and LAI
o For CS fallback, generating a TAI list such that the UE has a low chance of "falling back" to a cell in a LA different to the derived LAI (e.g. the TAI list boundary should not cross the LA boundary)
o Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE
o Initiating IMSI detach at EPS detach
o Initiating paging procedure towards eNodeB when MSC pages the UE for CS services
o Supporting SMS procedures with UE and MSC via SGs
o Rejecting CS Fallback call request (e.g. due to O&M reasons)

Mobility Management Entity (for 1xRTT CSFB)
o It serves as a signaling tunneling end point towards the 3GPP2 1xCS IWS via S102 interface for sending/receiving encapsulated 3GPP2 1xCS signaling messages to/from the UE
o Handling of S102 tunnel redirection in case of MME relocation
o 1xCS-IWS (terminating S102 reference point) selection for CSFB procedures
o Buffering of messages received via S102 for UEs in idle state

E-UTRAN for GERAN/UTRAN
o Forwarding paging request and SMS to the UE
o Directing the UE to the target CS capable cell via appropriate procedure (i.e. PS handover, RRC release with redirection, CCO w/NACC)
o The configuration of appropriate cell reselection hysteresis at Location Area boundaries (or across the whole E-UTRAN) to reduce Tracking Area Update traffic
o To facilitate the configuration of TA boundaries with LA boundaries, the E-UTRAN can
gather statistics (from the inbound inter-RAT mobility events of all UEs) of the most common LAs indicated in the RRC signaling
o Configuration to permit the operator to choose the target “fallback” RAT and frequency

MSC for GERAN/UTRAN
o Maintaining SGs association towards MME for EPS/IMSI attached UE
o Supporting SMS procedures via SGs to EPS
o In order to speed up the potential LAU procedure during CS fallback the MSC may be configured to lower the frequency of Authentication, TMSI reallocation and Identity check for UEs that are EPS/IMSI attached via the SGs interface

E-UTRAN for 1xRTT
o Provision of broadcast information to trigger UE for 1xRTT CS registration
o Establish CDMA2000 tunnel between the UE and MME and forward 1xRTT messages
o Directing the UE to the target CS capable cell via appropriate procedure (i.e. RRC release with redirection or enhanced 1xCSFB procedure with 1xSRVCC based)
o Release of E-UTRAN resources after UE leaves E-UTRAN coverage subsequent to a page for CS fallback to 1xRTT CS if PS handover procedure is not performed in conjunction with 1xCS fallback
o Invoking the optimized or non-optimized PS handover procedure concurrently with enhanced 1xCS fallback procedure when supported by the network and UE, and based on network configuration.

UE supporting GERAN/UTRAN CSFB
o CSFB procedures for EPS/IMSI attach, update and detach
o CS fallback request/reject and SMS procedures for using CS domain services

UE supporting 1xRTT CSFB
o 1xRTT CS registration over the EPS after the UE has completed the E-UTRAN attachment
o 1xRTT CS re-registration due to mobility
o CS fallback request/reject and SMS procedures for using CS domain services
o Includes enhanced CS fallback to 1xRTT capability indication as part of the UE radio capabilities if it  supports enhanced 1xCSFB
o Includes concurrent 1xRTT and HRPD capability indication as part of the UE radio capabilities if supported by the enhanced CS fallback to 1xRTT capable UE

Circuit Switched Fallback (CSFB)

CS domain services are the services that can be offered today in GSM-UMTS networks. Examples of such services are: voice and its supplementary services (e.g. call waiting, call forwarding), USSD, LCS, SMS, E911, LI, and even CS DUI video, etc. This rich set of CS domain features and capabilities are the result of years of standardization works in 3GPP and operators investments to their GSM-UMTS network.

In EPS, richer features/services can be offered to the end-user together with voice via IMS. While this is the case for EPS, it is challenging for some operators to launch EPS with data and voice/IMS from day one. Hence, these operators need a migration path to allow them to start from EPS with data only and allow the reuse of CS domain services until they get to the point where IMS voice can be added to the EPS.

Such migration path is possible with CS Fallback (CSFB) feature. CSFB is introduced in 3GPP Rel-8 to allow an UE in EPS to reuse CS domain services by defining how the UE can switch its radio from EUTRAN access to other RAT (e.g. GERAN/UTRAN/1xRTT access) that can support CS domain services. In addition, CSFB specification TS 23.272 also defines how the SMS is transferred to the UE natively via EPS from the MSC. It should be noted that this type of SMS delivery mechanism is defined in CSFB specification but the UE is not falling back to GERAN/UTRAN/1xRTT access.

With CSFB, UE under EPS can enjoy the fast PS data access and can switch over to GERAN/UTRAN/1xRTT access for CS domain services when needed. In addition, UE can also utilize the SMS feature supported by CSFB architecture.

UE, which wants to use CSFB, must first register itself to the CS domain via EPS. For GSM-UMTS CSFB feature, UE performs a combined EPS/IMSI Attach/TAU procedure. In the EPS Attach/TAU response message, the network indicates back to the UE whether CSFB (including SMS) is supported, “SMS-only”, “CSFB Not Preferred”, or none of these features are supported. “CSFB Not Preferred” is an indication to allow data centric devices to continue reside in EPS and to allow CSFB (including SMS) features to be used. On the other hand, a voice centric device receiving “CSFB Not Preferred” or “SMS-only” will assume CSFB is not supported in this network and will try to reselect to other networks (i.e. 2G or 3G) to obtain voice services. In 1xRTT CSFB features, the UE is aware that the network supports 1xCSFB by examining the system information broadcast information over E-UTRAN access and performs the 1xCS registration to the 1xRTT MSC via the CDMA2000 signaling tunnel between the UE (via EPS) and 1xCS IWS. This 1xCS registration request and response is transparent to the EPS.

After the UE has successfully registered itself to the CS domain (and has received positive response from MME that CSFB is possible in GERAN/UTRAN case), it can then request the MME to perform CSFB procedures whenever it wants to use CS domain services (e.g. originating a voice call or answer to a terminating voice call). Besides voice call, USSD, MO-LR, MT-LR, NI-LR, and call-independent Supplementary Services procedures (e.g. activates CFB) can also trigger CSFB procedures. In the CS terminating scenario, an active UE has the ability to reject terminating call request while it still resides in EPS. This is particularly useful when the end-user is watching a streaming video under EPS and does not want to answer a call from an unknown number to avoid any streaming disruption in the streaming video due to unwanted CSFB procedures.

For the GSM-UMTS CSFB feature, EPS can perform the CSFB procedure with PS handover procedure, RRC connection release with redirection information, or cell change order with NACC (for GERAN only). This is based on network configuration and deployment option. For 1xRTT CSFB feature, CSFB can be done with RRC connection release with redirection information or 1xSRVCC based signaling (known as enhanced 1xCSFB). 1xRTT CSFB UE may also have dual-Rx/dual-Tx or Dual-Rx/Single-Tx capability. Dual-Rx/dual-Tx 1xRTT CSFB UE can simultaneously transmit and receive on both EPS and 1x at the same time. This allows the UE to obtain 1x voice service from 1xRTT system while maintaining the data stream over EPS at the same time. This is also based on network configuration and deployment option, and UE capability. Dual-Rx/Single-Tx 1xRTT CSFB UE allows simplification in EPS network deployment because there is no coordination is required between the E UTRAN and 1xRTT network (i.e. S102 is not required).

After the UE is redirected to GERAN/UTRAN/1xRTT access via one of the above procedures, the existing CS setup procedure is taken over for the remaining of the call.

In Rel-9, IDLE mode camping mechanism is enhanced in the EPS and GPRS to allow the network to influence the UE’s RAT camping policy so that a CSFB UE will select GERAN/UTRAN access when it is in IDLE condition. The intention is to minimize the occurrence of CSFB procedure from EPS to allow the UE to invoke the CS domain services directly from GERAN/UTRAN as much as possible. On the other hand, this requires additional intelligence in the cell reselection policy in the GERAN/UTRAN access in order to move the UE in active state to EPS to enjoy the fast PS access when appropriate. There are also optimization enhancements to Rel-9 for speeding up the overall CSFB procedure.

As indicated earlier, SMS delivery via CS Domain is also defined as part of the CSFB feature. UE can utilize this feature after it has successfully attached itself to the CS domain. It should be noted that EPS has the option to support only the SMS feature and not the CSFB feature which redirect the UE to another RAT. For GERAN/UTRAN CSFB, MME can indicate this condition by having an SMS-only indicator to the UE during their combined EPS/IMSI Attach/TAU procedure. For 1xRTT CSFB, this indication is not specified, as the 1xCS registration procedure is transparent to the EPS. UE receiving the “SMS-only” indicator will not invoke the CSFB request and should not expect any CS paging coming from EPS.

When interworking with a 3GPP MSC, SMS is delivered via the SGs interface. For MO-SMS, UE first establishes a NAS tunnel to transfer the SMS PDU to MME. MME then transfer these SMS PDU over to MSC via the SGs. MT-SMS works the same way by having the MME establish a NAS tunnel to UE over E-UTRAN access.

When interworking with 1xMSC, the UE establishes a CDMA2000 tunnel with the 1xCS IWS via EPS and SMS is delivered via that tunnel. EPS is transparent to this process.

3GPP also defines the CSFB UE in voice-centric and data-centric mode of operation in TS 23.221. Voicecentric CSFB UE will always attempt to find a RAT where voice services can be supported. In the example of UE receiving an SMS-only or “CSFB Not Preferred” indication from the network during combined EPS/IMSI attach procedure, the voice-centric UE will autonomously switch to UTRAN/GERAN access if coverage is available so voice service is possible to this user. With a data-centric mode of operation, the CSFB UE will not switch to UTRAN/GERAN given the same scenario with the SMS-only indication from the network and will forgo the voice services or CS domain services altogether. This is because the data-centric mode UE wants the best possible PS access and voice is not the determining factor to move away from EPS.

Article from "4G Broadband Evolution: 3GPP Release 10 and beyond"

UE Positioning In LTE

UE positioning is an access network function (e.g. GERAN, UTRAN, E-UTRAN). An access network may support one or more UE positioning methods, which may be same or different from another access network. In E-UTRAN the following UE positioning methods are supported:

•  Cell ID positioning method
•  Enhanced Cell ID based positioning method
•  OTDOA positioning method
•  Network assisted GNSS (A-GNSS) positioning methods

Determining the position of a UE involves two main steps:

1. Radio signal measurements
2. Position estimate computation and optional velocity computation based on the measurements

The signal measurements may be made by the UE or the E-UTRAN. Both TDD and FDD radio interface will be supported in E-UTRAN. The basic signals measured for terrestrial position methods are typically the E-UTRA radio transmissions. Also other transmissions such as general radio navigation signals including those from Global Navigation Satellites Systems can also be measured. The position estimate computation may be made in the UE or in the E-SMLC. In UE-assisted positioning the UE perform the downlink radio measurements and the E-SMLC estimates the UE position while in UE-based positioning the UE performs both the downlink radio measurements and also the position estimation. The UE may require some assistance from the network in the form of assistance data in order to perform the downlink measurements and these are provided by the network either autonomously or upon UE requesting it.

The E-UTRAN positioning capabilities are intended to be forward compatible to other access types and other position methods, in an effort to reduce the amount of additional positioning support needed in the future.

CELL ID METHOD

This is the simplest of all positioning methods but the UE position is very coarse in that only the serving cell where the UE is located is provided. As E-UTRAN and MME are involved in the mobility management (e.g. tracking area update or paging) of UEs the serving base station and serving cell of the UE is always known especially when there is signaling between the E-SMLC and the UE to query the UE position.

ENHANCED CELL ID‐BASED METHOD

In this method the position obtained by the Cell ID method is enhanced through means of use of other UE or E-UTRAN measurements to estimate the UE position with better accuracy than the Cell ID method. The measurements used may be radio resource measurements or other measurements. The E-SMLC does not configure these measurements in the UE/E-UTRAN but only queries the UE/E-UTRAN for these measurements and obtains them if available in the UE/E-UTRAN.

NETWORK ASSISTED GNSS METHODS

In network assisted GNSS methods the network provides various assistance data to the UE that are equipped with radio receivers capable of receiving GNSS signals. The UEs use the assistance data provided by the network to help perform measurements. Examples of GNSS include: GPS, Modernized GPS, Galileo, GLONASS, Space Based Augmentation Systems (SBAS) and Quasi Zenith Satellite System (QZSS). Different GNSS can be used separately or in combination to determine the position of a UE. 

OTDOA METHOD

The OTDOA method is a downlink terrestrial positioning method. In this method the UE performs measurements of downlink signals of neighbor E-UTRAN cells. This is a good backup method for positioning the UE when satellite signals are not strong enough (e.g. indoors or bad atmospheric conditions etc). The UE receives the downlink radio transmission of four or more neighbor cells, aided by downlink reference signal transmissions from those cells and measures the time difference of arrival of the radio frames of the measured neighbor cells relative to the serving cell. These UE measurements are then used either by the UE or by the E-SMLC to estimate the UE position using a trilateration technique.

The E-UTRAN may combine two or more of the supported UE positioning methods and perform a hybrid positioning estimation to achieve a better positioning accuracy.

The UE positioning protocol is an end-to-end protocol with terminations in the UE and the E-SMLC(Enhanced Serving Mobile Location Center). This protocol is called the LTE Positioning Protocol (LPP). This is a transaction-oriented protocol with exchange of LPP messages between UE and E-SMLC where one or more messages realize each transaction. A transaction results in one activity or operation such as assistance data transfer, UE positioning capability transfer or position measurement/estimate exchange. There is a second UE positioning protocol, LPPa, with terminations in the E-UTRAN and E-SMLC that allows the exchange of information and measurements, which are useful for some specific positioning methods. Currently, the LPPa is used for the delivery of timing information that is resident only to the E-UTRAN and/or is semidynamically changing, which is required for the OTDOA positioning method. Apart from this the LPPa also supports the exchange of E-UTRAN assisted measurements that are used for the Enhanced Cell ID positioning method.

What is Evolved Packet Core ( EPC )

Evolved Packet Core (EPC) is the IP-based core network defined by 3GPP in Rel-8 for use by LTE and other access technologies. The goal of EPC is to provide simplified all-IP core network architecture to efficiently give access to various services such as the ones provided in IMS.

EPC consists essentially of a Mobility Management Entity (MME), a Serving Gateway (S-GW) that interfaces with the E-UTRAN and a PDN Gateway (P-GW) that interfaces to external packet data networks. EPC for LTE networks were announced by numerous vendors beginning in February 2009, allowing operators to modernize their core data networks to support a wide variety of access types using a common core network.

EPC solutions typically include backhaul, network management solutions, video solutions that monetize LTE investment and a complete portfolio of professional services.

4G Mobile Broadband Evolution: 3GPP Release-10 and Beyond

View more documents from Zahid Ghadialy.

LTE – the Future of IMS

View more presentations from RADVISION Ltd..

LTE - Long Term Evolution - Presentation

View more presentations from Arief Gunawan.

LTE Femtocell Roadmap- From Concept to Reality

View more presentations from Continuous Computing.

3GPP LTE-MAC

View more presentations from praveenkmr78.

RAT/Frequency Selection Priority Index - RFSP Index

Radio resource management functions are concerned with the allocation and maintenance of radio communication paths, and are performed by the radio access network. The RRM strategy in E-UTRAN may be based on user specific information.

To support radio resource management in E-UTRAN the MME provides the parameter 'Index to RAT/Frequency Selection Priority' (RFSP Index) to an eNodeB across S1. The RFSP Index is mapped by the eNodeB to locally defined configuration in order to apply specific RRM strategies. The RFSP Index is UE specific and applies to all the Radio Bearers.

Examples of how this parameter may be used by the E-UTRAN:
- to derive UE specific cell reselection priorities to control idle mode camping.
- to decide on redirecting active mode UEs to different frequency layers or RATs.
The MME receives the subscribed RFSP Index from the HSS (e.g., during the Attach procedure). For non-roaming subscribers the MME chooses the RFSP Index in use according to one of the following procedures, depending on operator's configuration:
- the RFSP Index in use is identical to the subscribed RFSP Index, or
- the MME chooses the RFSP Index in use based on the subscribed RFSP Index, the locally configured operator's policies and the UE related context information available at the MME, including UE's usage setting and voice domain preference for E-UTRAN, if received during Attach and Tracking Area Update procedures.

One example of how the MME can use the "UE voice capabilities and settings" is to select an RFSP value that enforces idle mode camping on 2G/3G for a UE acting in a "Voice centric" way and provisioned with "CS Voice preferred, IMS Voice as secondary", in order to minimize the occurrancy of RAT changes. Another example is the selection of an RFSP value that prevents idle mode camping on 2G for a UE provisioned with "IMS PS voice preferred, CS Voice as secondary" if other RATs supporting IMS Voice are available, as the UE would in such case always select the CS domain for its voice calls.

For roaming subscribers the MME may alternatively choose the RFSP Index in use based on the visited network policy, but can take input from the HPLMN into account (e.g., an RFSP Index value pre-configured per HPLMN, or a single RFSP Index value to be used for all roamers independent of the HPLMN).

The MME forwards the RFSP Index in use to the eNodeB across S1. The RFSP Index in use is also forwarded from source eNodeB to target eNodeB when X2 is used for intra-E UTRAN handover.

The MME stores the subscribed RFSP Index value received from the HSS and the RFSP Index value in use. During the Tracking Area Update procedure, the MME may update the RFSP Index value in use (e.g. the MME may need to update the RFSP Index value in use if the UE related context information in the MME has changed). When the RFSP Index value in use is changed, the MME immediately provides the updated RFSP Index value in use to eNodeB by modifying an existing UE context or by establishing an new UE context in the eNodeB. During inter-MME mobility procedures, the source MME forwards both RFSP Index values to the target MME. The target MME may replace the received RFSP Index value in use with a new RFSP Index value in use that is based on the operator's policies and the UE related context information available at the target MME.

The S1 messages that transfer the RFSP Index to the eNodeB are specified in TS 36.413 [36].