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.

eMPS: Enhanced Multimedia Priority Service in Release-10 and beyond

The response to emergency situations (e.g., floods, hurricanes, earthquakes, terrorist attacks) depends on the communication capabilities of public networks. In most cases, emergency responders use private radio systems to aid in the logistics of providing critically needed restoration services. However, certain government and emergency management officials and other authorised users have to rely on public network services when the communication capability of the serving network may be impaired, for example due to congestion or partial network infrastructure outages, perhaps due to a direct or indirect result of the emergency situation.

Multimedia Priority Service, supported by the 3GPP system set of services and features, is one element creating the ability to deliver calls or complete sessions of a high priority nature from mobile to mobile networks, mobile to fixed networks, and fixed to mobile networks.

Requirements for the Multimedia Priority Service (MPS) have been specified in TS 22.153 for the 3GPP Release-9

The intention of MPS is to enable National Security/Emergency Preparedness (NS/EP) users (herein called Service Users) to make priority calls/sessions using the public networks during network congestion conditions. Service Users are the government-authorized personnel, emergency management officials and/or other authorized users. Effective disaster response and management rely on the Service User’s ability to communicate during congestion conditions. Service Users are expected to receive priority treatment, in support of mission critical multimedia communications.

LTE/EPC Release 9 supports IMS-based voice call origination by a Service User and voice call termination to a Service User with priority. However, mechanisms for completing a call with priority do not exist for call delivery to a regular user for a priority call originated by a Service User. MPS enhancements are needed to support priority treatment for Release 10 and beyond for call termination and for the support of packet data and multimedia services.

MPS will provide broadband IP-based multimedia services (IMS-based and non-IMS-based) over wireless networks in support of voice, video, and data services. Network support for MPS will require end-to-end priority treatment in call/session origination/termination including the Non Access Stratum (NAS) and Access Stratum (AS) signaling establishment procedures at originating/terminating network side as well as resource allocation in the core and radio networks for bearers. The MPS will also require end-to-end priority treatment in case of roaming if supported by the visiting network and if the roaming user is authorized to receive priority service.

MPS requirement is already achieved in the 3G circuit-switched network. Therefore, if the network supports CS Fallback, it is necessary to provide at least the same capability as 3G circuit switched-network in order not to degrade the level of voice service. In CS Fallback, UE initiates the fallback procedures over the LTE as specified in TS 23.272 when UE decides to use the CS voice service for mobile originating and mobile terminating calls. To achieve priority handling of CS Fallback, NAS and AS signaling establishment procedures, common for both IP-based multimedia services and CS Fallback, shall be treated in a prioritized way.

In Release-10, for LTE/EPC, the following mechanisms will be specified.

• Mechanisms to allocate resources for signaling and media with priority based on subscribed priority or based on priority indicated by service signaling.
• For a terminating IMS session over LTE, a mechanism for the network to detect priority of the session and treat it with priority.

In Release-10, for CS Fallback, the following mechanism will be specified:

• A mechanism to properly handle the priority terminating voice call and enable the target UE to establish the AS and NAS connection to fall-back to the GERAN/UTRAN/1xRTT.

For more information, see:

3GPP TR 23.854: Enhancements for Multimedia Priority Service (Release 10)

3GPP TS 22.153: Multimedia priority service (Release 10)

RAN mechanisms to avoid CN overload due to MTC

Machine-to-Machine (M2M) is the future and Machine-type communications (MTC) will be very important once we have billions of connected devices. I have talked in the past about the 50 Billion connected devices by 2050 and the Internet of Things.

One of the challenges of today's networks is to handle this additional signalling traffic due to MTC. One of the very important topics being discussed in 3GPP RAN meetings is 'RAN mechanisms to avoid CN overload due to MTC'. Even though it has not been finalised, its interesting to see the direction in which things are moving.

The above figure from R2-106188 shows that an extended wait time could be added in the RRC Connection Reject/Release message in case if the eNodeB is overloaded. The device can reattempt the connection once the wait time has expired.

In R2-110462, another approach is shown where Core Network (CN) is overloaded. Here a NAS Request message is sent with delay tolerant indicator a.k.a. low priority indicator. If the CN is overloaded then it can reject the request with a backoff timer. Another approach would be to send this info to the eNodeB that can do a RRC Connection Reject when new connection request is received.

