Cell Broadcast Service or Public Warning System in 5G

  • Cell Broadcast Service or Public warning system is part of 5G cell broadcast mechanism.
  • Cell Broadcast Centre Function(CBCF), is generic broadcast centre responsible for all kind of broadcast messages including paid advertisement.
  • Public Warning System(PWS) is specific to public warning related broadcast messages like Earthquake, Tsunami etc.
Cell Broadcast and public warning system topology
  • Both the entities can Write/Replace/Cancel broadcast messages to AMF via Namf SAP(N50) interface.
  • When writing Broadcast message to AMF, CBCF/PWS need to provide the content of the message, message ID, number of broadcast, broadcast intervals etc.
  • At any point of time CBCF/PWS can cancel a broadcast by specifying the message ID that is currently actively broadcasted.

Warnning message delivery procedure in NG-RAN

Write/Replace Warnning message by AMF to NG-RAN

PWS Cancel Procedure

PWS Restart indication

PWS Failure Indication

Emergency Services(E911) FallBack procedures in 5G

1.1     Emergency Services FallBack ES-FB

1.1.1     Introduction

Service Request for emergency: This solution is new in 5GS, i.e., there is no equivalent in 4G. The UE uses service-request for emergency towards AMF if support for this feature has been indicated by the AMF. If receiving the service request for emergency, the AMF interacts with gNB to perform EPS Fallback. In this solution, there is no need for NR and 5GC to support emergency features other than needed for service-request for emergency handling. However, voice over NR (possibly including EPS Fallback) has to be supported on NR and 5GC (otherwise the UE would not even camp on NR).

If the 5GC has indicated Emergency Services Fallback support for the TA and RAT where the UE is currently camping, and if the UE supports emergency services fallback, the UE shall initiate the Emergency Services Fallback procedure described below in section 1.1.3.2

1.1.2     Registration Procedure (Message / IEs related with Emergency Support)

1.1.3     Emergency Service FallBack

1.1.3.1     23.502 Call Flow for Emergency Service FallBack (ES-FB)

1.1.3.2     General Call Flow for Emergency Service FallBack (ES-FB) . Redirection Case

  1. UE camps on E-UTRA or NR cell in the 5GS (in either CM_IDLE or CM_CONNECTED state).
  2. In SIB1 (optional) , NW indicate support for Emergency.
  3. Registration Request from UE set required parameters like “Voice Centric” and “S1 Mode “Flag.
  4. In Registration Accept message, NW indicates  VoPS flag as TRUE and EMF flag as Non Zero (01 – 11) and EMC Flag as 00.
  5. UE sends a Service Request message as requesttype as emergency services fallback. The UE is not required to include the PDU Sessions that are not relevant for the emergency service in the List Of PDU Sessions to be Activated in the Service Request for the emergency service.
  6. For Redirection case, NW trigger Intersystem Redirection by sending RRCRelease message with RedirectInfo as E-ARFCN and VoiceFallBackIndication as TRUE.
  7. RRCConnectionRequest on LTE with establishmentcause as “Emergency” triggered.
  8. TAU procedure triggered with active flag to indicate that the UE has “user data pending”.
  9. After redirection to the target cell the UE establishes a PDN connection for IMS emergency services and performs the IMS procedures for establishment of an IMS emergency session.

1.1.3.3     Emergency Service FallBack (ES-FB) during QoS Flow Establishment

  1. If Emergency Services Fallback occurs during QoS Flow establishment than this is the same procedure as defined during EPS Fallback ( check older post for EPS – FallBack call flow). Only additional/different procedures for Emergency Services FallBack are mentioned below:
  2. In Registration Accept message, NW indicates that EMF as 01 and EMC as 00 .
  3. INTERNET and IMS PDU Session established.
  4. SoS / Emergency PDU session established and P-CSCF  and IP assigned to the UE.
  5. During E911 call initiation, Call FallBack to EPS due to lack of QoS Flow establishment for Emergency call on 5GS.
  6. Redirection procedure triggered with RRCRelease with E-UTRA ARFCN info and voicefallbackindication flag as TRUE.
  7. As N26 interface supported, UE trigger TAU Request with three (Emergency, Internet, IMS PDN) as Active. RRCCoonectionRequest with establishmentcause as “Emergency” used on EUTRA / EPS.
  8. Once All three PDN become active, Emergency call established on LTE.

1.2     References

  • 24.229
  • 23.502
  • 24.501
  • 24.301
  • 23.501
  • GSMA NG.114
  • 38.331
  • 38.413

EPS Fallback Voice in 5G

1.1     Introduction

Voice over NR with EPS Fallback includes an additional mobility trigger by which the UE falls back from NG-RAN to LTE during call establishment. This may be needed, e.g., in case not all feature for voice over NR are implemented in the UE or in case of temporary lack of radio resources in NR.

EPS fallback is an additional mobility trigger for improving voice KPIs. EPS Fallback enables phones to use the 5GC with NR, but RAN may trigger moving the phone LTE connected to EPC during call establishment. The reason for moving the UE to LTE can be :

  • temporary lack of radio resources in NR for voice
  • the UE is in area where NR in 5GS is not dimensioned and tuned for voice
  • Prior to all needed voice features are in place in the phone.

A smartphone (UE), connected to NR that tries to establish a voice connection, may perform an EPS fallback at call setup, triggered by the attempt to establish the Quality-of-Service (QoS) flow for voice media in NR.

At the attempt to establish the QoS flow for the voice media over NR during call set-up, the NG-RAN rejects the QoS flow setup towards the SMF with an indication that mobility is in progress. The NG-RAN initiates transfer of all PDU sessions from 5GS to EPS, using one of the two standardized procedures:

  • Release with redirect
  • Inter-system handover

1.2     Technical Aspect

When a UE moves from EPC to 5GC, the UE always performs Registration procedure.

When a UE moves from 5GC to EPC, the UE performs either Tracking Area Update or Initial Attach.

The UE performs Tracking Area Update procedure if :

–    Both the UE and the EPC support “attach without PDN connectivity”, or

–    The UE has at least one PDU Session for which Session Continuity is supported during interworking, i.e. the UE has EPS Bearer ID and mapped EPS QoS parameters received as described in clause 4.11.1.1 of 23.502.

The UE performs an initial attach procedure if :

–    The UE is registered without PDU Session in 5GC or the UE is registered only with PDU Session for which Session Continuity is not supported during interworking to EPC, and

     –         Either the UE or the EPC does not support attach without PDN connectivity

1.3     3GPP CallFlow from 3GPP 23.502

Please refer Section 4.13.6.1 of 3GPP 23.502

1.4     General CallFlow in Details

1.4.1     End to End Call Flow (Redirection and N26 Supported)

End to End EPS Fallback with N26 and Redirection Supported
  1. During “Registration Request” from UE, it will indicate UE Usage Settings as “Voice Centric” and “S1 Mode “ is TRUE.
  2. AMF request NGRAN to enquire about IMS Voice Support on NR from UE. NGRAN send UE Capability Enquiry –NR to UE.
  3. UE send UECapabiltyInformtion-NR Capability with VoiceOverNR flag set as FALSE. That means , UE does not support Voice over NR and eventually Fallback Voice call session on EPS.NGRAN inform AMF about IMSVoiceSupportIndicator to FALSE in UERadioCapabiltyCheckResponse message.
  4. AMF inform NGRAN that RedirectionEPSFallbackIndicator as TRUE in IntialContextSetupReq message.
  5. In RegistrationAccept message from NW, IWKN26 bit is set to FALSE (we are assuming that UE support N26 Interface and support Single Registration Mode) and IMS VoPs 3gpp Flag set as TRUE in 5GS Network Feature Support IE.
  6. PDU Session for INTERNET DNN is established.
  7. PDU Session for IMS DNN is established (Please check other post for IMS PDU Session Establishment).
  8. IMS Registration Completed with P-CSCF and UE IP assigned in IMS PDU Session. In REGISTER , SUBSCRIBE message P-Access-Network-Info should be use wit value of NR cell like “3GPP-NR-FDD” and MCC+MNC+TAC+NCI like  :
P-ANI Header (Reference 24.229)
  • For MO Voice call, UE initiate INVITE with P-ANI as “3GPP-NR-FDD” and SDP content with EVS audio Codec. NW sends 183SessionInProgress message and FallBack Procedure triggered during reservation of dedicated resources for Voice Session.
  • During Dedicated QoS Flow Establishment, NGRAN and 5GC take decision to FallBack Voice Call on EPS as Voice over NR cannot be established due to VoiceOverNR Flag is FALSE.
  • NGRAN initiate RRCRelease or HandoverRequest  with ReDirectionInfo with EUTRAN Cell info to Fallback on LTE / EPS.
  • As NW indicate N26 interface supported than UE will send TAU Request message with ”request type “ as “handover” with  IMS PDN and Internet PDN as Active in EBI information. NW mapped these PDN information with INTERNET / IMS PDU session (MME communicate with AMF over N26 interface to fetch UE Context information). Please check next section for other important IEs of TAU.
  • UE will send IMS Re-Register with PANI as “3GPP-EUTRA-FDD” for RAT change.
  • Other SIP messages transferred between UE and IMS Server and Dedicated Bearer for Voice with QCI =1 established on LTE.

1.4.2     Layer 3 Call Flow ( NR – LTE) for EPSFallBack (N26 Supported)

LAyer 3 and TAU procedure details
  • Please refer previous section Except TAU procedure.
  • After receiving RRCRelease (Redirection Case RRC_IDLE) UE will camp on LTE Cell as per ARFCN provided.
  • In TAU Request message (5G Integrity Protected):
    • UE will provide Request Type as “Handover”, UE Status as “5GMM REGISTERED”, Old GUTI (mapped with 5G-GUTI), EPS Bearer status set for INTERNET and IMS PDN as “Active”, PCO – 0001AH as PDU Session ID (mapped for IMS and INTERNET PDN)
  • For TAU Accept, MME interact with AMF on N26 interface and fetch UE context and mapped PDU session (IMS and INTERNET) and assign Bearer ID for IMS and INTERENT PDN. Same UE IP and P-CSCF is used as assigned by 5GC.
  • Once both Default PDN established, Dedicated bearer request procedure for Voice Call QCI = 1 started and Voice call established.

1.5     References

  • 24.229
  • 23.502
  • 24.501
  • 24.301
  • 23.501
  • GSMA NG.114
  • 38.331
  • 38.413

5G Quality Of Services (QoS)

The concept of QoS in 5G is flow based. Packets are classified and marked using QFI (QoS Flow Identifier). The 5G QoS flows are mapped in the AN (Access Network) to DRBs (Data Radio Bearers) unlike 4G LTE where mapping is one to one between EPC and radio bearers. It supports following QoS flow types. 

  • GBR QoS flow, requires guaranteed flow bit rate.
  • Non-GBR QoS flow, does not require guaranteed flow bit rate.
  • Delay Critical  QoS flow, For Mission Critical  guaranteed flow bit rate.

The 5G QoS flows are mapped in the AN (Access Network) to DRBs (Data Radio Bearers) unlike 4G LTE where mapping is one to one between EPC and radio bearers.

5G NR QoS Architecture

New Quality Of Experience (QoE) in 5G

How 5G QoS is differ from 4G

General

The concept of QoS in 4G LTE is based on Bearers. The Concept of QoS in 5G is based on Flow Based.

In 4G, EPS Bearer ID (EBI) is used to distinguish between different Quality Of Services (QoS).

5G uses QoS Flows, each identified by a QoS Flow ID (QFI). As with 4G LTE both non-GBR flows and GBR flows are supported in 5G, along with a new delay-critical GBR. 5G also introduces a new concept – Reflective QoS.

The 5G QoS flows are mapped in the AN (Access Network) to DRBs (Data Radio Bearers) unlike 4G LTE where mapping is one to one between EPC and radio bearers.

4G vs 5G QoS flow parameters

5G – 5GC QoS Packet Filtering

In 5G, QoS Flow mapping happen two times. In the 5GC, there is only a single user plane network function – the UPF – for transport of data between the gNB and the core. In 5G, there is a one-to-many relationship between the GTP-U tunnel on N3 and the DRBs on the air interface. Each QoS flow on N3 is mapped to a single GTP-U tunnel. The gNB may map individual QoS flows to one more DRBs. Therefore, a PDU session may contain multiple QoS flows and several DRBs but only a single N3 GTP-U tunnel. A DRB may transport one or more QoS flows.

5G QoS Parameters / Attributes

QoS flow is identified by QFI within PDU session. This QFI is carried in an encapsulation header over NG-U. 
• For each UE, 5GC establishes one or more PDU sessions and NG-RAN establishes at least one DRB together with PDU session. Additional DRBs are configured for QoS flows of that PDU session consecutively. 
• NG-RAN maps packets which belong to the different PDU sessions to different DRBs.


NAS level packet filters in UE and in 5GC associate UL/DL packets with QoS flows. At NAS level, QoS flow is characterised by QoS profile provided by 5GC to NG-RAN and QoS rules provided by 5GC to UE. 

AS-level mapping rules in UE and in NG-RAN associate UL/DL QoS flows with DRBs. At AS (Access Stratum) level, DRB defines packet treatment on radio interface (Uu). 

5G QoS Flow Descriptions

The network can also provide the UE with one or more QoS flow descriptions associated with a PDU session at the PDU session establishment or at the PDU session modification.

Each QoS flow description contains:

a)  a QoS flow identifier (QFI);

b)  if the flow is a GBR QoS flow:

1)  Guaranteed flow bit rate (GFBR) for UL;

2)  Guaranteed flow bit rate (GFBR) for DL;

3)  Maximum flow bit rate (MFBR) for UL;

4)  Maximum flow bit rate (MFBR) for DL; and

5)  optionally averaging window, applicable for both UL and DL;

 OR

If the flow is aNon-GBR QoS flow:

  1. Reflective QoS Attribute (RQA) in DL
  2. Additional QoS Flow Information

c)  5QI, if the QFI is not the same as the 5QI of the QoS flow identified by the QFI; and

d) ARP

e)  optionally, an EPS bearer identity (EBI) if the QoS flow can be mapped to an EPS bearer .

5G QoS Rules

5G Signaled QoS Rule

The NAS protocol enables the network to provide the UE with signalled QoS rules associated with a PDU session.The network can provide the UE with one or more signalled QoS rules associated with a PDU session at the PDU session establishment or at the PDU session modification.

Each signalled QoS rule contains:

a )        an indication of whether the QoS rule is the default QoS rule;

b)         a QoS rule identifier (QRI);

c)         a QoS flow identifier (QFI);

d)         optionally, a set of packet filters; and

e)         a precedence value.

5G Derived  QoS Rule

The reflective QoS in the UE creates derived QoS rules associated with a PDU session based on DL user data packets received via the PDU session.

Each derived QoS rule contains:

a)  a QoS flow identifier (QFI);

b)  a packet filter for UL direction; and

     c)  a precedence value of 80 (decimal)

5G QoS Flow Characteristics

  • Resource Type (GBR, Delay critical GBR or Non-GBR);
  • Priority Level;
  • Packet Delay Budget (including Core Network Packet Delay Budget);
  • Packet Error Rate;
  • Averaging window (for GBR and Delay-critical GBR resource type only);
  • Maximum Data Burst Volume (for Delay-critical GBR resource type only).

5G QoS Flow Table

5G Network Slicing Concepts

Introduction

In 5G network communication infrastructure is not just confined to mobile voice/text communication, it is now segregated and very diversified to different services like Industrial IoT, Smart home domestic IoT, Low latency Medical communication, high bandwidth mobile broadband etc. And each of these services require different data behavior and QoS from network infrastructure.

In 5G each network node is equipped with special features to serve the purpose of one or multiple services and the kind of service supported by a particular node is defined in NSSF(Network Slice Selection Function). For any particular service request from UE, is served by a set of network entities associated with that Service and called a slice.

NSSAI(Network Slice Selection Assistance Information) Structure and Fundamentals

  • Network Slice configuration Information can have multiple NSSAI
  • Each PLMN can have at most one configured NSSAI
  • Each NSSAI has multiple S-NSSAI slices.
  • Each S-NSSAI slice has multiple DNNs configured.
  • A configured NSSAI can be configured by a serving PLMN or default NSSAI configured by HPLMN.
  • If Serving PLMN doesn’t have specific configured PLMN then it uses default configured NSSAI from HPLMN.
  • UE is pre-configured/provisioned by signalling message with default configured NSSAI by HPLMN.
  • UE is only configured with a set of subscribed S-NSSAIs out of the default configured NSSAI, which is a subset of the S-NSSAIs configured inside default configured NSSAI in HPLMN.
  • Allowed S-NSSAIs provided to the UE can have values, which are not served by Serving PLMN, in that case Serving PLMN updates the allowed S-NSSAI list with mapping to corresponding S-NSSAI of the HPLMN.

S-NSSAI and it’s Structure

Each Slice is identified by S-NSSAI (single network slice selection identifier)

  • SST is required value where was SD is optional
  • SST refer to expected behaviour of the slice.
  • SD is optional and differentiates among multiple slices with same SST.

  • UE during Registration and PDU session Establishment sends S-NSSAI value and optionally HPLMN NSSAI value, if in visiting area.
  • The requested NSSAI signalled by UE to network allows the network to select appropriate serving AMF, Network slice and network slice instance.
  • Based on the subscription data, one UE can have subscription to multiple S-NSSAIs and one of them can be marked as default S-NSSAI.
  • Subscription information for each S-NSSAI may have multiple DNN and one of them is default DNN.

Services provided by NSSF

Nnssf_NSSelection_Get service operation

  • May be invoked during Registration, for serving AMF selection and re-allocation.
  • PDU session establishment procedure, for SMF selection.
  • UE configuration update procedure, to update allowed S-NNAIs to UEs in current serving PLMN.

Nnssf_NSSAIAvailability

  • Nnssf_NSSAIAvailability_Update : In this process, AMF updates NSSF with S-NSSAIs supported by AMF per TA and   gets back availability of S-NSSAIs for each TA.
  • Nnssf_NSSAIAvailability_Notify  : AMF notify NSSF with restricted S-NSSAIs per TA using this procedure.

AMF Re-allocation Procedure

During UE registration procedure, if AMF doesn’t support one or more requested S-NSSAIs which is allowed by SPLMN/HPLMN then it request NSSF to provide the appropriate AMF to redirect the registration request from UE.