Transcript Emergency call stage 2 requirements

CP-a060003
Emergency 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 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
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)
Le (e.g. E2)
from PSAP
LRF
Ml
Mm
UE
Gm
P-CSCF
Mw
E-CSCF
Mi/Mg
to PSAP
(via PSTN
via BGCF/
MGCF)
Mw
S-CSCF
to PSAP or ECS
via IP mutimedia
Network
Mm/Mw
from PSAP
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
1. Detect Emergency
Emegency
sesssion request
2. Terminate
UE capability
anyand
ongoing
resource
communication
validation
3. Bearer Registration
4. Bearer Resource Request
5. P-CSCF Discovery
6. IMS Registration
7. Establish Emergency Session (and Bearer Resources)
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.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
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