All Documents from 3GPP RAN2 #72-bis are available here. Search for NIMTC for M2M related and overload related docs.

Packet Flow in 2.5G, 3G, 3.5G and 4G

The 'LTE Signaling' is a very interesting book just being released that is a must have for people who are involved in design, development and testing. A book that explains the basic concepts from beginning till advanced concepts and explains how different components and interfaces fit together.

Though I havent yet read this book, I have read the earlier one titled UMTS Signaling, from the same authors that is an excellent reference for understanding Signalling in UMTS. I have no doubt that this book will be the same high quality.

The Excerpt on Wiley's website provides complete chapter 1 which is quite detailed and the Packet flow pictures and details below is extracted from this book.

The first stage of the General Packet Radio Service (GPRS), that is often referred to as the 2.5G network, was deployed in live networks starting after the year 2000. It was basically a system that offered a model of how radio resources (in this case, GSM time slots) that had not been used by Circuit Switched (CS) voice calls could be used for data transmission and, hence, profitability of the network could be enhanced. At the beginning there was no pre-emption for PS (Packet Switched) services, which meant that the packet data needed to wait to be transmitted until CS calls had been finished.

In contrast to the GSM CS calls that had a Dedicated Traffic Channel (DTCH) assigned on the radio interface, the PS data had no access to dedicated radio resources and PS signaling, and the payload was transmitted in unidirectional Temporary Block Flows (TBFs) as shown in Figure 1.2.

In Release 99, when a PDP (Packet Data Protocol) context is activated the UE is ordered by the RNC (Radio Network Controller) to enter the Radio Resource Control (RRC) CELL_DCH state. Dedicated resources are assigned by the Serving Radio Network Controller (SRNC): these are the dedicated physical channels established on the radio interface. Those channels are used for transmission of both IP payload and RRC signaling – see Figure 1.7. RRC signaling includes the exchange of Non-Access Stratum (NAS) messages between the UE and SGSN.

The spreading factor of the radio bearer (as the combination of several physical transport resources on the Air and Iub interfaces is called) depends on the expected UL/DL IP throughput. The expected data transfer rate can be found in the RANAP (Radio Access Network Application Part) part of the Radio Access Bearer (RAB) assignment request message that is used to establish the Iu bearer, a GPRS Tunneling Protocol (GTP) tunnel for transmission of a IP payload on the IuPS interface between SRNC and SGSN. While the spreading factor controls the bandwidth of the radio connection, a sophisticated power control algorithm guarantees the necessary quality of the radio transmission. For instance, this power control ensures that the number of retransmitted frames does not exceed a certain critical threshold.

Activation of PDP context results also in the establishment of another GTP tunnel on the Gn interface between SGSN and GGSN. In contrast to IuPS, where tunnel management is a task of RANAP, on the Gn interface – as in (E)GPRS – the GPRS Tunneling Protocol – Control (GTP-C) is responsible for context (or tunnel) activation, modification, and deletion.

However, in Release 99 the maximum possible bit rate is still limited to 384 kbps for a single connection and, more dramatically, the number of users per cell that can be served by this highest possible bit rate is very limited (only four simultaneous 384 kbps connections per cell are possible on the DL due to the shortness of DL spreading codes).

To increase the maximum possible bit rate per cell as well as for the individual user, HSPA was defined in Releases 5 and 6 of 3GPP.

In High-Speed Downlink Packet Access (HSDPA) the High-Speed Downlink Shared Channel (HSDSCH) which bundles several High-Speed Physical Downlink Shared Channels (HS-PDSCHs) is used by several UEs simultaneously – that is why it is called a shared channel.

A single UE using HSDPA works in the RRC CELL_DCH state. For DL payload transport the HSDSCH is used, that is, mapped onto the HS-PDSCH. The UL IP payload is still transferred using a dedicated physical data channel (and appropriate Iub transport bearer); in addition, the RRC signaling is exchanged between the UE and RNC using the dedicated channels – see Figure 1.8.

All these channels have to be set up and (re)configured during the call. In all these cases both parties of the radio connection, cell and UE, have to be informed about the required changes. While communication between NodeB (cell) and CRNC (Controlling Radio NetworkController) uses NBAP (Node B Application Part), the connection between the UE and SRNC (physically the same RNC unit, but different protocol entity) uses the RRC protocol.

The big advantage of using a shared channel is higher efficiency in the usage of available radio resources. There is no limitation due to the availability of codes and the individual data rate assigned to a UE can be adjusted quicker to the real needs. The only limitation is the availability of processing resources (represented by channel card elements) and buffer memory in the base station.

From the user plane QoS perspective the two major targets of LTE are:

• a further increase in the available bandwidth and maximum data rate per cell as well as for the individual subscriber;

• reducing the delays and interruptions in user data transfer to a minimum.

These are the reasons why LTE has an always-on concept in which the radio bearer is set up immediately when a subscriber is attached to the network. And all radio resources provided to subscribers by the E-UTRAN are shared resources, as shown in Figure 1.9. Here it is illustrated that the IP payload as well as RRC and NAS signaling are transmitted on the radio interfaces using unidirectional shared channels, the UL-SCH and the Downlink Shared Channel (DL-SCH). The payload part of this radio connection is called the radio bearer. The radio bearer is the bidirectional point-to-point connection for the user plane between the UE and eNodeB (eNB). The RAB is the user plane connection between the UE and the Serving Gateway (S-GW) and the S5 bearer is the user plane connection between the S-GW and public data network gateway (PDN-GW).

The end-to-end connection between the UE and PDN-GW, that is, the gateway to the IP world outside the operator’s network, is called a PDN connection in the E-UTRAN standard documents and a session in the core network standards. Regardless, the main characteristic of this PDN connection is that the IP payload is transparently tunneled through the core and the radio access network.

To control the tunnels and radio resources a set of control plane connections runs in parallel with the payload transport. On the radio interface RRC and NAS signaling messages are transmitted using the same shared channels and the same RLC transport layer that is used to transport the IP payload.

RRC signaling terminates in the eNB (different from 3G UTRAN where RRC was transparently routed by NodeB to the RNC). The NAS signaling information is – as in 3G UTRAN – simply forwarded to the Mobility Management Entity (MME) and/or UE by the eNB.

You can read in detail about all these things and much more from the Wiley's website here.

UEInformationRequest/UEInformationResponse - New RRC messages in Release-9

As is obvious from the title, The UE information procedure is used by E-UTRAN to request the UE to report information [1].

There are two different scenarios for the Network to send the UEInformationRequest message to the UE. One is to find out the number of RACH preambles it needed for the random access procedure and the other is to get the measurement information when a Radio Link Failure (RLF) occurred.

[2] also provides the following detail:

The network may poll for the UE report after a successful random access procedure (UEInformationRequest) and the UE responds with the number of preambles sent by MAC for the last successfully completed random access procedure and whether contention is detected by MAC for at least one of the transmitted preambles for the last successfully completed random access procedure (UEInformationResponse).

Source:

[1] 3GPP TS 36.331 V9.3.0: Radio Resource Control (RRC); Protocol specification - Section 5.6.5

[2] 3GPP TR 36.902 V9.2.0: Self-configuring and self-optimizing network (SON) use cases and solutions

Proximity Indication - New RRC Uplink Message in Rel-9

The inbound handover from a Macro eNB to an HeNB (a.k.a. Femtocell) is not supported in Release 8. Before making a handover decision to a HeNB, the Macro eNB needs to acquire UE measurement information related to the so-called target CSG cell. Nevertheless, UEs cannot continuously make measurements and read the system information of lots of CSG cells in cases of large scale HeNB deployments.

In order to allow the UE to make those measurements efficiently, a newly defined proximity report can be configured within the RRC Reconfiguration message. This proximity report will allow the UE to send a so-called “proximity indication” to the source eNB in the uplink whenever it is entering or leaving the proximity of one or more cells with CSG IDs that the UEs has in its CSG Whitelist.

A UE that is able to determine that it is near its CSG cell can thus inform the network to take the necessary actions for handover preparation. The detection of proximity is based on an autonomous search function.

The source eNB, upon receiving the proximity indication, might ask the UE to perform measurements of the CSG cell, to read the System Information (SI) or, in case it already has all required information, it might already start the handover procedure. PCI (Physical Cell Identification) confusion is resolved in Release 9. The eNB will ask the UE to report the global cell identity. As usual the UE reporting is using the RRC measurement procedures. The ovell procedure is illustrated in Figure below.

In summary five basic steps can be identified:

1. Proximity configuration/reporting

2. HO measurement configuration/reporting

3. Resolution of PCI confusion by requesting and reporting System Information

4. Access Control in the network

5. HO execution

Since the CSG search can be very slow there are no strict requirements on the inbound handover performance, which can range from one to several 10’s of seconds.

Since the proximity information is based on UE signaling, the network might be receiving a lot of proximity indications, increasing the network load. Therefore, it was agreed to limit proximity indications a UE can send within a certain time frame. A timer, called the prohibit proximity timer, was introduced.

Source:

• 3GPP TS 36.331 v9.3.0 section 5.3.14
• Nomor Research Whitepaper - LTE Home Node Bs and its enhancements in Release 9

Understanding smartphone traffic - Interesting Presentation

Understanding smartphone traffic - Droidcon

View more presentations from Ericsson Labs

If you like the above then also check out the Fast Dormancy in Release-8.

Fast Dormancy in Release-8

Nokia Siemens Networks has collaborated with Qualcomm to carry out the industry’s first successful interoperability test of the new 3GPP standardized Release 8 Fast Dormancy feature. Unlike proprietary approaches to fast dormancy, the new standard allows operators to take full advantage of smart network features such as Cell_PCH without worrying that individual handset settings will ignore network controls.

The test was conducted at Nokia Siemens Networks’ Smart Lab in Dallas using Nokia Siemens Networks’ Flexi Multiradio Base Station and Radio Network Controller and Qualcomm’s QSC7230TM smartphone optimized chipset. The test showed how smartphones can act dynamically, exploiting Cell_PCH on Nokia Siemens Networks’ smart networks or adjusting to Fast Dormancy on other vendors’ traditional networks.

In fact the operators have been getting upset quite for some time because of smartphone hacks that save the UE battery life but cause network signalling congestion. See here.

To explain the problem, lets look at the actual signalling that occurs when the UE is not transmitting anything. Most probably it gets put into CELL_PCH or URA_PCH state. Then when keep alive messages need to be sent then the state is transitioned to CELL_FACH and once done its sent back to CELL_PCH. Now the transitioning back from CELL_FACH (or CELL_DCH) to CELL_PCH can take quite some time, depending on the operator parameters and this wastes the UE battery life.

To get round this problem, the UE manufacturers put a hack in the phone and what they do is that if there no data to transmit for a small amount of time, the UE sends RRC Signalling Connection Release Indication (SCRI) message. This message is supposed to be used in case when something is gone wrong in the UE and the UE wants the network to tear the connection down by sending RRC Connection Release message. Anyway, the network is forced to Release the connection.

If there is another requirement to send another keep alive message (they are needed for lots of apps like Skype, IM's, etc.) the RRC connection would have to be established all over again and this can cause lots of unnecessary signalling for the network causing congestion at peak times.

To speed up the transitioning to CELL_PCH state in Release-8 when the UE sends SCRI message, its supposed to include the cause value as "UE Requested PS Data session end". Once the network receives this cause it should immediately move the UE to CELL_PCH state.

This is a win win situation for both the network and the UE vendors as long as a lot of UE's implement this. The good thing is that even a pre-Rel8 UE can implement this and if the network supports this feature it would work.

GSMA has created a best practices document for this feature which is embedded below.

Fast dormancy from Dono Miguel

Further Reading:

• UMTS State Switching and Fast Dormancy Evolution - Martin Sauter
• RP-090941 - System impact of poor proprietary Fast Dormancy implementations
• RP-090942 - Clarification on Enhanced SCRI approach for fast dormancy
• RP-090960 - Configuration of Fast Dormancy
• R2-096882 - Changes to Release-8 Fast Dormanc

LTE UE Initial Signalling example

I have added initial signaling MSC for an LTE UE at the 3G4G website here. I havent yet managed to expand on the signalling details yet but it should be a good starting point for most people.

Santosh on his Wired n Wireless site has details on LTE Attach procedure which you may find interesting here. See here.

Signaling latency in UMTS/HSPA and LTE

I think this is a very good self explanatory picture from a presentation by Qasara.

Do check out the 3G4G page for up to date presentations, whitepapers, etc. on LTE/SAE.