Attach Sequence for LTE Radio

I have in past posted a complete Attach Sequence on the 3G4G website for LTE Radio Signaling but included the signalling on a few nodes. Recently I came across a signalling example in NTT Docomo technical journal which was less detailed but at a higher level and detailed signalling on these other nodes. It may be worthwhile brushing up the LTE Architecture diagram before diving into this.

With EPC, when a terminal connects to the LTE radio access system it is automatically connected to the PDN and this connected state is maintained continuously. In other words, as the terminal is registered on the network (attached) through the LTE radio access system, a communications path to the PDN (IP connectivity) is established.

The PDN to which a connection is established can be preconfigured on a per-subscriber basis, or the terminal can specify it during the attach procedure. This PDN is called the default PDN. With the always-on connection function, the radio link of the connection only is released after a set amount of time has elapsed without the terminal performing any communication, and the IP connectivity between the terminal and the network is maintained. By doing this, only the radio link needs to be reconfigured when the terminal begins actual communication, allowing the connection-delay time to be reduced. Also, the IP address obtained when the terminal attaches can be used until it detaches, so it is always possible to receive packets using that IP address.

The information flow for the terminal attaching to the network up until the connection to the PDN is established is shown in Figure 2 below.

Steps (1) to (3): When the terminal establishes a radio control link for sending and receiving control signals with the eNodeB, it sends an attach request to the MME. The terminal and MME perform the required security procedures, including authentication, encryption and integrity.

Steps (4) to (5): The MME sends an update location request message to the Home Subscriber Server (HSS), and the HSS records that the terminal is connected under the MME.

Step (6): To begin establishing a transmission path to the default PDN, the MME sends a create session request to the S-GW.

Steps (7) to (8): When the S-GW receives the create session request from the MME, it requests proxy binding update to the P-GW. The P-GW allocates an IP address to the terminal and notifies the S-GW of this information in a proxy binding acknowledgement message. This process establishes a continuous core-network communications path between the P-GW and the S-GW for the allocated IP address.

Step (9): The S-GW prepares a radio access bearer from itself to the eNodeB, and sends a create session response signal to the MME. The create session response signal contains information required to configure the radio access bearer from the eNodeB to the S-GW, including information elements issued by the S-GW and the IP address allocated to the terminal.

Steps (10) to (11) and (13): The MME sends the information in the create session response signal to the eNodeB in an initial context setup request signal. Note that this signaling also contains other notifications such as the attach accept, which is the response to the attach request. When the terminal receives the attach accept in Step (11), it sends an attach complete response to the MME, notifying that processing has completed.

Step (12): The eNodeB establishes the radio data link and sends the attach accept to the terminal. It also configures the radio access bearer from the eNodeB to the S-GW and sends an initial context setup response to the MME. The initial context setup response contains information elements issued by the eNodeB required to establish the radio access bearer from the S-GW to the eNodeB.

Steps (14) to (15): The MME sends the information in the initial context setup response to the S-GW in a modify bearer request signal. The S-GW completes configuration of the previously prepared radio bearer from the S-GW to the eNodeB and sends a modify bearer response to the MME.

Through these steps, a communications path from the terminal to the P-GW is established, enabling communication with the default PDN.

If the terminal performs no communication for a set period of time, the always-on connection function described above releases the radio control link, the LTE radio data link, and the LTE radio access bearer, while maintaining the core network communications path.

After the terminal has established a connection to the default PDN, it is possible to initiate another connection to a different PDN. In this way it is possible to manage PDNs according to service.

For example the IMS PDN, which provides voice services by packet network, could be used as the default PDN, and a different PDN could be used for internet access.

To establish a connection to a PDN other than the default PDN, the procedure is the same as the attach procedure shown in Fig.2, excluding Steps (4) and (5).

TERMS:

Attach: Procedure to register a terminal on the network when, for example, its power is switched on.

Detach: Procedure to remove registration of a terminal from the network when, for example, its power is switched off.

Integrity: Whether the transmitted data is complete and has not been falsified. Here we refer to pre-processing required to ensure integrity of the data.

Bearer: A logical transmission path established, as between the S-GW and eNodeB.

Context setup: Configuration of information required for the communications path and communications management.

