RRC states in 5G

Looking back at my old post about UMTS & LTE (re)selection/handovers, I wonder how many different kinds of handovers and (re)selection options may be needed now.

In another earlier post, I talked about the 5G specifications. This can also be seen in the picture above and may be easy to remember. The 25 series for UMTS mapped the same way to 36 series for LTE. Now the same mapping will be applied to 38 series for 5G. RRC specs would thus be 38.331.

A simple comparison of 5G and LTE RRC states can be seen in the picture above. As can be seen, a new state 'RRC Inactive' has been introduced. The main aim is to maintain the RRC connection while at the same time minimize signalling and power consumption.

Looking at the RRC specs you can see how 5G RRC states will work with 4G RRC states. There are still for further studies (FFS) items. Hopefully we will get more details soon.

3GPP TS 22.261, Service requirements for the 5G system; Stage 1 suggests the following with regards to inter-working with 2G & 3G

5.1.2.2 Legacy service support
The 5G system shall support all EPS capabilities (e.g., from TSs 22.011, 22.101, 22.278, 22.185, 22.071, 22.115, 22.153, 22.173) with the following exceptions:
- CS voice service continuity and/or fallback to GERAN or UTRAN,
- seamless handover between NG-RAN and GERAN,
- seamless handover between NG-RAN and UTRAN, and
- access to a 5G core network via GERAN or UTRAN.

5G Core Network, System Architecture & Registration Procedure

The 5G System architecture (based on 3GPP TS 23.501: System Architecture for the 5G System; Stage 2) consists of the following network functions (NF). The functional description of these network functions is specified in clause 6.
- Authentication Server Function (AUSF)
- Core Access and Mobility Management Function (AMF)
- Data network (DN), e.g. operator services, Internet access or 3rd party services
- Structured Data Storage network function (SDSF)
- Unstructured Data Storage network function (UDSF)
- Network Exposure Function (NEF)
- NF Repository Function (NRF)
- Network Slice Selection Function (NSSF)
- Policy Control function (PCF)
- Session Management Function (SMF)
- Unified Data Management (UDM)
- Unified Data Repository (UDR)
- User plane Function (UPF)
- Application Function (AF)
- User Equipment (UE)
- (Radio) Access Network ((R)AN)

As you can see, this is slightly more complex than the 2G/3G/4G Core Network Architecture.

Alan Carlton, Vice President, InterDigital and Head of InterDigital International Labs Organization spanning Europe and Asia provided a concise summary of the changes in 5G core network in ComputerWorld:

Session management is all about the establishment, maintenance and tear down of data connections. In 2G and 3G this manifested as the standalone General Packet Radio Service (GPRS). 4G introduced a fully integrated data only system optimized for mobile broadband inside which basic telephony is supported as just one profile.

Mobility management as the name suggests deals with everything that needs doing to support the movement of users in a mobile network. This encompasses such functions as system registration, location tracking and handover. The principles of these functions have changed relatively little through the generations beyond optimizations to reduce the heavy signaling load they impose on the system.

The 4G core network’s main function today is to deliver an efficient data pipe. The existence of the service management function as a dedicated entity has been largely surrendered to the “applications” new world order. Session management and mobility management are now the two main functions that provide the raison d’etre for the core network.

Session management in 4G is all about enabling data connectivity and opening up a tunnel to the world of applications in the internet as quickly as possible. This is enabled by two core network functions, the Serving Gateway (SGW) and Packet Data Gateway (PGW). Mobility management ensures that these data sessions can be maintained as the user moves about the network. Mobility management functions are centralized within a network node referred to as Mobility Management Entity (MME). Services, including voice, are provided as an “app” running on top of this 4G data pipe. The keyword in this mix, however, is “function”. It is useful to highlight that the distinctive nature of the session and mobility management functions enables modularization of these software functions in a manner that they can be easily deployed on any Commercial-Off-The-Shelf (COTS) hardware.

The biggest change in 5G is perhaps that services will actually be making a bit of a return...the plan is now to deliver the whole Network as a Service. The approach to this being taken in 3GPP is to re-architect the whole core based on a service-oriented architecture approach. This entails breaking everything down into even more detailed functions and sub-functions. The MME is gone but not forgotten. Its former functionality has been redistributed into precise families of mobility and session management network functions. As such, registration, reachability, mobility management and connection management are all now new services offered by a new general network function dubbed Access and Mobility Management Function (AMF). Session establishment and session management, also formerly part of the MME, will now be new services offered by a new network function called the Session Management Function (SMF). Furthermore, packet routing and forwarding functions, currently performed by the SGW and PGW in 4G, will now be realized as services rendered through a new network function called the User Plane Function (UPF).

