Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.167  Word version:  18.2.0

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

 

C (Normative)  emergency services using Fixed Broadband Accessp. 39

C.1  Location Retrieval for emergency services over fixed broadband accessp. 39

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 accessp. 39

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].
Reproduction of 3GPP TS 23.167, Fig. C.1: Additional P-CSCF interface for fixed broadband access
Up
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.
Up

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

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 and the DHCP option that allows hosts to learn their civic location via DHCP, as specified in RFC 4676. 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.
Up

D  Examples of call flows according to NENA I2 recommendationsp. 41

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

D.1  ECS redirecting IMS emergency callp. 41

Reproduction of 3GPP TS 23.167, Fig. D.1:
Up
This flow is supported by the procedures in clause 7.3, where the E-CSCF need not enquire the LRF for location information. Additional steps defined here are standard SIP methods, but not defined in this specification.
Detailed description of the procedure:
Step 1.
An IMS emergency call is initiated.
Step 2.
The E-CSCF sends an Invite message with 911 or other well-known emergency number as the dialled number, the UE's location information in a Location Object (LO) if available, and the UE's media capabilities encapsulated in a SDP payload, to the ECS.
Step 3.
Based on the received Location Object (LO), the ECS will determine to which PSAP/EC the call should be routed and allocate an ESQK from the ESQK pool associated with that particular PSAP/EC. The ECS then will format a SIP response with the retrieved ESRN/ESQK in the Contact fields to redirect the emergency call.
Step 4.
The IMS Core uses the ESRN/ESQK received in the call redirect message to format an INVITE message properly, and sends it to the MGCF/MGW. A P-Asserted-Identity field may be inserted in the INVITE message, it contains either an ESQK or the CBN.
Step 5.
The emergency call setup continues with the PSAP/EC.
Step 6.
The ECS initiates a subscription at the IMS Core to request a notification of call termination of the emergency call.
Step 7.
An acknowledgement is returned.
Step 8.
The emergency session establishment signalling continues.
Step 9.
The PSAP retrieves location from the ECS.
Step 10.
The emergency session is released.
Step 11.
The IMS Core sends an Event Notification message to the ECS with an Event indicating that the 911 call has been terminated. At this time, the ESQK allocated to the emergency session can be released.
Step 12.
An acknowledgement is returned to the IMS Core.
Up

D.2  ECS routes the emergency call to the gateway with record routep. 43

Reproduction of 3GPP TS 23.167, Fig. D.2:
Up
This flow is supported by the procedures in clause 7.3, where the E-CSCF need not enquire the LRF for location information.
Detailed description of the procedure:
Step 1.
An IMS emergency call is initiated.
Step 2.
The E-CSCF sends an Invite message with 911 or other well-known emergency number as the dialled number, the UE's location information in a Location Object (LO) if available, and the UE's media capabilities encapsulated in a SDP payload, to the ECS.
Step 3.
Based on the received Location Object (LO), the ECS will determine to which PSAP/EC the call should be routed and allocate an ESQK from the ESQK pool associated with that particular PSAP/EC. The ECS then re-issues an Invite to an appropriate MGCF/MGW with the ESRN/LRO, ESQK and a record route indication. or the call to be routed to PSAP the P-Asserted-Identity contains ESQK, A P-Asserted-Identity field may be inserted in the INVITE message, f for the call to be routed to other emergency answering centre the P-Asserted-Identity contains the CBN.
Step 4.
The emergency call setup continues with the PSAP/EC.
Step 5.
The emergency session establishment signalling continues.
Step 6.
The PSAP retrieves location from the ECS.
Step 7.
Either the caller or PSAP initiates the call termination signalling.
Step 8.
The E-CSCF or MGCF/MGW forwards the hang-up message to the ECS. At this time, the ESQK allocated to the emergency session can be released.
Step 9.
The ECS sends an OK to the E-CSCF or MGCF/MGW.
Step 10.
The call termination signalling continues.
Up

Up   Top   ToC