Emergency Calls in LTE/SAE Release-9

From a 3GPP presentation by Hannu Hietalahti:

Emergency calls in LTE

Regulatory requirement of emergency calls is supported in Rel-9 for LTE:

1. Detection of emergency numbers in UE

2. Indication and prioritisation of emergency calls

3. Location services, both for routing and user location data for PSAP (Public Safety Answering Point)

4. Callback is possible, but processed as normal call without exceptions

UE matches digits dialledby the user with list of known emergency numbers

1. Emergency number list in the UE is common for CS and PS domain use

2. Default 112 and 911, USIM pre-configuration, downloaded in MM procedure

3. In case of match, the UE shall initiate the call as an emergency call

In IMS emergency calls the UE translates dialled number into emergency service URN

1. Service URN with a top-level service type of "sos" as specified in RFC5031

2. Additionally, sub-service type can be added to indicate emergency category if information on the type of emergency service is known (fire, ambulance, police,…)

P-CSCF (Proxy - Call Session Control Function) must also be prepared to detect emergency call if the UE is not aware of local emergency call

1. This is backup for those cases when the (roaming) UE does not have full information of all local emergency call numbers and initiates a normal call

2. From EPC perspective, it will be a normal PDN connection

Benefit of location information

1. P-CSCF discovers the regionally correct PSAP to take the emergency call

2. PSAP gets information on the precise user location

Related Posts:

• 3GPP Release-9 Features updated
• Service Specific Access Control (SSAC) in 3GPP Release 9
• Public Warning System (PWS) in Release-9
• Europe makes 'eCall' high priority
• 3GPP Earthquake and Tsunami Warning service (ETWS)

Standards Developments in SAE

Standards Developments in SAE

View more presentations from Zahid Ghadialy.

LTE Evolved Packet System Architecture poster from ALU

Interesting poster from ALU on the Evolved Packet System Architecture. Available to download from Slideshare.

MSF LTE Interoperability White Paper, Jun 2010

This white paper provides a summary of the MultiService Forum’s (MSF) Global LTE Interoperability event which took place from March 15-30, 2010.

The LTE Interoperability Event is designed to test standards compliance of Evolved Packet Core network scenarios of interest to major Service Providers, and to gauge vendor support for this technology. Building on the success of previous Global MSF Interoperability (GMI) events, the LTE Interoperability event provided the first global “real network” multi-vendor trial of the Evolved Packet Core infrastructure.

Incorporating the Evolved Packet Core defined within the Third Generation Partnership Project (3GPP) Release 8 (R8) standards, the MSF architecture introduced new access tiles to support LTE access and non-3GPP (specifically eHRPD) access to EPC. The IMS core network provided the application layer for which services may be deployed, and the binding of Quality of Service utilizing the Policy and Charging Control (PCC) for the bearer.

The event demonstrated that most of the defined LTE/EPC interfaces were mature and interoperable; however limited backwards compatibility between different implementations of 3GPP Release 8 specifications did create some issues. The fact that 3GPP does not require backward compatibility is a known limitation, but it is important to understand that this is limiting interoperability with commercially available equipment. Service providers will need to factor this into vendor selection.

Highlights of the event included:-

• Sessions were successfully established via LTE access to EPC, with creation of default and dedicated bearers with appropriate Quality of Service applied.
• An end-to-end IMS Voice over LTE session was also successfully demonstrated,
• Access to the EPC via a simulated eHRPD access was successfully tested.
• Handover between LTE and eHRPD,
• Roaming was successfully tested.

Though the essential standards are reasonably mature, the implementation of early versions of the standards within several of the available implementations of network nodes highlights the problems that can arise due to non-backwards compatibility between 3GPP releases. It is also clear that early implementations have focused initially on development of LTE access to EPC and that support for legacy access (2G/3G) to EPC is somewhat behind. Events such as the MSF LTE Interoperability event highlight these issues and prove the validity of the MSF approach to achieving multi-vendor interoperability.

MSF LTE Interoperability White Paper, Jun 2010

View more documents from Zahid Ghadialy.

This paper is available to download from here.

LTE QCI and End-to-end bearer QoS in EPC

Gary Leonard, Director Mobile Solutions, IP Division, Alcatel-Lucent in a presentation at the LTE World Summit

GPRS Roaming eXchange (GRX) for LTE/EPS Networks

The GSM Association (GSMA) has came to the realization that GPRS roaming based on bilateral relationships between individual GPRS operators is incredibly complex and expensive to maintain, in particular if the number of roaming partners is high. In fact, each operator will have to have N(N - 1) dedicated links to other operators (given that N is the global numbers of operators for which roaming should be supported). The GSMA has therefore recommended the use of a GPRS Roaming eXchange (GRX) for the Inter-PLMN GPRS roaming scenario.

The GRX is built on a private or public IP backbone and transports GPRS roaming traffic via the GTP between the visited and the home PLMN (Figure above). A GRX service provider has a network consisting of a set of routers and the links connecting to the GPRS networks. Moreover, the GRX network will have links connecting to other GRX nodes to support GRX peering between networks.

The GRX service provider acts as a hub, therefore allowing a GPRS operator to interconnect with each roaming partner without the need for any dedicated connections. This allows faster implementation of new roaming relations, faster time to market for new operators, and better scalability since an operator can start with low-capacity connections to the GRX and upgrade them depending on the bandwidth and quality requirements of the traffic. Other benefits of GRX are as follows:

Support of QoS: This aspect that will be very important for the GPRS services and, in particular, for the transition to 3G systems.

Security: The interconnection between the home operator and the visited operator uses the private GRX networks, hence does not require the overhead of maintaining expensive IPSEC tunnels over the public Internet.

DNS support: Through GRX it is possible to support a worldwide ".gprs" DNS root, where the various GRX operators will collaborate in managing the root and each operator's DNS servers will be connected to such roots to provide translation of DNS names specific to one operator.

In conclusion, GRX is introduced for GPRS roaming to facilitate the network operators for the interconnection between networks to support roaming and will play a very important role for the transition to third-generation systems.

In the LTE World Summit, Alex Sinclair, Chief Technology Officer, GSMA mentioned about the important role GRX will play in the LTE networks. The figure below are his views on GRX.

Diagram and Initial text Reference: IP in Wireless Networks By Basavaraj Patil, et al.

More information on GRX is available in GSM Association IR.34 document.

CS Services over EPS study in Release 9

One of the Release-9 items is "Study on Circuit Switched (CS) domain services over evolved Packet Switched (EPS) access" which is described in 3GPP TR 23.879.

Martin Sauter has already done some analysis on this topic so I would advice anyone interested to read it on his blog here.

Service Specific Access Control (SSAC) in 3GPP Release 9

In an emergency situation, like Earthquake or Tsunami, degradation of quality of service may be experienced. Degradation in service availability and performance can be accepted in such situations, but mechanisms are desirable to minimize such degradation and maximize the efficiency of the remaining resources.

When Domain Specific Access Control (DSAC) mechanism was introduced for UMTS, the original motivation was to enable PS service continuation during congestion in CS Nodes in the case of major disaster like an Earthquake or a Tsunami.

In fact, the use case of DSAC in real UMTS deployment situation has been to apply access control separately on different types of services, such as voice and other packet-switched services.

For example, people’s psychological behaviour is to make a voice call in emergency situations and it is not likely to change. Hence, a mechanism will be needed to separately restrict voice calls and other services.

As EPS is a PS-Domain only system, DSAC access control does not apply.

The SSAC Technical Report (see Reference) identifies specific features useful when the network is subjected to decreased capacity and functionality. Considering the characteristics of voice and non-voice calls in EPS, requirements of the SSAC could be to restrict the voice calls and non-voice calls separately.

For a normal paid service there are QoS requirements. The provider can choose to shut down the service if the requirements cannot be met. In an emergency situation the most important thing is to keep communication channels uninterrupted, therefore the provider should preferably allow for a best effort (degradation of) service in preference to shutting the service down. During an emergency situation there should be a possibility for the service provider also to grant services, give extended credit to subscribers with accounts running empty. Under some circumstances (e.g. the terrorist attack in London on the 7 of July in 2005), overload access control may be invoked giving access only to authorities or a predefined set of users. It is up to national authorities to define and implement such schemes.

Reference: 3GPP TR 22.986 - Study on Service Specific Access Control