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

Couple of Tutorials on ETSI NFV MANO

The premises of virtualization is to move physical network functions (PNF in hardware) into software and to design them in a way so that they can be deployed on a NFVI (Network Functions Virtualization Infrastructure, a.k.a. the cloud).

MANagement and Orchestration (MANO) is a key element of the ETSI network functions virtualization (NFV) architecture. MANO is an architectural framework that coordinates network resources for cloud-based applications and the lifecycle management of virtual network functions (VNFs) and network services. As such, it is crucial for ensuring rapid, reliable NFV deployments at scale. MANO includes the following components: the NFV orchestrator (NFVO), the VNF manager (VNFM), and the virtual infrastructure manager (VIM).

NFV MANO is broken up into three functional blocks:

• NFV Orchestrator: Responsible for onboarding of new network services (NS) and virtual network function (VNF) packages; NS lifecycle management; global resource management; validation and authorization of network functions virtualization infrastructure (NFVI) resource requests.
• VNF Manager: Oversees lifecycle management of VNF instances; fills the coordination and adaptation role for configuration and event reporting between NFV infrastructure (NFVI) and Element/Network Management Systems.
• Virtualized Infrastructure Manager (VIM): Controls and manages the NFVI compute, storage, and network resources.

For the NFV MANO architecture to work properly and effectively, it must be integrated with open application program interfaces (APIs) in the existing systems. The MANO layer works with templates for standard VNFs and gives users the power to pick and choose from existing NFVI resources to deploy their platform or element.

Couple of good old tutorials, good as gold, explaining the ETSI NFV MANO concept. The videos are embedded below. The slides from the video are probably not available but there are other slides from ETSI here. If you are new to this, this is a good presentation to start with.

NFV MANO Part 1: Overview and VNF Lifecycle Management: Uwe Rauschenbach | Rapporteur | ETSI NFV ISG covers:

• ETSI NFV MANO Concepts
• VNF Lifecycle Management

NFV MANO Part 2: Network Service Lifecycle Management: Jeremy Fuller | Chair, IFA WG | ETSI NFV ISG covers:

• Network Service Lifecycle Management

If you have any better suggestions for the slides / video, please feel free to add in the comments.

Related Posts:

• The 3G4G Blog: What is Cloud Native and How is it Transforming the Networks?

What is Cloud Native and How is it Transforming the Networks?

Cloud native is talked about so often that it is assumed everyone knows what is means. Before going any further, here is a short introductory tutorial here and video by my Parallel Wireless colleague, Amit Ghadge.  

A simple explanation of Cloud Native by Antía Fernández López, Gradiant at @cambwireless #CWTEC #CloudNative #CloudComputing pic.twitter.com/0XkQAPmPNv

— 3G4G (@3g4gUK) September 24, 2020

If instead you prefer a more detailed cloud native tutorial, here is another one from Award Solutions.

Back in June, Johanna Newman, Principal Cloud Transformation Manager, Group Technology Strategy & Architecture at Vodafone spoke at the Cloud Native World with regards to Vodafone's Cloud Native Journey 

Roz Roseboro, a former Heavy Reading analyst who covered the telecom market for nearly 20 years and currently a Consulting Analyst at Light Reading wrote a fantastic summary of that talk here. The talk is embedded below and selective extracts from the Light Reading article as follows:

While vendors were able to deliver some cloud-native applications, there were still problems ensuring interoperability at the application level. This means new integrations were required, and that sent opex skyrocketing.

I was heartened to see that Newman acknowledged that there is a difference between "cloud-ready" and "cloud-native." In the early days, many assumed that if a function was virtualized and could be managed using OpenStack, that the journey was over.

However, it soon became clear that disaggregating those functions into containerized microservices would be critical for CSPs to deploy functions rapidly and automate management and achieve the scalability, flexibility and, most importantly, agility that the cloud promised. Newman said as much, remarking that the jump from virtualized to cloud-native was too big a jump for hardware and software vendors to make.

The process of re-architecting VNFs to containerize them and make them cloud-native is non-trivial, and traditional VNF suppliers have not done so at the pace CSPs would like to see. I reference here my standard chicken and egg analogy: Suppliers will not go through the cost and effort to re-architect their software if there are no networks upon which to deploy them. Likewise, CSPs will not go through the cost and effort to deploy new cloud networks if there is no software ready to run on them. Of course, some newer entrants like Rakuten have been able to be cloud-native out of the gate, demonstrating that the promise can be realized, in the right circumstances.

Newman also discussed the integration challenges – which are not unique to telecom, of course, but loom even larger in their complex, multivendor environments. During my time as a cloud infrastructure analyst, in survey after survey, when asked what the most significant barrier to faster adoption of cloud-native architectures, CSPs consistently ranked integration as the most significant.

Newman spent a little time discussing the work of the Common NFVi Telco Taskforce (CNTT), which is charged with developing a handful of reference architectures that suppliers can then design to which will presumably help mitigate many of these integration challenges, not to mention VNF/CNF life cycle management (LCM) and ongoing operations.

Vodafone requires that all new software be cloud-native – calling it the "Cloud Native Golden Rule." This does not come as a surprise, as many CSPs have similar strategies. What did come as a bit of a surprise, was the notion that software-as-a-service (SaaS) is seen as a viable alternative for consuming telco functions. While the vendor with the SaaS offering may not itself be cloud-native (for example, it could still have hardware dependencies), from Vodafone's point of view, it ends up performing as such, given the lower operational and maintenance costs and flexibility of a SaaS consumption model.

If you have some other fantastic links, videos, resources on this topic, feel free to add in the comments.

Related Posts:

• Operator Watch Blog: The Many Firsts of STC Kuwait
• Operator Watch Blog: Rakuten details its Open RAN and Innovation Journey
• Operator Watch Blog - Rakuten Japan: Transitioning from MVNO to MNO later in 2019

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) 

Reliance Jio and 5G Network Architecture Option 6

Last week I read about Jio looking at 5G Network Architecture Option 6. There were also a few discussions on Twitter with users sounding a bit confused. So here is my attempt to explain what is Option 6. Video and slides embedded below. 

Why does Jio want 5G Network Architecture Option 6? from 3G4G

You can also see this original video where Satish Jamadagni, Vice President - Network Planning Engineering, Head of Standards at Reliance Jio talks about the need for Option 6. 

Feel free to leave your thoughts in the comments below.

Related Posts:

• Operator Watch Blog: Jio going it alone for 5G Development
• Operator Watch Blog: Jio is the Largest Mobile Network in India by Subscriber Numbers
• Operator Watch Blog: Jio Makes Another Set of Extremely Bold Announcements
• 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) ?
• The 3G4G Blog: Would 5G NSA undergo Sunset? When?
• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• 3G4G: Free 2G, 3G, 4G & 5G Training Videos
• 3G4G: 5G (IMT-2020) Wireless
• 3G4G: 3GPP 5G Standards and Specifications
• Free 5G Training

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?

Two Types of SMS in 5G

GSMA recently published updated "5G Implementation Guidelines: SA Option 2". It explains the two types of SMS in 5G, the same way there were 2 types of SMS in LTE.

Within 5GC, SMS Function (SMSF) supports SMS over NAS (SMSoNAS) defined in 3GPP TS 23.501. Besides, SMSoIP can also be considered as IMS based SMS solution under 5G network. SMSoIP can be deployed simultaneously with voice service over IMS to provide both voice and short message service. It is recommended to use SMSoNAS solution if voice services over IMS is not supported or for a 5G data card/Machine Type Communications (MTC)/Non-IMS device without voice service. The network architecture of SMSoIP and SMSoNAS is shown in Figure.

Two Types of SMS in 5G: SMS over NAS (SMSoNAS) & SMS over IP/IMS (SMSoIP / SMSoIMS) - https://t.co/A88ayY8F1x via @3g4gUK #Free5Gtraining #3G4G5G #GSMA #Mpirical #4G #5G #5GNetworks #5Gtechnology #SMS #5GSMS #Messaging #5GMessaging #SMSoNAS #SMSF #SMSoIP #IMS #SMSoIMS pic.twitter.com/ceI7wGEWBt

— Free 5G Training (@5Gtraining) May 31, 2021

Mpirical explains it in the video as embedded below:

You may also find "5G SMS is Very Real and Here to Stay" by William Dudley useful. It covers a lot of technical details and signalling. It's available here.

Related  posts:

• The 3G4G Blog: Mobile Voice Communications is neither Dying, nor Dead!

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