Showing posts with label 3GPP. Show all posts
Showing posts with label 3GPP. Show all posts

Tuesday, 6 February 2018

QUIC - Possibly in 5G, 3GPP Release-16


Over the last year or so, I have heard quite a few discussions and read many articles around why QUIC is so good and why we will replace TCP with QUIC (Quick UDP Internet Connection). One such article talking about QUIC benefits says:

QUIC was initially developed by Google as an alternative transport protocol to shorten the time it takes to set up a connection. Google wanted to take benefits of the work done with SPDY, another protocol developed by Google that became the basis for the HTTP/2 standard, into a transport protocol with faster connection setup time and built-in security. HTTP/2 over TCP multiplexes and pipelines requests over one connection but a single packet loss and retransmission packet causes Head-of-Line Blocking (HOLB) for the resources that were being downloaded in parallel. QUIC overcomes the shortcomings of multiplexed streams by removing HOLB. QUIC was created with HTTP/2 as the primary application protocol and optimizes HTTP/2 semantics.


What makes QUIC interesting is that it is built on top of UDP rather than TCP. As such, the time to get a secure connection running is shorter using QUIC because packet loss in a particular stream does not affect the other streams on the connection. This results in successfully retrieving multiple objects in parallel, even when some packets are lost on a different stream. Since QUIC is implemented in the userspace compared to TCP, which is implemented in the kernel, QUIC allows developers the flexibility of improving congestion control over time, since it can be optimized and better replaced compared to kernel upgrades (for example, apps and browsers update more often than OS updates).

Georg Mayer mentioned about QUIC in a recent discussion with Telecom TV. His interview is embedded below. Jump to 5:25 for QUIC part only

Georg Mayer, 3GPP CT work on 5G from 3GPPlive on Vimeo.

Below are some good references about QUIC in case you want to study further.

Tuesday, 16 January 2018

3GPP-VRIF workshop on Virtual Reality Ecosystem & Standards in 5G

Its been a year since I last posted about Augmented / Virtual Reality Requirements for 5G. The topic of Virtual Reality has since made good progress for 5G. There are 2 technical reports that is looking at VR specifically. They are:

The second one is work in progress though. 

Anyway, back in Dec. 3GPP and Virtual Reality Industry Forum (VRIF) held a workshop on VR Ecosystem & Standards. All the materials, including agenda is available here. The final report is not there yet but I assume that there will be a press release when the report is published.

While there are some interesting presentations, here is what I found interesting:

From presentation by Gordon Castle, Head of Strategy Development, Ericsson





From presentation by Martin Renschler, Senior Director Technology, Qualcomm


For anyone wanting to learn more about 6 degrees of freedom (6- DoF), see this Wikipedia entry. According to the Nokia presentation, Facebook’s marketing people call this “6DOF;” the engineers at MPEG call it “3DOF+.”
XR is 'cross reality', which is any hardware that combines aspects of AR, MR and VR; such as Google Tango.

From presentation by Devon Copley, Former Head of Product, Nokia Ozo VR Platform
Some good stuff in the pres.

From presentation by Youngkwon Lim, Samsung Research America; the presentation provided a link to a recent YouTube video on this presentation. I really liked it so I am embedding that here:



Finally, from presentation by Gilles Teniou, SA4 Vice chairman - Video SWG chairman, 3GPP





You can check and download all the presentations here.

Further Reading:

Sunday, 7 January 2018

Satellites & Non-terrestrial networks (NTN) in 5G


Satellites has been an area of interest of mine for a while as some of you know that I used to work as Satellite Applications & Services Programme manager at techUK. I have written about how I see satellites complementing the mobile networks here and here.

Its good to see that there is some activity in 3GPP going on about satellites & Non-terrestrial networks (NTN) in 5G. While there are some obvious roles that satellites can play (see pic above), the 5G work is looking to cover a lot more topics in details.

3GPP TR 38.913: Study on scenarios and requirements for next generation access technologies looks at 12 different scenarios, the ones relevant to this topic ate Air to ground, Light aircraft and Satellite to terrestrial.
3GPP TR 38.811: Study on New Radio (NR) to support non terrestrial networks (Release 15) covers this topic a bit more in detail. From looking at how satellites and other aerial networks work in general, it looks at the different NTN architecture options as can be seen above.
People looking to study this area in detail should probably start looking at this TR first.

