Archive 2020

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 Security (5G AKA Authentication)

5G Security Procedure between UE and Network

Security Types in 5G Network

  1. Security required for UE to access network services comes under Network access security. This security mainly cover Authentication, Integrity and ciphering of Signalling and data.
  2. Domain Security mainly covers secure communication between different Network nodes.
  3. Application domain security covers security mechanism between peer applications.
  4. There are two different kind of authentication

Different Authentication, Ciphering and Integrity Algorithms

  • In most cases for Authentication Key Agreement(AKA), operators use Milenage/TUAK algorithm. But some cases proprietary algorithm.
  • For Cyphering and Integrity Protection following Algorithms are used. 

Ciphering Algorithms

Integrity Algorithms

Key Distribution

5G AKA Authentication Procedure

Authentication Flow Steps

  1. After receiving Registration Request, AMF  initiates authentication procedure with UE, if UE security context is not existing with AMF.
  2. AMF sends Nausf_UEAuthentications Request with SUCI or SUPI and Serving network name.
  3. AUSF based on the Serving Network name, determine if AMF is authorised to send this message.
  4. Then AUSF, sends Nudm_UEAuthentication_Get Request with SUPI/SUCI to UDM.
  5. UDM Calculates the 5G HE AV as below. UDM Uses Milenage functions to derive MAC, XRES, CK, IK and AK.
  • UDM derives Kausf is as follows using HMAC-SHA-256(K, S) KDF(Key Derivation Function) function as below.
  • UDM derives XRES* as follows using HMAC-SHA-256(K, S) KDF function.
  • UDM derives 5G HE AV from above derived keys as below and send it to AUSF with message “Nudm_Authentication get Response” 5G HE AV = RAND ‖ XRES* ‖ Kausf ‖ AUTN
  1. Derivation of 5G SE AV at AUSF
  • HXRES* Calculation at AUSF: HXRES* is 128 bit MSB of the output of SHA-256 hash, calculated by passing RAND || XRES* as input to SHA-256 algorithm.
  • AUSF derives Kseaf from Kausf by passing K= Kausf  and S = 0x6C || Serving Network Name || Lenth of Serving Network Name to KDF function.
  • AUSF calculates 5G AV and 5G SE AV as below and send 5G SE AV to AMF. 5G AV = RAND ‖ HXRES* ‖ Kseaf ‖ AUTN 5G SE AV = RAND ‖ HXRES* ‖ AUTN
  1. AMF Sends NAS Authentication Request to UE with RAND and AUTN from 5G SE AV.
  1. UE Uses Milenage functions to derive XMAC, RES, CK, IK as below.
  1. UE Verify the MAC received in AUTN with XMAC calculated above to authenticate the network and check the freshness of AUTN. Here if the comparison fails then it will send authentication failure with AUTS.
  1. UE derives RES* as follows using HMAC-SHA-256(K, S) KDF function. using keys calculated above, and then sends RES* to AMF.
  1. AMF Calculates HRES* from RES* : HRES* is 128 bit MSB of the output of SHA-256 hash, calculated by passing RAND || RES* as input to SHA-256 algorithm.
  1. AMF compares HRES*(Calculated above) with HXRES* received from AUSF to check for successful authentication.
  1. AMF sends RES* received from UE to AUSF with “Authenticate Request” message.
  1. AUSF compares RES* with the XRES*(part of 5G HE AV) received from UDM in step 5.
  1. If Comparison is successful, AUSF sends Authentication Event notification to UDM with “Success”.

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