Showing posts with label Technical Details. Show all posts
Showing posts with label Technical Details. Show all posts

Thursday 12 April 2018

#CWHeritage Talk: The History of Synchronization in Digital Cellular Networks


CW (a.k.a. Cambridge Wireless) held a very interesting event titled 'Time for Telecoms' at the Science Museum in London. I managed to record this one talk by Prof. Andy Sutton, who has also kindly shared slides and some other papers that he mentions in his presentation. You can also see the tweets from the event on Twitter.

The video playlist and the presentation is embedded below.






The papers referred to in the presentation/video available as follows:

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:

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

Wednesday 20 September 2017

A quick starter on 4G voice (for beginners)


I recently did a 4G voice presentation for beginners after realizing that even though so many years have passed after VoLTE was launched, people are still unsure how it works or how its different from CS Fallback.

There are many other posts that discuss these topics in detail on this blog (follow the label) or on 3G4G website. Anyway, here is the video:


The slides are available on 3G4G Slideshare account here. More similar training videos are available here.

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:

Thursday 20 July 2017

Second thoughts about LTE-U / LAA

Its been a while since I wrote about LTE-U / LAA on this blog. I have written a few posts on the small cells blog but they seem to be dated as well. For anyone needing a quick refresher on LTE-U / LAA, please head over to IoTforAll or ShareTechNote. This post is not about the technology per se but the overall ecosystem with LTE-U / LAA (and even Multefire) being part of that.

Lets recap the market status quickly. T-Mobile US has already got LTE-U active and LAA was tested recently. SK Telecom achieved 1Gbps in LAA trials with Ericsson. AT&T has decided to skip the non-standard LTE-U and go to standards based LAA. MTN & Huawei have trialled LAA for in-building in South Africa. All these sound good and inspires confidence in the technology however some observations are worrying me.


Couple of years back when LTE-U idea was conceived, followed by LAA, the 5GHz channels were relatively empty. Recently I have started to see that they are all filling up.

Any malls, hotels, service stations or even big buildings I go to, they all seem to be occupied. While supplemental downlink channels are 20MHz each, the Wi-Fi channels could be 20MHz, 40MHz, 80MHz or even 160MHz.

On many occasions I had to switch off my Wi-Fi as the speeds were so poor (due to high number of active users) and go back to using 4G. How will it impact the supplemental downlink in LTE-U / LAA? How will it impact the Wi-Fi users?

On my smartphone, most days I get 30/40Mbps download speeds and it works perfectly fine for all my needs. The only reason we would need higher speeds is to do tethering and use laptops for work, listen to music, play games or watch videos. Most people I know or work with dont require gigabit speeds at the moment.

Once a user that is receiving high speeds data on their device using LTE-U / LAA creates a Wi-Fi hotspot, it may use the same 5GHz channels as the ones that the network is using for supplemental downlink. How do you manage this interference? I am looking forward to discussions on technical fora where users will be asking why their download speeds fall as soon as they switch Wi-Fi hotspot on.

The fact is that in non-dense areas (rural, sub-urban or even general built-up areas), operators do not have to worry about the network being overloaded and can use their licensed spectrum. Nobody is planning to deploy LTE-U / LAA in these areas. In dense and ultra-dense areas, there are many users, many Wi-Fi access points, ad-hoc Wi-Fi networks and many other sources of interference. In theory LTE-U / LAA can help significantly but as there are many sources of interference,its uncertain if it would be a win-win for everyone or just more interference for everyone to deal with.

Further reading:

Monday 19 June 2017

Network Sharing is becoming more relevant with 5G

5G is becoming a case of 'damned if you do damned if you don't'. Behind the headlines of new achievements and faster speeds lies the reality that many operators are struggling to keep afloat. Indian and Nigerian operators are struggling with heavy debt and it wont be a surprise if some of the operators fold in due course.

With increasing costs and decreasing revenues, its no surprise that operators are looking at ways of keeping costs down. Some operators are postponing their 5G plans in favour of Gigabit LTE. Other die hard operators are pushing ahead with 5G but looking at ways to keep the costs down. In Japan for example, NTT DOCOMO has suggested sharing 5G base stations with its two rivals to trim costs, particularly focusing efforts in urban areas.


In this post, I am looking to summarise an old but brilliant post by Dr. Kim Larsen here. While it is a very well written and in-depth post, I have a feeling that many readers may not have the patience to go through all of it. All pictures in this post are from the original post by Dr. Kim Larsen.


Before embarking on any Network sharing mission, its worthwhile asking the 5W's (Who, Why, What, Where, When) and 2H's (How, How much).

  • Why do you want to share?
  • Who to share with? (your equal, your better or your worse).
  • What to share? (sites, passives, active, frequencies, new sites, old sites, towers, rooftops, organization, ,…).
  • Where to share? (rural, sub-urban, urban, regional, all, etc..).
  • When is a good time to start sharing? During rollout phase, steady phase or modernisation phase. See picture below. For 5G, it would make much more sense that network sharing is done from the beginning, i.e., Rollout Phase


  • How to do sharing?. This may sound like a simple question but it should take account of regulatory complexity in a country. The picture below explains this well:



  • How much will it cost and how much savings can be attained in the long term? This is in-fact a very important question because the end result after a lot of hard work and laying off many people may result in an insignificant amount of cost savings. Dr. Kim provides detailed insight on this topic that I find it difficult to summarise. Best option is to read it on his blog.


An alternative approach to network sharing is national roaming. Many European operators are dead against national roaming as this means the network loses its differentiation compared to rival operators. Having said that, its always worthwhile working out the savings and seeing if this can actually help.

National Roaming can be attractive for relative low traffic scenarios or in case were product of traffic units and national roaming unit cost remains manageable and lower than the Shared Network Cost.

The termination cost or restructuring cost, including write-off of existing telecom assets (i.e., radio nodes, passive site solutions, transmission, aggregation nodes, etc….) is likely to be a substantially financial burden to National Roaming Business Case in an area with existing telecom infrastructure. Certainly above and beyond that of a Network Sharing scenario where assets are being re-used and restructuring cost might be partially shared between the sharing partners.

Obviously, if National Roaming is established in an area that has no network coverage, restructuring and termination cost is not an issue and Network TCO will clearly be avoided, Albeit the above economical logic and P&L trade-offs on cost still applies.

If this has been useful to understand some of the basics of network sharing, I encourage you to read the original blog post as that contains many more details.

Futher Reading:



Sunday 11 June 2017

Theoretical calculation of EE's announcement for 429Mbps throughput


The CEO of UK mobile network operator EE recently announced on twitter that they have achieved 429 Mbps in live network. The following is from their press release:

EE, the UK’s largest mobile network operator and part of the BT Group, has switched on the next generation of its 4G+ network and demonstrated live download speeds of 429Mbps in Cardiff city centre using Sony’s Xperia XZ Premium, which launched on Friday 2 June. 
The state of the art network capability has been switched on in Cardiff and the Tech City area of London today. Birmingham, Manchester and Edinburgh city centres will have sites upgraded during 2017, and the capability will be built across central London. Peak speeds can be above 400Mbps with the right device, and customers connected to these sites should be able to consistently experience speeds above 50Mbps. 
Sony’s Xperia XZ Premium is the UK’s first ‘Cat 16’ smartphone optimised for the EE network, and EE is the only mobile network upgrading its sites to be able to support the new device’s unique upload and download capabilities. All devices on the EE network will benefit from the additional capacity and technology that EE is building into its network. 
... 
The sites that are capable of delivering these maximum speeds are equipped with 30MHz of 1800MHz spectrum, and 35MHz of 2.6GHz spectrum. The 1800MHz carriers are delivered using 4x4 MIMO, which sends and receives four signals instead of just two, making the spectrum up to twice as efficient. The sites also broadcast 4G using 256QAM, or Quadrature Amplitude Modulation, which increases the efficiency of the spectrum.

Before proceeding further you may want to check out my posts 'Gigabit LTE?' and 'New LTE UE Categories (Downlink & Uplink) in Release-13'

If you read the press release carefully, EE are now using 65MHz of spectrum for 4G. I wanted to provide a calculation for whats possible in theory with this much bandwidth.