3GPP also released a news item on this topic last week. It also refers to the above TR and a new one for Release 16. The following from 3GPP news:

The roles and benefits of satellites in 5G have been studied in 3GPP Release 14, leading to the specific requirement to support satellite access being captured in TS 22.261 - “Service requirements for next generation new services and markets; Stage 1”, recognizing the added value that satellite coverage brings, as part of the mix of access technologies for 5G, especially for mission critical and industrial applications where ubiquitous coverage is crucial.

Satellites refer to Spaceborne vehicles in Low Earth Orbits (LEO), Medium Earth Orbits (MEO), Geostationary Earth Orbit (GEO) or in Highly Elliptical Orbits (HEO).

Beyond satellites, Non-terrestrial networks (NTN) refer to networks, or segments of networks, using an airborne or spaceborne vehicle for transmission. Airborne vehicles refer to High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) - including tethered UAS, Lighter than Air UAS and Heavier than Air UAS - all operating at altitude; typically between 8 and 50 km, quasi-stationary.

These Non-terrestrial networks feature in TSG RAN’s TR 38.811 “Study on NR to support non-terrestrial networks”. They will:
  • Help foster the 5G service roll out in un-served or underserved areas to upgrade the performance of terrestrial networks
  • Reinforce service reliability by providing service continuity for user equipment or for moving platforms (e.g. passenger vehicles-aircraft, ships, high speed trains, buses)
  • Increase service availability everywhere; especially for critical communications, future railway/maritime/aeronautical communications
  • Enable 5G network scalability through the provision of efficient multicast/broadcast resources for data delivery towards the network edges or even directly to the user equipment


The objective of TR 38.811 is to study channel models, to define the deployment scenarios as well as the related system parameters and to identify and assess potential key impact areas on the NR. In a second phase, solutions for the identified key impacts on RAN protocols/architecture will be evaluated and defined.

A second study item, the “Study on using Satellite Access in 5G” is being addressed in Working Group SA1.  It shall lead to the delivery of the corresponding Technical Report TR 22.822 as part of Release 16.

This study will identify use cases for the provision of services when considering the integration of 5G satellite-based access components in the 5G system. When addressing the integration of (a) satellite component(s), use cases will identify new potential requirements for 5G systems addressing:
  • The associated identification of existing / planned services and the corresponding modified or new requirements
  • The associated identification of new services and the corresponding requirements
  • The requirements on set-up / configuration / maintenance of the features of UE’s when using satellite components related features as well for other components from the 5G system
  • Regulatory requirements when moving to (or from) satellite from (or to) terrestrial networks


You may also like my presentation / video on 'Connectivity on Planes'.

Friday, 22 December 2017

The small detail about 5G you may have missed...


While going through the latest issue of CW Journal, I came across this article from Moray Rumney, Lead Technologist, Keysight. It highlights an interesting point that I missed out earlier that 5G also includes all LTE specifications from Release 15 onwards.

I reached out to our CW resident 3GPP standards expert Sylvia Lu to clarify and received more details.
There is a whole lot of detail available in RP-172789.zip. Here RIT stands for Radio Interface Technology and SRIT for Set of RIT.

In fact at Sylvia clarified, NB-IoT and Cat-M will also be part of the initial IMT-2020 submissions early next year. Thanks Sylvia.


There is also this nice presentation by Huawei in ITU (here) that describes Requirements, Evaluation Criteria and Submission Templates for the development of IMT-2020. It is very helpful in understanding the process.

Coming back to the question I have often asked (see here for example),
1. What features are needed for operator to say they have deployed 5G, and
2. How many sites / coverage area needed to claim 5G rollout

With LTE Release-15 being part of 5G, I think it has just become easy for operators to claim they have 5G.

What do you think?

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:


Tuesday, 5 December 2017

Summary of 3GPP Release-14 Work Items


With all focus on 5G (Release-15), looks like Rel-14 has been feeling a bit neglected. There are some important updates though as it lays foundation for other services.

3GPP used to maintain Release Descriptions here for all different releases but have stopped doing that since 2014. For Release-14, a new document "3GPP TR 21.914: Release 14 Description; Summary of Rel-14 Work Items" is now available here.

