Friday, November 27, 2009

LTE User Plane - Protocol Stacks

UE - P GW user plane with E-UTRAN

- GPRS Tunnelling Protocol for the user plane (GTP U): This protocol tunnels user data between eNodeB and the S GW as well as between the S GW and the P GW in the backbone network. GTP shall encapsulate all end user IP packets.
- MME controls the user plane tunnel establishment and establishes User Plane Bearers between eNodeB and S GW.
- UDP/IP: These are the backbone network protocols used for routeing user data and control signalling.
- LTE-Uu: The radio protocols of E-UTRAN between the UE and the eNodeB are specified in TS 36.300 [5].

eNodeB - S GW

UE - PDN GW user plane with 2G access via the S4 interface

UE - PDN GW user plane with 3G access via the S12 interface

UE - PDN GW user plane with 3G access via the S4 interface

Tuesday, November 24, 2009

LTE Control Plane - Protocol Stacks

eNodeB - MME

- S1 Application Protocol (S1-AP): Application Layer Protocol between the eNodeB and the MME.
- SCTP for the control plane (SCTP): This protocol guarantees delivery of signalling messages between MME and eNodeB (S1). SCTP is defined in RFC 2960 [35].


- NAS: The NAS protocol supports mobility management functionality and user plane bearer activation, modification and deactivation. It is also responsible of ciphering and integrity protection of NAS signalling.
- LTE-Uu: The radio protocol of E-UTRAN between the UE and the eNodeB is specified in TS 36.300 [5].

- GPRS Tunnelling Protocol for the control plane (GTP C): This protocol tunnels signalling messages between SGSN and MME (S3).
- User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in RFC 768 [26].


- GPRS Tunnelling Protocol for the control plane (GTP C): This protocol tunnels signalling messages between SGSN and S GW (S4).
- User Datagram Protocol (UDP): This protocol transfers signalling messages. UDP is defined in RFC 768 [26].





- Diameter: This protocol supports transferring of subscription and authentication data for authenticating/authorizing user access to the evolved system between MME and HSS (S6a). Diameter is defined in RFC 3588 [31].
- Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is defined in RFC 2960 [35].


- Diameter: This protocol supports UE identity check procedure between MME and EIR (S13). Diameter is defined in RFC 3588 [31].
- Stream Control Transmission Protocol (SCTP): This protocol transfers signalling messages. SCTP is defined in RFC 2960 [35].

Friday, November 20, 2009

Knowing GUTI - Globally Unique Temporary ID

In LTE the GUTI is allocated to the UE by the MME and has two components. These are the GUMMEI (Globally Unique MME ID) and the M-TMSI (MME-TMSI). While the GUMMEI identifies the MME, the M-TMSI identifies the UE within the MME.

In GPRS and UMTS the mobile's temporary id was the (P-TMSI) Packet Temporary Mobile Identity. This id is changed on a frequent basis and used instead of the IMSI (The International Mobile Subscriber Identification) in most air interface messages for security reasons.

In LTE, the P-TMSI is now called the Globally Unique Temporary ID, or the GUTI. Some of the digits in the GUTI identify the Mobility Management Entity the mobile was last registered with and they are referred to as the Globally Unique MME Identifier, or the GUMMEI.

When contacting the network, the mobile sends the GUTI to the base station which then uses the parameter to identify the MME to which it will send the request to re-establish the communication session.It's also possible to roam between different radio technologies. If the mobile has reselected from a UMTS cell to an LTE cell, a TAU is made and since the mobile does not have a GUTI, the P-TMSI is sent instead.This way, the newly assigned MME can contact the 3G SGSN to request the subscribers current profile (IP address, PDP contexts, etc.).

The same mechanisms apply when the mobile reselects from an LTE cell to a UMTS or GPRS cell. In this case the GUTI is sent in the P-TMSI parameter and the procedure is reffered to as Routeing Area Update (RAU) instead of TAU.

The GUTI has two main components:
  • one that uniquely identifies the MME which allocated the GUTI; and
  • one that uniquely identifies the UE within the MME that allocated the GUTI.
The Globally Unique MME Identifier (GUMMEI) is constructed from the MCC, MNC and MME Identifier (MMEI). Within the MME, the mobile is identified by the M-TMSI.

Finally the GUTI is constructed from the GUMMEI and the M-TMSI.

Monday, November 16, 2009

Dispelling LTE Myths

At the recent Leadership meeting of 3GPP, the Technical Specification Group Chairmen sat down to discuss some of theMyths that surround LTE’s roll-out.
Is LTE Data Only? ...Does it support SMS? ...Is IMS a success? ...Can LTE complete emergency calls?
Here are the answers:

Myth 1: LTE is Data only

Reality: LTE supports voice and efficient support of voice was one of the key considerations in designing LTE. The voice solution for LTE is IMS VoIP and it is fully specified.

The 3GPP solution for voice over LTE is a combination of multiple efforts:
  • The work in Rel 7 to optimize IMS signalling and VoIP encoding so it would be as good or better than CS voice in terms of quality and efficiency,
  • The work in Rel 8 to develop a radio and core network evolution optimized for the transfer of packet data.
  • The work in Rel-7 to add the IMS emergency call requirements and to adapt it to regulatory requirements in LTE and GPRS in Rel-9.
  • The work in Rel-8 to add the always-on IP connectivity requirements in LTE
A key consideration to recognize is that under LTE, voice is just one of many potential media streams that can be communicated. A packet based network and VoIP allows this flexibility while still providing efficient use of radio and network resources.

However, 3GPP recognizes that adoption of both LTE and IMS will not occur overnight For this reason 3GPP provided a transition solution for voice called CS Fallback. This allows a LTE device to drop back to the legacy 3G or 2G network if IMS VoIP capabilities are not supported. This is viewed as an interim solution to ease the transition to IMS and VoIP.

Myth 2: SMS isn’t supported over LTE

Reality: LTE and EPS will support a rich variety of messaging applications and also SMS is supported over LTE. The solution is twofold, covering both the full IMS case and a transition solution for those networks that do not support IMS.

SMS over IP was fully specified 3GPP Rel 7. It depends on IMS and it is intended to provide compatibility between the existing cellular legacy and the implementations with more elaborate messaging capabilities via SMS and IMS interworking..

For environments without IMS a transition solution was specified. This is called SMS over SGs (previously called the misleading name: SMS over CS). It is a hybrid approach that allows the transmission of native SMS from CS infrastructure over the LTE radio network. SMS over SGs was specified as part of Rel 8. SMS over SGs provides SMS service for mobiles in LTE and since it requires also CS domain infrastructure for the SMS transmission, it is intended to be a transition solution.

Myth 3: IMS isn’t ready for prime time

Reality: IMS has been around a long time. It was first developed as part of Rel 5 in 2002. It is based on IETF protocols such as SIP and SDP that are very mature. These technologies have been embraced by the industry as the signalling mechanism for multimedia applications.

In Rel 7 an effort was made to optimize IMS and the supporting protocols to ensure that voice and other media were supported as efficiently as in circuit switched networks.

IMS is fully specified and mature. The difficulties in rolling out IMS are not due to the protocols or the specifications. The consideration point is not only technical aspects but also shifting the whole industry paradigm from CS services to a truly IP-based environment, i.e. service migration, policies, interoperability and deployment plan included. However, these complexities must be addressed if the idea is to truly provide a richer service environment. This work is ongoing in many forums outside of 3GPP (e.g. Rich Communication Suite).

Myth 4: LTE doesn’t support emergency calls

Reality: VoIP support for emergency calls (including location support) is specified as part of Rel 9. This fulfils the last regulatory requirement separating VoIP from CS in 3GPP networks. A transition solution exists which is falling back to 3G/2G for completing emergency calls. This solution has existed since IMS was introduced (Rel 5).

However, to satisfy the situation of a fallback network not existing, this enhancement was completed in Rel 9. This allows the operator the option of supporting the regulatory requirements for LTE VoIP calls both for phones that can register for normal services and for those in limited service, including the USIM-less case.

Also the emergency call callback from the PSAP and its interaction with the possibly activated supplementary services is specified.

Legacy Service
Transition Solution
EPS Solution
CS Voice
CS Fallback (Rel 8)
IMS VoIP (Rel 7)
SMS over SGs (used to be called SMS over CS) (Rel 8)
SMS over IP (Rel 7)
Supplementary Services
CS Fallback (Rel 8)
Multimedia Telephony (Rel 7)
Emergency Calls w Location Support
CS Emergency Calls (Rel 5)
IMS Emergency Calls w Location Support (Rel 9)

Sunday, November 15, 2009

What is Inter RAT HO ?

1. Inter RAT HO is network controlled through source access system. The source access system decides about starting the preparation and provides the necessary information to the target system in the format required by the target system. That is, the source system adapts to the target system. The actual handover execution is decided in the source system.

2. Inter RAT HO is backwards handover, i.e. radio resources are prepared in the target 3GPP access system before the UE is commanded by the source 3GPP access system to change to the target 3GPP access system.

3. To enable backwards handover, and while RAN level interfaces are not available, a control interface exists in CN level. In Inter RAT HO involving E-UTRAN access, this interface is between 2G/3G SGSN and corresponding MME/Serving Gateway.

4. The target access system will be responsible for giving exact guidance for the UE on how to make the radio access there (this includes radio resource configuration, target cell system information etc.). This information is given during the handover preparation and should be transported completely transparently through the source access system to the UE.

5. Mechanisms for avoiding or mitigating the loss of user data (i.e. forwarding) can be used until the 3GPP Anchor determines that it can send DL U-plane data directly to the target system.

6. The handover procedure should not require any UE to CN signalling in order for data to start to flow in the target system. This requires that the security context, UE capability context and QoS context is transferred (or translated) within the network between source and target system.

7. Similar handover procedure should apply for handovers of both real time and non-real time services.

8. Similar handover procedure should apply for both Inter RAT Handover and intra-LTE Handover with EPC node change.

9. Network controlled mobility is supported even if no prior UE measurements have been performed on the target cell and/or frequency i.e. “blind HO” is supported.

Thursday, November 12, 2009

U-Plane Handling During HO

The U-plane handling during the Intra-E-UTRAN-Access mobility activity for UEs in ECM-CONNECTED takes place to avoid data loss during HO.
  • During HO preparation U-plane tunnels are established between the source eNB and the target eNB. There is one tunnel established for uplink data forwarding and another one for downlink data forwarding for each E-RAB for which data forwarding is applied.
  • During HO execution, user data is forwarded from the source eNB to the target eNB.
    • Forwarding of downlink user data from the source to the target eNB should take place in order as long as packets are received at the source eNB from the EPC or the source eNB buffer has not been emptied.
  • During HO completion:
    • The target eNB sends a PATH SWITCH message to MME to inform that the UE has gained access and MME sends a USER PLANE UPDATE REQUEST message to the Serving Gateway, the U-plane path is switched by the Serving Gateway from the source eNB to the target eNB.
    • The source eNB should continue forwarding of U-plane data as long as packets are received at the source eNB from the Serving Gateway or the source eNB buffer has not been emptied.

Path Switch

After the downlink path is switched at the Serving GW downlink packets on the forwarding path and on the new direct path may arrive interchanged at the target eNB. The target eNodeB should first deliver all forwarded packets to the UE before delivering any of the packets received on the new direct path. The method employed in the target eNB to enforce the correct delivery order of packets is outside the scope of the standard.

In order to assist the reordering function in the target eNB, the Serving GW shall send one or more "end marker" packets on the old path immediately after switching the path for each E-RAB of the UE. The "end marker" packet shall not contain user data. The "end marker" is indicated in the GTP header. After completing the sending of the tagged packets the GW shall not send any further user data packets via the old path.

Upon receiving the "end marker" packets, the source eNB shall, if forwarding is activated for that bearer, forward the packet toward the target eNB.

On detection of an "end marker" the target eNB shall discard the end marker packet and initiate any necessary processing to maintain in sequence delivery of user data forwarded over X2 interface and user data received from the serving GW over S1 as a result of the path switch.

On detection of the "end marker", the target eNB may also initiate the release of the data forwarding resource. However, the release of the data forwarding resource is implementation dependent and could also be based on other mechanisms (e.g. timer-based mechanism).

EPC may change the uplink end-point of the tunnels with Path Switch procedure. However, the EPC should keep the old GTP tunnel end-point(s) sufficiently long time in order to minimise the probability of packet losses and avoid unintentional release of respective E-RAB(s).

Wednesday, November 11, 2009

Idle Mode Signaling Reduction - ISR

Idle mode signalling reduction is a feature that allows the UE to roam between LTE & 2G/3G. Basically it aims at reducing the frequency of TAU and RAU procedures caused by UEs reselecting between E-UTRAN and GERAN/UTRAN which are operated together. Especially it not only reduces the signalling between UE and network, but also reduces the singalling between E-UTRAN & UTRAN/GERAN.

The dependancy between 2G/3G and EPC is minimized at the cost of ISE-specific node and interface functionality. The idea behind ISR feature is that UE can be registered in UTRAN/GERAN RA at the same time it is registered in  an E-UTRAN TA or list of TAs. The UE keeps the two registrations in parallel and run periodic timers for both registrations independently. Simillarly UE keeps the two registrations the two registrations in parallel and it also ensures that UE can be paged in both the RA and the TAs it is registered in.

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, Serving GW and HSS) to activate ISR for a UE. The network can decide for ISR activation individually for each UE. Gn/Gp SGSNs do not support ISR functionality.

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.

Implicit detach by one CN node (either SGSN or MME) deactivates ISR in the network. ISR is deactivated in the UE when the UE cannot perform periodic updates in time.

Tuesday, November 10, 2009

Architecture for Optimized Handovers between E-UTRAN Access and cdma2000 HRPD Access

S101 Interface

It enables interactions between EPS and HRPD access to allow for pre-registration and handover signalling with the target system.

The S101 interface supports procedures for Pre-Registration, Session Maintenance and Active handovers between E-UTRAN and HRPD networks. This is based on tunnelling over S101 signalling of one technology while the UE is in the other technology. The HRPD air interface messages tunnelled over S101 in E‑UTRAN to HRPD mobility

S101 Protocol Stack

S103 Interface

This User Plane interface is used to forward DL data to minimize packet losses in mobility from E-UTRAN to HRPD.

The S103 interface between the Serving GW and HS‑GW supports the forwarding of DL data during mobility from E-UTRAN to HRPD. Signalling procedures on the S101 interface are used to set up tunnels on the S103 interface.

The S103 supports the following requirements:
  • The ability to tunnel traffic on a per-UE, per-PDN basis
  • Generic Routing Encapsulation (GRE) RFC 2784 [23] including the Key Field extension RFC 2890 [24]. The Key field value of each GRE packet header uniquely identifies the PDN connectivity that the GRE packet payload is associated with.

 S103 Protocol Stack

Monday, November 9, 2009

Functional Split between E-UTRAN and EPC

P-GW Function

The PDN Gateway (P-GW) hosts the following functions (see 3GPP TS 23.401 [17]):
  • Per-user based packet filtering (by e.g. deep packet inspection);
  • Lawful Interception;
  • UE IP address allocation;
  • Transport level packet marking in the downlink;
  • UL and DL service level charging, gating and rate enforcement;
  • DL rate enforcement based on APN-AMBR;

Friday, November 6, 2009

S-GW Functions

The Serving Gateway (S-GW) hosts the following functions (see 3GPP TS 23.401 [17])
  • The local Mobility Anchor point for inter-eNB handover;
  • Mobility anchoring for inter-3GPP mobility;
  • E-UTRAN idle mode downlink packet buffering and initiation of network triggered service request procedure;
  • Lawful Interception;
  • Packet routeing and forwarding;
  • Transport level packet marking in the uplink and the downlink;
  • Accounting on user and QCI granularity for inter-operator charging;
  • UL and DL charging per UE, PDN, and QCI.

Thursday, November 5, 2009

The MME Function

  • NAS signalling;
  • NAS signalling security;
  • AS Security control;
  • Inter CN node signalling for mobility between 3GPP access networks;
  • Idle mode UE Reachability (including control and execution of paging retransmission);
  • Tracking Area list management (for UE in idle and active mode);
  • PDN GW and Serving GW selection;
  • MME selection for handovers with MME change;
  • SGSN selection for handovers to 2G or 3G 3GPP access networks;
  • Roaming;
  • Authentication;
  • Bearer management functions including dedicated bearer establishment;
  • Support for PWS (which includes ETWS and CMAS) message transmission.


Tuesday, November 3, 2009

eNB Functionalities

  • 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).