Going back to basics (detailed calculation for basics in slideshare below), in LTE/LTE-A, the maximum bandwidth possible is 20MHz. Any more bandwidth can be used with Carrier Aggregation. So as per the EE announcement, its 20 + 10 MHz in 1800 band and 20 + 15 MHz in 2600 band

So for 1800 MHz band:

50 resource blocks (RBs) per 10MHZ, 150 for 30MHz.
Each RB has 12x7x2=168 symbols per millisecond in case of normal modulation support cyclic prefix (CP).
For 150 RBs, 150 x 168 = 25200 symbols per ms or 25,200,000 symbols per second. This can also be written as 25.2 Msps (Mega symbols per second)
256 QAM means 8 bits per symbol. So the calculation changes to 25.2 x 8 = 201.6 Mbps. Using 4 x 4 MIMO, 201.6 x 4 = 806.4Mbps
Removing 25% overhead which is used for signalling, this gives 604.80 Mbps


Repeating the same exercise for 35MHz of 2600 MHz band, with 2x2 MIMO and 256 QAM:

175 x 168 = 29400 symbols per ms or 29,400,000 symbols per second. This can be written as 29.4 Msps
29.4 x 8 = 235.2 Mbps
Using 2x2 MIMO, 235.2 x 2 = 470.4 Mbps
Removing 25% overhead which is used for signalling, this gives 352.80 Mbps

The combined theoretical throughput for above is 957.60 Mbps

For those interested in revisiting the basic LTE calculations, here is an interesting document:




Further reading:

Sunday 7 May 2017

10 years battery life calculation for Cellular IoT

I made an attempt to place the different cellular and non-cellular LPWA technologies together in a picture in my last post here. Someone pointed out that these pictures above, from LoRa alliance whitepaper are even better and I agree.

Most IoT technologies lists their battery life as 10 years. There is an article in Medium rightly pointing out that in Verizon's LTE-M network, IoT devices battery may not last very long.

The problem is that 10 years battery life is headline figure and in real world its sometimes not that critical. It all depends on the application. For example this Iota Pet Tracker uses Bluetooth but only claims battery life of  "weeks". I guess ztrack based on LoRa would give similar results. I have to admit that non-cellular based technologies should have longer battery life but it all depends on applications and use cases. An IoT device in the car may not have to worry too much about power consumption. Similarly a fleet tracker that may have solar power or one that is expected to last more than the fleet duration, etc.


So coming back to the power consumption. Martin Sauter in his excellent Wireless Moves blog post, provided the calculation that I am copying below with some additions:

The calculation can be found in 3GPP TR 45.820, for NB-IoT in Chapter 7.3.6.4 on ‘Energy consumption evaluation’.

The battery capacity used for the evaluation was 5 Wh. That’s about half or even only a third of the battery capacity that is in a smartphone today. So yes, that is quite a small battery indeed. The chapter also contains an assumption on how much power the device draws in different states. In the ‘idle’ state the device is in most often, power consumption is assumed to be 0.015 mW.

How long would the battery be able to power the device if it were always in the idle state? The calculation is easy and you end up with 38 years. That doesn’t include battery self-discharge and I wondered how much that would be over 10 years. According to the Varta handbook of primary lithium cells, self-discharge of a non-rechargable lithium battery is less than 1% per year. So subtract roughly 4 years from that number.

Obviously, the device is not always in idle and when transmitting the device is assumed to use 500 mW of power. Yes, with this power consumption, the battery would not last 34 years but less than 10 hours. But we are talking about NB-IoT so the device doesn’t transmit for most of the time. The study looked at different transmission patterns. If 200 bytes are sent once every 2 hours, the device would run on that 5 Wh battery for 1.7 years. If the device only transmits 50 bytes once a day the battery would last 18.1 years.

So yes, the 10 years are quite feasible for devices that collect very little data and only transmit them once or twice a day.

The conclusions from the report clearly state:

The achievable battery life for a MS using the NB-CIoT solution for Cellular IoT has been estimated as a function of reporting frequency and coupling loss. 

It is important to note that these battery life estimates are achieved with a system design that has been intentionally constrained in two key respects:

  • The NB-CIoT solution has a frequency re-use assumption that is compatible with a stand-alone deployment in a minimum system bandwidth for the entire IoT network of just 200 kHz (FDD), plus guard bands if needed.
  • The NB-CIoT solution uses a MS transmit power of only +23 dBm (200 mW), resulting in a peak current requirement that is compatible with a wider range of battery technologies, whilst still achieving the 20 dB coverage extension objective.  

The key conclusions are as follows:

  • For all coupling losses (so up to 20 dB coverage extension compared with legacy GPRS), a 10 year battery life is achievable with a reporting interval of one day for both 50 bytes and 200 bytes application payloads.
  • For a coupling loss of 144 dB (so equal to the MCL for legacy GPRS), a 10 year battery life is achievable with a two hour reporting interval for both 50 bytes and 200 bytes application payloads. 
  • For a coupling loss of 154 dB, a 10 year battery life is achievable with a 2 hour reporting interval for a 50 byte application payload. 
  • For a coupling loss of 154 dB with 200 byte application payload, or a coupling loss of 164 dB with 50 or 200 byte application payload, a 10 year battery life is not achievable for a 2 hour reporting interval. This is a consequence of the transmit energy per data bit (integrated over the number of repetitions) that is required to overcome the coupling loss and so provide an adequate SNR at the receiver. 
  • Use of an integrated PA only has a small negative impact on battery life, based on the assumption of a 5% reduction in PA efficiency compared with an external PA.

Further improvements in battery life, especially for the case of high coupling loss, could be obtained if the common assumption that the downlink PSD will not exceed that of legacy GPRS was either relaxed to allow PSD boosting, or defined more precisely to allow adaptive power allocation with frequency hopping.

I will look at the technology aspects in a future post how 3GPP made enhancements in Rel-13 to reduce power consumption in CIoT.

Also have a look this GSMA whitepaper on 3GPP LPWA lists the applications requirements that are quite handy.

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 16 October 2016

Inside 3GPP Release-13 - Whitepaper by 5G Americas


The following is from the 5G Americas press release:

The summary offers insight to the future of wireless broadband and how new requirements and technological goals will be achieved. The report updates Release 13 (Rel-13) features that are now completed at 3GPP and were not available at the time of the publication of a detailed 5G Americas report, Mobile Broadband Evolution Towards 5G: 3GPP Release 12 & Release 13 and Beyond in June 2015.
The 3GPP standards have many innovations remaining for LTE to create a foundation for 5G.  Rel-12, which was finalized in December 2014, contains a vast array of features for both LTE and HSPA+ that bring greater efficiency for networks and devices, as well as enable new applications and services. Many of the Rel-12 features were extended into Rel-13.  Rel-13, functionally frozen in December 2015 and completed in March 2016, continues to build on these technical capabilities while adding many robust new features.
Jim Seymour, Principal Engineer, Mobility CTO Group, Cisco and co-leader of the 5G Americas report explained, “3GPP Release 13 is just a peek behind the curtain for the unveiling of future innovations for LTE that will parallel the technical work at 3GPP on 5G. Both LTE and 5G will work together to form our connected future.”
The numerous features in the Rel-13 standards include the following for LTE-Advanced:
  • Active Antenna Systems (AAS), including beamforming, Multi-Input Multi-Output (MIMO) and Self-Organizing Network (SON) aspects
  • Enhanced signaling to support inter-site Coordinated Multi-Point Transmission and Reception (CoMP)
  • Carrier Aggregation (CA) enhancements to support up to 32 component carriers
  • Dual Connectivity (DC) enhancements to better support multi-vendor deployments with improved traffic steering
  • Improvements in Radio Access Network (RAN) sharing
  • Enhancements to Machine Type Communication (MTC)
  • Enhanced Proximity Services (ProSe)
Some of the standards work in Rel-13 related to spectrum efficiency include:                                                                                                                       
  • Licensed Assisted Access for LTE (LAA) in which LTE can be deployed in unlicensed spectrum
  • LTE Wireless Local Area Network (WLAN) Aggregation (LWA) where Wi-Fi can now be supported by a radio bearer and aggregated with an LTE radio bearer
  • Narrowband IoT (NB-IoT) where lower power wider coverage LTE carriers have been designed to support IoT applications
  • Downlink (DL) Multi-User Superposition Transmission (MUST) which is a new concept for transmitting more than one data layer to multiple users without time, frequency or spatial separation
“The vision for 5G is being clarified in each step of the 3GPP standards. To understand those steps, 5G Americas provides reports on the developments in this succinct, understandable format,” said Vicki Livingston, Head of Communications for the association.

The whitepaper as follows:



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:

Monday 26 September 2016

QoS in VoWiFi

Came across this presentation by Eir from last year's LTE Voice Summit.



As the summary of the above presentation says:
  • Turning on WMM (or WME) at access point provides significant protection for voice traffic against competing wireless data traffic
  • Turning on WMM at the client makes only a small difference where there are a small number of clients on the wireless LAN. This plus the “TCP Unfairness” problem means that it can be omitted.
  • All Home gateways support WMM but their firmware may need to be altered to prioritise on DSCP rather than layer two

As this Wikipedia entry explains:

Wireless Multimedia Extensions (WME), also known as Wi-Fi Multimedia (WMM), is a Wi-Fi Alliance interoperability certification, based on the IEEE 802.11e standard. It provides basic Quality of service (QoS) features to IEEE 802.11 networks. WMM prioritizes traffic according to four Access Categories (AC): voice (AC_VO), video (AC_VI), best effort (AC_BE), and background (AC_BK). However, it does not provide guaranteed throughput. It is suitable for well-defined applications that require QoS, such as Voice over IP (VoIP) on Wi-Fi phones (VoWLAN).

WMM replaces the Wi-Fi DCF distributed coordination function for CSMA/CA wireless frame transmission with Enhanced Distributed Coordination Function (EDCF). EDCF, according to version 1.1 of the WMM specifications by the Wi-Fi Alliance, defines Access Categories labels AC_VO, AC_VI, AC_BE, and AC_BK for the Enhanced Distributed Channel Access (EDCA) parameters that are used by a WMM-enabled station to control how long it sets its Transmission Opportunity (TXOP), according to the information transmitted by the access point to the station. It is implemented for wireless QoS between RF media.

This blog post describes how the QoS works in case of WMM.



Finally, this slide from Cisco shows how it will all fit together.

Further reading:

Friday 23 September 2016

5G New Radio (NR), Architecture options and migration from LTE


You have probably read about the demanding requirements for 5G in many of my blog posts. To meet these demanding requirements a 'next-generation radio' or 'new radio' (NR) will be introduced in time for 5G. We dont know as of yet what air interface, modulation technology, number of antennas, etc. for this NR but this slide above from Qualcomm gives an idea of what technologies will be required for this 5G NR.
The slide above gives a list of design innovations that will be required across diverse services as envisioned by 5G proponents.

It should be mentioned that Rel-10/11/12 version of LTE is referred to as LTE-Advanced and Rel-13/14 is being referred to as LTE-A Pro. Rel-15 will probably have a new name but in various discussions its being referred to as eLTE.

When first phase of 5G arrives in Rel-15, eLTE would be used for access network and EPC will still be used for core network. 5G will use NR and eventually get a new core network, probably in time for phase 2. This is often referred to as next generation core network (NGCN).

The slides below from Deutsche Telekom show their vision of how operators should migrate from eLTE to 5G.



The slides below from AT&T show their vision of LTE to 5G migration.



Eiko Seidel posted the following in 3GPP 5G standards group (i recommend you join if you want to follow technical discussions)


Summary RAN1#86 on New Radio (5G) Gothenburg, Sweden

At this meeting RAN1 delegates presented and discussed numerous evaluation results mainly in the areas of waveforms and channel coding.

Nonetheless RAN1 was not yet prepared to take many technical decisions. Most agreements are still rather general. 

First NR terminology has been defined. For describing time structures mini-slots have been introduced: a mini-slot is the smallest possible scheduling unit and smaller than a slot or a subframe.

Discussions on waveforms favored filtered and windowed OFDM. Channel coding discussions were in favor of LDPC and Turbo codes. But no decisions have been made yet.