An executive summary from the document:

Release 14 focusses on the following items:
  • Improving the Mission Critical aspects, in particular with the introduction of Video and Data services
  • Introducing the Vehicle-to-Everything (V2X) aspects, in particular the Vehicle-to-Vehicle (V2)
  • Improving the Cellular Internet of Things (CIoT) aspects, with 2G, 3G and 4G support of Machine-Type of Communications (MTC)
  • Improving the radio interface, in particular by enhancing the aspects related to coordination with WLAN and unlicensed spectrum
  • A set of uncorrelated improvements, e.g. on Voice over LTE (VoLTE), IMS, Location reporting.


The continuation of this document provides an exhaustive view of all the items specified by 3GPP in Release 14.

I have blogged about the Mission Critical Communications here. 3GPP has also done a webinar on this topic which can be viewed here. I like this slide below that summarizes features in different releases.

Then there are quite a few new features and enhancements for V2X. I have blogged about sidelink and its proposed extensions here.

From the document:

The Work Item on “Architecture enhancements for LTE support of V2X services (V2XARC)”, driven by SA WG2, specifies the V2X architectures, functional entities involved for V2X communication, interfaces, provisioned parameters and procedures in TS 23.285.
Figure above depicts an overall architecture for V2X communication. V2X Control Function is the logical function defined for network related actions required for V2X and performs authorization and provisioning of necessary parameters for V2X communication to the UE via V3 interface.

A UE can send V2X messages over PC5 interface by using network scheduled operation mode (i.e. centralized scheduling) and UE autonomous resources selection mode (i.e. distributed scheduling) when the UE is "served by E-UTRAN" while a UE can send V2X messages over PC5 interface only by using UE autonomous resources selection mode when the UE is "not served by E-UTRAN". 

Both IP based and non-IP based V2X messages over PC5 are supported. For IP based V2X messages over PC5, only IPv6 is used. PPPP (ProSe Per-Packet Priority) reflecting priority and latency for V2X message is applied to schedule the transmission of V2X message over PC5.

A UE can send V2X messages over LTE-Uu interface destined to a locally relevant V2X Application Server, and the V2X Application Server delivers the V2X messages to the UE(s) in a target area using unicast delivery and/or MBMS (Multimedia Broadcast/Multicast Service) delivery.

Both IP based and non-IP based V2X messages are supported for V2X communication over LTE-Uu. In order to transmit non-IP based V2X messages over LTE-Uu, the UE encapsulates the V2X messages in IP packets.

For latency improvements for MBMS, localized MBMS can be considered for localized routing of V2X messages destined to UEs.

For V2X communication over LTE-Uu interface, the V2X messages can be delivered via Non-GBR bearer (i.e. an IP transmission path with no reserved bitrate resources) as well as GBR bearer (i.e. an IP transmission path with reserved (guaranteed) bitrate resources). In order to meet the latency requirement for V2X message delivery, the following standardized QCI (QoS Class Identifier) values defined in TS 23.203 can be used:
  • QCI 3 (GBR bearer) and QCI 79 (Non-GBR bearer) can be used for the unicast delivery of V2X messages.
  • QCI 75 (GBR bearer) is only used for the delivery of V2X messages over MBMS bearers. 


There are updates to cellular IoT (CIot) which I have blogged about here.

There are some other interesting topic that are enhanced as part of Release14. Here are some of them:
  • S8 Home Routing Architecture for VoLTE
    • Robust Call Setup for VoLTE subscriber in LTE
    • Enhancements to Domain Selection between VoLTE and CDMA CS
    • MBMS improvements
    • eMBMS enhancements for LTE
    • IMS related items
    • Evolution to and Interworking with eCall in IMS
    • Password-based service activation for IMS Multimedia Telephony service
    • Multimedia Priority Service Modifications
    • Enhancements to Multi-stream Multiparty Conferencing Media Handling
    • Enhancement for TV service
    • Improved Streaming QoE Reporting in 3GPP (IQoE)
    • Quality of Experience (QoE) Measurement Collection for streaming services in UTRAN
    • Development of super-wideband and fullband P.835
    • Enhancements to User Location Reporting Support
    • Enhancing Location Capabilities for Indoor and Outdoor Emergency Communications
    • Further Indoor Positioning Enhancements for UTRA and LTE
    • Improvements of awareness of user location change
    • Terminating Access Domain Selection (T-ADS) supporting WLAN Access
    • Enhanced LTE-WLAN Aggregation (LWA)
    • Enhanced LTE WLAN Radio Level Integration with IPsec Tunnel (eLWIP)
    • Positioning Enhancements for GERAN
    • New GPRS algorithms for EASE
    • RRC optimization for UMTS
    • Multi-Carrier Enhancements for UMTS
    • DTX/DRX enhancements in CELL_FACH
    • LTE radio improvements
    • Enhancements on Full-Dimension (FD) MIMO for LTE
    • Downlink Multiuser Superposition Transmission for LTE
    • Performance enhancements for high speed scenario in LTE
    • Control and User Plane Separation (CUPS) of EPC nodes
    • Paging Policy Enhancements and Procedure
    • Shared Subscription Data Update
    • Service Domain Centralization
    • Control of Applications when Third party Servers encounter difficulties
    • PS Data Off Services
    • Enhancement to Flexible Mobile Service Steering 
    • Sponsored data connectivity improvements
    • Group based enhancements in the network capability exposure functions
    • Improved operator control using new UE configuration parameters
    • Charging and OAM stand alone improvements
    • Rel-14 Charging
    • ...

    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 with video embedded below. If for some reason you prefer direct link to video, its here.



    See also:

    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.

    Tuesday, 26 September 2017

    5G Dual Connectivity, Webinar and Architecture Overview

    One of the things that will come as a result of NSA (Non-StandAlone) architecture will be the option for Dual Connectivity (DC). In fact, DC was first introduced in LTE as part of 3GPP Release 12 (see 3G4G Small Cells blog entry here). WWRF (Wireless World Research Forum) has a good whitepaper on this topic here and NTT Docomo also has an excellent article on this here.

    A simple way to understand the difference between Carrier Aggregation (CA) and Dual Connectivity (DC) is that in CA different carriers are served by the same backhaul (same eNB), while in DC they are served by different backhauls (different eNB or eNB & gNB).


    We have produced a short video showing different 5G architectures, looking mainly at StandAlone (SA) and Non-StandAlone (NSA) architectures, both LTE-Assisted and NR-Assisted. The video is embedded below:



    Finally, 3GPP has done a short webinar with the 3GPP RAN Chairman Balazs Bertenyi explaining the outcomes from RAN#77. Its available on BrightTalk here. If you are interested in the slides, they are available here.

    Related posts:

    Tuesday, 25 July 2017

    5G Security Updates - July 2017


    Its been nearly 2 years since I last blogged about ETSI Security workshop. A lot has changed since then, especially as 5G is already in the process of being standardised. This is in addition to NFV / SDN that also applied to 4G networks.

    ETSI Security Week (12 - 16 June) covered lot more than 5G, NFV, SDN, etc. Security specialists can follow the link to get all the details (if they were not already aware of).

    I want to quickly provide 3 links so people can find all the useful information:

    NFV Security Tutorialdesigned to educate attendees on security concerns facing operators and providers as they move forward with implementing NFV. While the topics are focused on security and are technical in nature we believe any individual responsible for designing, implementing or operating a NFV system in an organization will benefit from this session. Slides here.

    NFV Security: Network Functions Virtualization (NFV), leveraging cloud computing, is set to radically change the architecture, security, and implementation of telecommunications networks globally. The NFV Security day will have a sharp focus on the NFV security and will bring together the world-wide community of the NFV security leaders from the industry, academia, and regulators. If you want to meet the movers and shakers in this field, get a clear understanding of the NFV security problems, challenges, opportunities, and the state of the art development of security solutions, this day is for you. Slides here.



    5G Security: The objectives of this event are to:
    • Gather different actors involved in the development of 5G, not only telecom, and discuss together how all their views will shape together in order to understand the challenges, threats and the security requirements that the 5G scenarios will be bringing.
    • Give an update of what is happening in:
      • 5G security research: Lot of research is on-going on 5G security and several projects exist on the topic.
      • 5G security standards: Standardization bodies have already started working 5G security and their work progress will be reviewed. Also any gap or additional standardization requirements will be discussed.
      • Verticals and business (non-technical) 5G security requirements: 5G is playground where different verticals besides the telecom industry is playing a role and their requirements will be key for the design of 5G security. In addition 5G is where "security" will become the business driver.
    • Debate about hot topics such as: IoT security, Advances in lightweight cryptography, Slicing security. Privacy. Secure storage and processing. Security of the interconnection network (DIAMETER security). Relevance of Quantum Safe Cryptography for 5G, Authorization concepts....
    Slides for 5G Security here.

    In addition, Jaya Baloo, CISO, KPN Telecom talks about 5G network security at TechXLR8 2017. Embedded is a video of that:


    Tuesday, 27 June 2017

    Mission Critical Services update from 3GPP - June 2017


    3GPP has published an overview of what has been achieved so far in the Mission Critical and also provides an outlook of what can be expected in the near future. A more detailed paper summarizing the use cases and functional aspects of Rel-13, Rel-14 and upcoming Rel-15 will be published later this year.

    Mission Critical Services – Detailed List of Rel-13, Rel-14 and Rel-15 Functionalities

    Rel-13 MCPTT (completed 2016)
    • User authentication and service authorization
    • Configuration
    • Affiliation and de-affiliation
    • Group calls on-network and off-network (within one system or multiple systems, pre-arranged or chat model, late entry, broadcast group calls, emergency group calls, imminent peril group calls, emergency alerts)
    • Private calls on-network and off-network (automatic or manual commencement modes, emergency private calls)
    • MCPTT security
    • Encryption (media and control signalling)
    • Simultaneous sessions for call
    • Dynamic group management (group regrouping)
    • Floor control in on-network (within one system or across systems) and in off-network
    • Pre-established sessions
    • Resource management (unicast, multicast, modification, shared priority)
    • Multicast/Unicast bearer control, MBMS (Multimedia Broadcast/Multicast Service) bearers
    • Location configuration, reporting and triggering
    • Use of UE-to-network relays
    Rel-14 MC Services (completed 2017)
    MC Services Common Functionalities:
    • User authentication and service authorization
    • Service configuration
    • Affiliation and de-affiliation
    • Extended Location Features
    • (Dynamic) Group Management
    • Identity management
    • MC Security framework
    • Encryption (media and control signalling)
    MCPTT Enhancements:
    • First-to-answer call setup (with and without floor control)
    • Floor control for audio cut-in enabled group
    • Updating the selected MC Service user profile for an MC Service
    • Ambient listening call
    • MCPTT private call-back request
    • Remote change of selected group
    MCVideo, Common Functions plus:
    • Group Call (including emergency group calls, imminent peril group calls, emergency alerts)
    • Private Call (off-network)
    • Transmission Control
    MCData, Common Functions plus:
    • Short Data Service (SDS)
    • File Distribution (FD) (on-network)
    • Transmission and Reception Control
    • Handling of Disposition Notifications
    • Communication Release
    Rel-15 MC Services (in progress)

    MC Services Common Functionalities Enhancements:
    • Enhanced MCPTT group call setup procedure with MBMS bearer
    • Enhanced Location management, information and triggers
    • Interconnection between 3GPP defined MC systems
    • Interworking with legacy systems

    MCPTT Enhancements:
    • Remotely initiated MCPTT call
    • Enhanced handling of MCPTT Emergency Alerts
    • Enhanced Broadcast group call
    • Updating pre-selected MC Service user profile
    • Temporary group call - user regroup
    • Functional alias identity for user and equipment
    • Multiple simultaneous users
    MCVideo Additions:
    • Video push
    • Video pull
    • Private call (on-network)
    • Broadcast Group Call
    • Ambient Viewing Call
    • Capability information sharing
    • Simultaneous Sessions
    • Use of MBMS transmission
    • Emergency and imminent peril private communications
    • Primary and Partner MC system interactions for MCVideo communications
    • Remote video parameters control capabilities

    MCData Additions:
    • MCData specific Location
    • Enhanced Status
    • Accessing list of deferred communications
    • Usage of MBMS
    • Emergency Alert
    • Data streaming
    • File Distribution (FD) (off-network)
    • IP connectivity

    Release-14 features will be available by end of September 2017 and many Release-15 features, that is being hurried due to 5G will be available by June 2018.

    For more details, follow the links below:



    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.