Short Tutorial on Mission Critical Services in LTE and 5G

Over the years we have looked at the standards development, infrastructure development and even country specific mission critical solutions development in various blog posts. In this post we are sharing this short new tutorial by Mpirical on mission critical services in LTE and 5G. The video is embedded below:

Related Posts: 

• The 3G4G Blog: Maritime Communication (MARCOM) Services over 3GPP system
• The 3G4G Blog: Update from 3GPP on LTE & 5G Mission Critical Communications
• The 3G4G Blog: Mission Critical Services update from 3GPP - June 2017
• The 3G4G Blog: QCI Enhancements For Mission Critical Communications
• The 3G4G Blog: Virve 2.0 - Finland's 4G/5G Public Safety Network
• Connectivity Technology Blog: Virve 2.0 is becoming a broad-band service
• Telecoms Infrastructure Blog: T-Mobile USA's Disaster Response Satellite Vehicles, Drones and COWs
• Telecoms Infrastructure Blog: THOR - Verizon's Disaster Response COW
• The 3G4G Blog: A practical use of MOCN in ESN
• Telecoms Infrastructure Blog: Meshing for BYOC (Bring Your Own Coverage)
• The 3G4G Blog: 3GPP Release 17 Description and Summary of Work Items 

UE Assistance Information in LTE and 5G

I have been asked about the UE Assistance Information (UAI) RRC message a few times before. Generally I have always pointed people back to the LTE/5G specifications but here is a concise video that the telecoms technology training company Mpirical have shared recently:

If you want to dig further into details then please see the RRC specifications: 36.331 for LTE and 38.331 for 5G. 

Over the years I have added quite a few short tutorials from Mpirical on this blog, do check them out below.

Related Posts: 

• The 3G4G Blog: EPS Fallback Mechanism in 5G Standalone Networks
• The 3G4G Blog: Is there a compelling Business Case for 5G Network Slicing in Public Networks?
• The 3G4G Blog: IP Multimedia Subsystem (IMS) Support for Service Based Architecture (SBA)
• The 3G4G Blog: Network Slicing using User Equipment Route Selection Policy (URSP)
• The 3G4G Blog: 5G User Plane Redundancy
• The 3G4G Blog: 5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD
• The 3G4G Blog: 5G Enhanced URLLC (eURLLC)
• The 3G4G Blog: Two Types of SMS in 5G
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: CUPS for Flexible U-Plane Processing Based on Traffic Characteristics
• The 3G4G Blog: Tutorial on 4G/5G Mobile Network Uplink Working and Challenges
• The 3G4G Blog: Open RAN Terminology and Players
• 3G4G: Free 2G, 3G, 4G & 5G Training Videos 

Small Data Transmission (SDT) in LTE and 5G NR

One of the features that was introduced part of 5G NR 3GPP Release 17 is known as Small Data Transmission (SDT). When small amount of data, in case of an IoT device, needs to be sent, there is no need to establish data radio bearers. The information can be sent as part of signalling message. A similar approach is available in case of 4G LTE. 

Quoting from Ofinno whitepaper 'Small Data Transmission: PHY/MAC', 

The SDT in the 3GPP simply refers to data transmission in an inactive state. Specifically, the SDT is a transmission for a short data burst in a connectionless state where a device does not need to establish and teardown connections when small amounts of data need to be sent.

In the 3GPP standards, the inactive state had not supported data transmission until Release 15. The 3GPP standards basically allowed the data transmission when ciphering and integrity protection are achieved during the connection establishment procedure. Therefore, the data transmission can occur after the successful completion of the establishment procedure between the device and network.

The problem arises as a device stays in the connected state for a short period of time and subsequently releases the connection once the small size data is sent. Generally, the device needs to perform multiple transmissions and receptions of control signals to initiate and maintain the connection with a network. As a payload size of the data is relatively smaller compared with the amounts of the control signals, making a connection for the small data transmission becomes more of a concern for both the network and the device due to the control signaling overhead.

The 3GPP has developed the SDT procedure to enable data transmission in the inactive state over the existing LTE and NR standards. The device initiates the SDT procedure by transmitting an RRC request message (e.g., SDT request message) and data in parallel instead of transmitting the data after the RRC request message processed by a network. Additional transmission and/or reception are optional. The device performs this SDT procedure without transition to the connected state (i.e., without making a connection to the network).

The SDT enables for the network to accept data transmission without signaling intensive bearer establishment and authentication procedure required for the RRC connection establishment or resume procedure. For example, in the SDT procedure, the device needs only one immediate transmission of a transport block (TB) that contains data and RRC request message. Furthermore, the device does not need to perform procedures (e.g., radio link monitoring) defined in the connected state since the RRC state is kept as the inactive state. This results in improving the battery life of the device by avoiding control signaling unnecessary for transmission of small size data.

The principle of the SDT is very simple. The network configures radio resources beforehand for the data transmission in the inactive state. For example, if the conditions to use the configured radio resources satisfy, the device transmits data and the RRC request message together via the configured radio resources. In the 3GPP standards, there are two types of the SDT depending on the ways to configure the radio resources: (1) SDT using a random access (RA) and (2) SDT using preconfigured radio resources. 

Figure 2 (top) illustrates different types of the SDT referred in 3GPP LTE and NR standards. The SDT using the random access in LTE and NR standards is referred to as an EDT (early data transmission) and RA-SDT (Random Access based SDT), respectively. For both the EDT and the RA-SDT, the device performs data transmission using shared radio resources of the random access procedure. Thus, the contention with other devices can occur over the access to the shared radio resources. The shared radio resources for the SDT are broadcast by system information and are configured as isolated from the one for a nonSDT RA procedure, i.e., the legacy RA procedure. On the other hands, the CG-SDT uses the preconfigured radio resources dedicated to the device. The SDT using the preconfigured radio resource is referred to as transmission via PUR (Preconfigured Uplink Resource) in the LTE standards. The NR standards refers the SDT using the preconfigured radio resource as CG-SDT (Configured Grant based SDT). The network configures the configuration parameters of the preconfigured radio resources when transiting the device in the connected state to the inactive state. For example, an RRC release message transmitted from the network for a connection release contains the configuration parameters of PUR or CG-SDT. No contention is expected for the SDT using the preconfigured radio resource since the configuration parameters are dedicated to the device. 

You can continue reading the details in whitepaper here. Ofinno has another whitepaper on this topic, 'Small Data Transmission (SDT): Protocol Aspects' here.

3GPP also recently published an article on this topic here. Quoting from the article:

With SDT it is possible for the device to send small amounts of data while remaining in the inactive state. Note that this idea resembles the early GSM systems where SMS messages where sent via the control signalling; that is, transferring small amounts of data while the mobile did not have a (voice) connection.

SDT is a procedure which allows data and/or signalling transmission while the device remains in inactive state without transitioning to connected state. SDT is enabled on a radio bearer basis and is initiated by the UE only if less than a configured amount of UL data awaits transmission across all radio bearers for which SDT is enabled. Otherwise the normal data transmission scheme is used.

With SDT the data is transmitted quickly on the allocated resource. The IoT device initiates the SDT procedure by transmitting an RRC request message and payload data in parallel, instead of the usual procedure where the data is transmitted after the RRC request message is processed by a network.

It is not only the speed and the reduced size of the transmitted data which make SDT such a suitable process for IoT devices. Since the device stays in the inactive state, it does not have to perform many tasks associated with the active state. This further improves the battery life of the IoT device. Additional transmission and/or reception are optional.

There are two ways of performing SDT:

1. via random access (RA-SDT)
2. via preconfigured radio resources (CG-SDT)

Random Access SDT

With RA-SDT, the IoT device does not have a dedicated radio resource, and it is possible that the random access message clashes with similar RA-SDT random access messages from other IoT devices. The device gets to know the radio resources for the RA procedure from system information messages, in a similar way to non RA-SDT devices. However, the RA radio resources for SDT and non SDT devices are kept separate; that is, these device types do not interfere with each other in random access

The RA-SDT procedure can be a two-step or a four-step random access procedure. In two-step procedure the payload data is already sent with the initial random access message, whereas in four-step procedure the device first performs contention resolution with the random access request - random access response message pair, and then sends the UL payload with RRC Resume Request. The procedure may continue with further uplink and downlink small data transmissions, and then it is terminated with an RRC Release from the network.

Below are the signalling diagrams for both two-step and four-step RA-SDT procedures. Note that in both cases the UE stays in the RRC inactive state during the whole process.

Configured Grant SDT

For CG-SDT, the radio resources are allocated periodically based on the estimation of the UE’s traffic requirements. This uplink scheduling method is called Configured Grant (CG). With CG-SDT there will be no message clashes with other IoT devices since the radio resources are dedicated for each device. The resource allocation is signalled to the IoT device by the network when the device leaves the connected state.

If the amount of data in the UE's tx buffer is larger than a defined limit, then the data transmission is done using the normal non-SDT procedure.

For SDT process, the device selects the CG-SDT as the SDT type if the resources for the CG-SDT are configured on the selected uplink carrier. If the resources for the CG-SDT are unavailable or invalid, the RA-SDT or the non-SDT RA procedure will be chosen if those are configured. If no SDT type configuration is available then a normal non-SDT data transmission is performed.

With IoT devices proliferating, it makes sense to optimise data transfer and anything else that will reduce the power consumption and let the battery in the devices last for much longer.

Related Posts: 

• The 3G4G Blog: 3GPP Release 17 Description and Summary of Work Items
• The 3G4G Blog: A Technical Introduction to 5G NR RRC Inactive State
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System
• The 3G4G Blog: Four Ways 5G Can Improve the Battery Life of User Equipment (UE)
• The 3G4G Blog: Energy Consumption in Mobile Networks and RAN Power Saving Schemes
• The 3G4G Blog: Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)
• The 3G4G Blog: Are there 50 Billion IoT Devices yet?
• The 3G4G Blog: 5G Non IP Data Delivery and Lightweight M2M (LwM2M) over NIDD
• The 3G4G Blog: Introduction to 5G Reduced Capability (RedCap) Devices
• The 3G4G Blog: Embedded SIM (eSIM) and Integrated SIM (iSIM)
• Connectivity Technology Blog: Is LTE Cat 1bis Uniting the Fragmented Cellular IoT Market? 

DCCA Features and Enhancements in 5G New Radio

In another new whitepaper on 5G-Advanced, Nokia has detailed DCCA (DC + CA) features and enhancements from Rel-15 until Rel-18. The following is an extract from the paper:

Mobility is one of the essential components of 5G-Advanced. 3GPP has already defined a set of functionalities and features that will be a part of the 5G-Advanced Release 18 package. These functionalities can be grouped into four areas: providing new levels of experience, network extension into new areas, mobile network expansion beyond connectivity, and providing operational support excellence. Mobility enhancements in Release 18 will be an important part of the ‘Experience enhancements” block of features, with the goal of reducing interruption time and improving mobility robustness.

Fig. 2 shows a high-level schematic of mobility and dual connectivity (DC)/Carrier Aggregation (CA) related mechanisms that are introduced in the different 5G legacy releases towards 5G-Advanced in Release 18. Innovations such as Conditional Handover (CHO) and dual active protocol stack (DAPS) are introduced in Release 16. More efficient operation of carrier aggregation (CA), dual connectivity (DC), and the combination of those denoted as DCCA, as well as Multi-Radio Access Technology DC (MR-DC) are introduced through Releases 16 and 17.

For harvesting the full benefits of CA/DC techniques, it is important to have an agile framework where secondary cell(s) are timely identified and configured to the UE when needed. This is of importance for non-standalone (NSA) deployments where a carrier on NR should be quickly configured and activated to take advantage of 5G. Similarly, it is of importance for standalone (SA) cases where e.g. a UE with its Primary Cell (PCell) on NR Frequency Range 1 (FR1) wants to take additional carriers, either on FR1 and/or FR2 bands, into use. Thus, there is a need to support cases where the aggregated carriers are either from the same or difference sites. The management of such additional carriers for a UE shall be highly agile in line with the user traffic and QoS demands; quickly enabling usage of additional carriers when needed and again quickly released when no longer demanded to avoid unnecessary processing at the UE and to reduce its energy consumption. This is of particular importance for users with time-varying traffic demands (aka burst traffic conditions).

In the following, we describe how such carrier management is gradually improved by introducing enhancements for cell identification, RRM measurements and reduced reporting delays from UEs. As well as innovations related to Conditional PSCell Addition and Change (CPAC) and deactivation of secondary cell groups are outlined.

The paper goes on to discuss the following scenarios in detail for DCCA enhancements:

• Early measurement reporting
• Secondary cell (SCell) activation time improvements
• Direct SCell activation
• Temporary RS (TRS)-based SCell Activation
• Conditional Secondary Node (SN) addition and change for fast access
• Activation of secondary cell group

The table below summarizes the DCCA features in 5G NR

Related Posts: 

• The 3G4G Blog: ATIS Webinar on '5G Standards Development Update in 3GPP Release 17 and 18'
• The 3G4G Blog: 3GPP's 5G-Advanced Workshop Summary
• The 3G4G Blog: What Is the Role of AI and ML in the Open RAN and 5G Future?
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G
• Free 6G Training: Deep Learning in the 6G Air Interface
• Free 6G Training: Kyocera Develops Transmissive Metasurface Technology for B5G and 6G
• Free 6G Training: 6G and B5G Prospects for Vertical Industry
• Free 6G Training: The Potential of Full Duplex in Beyond 5G and 6G
• Free 6G Training: Using a Dielectric Waveguide as a Pinching Antenna for B5G and 6G 

Managing 5G Signalling Storms with Service Communication Proxy (SCP)

When we made our 5G Service Based Architecture (SBA) tutorial some four years back, it was based on Release-15 of the 3GPP standards. All Network Functions (NFs) simply sent discovery requests to the Network Repository Function (NRF). While this works great for trials and small scale deployments it can also lead to issues as can be seen in the slide above.

In 3GPP Release-16 the Service Communication Proxy (SCP) has now been introduced to allow the Control Plane network to handle and prioritize massive numbers of requests in real time. The SCP becomes the control point that mediates all Signalling and Control Plane messages in the network core.

SCP routing directs the flow of millions of simultaneous 5G function requests and responses for network slicing, microservice instantiation or edge compute access. It also plays a critical role in optimizing floods of discovery requests to the NRF and in overall Control Plane load balancing, traffic prioritization and message management.

A detailed whitepaper on '5G Signaling and Control Plane Traffic Depends on Service Communications Proxy (SCP)' by Strategy Analytics is available on Huawei's website here. This report was a follow on from the 'Signaling — The Critical Nerve Center of 5G Networks' webinar here.

Related Posts:

• 3G4G: 5G Service Based Architecture (SBA)
• The 3G4G Blog: Interfacing HSS and UDM in 5GS with UDICOM (a.k.a NU1 / Nhss)
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Everything you need to know about 5G Security
• 3G4G: 3GPP 5G Specifications

Will Wi-Fi Help 3GPP Bring Reliable Connectivity Indoors?

I have argued a few times now that it would make much more sense to be able to make access and core independent of each other. 3GPP 5G Standards already have a feature available from Release-16 onwards that enables this with 5G Core, Standalone networks.

We use our smart devices currently for voice and data communications. When we are indoor, many times the data goes over Wi-Fi. This is what tempted operators to move to WiFi for voice solution as well. Many operators are now enabling Voice of WiFi in their network to provide reliable voice coverage indoors.

While this works currently without any issues, when operators start offering new native services and applications, like XR over 5G, the current approach won't help. When our devices are connected over Wi-Fi at present, they are unable to take advantage of operator core or services. With access and core independence, this will no longer be an issue.

I gave a short (15 mins) virtual presentation at 5G Techritory this year. I argued not just for WWC but also looked at what 5G features have a potential for revolution. It's embedded below.

Related Posts:

• 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: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• Connectivity Technology Blog: 5G Wireline Access Architecture
• Operator Watch Blog: Telefonica Plans to achieve Fixed Mobile Convergence (FMC)
• Operator Watch Blog: BT's Converged Core to Launch in 2023 

5G NR-Unlicensed (NR-U)

I have been talking about unlicensed LTE since 2013. With all the debate around LTE-U and LAA now non-existent, the technology has evolved with every new release. As can be seen from this picture by Ericsson above, 5G NR-U in Release-16 supports:

• License-exempt Downlink (DL)
• License-exempt scheduled Uplink (UL)
• License-exempt autonomous UK
• Standalone license-exempt operation

5G New Radio Unlicensed (NR-U): Challenges and Evaluation - https://t.co/RFyhHHddzh #Free5Gtraining #3G4G5G #5G #5GNR #NRU #NRunlicensed #UnlicensedSpectrum #5GNetworks #5GTechnology #Release16 pic.twitter.com/aiTg2RCECR

— Free 5G Training (@5Gtraining) October 17, 2021

The Release-16 work item summary details the following deployment scenarios for NR-based access to unlicensed spectrum:

• Scenario A: Carrier aggregation between NR in licensed spectrum (PCell) and NR in shared spectrum (SCell);
• A.1: SCell is not configured with UL (DL only); 
• A.2: SCell is configured with UL (DL+UL). 
• Scenario B: Dual connectivity between LTE in licensed spectrum and NR in shared spectrum (PSCell);
• Scenario C: NR in shared spectrum (PCell);
• Scenario D: NR cell in shared spectrum and uplink in licensed spectrum;
• Scenario E: Dual connectivity between NR in licensed spectrum (PCell) and NR in shared spectrum (PSCell)

5G New Radio Unlicensed: Challenges and Evaluation, available on arXiv here provides a lot of useful information on different kind of operations within the unlicensed band and the challenges of co-existence with Wi-Fi

Finally, Qualcomm has quite a few resources on this topic. Last year, they hosted a webinar on the topic, "How does unlicensed spectrum with NR-U transform what 5G can do for you?". The slides from that are available here and a video of that is available here. RCR Wireless also has this short article from one of the webinar presenters here.

Related Posts: 

• The 3G4G Blog: 3GPP Release 16 Description and Summary of Work Items
• The 3G4G Blog: Introduction to 5G Reduced Capability (RedCap) Devices
• The 3G4G Blog: Positioning in 5G networks
• The 3G4G Blog: Qualcomm Explains 5G Millimeter Wave (mmWave) Future & Integrated Access and Backhaul (IAB)
• The 3G4G Blog: '5G RAN Release 18 for Industry Verticals' Webinar Highlights
• The 3G4G Blog: Qualcomm Demoes Sub-band Half Duplex (SBHD)
• The 3G4G Blog: Reducing 5G Device Power Consumption Using Connected-mode Discontinuous Reception (C-DRX)
• The 3G4G Blog: Positioning Techniques for 5G NR in 3GPP Release-16
• The 3G4G Blog: 5G Enhanced URLLC (eURLLC) 

Maritime Communication (MARCOM) Services over 3GPP system

Maritime Communication Services over 3GPP System is one of the topics listed in the 3GPP Release-16 summary that I summarised here.

Maritime domain, one of 5G vertical domains in 3GPP, started to be considered since 2016 to enable 3GPP systems to play the role of mobile communication platform necessary for the digitalization and mobilization of the maritime domain that bring about the Fourth Industrial Revolution of the maritime businesses as well as maritime safety.

Compared to other vertical domains, the maritime domain has the radio communication environment that 3GPP hasn’t considered in detail, which means that maritime related issues and features were not in the scope of 3GPP standardization and some of existing 3GPP enabling technologies or solutions are not able to fully support the optimized performances required by the maritime domain in a way that has been guaranteed for on-land communication. In addition, on-board mobile users in a vessel would like to experience the same rich mobile communication services as they enjoy on land.

Furthermore, it is of the view that the capacity and rate for data transmission based on legacy maritime radio communication technologies are indeed not enough for e-Navigation described in IMO Strategy Implementation Plan (SIP) or Maritime Autonomous Surface Ships (MASS), which the International Maritime Organization (IMO), a United Nations specialized agency, have been working to provide to ship.

Considering that the maritime domain is one of 5G vertical domains that 3GPP take into account in order for 5G to be able to provide enhanced mobile broadband services or massive machine-type communication services etc. everywhere anytime in the world, it is desirable to study use cases and requirements for maritime communication services over 3GPP system so that 3GPP system can be a good candidate of innovative tools to help address the information gap between users on land and users at sea as well as the maritime safety and vessel traffic management etc. that IMO intends to achieve especially in 5G era.

3GPP TR 22.819, Feasibility Study on Maritime Communication Services over 3GPP system concluded in 2018 and a report is available here. The scope of the document says:

The present document aims to support the maritime communication services between users ashore and at sea or between vessels at sea over 3GPP system that are targeted to improve maritime safety, protect the maritime environment and promote the efficiency of shipping by reducing maritime casualty caused by human error, in particular, involving small ships and fishing vessels. In addition, the outcome of the technical report is expected to narrow the information gap between mobile users on land and shipboard users on vessels at sea by making it possible to provide the mobile broadband services.

The document describes use cases and potential requirements for services between shore-based users such as authorities and shipboard users in the maritime radio communication environment over 3GPP system. In addition, it deals with use cases to support Mission Critical Services between authorities on land and authorities at sea (e.g. maritime police) as well as use cases to support the interworking between 3GPP system and the existing/future maritime radio communication system for the seamless service of voice communication and data communication between users ashore and at sea or between vessels at sea.

Analysis is also made on which legacy services and requirements from the existing 3GPP system need to be included and which potential requirements need additional work for new functions to support maritime communication services over 3GPP system.

The first 3GPP Technical Specification (TS) 22.119 covering service requirements (Stage 1) is specified for the support of maritime communication (MARCOM) over 3GPP systems.

The maritime domain, one of the 5G vertical domains in 3GPP, is moving forward with the digitalisation and mobilisation of commercial as well as safety fields. Legacy 3GPP-based technologies and solutions can be beneficial to the digitalisation and mobilisation of the maritime domain though some of the legacy 3GPP enabling technologies and solutions may not be able to fully support the performances required by the maritime domain. The maritime radio environment was not originally considered by 3GPP when the technical specifications and solutions were standardised for LTE and 5G. 

However, most of the legacy mobile services and IoT services based on capabilities of EPS and 5GS specified in 3GPP specifications are applicable to maritime usage for the support of mobile broadband services, and for the support of IoT services or machine-type communication services in a vessel at sea. 

In addition, there are service scenarios and requirements specified in 3GPP specifications based on requirements of other related vertical domains (e.g. public safety domain, automotive domain, factory automation domain, and satellite industrial domain). Some requirements derived by service scenarios from these related vertical domains are applicable to the maritime domain. Thus, it is beneficial to use 3GPP enabling technologies developed to satisfy those requirements for the maritime domain in terms of the economy of scale.

For example, satellite access is one of the 3GPP radio access networks supported over the 5G system, so it is possible to provide seamless maritime mobile services by integrating multiple access technologies including satellite access depending on the service scenarios. In addition, Vertical LAN that can replace Ethernet-based access are applicable to indoor maritime mobile services inside a vessel.

Mission Critical (MC) Services specified in 3GPP specifications are applicable to commercial and maritime safety fields. Some similarities exist between the public safety domain and the maritime domain in terms of service scenarios that are essentially the same. For example, in some situations, mobile communication services are supported in spite of disconnected networks, i.e. off-network mode, or under isolated conditions. 

However, the maritime domain also has specific situations that do not happen in other vertical domains or in the legacy ICT industrial domain. New 3GPP enabling technologies dedicated to the maritime domain can be used to address such specific situations based on requirements derived from maritime use cases. Other vertical domains may benefit from such new 3GPP enabling technologies that consider maritime domain scenarios and may need more robust technologies or solutions than those that currently exist for those vertical domains.

The following specifications are relevant for MARCOM:

• 3GPP TS 22.119, Maritime communication services over 3GPP system
• 3GPP TS 22.179, Mission Critical Push to Talk (MCPTT); Stage 1
• 3GPP TS 22.280, Mission Critical (MC) services common requirements
• 3GPP TS 22.281, Mission Critical (MC) video
• 3GPP TS 22.282, Mission Critical (MC) data

Related Posts: 

• The 3G4G Blog: 3GPP Release 16 Description and Summary of Work Items
• The 3G4G Blog: '5G RAN Release 18 for Industry Verticals' Webinar Highlights
• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Future Railway Mobile Communication System (FRMCS)
• The 3G4G Blog: Update from 3GPP on LTE & 5G Mission Critical Communications 

3GPP Release 16 Description and Summary of Work Items

Someone reached out recently asking for a summary of Release 16 features. For people who are involved in standards, they already know of a few ways you can get this quickly. 

The first is to go to the Releases page here: https://www.3gpp.org/specifications/releases 

Here you can see the status of current releases as well as at the bottom of the page you can jump to the individual releases. 

A full Release Description is produced by the Work Plan manager at the completion of the work. This has been available since Release-14 onwards. You can go and get the latest version of the following technical reports:  

• TR 21.914 covers Rel-14, 
• TR 21.915 for Rel-15 and now 
• TR 21.916 as the Rel-16 description document.

The following is the summary of features listed in 3GPP TR 21.916 for Release-16: 

5. Enhancement of Ultra-Reliable and Low Latency Communications (URLLC)
1. Enhancement of URLLC support in the 5G Core network
2. Physical Layer Enhancements for NR Ultra-Reliable and Low Latency Communication (URLLC)
3. Support of NR Industrial Internet of Things
6. Support of LAN-type services
1. NR-based access to unlicensed spectrum
2. LAN support in 5G
3. 5GS Enhanced support of Vertical and LAN Services
7. Cellular Internet of Things (IoT)
1. Cellular IoT support and evolution for the 5G System
2. Additional enhancements for NB-IoT
3. Additional MTC enhancements for LTE
8. Advanced V2X support
1. Improvement of V2X service Handling
2. Architecture enhancements for 3GPP support of advanced V2X services
3. Application layer support for V2X services
4. 5G V2X with NR sidelink
9. Northbound APIs related items
1. Usage of CAPIF for xMB API
2. Enhancement of 3GPP Northbound APIs
3. Enhancements for Common API Framework for 3GPP Northbound APIs
4. Service Enabler Architecture Layer for Verticals
5. Other APIs-related items
10. Coexistence with Non-3GPP systems
1. Wireless and Wireline Convergence Enhancement
2. Access Traffic Steering, Switch and Splitting support in the 5G system architecture
11. Railways and Maritime
1. Mobile Communication System for Railways 2
2. Further performance enhancement for LTE in high speed scenario
3. NR support for high speed train scenario
4. Maritime Communication Services over 3GPP System
12. Mission Critical, Public Warning
1. Enhancements of Public Warning System
2. MBMS APIs for Mission Critical Services
3. Mission Critical Services Security Enhancements
4. Other Mission critical improvements
1. MCData File Distribution support over xMB
2. Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems
3. MBMS APIs for Mission Critical Services
4. Enhancements to Functional architecture and information flows for Mission Critical Data
5. MC Communication Interworking
6. Enhanced Mission Critical Push-to-talk architecture phase 2
7. Other Mission Critical activities
13. Conversational services, Streaming and TV
1. Conversational services
1. Coverage and Handoff Enhancements for Multimedia (CHEM)
2. Single radio voice continuity from 5GS to 3G
3. Volume Based Charging Aspects for VoLTE
4. EVS Floating-point Conformance for Non Bit-Exact
5. Media Handling Extensions for 5G Conversational Services
6. VR QoE metrics
7. Media Handling Aspects of RAN Delay Budget Reporting in MTSI
8. Removal of H.263 and MPEG-4 Visual from 3GPP Services
2. 13.2 Streaming
1. Enhancement of LTE for Efficient delivery of Streaming Service
2. Enhancements to Framework for Live Uplink Streaming
3. Media streaming architecture
14. 5G Location and Positioning Services
1. 5G positioning services (5G_HYPOS)
2. Enhancement to the 5GC LoCation Services
3. NR positioning support
15. User Identities, Authentication, multi-device
1. User Identities and Authentication
2. Multi-device and multi-identity
16. Slicing
1. Enhancement of Network Slicing
2. Enhancement of 3GPP management system for multiple tenant environment support
3. Business Role Models for Network Slicing
4. Enhancement of performance assurance for 5G networks including network slicing
17. UE radio capability signalling optimization
1. Optimisations on UE radio capability signalling
18. Other system-wide Features
1. Enablers for Network Automation Architecture for 5G
2. Provision of Access to Restricted Local Operator Services by Unauthenticated UEs
3. Enhancing Topology of SMF and UPF in 5G Networks
4. Private and Non-Public Network Support for NG-RAN
5. Service-Based Architecture
1. Enhancements to the Service-Based 5G System Architecture
2. SBA aspects of enhanced IMS to 5GC integration
6. User data interworking, Coexistence and Migration
19. Radio Features
1. NR-related Release 16 Features
1. NR-based access to unlicensed spectrum
2. 2-step RACH for NR
3. UE Power Saving in NR
4. Integrated access and backhaul for NR
5. Dual Connectivity (EN-DC) with 3 bands DL and 3 bands UL
6. NR mobility enhancements
7. Rel-16 NR inter-band CA/Dual Connectivity for 2 bands DL with x bands UL (x=1, 2)
8. Rel16 NR inter-band Carrier Aggregation for 3 bands DL with 1 band UL
9. Add support of NR DL 256QAM for frequency range 2 (FR2)
10. SON (Self-Organising Networks) and MDT (Minimization of Drive Tests) support for NR
11. Introduction of NR FDD bands with variable duplex and corresponding framework
12. Cross Link Interference (CLI) handling and Remote Interference Management (RIM) for NR
13. RF requirements for NR frequency range 1 (FR1)
14. NR RF requirement enhancements for frequency range 2
15. NR RRM enhancement
16. RRM requirement for CSI-RS based L3 measurement in NR
17. Over the air (OTA) base station (BS) testing TR
2. Release 16 Features impacting both LTE and NR
1. Transfer of Iuant interface specifications from 25-series to 37-series
2. Introduction of GSM, UTRA, E-UTRA and NR capability set(s) (CS(s)) to the multi-standard radio (MSR) specifications
3. Direct data forwarding between NG-RAN and E-UTRAN nodes for inter-system mobility
4. eNB(s) Architecture Evolution for E-UTRAN and NG-RAN
5. High power UE (power class 2) for EN-DC (1 LTE TDD band + 1 NR TDD band)
6. LTE-NR & NR-NR Dual Connectivity and NR Carrier Aggregation enhancements
7. 29 dBm UE Power Class for LTE band 41 and NR Band n41
8. LTE/NR Dynamic Spectrum Sharing (DSS) in band 48/n48 frequency range
3. LTE-related Release 16 Features
1. LTE-based 5G terrestrial broadcast
2. Support for NavIC Navigation Satellite System for LTE
3. Even further mobility enhancement in E-UTRAN
4. DL MIMO efficiency enhancements for LTE
5. Other LTE-only items
20. All other Release 16 Features
1. Service Interactivity
2. RTCP Verification for Real-Time Services
3. Stage-3 SAE Protocol Development for Rel16
4. Reliable Data Service Serialization Indication
5. Shared Data Handling on Nudm and Nudr
6. New Services and Markets Technology Enablers – Phase 2
7. Ambient noise test methodology for evaluation of acoustic UE performance
8. KPI reporting
21. Telecom Management
1. Network and Service Management
1. 5G Management capabilities
2. Energy Efficiency of 5G
3. OAM aspects of LTE and WLAN integration
4. Methodology for 5G management specifications
5. Closed loop SLS Assurance
6. Trace Management in the context of Services Based Management Architecture and Streaming Trace reporting
7. Management of QoE measurement collection
8. Network Resource Model (NRM) enhancement
2. Charging Management
1. Charging Enhancement of 5GC interworking with EPC
3. Other charging and management items
22. Other items
1. Items not (fully) completed in Rel-16
1. Remote Identification of Unmanned Aerial Systems
2. 5G message service
3. Integration of Satellite Access in 5G

If you find them useful then please get the latest document from here.

Related Posts: 

• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Anritsu Webinar on 'Evolution of 5G from 3GPP Rel-15 to Rel-17 and Testing Challenges'
• The 3G4G Blog: Future Railway Mobile Communication System (FRMCS)
• The 3G4G Blog: Qualcomm Explains 5G Millimeter Wave (mmWave) Future & Integrated Access and Backhaul (IAB)
• The 3G4G Blog: 5G User Plane Redundancy
• The 3G4G Blog: NWDAF in 3GPP Release-16 and Release-17
• The 3G4G Blog: UE Radio Capability Signaling Optimization (RACS) in Rel. 16
• The 3G4G Blog: Conditional Handover (Rel. 16) Explained
• The 3G4G Blog: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• The 3G4G Blog: Positioning Techniques for 5G NR in 3GPP Release-16
• The 3G4G Blog: Understanding the Dual Active Protocol Stack (DAPS) Handover in 5G
• The 3G4G Blog: 5G Enhanced URLLC (eURLLC)
• The 3G4G Blog: 3GPP MDT - How it works and what is new in Rel. 16
• The 3G4G Blog: Mobile Initiated Connection Only (MICO) mode in 5G System 

Future Railway Mobile Communication System (FRMCS)

I have been meaning to write on this topic for a very long time. The discussion started back in 2016 when the limitations of GSM-R were obvious and it was recognised that a successor will be needed sooner or later. The International Railway Union (UIC) published a user requirement specification in their paper “Future Railway Mobile Communication System - FRMCS”. This is available on 3GPP server as liaison statement S1-161250.

As 3GPP notes in their article, this was the trigger for them to go ahead and start the studies. Then in Release 16, 3GPP TS 22.289 "Mobile communication system for railways" outlined the requirements for railway communication, beyond the 3GPP Future Railway Mobile Communication System (FRMCS) Phase 1 specs. Details are available on this post here.

Source Tweet

The latest version of 3GPP TR 22.889, Study on Future Railway Mobile Communication System; Stage 1 is from Release 17. The introduction to the document clarifies:

The railway community is considering a successor communication system to GSM-R, as the forecasted obsolescence of the 2G-based GSM-R technology is envisaged around 2030, with first FRMCS trial implementations expected to start around 2020. 

The Future Railway Mobile Communication System (FRMCS) Functional Working Group (FWG) of the International Union of Railways (UIC) have investigated and summarised their requirements for the next generation railway communication system in the Future Railway Mobile Communication User Requirements Specification (FRMCS URS). The present document is based on this input given by the UIC/ETSI TC-RT 

Study on FRMCS Evolution (FS_eFRMCS), available as SP-201038 clarifies:

The UIC FRMCS programme was recently releasing stable version 5.0.0 of the User Requirement Specification, version 2.0.0 of the Functional Use Cases and a new specification item, version 1.0.0 of the Telecom On-Board System - Functional Requirements Specification, as a further step in the evolution of the FRMCS specifications. The UIC FRMCS Programme is developing all the technical conditions for the 5G FRMCS, with the main objective to make available a “FRMCS First Edition” ecosystem available for procurement by Q1 2025.

The UIC FRMCS 3GPP Task Force has been identifying and analyzing impact of this newly released set of FRMCS specifications on existing use cases and requirements collected in TR 22.889. The UIC FRMCS 3GPP Task Force analysis has concluded that refining existing use cases, defining new use cases such as merging railway emergency communications and real-time translation of conversation, and deriving potential new requirements, will be necessary to align FRMCS and 3GPP specifications. The potential impact on normative work is estimated to be limited and much less compared to the study work.

As approved in SA1#90-e (S1-202245), TR 22.889 has now been re-named to TR 22.989 from Rel-18 onwards (latest version is TR 22.989 v18.0.0) to make it visible to the Rail community to be able to follow the 3GPP normative work in line with their needs. It is of most importance for the Rail community that specifications from different organisations (i.e. UIC, 3GPP and ETSI) are all aligned.

Due to the expected 3GPP work overload in Release 18 (SA1 and downstream groups), it is proposed to reduce the scope of the present Rel-18 study to evolution of critical applications related use cases only already identified by UIC – what is really essential for the railways as part of the “FRMCS First Edition” and the migration phase from GSM-R to FRMCS. 

Study of non-essential use cases (e.g. evolution of performance and business use cases) shall be postponed to Rel-19.

This plan is from 2019 so quite likely that it is already outdated. It does provide an idea on different steps and trial plans. Some of this was also covered in the 5G RAN Release 18 for Industry Verticals Webinar detailed here.

Finally, as this image from Arthur D. Little highlights, there is a lot of other interest in addition to FRMCS for 5G in railway. Report here.

Related Posts:

• The 3G4G Blog: '5G RAN Release 18 for Industry Verticals' Webinar Highlights
• The 3G4G Blog: Three New Standards to Accelerate 5G Wireless Wireline Convergence (WWC)
• The 3G4G Blog: 3GPP's 5G-Advanced Workshop Summary
• The 3G4G Blog: 3GPP's 5G-Advanced Technology Evolution from a Network Perspective Whitepaper
• Telecoms Infrastructure Blog: Bringing Connectivity to Underground Rail Network
• Connectivity Technology Blog: Deutsche Bahn to get Seamless Mobile Network Along all Tracks
• Connectivity Technology Blog: China Unicom Brings 5G Connectivity to Nanjing Metro 

Qualcomm Explains 5G Millimeter Wave (mmWave) Future & Integrated Access and Backhaul (IAB)

We have covered various topics in our blog posts on millimeter wave spectrum and even going beyond 52.6 GHz in FR2. A Qualcomm webinar from back in January expands on many of the topics that I looked superficially in various posts (links at the bottom).

The following is edited from the Qualcomm blog post:

5G NR in unlicensed spectrum (NR-U) was standardized in Release 16 and it is a key enabler for the 5G expansion to new use cases and verticals, providing expanded spectrum access to mobile operators, service providers, and industry players. At the same time, we are starting to push the mmWave boundary to even higher bands toward the sub-Terahertz (i.e., >100 GHz) range. Expected in Release 17, 5G NR will support spectrum bands up to 71 GHz, leveraging the 5G NR Release 15 scalable numerology and flexible framework. This opens up 5G to operate in the globally unlicensed 60 GHz band, which can fuel a broad range of new applications and deployments.

One daunting challenge that mobile operators will face when expanding 5G mmWave network coverage is the cost of deploying additional base stations for mmWave, which usually requires new fiber optics backhaul installations. Release 16-defined IAB allows a base station to not just provide wireless access for its user devices (e.g., smartphones) but also the ability to backhaul wirelessly via neighboring base stations using the same mmWave spectrum. IAB opens the door to more flexible densification strategies, allowing mobile operators to quickly add new base stations to their networks before having to install new fiber to increase backhaul capacity. 

Release 16 established foundational IAB capabilities, such as dynamic topology adaptation for load balancing and blockage mitigation, and Release 17+ will further enhance IAB by bringing new features like full-duplex operation, topology redundancy, and ML-based network management.

Beyond IAB, there is a rich roadmap of other new features that can further improve 5G mmWave system performance and efficiency. The webinar embedded below is presented by Ozge Koymen, Senior Director, Technology, Qualcomm Technologies, Inc. It covers the following topics:

• Qualcomm's vision for 5G mmWave and the new opportunities it poises to bring for the broader ecosystem
• mmWave capabilities and enhancements coming in Release -16 and beyond
• Qualcomm’s role in mobilizing and democratizing 5G mmWave to usher in new experiences
• Latest update on the global commercial rollout of 5G mmWave networks and devices

Slides of the presentation are available here.

Related Posts:

• Free 6G Training: Spectrum for 5G, Beyond 5G and 6G research
• The 3G4G Blog: A mmWave Special Cell in Open RAN Environment
• The 3G4G Blog: Spectrum for 5G NR beyond 52.6 GHz
• The 3G4G Blog: 5G Integrated Access and Backhaul (IAB) Enhancements in Rel-17
• The 3G4G Blog: Carrier Aggregation (CA) and Dual Connectivity (DC)
• The 3G4G Blog: The Politics of Standalone vs Non-Standalone 5G & 4G Speeds 

5G User Plane Redundancy

We looked at the 5G Enhanced URLLC (eURLLC) earlier. One of the ways to improve reliability is to have redundancy in the user plane. This can use different approaches like: 

• Duplicating N3
• Adding a secondary gNB using Dual connectivity
• Introducing another UPF
• Two anchor UPFs

In fact they are all built on top of each other so you can decide how critical are your user plane redundancy needs. 

I came across this short video from Mpirical embedded below that covers this topic nicely. In case you want to refresh your 5G Core Network architecture, jump to our old tutorial here.

Related Posts:

• The 3G4G Blog: 5G Enhanced URLLC (eURLLC)
• The 3G4G Blog - Ultra Reliability: 5x9s (99.999%) in 3GPP Release-15 vs 6x9s (99.9999%) in 3GPP Release-16 
• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• 3G4G: 3GPP 5G Specifications
• 3G4G: 5G (IMT-2020) Wireless 

Positioning in 5G networks

I have written about the 5G positioning techniques not that long back on this blog here and on connectivity technology blog here. With Release-16 now ready for deployment, Huawei has already announced world's first in 5G Indoor Positioning. Their announcement said:

China Mobile Suzhou and Huawei reached a new milestone with the verification of the 5G indoor positioning capability in metro transport scenarios in Suzhou — a major city located along the southeastern edge of Jiangsu Province in eastern China. The verification showed that, even with pRRUs being hidden, a positioning precision of 3 to 5 m can be achieved in 90% of the platform and hall areas. This is the first time that 5G indoor positioning has been verified on live networks in the world, providing valuable experience for the commercial growth of 5G positioning in vertical industries.

Indoor location-based services are in high demand of vertical applications, such as indoor navigation, asset tracking, geofencing, logistics management, and personnel management, which reflects the huge market space of indoor positioning. Currently, indoor positioning technologies are of great variety and most of them need to be deployed and maintained individually, resulting in high end-to-end costs. As a part of the continuous evolution of 5G, positioning has been added to 3GPP Release 16 finalized in mid 2020 to realize indoor positioning by leveraging the ultra-high signal resolution empowered by 5G's high bandwidth, multi-point measurements, and multi-access edge computing (MEC) deployment.

The verification was based on Huawei's 5G digital indoor solution LampSite and leading MEC solution. The LampSite units measure the radio signals of 5G devices and work with MEC to analyze the signal characteristics. Based on the results of the analysis, leading algorithms are used to precisely locate 5G devices.

We wrote about Huawei's Lampsite on Telecoms Infrastructure blog last year here.

A group of Ericsson engineers have written a research paper on 5G positioning recently. It's available on arXiv here. Here is the abstract:

In this paper we describe the recent 3GPP Release 16 specification for positioning in 5G networks. It specifies positioning signals, measurements, procedures, and architecture to meet requirements from a plethora of regulatory, commercial and industrial use cases. 5G thereby significantly extends positioning capabilities compared to what was possible with LTE. The indicative positioning performance is evaluated in agreed representative 3GPP simulation scenarios, showing a 90 percentile accuracy of a few meters down to a few decimeters depending on scenarios and assumptions.

Definitely worth a read if you like hardcore technical papers.

Related Posts:

• The 3G4G Blog: Positioning Techniques for 5G NR in 3GPP Release-16
• Connectivity Technology Blog: 5G Indoor Precise Positioning
• Telecoms Infrastructure Blog: Huawei 5G Lampsite wins awards and speed tests 

Everything you need to know about 5G Security

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

5G Security Briefing from 3G4G

The slides could be downloaded from SlideShare.

Related Posts:

• The 3G4G Blog: Lawful Intercept in 5G Networks
• The 3G4G Blog: Key Technology Aspects of 5G Security by Rohde & Schwarz
• The 3G4G Blog: 5G Roaming with SEPP (Security Edge Protection Proxy)
• The 3G4G Blog: Evolution of Security from 4G to 5G
• The 3G4G Blog - Tutorial: Service Based Architecture (SBA) for 5G Core (5GC)
• 3G4G: Security in 2G, 3G, 4G & 5G Mobile Networks
• 3G4G: 5G (IMT-2020) Wireless 

NWDAF in 3GPP Release-16 and Release-17

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.

Related Posts:

• The 3G4G Blog: ATIS Webinar on '5G Standards Developments in 3GPP Release 16 and Beyond'
• The 3G4G Blog: Automating the 5G Core using Machine Learning and Data Analytics
• The 3G4G Blog: Artificial Intelligence - Beyond SON for Autonomous Networks
• 3G4G: 5G Service Based Architecture (SBA)