The whole point of this new architectural approach is to enable a flexible Network as a Service solution. By standardizing a modularized set of services, this enables deployment on the fly in centralized, distributed or mixed configurations to enable target network configurations for different users. This very act of dynamically chaining together different services is what lies at the very heart of creating the magical network slices that will be so important in 5G to satisfy the diverse user demands expected. The bottom line in all this is that the emphasis is now entirely on software. The physical boxes where these software services are instantiated could be in the cloud or on any targeted COTS hardware in the system. It is this intangibility of physicality that is behind the notion that the core network might disappear in 5G.

3GPP TS 23.502: Procedures for the 5G System; Stage 2, provides examples of signalling for different scenarios. The MSC above shows the example of registration procedure. If you want a quick refresher of LTE registration procedure, see here.

I dont plan to expand on this procedure here. Checkout section "4.2.2 Registration Management procedures" in 23.502 for details. There are still a lot of FFS (For further studies 😉) in the specs that will get updated in the coming months.


Further Reading:

• 3GPP TR 23.799: Study on Architecture for Next Generation System
• 3GPP TS 23.501: System Architecture for the 5G System; Stage 2
• 3GPP TS 23.502: Procedures for the 5G System; Stage 2

Enhanced 5G Security via IMSI Encryption

Source: North Star Post

IMSI Catchers can be a real threat. It doesn't generally affect anyone unless someone is out to get them. Nevertheless its a security flaw that is even present in LTE. This presentation here is a good starting point on learning about IMSI Catcher and the one here about privacy and availability attacks.

This article by Ericsson is a good starting point on how 5G will enhance security by IMSI encryption. From the article:

The concept we propose builds on an old idea that the mobile device encrypts its IMSI using home network’s asymmetric key before it is transmitted over the air-interface. By using probabilistic asymmetric encryption scheme – one that uses randomness – the same IMSI encrypted multiple times results in different values of encrypted IMSIs. This makes it infeasible for an active or passive attacker over the air-interface to identify the subscriber. Above is a simplified illustration of how a mobile device encrypts its IMSI. 

Each mobile operator (called the ‘home network’ here) has a public/private pair of asymmetric keys. The home network’s private asymmetric key is kept secret by the home network, while the home network’s public asymmetric key is pre-provisioned in mobile devices along with subscriber-specific IMSIs (Step 0). Note that the home network’s public asymmetric key is not subscriber-specific. 

For every encryption, the mobile device generates a fresh pair of its own public/private asymmetric keys (Step 1). This key pair is used only once, hence called ephemeral, and therefore provide probabilistic property to the encryption scheme. As shown in the figure, the mobile device then generates a new key (Step 2), e.g., using Diffie–Hellman key exchange. This new key is also ephemeral and is used only once to encrypt the mobile device’s IMSI (Step 3) using symmetric algorithm like AES. The use of asymmetric and symmetric crypto primitives as described above is commonly known as integrated/hybrid encryption scheme. The Elliptic Curve Integrated Encryption Scheme (ECIES) is a popular scheme of such kind and is very suitable to the use case of IMSI encryption because of low impact on radio bandwidth and mobile device’s battery. 

The nicest thing about the described concept is that no public key infrastructure is necessary, which significantly reduces deployment complexity, meaning that mobile operators can start deploying IMSI encryption for their subscribers without having to rely on any external party or other mobile operators.

'3GPP TR 33.899: Study on the security aspects of the next generation system' lists one such approach.

The Key steps are as follows:

1. UE is configured with 5G (e)UICC with ‘K’ key, the Home Network ID, and its associated public key.
2. SEAF send Identity Request message to NG-UE. NG-UE considers this as an indication to initiate Initial Authentication.
3. NG-UE performs the following:
1. Request the (e)UICC application to generate required security material for initial authentication, RANDUE, , COUNTER, KIARenc, and KIARInt.
2. NG-UE builds IAR as per MASA. In this step NG-UE includes NG-UE Security Capabilities inside the IAR message. It also may include its IMEI. 
3. NG-UE encrypts the whole IAR including the MAC with the home network public key.
4. NG-UE sends IAR to SEAF.
4. Optionally, gNB-CP node adds its Security Capabilities to the transposrt message between the gNB-CP and the SEAF (e.g., inside S1AP message as per 4G).
5. gNB-CP sends the respective S1AP message that carries the NG-UE IAR message to the SEAF.
6. SEAF acquirs the gNB-CP security capabilities as per the listed options in clause 5.2.4.12.4.3and save them as part of the temporary context for the NG-UE.
7. SEAF follows MASA and forward the Authentication and Data Request message to the AUSF/ARPF.
8. When AUSF/ARPF receives the Authentication and Data Request message, authenticates the NG-UE as per MASA and generates the IAS respective keys. AUSF/ARPF may recover the NG-UE IMSI and validate the NG-UE security capabilities.
9. AUSF/ARPF sends Authentication and Data Response to the SEAF as per MASA with NG-UE Security Capabilities included.
10. SEAF recovers the Subscriber IMSI, UE security Capabilities, IAS keys, RANDHN, COUNTER and does the following:
1. Examine the UE Security Capabilities and decides on the Security parameters.
2. SEAF may acquire the UP-GW security capabilities at this point after receiving the UP-GW identity from AUSF/ARPF or allocate it dynamically through provisioning and load balancing.
11. SEAF builds IAS and send to the NG-UE following MASA. In addition, SEAF include the gNB-CP protocol agreed upon security parameters in the S1AP message being sent to the gNB-CP node.
12. gNB-CP recovers gNB-CP protocol agreed upon security parameters and save it as part of the NG-UE current context.
13. gNB-CP forwards the IAS message to the NG-UE.
14. NG-UE validates the authenticity of the IAS and authenticates the network as per MASA. In addition, the UE saves all protocols agreed upon security parameters as part of its context. NG-UE sends the Security and Authentication Complete message to the SEAF.
15. SEAF communicates the agreed upon UP-GW security parameters to the UP-GW during the NG-UE bearer setup.

ARPF - Authentication Credential Repository and Processing Function 
AUSF - Authentication Server Function 
SCMF - Security Context Management Function
SEAF - Security Anchor Function
NG-UE - NG UE
UP - User Plane 
CP - Control Plane
IAR - Initial Authentication Request 
IAS - Initial Authentication Response
gNB - Next Generation NodeB

You may also want to refer to the 5G Network Architecture presentation by Andy Sutton for details.

See also:

• 5G Security Updates - July 2017
• 5G: Architecture, QoS, gNB, Specifications - April 2017 Update
• 5G – Beyond the Hype
• 5G Network Architecture and Design Update - Jan 2017

New LTE UE Categories (Downlink & Uplink) in Release-13

Just noticed that the LTE UE Categories have been updated since I last posted here. Since Release-12 onwards, we now have a possibility of separate Downlink (ue-CategoryDL) and Uplink (ue-CategoryUL) categories.

From the latest RRC specifications, we can see that now there are two new fields that can be present ue-CategoryDL and ue-CategoryUL.

An example defined here is as follows:

Example of RRC signalling for the highest combination
UE-EUTRA-Capability
   ue-Category = 4
      ue-Category-v1020 = 7
         ue-Category-v1170 = 10
            ue-Category-v11a0 = 12
               ue-CategoryDL-r12 = 12
               ue-CategoryUL-r12 = 13
                  ue-CategoryDL-v1260 = 16

From the RRC Specs:

• The field ue-CategoryDL is set to values m1, 0, 6, 7, 9 to 19 in this version of the specification.
• The field ue-CategoryUL is set to values m1, 0, 3, 5, 7, 8, 13 or 14 in this version of the specification.

3GPP TS 36.306 section 4 provides much more details on these UE categories and their values. I am adding these pictures from the LG space website.

More info:

• 3GPP TS 36.331: Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification
• 3GPP TS 36.306: Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) radio access capabilities
• http://niviuk.free.fr/ue_category.php - up to date info on LTE UE categories
• http://www.sharetechnote.com/html/LTE_Advanced_UE_Category.html

5G, Hacking & Security

It looks like devices that are not manufactures with security and privacy in mind are going to be the weakest link in future network security problems. I am sure you have probably read about how hacked cameras and routers enabled a Mirai botnet to take out major websites in October. Since then, there has been no shortage of how IoT devices could be hacked. In fact the one I really liked was 'Researchers hack Philips Hue lights via a drone; IoT worm could cause city blackout' 😏.

Enter 5G and the problem could be be made much worse. With high speed data transfer and signalling, these devices can create an instantaneous attack on a very large scale and generating signalling storm that can take a network down in no time.

Giuseppe TARGIA, Nokia presented an excellent summary of some of these issues at the iDate Digiworld Summit 2016. His talk is embedded below:



You can check out many interesting presentations from the iDate Digiworld Summit 2016 on Youtube and Slideshare.

Related posts:

• Three Presentations on 5G Security
• New whitepaper on Narrowband Internet of Things
• 5G New Radio (NR), Architecture options and migration from LTE
• M2M vs IoT
• Some more thoughts on 5G
• LTE, 5G and V2X
• 5G, Debates, Predictions and Stories

Whats up with VoLTE Roaming?

I have been covering the LTE Voice Summit for last couple of years (see here: 2015 & 2014) but this year I wont be around unfortunately. Anyway, I am sure there will be many interesting discussions. From my point of view, the 2 topics that have been widely discussed is roaming and VoWiFi.

One of the criticisms of VoWiFi is that it does not the QoS aspect is missing, which makes VoLTE special. In a recent post, I looked at the QoS in VoWiFi issue. If you haven't seen it, see here.

Coming back to VoLTE roaming, I came across this recent presentation by Orange.

This suggests that S8HR is a bad idea, the focus should be on LBO. For anyone who is not aware of the details of S8HR & LBO, please see my earlier blog post here. What this presentation suggests is to use LBO with no MTR (Mobile Termination Rates) but instead use TAP (Transferred Account Procedures). The presentation is embedded below:

Another approach that is not discussed too much but seems to be the norm at the moment is the use of IP eXchange (IPX). I also came across this other panel discussion on the topic

IPX is already in use for data roaming today and acts as a hub between different operators helping to solve inter-operability issues and mediating between roaming models. It can work out based on the calling and callee party what kind of quality and approach to use.

Here is the summary of the panel discussion:

Hopefully the LTE Voice Summit next week will provide some more insights. I look forward to hearing them.

Blog posts on related topics:

• VoLTE Roaming – Let’s Take Away The Confusion - iBasis
• VoLTE Roaming – Critical enabler or long term ideal? - 5G World
• VoLTE Roaming Confusion and the IPX Provider Opportunity - Ovum
• IPX providers must look internally for class-of-service customers - Ovum

Dedicated Core Networks (DCN) for different traffic types

Looking at a paper (embedded below) from NTT Docomo technical journal where they talk about Dedicated Core Network (DCN) for handling different traffic type (M2M/IoT for example). Note that this approach is different from NFV based network sliced architecture. For the latter, the network functions should have been virtualized.

There will be some signalling overhead in the core network to handle the new core and reroute the traffic according destined for the new dedicated core. I would still hope that this would be minuscule in the grand scheme of things. Anyway, let me know what you think about the paper below.

New whitepaper on Narrowband Internet of Things

Rohde & Schwarz has just published a new whitepaper on Narrowband Internet of Things (NB-IoT).

NB-IoT has been introduced as part of 3GPP Rel-13 where 3GPP has specified a new radio interface. NBIoT is optimized for machine type traffic and is kept as simple as possible in order to reduce device costs and to minimize battery consumption. In addition, it is also adapted to work in difficult radio conditions, which is a frequent operational area for certain machine type communication devices. Although NB-IoT is an independent radio interface, it is tightly connected with LTE, which also shows up in its integration in the current LTE specifications.

The paper contains the necessary technical details including the new channels, new frame and slot structure, new signalling messages including the system information messages, etc. It's a good read.

Its embedded below and can be downloaded from here:

Related posts:

• LTE-M a.k.a. Rel-13 Cellular IoT
• Cellular IoT (CIoT) or LoRa?
• LTE Category-0 low power M2M devices

MCPTT Off-network and UE to UE/Network Relays

3GPP SA6 recently held a workshop on Mission Critical Push To Talk (MCPTT) stage 3 development in Canada. You can look at the meeting report here and download any presentations from here.

An interesting presentation that caught my attention was one on "MCPTT Off-network Architecture". The presentation is embedded below where it is described technically what is meant by Off-network. From my understanding an off-network from MCPTT point of view is one where the UE does not have network coverage.

In such a situation a UE can connect to another UE that can connect to UE/network (if available) to relay the message. Its similar to another technology that I have talked about, Multihop Cellular Networks and ODMA. Anyway, here is the presentation:

Sometimes the standards can take too long to develop a feature and apps can come and deliver a similar service at a very short notice. One such App that does something similar is called Firechat, which played a big role in many protests worldwide. The video explaining it below is worth watching.


The problem with Apps is that they cannot be used by the emergency services or other governmental organisations, unless a standard feature is available. This is the expectation from this Off-network relays. It would work in combination with D2D/ProSe.


