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

Saturday, 24 November 2018

5G Top-10 Misconceptions


Here is a video we did a few weeks back to clear the misconceptions about 5G. The list above summarizes the topics covered.



The video is nearly 29 minutes long. If you prefer a shorter version or are bored of hearing me 😜 then a summary version (just over 3 minutes) is in 3G4G tweet below.


The slides can be downloaded from our Slideshare channel as always.

As always, we love your feedback, even when you strongly disagree.

Other interesting recent posts on 5G:


Monday, 19 November 2018

5G NR Radio Protocols Overview


3GPP held a workshop on 5G NR submission towards IMT-2020 last week. You can access all the agenda, documents, etc. on the 3GPP website here. You can also get a combined version of all presentations from the 3G4G website here. I also wrote a slightly detailed article on this workshop on 3G4G website here.

The following is nice overview of the 5G Radio Interface protocol as defined by 3GPP in NR Rel.15 by Sudeep Palat, Intel. The document was submitted to the 3GPP workshop on ITU submission in Brussels on Oct 24, 2018.



The presentation discusses NR radio interface architecture and protocols for control and user plane; covering RRC, SDAP, PDCP, RLC and MAC, focussing on differences and performance benefits compared to LTE.  RRC states and state transitions with reduced transition delays are also discussed.

Related Posts:

Tuesday, 1 May 2018

MAMS (Multi Access Management Services) at MEC integrating LTE and Wi-Fi networks

Came across Multi Access Management Services (MAMS) a few times recently so here is a quick short post on the topic. At present MAMS is under review in IETF and is being supported by Nokia, Intel, Broadcom, Huawei, AT&T, KT.

I heard about MAMS for the first time at a Small Cell Forum event in Mumbai, slides are here for this particular presentation from Nokia.

As you can see from the slide above, MAMS can optimise inter-working of different access domains, particularly at the Edge. A recent presentation from Nokia (here) on this topic provides much more detailed insight.

From the presentation:

        MAMS (Multi Access Management Services) is a framework for

-            Integrating different access network domains based on user plane (e.g. IP layer) interworking,

-            with ability to select access and core network paths independently

-            and user plane treatment based on traffic types

-            that can dynamically adapt to changing network conditions

-            based on negotiation between client and network
        The technical content is available as the following drafts*



-            MAMS User Plane Specification: https://tools.ietf.org/html/draft-zhu-intarea-mams-user-protocol-02




*Currently under review, Co-authors: Nokia, Intel, Broadcom, Huawei, AT&T, KT,

The slides provide much more details, including the different use cases (pic below) for integrating LTE and Wi-Fi at the Edge.


Here are the references for anyone wishing to look at this in more detail:

Thursday, 12 April 2018

#CWHeritage Talk: The history of synchronisation 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:


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: