Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 23.167  Word version:  16.3.0

Top   Top   Up   Prev   Next
1…   4…   5…   7…   7.5…   7.7…   C…   E…   I…   K…   L…

 

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.

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.

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.

7.5.4  PSAP supporting NG-eCall |R14|

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 SessionWord‑p. 29

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.
(not reproduced yet)
Figure 7.6-1: Handling of location information in IMS emergency calls
Up
Step 1.
The user initiates an emergency call.
Step 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.
Step 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.
Step 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.
Step 5.
The LRF may already have the information requested by IMS core or LRF may request the UE's location information.
Step 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.
Step 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.
Step 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.
Step 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.
Step 7a.
The INVITE is sent to an MGCF/MGW,
Step 7b.
The IAM is continued towards the emergency centre or PSAP, or
Step 7c.
The INVITE is sent directly to the emergency centre or PSAP.
Step 8.
The emergency call establishment is completed.
Step 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.
Step 10.
Depending on the access type, UE location is determined as follows:
Step 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.
Step 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.
Step 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.
Step 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.
Step 12.
The emergency call is released.
Step 13.
The IMS core may indicate to the LRF that the call is released. The LRF deletes any record stored in step 5a.
Up

7.6.2Void

7.6.3Void


Up   Top   ToC