Showing posts with label LTE. Show all posts
Showing posts with label LTE. Show all posts

Wednesday 14 August 2024

3GPP Release 18 Description and Summary of Work Items

The first official release of 3GPP TR 21.918: "Release 18 Description; Summary of Rel-18 Work Items" has been published. It's the first official version of 5G-Advanced. Quoting from the report: 

Release 18 specifies further improvements of the 5G-Avanced system. 

These improvements consist both in enhancements of concepts/Features introduced in the previous Releases and in the introduction of new topics.

Some of the key improvements are:

  • a further integration of the Satellite (NTN) access (introduced in Rel-17) in the 5G System (5GS), 
  • a more efficient support of Internet of Things (IoT), Machine-Type Communication (MTC), including by satellite coverage
  • and also several aspects of proximity communication and location (Sidelink, Proximity, Location and Positioning, better support of the industrial needs (Verticals, Industries, Factories, Northbound API), Multicast and Broadcast Services (MBS), Network Slicing or Uncrewed Aerial Vehicles (UAV).

As for the new topics, some of the key aspects are:

  • Energy Efficiency (EE)
  • Artificial Intelligence (AI)/Machine Learning (ML)
  • eXtended, Augmented and Virtual Reality (XR, AR, VR), immersive communications

The following list is from the v1.0.0 table of contents to make it easier to find the list of topics. If it interests you, download the latest version technical report from the directory here.

5 Satellite / Non-Terrestrial Network (NTN)
5.1 General aspects
5.1.1 User plane: “5G system with satellite backhaul”
5.1.2 Discontinuous coverage: “Satellite access Phase 2”
5.1.3 Radio: "NR NTN enhancements"
5.1.4 Charging and Management aspects of Satelite
5.2 Specific aspects
5.2.1 IoT (Internet of Things) NTN enhancements
5.2.2 Guidelines for Extra-territorial 5G Systems
5.2.3 5G system with satellite access to Support Control and/or Video Surveillance
5.2.4 Introduction of the satellite L-/S-band for NR
5.2.5 Other band-related aspects of satellite

6 Internet of Things (IoT), Machine-Type Communication (MTC)
6.1 Personal IoT and Residential networks
6.2 Enhanced support of Reduced Capability (RedCap) NR devices
6.3 NR RedCap UE with long eDRX for RRC_INACTIVE State
6.4 Application layer support for Personal IoT Network
6.5 5G Timing Resiliency System
6.6 Mobile Terminated-Small Data Transmission (MT-SDT) for NR
6.7 Adding new NR FDD bands for RedCap in Rel-18
6.8 Signal level Enhanced Network Selection
6.9 IoT NTN enhancements

7 Energy Efficiency (EE)
7.1 Enhancements of EE for 5G Phase 2
7.2 Network energy savings for NR
7.3 Smart Energy and Infrastructure

8 Uncrewed Aerial Vehicles (UAV), UAS, UAM
8.1 Architecture for UAV and UAM Phase 2
8.2 Architecture for UAS Applications, Phase 2
8.3 NR support for UAV
8.4 Enhanced LTE Support for UAV

9 Sidelink, Proximity, Location and Positioning
9.1 5GC LoCation Services - Phase 3
9.2 Expanded and improved NR positioning
9.3 NR sidelink evolution
9.4 NR sidelink relay enhancements
9.5 Proximity-based Services in 5GS Phase 2
9.6 Ranging-based Service and sidelink positioning
9.7 Mobile Terminated-Small Data Transmission (MT-SDT) for NR
9.8 5G-enabled fused location service capability exposure

10 Verticals, Industries, Factories, Northbound API
10.1 Low Power High Accuracy Positioning for industrial IoT scenarios
10.2 Application enablement aspects for subscriber-aware northbound API access
10.3 Smart Energy and Infrastructure
10.4 Generic group management, exposure and communication enhancements
10.5 Service Enabler Architecture Layer for Verticals Phase 3
10.6 SEAL data delivery enabler for vertical applications
10.7 Rel-18 Enhancements of 3GPP Northbound and Application Layer interfaces and APIs
10.8 Charging Aspects of B2B
10.9 NRF API enhancements to avoid signalling and storing of redundant data
10.10 GBA_U Based APIs
10.11 Other aspects

11 Artificial Intelligence (AI)/Machine Learning (ML)
11.1 AI/ML model transfer in 5GS
11.2 AI/ML for NG-RAN
11.3 AI/ML management & charging
11.4 NEF Charging enhancement to support AI/ML in 5GS

12 Multicast and Broadcast Services (MBS)
12.1 5G MBS Phase 2
12.2 Enhancements of NR MBS
12.3 UE pre-configuration for 5MBS
12.4 Other MBS aspects

13 Network Slicing
13.1 Network Slicing Phase 3
13.2 Enhancement of NSAC for maximum number of UEs with at least one PDU session/PDN connection
13.3 Enhancement of Network Slicing UICC application for network slice-specific authentication and authorization
13.4 Charging Aspects of Network Slicing Phase 2
13.5 Charging Aspects for NSSAA
13.6 Charging enhancement for Network Slice based wholesale in roaming
13.7 Network Slice Capability Exposure for Application Layer Enablement
13.8 Other slice aspects

14 eXtended, Augmented and Virtual Reality (XR, AR, VR), immersive
14.1 XR (eXtended Reality) enhancements for NR
14.2 Media Capabilities for Augmented Reality
14.3 Real-time Transport Protocol Configurations
14.4 Immersive Audio for Split Rendering Scenarios  (ISAR)
14.5 Immersive Real-time Communication for WebRTC
14.6 IMS-based AR Conversational Services
14.7 Split Rendering Media Service Enabler
14.8 Extended Reality and Media service (XRM)
14.9 Other XR/AR/VR items

15 Mission Critical and emergencies
15.1 Enhanced Mission Critical Push-to-talk architecture phase 4
15.2 Gateway UE function for Mission Critical Communication
15.3 Mission Critical Services over 5MBS
15.4 Mission Critical Services over 5GProSe
15.5 Mission Critical ad hoc group Communications
15.6 Other Mission Critical aspects

16 Transportations (Railways, V2X, aerial)
16.1 MBS support for V2X services
16.2 Air-to-ground network for NR
16.4 Interconnection and Migration Aspects for Railways
16.5 Application layer support for V2X services; Phase 3
16.6 Enhanced NR support for high speed train scenario in frequency range 2 (FR2)

17 User Plane traffic and services
17.1 Enhanced Multiparty RTT
17.2 5G-Advanced media profiles for messaging services
17.3 Charging Aspects of IMS Data Channel
17.4 Evolution of IMS Multimedia Telephony Service
17.5 Access Traffic Steering, Switch and Splitting support in the 5G system architecture; Phase 3
17.6 UPF enhancement for Exposure and SBA
17.7 Tactile and multi-modality communication services
17.8 UE Testing Phase 2
17.9 5G Media Streaming Protocols Phase 2
17.10 EVS Codec Extension for Immersive Voice and Audio Services
17.11 Other User Plane traffic and services items

18 Edge computing
18.1 Edge Computing Phase 2
18.2 Architecture for enabling Edge Applications Phase 2
18.3 Edge Application Standards in 3GPP and alignment with External Organizations

19 Non-Public Networks
19.1 Non-Public Networks Phase 2
19.2 5G Networks Providing Access to Localized Services
19.3 Non-Public Networks Phase 2

20 AM and UE Policy
20.1 5G AM Policy
20.2 Enhancement of 5G UE Policy
20.3 Dynamically Changing AM Policies in the 5GC Phase 2
20.4 Spending Limits for AM and UE Policies in the 5GC
20.5 Rel-18 Enhancements of UE Policy

21 Service-based items
21.1 Enhancements on Service-based support for SMS in 5GC
21.2 Service based management architecture
21.3 Automated certificate management in SBA
21.4 Security Aspects of the 5G Service Based Architecture Phase 2
21.5 Service Based Interface Protocol Improvements Release 18

22 Security-centric aspects
22.1 IETF DTLS protocol profile for AKMA and GBA
22.2 IETF OSCORE protocol profiles for GBA and AKMA
22.3 Home network triggered primary authentication
22.4 AKMA phase 2
22.5 5G Security Assurance Specification (SCAS) for the Policy Control Function (PCF)
22.6 Security aspects on User Consent for 3GPP services Phase 2
22.7 SCAS for split-gNB product classes
22.8 Security Assurance Specification for AKMA Anchor Function Function (AAnF)
22.9 Other security-centric items

23 NR-only items
23.1 Not band-centric
23.1.1 NR network-controlled repeaters
23.1.2 Enhancement of MIMO OTA requirement for NR UEs
23.1.3 NR MIMO evolution for downlink and uplink
23.1.4 Further NR mobility enhancements
23.1.5 In-Device Co-existence (IDC) enhancements for NR and MR-DC
23.1.6 Even Further RRM enhancement for NR and MR-DC
23.1.7 Dual Transmission Reception (TxRx) Multi-SIM for NR
23.1.8 NR support for dedicated spectrum less than 5MHz for FR1
23.1.9 Enhancement of NR Dynamic Spectrum Sharing (DSS)
23.1.10 Multi-carrier enhancements for NR
23.1.11 NR RF requirements enhancement for frequency range 2 (FR2), Phase 3
23.1.12 Requirement for NR frequency range 2 (FR2) multi-Rx chain DL reception
23.1.13 Support of intra-band non-collocated EN-DC/NR-CA deployment
23.1.14 Further enhancements on NR and MR-DC measurement gaps and measurements without gaps
23.1.15 Further RF requirements enhancement for NR and EN-DC in frequency range 1 (FR1)
23.1.16 Other non-band related items
23.2 Band-centric
23.2.1 Enhancements of NR shared spectrum bands
23.2.2 Addition of FDD NR bands using the uplink from n28 and the downlink of n75 and n76
23.2.3 Complete the specification support for BandWidth Part operation without restriction in NR
23.2.4 Other NR band related topics

24 LTE-only items
24.1 High Power UE (Power Class 2) for LTE FDD Band 14
24.2 Other LTE-only items

25 NR and LTE items
25.1 4Rx handheld UE for low NR bands (<1GHz) and/or 3Tx for NR inter-band UL Carrier Aggregation (CA) and EN-DC
25.2 Enhancement of UE TRP and TRS requirements and test methodologies for FR1 (NR SA and EN-DC)
25.3 Other items

26 Network automation
26.1 Enablers for Network Automation for 5G phase 3
26.2 Enhancement of Network Automation Enablers

27 Other aspects
27.1 Support for Wireless and Wireline Convergence Phase 2
27.2 Secondary DN Authentication and authorization in EPC IWK cases
27.3 Mobile IAB (Integrated Access and Backhaul) for NR
27.4 Further NR coverage enhancements
27.5 NR demodulation performance evolution
27.6 NR channel raster enhancement
27.7 BS/UE EMC enhancements for NR and LTE
27.8 Enhancement on NR QoE management and optimizations for diverse services
27.9 Additional NRM features phase 2
27.10 Further enhancement of data collection for SON (Self-Organising Networks)/MDT (Minimization of Drive Tests) in NR and EN-DC
27.11 Self-Configuration of RAN Network Entities
27.12 Enhancement of Shared Data ID and Handling
27.13 Message Service within the 5G system Phase 2
27.14 Security Assurance Specification (SCAS) Phase 2
27.15 Vehicle-Mounted Relays
27.16 SECAM and SCAS for 3GPP virtualized network products
27.17 SECAM and SCAS for 3GPP virtualized network products
27.18 MPS for Supplementary Services
27.19 Rel-18 enhancements of session management policy control
27.20 Seamless UE context recovery
27.21 Extensions to the TSC Framework to support DetNet
27.22 Multiple location report for MT-LR Immediate Location Request for regulatory services
27.23 Enhancement of Application Detection Event Exposure
27.24 General Support of IPv6 Prefix Delegation in 5GS
27.25 5G Timing Resiliency System
27.26 MPS when access to EPC/5GC is WLAN
27.27 Data Integrity in 5GS
27.28 Security Enhancement on RRCResumeRequest Message Protection

28 Administration, Operation, Maintenance and Charging-centric Features
28.1 Introduction
28.2 Intent driven Management Service for Mobile Network phase 2
28.3 Management of cloud-native Virtualized Network Functions
28.4 Management of Trace/MDT phase 2
28.5 Security Assurance Specification for Management Function (MnF)
28.6 5G performance measurements and KPIs phase 3
28.7 Access control for management service
28.8 Management Aspects related to NWDAF
28.9 Management Aspect of 5GLAN
28.10 Charging Aspects of TSN
28.11 CHF Distributed Availability
28.12 Management Data Analytics phase 2
28.12 5G System Enabler for Service Function Chaining
28.13 Other Management-centric items

29 Other Rel-18 Topics

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

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , , , ,

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: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Monday 6 May 2024

6G and Other 3GPP Logos

The Project Coordination Group (PCG) of 3GPP recently approved a new logo for use on specifications for 6G, during their 52nd PCG meeting, hosted by ATIS in Reston, Virginia. As with previous logos, surely people in general will use them not just for 3GPP 6G compliant products, but for all kinds of things.

Over the years many people have reached out to me to ask for 3GPP logos, even though they are available publicly. All 3GPP logos, from 3G to 6G is available in the Marcoms directory here. In addition to the logo, each directory also lists guidance for use of the logos. For example, 3GPP does not allow the use of the logo as shown on the left in the image on top of the post while the one on the right is okay.

Surely there isn't an issue for general use but for anyone wishing to use the logos for their products, equipment, documentation or books, they will have to strictly comply with the rules.

Related Posts: 

Posted by Zahid Ghadialy at 14:35 Leave a comment...0 comments so far
Labels: , , , , , , ,

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: 

Posted by Zahid Ghadialy at 07:33 Leave a comment...0 comments so far
Labels: , , , , , , , , , , ,

Wednesday 13 September 2023

Private Networks Introductory Series

Private Networks has been a hot topic for a while now. We made a technical introductory video which has over 13K views while its slides have over 25K views. The Private Networks blog that officially started in April is now getting over 2K views a month. 

In addition, there are quite a few questions and enquiries that I receive on them on a regular basis. With this background, it makes sense to add these Introductory video series by Firecell in a post. Their 'Private Networks Tutorial Series' playlist, aiming to demystify private networks, is embedded below:

The playlist has five videos at the moment, hopefully they will add more:

  • Introduction to different kinds of mobile networks: public, private and hybrid networks
  • Different Names for Private Networks
  • Drivers and Enablers of Private Networks
  • Mobile Cellular vs Wi-Fi Private Networks
  • Architecture of Mobile Private Networks

I also like this post on different names for private networks.

Related Posts: 

Posted by Zahid Ghadialy at 18:35 Leave a comment...0 comments so far
Labels: , , , , , ,

Thursday 3 August 2023

Tutorial: A Quick Introduction to 3GPP

We recently made a beginners tutorial explaining the need for The 3rd Generation Partnership Project (3GPP), its working, structure and provides useful pointers to explore further. The video and slides are embedded below.

You can download the slides from here.

Related Posts: 

Posted by Zahid Ghadialy at 07:35 Leave a comment...0 comments so far
Labels: , , , , ,

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: 

Posted by Zahid Ghadialy at 19:35 Leave a comment...0 comments so far
Labels: , , , , , , , , , , , ,

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: 

Posted by Zahid Ghadialy at 10:35 Leave a comment...0 comments so far
Labels: , , ,

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:

Posted by Zahid Ghadialy at 07:35 Leave a comment...1 comments so far
Labels: , , , , , , , , , , ,

Friday 26 August 2022

How Multiband-Cells are used for MORAN RAN Sharing

In the previous blog post I have explained the concept of multi-band cells in LTE networks and promised to explain a bit deeper how such cells can be used in Multi-Operator RAN (MORAN) scenarios. 

MORAN is characterized by the fact that all network resources except the radio carriers and the Home Subscriber Server (HSS) are shared between two or more operators. 

What this means in detail can be see in Step 1 of the figure below. 

The yellow Band #1 spectrum of the multi-band cell is owned by Network Operator 1 while the blue spectrum of Band #2 and Band #3 belongs to Network Operator 2.

Band #1 is the default band. This means if a UE enters the cell is always has to establish the initial RRC signaling connection on Band #1 as shown in step 1.

The spectrum owned by Network Operator 2 comes into the game as soon as a dedicated radio bearer (DRB), in the core network known as E-RAB, is established in this RRC connection. 

Then we see intra-frequency (intra-cell) handover to Band #2 where the RRC signaling connection is continued. Band #3 is added for user plane transport as a secondary "cell" (the term refers to the 3GPP 36.331 RRC specification). 

The reason for this behavior can be explained when looking a frequency bandwidths. 

The default Band #1 is a low frequency band with a quite small bandwidth, e.g. 5 MHz. as it is typically used for providing good coverage in rural areas. Band #2 is also a lower frequency band, but Band #3 is a high frequency band with maximum bandwidth of 20 MHz. So Band #3 brings the highest capacity for user plane transport and that is the reason for the handover to the spectrum owned by Network Operator 2 and the carrier aggregation used on these frequency bands. 

However, due to the higher frequency the footprint of Band #3 is lower compared to the other two frequency bands. 

For UEs at the cell edge (or located in buildings while being served from the outdoor cell) this leads quite often to situations where the radio coverage of Band #3 becomes insufficient. In such cases the UE typically sends a RRC measurement event A2 (means: "The RSRP of the cell is below a certain threshold."). 

If such A2 event is received by the eNB it stops the carrier aggregation transport and releases the Band #3 resources so that all user plane transport continues to run on the limited Band #2 resources as shown in step 3.

And now in the particular eNB I observed a nice algorithm starts that could be seen as a kind of zero-touch network operation although it does not need big data nor artificial intelligence. 

10 seconds after the secondary frequency resources of Band #3 have been deleted they are added again to the connection, but if the UE is still at the same location the next A2 will be reported soon and carrier aggregation will be stopped again for 10 seconds and then the next cycle starts.

This automation loop is carried out endlessly until the UE changes its location or the RRC connection is terminated. 

Related Posts:

Posted by Ralf Kreher at 11:48 Leave a comment...1 comments so far
Labels: , , , , , ,
Subscribe to: Posts (Atom)