Showing posts with label NR RRC. Show all posts
Showing posts with label NR RRC. Show all 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:

Thursday 4 November 2021

Voice over New Radio (VoNR) Establishment and Release between NG RAN and 5G Core

In this video I explain how QoS Flows for VoNR are established and released especially on N2 reference point between 5G Core and NG RAN.

The pervious video about generic aspects of "QoS Flow Establishments in 5G Standalone RAN and Core" you will find in the first link of the Related Posts listed below:

Monday 14 June 2021

A mmWave Special Cell in Open RAN Environment

NR RRC signaling messages exchanged for establishing a 5G radio connection, in particular the NR RRC Reconfiguration and NR RRC CG Config messages, contain a parameter called "SpCellID", which refers to the Special Cell ID. 

The concept of the Special Cell already exists in 3GPP LTE Advanced standards. Here a Special Cell is set of physical cells with same or different carrier frequency and physical cell ID (PCI) that overlap in a certain geographical area and thus, are combined for data transmission to/from UEs located in this area.

This concept now also gains high importance for 5G NR mmWave spectrum and here is why:

Many 5G mmWave radio transmitters can only handle a maximum bandwidth of 100 MHz, but the radio sector shall be covered with total bandwidth of e.g. 600 MHz. To achieve this six mmWave radio transmitters are installed in parallel at the same spot covering the same footprint. 

Each transmitter is identified on the radio interface by its own dedicated NR ARFCN (carrier frequency) and PCI. Thus, from UE point of view the sector is covered with 6 dedicated NR cells that all together form a Special Cell.

When a UE gets radio resources assigned in this 5G sector one of  the 6 cells is the Primary Cell, which NR CGI (Cell Global Identity) is then used as Special Cell ID in layer 3 signaling messages. All other cells act as Secondary Cells.

In an Open RAN environment the F1AP protocol allows perfect analysis of the SpCell resource allocation since it contains the SpCellID as well as all SCellIDs to be setup in the call. 

If the gNB-DU fails to allocated resources for a particular Secondary Cell this will also be signaled together with a failure cause value on F1AP as illustrated in the figure below. Also radio link failures occurring within the Special Cell will be signaled on F1AP including a cause value that provides deeper insight than  protocol causes seen on X2AP (in case of 5G NSA connections) or NGAP (in case of 5G SA connections). 

(click on image to enlarge)