5GS-WiFi(ePDG) Calling/Offloading Aspects

1       EPDG <–>5GS IMS Media (Voice/Video) Offloading

1.1     Introduction

We already have seen about IMS Media Voice / Video etc offload to ePDG from EPS to seek better Quality coverage and throughput and Seamless experience for Video / Voice calls in a closed environment like In-house, office, etc where User can access good WiFi coverage than EPS. To get same kind of good quality coverage experience in epDG <–> 5GS HO deployment, I have covered possible call flows with required changes in IKE_AUTH and 5GS message to support these scenarios. We will not cover N3IWF <–> 5GS Handover scenarios in this document now and will cover it in the future.

1.2     Technical Aspect and Interfaces

1.2.1     General

WLAN 5 standard and above (WLAN 6 and WLAN 6E) are preferred to do better seamless HO between eDPG ßà 5GS.  802.11ax is highly desirable as a WLAN standard.

1.2.2     Interworking Architecture between ePDG <–> 5GS

1.2.3     Pre-Requisite

To Simplify and for better understanding, I have taken case as UE is 3GPP REGISTERED with 5GS in upcoming sections. Furthermore,  There is N26 interface between AMF and MME present and UE support only Single Registration mode only.

  1. If UE is Registered with 3GPP EPS than during ePDG -> 5GS HO, UE will initiate RegistrationRequest on 5G with “requesttype” as “Mobility Registration” in Single Registration mode.
  2. If UE support Dual Registration mode than UE will initiate RegistrationRequest on 5G with “requesttype” as “initial Registration

1.3     5GS –> epDG IMS Media Offloading

1.3.1     3GPP defined Call Flow as per 23.502

1.3.2     General Call Flow

  1. UE is registered with 5GS and IMS and Internet PDU session established. Voice  / Video / RTT call is successfully established on 5GS.
  2. NW measure WLAN / ePDG power and find good WLAN power, which is appropriate to do Voice / Video offload on ePDG.
  3. ePDG DNS message exchanged and UE gets ePDG Tunnel information.
  4. IKE_SA_INIT Procedure on epDG start to get Encryption algos and other epDG policies exchange.
  5. In IKE_AUTH_Req , UE inform NW about N1_Mode_Capabilty with PLMN info which are equivalent to 5GS and ongoing PDU_Session_ID . Same PCO information ( Port, UE IP, etc) as used in 5GS will be reused.
  6. In IKE_AUTH_RESP, NW will provide N1_Mode_Information with S-NSSAI information and equivalent PLMN ID and other default parameters ( same as used in EPS).
  7. IMS PDU session on 5GS released.
  8. Once EAP-AKA IKEV2 procedure completed. UE will initiate IMS Re-Registration on epDG
  9. IMS Voice/ Video/RTT call offload from 5GS to epDG.

1.4     ePDG–> 5GS IMS Media HO

1.4.1     3GPP defined Call Flow as per 23.502

1.4.2     General Call Flow

  1. UE is 5GS 3GPP Registered and Internet PDU session established.
  2. IMS PDU and Media (Voice, Video, RTT) are established on ePDG and RTP date for Video / Audio are flowing on ePDG.
  3. In IKE_AUTH message, UE is already provided N1 Mode capability / information to NW about N1 Mode support .
  4. ePDG power reduced below to threshold and 5G RAN power increased.
  5. UE will send PDU Session Establishment Req for IMS DNN with requesttype as “existing PDU Session” and same PCO information (UE IP, port etc, ) to 5GS.
  6. NW will respond with PDUSessionAccept with same PCO information and 5QI as 5 and other QoS Flow information as required  for IMS PDU Session .
  7. IMS Re-Registration procedure happened on 5GS with PANI as “NR-FDD”.
  8. PDU Modification command from NW with 5QI =1 and other QoS Rules to established Voice completed.
  9. Voice Media RTP packets started on 5GS between UE and 5GS.
  10. IMS PDU ePDG tunnel release between UE-epDG.

1.5     ePDG –> 5GS –> EPS Fallback case

1.5.1     3GPP defined Call Flow as per 23.502

1.5.2     General Call Flow

  1. Please follow till step 7 of section 1.4.2
  2. UE may send Re-INVITE to establish and request Dedicated Voice QoS Flow on 5GS and set PANI as “3GPP-NR-FDD” .
  3. NW will decide to do Fallback Voice / video on EPS during Voice QoS Flow establishment.
  4. Voice Media RTP may be paused or go on default IMS PDU Session for some time until dedicated bearer / QoS flow not established.
  5. Please follow EPS Fallback procedure for Voice establishment on EPS.
  6. After Voice call ends on EPS , UE will do either Redirection or Reselection to move back to NR.

1.6     References

  • 24.501
  • 23.502
  • 23.402
  • 24.302
  • 23.501

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 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”.