UE Radio Capability Signaling Optimization (RACS) in Rel. 16

The data volume of UE Radio Capability Information defined in 3GPP 38.306 is already high and will further increase starting with Rel. 16 due to additional supported bands and other features.

Due to this 3GPP has standardized in Release 16 what is called UE Radio Capability Signaling Optimization (RACS) for both, E-UTRAN/EPS and NG RAN/NGC networks. 

Release 16 RACS does not apply to NB-IoT.

The first key element of this feature set is the introduction of a new UE Radio Capability ID that is structured as defined in 3GPP 23.003 and shown in figure 1 below:

Figure 1: UE Radio Capability ID according to 3GPP 23.003

The components of this new ID are:

•    TF - Type Field (TF): identifies the type of UE radio capability ID.

            Type = 0 -> manufacturer-assigned UE radio capability ID
            Type = 1 -> network-assigned UE radio capability ID

•  The Vendor ID is an identifier of UE manufacturer and only present if TF = 0. The vendor IDs are provided by Internet Assigned Numbers Authority (IANA). The complete list of assigned numbers is publicly available here: https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers

•  The Version ID configured by the UE Capability Management Function (UCMF) that is part of the EPS/5GC. The Version ID value makes it possible to detect whether a UE Radio Capability ID is current or outdated.

·      The Radio Configuration Identifier (RCI) identifies the UE radio configuration.

The PLMN-assigned UE Radio Capability ID is assigned to the UE using the Non-Access Stratum UE Configuration Update Command or Registration Accept message (figure 2).

Figure 2: PLMN-assigned UE Radio Capability Update according to 3GPP 23.743

The new UCMF (UE radio Capability Management Function) stores All UE Radio Capability ID mappings in a PLMN and is responsible for assigning every PLMN-assigned UE Radio Capability ID.

Due to introduction of the UMCM in the core networks the new Nucmf service-based interface is defined for the 5GC and new S17 reference point is defined for the EPS as shown in figure 3.

Figure 3: Network Architecture with UCMF according to 3GPP 21.916

Each UE Radio Capability ID stored in the UCMF can be associated to one or both UE radio capabilities formats specified in 3GPP TS 36.331 [LTE RRC] and 3GPP TS 38.331 [NR RRC]. The AMF must only be able ot handle the NR RRC format while the MME uses the LTE RRC format. Which format is required by the UCMF is configurable.

If at any time the AMF/MME has neither a valid UE Radio Capability ID nor any stored UE radio capabilities for the UE, the AMF/MME may trigger the RAN to provide the UE Radio Capability information and subsequently request the UCMF to allocate a UE Radio Capability ID.

In NG RAN the UE Capability Request can be requested by the AMF as a flag in any NGAP Downlink NAS Transport message or by sending a NGAP UE Radio Capability Check Request (for checking compatibility of IMS voice capabilities). This triggers a NR RRC UE Capability Transfer procedure and subsequently NGAP UE Radio Capability Info Indication or NGAP UE Radio Capability Check Response (for IMS voice support parameters).

Using the NGAP UE Capability ID Mapping procedure the NG RAN node is able to request the most recent UE Capability ID mapping information from the core network functions AMF/UCMF. The same functionality is implemented in S1AP for signaling between eNB and MME/UCMF.

If the volume of the LTE/NR RRC UE Capability to be sent by the UE is larger than the maximum supported size of a PDCP SDU (specified in 3GPP 38.323) then the UE Capability Info can be transported in LTE/NR RRC using a chain of UL Dedicated Message Segment messages.

Figure 4: RRC UL Dedicated Segment Message transporting UE Radio Capability Information according to 3GPP 36.331 and 38.331

Each of these message will have a dedicated segment number and the last one has the rrc-MessageSegmentType =  “lastSegment”, which triggers reassembly of the orignal UE Capabability information in the receiving entity.

Conditional Handover (Rel. 16) Explained

Although a couple of SON mobility robustness features have been introduced in LTE radio networks it is still a common problem in some network areas that a high number of handover failures leads to higher drop rates and large numbers of RRC Re-Establishments.

Often these problems occur due to quickly changing radio conditions in the handover preparation phase or after handover execution attempt. 

SON algorithms cannot cope with these dynamic changes of the environment, but improvement is possible if the UE itself is enabled to constantly monitor the radio quality during the handover procedure and finally select the best possible target cell from a list of candidate neighbors. This new feature defined in 3GPP Release 16 for both, NG RAN (5G SA NR) as well as E-UTRAN (LTE), is called "Conditional Handover". The figure below illustrates how it works.

(click on the picture to enlarge)

Step 1 is the RRC Measurement Report indicating that handover to a neighbor cell is required. However, this message contains a list of candidate neighbor cells.

In the figure it is assumed that each of these candidate cells is controlled by a different gNB. Hence, 3 XnAP Handover Preparation procedures are performed and each potential target gNB allocates radio resources for the UE and provides a handover command (NR RRC Reconfiguration message) that is sent back to the source gNB (step 2).

In step 3 the source gNB builds the conditional handover command, which is a NR RRC Reconfiguration message that contains a list of conditional reconfiguration options plus additional RRC measurement configurations that enable the UE to find out which of the possible target cells is the best fit. 

