How it Works

Identification of Emergency Service Sessions

5G

SMF identifies the emergency session based on request type "Initial Emergency Request" or "Existing Emergency PDU Session" received in SmContextCreate Message from AMF or if the DNN is configured as an Emergency DNN.

4G

SMF identifies the emergency session based on the authentication status of IMSI. If the IMSI is unauthenticated (UIMSI is set to 1), the session is considered as an emergency session.

If IMSI is authenticated (UIMSI is set to 0), and DNN is configured as an emergency DNN (using new CLI) in SMF, the session is identified as an emergency session.

  • For non-emergency session, SUPI or IMSI is mandatory.

  • For emergency session:

    • For an authenticated SUPI or IMSI, SUPI or IMSI is used as the session-key based on the current implementation.

    • For an unauthenticated SUPI or IMSI, PEI or IMEI is always used as the session-key, If PEI or IMEI is not present, then the call is rejected.

UDM Interaction for Emergency Sessions

  1. SMF skips UDM interaction if SUPI or IMSI is unauthenticated.

  2. SMF skips UDM interaction if SUPI/IMSI is authenticated and if “authorization” in DNN configuration is set to “local”.

  3. SMF interacts with UDM if SUPI or IMSI is authenticated and if “authorization” in DNN configuration is not set to local.

    • If UDM rejects, then the call will be rejected.

    • If UDM exchanges fail, further handling is done based on UDM failure handling template provisioning.

Important

SMF does not consider whether “authorization local” is configured in DNN profile or not.

Configuring Emergency Sessions

  1. Existing DNN, P-CSCF, UPF, and QoS Profile configuration works for emergency sessions.

  2. Use CLI classify a DNN as Emergency DNN.

  3. If "authorization" is set (using CLI) to local under DNN, UDM interaction is not required.

  4. Use default Flow Only timer configuration to retain the default bearer to enable PSAP Callback session.

Support for Emergency Services if Request Type is “Existing Emergency PDU Session”

  1. If the request type indicates "Existing Emergency PDU Session", the SMF determines that the request is HO from EPS (4G and WiFi). Current implementation supports emergency sessions mobility in WiFi to 5G HO using request type as “Existing Emergency PDU Session” and in 4G to 5G HO using N26 interface.

  2. The SMF identifies the existing PDU session based on the PDU Session ID.

  3. SMF updates the existing SM context to provide the representation of the updated SM context to the AMF in the response instead of creating new SM, which is equivalent to handling of “Existing PDU Session”.

Default Flow Only Timer for an Emergency Service (Dedicated Bearer)

At reception of an HTTP POST message that removes one or several PCC Rules from a PDU Session restricted to emergency services:

  • When all PCC Rules bound to a QoS flow are removed, SMF initiates a QoS flow termination procedure.

  • When not all PCC Rules bound to a QoS flow are removed, SMF initiates QoS flow modification procedure.

In addition, the SMF initiates a default flow only if timer if all PCC Rules with a 5QI other than the 5QI of the default QoS flow or the 5QI used for IMS signalling are removed from the PDU session restricted to Emergency Services (example - to enable public safety answering point (PSAP) Callback session). When the default flow only timer expires, the SMF initiates a PDU session termination procedure.

  1. The SMF initiates default flow only timer when a PCF initiated modify procedure removes a dedicated bearer(voice/video). The main intension of this timer is to hold the emergency session for some more time to facilitate a PSAP callback.

  2. When default flow only timer expires, the PCEF initiates termination of the IMS Emergency session.

  3. The SMF stops the default flow only timer on receiving a PCF-initiated modification request for creating a new bearer.

EPS FB

If gNB rejects the QFI and EPS fall back is armed. SMf performs the EPS fallback as a it is done for a normal non-emergency session.

Use of PEI as Session Key

SMF uses PEI as session key if SUPI is not present or it is not authenticated. Following conditions must be met for PduContext on SMF:

  1. The REST-EP, when the message is received, checks affinity based on SUPI and PEI. First lookup will be done with SUPI. If it fails, checks with the PEI.

    Or

    Both SUPI and PEI keys can be looked up.

  2. When Smf-Service chooses PEI as key, it sets affinity in cache-pod using PEI.

  3. When Smf-Service inserts CDL record using PEI as key, PEI will be added as Primary Key type. Either Primary key is SUPI+PduSessionid or PEI+PduSessionID.

  4. After first transaction, CDL lookup will happen both with SUPI or PEI which ever is available.

  5. SEID is generated using PEI hashing.