Not having taken many decisions at this meeting, RAN1 now is behind its schedule for New Radio.
Hopefully the lag can be made up at two additional NR specific ad hoc meetings that have been scheduled for January and June 2017.

(thanks to my colleague and friend Dr. Frank Kowalewski for writing this short summary!)

Yet another post from Eiko on 3GPP RAN 3 on related topic.

The RAN3 schedule is that in February 2017 recommendations can be made for a protocol architecture.  In the meeting arguments came up by some parties that the work plan is mainly addressing U-Plane architecture and that split of C- and U-plane is not considered sufficiently. The background is that the first step will be dual connectivity with LTE using LTE RRC as control plane and some companies would like to concentrate on this initially. It looks like that a prioritization of features might happen in November timeframe. Beside UP and CP split, also the functional split between the central RAN node and the distributed RAN node is taking place for the cloud RAN fronthaul interface. Besides this, also discussion on the fronthaul interface takes place and it will be interesting to see if RAN3 will take the initiative to standardize a CPRI like interface for 5G. Basically on each of the three interfaces controversial discussion is ongoing.

Yet another basic question is, what is actually considered as a “New 5G RAN”? Is this term limited to a 5G eNB connected to the NG core? Or can it also be also an eLTE eNB with Dual Connectivity to 5G? Must this eLTE eNB be connected to the 5G core or is it already a 5G RAN when connected to the EPC? 

Finally, a slide from Qualcomm on 5G NR standardization & launch.


Sunday 22 May 2016

QCI Enhancements For Mission Critical Communications

Its been quite a while since I posted about QCI and end-to-end bearer QoS in EPC. In LTE Release-12 some new QCI values were added to handle mission critical communications.


This picture is taken from a new blog called Public Safety LTE. I have discussed about the Default and Dedicated bearers in an earlier post here (see comments in that post too). You will notice in the picture above that new QCI values 65, 66, 69 & 70 have been added. For mission critical group communications new default bearer 69 would be used for signalling and dedicated bearer 65 will be used for data. Mission critical data would also benefit by using QCI 70.


LTE for Public Safety that was published last year provides a good insight on this topic as follows:

The EPS provides IP connectivity between a UE and a packet data network external to the PLMN. This is referred to as PDN connectivity service. An EPS bearer uniquely identifies traffic flows that receive a common QoS treatment. It is the level of granularity for bearer level QoS control in the EPC/E-UTRAN. All traffic mapped to the same EPS bearer receives the same bearer level packet forwarding treatment. Providing different bearer level packet forwarding treatment requires separate EPS bearers.

An EPS bearer is referred to as a GBR bearer, if dedicated network resources related to a Guaranteed Bit Rate (GBR) are permanently allocated once the bearer is established or modified. Otherwise, an EPS bearer is referred to as a non-GBR bearer.

Each EPS bearer is associated with a QoS profile including the following data:
• QoS Class Identifier (QCI): A scalar pointing in the P-GW and eNodeB to node-specific parameters that control the bearer level packet forwarding treatment in this node.
• Allocation and Retention Priority (ARP): Contains information about the priority level, the pre-emption capability, and the pre-emption vulnerability. The primary purpose of the ARP is to decide whether a bearer establishment or modification request can be accepted or needs to be rejected due to resource limitations.
• GBR: The bit rate that can be expected to be provided by a GBR bearer.
• Maximum Bit Rate (MBR): Limits the bit rate that can be expected to be provided by a GBR bearer.

Following QoS parameters are applied to an aggregated set of EPS bearers and are part of user’s subscription data:
• APN Aggregate Maximum Bit Rate (APN-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers and across all PDN connections associated with the APN.
• UE Aggregate Maximum Bit Rate (UE-AMBR): Limits the aggregate bit rate that can be expected to be provided across all non-GBR bearers of a UE. The UE routes uplink packets to the different EPS bearers based on uplink packet filters assigned to the bearers while the P-GW routes downlink packets to the different EPS bearers based on downlink packet filters assigned to the bearers in the PDN connection.

Figure 1.5 above shows the nodes where QoS parameters are enforced in the EPS system.

Related links: