Showing posts with label Release 17. Show all posts
Showing posts with label Release 17. Show all posts

Thursday, 27 June 2024

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

Wednesday, 24 January 2024

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

Wednesday, 12 July 2023

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

Wednesday, 31 May 2023

New 5G NTN Spectrum Bands in FR1 and FR2

Release-17 includes two new FR1 bands for NTN; n255 (a.k.a. NTN 1.6GHz) and n256 (a.k.a. NTN 2GHz). The picture is from a slide in Rohde & Schwarz presentation available here. Quoting from an article by Reiner Stuhlfauth, Technology Manager Wireless, Rohde & Schwarz:

Currently, several frequency ranges are being discussed within 3GPP for NTN. Some are in the FR1 legacy spectrum, and some beyond 10 GHz and FR2. The current FR1 bands discussed for NTN are:

  • The S-band frequencies from 1980 to 2010 MHz in uplink (UL) direction and from 2170 to 2200 MHz in downlink (DL) direction (Band n256).
  • The L-band frequencies from 1525 to 1559 MHz DL together with 1626.5 to 1660.5 MHz for the UL (Band n255).1

These frequency ranges have lower path attenuation, and they’re already used in legacy communications. Thus, components are available now, but the bands are very crowded, and the usable bandwidth is restricted. Current maximum bandwidth is 20 MHz with up to 40-MHz overall bandwidth envisaged in the future [TR 38.811].

As far as long-term NTN spectrum use is concerned, 3GPP is discussing NR-NTN above 10 GHz. The Ka-band is the highest-priority band with uplinks between 17.7 and 20.2 GHz and downlinks between 27.5 and 30 GHz, based on ITU information regarding satellite communications frequency use.2 Among current FR2 challenges, one is that some of the discussed bands fall into the spectrum gap between FR1 and FR2 and that NTN frequencies will use FDD duplex mode due to the long roundtrip time.

Worth highlighting again that the bands above, including n510, n511 and n512 are all FDD bands due to the long round trip times.

The latest issue of 3GPP highlight magazine has an article on NTN as well. Quoting from the article:

The NTN standard completed as part of 3GPP Release 17 defines key enhancements to support satellite networks for two types of radio protocols/interfaces:

  • 5G NR radio interface family also known as NR-NTN
  • 4G NB-IoT & eMTC radio interfaces family known as IoT-NTN

These critical enhancements including adaptation for satellite latency and doppler effects have been carefully defined to support a wide range of satellite network deployment scenarios and orbits (i.e., LEO, MEO and GEO), terminal types (handheld, IoT, vehicle mounted), frequency bands, beam types (Earth fixed/Earth moving) and sizes. The NTN standard also addresses mobility procedures across both terrestrial and non-terrestrial network components. Release 17 further includes Radio Frequency and Radio Resource Management specifications for terminals and satellite access nodes operating in two FR1 frequency ranges allocated to Mobile Satellite Services (i.e., n255 and n256).

You can read it here.

Related Posts

Tuesday, 17 January 2023

Authentication and Key Management for Applications (AKMA) based on 3GPP credentials in the 5G System (5GS)

3GPP Release 17 introduced a new feature called AKMA (Authentication and Key Management for Applications), the goal of which is to enable the authentication and generation of application keys based on 3GPP credentials for all UE types in the 5G System, especially IoT devices, ensuring to bootstrap the security between the UE and the applications in the 5G system.

3GPP TR 21.917 has an excellent summary as follows:

Authentication and key management for applications based on 3GPP credential in 5G (AKMA) is a cellular-network-based delegated authentication system specified for the 5G system, helping establish a secure tunnel between the end user and the application server. Using AKMA, a user can log in to an application service only based on the 3GPP credential which is the permanent key stored in the user’s tamper-resistant smart card UICC. The application service provider can also delegate the task of user authentication to the mobile network operator by using AKMA. 

The AKMA architecture and procedures are specified by SA3 in TS 33.535, with the related study showing how its general principles are derived documented in TR 33.835. The AKMA feature introduces a new Network Function into the 5G system, which is the AKMA Anchor Function (AAnF). Its detailed services and API definitions are specified by CT3 in TS 29.535. Earlier generations of cellular networks include two similar standards specified by SA3, which are generic bootstrapping architecture (GBA) and battery-efficient security for very low throughput machine type communication devices (BEST). Since the AKMA feature is deemed as a successor of these systems, the work is launched by SA3 without the involvement of stage 1.

In the latest issue of 3GPP Highlights Magazine, Suresh Nair, 3GPP Working Group SA3 Chair, Saurabh Khare & Jing Ping (Nokia) has explained the AKMA procedure. The article is also available on 3GPP website here. The article lists the following as AKMA advantages:

  • Since the AKMA framework uses authentication and authorization of the UE leveraging the PLMN credentials stored on the USIM, this becomes as strong as the network primary authentication and subsequent keys derived further to UE and Application Function (AF) interface.
  • The Application Functions can leverage the authentication service provided by the AKMA Anchor Function (AAnF) without additional CAPEX and OPEX.
  • The architecture provides a direct interface between the UE and the AF where a customized application-specific interface can be built, including the key management, key lifetime extension, etc.

The Journal of ICT Standardization has a paper on Authentication Mechanisms in the 5G System. It details AKMA and much more. It's a great place to start for anyone new looking to understand different 5G Authentication Mechanisms. 

Related Posts

Saturday, 24 December 2022

3GPP Release 17 Description and Summary of Work Items

An updated (looks final) version of 3GPP TR 21.917: Release 17 Description; Summary of Rel-17 Work Items was added to the archive earlier this month. It is a fantastic summary of all the Rel-17 features. Quoting the executive summary from the specs:

Release 17 is dedicated to consolidate and enhance the concepts and functionalities introduced in the previous Releases, while introducing a small number of brand new Features.

The improvements relate to all the key areas of the previous Releases: services to the industry (the "verticals"), including positioning, private network, etc.; improvements for several aspects of 5G supporting Internet of Things (IoT), both in the Core Network and in the Access Network, of proximity (direct) communications between mobiles, in particular in the context of autonomous driving (V2X), in several media aspects of the user plane related to the entertainment industry (codec, streaming, broadcasting) and also of the support of Mission Critical communications. Furthermore, a number of network functionalities have been improved, e.g. for slicing, traffic steering and Edge-computing.

The Radio interface and the Access Network have been significantly improved too (MIMO, Repeaters, 1024QAM modulation for downlink, etc.). While most of the improvements target 5G/NR radio access (or are access-agnostic), some improvements are dedicated to 4G/LTE access. Such improvements are clearly identified in the title and in the chapters where they appear.

Note: To avoid terminology such as "even further improvements of…", the successive enhancements are now referred to as "Phase n": "phase 2" refers to the first series of enhancements, "Phase 3" to the enhancements of the enhancements, etc. In this transition Release, the "Phase n" way of referring to successive enhancements has not always been used consistently nor enforced.

As for the new Features, the main new Feature of this Release is the support of satellite access, and a dedicated chapter covers this topic.

Note that the classifications, groupings and order of appearance of the Features in this document reflect a number of choices by the editor as there is no "3GPP endorsement" for classification/order. This Executive Summary has also been written by the editor and represents his view.

The following list is from the table of contents to provide you an idea and if it interests you, download the technical report here

5 Integration of satellite components in the 5G architecture
5.1 General traffic (non-IoT)
5.1.1 SA and CT aspects
5.1.2 RAN aspects
5.2 NB-IoT/eMTC support for Non-Terrestrial Networks

6 Services to "verticals"
6.1 Introduction
6.2 Generic functionalities, to all verticals
6.2.1 Network and application enablement for verticals
6.2.1.1 Enhanced Service Enabler Architecture Layer for Verticals
6.2.1.2 Enhancements for Cyber-physical control Applications in Vertical domains (eCAV)
6.2.1.3 Enhancements of 3GPP Northbound Interfaces and APIs
6.2.2 Location and positioning
6.2.2.1 RAN aspects of NR positioning enhancements
6.2.2.2 Enhancement to the 5GC LoCation Services-Phase 2
6.2.3 Support of Non-Public and Private Networks
6.2.3.1 Enhanced support of Non-Public Networks
6.2.3.2 Enhancement of Private Network support for NG-RAN
6.3 Specific verticals support
6.3.1 Railways
6.3.1.1 Enhancements to Application Architecture for the Mobile Communication System for Railways Phase 2
6.3.1.2 Enhanced NR support for high speed train scenario (NR_HST)
6.3.1.2.1 NR_HST for FR1
6.3.1.2.2 NR_HST for FR2
6.3.1.3 NR Frequency bands for Railways
6.3.1.3.1 Introduction of 900MHz NR band for Europe for Rail Mobile Radio (RMR)
6.3.1.3.2 Introduction of 1900MHz NR TDD band for Europe for Rail Mobile Radio (RMR)
6.3.2 Mission Critical (MC) and priority service
6.3.2.1 Mission Critical Push-to-talk Phase 3
6.3.2.2 Mission Critical Data Phase 3
6.3.2.3 Mission Critical security Phase 2
6.3.2.4 Mission Critical Services over 5GS
6.3.2.5 Enhanced Mission Critical Communication Interworking with Land Mobile Radio Systems (CT aspects)
6.3.2.6 Mission Critical system migration and interconnection (CT aspects)
6.2.3.7 MC services support on IOPS mode of operation
6.3.2.8 MCPTT in Railways
6.3.2.9 Multimedia Priority Service (MPS) Phase 2
6.3.3 Drone/UAS/UAV/EAV
6.3.3.1 Introduction
6.3.3.2 General aspects
6.3.3.2.1 5G Enhancement for UAVs
6.3.3.2.2 Application layer support for UAS
6.3.3.3 Remote Identification of UAS
6.3.4 Media production, professional video and Multicast-Broadcast
6.3.4.1 Communication for Critical Medical Applications
6.3.4.2 Audio-Visual Service Production
6.3.4.3 Multicast-Broadcast Services (MBS)
6.3.4.3.1 Multicast-broadcast services in 5G
6.3.4.3.2 NR multicast and broadcast services
6.3.4.3.3 5G multicast and broadcast services
6.3.4.3.4 Security Aspects of Enhancements for 5G MBS
6.3.4.4 Study on Multicast Architecture Enhancements for 5G Media Streaming
6.3.4.5 5G Multicast-Broadcast User Service Architecture and related 5GMS Extensions
6.3.4.6 Other media and broadcast aspects
6.4 Other "verticals" aspects

7 IoT, Industrial IoT, REDuced CAPacity UEs and URLLC
7.1 NR small data transmissions in INACTIVE state
7.2 Additional enhancements for NB-IoT and LTE-MTC
7.3 Enhanced Industrial IoT and URLLC support for NR
7.4 Support of Enhanced Industrial IoT (IIoT)
7.5 Support of reduced capability NR devices
7.6 IoT and 5G access via Satellite/Non-Terrestrial (NTN) link
7.7 Charging enhancement for URLLC and CIoT
7.8 Messaging in 5G

8 Proximity/D2D/Sidelink related and V2X
8.1 Enhanced Relays for Energy eFficiency and Extensive Coverage
8.2 Proximity-based Services in 5GS
8.3 Sidelink/Device-to-Device (D2D)
8.3.1 NR Sidelink enhancement
8.3.2 NR Sidelink Relay
8.4 Vehicle-to-Everything (V2X)
8.4.1 Support of advanced V2X services - Phase 2
8.4.2 Enhanced application layer support for V2X services

9 System optimisations
9.1 Edge computing
9.1.1 Enhancement of support for Edge Computing in 5G Core network
9.1.2 Enabling Edge Applications
9.1.3 Edge Computing Management
9.2 Slicing
9.2.1 Network Slicing Phase 2 (CN and AN aspects)
9.2.2 Network Slice charging based on 5G Data Connectivity
9.3 Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 2
9.4 Self-Organizing (SON)/Autonomous Network
9.4.1 Enhancement of data collection for SON/MDT in NR and EN-DC
9.4.2 Autonomous network levels
9.4.3 Enhancements of Self-Organizing Networks (SON)
9.5 Minimization of service Interruption
9.6 Policy and Charging Control enhancement
9.7 Multi-(U)SIM
9.7.1 Support for Multi-USIM Devices (System and CN aspects)
9.7.2 Support for Multi-SIM Devices for LTE/NR

10 Energy efficiency, power saving
10.1 UE power saving enhancements for NR
10.2 Enhancements on EE for 5G networks
10.3 Other energy efficiency aspects

11 New Radio (NR) physical layer enhancements
11.1 Further enhancements on MIMO for NR
11.2 MIMO Over-the-Air requirements for NR UEs
11.3 Enhancements to Integrated Access and Backhaul for NR
11.4 NR coverage enhancements
11.5 RF requirements for NR Repeaters
11.6 Introduction of DL 1024QAM for NR FR1
11.7 NR Carrier Aggregation
11.7.1 NR intra band Carrier Aggregation
11.7.2 NR inter band Carrier Aggregation
11.8 NR Dynamic Spectrum Sharing
11.9 Increasing UE power high limit for CA and DC
11.10 RF requirements enhancement for NR FR1
11.11 RF requirements further enhancements for NR FR2
11.12 NR measurement gap enhancements
11.13 UE RF requirements for Transparent Tx Diversity for NR
11.14 NR RRM further enhancement
11.15 Further enhancement on NR demodulation performance
11.16 Bandwidth combination set 4 (BCS4) for NR
11.17 Other NR related activities
11.18 NR new/modified bands
11.18.1 Introduction of 6GHz NR licensed bands
11.18.2 Extending current NR operation to 71 GHz
11.18.3 Other NR new/modified bands

12. New Radio (NR) enhancements other than layer 1
12.1 NR Uplink Data Compression (UDC)
12.2 NR QoE management and optimizations for diverse services

13 NR and LTE enhancements
13.1 NR and LTE layer 1 enhancements
13.1.1 High-power UE operation for fixed-wireless/vehicle-mounted use cases in LTE bands and NR bands
13.1.2 UE TRP and TRS requirements and test methodologies for FR1 (NR SA and EN-DC)
13.1.3 Other Dual Connectivity and Multi-RAT enhancements
13.2 NR and LTE enhancements other than layer 1
13.2.1 Enhanced eNB(s) architecture evolution for E-UTRAN and NG-RAN
13.2.2 Further Multi-RAT Dual-Connectivity enhancements
13.2.3 Further Multi-RAT Dual-Connectivity enhancements

14 LTE-only enhancements
14.1 LTE  inter-band Carrier Aggregation
14.2 LTE new/modified bands
14.2.1 New bands and bandwidth allocation for 5G terrestrial broadcast - part 1
14.3 Other LTE bands-related aspects

15 User plane improvements
15.1 Immersive Teleconferencing and Telepresence for Remote Terminals
15.2 8K Television over 5G
15.3 5G Video Codec Characteristics
15.4 Handsets Featuring Non-Traditional Earpieces
15.5 Extension for headset interface tests of UE
15.6 Media Streaming AF Event Exposure
15.7 Restoration of PDN Connections in PGW-C/SMF Set
15.8 Other media and user plane aspects

16 Standalone Security aspects
16.1 Introduction
16.2 Authentication and key management for applications based on 3GPP credential in 5G (AKMA)
16.3 AKMA TLS protocol profiles
16.4 User Plane Integrity Protection for LTE
16.5 Non-Seamless WLAN offload authentication in 5GS
16.6 Generic Bootstrapping Architecture (GBA) into 5GC
16.7 Security Assurance Specification for 5G
16.8 Adapting BEST for use in 5G networks
16.9 Other security aspects

17 Signalling optimisations
17.1 Enhancement for the 5G Control Plane Steering of Roaming for UE in Connected mode
17.2 Same PCF selection for AMF and SMF
17.3 Enhancement of Inter-PLMN Roaming
17.4 Enhancement on the GTP-U entity restart
17.5 Packet Flow Description management enhancement
17.6 PAP/CHAP protocols usage in 5GS
17.7 Start of Pause of Charging via User Plane
17.8 Enhancement of Handover Optimization
17.9 Restoration of Profiles related to UDR
17.10 IP address pool information from UDM
17.11 Dynamic management of group-based event monitoring
17.12 Dynamically Changing AM Policies in the 5GC
17.13 Other aspects

