Showing posts with label Signalling. Show all posts
Showing posts with label Signalling. Show all posts

Friday 14 September 2018

End-to-end Network Slicing in 5G

I recently realised that I have never written a post just on Network slicing. So here is one on the topic. So the first question asked is, why do we even need Network Slicing? Alan Carlton from Interdigital wrote a good article on this topic. Below is what I think is interesting:

Network slicing is a specific form of virtualization that allows multiple logical networks to run on top of a shared physical network infrastructure. The key benefit of the network slicing concept is that it provides an end-to-end virtual network encompassing not just networking but compute and storage functions too. The objective is to allow a physical mobile network operator to partition its network resources to allow for very different users, so-called tenants, to multiplex over a single physical infrastructure. The most commonly cited example in 5G discussions is sharing of a given physical network to simultaneously run Internet of Things (IoT), Mobile Broadband (MBB), and very low-latency (e.g. vehicular communications) applications. These applications obviously have very different transmission characteristics. For example, IoT will typically have a very large number of devices, but each device may have very low throughput. MBB has nearly the opposite properties since it will have a much smaller number of devices, but each one will be transmitting or receiving very high bandwidth content. The intent of network slicing is to be able to partition the physical network at an end-to-end level to allow optimum grouping of traffic, isolation from other tenants, and configuring of resources at a macro level.

Source: ITU presentation, see below

The key differentiator of the network slicing approach is that it provides a holistic end-to-end virtual network for a given tenant. No existing QoS-based solution can offer anything like this. For example, DiffServ, which is the most widely deployed QoS solution, can discriminate VoIP traffic from other types of traffic such as HD video and web browsing. However, DiffServ cannot discriminate and differentially treat the same type of traffic (e.g. VoIP traffic) coming from different tenants.

Also, DiffServ does not have the ability to perform traffic isolation at all. For example, IoT traffic from a health monitoring network (e.g. connecting hospitals and outpatients) typically have strict privacy and security requirements including where the data can be stored and who can access it. This cannot be accomplished by DiffServ as it does not have any features dealing with the compute and storage aspects of the network. All these identified shortfalls of DiffServ will be handled by the features being developed for network slicing.

I came across this presentation by Peter Ashwood-Smith from Huawei Technologies who presented '5G End to-end network slicing Demo' at ITU-T Focus Group IMT-2020 Workshop and Demo Day on 7 December 2016. Its a great presentation, I wish a video of this was available as well. Anyway, the presentation is embedded below and the PPT can be downloaded from here.



The European Telecommunications Standards Institute (ETSI) has established a new Industry Specification Group (ISG) on Zero touch network and Service Management (ZSM) that is working to produce a set of technical specifications on fully automated network and service management with, ideally, zero human intervention. ZSM is targeted for 5G, particularly in network slice deployment. NTT Technical review article on this is available here.

Finally, here is a presentation by Sridhar Bhaskaran of Cellular Insights blog on this topic. Unfortunately, not available for download.


Related Posts:

Monday 25 June 2018

Free Apps for Field Testing - Part 2

The last time I wrote about the free apps for field testing, many people came back and suggested additional apps that are much more commonly used. In fact we got the following comment when 3G4G re-posted this

As I have used both these apps frequently, here is a small summary on them.

Network Signal Guru: This is surprisingly very popular and is quite useful. The only issue is that you need to have a rooted phone with Qualcomm chipset. I know many testers have their favourite phones and quite a few testers buy the latest phones, root them and start testing using NSG (Network Signal Guru).

I prefer using Motorola Moto Gx series phones. They are cheap, not too difficult to root (YouTube have quite a few tutorials and Google search works too) and I find that their receivers are better than others. Have detected cells that other phones cant and have even camped and speed tested on them too.

So what can NSG do?

It can provide lots of useful information on the physical layer, cell configurations, neighbor cell lists, MIMO, etc.
You can even RAT lock to LTE / WCDMA / GSM and band lock to use a specific band. It can be very useful during surveys when you want to check if you can see particular frequency anywhere in an area. You can also see Codecs, RACH information, Data information, etc.

Finally, one of the best things I find is the signalling information. Some of the details are only available for purchased option, its nevertheless very useful. Just in case you are wondering how much does it cost, its roughly £50 per month license in UK.


Cell Mapper: I find this much more helpful as it can be used without rooting. CellMapper is a crowd-sourced cellular tower and coverage mapping service. Its simple and only used for basic testing but nevertheless very useful. To give you an idea, the other day I was camped on a cell with very good signal quality but very poor data rates and there weren't many people so congestion didn't seem like a factor. On investigation I found out that I was camped on 800MHz band that has limited bandwidth per operator and there was no CA.

Cell mapper, as you can see provides information about the cell you are camped on, the cell tower location, what other sectors and frequencies are there, etc.


Do you have a favorite testing app that I missed? Let me know in comments.

Sunday 25 March 2018

5G Security Updates - March 2018


Its been a while since I wrote about 5G security in this fast changing 5G world. If you are new to 3GPP security, you may want to start with my tutorial here.

3GPP SA3 Chairman, Anand R. Prasad recently mentioned in his LinkedIn post:

5G security specification finalized! Paving path for new business & worry less connected technology use.

3GPP SA3 delegates worked long hours diligently to conclude the specification for 5G security standard during 26 Feb.-2 Mar. Several obstacles were overcome by focussed effort of individuals & companies from around the globe. Thanks and congrats to everyone!

All together 1000s of hours of work with millions of miles of travel were spent in 1 week to get the work done. This took 8 meetings (kicked off Feb. 2017) numerous on-line meetings and conference calls.

Excited to declare that this tremendous effort led to timely completion of 5G security specification (TS 33.501) providing secure services to everyone and everything!

The latest version of specs is on 3GPP website here.

ITU also held a workshop on 5G Security in Geneva, Switzerland on 19 March 2018 (link). There were quite a few interesting presentations. Below are some slides that caught my attention.

The picture in the tweet above from China Mobile summarises the major 5G security issues very well. 5G security is going to be far more challenging than previous generations.

The presentation by Haiguang Wang, Huawei contained a lot of good technical information. The picture at the top is from that presentation and highlights the difference between 4G & 5G Security Architecture.


New entities have been introduced to make 5G more open.


EPS-AKA vs 5G-AKA (AKA = Authentication and Key Agreement) for trusted nodes


EAP-AKA' for untrusted nodes.


Slice security is an important topic that multiple speakers touched upon and I think it would continue to be discussed for a foreseeable future.

Dr. Stan Wing S. Wong from King’s College London has some good slides on 5G security issues arising out of Multi-Tenancy and Multi-Network Slicing.

Peter Schneider from Nokia-Bell Labs had good slides on 5G Security Overview for Programmable Cloud-Based Mobile Networks

Sander Kievit from TNO, a regular participant of working group SA3 of 3GPP on behalf of the Dutch operator KPN presented a view from 3GPP SA3 on the Security work item progress (slides). The slide above highlights the changes in 5G key hierarchy.

The ITU 5G Security Workshop Outcomes is available here.

ETSI Security Week 2018 will be held 11-15 June 2018. 5G security/privacy is one of the topics.

There is also 5GPPP Workshop on 5G Networks Security (5G-NS 2018), being held in Hamburg, Germany on August 27-30, 2018.

In the meantime, please feel free to add your comments & suggestions below.


Related Posts & Further Reading:

Thursday 4 January 2018

Introduction to 3GPP Security in Mobile Cellular Networks


I recently did a small presentation on 3GPP Security, looking at the how the security mechanism works in mobile cellular networks; focusing mainly on signaling associated with authentication, integrity protection and ciphering / confidentiality. Its targeted towards people with basic understanding of mobile networks. Slides with embedded video below.



You can also check-out all such videos / presentations at the 3G4G training section.

Monday 18 December 2017

Control and User Plane Separation of EPC nodes (CUPS) in 3GPP Release-14


One of the items in 3GPP Rel-14 is Control and User Plane Separation of EPC nodes (CUPS). I have made a video explaining this concept that is embedded below.

In 3G networks (just considering PS domain), the SGSN and GGSN handles the control plane that is responsible for signalling as well as the user plane which is responsible for the user data. This is not a very efficient approach for deployment.

You can have networks that have a lot of signalling (remember signaling storm?) due to a lot of smartphone users but not necessarily consuming a lot of data (mainly due to price reasons). On the other hand you can have networks where there is not a lot of signalling but lot of data consumption. An example of this would be lots of data dongles or MiFi devices where users are also consuming a lot of data, because it’s cheap.

To cater for these different scenarios, the control plane and user plane was separated to an extent in the Evolved Packet Core (EPC). MME handles the control plane signalling while S-GW & P-GW handles the user plane

CUPS goes one step further by separating control & user plane from S-GW, P-GW & TDF. TDF is Traffic Detection Function which was introduced together with Sd reference point as means for traffic management in the Release 11. The Sd reference point is used for Deep Packet Inspections (DPI) purposes. TDF also provides the operators with the opportunity to capitalize on analytics for traffic optimization, charging and content manipulation and it works very closely with Policy and charging rules function, PCRF.

As mentioned, CUPS provides the architecture enhancements for the separation of S-GW, P-GW & TDF functionality in the EPC. This enables flexible network deployment and operation, by using either distributed or centralized deployment. It also allows independent scaling between control plane and user plane functions - while not affecting the functionality of the existing nodes subject to this split.

As the 3GPP article mentions, CUPS allows for:
  • Reducing Latency on application service, e.g. by selecting User plane nodes which are closer to the RAN or more appropriate for the intended UE usage type without increasing the number of control plane nodes.
  • Supporting Increase of Data Traffic, by enabling to add user plane nodes without changing the number of SGW-C, PGW-C and TDF-C in the network.
  • Locating and Scaling the CP and UP resources of the EPC nodes independently.
  • Independent evolution of the CP and UP functions.
  • Enabling Software Defined Networking to deliver user plane data more efficiently.

The following high-level principles were also adopted for the CUPS:
  • The CP function terminates the Control Plane protocols: GTP-C, Diameter (Gx, Gy, Gz).
  • A CP function can interface multiple UP functions, and a UP function can be shared by multiple CP functions.
  • An UE is served by a single SGW-CP but multiple SGW-UPs can be selected for different PDN connections. A user plane data packet may traverse multiple UP functions.
  • The CP function controls the processing of the packets in the UP function by provisioning a set of rules in Sx sessions, i.e. Packet Detection Rules for packets inspection, Forwarding Action Rules for packets handling (e.g. forward, duplicate, buffer, drop), Qos Enforcement Rules to enforce QoS policing on the packets, Usage Reporting Rules for measuring the traffic usage.
  • All the 3GPP features impacting the UP function (PCC, Charging, Lawful Interception, etc) are supported, while the UP function is designed as much as possible 3GPP agnostic. For example, the UPF is not aware of bearer concept.
  • Charging and Usage Monitoring are supported by instructing the UP function to measure and report traffic usage, using Usage Reporting Rule(s). No impact is expected to OFCS, OCS and the PCRF.
  • The CP or UP function is responsible for GTP-u F-TEID allocation.
  • A legacy SGW, PGW and TDF can be replaced by a split node without effecting connected legacy nodes.
CUPS forms the basis of EPC architecture evolution for Service-Based Architecture for 5G Core Networks. More in another post soon.

A short video on CUPS below, slides available here.



Further reading:


Thursday 23 November 2017

5G NR Radio Protocols and Tight Inter-working with LTE


Osman Yilmaz, Team Leader & Senior Researcher at Ericsson Research in Finland gave a good summary of 5G NR at URLLC 2017 Conference (see summary here). His presentation is embedded below:



Osman, along with Oumer Teyeb, Senior Researcher at Ericsson Research & member of the Ericsson 5G standardization delegation has also published a blog post LTE-NR tight-interworking on Ericsson Research blog.

The post talks about how how signalling and data will work in LTE & New Radio (NR) dual connected devices. In control plane it looks at RRC signalling applicable for this DC devices whereas in user plane it looks at direct and split DRB options.


Further details here.

Thursday 9 November 2017

Quick tutorial on Mobile Network Sharing Options


Here is a quick tutorial on mobile network sharing approaches, looking at site/mast sharing, MORAN, MOCN and GWCN. Slides and video embedded below. If for some reason you prefer direct link to video, its here.

Sunday 5 November 2017

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.

Sunday 3 September 2017

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:

Sunday 20 August 2017

Enhanced 5G Security via IMSI Encryption


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:

Saturday 7 January 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:



Sunday 4 December 2016

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:


Friday 7 October 2016

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:

Saturday 27 August 2016

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.



Wednesday 10 August 2016

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:

Friday 28 August 2015

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

Sunday 9 August 2015

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.

Sunday 12 July 2015

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