In step 4 the UE makes its handover decision and moves to the cell controlled by target gNB 1.

Here it sends in step 5 the NR RRC Reconfiguration Complete message. 

The target gNB 1 detects the handover completion based on the reception of the NR RRC Reconfiguration Complete message, performs NGAP Path Switch procedure (not shown in figure) and triggers the release of the UE context in source gNB on behalf of sending the XnAP UE Context Release message (step 6).

With this information the source gNB also detects the successful handover completion and orders in step 7 the release of the radio resources provided by target gNB 2 and 3 to which it sends the new XnAP Conditional Handover Cancel message.

As mentioned before the conditional handover is also possible for LTE radio connections. In this case X2AP is used instead of XnAP and LTE RRC instead of NR RRC.

The conditional handover can be performed for all kind of intra-eNB/gNB handover and X2/Xn handover. However, S1/N2 (NG-C) conditional handover is not allowed.

Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)

It's been just over a year since I wrote a detailed post on what I called '5G and Fixed-Mobile Convergence (FMC)'. The technical term being used in the industry for this feature is Wireless Wireline Convergence (WWC). 

BBF (@Broadband_Forum) has published 3 new standards to accelerate global 5G adoption - https://t.co/ufoHRfK3BE - Wireless Wireline Convergence (#WWC) allows Wi-Fi and other wireline technologies to be part of 5G#Free5Gtraining #5G #5GNetworks #5GTechnology #FMC #5GConvergence pic.twitter.com/OcCyLYix2b

— 5G Training (@5Gtraining) November 26, 2020

Broadband Forum, the communications industry’s leading open standards development organization focused on accelerating broadband innovation, standards, and ecosystem development has just announced the publication of three new standards to accelerate global 5G adoption. The press release said:

Building on the Forum’s mission to drive a future consolidated approach to 5G, the standards will reduce development time, as well as capex and opex, from the traditional disparate fixed broadband and 5G networks. Ultimately, they will deliver a common and managed broadband experience to the end-user whatever the final connectivity technology.

There are three major sets of technical specifications that have been finalized, including 5G Wireless Wireline Convergence Architecture (TR-470), Access Gateway Function (AGF) Functional Requirements (TR-456) and Device Data Model (TR-181). Together, these documents provide functions and interfaces for Fixed Mobile Convergence (FMC), the AGF, and customer premises equipment (CPE) such as 5G-enabled routers.

TR-470 – produced in conjunction with 3GPP – describes the 5G FMC architecture, providing a high-level guide for network architects and planners and enabling fixed and mobile functions to coexist over a shared infrastructure. This will facilitate multi-access connectivity and give consumers a seamless, access-independent service experience.

For operators, the network functions required to operate their infrastructure will be streamlined and common technology, on-boarding, training, services and subscriber management between fixed and mobile divisions can be achieved. Furthermore, additional revenue streams will be created, with FMC extending the geographical reach of 5G core networks and the service offering of fixed networks.

TR-456 describes the functional requirements of the AGF. The AGF resides between fixed access networks and the 5G core network to support 5G and wireline Residential Gateways, creating a truly converged deployment. Alongside this, Broadband Forum’s Device: 2 data model (TR-181 Issue 2 Amendment 14), which is used by User Services Platform (USP), has been extended to address 5G Residential Gateways. The Device: 2 data model applies to all types of TR-069 or USP-enabled devices, including end devices, Residential Gateways, and other network infrastructure devices

In addition, the Functional Requirements for Broadband Residential Gateway Devices (TR-124) specification is expected to be finalized in Q4 2020. Moving from the network into the home, TR-124 has been extended to add requirements related to the 5G Residential Gateway extending the 5G control plane to the premises to open up new service opportunities with real time fulfillment.

In the video below, David Allan, Work Area Director for Wireless-Wireline Convergence at Broadband Forum and Christele Bouchat, Innovation Group Director at Broadband Forum discuss what is coming up in the next phase of 5G work and what opportunities this has opened up for the industry

WWC has a great potential to allow wireline and trusted/untrusted Wi-Fi to work with 5G so I am hopeful that operators will adopt this sooner, rather than later.

Follow the links below to learn more about this feature.

Related Posts:

• Connectivity Technology Blog: 5G Wireline Access Architecture
• The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC)
• The 3G4G Blog: Introduction to 5G ATSSS - Access Traffic Steering, Switching and Splitting
• The 3G4G Blog: Exploring Network Convergence of Mobile, Broadband and Wi-Fi
• Operator Watch Blog: BT's Converged Core to Launch in 2023
• Operator Watch Blog: Jio Makes Another Set of Extremely Bold Announcements 

Business Role Models for Network Slicing and iRAT Mobility for Cellular Internet of Things (CIoT) in Release 16

 3GPP Release 16 describes business role models for network slicing and in TR 21.916 I found the figures below that I have pimped a little bit to illustrate an asset tracking use case for goods transported with a truck from Factory A to Factory B. 

Factory B is equipped with a 5G Non-Public Network (NPN) that broadcasts an NPN-ID or - if the network infrastructure is deployed by an operator - a Cell Access Group ID (CAG ID).

I would like to assume that in case of the scenario shown in 3GPP Figure 2-2 the asset tracking CIoT devices are able to access any necessary PLMN, Network Slice and NPN. This can be achieved e.g. by using an eSIM. 

So while the truck is at the location of Factory A the asset tracking "things" will connect to the private slice of Factory A provided by the operator of PLMN 1. Factory A is a tenant of this operator. This means: Factory A rented a virtual part of PLMN1 for private use and technically this rented virtual network part is realized by a NW slice. 

When the truck leaves Factory A and drives on the road (maybe a long distance) to Factory B the asset tracking data must be transmitted over public mobile network infrastructure. Depending on rural coverage this service can be offered by PLMN 2 (as in case of 3GPP figure 2-2) or by PLMN 1 (as in case of 3GPP figure 2-3).

In case of 3GPP figure 2-4 the operator of PLMN 1 is even able to provide the private slice along the road, which allows Factory A to stretch the coverage of their virtual private network (slice) over a very long distance.

Looking further into the Cellular IoT enhancements defined by 3GPP in Release 16 it turns out that actually there is no need for a nation-wide 5G coverage to realize at least the role models shown in the 3GPP figures 2-2 and 2-3.

Because Release 16 also defines co-existence and inter-RAT mobility between 5G CIoT traffic and 4G NB-IoT the operators of PLMN 1 and PLMN 2 may offer NB-IoT coverage along the road while the factories are covered with 5G NR frequency cells - as shown in my second figure below.  

It illustrates the great improved flexibility that Release 16 standards are offering for customized business solutions and monitoring the service quality is not a trivial task under these circumstances.  

Related Posts:

• The 3G4G Blog: 5G Private and Non-Public Network (NPN)
• The 3G4G Blog: Network Slicing Tutorials and Other Resources 

Positioning Techniques for 5G NR in 3GPP Release-16

I realised that I have not looked at Positioning techniques a lot in our blogs so this one should be a good summary of the latest positioning techniques in 5G.

Qualcomm has a nice short summary here: Release 16 supports multi-/single-cell and device-based positioning, defining a new positioning reference signal (PRS) used by various 5G positioning techniques such as roundtrip time (RTT), angle of arrival/departure (AoA/AoD), and time difference of arrival (TDOA). Roundtrip time (RTT) based positioning removes the requirement of tight network timing synchronization across nodes (as needed in legacy techniques such as TDOA) and offers additional flexibility in network deployment and maintenance. These techniques are designed to meet initial 5G requirements of 3 and 10 meters for indoor and outdoor use cases, respectively. In Release 17, precise indoor positioning functionality will bring sub-meter accuracy for industrial IoT use cases.

I wrote about the 5G Americas white paper titled, "The 5G Evolution: 3GPP Releases 16-17" highlighting new features in 5G that will define the next phase of 5G network deployments across the globe. The following is from that whitepaper:

Release-15 NR provides support for RAT-independent positioning techniques and Observed Time Difference Of Arrival (OTDOA) on LTE carriers. Release 16 extends NR to provide native positioning support by introducing RAT-dependent positioning schemes. These support regulatory and commercial use cases with more stringent requirements on latency and accuracy of positioning.25 NR enhanced capabilities provide valuable, enhanced location capabilities. Location accuracy and latency of positioning schemes improve by using wide signal bandwidth in FR1 and FR2. Furthermore, new schemes based on angular/spatial domain are developed to mitigate synchronization errors by exploiting massive antenna systems.

The positioning requirements for regulatory (e.g. E911) and commercial applications are described in 3GPP TR 38.855. For regulatory use cases, the following are the minimum performance requirements:

• Horizontal positioning accuracy better than 50 meters for 80% of the UEs.
• Vertical positioning accuracy better than 5 meters for 80% of the UEs.
• End-to-end latency less than 30 seconds.

For commercial use cases, for which the positioning requirements are more stringent, the following are the starting-point performance targets

• Horizontal positioning accuracy better than 3 meters (indoors) and 10 meters (outdoors) for 80% of the UEs.
• Vertical positioning accuracy better than 3 meters (indoors and outdoors) for 80% of the UEs.
• End-to-end latency less than 1 second.

Figure 3.11 above shows the RAT-dependent NR positioning schemes being considered for standardization in Release 16:

• Downlink time difference of arrival (DL-TDOA): A new reference signal known as the positioning reference signal (PRS) is introduced in Release 16 for the UE to perform downlink reference signal time difference (DL RSTD) measurements for each base station’s PRSs. These measurements are reported to the location server.
• Uplink time difference of arrival (UL-TDOA): The Release-16 sounding reference signal (SRS) is enhanced to allow each base station to measure the uplink relative time of arrival (UL-RTOA) and report the measurements to the location server.
• Downlink angle-of-departure (DL-AoD): The UE measures the downlink reference signal receive power (DL RSRP) per beam/gNB. Measurement reports are used to determine the AoD based on UE beam location for each gNB. The location server then uses the AoDs to estimate the UE position.
• Uplink angle-of-arrival (UL-AOA): The gNB measures the angle-of-arrival based on the beam the UE is located in. Measurement reports are sent to the location server.
• Multi-cell round trip time (RTT): The gNB and UE perform Rx-Tx time difference measurement for the signal of each cell. The measurement reports from the UE and gNBs are sent to the location server to determine the round trip time of each cell and derive the UE position.
• Enhanced cell ID (E-CID). This is based on RRM measurements (e.g. DL RSRP) of each gNB at the UE. The measurement reports are sent to the location server.

UE-based measurement reports for positioning:

• Downlink reference signal reference power (DL RSRP) per beam/gNB
• Downlink reference signal time difference (DL RSTD)
• UE RX-TX time difference

gNB-based measurement reports for positioning:

• Uplink angle-of-arrival (UL-AoA)
• Uplink reference-signal receive power (UL-RSRP)
• UL relative time of arrival (UL-RTOA)
• gNB RX-TX time difference

NR adopts a solution similar to that of LTE LPPa for Broadcast Assistance Data Delivery, which provides support for A-GNSS, RTK and OTDOA positioning methods. PPP-PTK positioning will extend LPP A-GNSS assistance data message based on compact “SSR messages” from QZSS interface specifications. UE-based RAT-dependent DL-only positioning techniques are supported, where the positioning estimation will be done at the UE-based on assistance data provided by the location server.

Rohde&Schwarz have a 5G overview presentation here. This picture from that presentation is a good summary of the 3GPP Release-16 5G NR positioning techniques. This nice short video on "Release 16 Location Based Services Requirements" complements it very well. 

Related Posts:

• Connectivity Technology Blog: 5G Indoor Precise Positioning
• The 3G4G Blog: R&S Webinar on LTE-A Pro and evolution to 5G

Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G

In this video I explain the principles and signaling procedures related to the DAPS handover.

The DAPS handover is a new feature for URLLC services defined by 3GPP in Rel. 16.

Related Article:

• Techplayon: 5G NR Dual Active Protocol Stack (DAPS) Handover – 3GPP Release 16

5G Enhanced URLLC (eURLLC)

One of the interesting features of 5G is Ultra-Reliability and Low-Latency Communication or URLLC. It has been enhanced as part of 3GPP Release-16. A summary of the changes in eURLLC can be seen in the picture above. 

This ATIS webinar that I blogged about last week covered this topic as well. For example L1/L2 changes have been summarised nicely in this Qualcomm slide above while the slide from Intel speaker below looks at redundant transmission and session continuity.

Redundant transmission in the user plane is an extremely useful feature, especially if the packets are mission critical and have to reach from the source to their destination in a guaranteed time / reliability.

Dual connectivity will enable this redundant path when required to meet a guaranteed reliability. 

Here is a short video from the training company Mpirical, explaining the the 5G eURLLC feature: 

Related Posts:

• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Carrier Aggregation (CA) and Dual Connectivity (DC)
• The 3G4G Blog - Ultra Reliability: 5x9s (99.999%) in 3GPP Release-15 vs 6x9s (99.9999%) in 3GPP Release-16
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: 2-step RACH Enhancement for 5G New Radio (NR) 

ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'

3GPP Organizational Partner, ATIS (Alliance for Telecommunications Industry Solutions), recently delivered a webinar (video & slides below) titled "5G Standards Developments in 3GPP Release 16 and Beyond". 

3GPP News details:

An expert panel brings you up-to-speed on the current state of 5G standardization. The webinar delivers a broad overview of 3GPP's work and introduces some of the key technology elements. It is suitable for people in technical roles and technical executives who want to understand the current state of 5G standardization.

In Release 16, 3GPP delivered important updates to 5G specifications to broaden their range of commercial applications and improve the efficiency of networks. 3GPP is now further enhancing 5G in Release 17 and starting to plan Release 18. This webinar provides an up-to-date view of the completed 3GPP Release 16 work with a particular focus on how the work is expanding capabilities of 5G and enhancing the technical performance of the mobile system. It also looks ahead to future 3GPP deliverables and their use cases.

The webinar features, Iain Sharp, Principal Technologist at ATIS (Moderator), Greg Schumacher, Global Standards at T-Mobile USA and 3GPP SA and SA1 Vice Chairman, Puneet Jain, Director of Technical Standards at Intel and 3GPP SA2 Chairman and Wanshi Chen, Senior Director, Technology at Qualcomm and 3GPP RAN1 Chairman

Many interesting topics have been covered including the updates on mMTC and URLLC. 

There is also details about new features coming in 3GPP Release-17 and an early look at what 3GPP Release-18 might include, as can be seen in the picture above.

Slides are available here and video is embedded below.

Related Posts:

• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: 2-step RACH Enhancement for 5G New Radio (NR)
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System
• The 3G4G Blog: 3GPP MDT - How it works and what is new in Rel. 16
• The 3G4G Blog: Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)
• The 3G4G Blog: Would 5G NSA undergo Sunset? When?
• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC) 

Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)

Back in 2012, we were talking about migration from HLR to HSS. Now we are discussing how to interface HSS to the UDM (Unified Data Management in 5G Core).

In the recent 5G World event, Richard Band, Head of 5G Core, HPE talked about 4G to 5G transition planning. During the talk he mentioned about UDICOM, which is the Standardised new interface between HSS and UDM as defined in 3GPP TS 23.632.

5G Security, Openness, and Trust Considerations: How an open and transparent 5G core design can bolster confidence - A joint paper written by @mobileworldlive and @HPE - https://t.co/XkJHUaaGTM#Free5Gtraining #5G #5GNetwork #5GC #5GCore #HPE #MWL #Security #5GSecurity pic.twitter.com/NWVgnl9INQ

— 5G Training (@5Gtraining) September 6, 2020

UDICOM allows operators to deploy separate HSS and UDM, even from different vendors. Supported features include:

• Authentication
• Single Registration Handover
• IMS
• SMS over NAS

3GPP TS 23.632 (Technical Specification Group Core Network and Terminals; User data interworking, coexistence and migration; Stage 2; Release 16) does not use the term UDICOM. It does however describe the interface details, system architecture, system procedures and network function service procedures of UDM-HSS interface.

As can be seen in the picture above, the following reference points are realized by service-based interfaces:
NU1: Reference point between the HSS and the UDM.
NU2: Reference point between the HSS and the 5GS-UDR.

The following Service based interfaces are defined for direct UDM-HSS interworking:
Nudm: Service-based interface exhibited by UDM.
Nhss: Service-based interface exhibited by HSS.

I am not going in more details here but anyone wanting to learn more about the interface should start with 3GPP TS 23.632.

Finally, this talk from HP Enterprise below provides more details of UDICOM.



Related Posts:

• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• The 3G4G Blog: Two Types of SMS in 5G
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: 5G eXtended Reality (5G-XR) in 5G System (5GS)
• The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC)
• Connectivity Technology Blog: Fixed Wireless Access (FWA) and the Path to 5G Wireless Wireline Convergence (WWC)
• The 3G4G Blog: 5G Network Architecture Options (Updated)
• The 3G4G Blog: What about 5G Network Architecture Option 4 (a.k.a. NE-DC) ?
• The 3G4G Blog: Would 5G NSA undergo Sunset? When?

3GPP MDT - How it works and what is new in Rel. 16

Today I launched my first video. It is about the 3GPP Minimization of Drive Test (MDT) and what is new for this feature in Rel. 16 / 5G networks.

This video explains the overall concept of the MDT feature defined by 3GPP. Individual signaling procedures for immediate and logged mode MDT reporting are presented as well as the latest enhancements for 5G networks defined in 3GPP Release 16.

Enjoy watching

Would 5G NSA undergo Sunset? When?

I have been thinking about the long term evolution of 5G and have now reached the conclusion that it would make sense in the long run to switch off non-standalone 5G. This would of course be only after 5G core has been tested and used extensively. Instead of writing my reasoning, here is a 10 minute video and the corresponding slides.

Opinion: Would 5G NSA undergo Sunset? from 3G4G

Let me know what you think in the comments below. If you agree, when do you think is the best time for 5G NSA Sunset?


Related Posts:

• The 3G4G Blog: 5G Network Architecture Options (Updated)
• The 3G4G Blog: The Politics of Standalone vs Non-Standalone 5G & 4G Speeds
• The 3G4G Blog: What about 5G Network Architecture Option 4 (a.k.a. NE-DC) ?
• Operator Watch Blog: The Many Firsts of STC Kuwait 
• The 3G4G Blog: Service Based Architecture (SBA) for 5G Core (5GC)
• The 3G4G Blog: 5G Dynamic Spectrum Sharing (DSS)
• 3G4G: Free 2G, 3G, 4G & 5G Training Videos
• 3G4G: 5G (IMT-2020) Wireless
• 3G4G: 3GPP 5G Standards and Specifications
• Free 5G Training

Mobile Initiated Connection Only (MICO) mode in 5G System

Mobile Initiated Connection Only (MICO) mode is designed for IoT devices that send small amounts of data and do not need to be paged. An example of this could be a smart bin that sends a message to the waste collection company saying it is 50% full, etc. This way the bin emptying lorry can plan to empty it in the next collection round. Here there is no reason to page the bin as there is no mobile terminated data that would be required.

MICO mode has to be negotiated between the device and AMF in 5GC. A device in MICO mode cannot be paged as it would not listen to paging to conserve battery power. This extreme power saving mode can ensure that the battery can last for very long time, ideally years thereby making this vision of billions of connected IoT devices a reality.

In an earlier post on RRC Inactive state, we looked at NAS states, along with RRC states. When the UE is in MICO mode, the AMF in 5GC will consider the UE to be unreachable when it is in CM-IDLE state. In addition, a periodic registration timer is also allocated to the MICO mode UEs. The UE has to confirm the MICO mode again during registration update.

The video and presentation are embedded below:

Intermediate: Mobile Initiated Connection Only (MICO) from 3G4G

Related Posts:

• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G (IMT-2020) Wireless

Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'

At the TSG#88e Plenary meetings that ended on 03 July 2020, Release 16 was completed with both the Stage 3 freeze and the ASN.1 and OpenAPI specification freeze being approved. The 3GPP Release-16 page has more details on timelines but they may shift. See at the bottom of this post.

Anritsu have uploaded a short presentation on their channel that I am embedding below. I have skipped the beginning part but of you feel like you want to listen, jump to the beginning.




Meanwhile in the recently concluded TSG#88e Plenary meetings, there is a discussion on some of the timelines for Release-17 and Rel-18 moving. This graph below is from SP-200606.

In another piece of 3GPP news, RAN Working Group 6 (WG6 or RAN6) – responsible for the GERAN and UTRAN radio and protocol work - was formally closed.  No new features but specs will be maintained as necessary, of course.

Finally, here is a short video interview by 3GPP in which Balazs Bertenyi looks back at the recent TSG RAN Plenary e-meeting. He talks about the challenges, about IMT-2020, Rel-16 being just on time & the prospects for Rel-17.

Release 16 - RAN progress from 3GPPlive on Vimeo.


Related Posts:

• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G Health & Safety
• 3G4G: 5G (IMT-2020) Wireless
• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: An Introduction to Vehicle to Everything (V2X) and Cellular V2X (C-V2X)
• The 3G4G Blog: A Look into 5G Virtual/Open RAN - Part 6: Inter-gNB CU Handover involving Xn
• The 3G4G Blog: Carrier Aggregation (CA) and Dual Connectivity (DC)
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Embedded SIM (eSIM) and Integrated SIM (iSIM)

5G eXtended Reality (5G-XR) in 5G System (5GS)

We have been meaning to make a tutorial on augmented reality (AR), virtual reality (VR), mixed reality (MR) and extended reality (XR) for a while but we have only managed to do it. Embedded below is video and slides for the tutorial and also a playlist of different use cases on XR from around the world.

If you are not familiar with the 5G Service Based Architecture (SBA) and 5G Core (5GC), best to check this earlier tutorial before going further. A lot of comments are generally around Wi-Fi instead of 5G being used for indoors and we completely agree. 3GPP 5G architecture is designed to cater for any access in addition to 5G access. We have explained it here and here. This guest post also nicely explains Network Convergence of Mobile, Broadband and Wi-Fi.

Intermediate: 5G and Extended Reality (XR) from 3G4G

XR use cases playlist



A lot of info on this topic is from Qualcomm, GSMA, 3GPP and 5G Americas whitepaper, all of them in the links in the slides.


Related Posts:

• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• The 3G4G Blog: 5G and Fixed-Mobile Convergence (FMC)
• The 3G4G Blog: Introduction to 5G ATSSS - Access Traffic Steering, Switching and Splitting
• Guest Post by Ben Toner - Exploring Network Convergence of Mobile, Broadband and Wi-Fi
• Connectivity Technology Blog: 5G Indoor Precise Positioning
• Operator Watch Blog: NTT Docomo presentation on 5G Launch Plans and Use Cases Solutions Partnership
• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G (IMT-2020) Wireless

2-step RACH Enhancement for 5G New Radio (NR)

5G Americas recently published a white paper titled, "The 5G Evolution: 3GPP Releases 16-17" highlighting new features in 5G that will define the next phase of 5G network deployments across the globe. It's available here. One of the sections in that details the 2-step RACH enhancement that is being discussed for a while in 3GPP. The 2-step process would supercede the 4-step process today and would reduce the lartency and optimise the signalling.

The 5G Evolution: 3GPP Releases 16-17 white paper from @5GAmericas highlights specific updates in Releases 16-17. Good whitepaper, worth reading - https://t.co/wVHBj7ZunE #Free5GTraining pic.twitter.com/lshYbzP5ne

— 5G Training (@5Gtraining) January 18, 2020

Here are the details from the 5G Americas whitepaper:

RACH stands for Random Access Channel, which is the first message from UE to eNB when it is powered on. In terms of Radio Access Network implementation, handling RACH design can be one of the most important / critical portions.

The contention-based random-access procedure from Release 15 is a four-step procedure, as shown in Figure 3.12. The UE transmits a contention-based PRACH preamble, also known as Msg1. After detecting the preamble, the gNB responds with a random-access response (RAR), also known as Msg2. The RAR includes the detected preamble ID, a time-advance command, a temporary C-RNTI (TC-RNTI), and an uplink grant for scheduling a PUSCH transmission from the UE known as Msg3. The UE transmits Msg3 in response to the RAR including an ID for contention resolution. Upon receiving Msg3, the network transmits the contention resolution message, also known as Msg4, with the contention resolution ID. The UE receives Msg4, and if it finds its contention-resolution ID it sends an acknowledgement on a PUCCH, which completes the 4-step random access procedure.

The four-step random-access procedure requires two round-trip cycles between the UE and the base station, which not only increases the latency but also incurs additional control-signaling overhead. The motivation of two-step RACH is to reduce latency and control-signaling overhead by having a single round trip cycle between the UE and the base station. This is achieved by combining the preamble (Msg1) and the scheduled PUSCH transmission (Msg3) into a single message (MsgA) from the UE, known as MsgA. Then by combining the random-access respond (Msg2) and the contention resolution message (Msg4) into a single message (MsgB) from the gNB to UE, see Figure 3.13. Furthermore, for unlicensed spectrum, reducing the number of messages transmitted from the UE and the gNB, reduces the number of LBT (Listen Before Talk) attempts.

Design targets for two-step RACH:

• A common design for the three main uses of 5G, i.e. eMBB, URLLC and mMTC in licensed and unlicensed spectrum.
• Operation in any cell size supported in Release 15, and with or without a valid uplink time alignment (TA).
• Applicable to different RRC states, i.e. RRC_INACTIVE, RRC_CONNECTED and RRC_IDLE states.
• All triggers for four-step RACH apply to two-step RACH including, Msg3-based SI request and contention-based beam failure recovery (CB BFR).

As described earlier, MsgA consists of a PRACH preamble and a PUSCH transmission, known as MsgA PRACH and MsgA PUSCH respectively. The MsgA PRACH preambles are separate from the four-step RACH preambles, but can be transmitted in the same PRACH Occasions (ROs) as the preambles of fourstep RACH, or in separate ROs. The PUSCH transmissions are organized into PUSCH Occasions (POs) which span multiple symbols and PRBs with optional guard periods and guard bands between consecutive POs. Each PO consists of multiple DMRS ports and DMRS sequences, with each DMRS port/DMRS sequence pair known as PUSCH resource unit (PRU). two-step RACH supports at least one-to-one and multiple-to-one mapping between the preambles and PRUs.

After the UE transmits MsgA, it waits for the MsgB response from the gNB. There are three possible outcomes:

1. gNB doesn’t detect the MsgA PRACH ➡ No response is sent back to the UE ➡ The UE retransmits MsgA or falls back to four-step RACH starting with a Msg1 transmission.
2. gNB detects MsgA preamble but fails to successful decode MsgA PUSCH ➡ gNB sends back a fallbackRAR to the UE with the RAPID (random-access preamble ID) and an uplink grant for the MsgA PUSCH retransmission ➡ The UE upon receiving the fallbackRAR, falls back to four-step RACH with a transmission of Msg3 (retransmission of the MsgA PUSCH).
3. gNB detects MsgA and successfully decodes MsgA PUSCH ➡ gNB sends back a successRAR to the UE with the contention resolution ID of MsgA ➡ The reception of the successRAR successfully completes the two-step RACH procedure.

As described earlier, MsgB consists of the random-access response and the contention-resolution message. The random-access response is sent when the gNB detects a preamble but cannot successfully decode the corresponding PUSCH transmission. The contention resolution message is sent after the gNB successfully decodes the PUSCH transmission. MsgB can contain backoff indication, fallbackRAR and/or successRAR. A single MsgB can contain the successRAR of one or more UEs. The fallbackRAR consists of the RAPID: an uplink grant to retransmit the MsgA PUSCH payload and time-advance command. The successRAR consists of at least the contention resolution ID, the C-RNTI and the TA command.

For more details on this feature, see 3GPP RP-190711, “2-step RACH for NR” (Work-item description)

5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17

It's been a while since I last wrote about IAB on this blog here. At that time 3GPP Release-16 was being discussed. Since then things have moved on. While Release-16 is being prepared for final release soon, Release-17 study and work items have just been agreed upon.

IAB is included as part of Rel-16 but there isn't a comprehensive document or presentation easily available to details all that it will contain. Similarly the enhancements for Release-17 are available only superficially. Qualcomm is well known for making some really excellent presentations available on 5G. One of their presentations from January (here) has some details on IAB (pg. 32 - 35). There was also an excellent presentation by Navid Abedini, Qualcomm from IEEE Sarnoff Symposium, 2019 which is embedded at the end.

In a 3GPP RAN#84 discussion document RP-191181, Samsung has provided a comprehensive summary of what is being done as part of Rel-16 and what did not make in that:

• Rel-16 IAB aims at basic operations
• Architecture and protocol design
• IAB integration procedure 
• Routing, BAP and BH configuration
• CP and UP data transmission  via IAB
• Topology support: 
• Spanning Tree (ST) and Directed acyclic graph (DAG) 
• Intra-Donor adaptation is prioritized
• The following cannot  be supported in Rel-16
• Mobile IAB
• Topology support: Mesh
• Some functionalities in Rel-16 may not be completed due to time constrains e.g. 
• Topology adaptation between IAB donors
• Mechanisms for efficient control signaling transmission

Ericsson also provides a good summary in RP-190971 regarding Release 16 IAB and Rel-17 enhancements:

• IAB Rel-16 provide basic support for multi-hop and multi-path relaying. 
• The solution supports 
• QoS prioritization of traffic on the backhaul link
• Flexible resource usage between access and backhaul
• Topology adaptivity in case link failure
• In Rel-17 it would be possible to further evolve the IAB solution targeting increased efficiency and support for new use cases

Meanwhile in the recently concluded RAN#86, AT&T provided a good detailed summary on what enhancements are required for IAB as part of Rel-17 in RP-192709

• Duplexing enhancements
• Multiplexing beyond TDM (FDM/SDM/multi-panel Tx/Rx) including multi-parent scenarios, case 6/7 timing alignment, power control/CLI optimizations
• Topology enhancements
• Mobile IAB: CP/UP split + Group mobility 
• Inter-CU topology adaptation
• Mesh-connectivity between IAB nodes for local control/user plane routing
• User plane enhancements
• Multi-hop scheduling enhancement – exchange of benefit metric between IAB nodes to enable radio-aware multi-hop scheduling to improve throughput performance
• Network Coding
• Study benefits compared to duplication over redundant backhaul routes

We will have to wait and see what makes it into the enhancements and what don't. Meanwhile here is a video from Navid Abedini, Qualcomm from IEEE Sarnoff Symposium, 2019




Related Posts:

• Connectivity Technology Blog: Integrated Access and Backhauling (IAB) - Today and Tomorrow
• 5G Evolution with Matthew Baker, Nokia
• Summary of #CWTEC 2019 Conference: 5G, Satellites & Magic MIMO
• 5G and Fixed-Mobile Convergence (FMC)
• R&S Webinar on LTE-A Pro and evolution to 5G
• Introduction to NR-Light a.k.a. NR-Lite
• An Introduction to Non-Terrestrial Networks (NTN)

5G Evolution with Matthew Baker, Nokia

I wrote a summary of CW (Cambridge Wireless) TEC conference here a couple of months back. The last session was on "Getting ready for Beyond-5G Era". Matthew Baker, Head of Radio Physical Layer & Co-existence Standardization, Nokia Bell Labs was one of the speakers. His talk provided a summary of 3GPP Rel-15 and then gave a nice and short summary of all the interesting things coming in Rel-16 and being planned for Rel-17. The slides from his presentation is embedded below:

5G Evolution: Progressive Enhancement & N ew Features for New Markets from 3G4G

Nokia also created a short video where Matthew talks about these new features. It's embedded below:



Related Posts:

• Summary of #CWTEC 2019 Conference: 5G, Satellites & Magic MIMO
• 5G and Fixed-Mobile Convergence (FMC)
• R&S Webinar on LTE-A Pro and evolution to 5G
• Introduction to NR-Light a.k.a. NR-Lite
• An Introduction to Non-Terrestrial Networks (NTN)

Guest Post: Exploring Network Convergence of Mobile, Broadband and Wi-Fi

This is a guest post by Ben Toner, Founder and Director, Numerous Networks

Are multiple networks better than one?

How many articles have you read with a title similar to "Which technology is better, 5G or Wi-Fi6?" If, like me, you regularly use Wi-Fi and cellular (I still use 4G though) then you might find it hard to take sides.

Enter Network Convergence - the concept of bringing multiple networks together to get the best of them all. Imagine, as an end user, not having to decide which network to use but instead feeling satisfied that your data was traversing the best combination of networks at that moment in time.

Imagine a business traveler being connected to Wi-Fi which is slow or busy while trying to take that all important conference call while sitting in an airport. Because you are roaming you want to use that Wi-Fi but you do not want to compromise the video call quality. If your network and device could work together to use just enough cellular data to supplement the slow Wi-Fi so that you stayed within your daily roaming quota but never lost a moment in the video call - then you would probably be very happy with that service. Better still, as you start walking off, if the call transitioned from Wi-Fi to cellular with no dropouts or hangup then you might be delighted!

Earlier I underlined best because that in itself is somewhat complicated.  The example above is easy to desribe but quite hard for to achieve within a framework where all possible scenarios are handled that well, for every user. The common questions which need to be factored into any such choice are:

• What do I as the end user want? 
• What performance can each network deliver. 
• How important is the transfer of content at that time and 
• How much am I willing to pay for it (how many MB of my data plan am I willing to use?). 

This is one of the challenges that we cannot easily solve today, but technology is being developed to help in that process. The operators and device vendors are working within standardisation to develop technology which can provide such a converged service. However at this time there is still a rules mechanism behind it all which does not really describe how user input and preference is going to be captured.

In the last 10 years I have witnessed many battles within service providers when deciding what "one size fits all" service to offer everyone when deciding how to make service provider Wi-Fi available to their customers; all fuelled by my points above.

A lot of concepts are well designed and somewhat mature but deciding exactly what will be implemented in standards is currently ongoing.

In the following slides and video I introduce this whole concept of Network Convergence. The following content introduces the concept and then takes a detailed look at the ATSSS; technology being defined in 3GPP. I also have highlighted the technologoies you can get hold of today to try out network convergence.

I encourage you all to download the example technologies and try convergence for yourself. I'm eager to hear opinions of what technologies work best for each of you. And better still, what is not being provided which you think should be...

Looking forward to your feedback and answering your questions...

Network Convergence of Mobile, Broadband and Wi-Fi from 3G4G

Ben Toner
Founder and Director, Numerous Networks

Related Posts:

• Introduction to 5G ATSSS - Access Traffic Steering, Switching and Splitting
• BT's Converged Core to Launch in 2023
• 5G and Fixed-Mobile Convergence (FMC)
• Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• Updated 5G Terminology Presentation (Feb 2019)