5G & Security are both big topics on this blog as well as on 3G4G website. We reached out to 3GPP 5G security by experts from wenovator, Dr. Anand R. Prasad & Hans Christian Rudolph to help out audience understand the mysteries of 5G security. Embedded below is video and slides from a webinar they recorded for us.
You can ask any security questions you may have on the video on YouTube
We looked at Network Data Analytics Function, NWDAF, in detail here. While the 3GPP Release-16 work just starting back then, we have now completed Rel-16 and looking at Release 17.
The 5G Core (5GC) supports the application of analytics to provide Intelligent Automation of the network, In Rel-16 the set of use cases that are proposed for the NWDAF has been widely expanded.
In an earlier post, we looked at the ATIS webinar discussing Release-16 & forthcoming features in Rel-17. Puneet Jain, Director of Technical Standards at Intel and 3GPP SA2 Chairman talked briefly about NWDAF. The following is from his talk:
Release-16 provides support for Network Automation and Data Analytics. Network Data Analytics Function (NWDAF) was defined to provide analytics to 5G Core Network Functions (NFs) and to O&M. It consists of several services that were defined in 3GPP Rel-16 and work is now going in Release 17 to further extend them.
In release 16 Slice load level related network data analytics and observed service experience related network data analytics were defined. NF load analytics as well Network Performance analytics was also specified. NWDAF provides either statistics or prediction on the load communication and mobility performance in the area of interest.
Other thing was about the UE related analytics which includes UE mobility analytics, UE communication analytics, Expected UE behavior parameter, Related network data analytics and abnormal behavior related network data analytics.
The NWDAF can also provide user data congestion related analytics. This can be done by one time reporting or continuous reporting in the form of statistics or prediction or both to any other network function.
QoS sustainability analytics, this is where the consumer of QoS sustainability analytics may request NWDAF analytics information regarding the QoS change statistic for a specific period in the past in a certain area or the likelihood of QoS change for a specific period in future, in certain areas.
In Release 17, studies are ongoing for network automation phase 2. This includes some leftover from Release 16 such as UE driven analytics, how to ensure that slice SLA is guaranteed and then also new functionality is being discussed that includes things like support for multiple NWDAF instance in one PLMN including hierarchies, how to enable real-time or near-real-time NWDAF communications, how to enable NWDAF assisted user pane optimization and last which is very interesting is about interaction between NWDAF and AI model and training service owned by the operator.
This article on TM Forum talks about NWDAF deployment challenges and recommendations:
To deploy NWDAF, CSPs may encounter these challenges:
Some network function vendors may not be standards compliant or have interfaces to provide data or receive analytics services.
Integrating NWDAF with existing analytics applications until a 4G network is deployed is crucial as aggregated network data is needed to make decisions for centralized analytics use cases.
Many CSPs have different analytics nodes deployed for various use cases like revenue assurance, subscriber/marketing analytics and subscriber experience/network management. Making these all integrated into one analytics node also serving NWDAF use cases is key to deriving better insights and value out of network data.
Ensuring the analytics function deployed is integrated to derive value (e.g., with orchestrator for network automation, BI tools/any UI/email/notification apps for reporting).
Here are some ways you can overcome these challenges and deploy efficient next-generation analytics with NWDAF:
Mandate a distributed architecture for analytics too, this reduces network bandwidth overhead due to analytics and helps real-time use cases by design.
Ensure RFPs and your chosen vendors for network functions have, or plan to have, NWDAF support for collecting and receiving analytics services.
Look for carrier-grade analytics solutions with five nines SLAs.
Choose modular analytics systems that can accommodate multiple use cases including NWDAF as apps and support quick development.
Resource-efficient solutions are critical for on-premise or cloud as they can decrease expenses considerably.
Storage comes with a cost, store more processed smart data and not more raw big data unless mandated by law.
In designing an analytics use case, get opinions from both telco and analytics experts, or ideally an expert in both, as they are viewed from different worlds and are evolving a lot.
This is such an important topic that you will hear more about it on this blog and elsewhere.
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.
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.
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).
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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).
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)
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
