Keith Drage

1. CP-a060003Emergency call stage 2 requirements - A presentation of the requirements from 3GPP TS 23.167 Keith Drage

2. Introduction • 3GPP works to a 3 stage methodology. This represents the stage 2 work which is documented in 3GPP TS 23.167. • Stage 2 is meant to be a documentation of the functional requirements and functional architecture in a protocol independent manner. • The functional architecture is broken down into functional elements which may in some implementations be in separate physical boxes, but may in other implementations be combined into the same physical box.

3. General principles • Builds on existing IMS, which has local network functionality and home network functionality • Mobile terminals may well have simultaneous access to both the CS domain and the IMS for making emergency calls. Terminals making emergency calls need to decide which one to use (CS domain by default) • Emergency calling on IMS is being introduced in release 7. Release 5 and 6 IMS direct the terminal to make the emergency call on the CS domain • Mobile terminals roam, and may not be using the home network to which they are subscribed • Mobile terminals contain a UICC. Some regulators require mobile terminals without a UICC to be able to still make a mobile call. These slides do not address this issue. In particular such mobile terminals cannot authenticate with the network, and cannot identify their home network • In general mobile terminals are given extensive capabilities to recognise emergency calls, and the terminal will make such calls as emergency calls, rather than as normal voice calls

4. IMS recap (extracted from RFC 4083) • For a particular cellular device, the 3GPP IMS network is further decomposed in a home network and a visited network. • An IMS subscriber belongs to his or her home network. Services are triggered and may be executed in the home network. One or more SIP servers are deployed in the SIP home network to support IMS. Among those SIP servers, there is a SIP serving proxy (S-CSCF), which is also acting as a SIP registrar. Authentication/Authorization servers may be part of the home network as well. Users are authenticated in the home network. • A SIP outbound proxy (P-CSCF) is provided to support the User Agent (UA). The SIP outbound proxy is typically located in the visited network, although it may be located in the home network as well. The SIP outbound proxy maintains security associations between itself and the terminals.

5. IMS recap (cont.) • The home network may also support one or more SIP edge proxies (I-CSCF). These nodes may act as the first entry points for SIP signaling to the home network and may determine (with the help of location servers) which SIP registrar server to assign to a particular user. • The 3GPP IM CN Subsystem is designed to be access independent. Access is granted from 3GPP cellular terminals or from other terminals that use other accesses out of the scope of 3GPP

6. Reference architecture (3GPP TS 23.167 subclause 5.1)

7. P-CSCF discover and registration (1) • Because 3GPP allows roaming to a local network that is not the home network, in general a UE will go through an emergency registration procedure with the local network even if it has an existing registration • 1 exception: • In the case a UE is already IMS registered and is not roaming, the UE may skip the additional emergency registration • Otherwise: • If an emergency session establishment request is routed to a P-CSCF (SIP outbound proxy) located in the home network, the home network should be able to detect that the session is for emergency service (whether indicated as such or not) and respond to the UE indicating that the UE should initiate an emergency session in the visited network (e.g. via the CS domain of the visited network) • Emergency registration is still with the home network because of the 3GPP link between authentication and registration

8. P-CSCF discover and registration (2)

9. UE requirements (3GPP TS 23.167 subclause 6.1) • Should be able to detect an emergency session establishment request • Use a special emergency Public User Identity in the IMS emergency registration request • Include an emergency service indication in the emergency session request • Include an equipment identifier in the request to establish an emergency session for "anonymous user“ • Attempt the emergency call in CS domain, if capable • Handle a 380 (Alternative Service) response with the type set to "emergency" as a result of emergency attempt • Other general requirements of UE shall be referred to the general requirements of emergency calls in TS 22.101 [8]

10. UE requirements (cont) • The UE initiates the emergency session establishment request, and for the purpose of processing the request properly in the network the following specific information is supplied in the request message • Emergency session indication • Emergency Public User Identity • Optionally, type of emergency service. It could be implied in the above emergency session indication • UE's location information, if available • The Tel URI associated to the emergency Public User Identity, if available

11. P-CSCF requirements (3GPP TS 23.167 subclause 6.2.1 • Handle registration requests with an emergency Public User Identity like any other registration requests and forward the request to the IBCF or I-CSCF in the user's home network • Detect an emergency session establishment request • Reject/allow unmarked emergency requests • Reject/allow anonymous emergency requests • May query IP-CAN for location identifier • Select an Emergency CSCF in the same network to handle the emergency session request. The selection method is not standardized in the present document • 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 emergency Public User Identity

12. E-CSCF requirements (3GPP TS 23.167 subclause 6.2.2) • Receive an emergency session establishment request from a P-CSCF • 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 • 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 national requirements, the E-CSCF may send the contents of the P-asserted ID or UE identification to the LRF • Based on local policy, the E-CSCF may route the emergency IMS call to Emergency Call Server (NENA) for further call process

13. Location Retrieval Function (LRF) • The LRF handles the retrieval of location information for the UE including, where required, interim location information, initial location information and updated location information. The LRF may interact with a separate RDF or contain an integrated RDF in order to obtain routing information. The LRF may interact with a separate GMLC or contain an integrated GMLC in order to obtain location information. The LRF may interact with or contain other types of location server functions in order to obtain location information • The Routing Determination Function (RDF), which may be integrated in a Location Server (e.g. GMLC) or in an LRF, provides the proper PSAP destination address to the E-CSCF for routing the emergency request. It can interact with a location functional entity (e.g. GMLC) to manage ESQK allocation and management, and deliver location information to the PSAP • Note: How these entities all fit together is somewhat confused in 23.167 at the moment, due to trying to encompass both TISPAN and NENA requirements