18 Standalone Management Features
18.1 Introduction
18.2 Enhanced Closed loop SLS Assurance
18.3 Enhancement of QoE Measurement Collection
18.4 Plug and connect support for management of Network Functions
18.5 Management of MDT enhancement in 5G
18.6 Management Aspects of 5G Network Sharing
18.7 Discovery of management services in 5G
18.8 Management of the enhanced tenant concept
18.9 Intent driven management service for mobile network
18.10 Improved support for NSA in the service-based management architecture
18.11 Additional Network Resource Model features
18.12  Charging for Local breakout roaming of data connectivity
18.13 File Management
18.14 Management data collection control and discovery
18.15 Other charging and management aspects

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

Related Posts

Wednesday, 30 November 2022

Disaster Roaming in 3GPP Release-17

One way all operators in a country/region/geographic area differentiate amongst themselves is by the reach of their network. It's not in their interest to allow national roaming. Occasionally a regulator may force them to allow this, especially in rural or remote areas. Another reason why operators may choose to allow roaming is to reduce their network deployment costs. 

In case of disasters or emergencies, if an operator's infrastructure goes down, the subscribers of that network can still access other networks for emergencies but not for normal services. This can cause issues as some people may not be able to communicate with friends/family/work. 

A recent example of this kind of outage was in Japan, when the KDDI network failed. Some 39 million users were affected and many of them couldn't even do emergency calls. If Disaster Roaming was enabled, this kind of situation wouldn't occur.

South Korea already has a proprietary disaster roaming system in operation since 2020, as can be seen in the video above. This automatic disaster roaming is only available for 4G and 5G.

In 3GPP Release-17, Disaster Roaming has been specified for LTE and 5G NR. In case of LTE, the information is sent in SIB Type 30 while in 5G it is in SIB Type 15.

3GPP TS 23.501 section 5.40 provides summary of all the other information needed for disaster roaming. Quoting from that:

Subject to operator policy and national/regional regulations, 5GS provides Disaster Roaming service (e.g. voice call and data service) for the UEs from PLMN(s) with Disaster Condition. The UE shall attempt Disaster Roaming only if:

  • there is no available PLMN which is allowable (see TS 23.122 [17]);
  • the UE is not in RM-REGISTERED and CM-CONNECTED state over non-3GPP access connected to 5GCN;
  • the UE cannot get service over non-3GPP access through ePDG;
  • the UE supports Disaster Roaming service;
  • the UE has been configured by the HPLMN with an indication of whether Disaster roaming is enabled in the UE set to "disaster roaming is enabled in the UE" as specified in clause 5.40.2; and
  • a PLMN without Disaster Condition is able to accept Disaster Inbound Roamers from the PLMN with Disaster Condition.

In this Release of the specification, the Disaster Condition only applies to NG-RAN nodes, which means the rest of the network functions except one or more NG-RAN nodes of the PLMN with Disaster Condition can be assumed to be operational.

A UE supporting Disaster Roaming is configured with the following information:

  • Optionally, indication of whether disaster roaming is enabled in the UE;
  • Optionally, indication of 'applicability of "lists of PLMN(s) to be used in disaster condition" provided by a VPLMN';
  • Optionally, list of PLMN(s) to be used in Disaster Condition.

The Activation of Disaster Roaming is performed by the HPLMN by setting the indication of whether Disaster roaming is enabled in the UE to "disaster roaming is enabled in the UE" using the UE Parameters Update Procedure as defined in TS 23.502 [3]. The UE shall only perform disaster roaming if the HPLMN has configured the UE with the indication of whether disaster roaming is enabled in the UE and set the indication to "disaster roaming is enabled in the UE". The UE, registered for Disaster Roaming service, shall deregister from the PLMN providing Disaster Roaming service if the received indication of whether disaster roaming is enabled in the UE is set to "disaster roaming is disabled in the UE".

Check the specs out for complete details. 

From my point of view, it makes complete sense to have this enabled for the case when disaster strikes. Earlier this year, local governments in Queensland, Australia were urging the Federal Government to immediately commit to a trial of domestic mobile roaming during emergencies based on the recommendation by the Regional Telecommunications Independent Review Committee. Other countries and regions would be demanding this sooner or later as well. It is in everyone's interest that the operators enable this as soon as possible.

Related Posts:

Monday, 22 August 2022

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

Wednesday, 10 August 2022

AI/ML Enhancements in 5G-Advanced for Intelligent Network Automation

Artificial Intelligence (AI) and Machine Learning (ML) has been touted to automate the network and simplify the identification and debug of issues that will arise with increasing network complexity. For this reason 3GPP has many different features that are already present in Release-17 but are expected to evolve further in Release-18. 

I have already covered some of this topics in earlier posts. Ericsson's recent whitepaper '5G Advanced: Evolution towards 6G' also has a good summary on this topic. Here is an extract from that:

Intelligent network automation

With increasing complexity in network design, for example, many different deployment and usage options, conventional approaches will not be able to provide swift solutions in many cases. It is well understood that manually reconfiguring cellular communications systems could be inefficient and costly.

Artificial intelligence (AI) and machine learning (ML) have the capability to solve complex and unstructured network problems by using a large amount of data collected from wireless networks. Thus, there has been a lot of attention lately on utilizing AI/ML-based solutions to improve network performance and hence providing avenues for inserting intelligence in network operations.

AI model design, optimization, and life-cycle management rely heavily on data. A wireless network can collect a large amount of data as part of its normal operations. This provides a good base for designing intelligent network solutions. 5G Advanced addresses how to optimize the standardized interfaces for data collection while leaving the automation functionality, for example, training and inference up to the proprietary implementation to support full flexibility in the automation of the network.

AI/ML for RAN enhancements

Three use cases have been identified in the Release 17 study item related to RAN performance enhancement by using AI/ML techniques. Selected use cases from the Release 17 technical report will be taken into the normative phase in the next releases. The selected use cases are: 1) network energy saving; 2) load balancing; and 3) mobility optimization.

The selected use cases can be supported by enhancements to current NR interfaces, targeting performance improvements using AI/ML functionality in the RAN while maintaining the 5G NR architecture. One of the goals is to ensure vendor incentives in terms of innovation and competitiveness by keeping the AI model implementation specific. As shown in Fig.2 (on the top) an intent-based management approach can be adopted for use cases involving RAN-OAM interactions. The intent will be received by the RAN. The RAN will need to understand the intent and trigger certain functionalities as a result.

AI/ML for physical layer enhancements

It is generally expected that AI/ML functionality can be used to improve the radio performance and/or reduced the complexity/overhead of the radio interface. 3GPP TSG RAN has selected three use cases to study the potential air interface performance improvements through AI/ML techniques, such as beam management, channel state information feedback enhancement, and positioning accuracy enhancements for different scenarios. The AI/ML-based methods may provide benefits compared to traditional methods in the radio interface. The challenge will be to define a unified AI/ML framework for the air interface by adequate AI/ML model characterization using various levels of collaboration between gNB and UE.

AI/ML in 5G core

5G Advanced will provide further enhancements of the architecture for analytics and on ML model life-cycle management, for example, to improve correctness of the models. The advancements in the architecture for analytics and data collection serve as a good foundation for AI/ML-based use cases within the different network functions (NFs). Additional use cases will be studied where NFs make use of analytics with the target to support in their decision making, for example, network data analytics functions (NWDAF)- assisted generation of UE policy for network slicing.

If you are interested in studying this topic further, check out 3GPP TR 37.817: Study on enhancement for data collection for NR and ENDC. Download the latest version from here.

Related Posts

Wednesday, 4 May 2022

ATIS Webinar on '5G Standards Development Update in 3GPP Release 17 and 18'

Our blog post on ATIS Release-16 webinar has been one of the popular posts so it's no brainer that people will surely find this Release 17/18 update useful as well. 

The moderator for this webinar was Iain Sharp, Principal Technologist at ATIS. The following were the speakers and the topics they spoke on:

  • Services: Greg Schumacher, Global Standards, T-Mobile USA
  • Systems Architecture and Core Networks: Puneet Jain, Principal Engineer and Director of Technical Standards at Intel Corporation, and 3GPP SA2 Chairman
  • Radio Access Network: Wanshi Chen, Senior Director,Technology at Qualcomm, and 3GPP RAN Chairman

Here is a summary of the webinar:

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

The webinar will cover:

  • The status of 3GPP's work and the organization's roadmap for the future
  • The main themes the delivered Release 17 features in 3GPP specifications
  • How enhancements to 5G are helping the 5G market proposition (e.g., through new service opportunities, or enhanced efficiency of 5G networks)

The webinar will give a technical overview of 3GPP's Release 17 content and its benefits to 5G networks. It is suitable for people in technical roles and technical executives who want to understand the current state of 5G standardization.

The video is embedded below and the slides are available here:

Glad to see that 3GPP Rel-19 work has already started as can be seen in the roadmap below.

(click to enlarge)

Related Posts

Monday, 11 April 2022

3GPP Release-17 5G NR Reaches Completion

In the last week of March 2022, 3GPP Release 17 reached stage 3 functional freeze. Now the ASN work is ongoing and it will be frozen in June 2022. After that point, any changes will need to be submitted to 3GPP as CR (change request) and would have to be agreed by everyone (or unopposed).

Juan Montojo, Vice President, Technical Standards, Qualcomm Technoloigies, in his blog post reminds us:

Release 17 has been completed with its scope largely intact, despite the fact that the entire release was developed in the midst of a pandemic that hit the world, including 3GPP, right after the scope of the Release was approved in December 2019. 3GPP has been operating through electronic means from the latter part of January 2020 and has yet to get back to face-to-face meetings and interactions. The return to face-to-face meetings is not expected before June 2022. Release 17 completion not only marks the conclusion of the first phase of the 5G technology evolution, but it is a testament to the mobile ecosystem’s resiliency and commitment to drive 5G forward. I couldn’t be more proud of 3GPP, and our team, in particular, as Qualcomm Technologies led the efforts across a wide range of projects. Release 17 delivers another performance boost to the 5G system and continues expanding 5G into new devices, applications, and deployments.

The blog post briefly explains the 'New and enhanced 5G system capabilities' as well as features related to 'Expansion to new 5G devices and applications' as shown in the image on the top.

In addition, 3GPP Rel-17 has many other projects as can be seen in the image above. 3GPP TR 21.917: Release 17 Description; Summary of Rel-17 Work Items has a summary of all the items above but it is still undergoing revision.

Juan also did a webinar on this topic with Fierce Wireless, the video is embedded below:

The slides could be obtained from here.

Related Posts

Tuesday, 25 January 2022

3GPP Release-18 Work Moves Into Focus as Release-17 Reaches Maturity

In early December 2021, 3GPP reached a consensus on the scope of 5G NR Release-18. With the 3GPP Rel-17 functional freeze set for March 2022, Release-18 work is moving into focus. This is being billed as a significant milestone marking the beginning of 5G Advanced — the second wave of wireless innovations that will fulfil the 5G vision. Release 18 is expected to build on the solid foundation set by 3GPP Releases 15, 16, and 17, and it sets the longer-term evolution direction of 5G and beyond.

(click on the image to enlarge - PDF here)

The 3GPP Release-18 page has a concise summary of all that you need to know, including the timeline. For anyone interested in going through features one-by-one, start navigating from here, select Rel-18 from the top.

For others who may be more interested in summary rather than a lot of details, here are some good links to navigate:

  • Nokia whitepaper - 5G-Advanced: Expanding 5G for the connected world (link)
  • Paper by Ericsson researcher, Xingqin Lin, 'An Overview of 5G Advanced Evolution in 3GPP Release 18' (link)
  • Marcin DryjaÅ„ski, Rimedo Labs - 3GPP Rel-18: 5G-Advanced RAN Features (link)
  • Bevin Fletcher, FierceWireless: Next 3GPP standard tees up 5G Advanced (link)

As always, Qualcomm has a fantastic summary of 5G evolution and features in 3GPP Release-18 on their page here. The image above nicely shows the evolution of 5G from Release-15 all the way to Release-18. The image below shows a summary of 3GPP Release-18, 5G-Advanced features.

They also hosted a webinar with RCR wireless. The webinar is embedded below.

The slides can be downloaded from GSA website (account required, free to register) here.

Related Posts