For anyone interested in the latest Public Safety (PS), here is a presentation by SA6 chairman from July

Diameter Security is worse than SS7 Security?

Back in December last year, there was a flurry of news about SS7 security flaw that allowed hackers to snoop on an unsuspecting users calls and SMS. The blog readers will also be aware that SS7 is being replaced by the Diameter protocol. The main reason being to simplify roaming while at the same time being able to manage the signalling storm in the networks.


The bad news is that while is case of SS7, security issues are due to network implementation and configuration (above pic), the security issues in Diameter seem to be due to the protocol and architecture themselves (below pic)

Diameter is very important for LTE network architecture and will possibly continue in the future networks too. It is very important to identify all such issues and iron them before some hackers start exploiting the network vulnerabilities causing issues for everyone.

The presentation by Cédric Bonnet, Roaming Technical Domain Manager, Orange at Signalling Focus Day of LTE World Summit 2015 is embedded below:

From SS7 to Diameter Security from Zahid Ghadialy

Some important information from this post has been removed due to a valid complaint.

S8HR: Standardization of New VoLTE Roaming Architecture

VoLTE is a very popular topic on this blog. A basic VoLTE document from Anritsu has over 40K views and my summary from last years LTE Voice summit has over 30K views. I assume this is not just due to the complexity of this feature.

When I attended the LTE Voice summit last year, of the many solutions being proposed for roaming, 'Roaming Architecture for Voice over LTE with Local Breakout (RAVEL)' was being touted as the preferred solution, even though many vendors had reservations.

Since then, GSMA has endorsed a new VoLTE roaming architecture, S8HR, as a candidate for VoLTE roaming. Unlike previous architectures, S8HR does not require the deployment of an IMS platform in VPLMN. This is advantageous because it shortens time-to-market and provides services universally without having to depend on the capability of VPLMN.



Telecom Italia has a nice quick summary, reproduced below:

S8HR simplicity, however, is not only its strength but also its weakness, as it is the source of some serious technical issues that will have to be solved. The analysis of these issues is on the Rel13 3GPP agenda for the next months, but may overflow to Rel14. Let’s see what these issues are, more in detail:

Regulatory requirements - S8HR roaming architecture needs to meet all the current regulatory requirements applicable to voice roaming, specifically:

• Support of emergency calls - The issues in this context are several. For example, authenticated emergency calls rely on the existence if an IMS NNI between VPLMN and HPLMN (which S8HR does not provide); conversely, the unauthenticated emergency calls, although technically feasible in S8HR, are allowed only in some Countries subject to the local regulation of VPLMN. Also, for a non-UE-detectable IMS Emergency call, the P-CSCF in the HPLMN needs to be capable of deciding the subsequent action (e.g. translate the dialed number and progress the call or reject it with the indication to set up an emergency call instead), taking the VPLMN ID into account. A configuration of local emergency numbers per Mobile Country Code on P-CSCF may thus be needed.
• ­Support of Lawful Interception (LI) & data retention for inbound roamers in VPLMN -  S8HR offers no solution to the case where interception is required in the VPLMN for inbound roamers. 3GPP is required to define a solution that fulfill such vital regulatory requirement, as done today in circuit switched networks. Of course VPLMN and HPLMN can agree in their bilateral roaming agreement to disable confidentiality protection to support inbound roamer LI but is this practice really viable from a regulatory point of view?

Voice call continuity – The issue is that when the inbound roamers lose the LTE coverage to enter into  a 2G/3G CS area, the Single Radio Voice Call Continuity (SRVCC) should be performed involving the HPLMN in a totally different way than current specification (i.e. without any IMS NNI being deployed).
Coexistence of LBO and S8HR roaming architectures will have to be studied since an operator may need to support both LBO and S8HR VoLTE roaming architecture options for roaming with different operators, on the basis of bilateral agreement and depending on the capability.
Other issues relate to the capability of the home based S-CSCF and TAS (Telephony Application Server) to be made aware about the VPLMN identity for charging purposes and to enable the TAS to subsequently perform communication barring supplementary services. Also, where the roaming user calls a geo-local number (e.g. short code, or premium numbers), the IMS entities in HPLMN must do number resolution to correctly route the call.
From preliminary discussions held at Working Group level in SA2 (architecture) and SA3 (security) in April, it was felt useful to create a new 3GPP Technical Report to perform comprehensive technical analysis on the subject. Thus it is expected that the discussions will continue in the next months until the end of 2015 and will overheat Release 13 agenda due to their commercial and “political” nature. Stay tuned to monitor the progress of the subject or contact the authors for further information!

NTT Docomo also did some trials back in February and got some brilliant results:

In the trials, DOCOMO and KT achieved the world's first high-definition voice and video call with full end-to-end quality of service. Also, DOCOMO and Verizon achieved the world's first transoceanic high-definition VoLTE roaming calls. DOCOMO has existing commercial 3G and 4G roaming relations with Verizon Wireless and KT.

The calls were made on an IP eXchange (IPX) and network equipment to replicate commercial networks. With only two months of preparation, which also proved the technology's feasibility of speedy commercialization, the quality of VoLTE roaming calls using S8HR architecture over both short and long distances was proven to be better than that of existing 3G voice roaming services.

In fact, NTT Docomo has already said based on the survery from GSMA's Network 2020 programme that 80% of the network operators want this to be supported by the standards and 46% of the operators already have a plan to support this.

The architecture has the following technical characteristics:
(1) Bearers for IMS services are established on the S8 reference point, just as LTE data roaming.
(2) All IMS nodes are located at Home Public Land Mobile Network (HPLMN), and all signaling and media traffic for the VoLTE roaming service go through HPLMN.
(3) IMS transactions are performed directly between the terminal and P-CSCF at HPLMN. Accordingly, Visited Public Land Mobile Network (VPLMN) and interconnect networks (IPX/GRX) are not service-aware at the IMS level. The services can only be differentiated by APN or QoS levels.

These three technical features make it possible to provide all IMS services by HPLMN only and to minimize functional addition to VPLMN. As a result, S8HR shortens the time-to-market for VoLTE roaming services.

Figure 2 shows the attach procedure for S8HR VoLTE roaming. From Steps 1 to 3, there is no significant difference from the LTE data roaming attach procedure. In Step 4, HSS sends an update location answer message to MME. In order for the MME to select the PGW in HPLMN (Step 5), the MME must set the information element VPLMN Dynamic Address “Allowed,” which is included in the subscribed data, to “Not Allowed.” In Step 6, the bearer for SIP signaling is created between SGW and PGW with QCI=5. MME sends an attach accept message to the terminal with an IMS Voice over PS Session Support Indication information element, which indicates that VoLTE is supported. The information element is set on the basis of the MME’s internal configuration specifying whether there is a VoLTE roaming agreement to use S8HR. If no agreement exists between two PLMNs, the information element will not be set.

The complete article from the NTT Docomo technical journal is embedded

Static/Dynamic IP Address Allocation in LTE

I recently came across a discussion on how static and dynamic IP address are allocated in LTE for a UE. Luckily, there is a recent document from Netmanias that discussed this topic. The document is embedded below.

If you enjoyed reading the document (part 1) above, then there is a part 2 here. While in part 1, we saw that IP addresses can be either dynamic or static depending on their allocators, part 2 presents a specific case of IP address allocation – allocation in geographically-separated locations within an LTE network. In case of dynamic allocation, no matter where a user accesses, a dynamically selected P-GW dynamically allocates an IP address to the user for PDN connection. In case of static allocation, however, there is always one specific P-GW and one IP address for a user - the designated P-GW allocates a static IP address for the user’s PDN connection. A case study shows an LTE network that serves two cities as an example to describe different ways and procedures of IP address allocation, and see how they are different from each other.

Enhancing voice services using VoLTE

VoLTE has been a very popular topic on this blog. My overview of the LTE Voice Summit missed out narrowly from the Top 10 posts of 2014 but there were other posts related to VoLTE that made it.

In this magazine article, NTT Docomo not only talks about its own architecture and transition from 3G to 4G for voice and video, it provides some detailed insights from its own experience.

There is also discussion into technical details of the feature and examples of signalling for VoLTE registration and originating/terminating calls (control, session and user plane establishment), SMS, SRVCC, Video over LTE (ViLTE) and voice to video call switching.

The paper is embedded below and available from slideshare to download.

VoLTE for Enhancing Voice Services from Zahid Ghadialy

Related links:

• DOCOMO VoLTE and Next Steps
• VoLTE Roaming with RAVEL (Roaming Architecture for Voice over IMS with Local Breakout)
• 2015 will finally be the year of Voice over LTE (VoLTE)

The SS7 flaws that allows hackers to snoop on your calls and SMS

By now I am aware that most people have heard of the flaws in SS7 networks that allow hackers to snoop, re-route calls and read text messages. For anyone who is not aware of these things, can read some excellent news articles here:

• Hackers Can Read Your Texts Thanks to Huge Security Flaw - Gizmodo
• German researchers discover a flaw that could let anyone listen to your cell calls. - Washington Post
• White hats do an NSA, figure out LIVE PHONE TRACKING via protocol vuln - The Register
• 1980s technology can be used to hack any smartphone - Beta News

Our trusted security expert, Ravi Borgaonkar, informs us that all these flaws have already been discussed back in May, as part of Positive Hack Days (PHDays).

Here are the slides on SS7 hack from PHDays, http://t.co/VwUwtFVqyc mentions all flaws reveals in 3 #31c3 talks on SS7 security.
— Ravishankar Borgaonk (@raviborgaonkar) December 28, 2014

The presentation is embedded below and can be downloaded from Slideshare:

How to Intercept a Conversation Held on the Other Side of the Planet from Positive Hack Days

xoxoxo Added this new information on the 4th Jan 2015 oxoxox

The following is this presentation and video by Tobias Engel from the 31st Chaos Communication Congress

SS7: Locate. Track. Manipulate. from 3G4G

Observed Time Difference Of Arrival (OTDOA) Positioning in LTE

Its been a while I wrote anything on Positioning. The network architecture for the positioning entities can be seen from my old blog post here. 

Qualcomm has recently released a whitepaper on the OTDOA (Observed Time Difference Of Arrival) positioning. Its quite a detailed paper with lots of technical insights.

There is also signalling and example of how reference signals are used for OTDOA calculation. Have a look at the whitepaper for detail, embedded below.

Observed Time Difference Of Arrival (OTDOA) Positioning in 3GPP LTE from Zahid Ghadialy

Diamater: Market Status, Roaming, NFV and Case Studies

Some more interesting presentations from the Signalling Focus Day of LTE World Summit. Good overview of market by Greg Collins of Exact ventures is embedded below.

Diameter Signaling Market Update from Zahid Ghadialy

A good presentation by Tieto where they presented some good case studies for Diameter Interworking. Presentation embedded below:

Diameter routing & interworking in NFV from Zahid Ghadialy

The final presentation by Diametriq is very interesting because they presented interesting way of mining the control plane. Thee case study presented was of a 'silent roamer' who is not going to spend money while roaming because he is not sure how much money is spent. This can be exploited by the operator to offer flat packages, 1 day pass, etc. to get some revenue from these roamers. Their presentation included some animations that cannot be shown while being embedded. Please download the PPT from Slideshare to view them.

Unlocking New Value in the Diameter Signaling Path from Zahid Ghadialy

Advancements in Congestion control technology for M2M

NTT Docomo recently published a new article (embedded below) on congestion control approaches for M2M. In their own words:

Since 3GPP Release 10 (Rel. 10) in 2010, there has been active study of technical specifications to develop M2M communications further, and NTT DOCOMO has been contributing proactively to creating these technical specifications. In this article, we describe two of the most significant functions standardized between 3GPP Rel. 10 and Rel. 11: the M2M Core network communications infrastructure, which enables M2M service operators to introduce solutions more easily, and congestion handling technologies, which improve reliability on networks accommodating a large number of terminals.

Complete article as follows:

Core Network Infrastructure and Congestion Control Technology for M2M Communications from Zahid Ghadialy

Other related posts:

• Rise of the "Thing"
• Access Class Barring in LTE using System Information Block Type 2
• Extended Access Barring (EAB) in Release 11 to avoid MTC overload
• RAN mechanisms to avoid CN overload due to MTC
• Service Specific Access Control (SSAC) in 3GPP Release 9

Rise of the "Thing"

Light Reading carried an interesting cartoon on how M2M works. I wouldnt be surprised if some of the M2M applications at present do work like this. Jokes apart, last week the UK operator EE did a very interesting presentation on Scaling the network for the Rise of the Thing.

A question often asked is "What is the difference between the 'Internet of Things' (IoT) and 'Machine to Machine' (M2M)?". This can generate big discussions and can be a lecture on its own. Quora has a discussion on the same topic here. The picture above from the EE presentation is a good way of showing that M2M is a subset of IoT. 

Its also interesting to note how these 'things' will affect the signalling. I often come across people who tell me that since most M2M devices just use small amounts of data transfer, why is there a need to move from GPRS to LTE. The 2G and 3G networks were designed primarily for Voice with Data secondary function. These networks may work well now but what happens when the predicted 50 Billion connected devices are here by 2020 (or 500 Billion by 2030). The current networks would drown in the control signalling that would often result in congested networks. Congestion control is just one of the things 3GPP is working on for M2M type devices as blogged earlier here. In fact the Qualcomm presentation blogged about before does a decent job of comparing various technologies for IoT, see here.

