QoS Concept in LTE

An EPS bearer/E-RAB is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. That is, SDFs mapped to the same EPS bearer receive the same bearer level packet forwarding treatment (e.g. scheduling policy, queue management policy, rate shaping policy, RLC configuration, etc.).

One EPS bearer/E-RAB is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the default bearer. Any additional EPS bearer/E-RAB that is established to the same PDN is referred to as a dedicated bearer. The initial bearer level QoS parameter values of the default bearer are assigned by the network, based on subscription data. The decision to establish or modify a dedicated bearer can only be taken by the EPC, and the bearer level QoS parameter values are always assigned by the EPC.

An EPS bearer/E-RAB is referred to as a GBR bearer if dedicated network resources related to a Guaranteed Bit Rate (GBR) value that is associated with the EPS bearer/E-RAB are permanently allocated (e.g. by an admission control function in the eNodeB) at bearer establishment/modification. Otherwise, an EPS bearer/E-RAB is referred to as a Non-GBR bearer. A dedicated bearer can either be a GBR or a Non-GBR bearer while a default bearer shall be a Non-GBR bearer.

QoS parameters

The bearer level (i.e. per bearer or per bearer aggregate) QoS parameters are QCI, ARP, GBR, and AMBR. Each EPS bearer/E-RAB (GBR and Non-GBR) is associated with the following bearer level QoS parameters:

- QoS Class Identifier (QCI): scalar that is used as a reference to access node-specific parameters that control bearer level packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.), and that have been pre-configured by the operator owning the eNodeB.

- Allocation and Retention Priority (ARP): the primary purpose of ARP is to decide whether a bearer establishment / modification request can be accepted or needs to be rejected in case of resource limitations. In addition, the ARP can be used by the eNodeB to decide which bearer(s) to drop during exceptional resource limitations (e.g. at handover).

Each GBR bearer is additionally associated with the following bearer level QoS parameter:

- Guaranteed Bit Rate (GBR): the bit rate that can be expected to be provided by a GBR bearer,

Each APN access, by a UE, is associated with the following QoS parameter:

- per APN Aggregate Maximum Bit Rate (APN-AMBR).

Each UE in state EMM-REGISTERED is associated with the following bearer aggregate level QoS parameter:

- per UE Aggregate Maximum Bit Rate (UE-AMBR).

The GBR denotes bit rate of traffic per bearer while UE-AMBR/APN-AMBR denote bit rate of traffic per group of bearers. Each of those QoS parameters has an uplink and a downlink component.

Few Questions on Bearer

What is the EPS Bearer?

For E-UTRAN access to the EPC the PDN connectivity service is provided by an EPS bearer for GTP-based S5/S8, and by an EPS bearer concatenated with IP connectivity between Serving GW and PDN GW for PMIP-based S5/S8.

An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment between a UE and a PDN GW for GTP-based S5/S8, and between UE and Serving GW for PMIP-based S5/S8.

EPS Bearer is a virutal connection between UE and PGW which identifies a data send and received between these two end points with specific QoS attributes.

The procedure used to establish an EPS Bearer is called “EPS Bearer Activation” procedure. Either endpoint can trigger this procedure. For example, the PDN-GW may trigger this procedure when it determines that a new VoIP call is requested and a new EPS Bearer should be established to support this call.

What is Default Bearer and Dedicated Bearer?

Default Bearer

One EPS bearer is established when the UE connects to a PDN, and that remains established throughout the lifetime of the PDN connection to provide the UE with always-on IP connectivity to that PDN. That bearer is referred to as the default bearer.

Dedicated Bearer

Any additional EPS bearer that is established for the same PDN connection is referred to as a dedicated bearer.

Are default bearers created on a per UE or a per PDN (Packet Data Network) basis?

Default bearers are created on a per PDN basis. So if a UE is connecting to two PDNs it will need to establish two default bearers. The first default bearer will be established during the Attach process when the UE first powers up and the second will be done using Activate default EPS bearer context request procedure. When the second default bearer is established it will be dependent on the service and the UE.

LTE Bearer Service Architecture

- An E-RAB transports the packets of an EPS bearer between the UE and the EPC. When an E-RAB exists, there is a one-to-one mapping between this E-RAB and an EPS bearer.

- A data radio bearer transports the packets of an EPS bearer between a UE and an eNB. When a data radio bearer exists, there is a one-to-one mapping between this data radio bearer and the EPS bearer/E-RAB.

- An S1 bearer transports the packets of an E-RAB between an eNodeB and a Serving GW.

- An S5/S8 bearer transports the packets of an EPS bearer between a Serving GW and a PDN GW.

- A UE stores a mapping between an uplink packet filter and a data radio bearer to create the binding between an SDF and a data radio bearer in the uplink.

- An UL TFT in the UE binds an SDF to an EPS bearer in the uplink direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple uplink packet filters in the UL TFT.

- A DL TFT in the PDN GW binds an SDF to an EPS bearer in the downlink direction. Multiple SDFs can be multiplexed onto the same EPS bearer by including multiple downlink packet filters in the DL TFT.

- A PDN GW stores a mapping between a downlink packet filter and an S5/S8a bearer to create the binding between an SDF and an S5/S8a bearer in the downlink.

- An eNB stores a one-to-one mapping between a data radio bearer and an S1 bearer to create the binding between a data radio bearer and an S1 bearer in both the uplink and downlink.

- A Serving GW stores a one-to-one mapping between an S1 bearer and an S5/S8a bearer to create the binding between an S1 bearer and an S5/S8a bearer in both the uplink and downlink.

Dedicated bearer activation in combination with the default bearer activation

Dedicated bearer activation in combination with the default bearer activation at attach or UE requested PDN connectivity

It is possible for the PDN GW to initiate the activation of dedicated bearers as part of the attach procedure or as part of the UE requested PDN connectivity procedure over E UTRAN. However, the result of the dedicated bearer activation procedure is separate from the Attach procedure, meaning that the result of the Attach procedure is not dependent on whether the Dedicated bearer activation procedure succeeds or not. On the other hand, the dedicated bearer activation may only be regarded as successful if the Attach procedure completes successfully.

The messages of the Dedicated bearer activation can be sent together with the messages of the Attach procedure or of the UE requested PDN connectivity procedure (i.e. Attach accept or PDN Connectivity Accept).

If the MME has sent an Attach Accept message towards the eNodeB, and then the MME receives a Create Bearer Request before the MME receives the Attach Complete message, the MME shall wait for the Attach procedure to complete before the MME continues with Dedicated Bearer Activation procedure.

It is possible that multiple dedicated bearers can simultaneously be activated in the signalling flow shown below.

Figure describes the activation of dedicated bearer(s) in combination with the default bearer activation either as part of the Attach procedure (with specific steps 1a, 7a, 10a) or as part of the UE requested PDN connectivity procedure (with specific steps 1b, 7b, 10b).

5. (On the P‑GW-S‑GW interface) Create Session Response message of the Attach procedure or UE‑requested PDN connectivity procedure is combined with Create Bearer Request message of the Dedicated Bearer Activation Procedure

6.(On the S‑GW-MME interface) Create Session Response message of the Attach procedure or UE‑requested PDN connectivity procedure is combined with the Create Bearer Request message of the Dedicated Bearer Activation Procedure

7a. For Attach procedure: If the MME receives a Create Session Response message combined with a Create Bearer Request message, the MME shall send the S1-AP Initial Context Setup Request message to the eNodeB, including the NAS parts for both the Attach Accept message of the Attach procedure and the Bearer Setup Request of the Dedicated Bearer Activation Procedure.

NOTE: The MME shall not send a Bearer Setup Request message of a new Dedicated Bearer Activation procedure to the eNodeB before sending the Attach Accept message of the Attach procedure to the eNodeB. If the MME has already sent the Attach Accept message of the Attach procedure to the eNodeB, the MME shall wait for the Attach Complete message to arrive before sending a separate Bearer Setup Request of a Dedicated Bearer Activation procedure.

7b. For UE requested PDN connectivity procedure: If the MME receives a Create Session Response message combined with a Create Bearer Request message, the MME shall send the S1-AP Bearer Setup Request message to the eNodeB, including the NAS parts for both the PDN Connectivity Accept message and the Bearer Setup Request of the Dedicated Bearer Activation Procedure.

8-9. The radio bearer establishment of the default and dedicated bearer(s) is performed in the same RRC message.

10a.  For Attach procedure: The eNodeB sends the S1-AP Initial Context Setup Response message to the MME.

10b. For UE requested PDN connectivity procedure: The eNodeB sends the S1-AP Bearer Setup Response message to the MME.

11. For the Attach procedure: The UE sends the eNodeB a Direct Transfer message containing the Attach Complete (Session Management Response for the Default Bearer) message as response of the attach procedure, and Direct Transfer messages containing the Session Management Responses of the dedicated bearer setup procedure.

For the UE requested PDN connectivity procedure: The UE NAS layer builds a PDN Connectivity Complete (Session Management Response) for the Default Bearer Activation and Dedicated Bearer Activation Procedures. The UE then sends Direct Transfer (PDN Connectivity Complete) message to the eNodeB.

The NAS messages to establish the EPS bearers shall be handled individually by the UE and be sent in separate RRC Direct Transfer messages.

12. The eNodeB sends an Uplink NAS Transport message to the MME, which contains the NAS messages from the RRC message in step 11. There may be multiple Uplink NAS Transport messages when the UE sends multiple RRC messages containing NAS messages in step 11.

13. Upon reception of the response messages in both step 10 and step 12, the Modify Bearer Request message of the Attach procedure or UE requested PDN connectivity procedure is combined with the Create Bearer Response message of the Dedicated Bearer Activation Procedure. After that, the Serving GW continues with sending a Create Bearer Response message to the PDN GW.

Ref: 3GPP-23401.920

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

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].

UE - MME

- 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].
SGSN - MME

- 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].

SGSN - S GW

- 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].

S GW - P GW

MME - MME

MME - S GW

MME - HSS

- 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].

MME - EIR

- 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].

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.

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

source: http://www.3gpp.org/Dispelling-LTE-Myths

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.

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

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.

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

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;

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.

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.

 

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

LTE Architecture

The LTE architecture enables service providers to reduce the cost of owning and operating the network by allowing the service providers to have separate CN (MME, SGW, PDN GW) while the E-UTRAN (eNBs) is jointly shared by them. This is enabled by the S1-flex mechanism by enabling each eNB to be connected to multiple CN entities. When a UE attaches to the network, it is connected to the appropriate CN entities based on the identity of the service provider sent by the UE.

International Mobile Subscriber Identity (IMSI)

International Mobile Subscriber Identity (IMSI)

An International Mobile Subscriber Identity or IMSI ) is a unique number associated with all GSM and UMTS network mobile phone users. It is stored in the SIM inside the phone and is sent by the phone to the network. It is also used to acquire other details of the mobile in the Home Location Register (HLR) or as locally copied in the Visitor Location Register. In order to avoid the subscriber being identified and tracked by eavesdroppers on the radio interface, the IMSI is sent as rarely as possible and a randomly-generated TMSI is sent instead.


An IMSI is usually 15 digits long, but can be shorter (for example MTN South Africa's old IMSIs that are still being used in the market are 14 digits). The first 3 digits are the Mobile Country Code (MCC), and is followed by the Mobile Network Code (MNC), either 2 digits (Europeanstandard) or 3 digits (North American standard). The remaining digits are the mobile station identification number (MSIN) within the network's customer base.




Examples


IMSI:429011234567890
MCC 429 Nepal
MNC 01 Nepal Telecom
MSIN 1234567890


IMSI: 310150123456789
MCC 310 USA
MNC 150 AT&T
MSIN 123456789