Content for TS 23.167 Word version: 16.3.0
5 Architecture model and reference points
5.1 Reference architecture
5.2 Reference points
6 Functional description
6.1 UE
6.2 IMS Functional entities
...
...
5 Architecture model and reference points
5.1 Reference architecture
This specification introduces an additional CSCF role to those defined in the IMS architecture TS 23.002, called Emergency CSCF (E-CSCF), see Figure 5.1.
5.2 Reference points Word‑p. 17
The E-CSCF uses Mw, Mg, Mi, Ml, Mm, Mx and I4 reference points to connect to other IMS entities and other IP Networks.
6 Functional description
6.1 UE
- Should be able to detect an emergency session establishment request.
- In the case of NG-eCall, the IMS emergency session establishment request may be invoked either automatically without user input or manually via user input.
- Initiate an IMS emergency registration request.
- The UE may perform an IMS emergency session establishment without prior emergency registration when already IMS registered and it is in home network (e.g. including IP-CANs where roaming outside the home network is not supported).
- Otherwise, the UE shall perform an IMS emergency registration.
- Include an emergency service indication in the emergency session request.
- UE may support the GIBA procedure defined in TS 24.229 as part of the emergency IMS registration procedure.
- In the case of emergency IMS registration failure the UE shall be able to interpret the indication, if provided by the serving IMS, whether anonymous IMS emergency sessions are supported in the serving IMS. If the serving IMS has indicated support, the UE shall proceed with an anonymous IMS emergency session, otherwise it proceeds according to clause H.5.
- Include an equipment identifier in the request to establish an emergency session for "anonymous user".
- Include an equipment identifier in the request to establish an emergency session when the UE supports SRVCC as specified in TS 23.237.
- Include identity information for the IP-CAN if available (e.g. MCC-MNC or an equivalent)
- Attempt the emergency call in CS domain, if capable.
- Handle a 380 (Alternative Service) response with the type set to "emergency" e.g. as a result of non UE detectable emergency attempt.
- Handle a response with an indication, IMS emergency registration required as a result of emergency session establishment attempt.
- Other general requirements of UE shall be referred to the general requirements of emergency calls in TS 22.101.
- For NG-eCall, where transfer of the MSD is not acknowledged by the PSAP, the UE shall fall back to the in-band transfer of the MSD, as in CS domain defined in TS 26.267.
- Emergency service indication.
- A registered Public User Identifier. If the UE performed an emergency registration using a temporary Public User Identifier then the UE should not use the temporary Public User Identifier to initiate the emergency session. The selected Public User Identifier shall be part of an implicit registration set that includes a TEL URI.
- Optionally, type of emergency service. It could be implied in the above emergency service indication.
- For an NG-eCall an eCall indication including whether eCall is automatic or manual.
- UE's location information, if available.
- The TEL URI associated to the Public User Identifier, if available.
- GRUU, if available.
6.2 IMS Functional entities Word‑p. 19
6.2.1 Proxy CSCF
-
Handle registration requests with an emergency registration indication like any other registration request, except that it may reject an emergency registration request if the IM CN subsystem that the P-CSCF belongs to can not support emergency sessions for the UE (e.g., due to operator policy or UE is not within IM CN subsystem's geographical area or IP-CAN not supported).
-
Detect an emergency session establishment request.
-
Reject/allow unmarked emergency requests.
-
Reject/allow anonymous emergency requests.
-
Prevent non-emergency requests that are associated with an emergency registration.
-
May query IP-CAN for location identifier.
-
May query IP-CAN for additional subscriber related identifier(s).
-
Select an Emergency CSCF in the same network to handle the emergency session request. The selection method is not standardized in the present document.
-
Alternatively, for non-roaming subscribers and when the request is received over a non-emergency registration, the P-CSCF may forward an emergency session to an S-CSCF if so instructed by operator policy or local regulation.
-
Do not apply emergency session detection if requested using private network traffic and forward the session to the S-CSCF, except if operator policy requires the P-CSCF to detect emergency session requests and treat detected emergency session requests as if they are part of public network traffic.
-
For UEs without credentials, forward the equipment identifier to the E-CSCF that was received from the UE.
-
For UEs without credentials and subjected to local regulation, forward the additional subscriber related identifier(s) received from IP-CAN to the E-CSCF.
-
Prioritize the emergency session.
-
Check the validity of the caller TEL URI if provided by the UE and shall provide the TEL URI in the session establishment request if it is aware about the TEL URI associated with the Public User Identifier used for an emergency registration.
-
May respond to a UE with an emergency service indication as a result of detecting a non UE detectable emergency session establishment request
-
May respond to the UE with an indication, IMS emergency registration required as a result of processing the emergency session establishment attempt.
-
Should be able to identify the service data flow associated with emergency service and inform PCRF accordingly.
-
Upon IMS registration failure the P-CSCF may indicate to the UE whether anonymous IMS emergency sessions are supported.
6.2.2 Emergency CSCF Word‑p. 20
-
Receive an emergency session establishment request from a P-CSCF or an S-CSCF.
-
If the UE does not have credentials, a non-dialable callback number shall be derived where required by local regulation (e.g. see Annex C of J-STD-036 [23]).
-
If location information is not included in the emergency request or additional location information is required, the E-CSCF may request the LRF to retrieve location information as described in clause 7.6 Retrieving Location information for Emergency Session.
-
If required, the E-CSCF requests the LRF to validate the location information if included by the UE.
-
Determines or queries the LRF for the proper routing information/PSAP destination.
-
Route emergency session establishment requests to an appropriate destination including anonymous session establishment requests.
-
Subject to local regulation, the E-CSCF may send the contents of the P-asserted ID or UE identification to the LRF.
-
Based on operator policy, the E-CSCF may route the emergency IMS call to ECS for further call process.
-
For supporting SRVCC and/or DRVCC, see TS 23.237 and TS 23.216, the E-CSCF forwards the session establishment request to the EATF in the serving IMS network for anchoring.
-
Generation of CDRs.
-
For an NG-eCall and if an LRF/RDF is not deployed, the E-CSCF may use an indication of an automatic eCall or a manual eCall to assist routing of an emergency session establishment request.
-
For supporting emergency session request from MSC Server enhanced with ICS, see TS 23.292. E-CSCF follows the same procedure as defined for handling emergency session request from P-CSCF.
6.2.3 Location Retrieval Function
The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE that has initiated an IMS emergency session. It shall be possible to support configurations where the Location Retrieval Function (LRF) may consist of a Routing Determination Function (RDF) and a LS, the interface between Location Server and RDF is out of scope of this specification. For WLAN access, and for non-roaming UEs, if the LRF is configured then it may interact with HSS to provide an NPLI before interacting with the RDF. In some regions, for example in the North American region, ATIS-0700028 [45], if the BSSID of the serving WLAN is available, the LRF may query a database subject to national regulations and operator policies for the dispatchable location associated with the BSSID of the WLAN Access Point.
The LRF utilizes the RDF to provide the routing information to the E-CSCF for routing the emergency request. The RDF can interact with a LS and manage ESQK allocation and management. The ESQK is used by the PSAP to query the LRF for location information and optionally a callback number. The LRF-PSAP interactions are outside the scope of this specification.
Information provided by the LRF to the E-CSCF includes the routing information and other parameters necessary for emergency services, which are subject to local regulation. For example, this information may include the ESQK, ESRN, LRO in North America, location number in EU, PSAP SIP URI or TEL URI.
In order to provide the correct PSAP destination address to the E-CSCF, the LRF may require interim location information for the UE.
In some regions, for example in the North American region, it may be a requirement to provide the PSAP with an accurate initial location estimate for the UE and possibly to provide an accurate updated location estimate for the UE if requested by the PSAP. When this requirement exists, the LRF may store a record of the emergency session including all information provided by the E-CSCF and shall only release this record when informed by the E-CSCF that the emergency session has terminated. The information provided by the LRF to the E-CSCF (e.g. ESQK) shall then include correlation information identifying both the LRF and the emergency session record in the LRF. This correlation information shall be transferred to the PSAP during session establishment (e.g. in a SIP INVITE or via SS7 ISUP signalling from the MGCF). The PSAP may use this information to request an initial location estimate from the LRF and/or to request an updated location estimate.
6.2.4 Serving-CSCF Word‑p. 21
When the S-CSCF receives an Emergency Registration, the S-CSCF determine the duration of the registration by checking the value of the Expires header in the received REGISTER request and based on local regulation or operator policy of the serving system.
The emergency registration shall be handled as normal IMS registrations with the following considerations:
-
Upon emergency registration:
-
If a normal registration for the user does not exist, the S-CSCF shall download corresponding user profile from HSS to ensure that HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED.
-
Otherwise, S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
-
Upon deregistration or expiration of the last normal session:
-
If an emergency registration for the user still exists, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED.
-
Upon expiration of an emergency registration:
-
If a normal registration for the user still exists, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
-
Otherwise, the S-CSCF can either de-register the user in HSS or keep the registration status of the user unchanged in the HSS.
When an S-CSCF receives a session initiated by a non-roaming subscriber marked as emergency session from a P-CSCF, the S-CSCF:
-
performs caller authentication in the same way as for any other sessions;
-
if required, uses filter criteria to route to AS;
-
and forwards the request to an E-CSCF.
When an S-CSCF receives a session marked as emergency session from an AS, the S-CSCF:
-
if required, uses filter criteria to route to other ASs;
-
and forwards the request to an E-CSCF.
6.2.5 Void
6.2.6 Emergency Access Transfer Function (EATF) |R9| Word‑p. 22
The EATF provides IMS emergency session continuity which is specified in TS 23.237.
6.2.7 Interrogating-CSCF |R9|
I-CSCF supports IMS emergency session continuity which is specified in TS 23.237.
6.2.8 AS |R10|
An AS can be involved in emergency session handling (e.g. for emergency sessions made via hosted enterprise services ETSI TS 182 024 [37], or for AS initiated session).
Dependent on the service provided by the AS, if the AS is the first point that identifies an IMS emergency session, then the AS shall provide the following emergency session handling functions:
-
Detect an emergency session establishment request.
-
Verify that the UE is not roaming.
-
Optionally obtain location.
-
Prioritize the emergency session.
-
Provide in the session establishment request the TEL URI associated to the public user identity, in global format, if known and not already present.
-
Check the validity of the caller TEL URI if provided by the UE.
-
Mark the request as an emergency session request.
6.2.9 HSS |R9|
In the course of an emergency registration, the HSS shall not apply any barring condition and/or roaming restriction associated with the Public User Identity received in the emergency registration request.
The emergency registration shall be handled with the considerations defined in clause 6.2.4.
6.2.10 Media Gateway Control Function (MGCF) |R14|
For NG-eCall MGCF handles the emergency session as normal emergency call establishment.
6.2.11 MSC Server enhanced with ICS |R14|
The MSC Server enhanced with ICS may provide interworking mechanisms to support emergency call using CS media bearer and using IMS for routing/handling the emergency call toward PSAP. From the view point of E-CSCF, MSC Server enhanced with ICS behaves like a P-CSCF. Further details on MSC Server procedure are defined in TS 23.292.
6.2.12 IBCF |R14| Word‑p. 23
-
Forward emergency session establishment requests.
-
Prioritize the emergency session based on operator policy.
6.2.1 Proxy CSCF
- Handle registration requests with an emergency registration indication like any other registration request, except that it may reject an emergency registration request if the IM CN subsystem that the P-CSCF belongs to can not support emergency sessions for the UE (e.g., due to operator policy or UE is not within IM CN subsystem's geographical area or IP-CAN not supported).
- Detect an emergency session establishment request.
- Reject/allow unmarked emergency requests.
- Reject/allow anonymous emergency requests.
- Prevent non-emergency requests that are associated with an emergency registration.
- May query IP-CAN for location identifier.
- May query IP-CAN for additional subscriber related identifier(s).
- Select an Emergency CSCF in the same network to handle the emergency session request. The selection method is not standardized in the present document.
- Alternatively, for non-roaming subscribers and when the request is received over a non-emergency registration, the P-CSCF may forward an emergency session to an S-CSCF if so instructed by operator policy or local regulation.
- Do not apply emergency session detection if requested using private network traffic and forward the session to the S-CSCF, except if operator policy requires the P-CSCF to detect emergency session requests and treat detected emergency session requests as if they are part of public network traffic.
- For UEs without credentials, forward the equipment identifier to the E-CSCF that was received from the UE.
- For UEs without credentials and subjected to local regulation, forward the additional subscriber related identifier(s) received from IP-CAN to the E-CSCF.
- Prioritize the emergency session.
- Check the validity of the caller TEL URI if provided by the UE and shall provide the TEL URI in the session establishment request if it is aware about the TEL URI associated with the Public User Identifier used for an emergency registration.
- May respond to a UE with an emergency service indication as a result of detecting a non UE detectable emergency session establishment request
- May respond to the UE with an indication, IMS emergency registration required as a result of processing the emergency session establishment attempt.
- Should be able to identify the service data flow associated with emergency service and inform PCRF accordingly.
- Upon IMS registration failure the P-CSCF may indicate to the UE whether anonymous IMS emergency sessions are supported.
6.2.2 Emergency CSCF Word‑p. 20
-
Receive an emergency session establishment request from a P-CSCF or an S-CSCF.
-
If the UE does not have credentials, a non-dialable callback number shall be derived where required by local regulation (e.g. see Annex C of J-STD-036 [23]).
-
If location information is not included in the emergency request or additional location information is required, the E-CSCF may request the LRF to retrieve location information as described in clause 7.6 Retrieving Location information for Emergency Session.
-
If required, the E-CSCF requests the LRF to validate the location information if included by the UE.
-
Determines or queries the LRF for the proper routing information/PSAP destination.
-
Route emergency session establishment requests to an appropriate destination including anonymous session establishment requests.
-
Subject to local regulation, the E-CSCF may send the contents of the P-asserted ID or UE identification to the LRF.
-
Based on operator policy, the E-CSCF may route the emergency IMS call to ECS for further call process.
-
For supporting SRVCC and/or DRVCC, see TS 23.237 and TS 23.216, the E-CSCF forwards the session establishment request to the EATF in the serving IMS network for anchoring.
-
Generation of CDRs.
-
For an NG-eCall and if an LRF/RDF is not deployed, the E-CSCF may use an indication of an automatic eCall or a manual eCall to assist routing of an emergency session establishment request.
-
For supporting emergency session request from MSC Server enhanced with ICS, see TS 23.292. E-CSCF follows the same procedure as defined for handling emergency session request from P-CSCF.
6.2.3 Location Retrieval Function
The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE that has initiated an IMS emergency session. It shall be possible to support configurations where the Location Retrieval Function (LRF) may consist of a Routing Determination Function (RDF) and a LS, the interface between Location Server and RDF is out of scope of this specification. For WLAN access, and for non-roaming UEs, if the LRF is configured then it may interact with HSS to provide an NPLI before interacting with the RDF. In some regions, for example in the North American region, ATIS-0700028 [45], if the BSSID of the serving WLAN is available, the LRF may query a database subject to national regulations and operator policies for the dispatchable location associated with the BSSID of the WLAN Access Point.
The LRF utilizes the RDF to provide the routing information to the E-CSCF for routing the emergency request. The RDF can interact with a LS and manage ESQK allocation and management. The ESQK is used by the PSAP to query the LRF for location information and optionally a callback number. The LRF-PSAP interactions are outside the scope of this specification.
Information provided by the LRF to the E-CSCF includes the routing information and other parameters necessary for emergency services, which are subject to local regulation. For example, this information may include the ESQK, ESRN, LRO in North America, location number in EU, PSAP SIP URI or TEL URI.
In order to provide the correct PSAP destination address to the E-CSCF, the LRF may require interim location information for the UE.
In some regions, for example in the North American region, it may be a requirement to provide the PSAP with an accurate initial location estimate for the UE and possibly to provide an accurate updated location estimate for the UE if requested by the PSAP. When this requirement exists, the LRF may store a record of the emergency session including all information provided by the E-CSCF and shall only release this record when informed by the E-CSCF that the emergency session has terminated. The information provided by the LRF to the E-CSCF (e.g. ESQK) shall then include correlation information identifying both the LRF and the emergency session record in the LRF. This correlation information shall be transferred to the PSAP during session establishment (e.g. in a SIP INVITE or via SS7 ISUP signalling from the MGCF). The PSAP may use this information to request an initial location estimate from the LRF and/or to request an updated location estimate.
6.2.4 Serving-CSCF Word‑p. 21
When the S-CSCF receives an Emergency Registration, the S-CSCF determine the duration of the registration by checking the value of the Expires header in the received REGISTER request and based on local regulation or operator policy of the serving system.
The emergency registration shall be handled as normal IMS registrations with the following considerations:
-
Upon emergency registration:
-
If a normal registration for the user does not exist, the S-CSCF shall download corresponding user profile from HSS to ensure that HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED.
-
Otherwise, S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
-
Upon deregistration or expiration of the last normal session:
-
If an emergency registration for the user still exists, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED.
-
Upon expiration of an emergency registration:
-
If a normal registration for the user still exists, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
-
Otherwise, the S-CSCF can either de-register the user in HSS or keep the registration status of the user unchanged in the HSS.
When an S-CSCF receives a session initiated by a non-roaming subscriber marked as emergency session from a P-CSCF, the S-CSCF:
-
performs caller authentication in the same way as for any other sessions;
-
if required, uses filter criteria to route to AS;
-
and forwards the request to an E-CSCF.
When an S-CSCF receives a session marked as emergency session from an AS, the S-CSCF:
-
if required, uses filter criteria to route to other ASs;
-
and forwards the request to an E-CSCF.
6.2.5 Void
6.2.6 Emergency Access Transfer Function (EATF) |R9| Word‑p. 22
The EATF provides IMS emergency session continuity which is specified in TS 23.237.
6.2.7 Interrogating-CSCF |R9|
I-CSCF supports IMS emergency session continuity which is specified in TS 23.237.
6.2.8 AS |R10|
An AS can be involved in emergency session handling (e.g. for emergency sessions made via hosted enterprise services ETSI TS 182 024 [37], or for AS initiated session).
Dependent on the service provided by the AS, if the AS is the first point that identifies an IMS emergency session, then the AS shall provide the following emergency session handling functions:
-
Detect an emergency session establishment request.
-
Verify that the UE is not roaming.
-
Optionally obtain location.
-
Prioritize the emergency session.
-
Provide in the session establishment request the TEL URI associated to the public user identity, in global format, if known and not already present.
-
Check the validity of the caller TEL URI if provided by the UE.
-
Mark the request as an emergency session request.
6.2.9 HSS |R9|
In the course of an emergency registration, the HSS shall not apply any barring condition and/or roaming restriction associated with the Public User Identity received in the emergency registration request.
The emergency registration shall be handled with the considerations defined in clause 6.2.4.
6.2.10 Media Gateway Control Function (MGCF) |R14|
For NG-eCall MGCF handles the emergency session as normal emergency call establishment.
6.2.11 MSC Server enhanced with ICS |R14|
The MSC Server enhanced with ICS may provide interworking mechanisms to support emergency call using CS media bearer and using IMS for routing/handling the emergency call toward PSAP. From the view point of E-CSCF, MSC Server enhanced with ICS behaves like a P-CSCF. Further details on MSC Server procedure are defined in TS 23.292.
6.2.12 IBCF |R14| Word‑p. 23
-
Forward emergency session establishment requests.
-
Prioritize the emergency session based on operator policy.
- Receive an emergency session establishment request from a P-CSCF or an S-CSCF.
- If the UE does not have credentials, a non-dialable callback number shall be derived where required by local regulation (e.g. see Annex C of J-STD-036 [23]).
- If location information is not included in the emergency request or additional location information is required, the E-CSCF may request the LRF to retrieve location information as described in clause 7.6 Retrieving Location information for Emergency Session.
- If required, the E-CSCF requests the LRF to validate the location information if included by the UE.
- Determines or queries the LRF for the proper routing information/PSAP destination.
- Route emergency session establishment requests to an appropriate destination including anonymous session establishment requests.
- Subject to local regulation, the E-CSCF may send the contents of the P-asserted ID or UE identification to the LRF.
- Based on operator policy, the E-CSCF may route the emergency IMS call to ECS for further call process.
- For supporting SRVCC and/or DRVCC, see TS 23.237 and TS 23.216, the E-CSCF forwards the session establishment request to the EATF in the serving IMS network for anchoring.
- Generation of CDRs.
- For an NG-eCall and if an LRF/RDF is not deployed, the E-CSCF may use an indication of an automatic eCall or a manual eCall to assist routing of an emergency session establishment request.
- For supporting emergency session request from MSC Server enhanced with ICS, see TS 23.292. E-CSCF follows the same procedure as defined for handling emergency session request from P-CSCF.
When the S-CSCF receives an Emergency Registration, the S-CSCF determine the duration of the registration by checking the value of the Expires header in the received REGISTER request and based on local regulation or operator policy of the serving system.
The emergency registration shall be handled as normal IMS registrations with the following considerations:
-
Upon emergency registration:
- If a normal registration for the user does not exist, the S-CSCF shall download corresponding user profile from HSS to ensure that HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED.
- Otherwise, S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
-
Upon deregistration or expiration of the last normal session:
- If an emergency registration for the user still exists, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED.
-
Upon expiration of an emergency registration:
- If a normal registration for the user still exists, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS.
- Otherwise, the S-CSCF can either de-register the user in HSS or keep the registration status of the user unchanged in the HSS.
- performs caller authentication in the same way as for any other sessions;
- if required, uses filter criteria to route to AS;
- and forwards the request to an E-CSCF.
- if required, uses filter criteria to route to other ASs;
- and forwards the request to an E-CSCF.
6.2.5 Void
6.2.6 Emergency Access Transfer Function (EATF) |R9| Word‑p. 22
The EATF provides IMS emergency session continuity which is specified in TS 23.237.
6.2.7 Interrogating-CSCF |R9|
I-CSCF supports IMS emergency session continuity which is specified in TS 23.237.
6.2.8 AS |R10|
An AS can be involved in emergency session handling (e.g. for emergency sessions made via hosted enterprise services ETSI TS 182 024 [37], or for AS initiated session).
Dependent on the service provided by the AS, if the AS is the first point that identifies an IMS emergency session, then the AS shall provide the following emergency session handling functions:
-
Detect an emergency session establishment request.
-
Verify that the UE is not roaming.
-
Optionally obtain location.
-
Prioritize the emergency session.
-
Provide in the session establishment request the TEL URI associated to the public user identity, in global format, if known and not already present.
-
Check the validity of the caller TEL URI if provided by the UE.
-
Mark the request as an emergency session request.
6.2.9 HSS |R9|
In the course of an emergency registration, the HSS shall not apply any barring condition and/or roaming restriction associated with the Public User Identity received in the emergency registration request.
The emergency registration shall be handled with the considerations defined in clause 6.2.4.
6.2.10 Media Gateway Control Function (MGCF) |R14|
For NG-eCall MGCF handles the emergency session as normal emergency call establishment.
6.2.11 MSC Server enhanced with ICS |R14|
The MSC Server enhanced with ICS may provide interworking mechanisms to support emergency call using CS media bearer and using IMS for routing/handling the emergency call toward PSAP. From the view point of E-CSCF, MSC Server enhanced with ICS behaves like a P-CSCF. Further details on MSC Server procedure are defined in TS 23.292.
6.2.12 IBCF |R14| Word‑p. 23
-
Forward emergency session establishment requests.
-
Prioritize the emergency session based on operator policy.
- Detect an emergency session establishment request.
- Verify that the UE is not roaming.
- Optionally obtain location.
- Prioritize the emergency session.
- Provide in the session establishment request the TEL URI associated to the public user identity, in global format, if known and not already present.
- Check the validity of the caller TEL URI if provided by the UE.
- Mark the request as an emergency session request.
- Forward emergency session establishment requests.
- Prioritize the emergency session based on operator policy.