The EE presentation is embedded as follows:

Scaling the Network - Rise of the Thing from Zahid Ghadialy

Another good example website I was recently made aware of is http://postscapes.com/internet-of-things-examples/ - worth checking how IoT would help us in the future.

New RRC message in Rel-11: In-device coexistence indication

I have blogged about about IDC here and here. If the eNB is interested in knowing if the device is having an interference issue it can ask the UE to send this message in the RRC Conn Reconfiguration message. The UE would send the message if it has interference issues.

Inter-frequency handover is a good solution in case the UE is experiencing interference.

From the Rel-11 whitepaper posted last week here:

To assist the base station in selecting an appropriate solution, all necessary/available assistance information for both time and frequency domain solutions is sent together in the IDC indication. The IDC assistance information contains the list of carrier frequencies suffering from on-going interference and the direction of the interference. Additionally it may also contain time domain patterns or parameters to enable appropriate DRX configuration for time domain solutions on the serving LTE carrier frequency.

Note that the network is in the control of whether or not to activate this interference avoidance mechanism. The InDeviceCoexIndication message from the UE may only be sent if a measurement object for this frequency has been established. This is the case, when the RRCConnectionReconfiguration message from the eNB contains the information element idc-Config. The existence of this message declares that an InDeviceCoexIndication message may be sent. The IDC message indicates which frequencies of which technologies are interfered and gives assistance to possible time domain solutions. These comprise DRX assistance information and a list of IDC subframes, which indicate which HARQ processes E-UTRAN is requested to abstain from using. This information describes only proposals, it is completely up to the network to do the decisions.

Access Class Barring in LTE using System Information Block Type 2

As per 3GPP TS 22.011 (Service accessibility):

All UEs are members of one out of ten randomly allocated mobile populations, defined as Access Classes (AC) 0 to 9. The population number is stored in the SIM/USIM. In addition, UEs may be members of one or more out of 5 special categories (Access Classes 11 to 15), also held in the SIM/USIM. These are allocated to specific high priority users as follows. (The enumeration is not meant as a priority sequence):
Class 15 - PLMN Staff;
 -"-  14 - Emergency Services;
 -"-  13 - Public Utilities (e.g. water/gas suppliers);
 -"-  12 - Security Services;
 -"-  11 - For PLMN Use.

Now, in case of an overload situation like emergency or congestion, the network may want to reduce the access overload in the cell. To reduce the access from the UE, the network modifies the SIB2 (SystemInformationBlockType2) that contains access barring related parameters as shown below:

For regular users with AC 0 – 9, their access is controlled by ac-BarringFactor and ac-BarringTime. The UE generates a random number
– “Rand” generated by the UE has to pass the “persistent” test in order for the UE to access. By setting ac-BarringFactor to a lower value, the access from regular user is restricted (UE must generate a “rand” that is lower than the threshold in order to access) while priority users with AC 11 – 15 can access without any restriction

For users initiating emergency calls (AC 10) their access is controlled by ac-BarringForEmergency – boolean value: barring or not

For UEs with AC 11- 15, their access is controlled by ac-BarringForSpecialAC - boolean value: barring or not.

The network (E-UTRAN) shall be able to support access control based on the type of access attempt (i.e. mobile originating data or mobile originating signalling), in which indications to the UEs are broadcasted to guide the behaviour of UE. E-UTRAN shall be able to form combinations of access control based on the type of access attempt e.g. mobile originating and mobile terminating, mobile originating, or location registration.  The ‘mean duration of access control’ and the barring rate are broadcasted for each type of access attempt (i.e. mobile originating data or mobile originating signalling).

Another type of Access Control is the Service Specific Access Control (SSAC) that we have seen here before. SSAC is used to apply independent access control for telephony services (MMTEL) for mobile originating session requests from idle-mode.

Access control for CSFB provides a mechanism to prohibit UEs to access E-UTRAN to perform CSFB. It minimizes service availability degradation (i.e. radio resource shortage, congestion of fallback network) caused by mass simultaneous mobile originating requests for CSFB and increases the availability of the E-UTRAN resources for UEs accessing other services.  When an operator determines that it is appropriate to apply access control for CSFB, the network may broadcast necessary information to provide access control for CSFB for each class to UEs in a specific area. The network shall be able to separately apply access control for CSFB, SSAC and enhanced Access control on E-UTRAN.

Finally, we have the Extended Access Barring (EAB) that I have already described here before.