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

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.

    Monday, 1 May 2017

    Variety of 3GPP IoT technologies and Market Status - May 2017



    I have seen many people wondering if so many different types of IoT technologies are needed, 3GPP or otherwise. The story behind that is that for many years 3GPP did not focus too much on creating an IoT variant of the standards. Their hope was that users will make use of LTE Cat 1 for IoT and then later on they created LTE Cat 0 (see here and here).

    The problem with this approach was that the market was ripe for a solution to a different types of IoT technologies that 3GPP could not satisfy. The table below is just an indication of the different types of technologies, but there are many others not listed in here.


    The most popular IoT (or M2M) technology to date is the humble 2G GSM/GPRS. Couple of weeks back Vodafone announced that it has reached a milestone of 50 million IoT connections worldwide. They are also adding roughly 1 million new connections every month. The majority of these are GSM/GPRS.

    Different operators have been assessing their strategy for IoT devices. Some operators have either switched off or are planning to switch off they 2G networks. Others have a long term plan for 2G networks and would rather switch off their 3G networks to refarm the spectrum to more efficient 4G. A small chunk of 2G on the other hand would be a good option for voice & existing IoT devices with small amount of data transfer.

    In fact this is one of the reasons that in Release-13 GSM is being enhanced for IoT. This new version is known as Extended Coverage – GSM – Internet of Things (EC-GSM-IoT ). According to GSMA, "It is based on eGPRS and designed as a high capacity, long range, low energy and low complexity cellular system for IoT communications. The optimisations made in EC-GSM-IoT that need to be made to existing GSM networks can be made as a software upgrade, ensuring coverage and accelerated time to-market. Battery life of up to 10 years can be supported for a wide range use cases."

    The most popular of the non-3GPP IoT technologies are Sigfox and LoRa. Both these technologies have gained significant ground and many backers in the market. This, along with the gap in the market and the need for low power IoT technologies that transfer just a little amount of data and has a long battery life motivated 3GPP to create new IoT technologies that were standardised as part of Rel-13 and are being further enhanced in Rel-14. A summary of these technologies can be seen below


    If you look at the first picture on the top (modified from Qualcomm's original here), you will see that these different IoT technologies, 3GPP or otherwise address different needs. No wonder many operators are using the unlicensed LPWA IoT technologies as a starting point, hoping to complement them by 3GPP technologies when ready.

    Finally, looks like there is a difference in understanding of standards between Ericsson and Huawei and as a result their implementation is incompatible. Hopefully this will be sorted out soon.


    Market Status:

    Telefonica has publicly said that Sigfox is the best way forward for the time being. No news about any 3GPP IoT technologies.

    Orange has rolled out LoRa network but has said that when NB-IoT is ready, they will switch the customers on to that.

    KPN deployed LoRa throughout the Netherlands thereby making it the first country across the world with complete coverage. Haven't ruled out NB-IoT when available.

    SK Telecom completed nationwide LoRa IoT network deployment in South Korea last year. It sees LTE-M and LoRa as Its 'Two Main IoT Pillars'.

    Deutsche Telekom has rolled out NarrowBand-IoT (NB-IoT) Network across eight countries in Europe (Germany, the Netherlands, Greece, Poland, Hungary, Austria, Slovakia, Croatia)

    Vodafone is fully committed to NB-IoT. Their network is already operational in Spain and will be launching in Ireland and Netherlands later on this year.

    Telecom Italia is in process of launching NB-IoT. Water meters in Turin are already sending their readings using NB-IoT.

    China Telecom, in conjunction with Shenzhen Water and Huawei launched 'World's First' Commercial NB-IoT-based Smart Water Project on World Water Day.

    SoftBank is deploying LTE-M (Cat-M1) and NB-IoT networks nationwide, powered by Ericsson.

    Orange Belgium plans to roll-out nationwide NB-IoT & LTE-M IoT Networks in 2017

    China Mobile is committed to 3GPP based IoT technologies. It has conducted outdoor trials of NB-IoT with Huawei and ZTE and is also trialing LTE-M with Ericsson and Qualcomm.

    Verizon has launched Industry’s first LTE-M Nationwide IoT Network.

    AT&T will be launching LTE-M network later on this year in US as well as Mexico.

    Sprint said it plans to deploy LTE Cat 1 technology in support of the Internet of Things (IoT) across its network by the end of July.

    Further reading:

    Saturday, 15 April 2017

    Self-backhauling: Integrated access and backhaul links for 5G


    One of the items that was proposed during the 3GPP RAN Plenary #75 held in Dubrovnik, Croatia, was Study on Integrated Access and Backhaul for NR (NR = New Radio). RP-17148 provides more details as follows:

    One of the potential technologies targeted to enable future cellular network deployment scenarios and applications is the support for wireless backhaul and relay links enabling flexible and very dense deployment of NR cells without the need for densifying the transport network proportionately. 

    Due to the expected larger bandwidth available for NR compared to LTE (e.g. mmWave spectrum) along with the native deployment of massive MIMO or multi-beam systems in NR creates an opportunity to develop and deploy integrated access and backhaul links. This may allow easier deployment of a dense network of self-backhauled NR cells in a more integrated manner by building upon many of the control and data channels/procedures defined for providing access to UEs. An example illustration of a network with such integrated access and backhaul links is shown in Figure 1, where relay nodes (rTRPs) can multiplex access and backhaul links in time, frequency, or space (e.g. beam-based operation).

    The operation of the different links may be on the same or different frequencies (also termed ‘in-band’ and ‘out-band’ relays). While efficient support of out-band relays is important for some NR deployment scenarios, it is critically important to understand the requirements of in-band operation which imply tighter interworking with the access links operating on the same frequency to accommodate duplex constraints and avoid/mitigate interference. 

    In addition, operating NR systems in mmWave spectrum presents some unique challenges including experiencing severe short-term blocking that cannot be readily mitigated by present RRC-based handover mechanisms due to the larger time-scales required for completion of the procedures compared to short-term blocking. Overcoming short-term blocking in mmWave systems may require fast L2-based switching between rTRPs, much like dynamic point selection, or modified L3-based solutions. The above described need to mitigate short-term blocking for NR operation in mmWave spectrum along with the desire for easier deployment of self-backhauled NR cells creates a need for the development of an integrated framework that allows fast switching of access and backhaul links. Over-the-air (OTA) coordination between rTRPs can also be considered to mitigate interference and support end-to-end route selection and optimization.

    The benefits of integrated access and backhaul (IAB) are crucial during network rollout and the initial network growth phase. To leverage these benefits, IAB needs to be available when NR rollout occurs. Consequently, postponing IAB-related work to a later stage may have adverse impact on the timely deployment of NR access.


    There is also an interesting presentation on this topic from Interdigital on the 5G Crosshaul group here. I found the following points worth noting:

    • This will create a new type of interference (access-backhaul interference) to mitigate and will require sophisticated (complex) scheduling of the channel resources (across two domains, access and backhaul).
    • One of the main drivers is Small cells densification calling for cost-effective and low latency backhauling
    • The goal would be to maximize efficiency through joint optimization/integration of access and backhaul resources
    • The existing approach of Fronthaul using CPRI will not scale for 5G, self-backhaul may be an alternative in the shape of wireless fronthaul

    Let me know what you think.

    Related Links:



    Monday, 6 March 2017

    IMT-2020 (5G) Requirements


    ITU has just agreed on key 5G performance requirements for IMT-2020. A new draft report ITU-R M.[IMT-2020.TECH PERF REQ] is expected to be finally approved by  ITU-R Study Group 5 at its next meeting in November 2017. The press release says "5G mobile systems to provide lightning speed, ultra-reliable communications for broadband and IoT"


    The following is from the ITU draft report:

    The key minimum technical performance requirements defined in this document are for the purpose of consistent definition, specification, and evaluation of the candidate IMT-2020 radio interface technologies (RITs)/Set of radio interface technologies (SRIT) in conjunction with the development of ITU-R Recommendations and Reports, such as the detailed specifications of IMT-2020. The intent of these requirements is to ensure that IMT-2020 technologies are able to fulfil the objectives of IMT-2020 and to set a specific level of performance that each proposed RIT/SRIT needs to achieve in order to be considered by ITU-R for IMT-2020.


    Peak data rate: Peak data rate is the maximum achievable data rate under ideal conditions (in bit/s), which is the received data bits assuming error-free conditions assignable to a single mobile station, when all assignable radio resources for the corresponding link direction are utilized (i.e., excluding radio resources that are used for physical layer synchronization, reference signals or pilots, guard bands and guard times). 

    This requirement is defined for the purpose of evaluation in the eMBB usage scenario. 
    The minimum requirements for peak data rate are as follows:
    Downlink peak data rate is 20 Gbit/s.
    Uplink peak data rate is 10 Gbit/s.


    Peak spectral efficiency: Peak spectral efficiency is the maximum data rate under ideal conditions normalised by channel bandwidth (in bit/s/Hz), where the maximum data rate is the received data bits assuming error-free conditions assignable to a single mobile station, when all assignable radio resources for the corresponding link direction are utilized (i.e. excluding radio resources that are used for physical layer synchronization, reference signals or pilots, guard bands and guard times).

    This requirement is defined for the purpose of evaluation in the eMBB usage scenario.
    The minimum requirements for peak spectral efficiencies are as follows: 
    Downlink peak spectral efficiency is 30 bit/s/Hz.
    Uplink peak spectral efficiency is 15 bit/s/Hz.


    User experienced data rate: User experienced data rate is the 5% point of the cumulative distribution function (CDF) of the user throughput. User throughput (during active time) is defined as the number of correctly received bits, i.e. the number of bits contained in the service data units (SDUs) delivered to Layer 3, over a certain period of time.

    This requirement is defined for the purpose of evaluation in the related eMBB test environment.
    The target values for the user experienced data rate are as follows in the Dense Urban – eMBB test environment: 
    Downlink user experienced data rate is 100 Mbit/s
    Uplink user experienced data rate is 50 Mbit/s


    5th percentile user spectral efficiency: The 5th percentile user spectral efficiency is the 5% point of the CDF of the normalized user throughput. The normalized user throughput is defined as the number of correctly received bits, i.e., the number of bits contained in the SDUs delivered to Layer 3, over a certain period of time, divided by the channel bandwidth and is measured in bit/s/Hz. 

    This requirement is defined for the purpose of evaluation in the eMBB usage scenario.
    Indoor Hotspot – eMBB - Downlink: 0.3 bit/s/Hz Uplink: 0.21 bit/s/Hz
    Dense Urban – eMBB - Downlink: 0.225 bit/s/Hz Uplink: 0.15 bit/s/Hz
    Rural – eMBB - Downlink: 0.12 bit/s/Hz Uplink: 0.045 bit/s/Hz


    Average spectral efficiency: Average spectral efficiency  is the aggregate throughput of all users (the number of correctly received bits, i.e. the number of bits contained in the SDUs delivered to Layer 3, over a certain period of time) divided by the channel bandwidth of a specific band divided by the number of TRxPs and is measured in bit/s/Hz/TRxP.

    This requirement is defined for the purpose of evaluation in the eMBB usage scenario.
    Indoor Hotspot – eMBB - Downlink: 9 bit/s/Hz/TRxP Uplink: 6.75 bit/s/Hz/TRxP
    Dense Urban – eMBB - Downlink: 7.8 bit/s/Hz/TRxP Uplink: 5.4 bit/s/Hz/TRxP
    Rural – eMBB - Downlink: 3.3 bit/s/Hz/TRxP Uplink: 1.6 bit/s/Hz/TRxP


    Area traffic capacity: Area traffic capacity is the total traffic throughput served per geographic area (in Mbit/s/m2). The throughput is the number of correctly received bits, i.e. the number of bits contained in the SDUs delivered to Layer 3, over a certain period of time.

    This requirement is defined for the purpose of evaluation in the related eMBB test environment.
    The target value for Area traffic capacity in downlink is 10 Mbit/s/m2 in the Indoor Hotspot – eMBB test environment.


    User plane latency: User plane latency is the contribution of the radio network to the time from when the source sends a packet to when the destination receives it (in ms). It is defined as the one-way time it takes to successfully deliver an application layer packet/message from the radio protocol layer 2/3 SDU ingress point to the radio protocol layer 2/3 SDU egress point of the radio interface in either uplink or downlink in the network for a given service in unloaded conditions, assuming the mobile station is in the active state. 
    This requirement is defined for the purpose of evaluation in the eMBB and URLLC usage scenarios.
    The minimum requirements for user plane latency are
    4 ms for eMBB
    1 ms for URLLC 
    assuming unloaded conditions (i.e., a single user) for small IP packets (e.g., 0 byte payload + IP header), for both downlink and uplink.


    Control plane latency: Control plane latency refers to the transition time from a most “battery efficient” state (e.g. Idle state) to the start of continuous data transfer (e.g. Active state).
    This requirement is defined for the purpose of evaluation in the eMBB and URLLC usage scenarios.
    The minimum requirement for control plane latency is 20 ms. Proponents are encouraged to consider lower control plane latency, e.g. 10 ms.


    Connection density: Connection density is the total number of devices fulfilling a specific quality of service (QoS) per unit area (per km2).

    This requirement is defined for the purpose of evaluation in the mMTC usage scenario.
    The minimum requirement for connection density is 1 000 000 devices per km2.


    Energy efficiency: Network energy efficiency is the capability of a RIT/SRIT to minimize the radio access network energy consumption in relation to the traffic capacity provided. Device energy efficiency is the capability of the RIT/SRIT to minimize the power consumed by the device modem in relation to the traffic characteristics. 
    Energy efficiency of the network and the device can relate to the support for the following two aspects:
    a) Efficient data transmission in a loaded case;
    b) Low energy consumption when there is no data.
    Efficient data transmission in a loaded case is demonstrated by the average spectral efficiency 

    This requirement is defined for the purpose of evaluation in the eMBB usage scenario.
    The RIT/SRIT shall have the capability to support a high sleep ratio and long sleep duration. Proponents are encouraged to describe other mechanisms of the RIT/SRIT that improve the support of energy efficient operation for both network and device.


    Reliability: Reliability relates to the capability of transmitting a given amount of traffic within a predetermined time duration with high success probability

    This requirement is defined for the purpose of evaluation in the URLLC usage scenario. 
    The minimum requirement for the reliability is 1-10-5 success probability of transmitting a layer 2 PDU (protocol data unit) of 32 bytes within 1 ms in channel quality of coverage edge for the Urban Macro-URLLC test environment, assuming small application data (e.g. 20 bytes application data + protocol overhead). 
    Proponents are encouraged to consider larger packet sizes, e.g. layer 2 PDU size of up to 100 bytes.


    Mobility: Mobility is the maximum mobile station speed at which a defined QoS can be achieved (in km/h).

    The following classes of mobility are defined:
    Stationary: 0 km/h
    Pedestrian: 0 km/h to 10 km/h
    Vehicular: 10 km/h to 120 km/h
    High speed vehicular: 120 km/h to 500 km/h

    Mobility classes supported:
    Indoor Hotspot – eMBB: Stationary, Pedestrian
    Dense Urban – eMBB: Stationary, Pedestrian, Vehicular (up to 30 km/h)
    Rural – eMBB: Pedestrian, Vehicular, High speed vehicular 


    Mobility interruption time: Mobility interruption time is the shortest time duration supported by the system during which a user terminal cannot exchange user plane packets with any base station during transitions.

    This requirement is defined for the purpose of evaluation in the eMBB and URLLC usage scenarios.
    The minimum requirement for mobility interruption time is 0 ms.


    Bandwidth: Bandwidth is the maximum aggregated system bandwidth. The bandwidth may be supported by single or multiple radio frequency (RF) carriers. The bandwidth capability of the RIT/SRIT is defined for the purpose of IMT-2020 evaluation.

    The requirement for bandwidth is at least 100 MHz
    The RIT/SRIT shall support bandwidths up to 1 GHz for operation in higher frequency bands (e.g. above 6 GHz). 

    In case you missed, a 5G logo has also been released by 3GPP


    Related posts: