7 Procedures related to establishment of IMS emergency session

23.1673GPPIP Multimedia Subsystem (IMS) emergency sessionsRelease 17TS

7.1 High Level Procedures for IMS Emergency Services

7.1.1 UE Detectable Emergency Session

The following flow contains a high level description of the emergency service procedures performed when the UE can detect the emergency session is being requested.

Figure 7.1: Terminal Detected Emergency Calls

The following steps are performed:

1. The UE detects the request for the establishment of an emergency session. Step 2 to 6 may be skipped based on the conditions specified in clause 6.1.

2. In the case that the UE has insufficient resources or capabilities to establish an emergency call due to other ongoing sessions then the UE should terminate the ongoing communication and release reserved bearer resources.

3. In the case that bearer registration is required and has not been performed, the UE shall perform bearer registration to the IP-CAN. If the UE is already bearer registered, then the bearer registration procedures are not required to be performed.

NOTE 1: Depending on the IP-CAN, the UE may be assigned an IP address at this stage.

4. In the case that bearer resources for the transport of the IMS related signalling are required to be reserved in the IP-CAN, the UE shall reserve the resources in the IP-CAN. The IP‑CAN may support a UE indication that this request is for an emergency service.
If the IP-CAN does not provide an IP address to the UE in step 3, then the IP-CAN shall allocate an IP address to the UE during the bearer resource request procedures.

5. UE performs a P‑CSCF discovery procedure, where the UE discovers a P‑CSCF in the local network suitable for use in emergency sessions.

NOTE 2: The exact means for the P‑CSCF discovery is dependent upon the IP-CAN.

6. If the UE has sufficient credentials to authenticate with the IMS network, it shall initiate an IMS emergency registration by providing the IP address obtained at step 3 or step 4 to the P‑CSCF selected at step 5. The IP address used for signalling purposes is allocated in association with step 3 or step 4. The IMS registration request shall include an emergency indication. The implicit registration set of the SIP URI used in the emergency registration request used by the UE when the UE performs a non-emergency registration shall contain an associated TEL‑URI that is used to call back the UE.

The S‑CSCF may set the proposed registration expiration according to the local regulation or operator policy of the serving system. The subsequent registration flows are like any other registration with the considerations defined in clauses 6.2.4 and 6.2.9.

If the UE does not have sufficient credentials to authenticate with the IMS network, it shall not initiate an IMS emergency registration request, but instead immediately establish an emergency session towards the P‑CSCF as described in clause 7.4 and skip step 7.

7. The UE shall initiate the IMS emergency session establishment using the IMS session establishment procedures containing an emergency service indication, or the eCall type of emergency service indication in the case of eCall and any registered Public User Identifier. If the UE has performed emergency registration, the UE shall use an emergency registered Public User Identifier.

Whether the procedures are activated individually by the UE or some of them are performed automatically depends on the implementation of the terminal and on the UE’s configuration. For instance, the multimedia application in the UE could start the application level registration and steps 2-4 would have to be executed in response to support the operation initiated by the application. Interaction with the UE may happen during these steps.

7.1.2 Non UE detectable Emergency Session

As the UE could not detect the emergency session, the session establishment request will be sent to a P‑CSCF in the visited PLMN or a P‑CSCF in the home PLMN as per a normal session establishment procedure. The former is only applicable to a roaming situation whereas the latter can apply to both a roaming and non-roaming situation and for the case of SNPN. Prior to sending the session establishment request the UE must be registered in the IMS as per the normal registration procedure.

In the case that the P‑CSCF detects that this is a request to establish an emergency session, based upon operator policy (e.g., checking access type):

– the P‑CSCF may reject the session initiation request with an indication that this is for an emergency session. When the UE receives the session rejection then the UE shall:

– select a domain for the emergency session;

– if the PS domain is selected, follow the procedure in clause 7.1.1;

– for systems based on TS 24.008 [13], if the CS domain is selected and a dialled number is available, attempt a normal call (i.e. TS 11, see TS 22.003 [26]) using the dialled number if:

