CP-a060003Emergency call stage 2 requirements - A

presentation of the requirements from 3GPP TS 23.167

Keith Drage

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.

General principlesBuilds 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

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.

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

Reference architecture (3GPP TS 23.167 subclause 5.1)

Ml

to PSAP (via PSTNvia BGCF/

MGCF)

to PSAP or ECS via IP mutimedia

Network

UE P-CSCF E-CSCFGm Mw

Mi/Mg

Mm

S-CSCFMm/Mw

Mw

from PSAP

Le (e.g. E2)

from PSAPLRF

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

P-CSCF discover and registration (2)

UE IP - CAN IMS

3. Bearer Registration

4. Bearer Resource Request

5. P - CSCF Discovery

6. IMS Registration

7. Establish Emergency Session (and Bearer Resources)

1. Detect Emegency sesssion request

2. Terminate any ongoing communication

IP - CAN

3. Bearer Registration

4. Bearer Resource Request

5. P - CSCF Discovery

6. IMS Registration

7. Establish Emergency Session (and Bearer Resources)

1. Detect Emergency sesssion request

2. UE capability and resource validation

Emergency Center or PSAP

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]

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

P-CSCF requirements (3GPP TS 23.167 subclause 6.2.1Handle 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

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

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