– an emergency service information is included by the P-CSCF with either a country specific emergency subservice type (see TS 24.229 [19]) or a emergency subservice type (see TS 24.229 [19]) that does not map into an emergency service category for the CS domain; or

– no emergency service information is included by the P-CSCF;

– for systems based on TS 24.008 [13], if the CS domain is selected, attempt an emergency call (i.e. TS 12, see TS 22.003 [26]) if:

– a dialled number is not available; or

– an emergency service information is included by the P-CSCF with no emergency subservice type or a emergency subservice type (see TS 24.229 [19]) that maps into an emergency service category for the CS domain;

– if the CS domain is selected and for CS systems that do not support emergency call handling procedures (e.g. as described by TS12 in TS 22.003 [26] for systems based on TS 24.008 [13] or in systems providing access to IM CN subsystem using a cdma2000 network, for example) a normal call is made;

– If prior attempting the call in the CS domain the UE receives a list of local emergency numbers, the UE may verify if and recognizes the dialled number is an emergency number and if verified, the UE shall attempt an emergency call set up indicating the appropriate emergency call type.

– Alternatively, the P‑CSCF in the visited PLMN or the P‑CSCF in the home PLMN for a non-roaming UE may allow the session initiation request to continue by inserting the explicit emergency indication in the session request. The P-CSCF in the visited PLMN forwards that request to an Emergency CSCF in the same network. The P-CSCF in the home PLMN for a non-roaming UE may forward that request to a Serving CSCF or to an Emergency CSCF in the same network, based on local regulation or operator policy. The E‑CSCF shall inform the UE that the session has been marked as an emergency session so the UE can treat the session as an emergency session establishment.

– For the case when a SNPN uses IMS services provided by an independent IMS provider, the P-CSCF is located in the IMS provider network according to TS 23.228 [1], Annex A.

If the AS detects that this is a request to establish an emergency session, the AS shall handle the request as specified in clause 6.2.8 and forward the request marked as an emergency services request to the S-CSCF.

7.1.3 Emergency Session Establishment using LRF/RDF

Figure 7.2 illustrates a high level call flow for the IMS emergency session establishment procedure using LRF/RDF to retrieve location and routing information.

Figure 7.2: Emergency Session Establishment procedure with using LRF/RDF

1. UE initiates an emergency session request by sending a SIP INVITE message with including emergency URI.

2. If required, the IMS network may access the LRF to retrieve the UE’s location. For WLAN access, and for non-roaming UEs, if the LRF is configured then it may interact with HSS to provide an NPLI. 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.

NOTE 1: The details of the LRF querying a national database (e.g. in North America) are outside the scope of this specification.

3. If required, LRF invokes the RDF to determine the proper PSAP destination. LRF returns the necessary location/routing information (e.g., ESQK for North America or location number for EU) to the IMS network.

4. The IMS network uses the routing information returned by the LRF to route the emergency session request towards the appropriate PSAP.

NOTE 2: If the LRF provides an ESQK to the IMS network in step 3 or assigns any other dedicated resource to the emergency session, the IMS network shall inform the LRF when the session is released in order to allow the LRF to release this resource.

7.2 IMS Registration for Emergency Session

The IMS emergency registration procedure shall follow the procedures as described in clause 5.2.2.3 of TS 23.228 [1] with the following modifications:

– The UE shall initiate an IMS emergency registration when all of the following conditions are met:

– either the UE is not already IMS registered or the UE is IMS registered but is roaming outside its home network;

– the UE has sufficient credentials to authenticate with the IMS network;

– the UE is able to detect emergency session.

The UE shall also initiate an IMS emergency registration when it receives an "IMS emergency registration required" response as a result of the emergency session request:

– If the UE initiates an IMS emergency registration, it shall first initiate an emergency access to the IP-CAN if emergency access has been defined for the particular type of IP-CAN. This is to ensure that the session attempt is handled in the VPLMN when the UE is roaming and provides appropriate priority treatment and access to appropriate network elements (e.g. to a particular PDG or UPF and P‑CSCF in the VPLMN).

– If the UE had already performed an emergency access when it receives an "IMS emergency registration required" response as a result of an emergency registration or emergency session request, it shall perform an emergency access followed by an emergency registration using a different VPLMN or SNPN if available to prevent looping.

– The UE shall use an indication in the emergency registration request. This indication may be used to inform the home network that roaming restrictions may not be applied.

– The user’s home network should ignore roaming restrictions for emergency registration requests.

P‑CSCF handles the registration requests with an emergency indication like any other registration request.

The S‑CSCF in the home network may modify the received registration expiration value from the request according to local regulation or operator policy in the serving system. The subsequent registration flows are like any other registration with the considerations defined in clauses 6.2.4 and 6.2.9.

7.3 Emergency Session Establishment in the Serving IMS network

If the UE is able to detect that the user is requesting an emergency session then it shall include an emergency service indication in the emergency session establishment request. In the case of NG-eCall, the UE shall include the eCall type of emergency service (automatic or manual) in the emergency session establishment request.

The UE shall follow the requirements in TS 22.101 [8] for domain priority and selection when UE attempts to make an emergency call.

For an attempt in the IM CN Subsystem of the PS domain, the attempt should be in the serving (visited if roaming) IM CN Subsystem of the PS domain.

If the initial attempt is in the CS domain and it fails, the serving (visited if roaming) IM CN Subsystem of the PS domain shall be attempted if the UE is capable and if not disallowed by applicable domain selection rules. If the initial attempt is in the IM CN Subsystem of the PS domain and it fails, the UE shall make the attempt in the CS domain (if the UE is capable and if for an appropriate service e.g., voice).

If the UE is aware that it does not have sufficient credentials to authenticate with the IMS network, it shall not initiate an IMS registration but immediately establish an emergency session towards the P‑CSCF, see clause 7.4.

Upon receiving an initial request for an emergency session, the P‑CSCF shall follow the rules and procedures described in TS 23.228 [1] with the following additions and clarifications:

– When a UE using public network traffic initiates an emergency session, the P‑CSCF is the IMS network entity, which detects an emergency session.

– For the case that the initial request carries an indication that the request is for emergency services, and the UE is not registered in the IMS network, see clause 7.4 for details.

– For the case that UE is IMS registered and the initial request does not carry an indication that the request is for emergency services, and the P‑CSCF is able to detect that the request is for emergency services, the P‑CSCF shall perform the "Non UE detectable Emergency Session" described in clause 7.1.2 above.

– For the case that the initial request carries an indication that the request is for emergency services, and the UE is registered in the IMS network, but not performed emergency registration:

a) the P‑CSCF shall reject the request indicating that IMS emergency registration required, if the UE is roaming;

b) the home P‑CSCF may reject the request indicating that IMS emergency registration required, based on operator policy.

– On receipt of a session establishment request, which is recognized to be for an emergency service, the P‑CSCF shall check whether the UE provided a TEL‑URI as its identity in the request. If a TEL‑URI is present in the request, the P‑CSCF shall check the validity of this TEL‑URI. If no TEL‑URI is present in the request and the P‑CSCF is aware about the TEL‑URI associated with the emergency registration, it shall provide the TEL‑URI to the E‑CSCF in the session establishment request.

– A P-CSCF operating in a network that supports calling number attestation and signing may, based on operator policy, be responsible for inserting attestation information related to the asserted calling identity associated with an emergency session.

– The P‑CSCF may query the IP-CAN for the location identifier.

– P‑CSCF shall prioritize emergency sessions over other non-emergency sessions.

– A P-CSCF may assert Resource-Priority information for an emergency session, if configured through operator policies.

– Emergency IP flows need to be identified by P‑CSCF in the Rx interface signalling to allow the PCRF to prioritize emergency service data flows over non-emergency service data flows within IP‑CAN. The detailed procedures are specified in TS 23.203 [20].

Handling of emergency sessions detected by an AS is specified in clause 6.2.8.

For the case where the emergency session is provided via the interconnect from a private network (as defined in ETSI TS 182 025 [38]), the following procedures apply:

– For private network traffic where operator policy allows so, do not apply emergency session detection and forward the session according to normal procedures.

– Otherwise emergency sessions within the IMS are routed to the PSAP via the E-CSCF.

Upon receiving an initial request for an emergency session, the E‑CSCF shall perform the following:

– if location information is not included in the emergency service request or if additional location information is required, the E‑CSCF, if required, retrieves the UE’s location information as described in clause 7.6 Retrieving Location information for Emergency Session.

– If location information is included by the UE, the E‑CSCF, if required requests the LRF to validate the location information.

– May determine or may request the LRF to determine the appropriate routing information which could be based on the type of emergency service requested, the UE’s location and any indication of an eCall.

– determine the default PSAP destination if routing based on UE’s location is required but the location is unknown.

– If the PSAP/emergency centre contains a point of presence within the IMS connectivity network, the E‑CSCF shall forward the emergency session initiation request directly to the PSAP/emergency centre, including any additional subscriber related identifier(s) received from P-CSCF.

– If the PSAP/emergency centre has its point of presence in the PSTN/ISDN network or the CS domain, the E‑CSCF uses the TEL‑URI obtained from the LRF and forwards the request to an appropriate BGCF/MGCF for routing in the GSTN. This number shall have the same format as used for CS emergency calls. The MGCF may insert any available location information in the PSTN/CS signalling.

NOTE: If an ESRN is received from the LRF, the E‑CSCF maps the received ESRN from the LRF to a TEL-URI before forwarding the request to MGCF.

7.4 IMS Emergency Session Establishment without Registration

When the UE initiates an emergency session establishment without prior IMS registration, it shall include both the "anonymous user" and "emergency service" indications in the emergency session establishment request to the P‑CSCF.

Based on local regulation, the P‑CSCF may reject "anonymous user" emergency session establishment with appropriate error code. UE shall not reattempt the "anonymous user" emergency session again via the same network.

When P‑CSCF accepts the "anonymous user" emergency session establishment, it forwards this request to an appropriate E‑CSCF although no security association between UE and P‑CSCF is established. Based on local regulation, P‑CSCF may retrieve additional subscriber related identifier(s) from IP-CAN and forward those identifiers to E-CSCF. Prior to forwarding the request to an appropriate E-CSCF, the P-CSCF may assert Resource-Priority information for an emergency session if configured through operator policies.

The E‑CSCF shall follow the same rules and procedure as defined for the Emergency Session Establishment in the Serving IMS network in clause 7.3 to route the anonymous emergency session.

Where required by local regulation, the E-CSCF shall derive a non-dialable callback number to include as the UE’s identity in the session establishment request and the location/routeing request (e.g. see Annex C of J‑STD‑036 [23]).

7.5 Interworking with PSAP

7.5.1 PSAP/Emergency centre located at the GSTN

No special procedure is defined. PSAP uses the MSISDN (E.164) of the user for call back. Emergency call and call back feature interactions are handled as specified in TS 22.101 [8].

7.5.2 PSAP/Emergency centre connected via IP using SIP

No special procedure is defined. PSAP uses any public user identity that it has received from the user for call back. Emergency call and call back feature interactions are handled as specified in TS 22.101 [8].

7.5.3 PSAP/Emergency centre connected via ECS

No special procedures are identified in IMS Core, the routing determination will be performed by the ECS. Emergency call and call back feature interactions are handled as specified in TS 22.101 [8].

7.5.4 PSAP supporting NG-eCall

It is assumed that the PSAP supporting the NG-eCall shall be able to receive and verify the consistency of the initial MSD within the initial SIP INVITE.

7.6 Retrieving Location information for Emergency Session

7.6.1 Acquiring location information from the UE or the network

When performing an emergency service, four scenarios for retrieving location information for routing purposes are considered:

– the UE knows its own location;

– the UE retrieves its location information from the network;

– the IMS core retrieves the location information. The related high level procedures are described below;

– location information is not needed to route the emergency call by the IMS core, optionally the emergency routing determination and location information retrieval may be performed by the Emergency Call Server (ECS) as part of the emergency session establishment procedure. In this case, the IMS core does not need to obtain the location information. See the details in Annex D.

Figure 7.6-1: Handling of location information in IMS emergency calls

1. The user initiates an emergency call.

2. The UE determines its own location or location identifier if possible. If the UE is not able to determine its own location, the UE may, if capable, request its location information from the IP-CAN, if that is supported for the used IP-CAN. If applicable, the IP-CAN delivers to the UE the UE’s geographical location information and/or the location identifier.

3. The UE sends an INVITE with an emergency indication to the IMS core. The INVITE should contain any location information that the terminal has. The location information may be geographical location information or a location identifier, which is dependent upon the access network technology. If the UE is not able to provide any location information, the IMS core may seek to determine the UE’s location from the LRF as described below. The INVITE may optionally contain information concerning the location solutions and position methods supported by the UE.

NOTE: The location solutions and position methods conveyed in the INVITE and the means of inclusion in the INVITE are outside the scope of this specification.

4. If the location information provided in step 3 is trusted and sufficient to determine the correct PSAP, the procedure continues from step 7 onwards. If the location information is insufficient or if the IMS core requires emergency routing information, or if the IMS core is required to validate the location information, or if the IMS core is required to map the location identifier received from the UE into the corresponding geographical location information, the IMS core sends a location request to the LRF. The request shall include information identifying the IP-CAN and the UE and may include means to access the UE (e.g. UE’s IP address). The request shall also include any location information provided by the UE in step 2. The request may optionally include any information concerning the location solutions and position methods supported by the UE.

5. The LRF may already have the information requested by IMS core or LRF may request the UE’s location information.

5a. The means to obtain the location information may differ depending on the access technology the UE is using to access the IMS. The SUPL procedures defined in OMA AD SUPL: "Secure User Plane Location Architecture" [15], OMA TS ULP: "User Plane Location Protocol" [16], may be used if supported by the terminal and if it is possible to establish a user plane connection between the UE and the SUPL server. Information provided in step 4 concerning the location solutions and position methods supported by the UE may optionally be used by the LRF to help determine the means to obtain the location information.

5b. If configured to provide an NPLI for WLAN access, and if the UE is not roaming, the LRF queries HSS for every access the LRF is configured for. The LRF issues a separate query for every access. If the LRF cannot obtain an NPLI, it shall invoke procedure 5a.

The LRF may invoke an RDF to convert the location information received in step 4 or obtained in step 5a into PSAP routing information, but LRF’s interactions with RDF are out of scope of the present specification. The LRF may store the location information, but only for a defined limited time in certain regions, according to regional requirements.

6. The LRF sends the location information and/or the routing information to the IMS core. The LRF may also return correlation information (e.g. ESQK) identifying itself and any record stored in step 5a.

7. The IMS core uses the routing information provided in step 6 or selects an emergency centre or PSAP based on location information provided in step 3 or 6 and sends the request including the location information and any correlation information and possibly location information source, e.g., positioning method that was used to obtain the location information to the emergency centre or PSAP.

7a. The INVITE is sent to an MGCF/MGW;

7b. The IAM is continued towards the emergency centre or PSAP; or

7c. The INVITE is sent directly to the emergency centre or PSAP.

8. The emergency call establishment is completed.

9. The PSAP may send a location request to the LRF to get the initial location information for the target UE, or to request LRF to get updated, i.e. current, location information for the target UE. The PSAP may determine the LRF based on the location and/or correlation information received in step 7. The PSAP may also include the correlation information in the request to the LRF.

10. Depending on the access type, UE location is determined as follows:

10a. For non WLAN-access and optionally for WLAN access, the LRF determines the target UE’s location using one of the means listed in step 5a above. The LRF may use the correlation information received in step 9 to retrieve information about the UE that was stored in step 5a.

10b. For WLAN access, the LRF may use the correlation information received in step 6 to send a request to the IMS core to retrieve a UPLI from the UE. The IMS core uses the emergency call signalling channel for that purpose. Steps 10b1 to 10b4 depict this procedure. If UPLI is not available when the request comes to the UE (e.g. due to insufficient time), and UPLI cannot be returned, the UE may also provide UPLI once, when available by executing step 10b3 following step 8.

10c. For WLAN access, and if the LRF is configured to provide an NPLI for WLAN access, and if the UE is not roaming, the LRF queries HSS for every access the LRF is configured for. The LRF issues a separate query for every access. If the LRF cannot obtain an NPLI, it shall invoke procedure 10a.

11. The LRF returns the initial or updated location information to the emergency centre or PSAP. As an option for initial location, the LRF may instigate the location step 10a before the request in step 9 is received and may send the initial location to the emergency centre or PSAP either after the request in step 9 is received or before it is received.

12. The emergency call is released.

13. The IMS core may indicate to the LRF that the call is released. The LRF deletes any record stored in step 5a.

7.6.2 Void

7.6.3 Void

7.7 Transfer of MSD for eCall

7.7.1 MSD Transfer/Acknowledgement during Session Establishment with PSAP supporting NG-eCall

Figure 7.7.1-1 illustrates a high level call flow for an interworking scenario between a UE and a PSAP supporting NG-eCall.

This scenario occurs, when the UE detects that the NG-eCall is supported by the IP-CAN.

Figure 7.7.1-1: NG-eCall Scenario with PSAP supporting NG-eCall

1. The UE performs steps 1 to 6 of the procedure shown in Figure 7.1.

2. The UE sends an initial emergency SIP INVITE to the IMS core. The SIP INVITE shall contain the initial MSD and the eCall type of emergency service indicator (automatic, manual).

3a. The IMS core routes the SIP INVITE towards the appropriate PSAP.

NOTE: Routing within the IMS core is based on the UE location and the eCall type of emergency service indication, but not on the content of the initial MSD. The PSAP may use also location data contained within the initial MSD.

3b. The PSAP verifies the correctness of the initial MSD and returns a SIP 200 OK to the IMS core. The SIP 200 OK explicitly includes a positive or negative acknowledgement for the initial MSD.

3c. The IMS core proxies the SIP 200 OK to the UE.

4. The emergency call establishment is completed. In addition to the transfer of MSD, media channels are established. In this case the emergency voice channel is established.

5. The established audio channel supports bidirectional voice communication,

7.7.2 MSD Transfer/Acknowledgement during Session Establishment with a PSAP Not supporting NG-eCall (inband means)

Figure 7.7.2-1 illustrates a high level call flow for an interworking scenario between a UE and a PSAP via the CS domain.

This scenario may occur in the case, when PS access is available, but the UE does not detect that the NG-eCall is supported by the IP-CAN and there is no CS access available. In this case, the UE shall establish a regular IMS emergency call.

A similar scenario may occur in the case, when the UE detects that the IP_C AN supports NG-eCall and initiates an NG eCall but the session is handled by a PSAP not supporting NG-eCall. The only exception would be step 2 and where the SIP INVITE shall contain the initial MSD and the eCall type of emergency service indicator (automatic, manual).

Figure 7.7.2-1: eCall Scenario with PSAP not supporting NG-eCall

1. The UE performs steps 1 to 6 of the procedure shown in Figure 7.1.

2. The UE sends an initial emergency SIP INVITE to the IMS core. The SIP INVITE shall be setup as follows:

– if the UE has not received the "eCall supported" indication, the UE shall include the eCall type of emergency service indication (automatic, manual) and shall not include the initial MSD if the PS access is available;

– if the UE has received the "eCall supported" indication, the UE shall include the initial MSD and the eCall type of emergency service indicator (automatic, manual).

3. The IMS core routes the emergency SIP INVITE towards the appropriate PSAP. In this call flow, the appropriate PSAP is accessed over the MGCF and the CS domain after translating the eCall type of emergency service indication into the corresponding MSISDN.

3a. The SIP INVITE is sent to an MGCF/MGW for interfacing to the CS domain.

3b. The MGCF sends an IAM towards the appropriate PSAP for the emergency voice call.

4. The emergency voice call establishment is completed with a voice path only.

5. If the UE has sent the MSD in step 2 and did not receive acknowledgement for the initial MSD included in the SIP INVITE, or the UE did not send the MSD in step 2 the UE shall attempt to transfer the MSD to the PSAP via the eCall Inband Modem, as defined in TS 26.267 [42].

7.7.3 Transfer of an updated MSD

Figure 7.7.3-1 illustrates a high level call flow for transfer of an updated MSD in the case that the emergency centre or PSAP is accessed via the PS domain. The call flow is applicable following establishment of an emergency services session for eCall as described in clause 7.1.1 in which the initial MSD is transferred in the INVITE and prior to release of the emergency services session.

Figure 7.7.3-1: Sending an updated MSD for eCall

1. If the emergency centre or PSAP requires an MSD update, it may send a request for MSD to the IMS Core.

2. The IMS Core shall forward the request to the UE.

3. The UE shall send the most recent MSD to the IMS Core.

4. The IMS Core shall forward the MSD to the emergency centre or PSAP.

NOTE: Whether an acknowledgement message for the successful receipt of updated MSD by the PSAP is further provided to the UE is resolved in stage 3 level.

Annex A (informative):
Void

Annex B (informative):
Void

Annex C (normative):
IMS emergency services using Fixed Broadband Access

C.1 Location Retrieval for emergency services over fixed broadband access

These procedures described in this annex apply when the IP-CAN contains a Network Attachment Subsystem with a CLF as specified in ETSI ES 282 004 [18].

C.1.1 High Level Principles for Emergency location information for fixed broadband access

In addition to the architecture described in clause 5.1 above, the P‑CSCF may have an interface to an LRF which may contain a CLF as described below in figure C.1. For more information on the CLF refer to ETSI ES 282 004 [18].

Figure C.1: Additional P‑CSCF interface for fixed broadband access

For fixed broadband access, the UE may know its own network location or geographical location. If the UE knows its location, it shall insert the location information in the SIP INVITE request when establishing the emergency IMS session.

As an alternative, if the UE is not able to determine its own location, the UE should try to request its location from the access network, if the UE supports such functionality. The access network may know the location of the access point where the UE is connected to. In this case, the UE should request the location information from the access network according to clause 7.6. The UE shall insert the location information received as a response to the location query, if any, in the emergency SIP INVITE request. This location information may be network based, e.g. line identification, or geographical location information.

If the UE does not know its location and is unable to obtain its location from the access network, the UE should have a means to indicate in the emergency SIP INVITE that its location is unknown.

If the UE does not provide location information, the P‑CSCF may request location information from the LRF as described in clause 7.6 and insert the location information in the received INVITE request. The IMS network may also request location information from the LRF in the case that verification of the location information provided by the UE is required. After such verification, the IMS network may insert the location information received from the LRF or override the location information received from the UE before routing the request to the PSAP.

Alternatively, subject to operator policy, the S-CSCF may receive from the HSS a reference location of the user at registration, and insert it in the INVITE request, when network-provided location information is not already present. The reference location (e.g. line identification) is determined by the operator as part of the user profile.

NOTE: The reference location alternative is applicable to non-nomadic services provided on fixed lines for emergency sessions that are routed through the S-CSCF (see clause 6.2.4). The reference location corresponds the physical location of the fixed line.

C.1.2 Retrieval of location information for emergency services over fixed broadband access

In addition to clause 7.6, the following applies for a fixed broadband access:

– When the UE is requesting to retrieve the location information from IP-CAN, the UE may use the DHCP option for coordinate-based geographic location of the client as specified by IETF in RFC 3825 [9] and the DHCP option that allows hosts to learn their civic location via DHCP, as specified in RFC 4676 [10]. This DHCP option shall not be used by an UE on an IP-CAN using 3GPP RAT.

– The line identifier used by the UE with fixed broadband access may be authenticated by the IMS core.

Annex D (informative):
Examples of call flows according to NENA I2 recommendations

This clause provides the examples of call flows according to NENA I2 recommendations [17].