All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
All-IP Network Emergency Call Support
2
3
4
CONTENTS
5
6
7
List of Figures ..................................................................................................................................................................... iii
8
9
List of Tables ...................................................................................................................................................................... iv
10
11
Foreword .............................................................................................................................................................................. v
12
13
1
14
1.1
15
16
17
Introduction ............................................................................................................................................................ 1
2
Scope ....................................................................................................................................................... 1
References .............................................................................................................................................................. 2
18
2.1
Normative References ............................................................................................................................. 2
19
2.2
Informative Reference ............................................................................................................................. 3
20
21
22
3
Definitions, Abbreviations and Acronyms ............................................................................................................. 4
23
3.1
Definitions ............................................................................................................................................... 4
24
3.2
Abbreviations and Acronyms .................................................................................................................. 5
25
26
27
28
29
4
Terminology........................................................................................................................................................... 7
5
High Level Principles ............................................................................................................................................ 8
30
5.1
Architectural Principles ........................................................................................................................... 8
31
5.2
Naming and Addressing ........................................................................................................................ 10
5.3
Location information for Emergency Sessions ...................................................................................... 10
5.3.1
General Location Information Principles ................................................................................ 10
5.3.2
Void ......................................................................................................................................... 10
5.4
IP-CAN .................................................................................................................................................. 10
32
33
34
35
36
37
38
39
6
40
41
42
Architectural Model and Reference Points .......................................................................................................... 12
6.1
Reference architecture ........................................................................................................................... 12
6.2
Reference points .................................................................................................................................... 13
43
44
7
45
46
47
Functional Descriptions ....................................................................................................................................... 14
7.1
UE .......................................................................................................................................................... 14
7.2
IMS Functional entities ......................................................................................................................... 14
7.2.1
Proxy-CSCF ............................................................................................................................ 14
7.2.2
Emergency-CSCF.................................................................................................................... 15
7.2.3
Location Retrieval Function .................................................................................................... 15
7.2.4
Serving CSCF .......................................................................................................................... 16
48
49
50
51
52
53
54
55
56
57
58
59
8
Procedures Related to Establishment of IMS Emergency Session ...................................................................... 17
8.1
High Level Procedures for IMS Emergency Services ........................................................................... 17
8.1.1
UE Detectable Emergency Session ......................................................................................... 17
8.1.2
Non UE detectable Emergency Session .................................................................................. 18
8.1.3
Emergency Session Establishment using LRF/RDF ............................................................... 19
i
Contents
X.S0049-0 v1.0
A
All-IP Network Emergency Call Support
8.2
IMS Registration for Emergency Session .............................................................................................. 19
8.3
Emergency Session Establishment in the Serving IMS network ........................................................... 20
8.4
IMS Emergency Session Establishment without Registration ............................................................... 22
8.5
Interworking with PSAP ........................................................................................................................ 22
8.5.1
PSAP connected via the PSTN/ISDN Network ...................................................................... 22
8.5.2
PSAP connected via IP using SIP ........................................................................................... 22
8.6
Retrieving Location information for Emergency Session ...................................................................... 22
Annex A (Normative): IMS Emergency Services Using HRPD/PDS Network ................................................. 26
A.1
Requirements on the HRPD Network as an IP-CAN ............................................................................ 26
A.2
UE Specific Behavior for Emergency Calls over HRPD ....................................................................... 26
A.2.1 Without Existing Data Session ................................................................................................ 26
A.2.2 With Existing Data Session ..................................................................................................... 27
A.3
Information Flows ................................................................................................................................. 27
A.3.1 Emergency Call: HRPD Session Establishment for Unauthenticated Caller .......................... 27
A.3.2 Emergency Call: Authenticated UE while Roaming ............................................................... 30
B
Annex B (Normative): Emergency Public User Identity ..................................................................................... 33
C
Annex C (Normative): Carrier-ID....................................................................................................................... 34
D
C.1
DHCPv6 Options ................................................................................................................................... 34
C.2
DHCP Options ....................................................................................................................................... 35
Annex D (Normative): Enhancements to MMD Stage 3 for Emergency Services Support................................. 36
ii
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
3
LIST OF FIGURES
4
5
6
Figure 1
E-CSCF in Reference Architecture ................................................................................................ 12
Figure 2
Terminal Detected Emergency Calls .............................................................................................. 17
Figure 3
Emergency Session Establishment Procedure Using LRF/RDF .................................................... 19
Figure 4
Handling of Location Information in IMS Emergency Calls. ........................................................ 23
Figure 5
Unauthenticated UE Initiates an Emergency Call .......................................................................... 28
Figure 6
Authorized UE Initiates an Emergency Call while Roaming ......................................................... 31
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
iii
List of Figures
X.S0049-0 v1.0
All-IP Network Emergency Call Support
LIST OF TABLES
Table 1
DHCPv6 Vendor Class option ........................................................................................................ 34
Table 2
DHCPv6 Vendor-Specific Information option ............................................................................... 34
Table 3
DHCP Vendor Class Identifier option ............................................................................................ 35
Table 4
DHCP Vendor-Specific Information option ................................................................................... 35
iv
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
3
REVISION HISTORY
4
5
6
7
8
Revision
0 v1.0
Changes
This is the first issue of this specification
Date
February 2008
9
1
0
1
1
1
2
1
3
1
4
1
5
1
6
1
7
1
8
1
9
2
0
2
1
2
2
2
3
2
4
2
5
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
v
List of Tables
X.S0049-0 v1.0
All-IP Network Emergency Call Support
FOREWORD
(This foreword is not part of this Specification.)
This document contains portions of material copied from 3GPP document number TS 23.167. The
copyright on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB –
Association of Radio Industries and Businesses, Japan; CCSA – China Communications Standards
Association, China; ETSI – European Telecommunications Standards Institute; ATIS, USA; TTA –
Telecommunications Technology Association, Korea; and TTC – Telecommunication Technology
Committee, Japan, which have granted license for reproduction and for use by 3GPP2 and its
Organizational Partners.
Annex A, B, C and D are normative and are part of this Specification.
vi
All-IP Network Emergency Call Support
1
2
1
X.S0049-0 v1.0
Introduction
3
This document specifies Emergency Call handling for the Multimedia Domain (MMD) [2]-[11].
4
5
6
7
1.1
Scope
8
9
10
11
12
13
14
15
16
17
18
19
20
This document defines the stage-2 service description and normative stage 3 procedures in Annex D
for emergency services in the IP Multimedia Core Network Subsystem (IMS), including the elements
necessary to support IP Multimedia (IM) emergency services.
This document covers also the Access Network aspects that are crucial for the provisioning of IMS
emergency services. In particular HRPD [12] is supported. For cdma2000-1X access networks the
traditional circuit switch approach for emergency services [23] should be used.
For the current phase of emergency call support, it is assumed that PSAPs support Circuit-Switched
(CS) or IP voice calling capability. In the future more capable PSAPs may come into being, which
may have the capability to send and receive other types of media (e.g., pictures with escape routes,
video, etc.). This may be the subject of a future revision of this and other associated documents.
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
1
1 Introduction
2
2.1
References
Normative References
The following standards contain provisions which, through reference in this text, constitute provisions
of this Specification. At the time of publication, the editions indicated were valid. All standards are
subject to revision, and parties to agreements based on this Standard are encouraged to investigate the
possibility of applying the most recent editions of the standards indicated below. ANSI and TIA
maintain registers of currently valid national standards published by them.
2 References

References are either specific (identified by date of publication, edition number, version
number, etc.) or non specific.

For a specific reference, subsequent revisions do not apply.

For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2
document, a non-specific reference implicitly refers to the latest version of that document in
the same Release as the present document.
[1]
3GPP2 X.S0011-005-D: Wireless IP Network Standard: Accounting Services and 3GPP2
RADIUS VSAs
[2]
3GPP2 X.S0013-000: All-IP Core Network Multimedia Domain; Overview
[3]
3GPP2 X.S0013-002: IP Multimedia Subsystem (IMS); Stage-2
[4]
3GPP2 X.S0013-003: IP Multimedia (IM) Session Handling; IM Call Model
[5]
3GPP2 X.S0013-004: IP Multimedia Call Control Protocol Based on SIP and SDP;
Stage-3
[6]
Void
[7]
3GPP2 X.S0013-006: Cx Interface Based on the Diameter Protocol; Protocol Details
[8]
Void
[9]
Void
[10]
Void
[11]
3GPP2 X.S0013-011: Sh Interface Based on the Diameter Protocol
[12]
3GPP2 C.S0024-A: cdma2000 High Rate Packet Data Air Interface Specification
[13]
Void
[14]
Void
[15]
Void
[16]
IETF RFC 3261: SIP: Session Initiation Protocol
[17]
IETF RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax
[18]
IETF RFC3966: The tel URI for Telephone Numbers
[19]
3GPP2 S.R0115-0: All-IP Emergency Call Support; Stage 1 Requirements
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
[20]
OMA AD SUPL: Secure User Plane Location Architecture,
http://www.openmobilealliance.org
[21]
OMA TS ULP: User Plane Location Protocol, http://www.openmobilealliance.org.
[22]
NENA I2 Architecture: Interim VoIP Architecture for Enhanced 9-1-1 Services (i2)
[23]
J-STD-036-B: Enhanced Wireless 9-1-1, Phase 2; June 2005
[24]
IETF RFC 4119: A Presence-based GEOPRIV Location Object Format
[25]
3GPP2 X.S0002-0: MAP Location Services Enhancements
[26]
3GPP2 X.S0013-012: MMD Service Based Bearer Control – Stage 2
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
2.2
Informative Reference
17
18
19
[27]
3GPP2 S.R0037: IP Network Architecture Model for cdma2000 Spread Spectrum
Systems
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
3
2 References
3
Definitions, Abbreviations and Acronyms
This section contains definitions and acronyms that are used throughout the document.
3.1
Definitions
Emergency-CSCF (E-CSCF)
The Emergency-CSCF handles certain aspects of emergency sessions, e.g., routing of emergency
requests to the correct PSAP.
Emergency Service Query Key (ESQK)
A 10-digit North American Numbering Plan number used to identify a particular emergency call
instance. It is used by the LRF as a key to look up for the location information and callback
information associated with the emergency call instance and is also used by the PSAP to query location
information from the LRF.
Emergency Service Routing Key (ESRK)
See J-STD-036 [23].
Emergency Service Routing Number (ESRN)
North American Numbering Plan number used for routing of an emergency call to the appropriate
gateway for an eventual delivery towards a CS-based PSAP.
Geographical Location Information
Location indicated in geographical terms, for example geographical coordinates or street address
(e.g., as supported by IETF RFC 4119 [24]).
IP-Connectivity Access Network (IP-CAN)
The collection of network entities and interfaces that provides the underlying IP transport connectivity
between the UE and the IMS entities. An example of an “IP-Connectivity Access Network” is
HRPD/PDS.
Location Identifier
Information about the current location of the UE in the network. Location is indicated in network
terms, for example using the global cell id in cellular networks (OMA-Location also uses this term, but
OMA so far defines the Location Identifier only for cellular access.)
Location Information
Location information may consist of a Location Identifier, and/or Geographical location information.
Location Retrieval Function (LRF)
This functional entity 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 SLP/MPC [20, 25] or contain an integrated
3 Definitions, Abbreviations and Acronyms
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
SLP/MPC 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.
2
3
4
Last Routing Option (LRO)
5
A number, which may be used in the event of network failure towards a specific location based PSAP
or a number that can be associated to a national or default PSAP.
6
7
8
9
Public Safety Answering Point (PSAP)
10
A physical location that receives emergency calls from the public.
11
12
13
Routing Determination Function (RDF)
14
The functional entity, which may be integrated in a Location Server (e.g., SLP/MPC) or in an LRF that
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., SLP/MPC) to manage ESQK allocation, and deliver
location information to the PSAP.
15
16
17
18
19
20
21
3.2
Abbreviations and Acronyms
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
This section provides a definition of the abbreviations used within this recommendation, as:
AAA
AN
AS
CS
CSCF
DHCP
E-CSCF
ESQK
HSS
I-CSCF
IP-CAN
IMS
IMSI
IP
IPv4
IPv6
L2TP
LRF
MGW
MGCF
MPC
MRFC
OMA
P-CSCF
PCRF
PDE
PDS
PDSN
PPP
Authentication, Authorization, and Accounting
Access Network
Application Server
Circuit Switched
Call Session Control Function
Dynamic Host Configuration Protocol
Emergency-CSCF
Emergency Services Query Key
Home Subscriber Server
Interrogating CSCF
IP Connectivity Access Network
IP Multimedia Subsystem
International Mobile Subscriber Identity
Internet Protocol
Internet Protocol Version 4
Internet Protocol Version 6
Layer 2 Tunneling Protocol
Location Retrieval Function
Media Gateway
Media Gateway Control Function
Mobile Positioning Center
Media Resource Function Controller
Open Mobile Alliance
Proxy-CSCF
Policy Charging Rules Function
Position Determining Entity
Packet Data Subsystem
Packet Data Serving Node
Point to Point Protocol
5
3 Definitions, Abbreviations and Acronyms
PSAP
PSTN
QoS
MMD
NAI
RDF
URI
URL
SCS
S-CSCF
SIP
SLP
SUPL
UE
Public Safety Answering Point
Public Switched Telephone Network
Quality of Service
Multimedia Domain
Network Access Identifier
Routing Determination Function
Uniform Resource Identifier
Uniform Resource Name
Service Capability Server
Serving CSCF
Session Initiation Protocol
SUPL Location Platform
Secure User Plane for Location
User Equipment
3 Definitions, Abbreviations and Acronyms
6
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
4
X.S0049-0 v1.0
Terminology
3
4
This document uses the following “verbal forms” and “verbal form definitions”:
5
6
1.
“shall” and “shall not” identify items of interest that are to be strictly followed and from
which no deviation is recommended,
2.
“should” and “should not” indicate items of interest that are highly desirable and particularly
suitable, without identifying or excluding other items; or (in the negative form) indicate items
of interest that are not desirable, are not particularly suitable, or are not recommended but not
prohibited, and
3.
“may” and “may not” indicate items of interest that are optional but permissible within the
limits of this recommendation.
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
7
4 Terminology
5
5.1
High Level Principles
Architectural Principles
The solution for emergency sessions in the IMS fulfils the following architectural requirements:
1.
If the UE is attached to both the CS and PS domains, it should give priority to the CS
Domain. In case the call attempt fails, the UE should automatically make a second attempt on
the PS domain.
2.
Emergency services are independent from the IP-CAN with respect to the detection and
routing of emergency sessions. The emergency services shall be possible over a HRPD
cellular access network and WLAN access.
3.
Any kind of emergency numbers, and emergency SIP and tel URIs and special indications for
emergency sessions within the SIP signaling shall be supported.
4.
Emergency sessions should be prioritized over non-emergency sessions by the system.
5.
The establishment of IMS emergency sessions shall be possible for users with a barred public
user identity by initiating the call anonymously without registering.
6.
The primary solution shall be that the UE can detect an emergency session (e.g., by evaluating
the SIP-URI or the dialed number) by itself and indicates the emergency session to the
network. The cases where the UE can’t detect an emergency session shall also be supported.
7.
The solution shall work in case the UE has sufficient credentials to authenticate with the IMS
and is registered to the IMS or is not registered with the IMS. The case where the UE does
not have sufficient credentials to authenticate with the IMS shall also be supported where
regulations allow.
In the case that UE is not already IMS registered, the UE shall perform a registration for the
support of emergency services (emergency registration).
In the case a UE is already IMS registered, the UE may skip the additional emergency
registration if the UE is aware that it is in its home network (e.g., including IP-CANs where
roaming outside the home network is not supported).
If the UE does not have sufficient credentials to authenticate with the IMS core it shall be
possible to perform an emergency session establishment without an existing security
association between UE and P-CSCF, and the UE shall include an equipment identifier (the
specific details of the equipment identifier to use may depend upon the IP-CAN) in the
request to establish an emergency session.
8.
It shall be possible to reject emergency service requests from a UE without sufficient
credentials to authenticate with the IMS, where regulations allow.
9.
Emergency Service is not a subscription service and therefore, when the UE has roamed out
of its home network, emergency services shall be supported in the roamed-to network. In the
case that a UE has sufficient credentials, the UE shall initiate a registration with the network
(requiring the involvement of the home network). The CSCFs providing service for
emergency sessions may be different from the CSCFs involved in the other IMS services.
10.
If an emergency session establishment request is routed to a P-CSCF 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
5 High Level Principles
8
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
initiate an emergency session in the visited network (e.g., via the CS domain of the visited
network).
2
3
4
11.
PSAPs are connected to the PSTN, the CS domain, the PS domain or any other packet
network.
12.
PSAPs shall be able to call back the user for an emergency session from a UE that has
registered (i.e., containing valid credentials).
13.
The IMS core network shall be able to transport information on the estimated location of the
subscriber.
14.
The scope of this document is voice only.
15.
The network shall be able to retrieve the caller’s estimated location.
16.
As a regional option, the network shall be capable of assigning a routable location key
(i.e., Emergency Services Query Key, a.k.a. ESQK, which has the same properties as the
existing ESRK in wireless 911 services) to an IMS emergency session, and releasing the
ESQK when the emergency session is terminated.
17.
The network shall provide the caller’s location information to the PSAP upon query from the
PSAP.
18.
The network shall provide the possibility to route to a default answering point given the
scenario where the local PSAP can not be determined.
19.
Void
20.
Void
21.
Subject to local regulation, it shall be possible to prevent the sending of the information of the
users, such as public user identifiers and the location information to the PSAP, when
explicitly requested by the user, i.e., request on session by session basis.
22.
The emergency Public User Identifier shall only be used for emergency services and not for
other services.
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
In addition to the architectural requirements, the following architectural principles apply to IMS
emergency sessions:

The IMS network shall be able to discriminate between emergency sessions and other
sessions. This shall allow special treatment (e.g., with respect to filtering, higher priority,
routing, QoS) of emergency sessions.

If a visited network can support IMS emergency service, the emergency session shall be
established in the visited network whether or not UE is registered in IMS in the home
network.

The P-CSCF is the IMS network entity, which is responsible to detect the request for
emergency session and forwards the request to E-CSCF in the same network.

The P-CSCF serving the emergency call is the IMS network entity which may retrieve the
location identifier from the IP-CAN.

The E-CSCF is the IMS network entity, which shall be able to retrieve geographical location
information from the LRF in the case that the geographical location information is not
available and is required.

If required, the E-CSCF shall be able to forward the location information to the LRF for
validation of geographical location information in the case that the geographical location
information is included by the UE over any access network type.
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
9
5 High Level Principles

5.2
The E-CSCF is the IMS network entity, which is responsible to route the request to a PSAP or
BGCF based on location information and additionally other information such as type of
emergency service in the request.
Naming and Addressing
The UE shall use a special emergency Public User Identifier in the emergency registration request.
The implicit registration set of the emergency Public User Identifier shall contain an associated tel
URI.
5.3
Location information for Emergency Sessions
Location information is needed for 2 main reasons in emergency services. The initial purpose of the
location information is to enable the IMS network to determine which PSAP serves the area where the
UE is currently located, so that the IMS network can route the emergency session to the correct PSAP.
The second purpose is for the PSAP to get more accurate or updated location information for the
terminal during or after the emergency session where required by local regulation.
5.3.1
General Location Information Principles
The following general principles shall apply regarding the handling of location information:
5.3.2
5.4

If the UE has location information available, the UE shall include the location information in
the request to establish an emergency session. The location information may consist of
network location information, that is the Location Identifier, and/or the Geographical location
information.

The E-CSCF may query the LRF to obtain location identifier. If the E-CSCF does not receive
location information in the emergency service request, it may query the LRF for location
information.

The E-CSCF shall be able to query the LRF to validate the location information if provided
initially by the UE.

The E-CSCF routes the emergency request to the PSAP that corresponds to the current
location of the UE or to a default PSAP. The access dependent variations of this approach are
described below, for the cases where the UE is using HRPD or WLAN for the emergency
service.

The E-CSCF forwards the SIP request containing the UE’s location information to the PSAP
via PS domain or via BGCF/MGCF through the CS domain. The location information can
contain explicit location information and/or a reference key to allow the PSAP to retrieve
location at a later stage.
Void
IP-CAN
The following are the expectations on the IP-CAN for IMS emergency services:

5 High Level Principles
It shall be possible to access the IP-CAN without sufficient security credentials.
1
0
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0

It shall be possible to reject requests from a UE without sufficient security credentials to
establish bearer resources.

In the case that the IP-CAN receives a request to establish bearer resources for emergency
services, the IP-CAN shall ensure that the IP flows using the requested resources are only for
communication with the network entities involved in the support of the emergency services.
Applicable service data flow filters for emergency traffic need to be defined by the operator
according to the details described in [26].

The IP-CAN may support emergency services free of charge. Applicable SBBC rules need to
be defined by the operator according to the details described in [26].
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
11
5 High Level Principles
6
6.1
Architectural Model and Reference Points
Reference architecture
This specification introduces an additional CSCF role to those defined in the IMS architecture [3],
called Emergency CSCF (E-CSCF), see Figure 1.
Le (e.g. E2)
from PSAP
LRF
Ml
Mm
Gm
UE
P-CSCF
Mw
E-CSCF
Mi/Mg
to PSAP
(via PSTN
via BGCF/
MGCF)
Mw
Mm/Mw
S-CSCF
Figure 1
to PSAP or ECS
via IP mutimedia
Network
from PSAP
E-CSCF in Reference Architecture
Notes:
a.
P-CSCF and E-CSCF are always located in the same network; this is the visited network
when the UE is roaming.
b.
For simplicity, not all functional components, e.g., I-CSCF, MGCF and BGCF, are shown in
this figure.
c.
It shall be possible, for example in the
where the Location Retrieval Function
Function (RDF) and a Location Server
Server and RDF is out of scope of this
Location Server (e.g., in the LRF).
d.
LRF may be associated with the IP-CAN.
6 Architectural Model and Reference Points
North America regions, to support configurations
(LRF) may consist of a Routing Determination
(e.g., SLP/MPC), the interface between Location
specification. The RDF may be integrated in the
1
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
3
4
6.2
X.S0049-0 v1.0
Reference points
The E-CSCF uses Mw, Mr, Mg, Mi, MI, and Mm reference points to connect to other IMS entities.
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
13
6 Architectural Model and Reference Points
7
7.1
Functional Descriptions
UE
a.
Should be able to detect an emergency session establishment request.
b.
Use a special emergency Public User Identifier in the IMS emergency registration request.
The format of the emergency Public User Identifier is described in Annex E.
c.
May perform an IMS emergency session establishment without prior emergency registration
when already IMS registered and in the home network (e.g., including IP-CANs where
roaming outside the home network is not supported).
Otherwise, the UE shall perform an IMS emergency registration.
d.
Include an emergency service indication in the emergency session request.
e.
Include an equipment identifier in the request to establish an emergency session for
“anonymous user”.
f.
Attempt the emergency call in CS domain, if capable.
g.
Handle a response with an indication, IMS emergency registration required, as a result of
emergency session establishment attempt.
h.
Handle a 380 (Alternative Service) response with the type set to “emergency” as a result of a
non UE detectable emergency attempt.
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.
7.2
7.2.1

Emergency session indication.

Emergency Public User Identifier if an IMS emergency registration is performed. If not, any
registered Public User Identifier is used.

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 Identifier, if available.
IMS Functional entities
Proxy-CSCF

Handle registration requests with an emergency Public User Identifier like any other
registration requests except that it may reject an emergency registration request if the IM CN
subsystem that the P-CSCF belongs to can not support emergency sessions for the UE (e.g.,
due to local policy or UE is not within IM CN subsystem’s geographical area or IP-CAN is
not supported).Detect an emergency session establishment request.

Reject/allow unmarked emergency requests.
7 Functional Descriptions
1
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0

Reject/allow anonymous emergency requests.

Prevent the assertion of an emergency Public User Identifier in non-emergency requests

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 Identifier.

May respond to a UE with an emergency session indication as a result of detecting a non UE
detectable emergency session establishment request

May respond to the UE with an indication, IMS emergency registration required, as a result of
processing the emergency session establishment attempt.

Should be able to identify the service data flow associated with emergency service and inform
PCRF accordingly.
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
7.2.2
24
25
26
Emergency-CSCF

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 as
described in section 8.6 Retrieving Location information for Emergency Session.

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 UE identification
to the LRF.
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
7.2.3
Location Retrieval Function
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
The Location Retrieval Function (LRF) is responsible for retrieving the location information of the UE
that has initiated an IMS emergency session. It shall be possible to support configurations where the
Location Retrieval Function (LRF) may consist of a Routing Determination Function (RDF) and a
Location Server (e.g., SLP/MPC). The interface between Location Server and RDF is out of scope of
this specification.
The LRF utilizes the RDF to provide the routing information to the E-CSCF for routing the emergency
request. The RDF can interact with a location functional entity (e.g., SLP/MPC) and manage ESQK
allocation and management. The ESQK is used by the PSAP to query the LRF for location
information and optionally a callback number. The LRF-PSAP interactions are outside the scope of
this specification.
Information provided by the LRF to the E-CSCF includes the routing information and other parameters
necessary for emergency services, which are subject to local regulation. For example, this information
may include the ESQK, ESRN, LRO in North America, location number in EU, PSAP SIP URI or tel
URI.
59
15
7 Functional Descriptions
In order to provide the correct PSAP destination address to the E-CSCF, the LRF may require interim
location information for the UE.
In some regions, for example in the North American region, it may be a requirement to provide the
PSAP with an accurate initial location estimate for the UE and possibly to provide an accurate updated
location estimate for the UE if requested by the PSAP. When this requirement exists, the LRF may
store a record of the emergency session including all information provided by the E-CSCF and shall
only release this record when informed by the E-CSCF that the emergency session has terminated.
The information provided by the LRF to the E-CSCF (e.g., ESQK) shall then include correlation
information identifying both the LRF and the emergency session record in the LRF. This correlation
information shall be transferred to the PSAP during session establishment (e.g., in a SIP INVITE or via
SS7 ISUP signaling from the MGCF). The PSAP may use this information to request an initial
location estimate from the LRF and/or to request an updated location estimate.
7.2.4
Serving CSCF
When the S-CSCF receives an Emergency Registration, the S-CSCF determine the duration of the
registration by checking the value of the Expires header in the received REGISTER request and based
on local policy of the serving system.
NOTE: The value of the emergency registration time is subject to national regulation and can be
subject to roaming agreements.
7 Functional Descriptions
1
6
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
8
3
4
X.S0049-0 v1.0
Procedures Related to Establishment of IMS
Emergency Session
5
6
7
8.1
High Level Procedures for IMS Emergency Services
8
9
10
8.1.1
UE Detectable Emergency Session
11
12
13
The following flow contains a high level description of the emergency service procedures performed
when the UE can detect the emergency session is being requested.
14
Emergency
Center or PSAP
15
16
UE
IP -CAN
IMS
17
18
19
1. Detect Emergency
Emegency
sesssion request
20
21
22
2. Terminate
UE capability
anyand
ongoing
resource
communication
validation
23
24
3. Bearer Registration
25
26
27
4. Bearer Resource Request
28
29
5. P-CSCF Discovery
30
31
32
6. IMS Registration
Emergency Registration
33
34
7. Establish Emergency Session (and Bearer Resources)
35
36
37
38
Figure 2
Terminal Detected Emergency Calls
39
40
The following steps are performed:
41
42
1.
The UE detects the request for the establishment of an emergency session. Steps 2 to 6 may
be skipped based on the conditions specified in sub-clause 7.1.
2.
In the case that the UE has insufficient resources or capabilities to establish an emergency call
due to other ongoing sessions then the UE should terminate the ongoing communication and
release reserved bearer resources
3.
In the case that bearer registration is required and has not been performed, the UE shall
perform bearer registration to the IP-CAN. If the UE is already bearer registered, then the
bearer registration procedures are not required to be performed.
43
44
45
46
47
48
49
50
51
52
NOTE 1: Depending on the IP-CAN, the UE may be assigned an IP address at this stage.
53
54
55
56
57
4.
In the case that bearer resources for the transport of the IMS related signaling are required to
be reserved in the IP-CAN, the UE shall reserve the resources in the IP-CAN. The UE shall
provide an indication that this is for an emergency service.
58
59
17
8 Procedures Related to Establishment of IMS
Emergency Session
If the IP-CAN does not provide an IP address to the UE in step 3, then the IP-CAN shall
allocate an IP address to the UE during the bearer resource request procedures.
5.
UE performs a P-CSCF discovery procedure, where the UE discovers a P-CSCF in the local
network suitable for use in emergency sessions.
NOTE 2: The exact means for the P-CSCF discovery is dependant upon the IP-CAN.
6.
If the UE has sufficient credentials to authenticate with the IMS network, it shall initiate an
emergency services IMS registration by providing the IP address obtained at step 3 or step 4
to the P-CSCF selected at step 5. The IP address used for signaling purposes is allocated in
association with step 3 or step 4. The emergency services IMS registration request shall
include an Emergency Public User Identity. The implicit registration set of the emergency
Public User Identifier shall contain an associated tel URI that is used to call back the user
from the PSTN.
The S-CSCF may set the proposed registration expiration according to the local policy of the
serving system and regulation. The subsequent registration flows are like any other
registration.
If the UE does not have sufficient credentials to authenticate with the IMS network, it shall
not initiate an emergency services IMS registration request, but instead immediately establish
an emergency session towards the P-CSCF as described in step 7.
7.
If IMS emergency registration is performed, the UE shall initiate the IMS emergency session
establishment using the IMS session establishment procedures containing an emergency
session indication and emergency Public User Identifiers. Otherwise, the UE shall initiate the
IMS emergency session establishment using the IMS session establishment procedures
containing an emergency session indication and any registered Public User Identifier.
Whether the procedures are activated individually by the UE or some of them are performed
automatically depends on the implementation of the terminal and on the UE’s configuration. For
instance, the multimedia application in the UE could start the application level registration and steps 24 would have to be executed in response to support the operation initiated by the application.
Interaction with the UE may happen during these steps.
8.1.2
Non UE detectable Emergency Session
As the UE could not detect the emergency session, the session establishment request will be sent to a
P-CSCF in the visited network or a P-CSCF in the home network as per a normal session
establishment procedure. The former is only applicable to a roaming situation whereas the latter can
apply to both a roaming and non-roaming situation. Prior to sending the session establishment request
the UE must be registered in the IMS as per the normal registration procedure.
In the case that the P-CSCF detects that this is a request to establish an emergency session, based upon
local policy (e.g., checking access type):

The P-CSCF may reject the session initiation request with an indication that this is for an
emergency session. When the UE receives the session rejection then the UE shall either
attempt to initiate an emergency call in the CS domain or follow the procedure in 8.1.1.

Alternatively, the P-CSCF in the visited network or the P-CSCF in the home network for a
non-roaming UE may allow the session initiation request to continue by inserting the explicit
emergency indication in the session request and forward that request to an Emergency CSCF
in the same network. There is no requirement to inform the UE that the session has been
8 Procedures Related to Establishment of IMS
Emergency Session
1
8
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
marked as an emergency session, i.e., the UE can treat the session as a normal session
establishment.
2
3
4
5
8.1.3
Emergency Session Establishment using LRF/RDF
6
Figure 3 illustrates a high level call flow for the IMS emergency session establishment procedure using
LRF/RDF to retrieve location and routing information.
7
8
9
10
IMS
Network
UE
11
12
LRF
(RDF)
MGCF/
MGW
PSAP
13
1. UE initiates the emergency
session
14
15
16
2. if required, retrieve UE
location
17
18
19
20
3. if required, retrieve PSAP
routing information
21
22
23
24
4. E-CSCF routes the emergency session based on routing
destination from LRF
25
26
27
Figure 3
28
Emergency Session Establishment Procedure Using LRF/RDF
29
30
1.
UE initiates an emergency session request by sending a SIP INVITE message and including
emergency URI.
2.
If required, the IMS network may access the LRF to retrieve the UE’s location.
3.
If PSAP routing information is required, the LRF invokes the RDF to determine the proper
PSAP destination. The LRF returns the necessary location/routing information (i.e., ESQK)
to the IMS network.
4.
The IMS network uses the routing information returned by the LRF to route the emergency
session request towards the appropriate PSAP.
31
32
33
34
35
36
37
38
39
40
41
NOTE: If the LRF provides an ESQK to the IMS network in step 3 or assigns any other dedicated
resource to the emergency session, the IMS network shall inform the LRF when the session is
released in order to allow the LRF to release this resource.
42
43
44
45
46
8.2
IMS Registration for Emergency Session
47
48
49
The IMS emergency registration procedure shall follow the procedures as described in [2] and [4] with
the following modifications:
50
51
52
53
54

The UE shall initiate an IMS emergency registration when all of the following conditions are
met
–
either the UE is not already IMS registered or the UE is IMS registered but is roaming
outside its home network,
–
UE has sufficient credentials to authenticate with the IMS network
–
UE is able to detect emergency session
55
56
57
58
59
19
8 Procedures Related to Establishment of IMS
Emergency Session

The UE shall also initiate an IMS emergency registration when it receives an “IMS
emergency registration required” response as a result of the emergency session request.

If the UE initiates an IMS emergency registration, it shall first initiate an emergency access to
the IP-CAN if emergency access has been defined for the particular type of IP-CAN. This is
to ensure that the session attempt is handled in the visited network when the UE is roaming
and provides appropriate priority treatment and access to appropriate network elements (e.g.,
to a particular P-CSCF in the visited network).

If the UE had already performed an emergency access when it receives an “IMS emergency
registration required” response as a result of an emergency registration or emergency session
request, it shall perform an emergency access followed by an emergency registration using a
different visited network if available to prevent looping.

The UE shall use an emergency Public User Identifier in the emergency registration request.
This indication may be used to route calls coming from the PSAP to the contact address
registered during the emergency registration procedure and to inform the home network that
roaming restrictions may not be applied. The format of this public user identity is defined in
Annex E.
NOTE: The special emergency public user identifier is different from emergency indication
in the IMS emergency session establishment request.
P-CSCF handles the registration requests with an emergency Public User Identifier like any other
registration request.
The S-CSCF in the home network may modify the received registration expiration value from the
request according to local policy in the serving system and regulation. The subsequent registration
flows are like any other registration.
8.3
Emergency Session Establishment in the Serving IMS network
If the UE is able to detect that the user is requesting an emergency session then it shall include an
emergency service indication in the emergency session establishment request.
If the UE is CS capable and not attached to the PS domain, the UE shall attempt an emergency call in
the CS domain. If the UE is only PS attached, and the network has indicated that IMS emergency
services are supported, it should attempt the emergency call in the PS Domain. If the UE is attached to
both domains, it should give priority to the CS Domain. In case the call attempt fails, the UE should
automatically make a second attempt on the other domain. For an attempt in the IM CN Subsystem of
the PS domain, the attempt should be in the serving (visited if roaming) IM CN Subsystem of the PS
domain.
If the initial attempt is in the CS domain and it fails, the serving (visited if roaming) IM CN Subsystem
of the PS domain shall be attempted if the UE is capable. If the initial attempt is in the IM CN
Subsystem of the PS domain and it fails, the UE shall make the attempt in the CS domain.
If a UE attempts to initiate a session and receives a 380 (Alternative Service) response with the type set
to “emergency”, the UE shall then re-attempt the session as described above with first attempt being
towards the CS domain (if the UE is capable and if for an appropriate service e.g., voice), and with an
indication that emergency service is requested.
If the UE is aware that it does not have sufficient credentials to authenticate with the IMS network, it
shall not initiate an emergency services IMS registration but immediately establish an emergency
session towards the P-CSCF, see section 8.4.
8 Procedures Related to Establishment of IMS
Emergency Session
2
0
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
X.S0049-0 v1.0
Upon receiving an initial request for an emergency session, the P-CSCF shall follow the rules and
procedures described in [2-11] with the following additions and clarifications:
3
4

The P-CSCF is the IMS network entity, which detects an emergency session.
5
For the case that the initial request carries an indication that the request is for emergency
services, and the UE is not IMS registered in the IMS network, see section 8.4 for details.
6
7
8
9

For the case that UE is IMS registered and the initial request does not carry an indication that
the request is for emergency services, and the P-CSCF is able to detect that the request is for
emergency services, the P-CSCF shall perform the “Non UE detectable Emergency Session”
described in section 8.1.2 above.

For the case that the initial request carries an indication that the request is for emergency
services, and the UE is registered in the IMS network, but not performed emergency
registration:
10
11
12
13
14
15
16
17
18
–
the P-CSCF shall reject the request indicating that IMS emergency registration required,
if the UE is roaming;
–
the home P-CSCF may reject the request indicating that IMS emergency registration
required, based on local policy.
19
20
21
22
23

On receipt of a session establishment request, which is recognized to be for an emergency
service, the P-CSCF shall check whether the UE provided a tel URI as its identity in the
request. If a tel URI is present in the request, the P-CSCF shall check the validity of this tel
URI. If no tel URI is present in the request and the P-CSCF is aware about the tel URI
associated with the emergency Public User Identifier, it shall provide the tel URI to the ECSCF in the session establishment request.

The P-CSCF may query the IP-CAN for the location identifier.

P-CSCF shall prioritize emergency sessions over other non-emergency sessions.
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Upon receiving an initial request for an emergency session from P-CSCF, the E-CSCF shall perform
the following:

if location information is not included in the emergency service request or if additional
location information is required, the E-CSCF, if required, retrieves the UE’s location
information as described in section 8.6 Retrieving Location information for Emergency
Session.

If location information is included by the UE, the E-CSCF, if required requests the LRF to
validate the location information.

May determine or may request the LRF to determine the appropriate routing information
which could be based on the type of emergency service requested and UE’s location.

Determine the default PSAP destination if routing based on UE’s location is required but the
location is unknown.

If the PSAP contains a point of presence within the IMS connectivity network, the E-CSCF
shall forward the emergency session initiation request directly to the PSAP.

If the PSAP has its point of presence in the PSTN/ISDN network or the CS domain, the ECSCF uses the Tel-URI obtained from the LRF and forwards the request to an appropriate
BGCF/MGCF for routing in the PSTN/ISDN network. This number shall have the same
format as used for CS emergency calls. The MGCF may insert any available location
information in the PSTN/CS signaling.
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
21
8 Procedures Related to Establishment of IMS
Emergency Session
NOTE: In case an ESRN is received from the LRF, the E-CSCF maps the received ESRN
from the LRF to a TEL-URI before forwarding the request to MGCF.
8.4
IMS Emergency Session Establishment without Registration
When the UE initiates an emergency session establishment without prior IMS registration, it shall
include both the “anonymous user” and “emergency service” indications in the emergency session
establishment request to the P-CSCF.
Based on local policy, the P-CSCF may reject “anonymous user” emergency session establishment
with appropriate error code. UE shall not reattempt the “anonymous user” emergency session again
via the same network.
When P-CSCF accepts the “anonymous user” emergency session establishment, it forwards this
request to an appropriate E-CSCF although no security association between UE and P-CSCF is
established.
The E-CSCF shall follow the same rules and procedure as defined for the Emergency Session
Establishment in the Serving IMS network in section 8.3 to route the anonymous emergency session.
8.5
8.5.1
Interworking with PSAP
PSAP connected via the PSTN/ISDN Network
No special procedure is defined. PSAP uses the MDN (E.164) of the user for call back.
8.5.2
PSAP 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.
8.6
Retrieving Location information for Emergency Session
When performing an emergency service, three 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.
8 Procedures Related to Establishment of IMS
Emergency Session
2
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
IP-CAN
UE
IMS
Core
LRF
MGCF/
MGW
Emerg.
Centre
3
4
5
1. Init. Emerg.Call
6
7
2. Acquire location
8
3. INVITE (emergency)
9
10
11
4. Retrieve Location-routing information
12
13
14
5. Procedure to obtain the UE’s location
15
6. Return Location-routing information
16
7a. INVITE (emergency)
17
18
7b. IAM
19
20
7c. INVITE (emergency)
21
22
23
8. Complete Emergency Call Establishment
24
25
26
9. Retrieve location
27
28
29
10. Procedure to obtain the initial or
updated location
30
11. Return location
31
32
33
12. Release Emergency Call
34
35
13. Release call record
36
37
38
Figure 4
39
Handling of Location Information in IMS Emergency Calls.
40
41
42
43
1.
The user initiates an emergency call.
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 IPCAN, if that is supported for the used IP-CAN. If applicable, the IP-CAN delivers to the UE the
UE’s geographical information and/or the location identifier.
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 and possibly location information source,
e.g., positioning method that was used to obtain the location information. The location
information may be geographical location information or a location identifier, which is dependant
upon the access network technology. In case 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.
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
NOTE: the location solutions and position methods conveyed in the INVITE and the means of
inclusion in the INVITE are outside the scope of this specification.
59
23
8 Procedures Related to Establishment of IMS
Emergency Session
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 IP address). The request shall also include any
location information provided in step 3. The request may optionally include any information
concerning the location solutions and position methods supported by the UE.
5.
The LRF may already have the information requested by IMS core or LRF may request the UE’s
interim location information. The means to obtain the location information may differ depending
on the access technology the UE is using to access the IMS and may include using the procedures
defined in the SUPL procedures defined in OMA AD SUPL: “Secure User Plane Location
Architecture” [20], OMA TS ULP: “User Plane Location Protocol” [21], or other procedures. The
SUPL procedures 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.
The LRF may invoke an RDF to convert the location information received in step 4 or obtained in
step 5 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.
6.
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 5,
and possibly location information source, e.g., positioning method that was used to obtain the
location information.
7.
The IMS core uses the routing information provided in step 6 or selects a PSAP based on location
information provided in step 3 or 6 and sends the request including the location information, any
correlation information and possibly location information source, e.g., positioning method that
was used to obtain the location information to the PSAP.
7a. The INVITE is sent to an MGCF/MGW,
7b. The IAM is continued towards the PSAP, or
7c. The INVITE is sent directly to the PSAP.
8.
The emergency call establishment is completed.
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 the location and/or correlation information received in
step 7. The PSAP may also include the correlation information in the request to the LRF.
10.
The LRF determines the target UE’s location using any supported means.
11.
The LRF returns the initial or updated information to the PSAP. As an option for initial location,
the LRF may instigate the location step 10 before the request in step 9 is received and may send
the initial location to the PSAP either after the request in step 9 is received or before it is received.
12.
The emergency call is released.
8 Procedures Related to Establishment of IMS
Emergency Session
2
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
13.
X.S0049-0 v1.0
The IMS core may indicate to the LRF that the call is released. The LRF deletes any record stored
in step 5.
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
25
8 Procedures Related to Establishment of IMS
Emergency Session
A
A.1
Annex A (Normative): IMS Emergency Services
Using HRPD/PDS Network
Requirements on the HRPD Network as an IP-CAN
For an emergency call over HRPD, the requirements on the IP-CAN are covered by the following
HRPD specific requirements:
A.2

HRPD networks shall authenticate the UE in accordance with normal authentication
procedures, i.e., A12 and PDSN authentication. For support of unauthorized emergency
callers, A12 support is optional, PDSN authentication is required.

HRPD networks may allow limited access to UEs that wouldn’t normally be authenticated,
but which provide authentication credentials specific to emergency service. In this case, the
HRPD network allows access to UEs using NAIs of the form emergency@emergency.com
and emergency@a12.emergency.com for PDSN and A12 authentication respectively.

HRPD networks shall provide data access of the type requested by the UE, i.e., Simple IPv4,
Simple IPv6, Mobile IPv4, and Mobile IPv6.

The HRPD network shall not provide L2TP service to the UE. This is general requirement
and not only applicable to emergency services.

HRPD networks shall provide the address of the local P-CSCF via DHCP or DHCPv6
depending on the type of IP address acquired by the UE. This could be an IP (v4 or v6)
address or a SIP URI.

HRPD networks shall provide Carrier-ID information to the UE via DHCP or DHCPv6 so
that the UE may determine if it is roaming or not. Carrier-ID is defined in Annex C.
UE Specific Behavior for Emergency Calls over HRPD
For the specific case of an emergency call over HRPD the UE shall adhere to the following
procedures:
A.2.1
Without Existing Data Session

If the UE wants to make an emergency call but doesn’t currently have an existing data session
with the HRPD network, it shall create a Simple IPv4 or Simple IPv6 session per its normal
procedures.

If the UE fails in its attempt to access the HRPD network, it may attempt to access again
using the emergency NAI.
In this case, the UE shall use NAIs of the form
emergency@emergency.com and emergency@a12.emergency.com for PDSN and A12
authentication respectively.

If the UE accesses the network with the emergency NAI it shall obtain either a Simple IPv4
or Simple IPv6 address.

The UE shall obtain the address of the local P-CSCF via DHCP or DHCPv6, depending on
the type of IP address is has acquired. Note: this is done when IP addresses are obtained, not
when an emergency call is detected.
8 Procedures Related to Establishment of IMS
Emergency Session
2
6
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support

1
2
X.S0049-0 v1.0
The UE shall include the HRPD Sector ID of the serving AN in the P-Access-Network-Info
header of the SIP INVITE request.
3
4
5
A.2.2
With Existing Data Session
6

7
8
The UE shall obtain the address of the local P-CSCF via DHCP or DHCPv6, depending on
the type of IP address is has acquired.
9
Note: this is done when IP addresses are obtained, not when an emergency call is detected.
10
11

12
13
14
The UE shall obtain the HRPD’s Carrier-ID from a DHCP or DHCPv6 server in the serving
HRPD network. Carrier-ID is defined in Annex C.
–
If the UE uses Simple IPv4, it shall use the assigned Simple IPv4 address to send the
DHCPINFORM message. The destination address shall be the limited broadcast address
(all 1s).
–
If the UE uses Mobile IPv4, it shall use the Direct Delivery style [RFC 3024] to send
DHCPINFORM message. The destination address shall be the limited broadcast address
(all 1s).
–
If the UE uses Simple IPv6, it shall use the assigned Simple IPv6 address to send the
DHCPv6 Information-Request.
The destination address shall be the
All_DHCP_Relay_Agents_and_Servers multicast address (FF02::1:2).
–
If the UE uses Mobile IPv6, it shall use the assigned care-of-address (i.e., a Simple IPv6
address) to send the DHCPv6 Information-Request. The destination address shall be the
All_DHCP_Relay_Agents_and_Servers multicast address (FF02::1:2).
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

30
31
The UE shall determine whether it’s roaming based on the received Carrier-ID.
–
32

33
34
If the UE is roaming, it shall use the Simple IPv4 address or Simple IPv6 address.
The UE shall include the HRPD Sector ID of the serving AN in the P-Access-Network-Info
header of the SIP INVITE request.
35
36
37
38
A.3
Information Flows
39
40
41
42
43
44
45
46
A.3.1
Emergency Call: HRPD Session Establishment for Unauthenticated Caller
In this scenario, a UE without sufficient credentials to establish a HRPD session, requests a HRPD
session to be established for an emergency call in a network that supports emergency calls from
unauthorized callers. The access, IP and Services layer must each ensure the session is used only for
emergency calls. The PDSN, PCRF and P-CSCF are in the same network.
47
48
49
50
51
52
53
54
55
56
57
58
59
27
Annex A
Host Network
HRPD
RAN
UE
PDSN
PCRF
AAA
P/ECSCF
1. DO: Session Negotiation and Connection Request (emergency)
2. A12: CHAP auth( emergency NAI)
3. A11: A10 connection
4. CHAP auth( emergency NAI)
5. Get IP Addr
6. VoIP Bearer Path Established
7. Get P-CSCF Identity
8. Session Established
9. Data(INVITE( SDP ))
10. SIP: INVITE( SDP )
11. SIP: 180 Ringing(SDP)
12. Data(180 Ringing(SDP))
13: Authorize Session (CN IPaddr)
14. SIP: Complete SIP session establishment
15. Vocoded Speech
16. SIP session ends
17. Unauthorize CN - IPaddr
Figure 5
Unauthenticated UE Initiates an Emergency Call
Preconditions:

UE attempted to access the system with its stored credentials and was rejected or knows a
priori authentication will fail (e.g., system is not in UE’s PRL).

HRPD system is configured for PDSN authentication, A12 is optional.

Service Based Bearer Control (SBBC) is required in order to enforce policy for unauthorized
UEs allowed HRPD access for emergency calls.
8 Procedures Related to Establishment of IMS
Emergency Session
2
8
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
1.
2
X.S0049-0 v1.0
UE initiates HRPD session configuration by either by requesting a prior session or performing a
normal session negotiation:
3
a.
4
Prior Session Approach
5
a1. UE requesting a UATI and retrieval of a PriorSession that contains attributes and protocol
appropriate for VoIP.
6
7
8
a2. AN retrieving the PriorSession requested by the UE and assigning a UATI to the UE.
9
10
a3. The UE requests a connection from the RAN, indicating data is to be sent and includes the
Emergency Indicator, set to 1, if supported by the UE, and AN assigning a traffic channel to
the UE.
11
12
13
14
b.
Negotiated Session Approach
15
b1. UE requesting and receiving a UATI (i.e., RAN session identifier) from the RAN.
16
17
b2. RAN requesting and receiving a hardware id (HWID) (i.e., MEID) from the UE.
18
19
b3. UE requesting a connection from the RAN and receiving the assigned channel.
20
21
b4. UE and RAN negotiate HRPD session parameters (may include prior session request).
22
b5. Closing the connection between the UE and RAN.
23
24
b6. The UE requests a connection from the RAN, indicating data is to be sent and includes the
Emergency Indicator, set to 1, if supported by the UE and AN assigning a traffic channel to
the UE.
25
26
27
28
NOTE: Because HRPD RAN session negotiation begins at Rev.0, there is no way for the UE
to indicate emergency or priority at initial setup.
29
30
31
32
2.
Once the connection is established, and if the RAN is configured to do A12 (device/access level)
authentication, the RAN will initiate CHAP. The AN-AAA detects the emergency NAI in the
UE’s CHAP response and authorizes access, if local regulation or carrier policy requires
unauthorized emergency callers to be supported. No IMSI is returned by the AN-AAA for the
emergency NAI.
3.
The RAN creates an IMSI and establishes an A10/A11 connection to the PDSN.
4.
As part of PDSN (subscriber level) authentication, the PDSN initiates CHAP. The UE includes
the emergency NAI as part of its CHAP response. The AAA detects the emergency NAI and
authorizes the user, if local regulation or carrier policy requires unauthorized emergency callers to
be supported. ASSUMPTION: It is assumed that existing AAA or static mechanisms are used to
inform the PDSN of the limited authorization for the session (e.g., IP flow restrictions in RADIUS
Access Request/Response).
5.
The UE obtains a Simple IP address.
6.
The bearer path is established for the VoIP call, including QoS negotiation.
7.
UE obtains the identity of the P-CSCF.
8.
Optionally, the PDSN establishes a session to the local PCRF.
9.
The UE starts sending data. The PDSN will only allow data destined to the P-CSCF. Packets
addressed to other destinations will be dropped. Note: This is existing policy handling
functionality.
10.
The P/E-CSCF, along with other IMS entities, processes the INVITE from the UE containing the
emergency PUID, and forwards it towards the emergency network. The P/E-CSCF will reject any
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
29
Annex A
other requests. Note: A UE without sufficient credentials is allowed to initiate an emergency call
anonymously, without needing to register/authenticate at the IMS/Service layer.
A.3.2
11.
As part of call setup, the P-CSCF receives the SDP in the 180 Ringing from the far end, which
includes the IP address and media characteristics for the correspondent node (e.g., IP PSAP or
MGW connection to legacy PSAP trunk) and forwards it towards the UE via the PDSN.
12.
The PDSN forwards the data to the UE, since it came from the allowed IP address (P-CSCF).
13.
Optionally, in parallel with step 12, once the far end IP address is known, the P-CSCF notifies the
local PCRF via Tx, that data (i.e., bearer) is also authorized to the IP address of the Correspondent
Node (CN). The PCRF forwards the information to the PDSN via Ty. Priority may also be
indicated for some/all of the packet traffic to/from the UE. This priority information will also be
sent by the PDSN to the RAN as QoS information so that the RAN can properly handle the
emergency call.
14.
The SIP session is established (i.e., 200 OK received from far end)
15.
The UE and PSAP are talking
16.
The session ends (i.e., UE or correspondent node send BYE)
17.
Optionally, once the session is over, the P-CSCF, via Tx, requests the local PCRF to remove the
CN (i.e., IP address) from the allowed IP addresses. The request is then forwarded to the PDSN
via Ty.
Emergency Call: Authenticated UE while Roaming
A roaming and authorized UE with a Mobile IP HRPD session established, initiates an emergency call.
The UE must obtain a local IP address and local P-CSCF so that the call can be serviced by the
roaming carrier. The main functionality to support this is:
a.
After PPP establishment, the UE performs a local DHCP query to obtain the local Carrier and
local P-CSCF.
b.
When the UE detects an emergency call, if the local Carrier is not its home Carrier, the UE
obtains a local IP address if necessary.
c.
The UE must SIP register with its home service provider using an emergency public user id.
d.
IMS ensures this registration is only used for emergency calls.
8 Procedures Related to Establishment of IMS
Emergency Session
3
0
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
Visited Network
Home Network
3
4
5
6
7
UE
HRPD
RAN
PDSN
PCRF
P/ECSCF
PDSN
PCRF
IMS
8
9
AAA
10
11
1. Existing HRPD MIP Session, local Carrier and local P-CSCF known to UE
12
13
14
15
2. Rrequest local IPaddr
16
17
3. Return local IPadd
18
19
4. SIP: REGISTER( ePUID)
5. SIP: REGISTER( ePUID)
20
21
6. SIP: 200 OK
7. SIP: 200 OK
22
23
8. SIP: INVITE( SDP )
24
9. SIP: INVITE( SDP )
25
26
10. SIP: 180 Ringing(SDP)
11. SIP: 180 Ringing(SDP)
27
28
29
12. SIP: Complete SIP session establishment
30
31
32
13. Vocoded Speech
33
34
14. SIP session ends
35
36
37
38
39
40
Figure 6
Authorized UE Initiates an Emergency Call while Roaming
41
42
43
1.
A Mobile IP Session exists between the UE, PDSN in the visited network and the PDSN in the
home network. The UE has been authenticated at the access/device layer, IP layer and
IMS/Services layer. After PPP establishment, the UE obtained the local Carrier and local P-CSCF
identity via DHCP.
2.
The UE detects the user has initiated an emergency call. If the UE determines it is roaming (e.g.,
based on local Carrier id from step 1, the UE obtains a local IP address if necessary (e.g., it is not
necessary with IPv6 since the UE has a local IP address in the CoA).
3.
If a local IP address was requested in step 2, the local IP address is returned to the UE.
4.
The UE sends an emergency registration to the local P-CSCF, using an emergency Public User Id.
5.
IMS registers the UE with the ePUID.
6.
IMS registration completes.
7.
The UE receives the registration response.
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
31
Annex A
8.
The UE sends the INVITE to the local P-CSCF, including the ePUID and emergency URN.
9.
The P/E-CSCF, along with other IMS entities, processes the INVITE from the UE and forwards it
towards the emergency network. The P-CSCF may reject any other non-emergency requests.
10.
As part of call setup, the P-CSCF receives the SDP in the 180 Ringing from the far end, which
includes the IP address and media characteristics for the far end (e.g., IP PSAP or MGW
connection to legacy PSAP trunk)
11.
The 180 Ringing is forwarded to the UE.
12.
The SIP session is established (i.e., 200 OK received from far end)
13.
The UE and PSAP are connected.
14.
The session ends (i.e., UE or far end send BYE)
8 Procedures Related to Establishment of IMS
Emergency Session
3
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
3
4
B
X.S0049-0 v1.0
Annex B (Normative):
Identity
Emergency Public User
5
6
7
8
The emergency public user identity shall be derived from a public user identity as follows:
1.
UE selects any public user identity that is a SIP URI from ISIM. If the UE does not have
ISIM, UE derives a temporary public user identity from IMSI, IRM, or MIN as described in
Annex C of X.S0013-004 [5].
2.
UE adds “sos.” to the beginning of the domain part of the selected public user identity.
9
10
11
12
13
14
For example if the SIP URI for the selected public user identity is “sip:user@domain”, the
corresponding emergency public user identity is “sip:user@sos.domain”.
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
33
Annex B
C
Annex C (Normative): Carrier-ID
Operators can be uniquely identified by the Carrier-ID value. The UE shall acquire the Carrier-ID
value from the HRPD network via DHCP or DHCPv6 so that the UE may determine if it is roaming or
not. The Carrier-ID value is based on the Mobile Country Code (MCC) and Mobile Network Code
(MNC) values assigned to the operator. This value is also a RADIUS VSA specified in [1]. CarrierID is a 5 or 6 byte string comprising the 3 byte MCC and 2 or 3 byte MNC of the operator.
C.1
DHCPv6 Options
Upon receiving the DHCPv6 Information-Request that contains the Vendor Class option indicating
3GPP2-specific, the DHCPv6 server shall send the DHCPv6 Reply that contains the Vendor-Specific
Information option for MCC/MNC.
Table 1
DHCPv6 Vendor Class option
0
8
16
Option-Vendor-Class (16)
24
Length
Enterprise Number
Option-Vendor-Class: 16
Length: 8
Enterprise Number: 5535
Table 2
DHCPv6 Vendor-Specific Information option
0
8
16
Option-Vendor –Opts (17)
24
Length 1
Enterprise Number
Option Code (4)
Length 2
MCC/MNC
MCC/MNC
Option-Vendor –Opts: 17
Length 1: 18 octets
Enterprise Number: 5535
Option Code: 4 (for MCC/MNC)
Length 2: 10 octets
MCC/MNC: The first 3 octets are MCC, and the last 3 octets are MNC. An unassigned/invalid
MCC/MNC is set to all zeros.
8 Procedures Related to Establishment of IMS
Emergency Session
3
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
C.2
DHCP Options
3
Upon receiving the DHCPINFORM that contains the Vendor Class Identifier option indicating
3GPP2-specific, the DHCP server shall send the DHCPACK that contains the Vendor-Specific
Information option for MCC/MNC.
4
5
6
7
Table 3
8
9
X.S0049-0 v1.0
DHCP Vendor Class Identifier option
0
8
16
Code (60)
Length
Enterprise Number
24
10
11
12
13
Enterprise Number
Code: 60
14
15
Length: 6
16
17
Enterprise Number: 5535
18
19
20
21
Table 4
DHCP Vendor-Specific Information option
22
23
0
8
16
Code (43)
Length 1
Enterprise Number
24
24
25
26
Option Code (4)
27
28
Length 2
MCC/MNC
29
30
31
32
33
MCC/MNC
Code: 43
Length 1: 16 octets
34
35
Enterprise Number: 5535
36
37
38
39
40
41
42
Option Code: 4 (for MCC/MNC)
Length 2: 10 octets
MCC/MNC: The first 3 octets are MCC, and the last 3 octets are MNC. An unassigned/invalid
MCC/MNC is set to all zeros.
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
35
Annex C
D
Annex D (Normative): Enhancements to MMD
Stage 3 for Emergency Services Support
This annex contains the relevant procedures and protocols necessary to support emergency services in
IMS.
NOTE: The formatting of this annex allows for future incorporation into [5]. All sections and section
references in this Annex are relative to [5] and not the current document unless explicitly stated.
2
References
[69]
RFC 5031 (January 2008): A Uniform Resource Name (URN) for Services
[89]
draft-ietf-sip-location-conveyance-09 (May 2008): Session Initiation Protocol Location
Conveyance
Editor's note: The above document is a work in progress and should not be referenced unless
and until it is approved and published. Until such time as this Editor’s note is removed, the
inclusion of the above document is for informational purposes only.
[90]
RFC 4119 (December 2005) A Presence-based GEOPRIV Location Object Format
[91]
draft-ietf-ecrit-requirements-09 (May 2006): Requirements for Emergency Context Resolution
with Internet Technologies
[103] RFC 4967 (July 2007): Dial String Parameter for the Session Initiation Protocol Uniform
Resource Identifier
3
3.1
[J-STD-036]
J-STD-036-B: Enhanced Wireless 9-1-1, Phase 2; June 2005
[X.S0049]
X.S0049: All-IP Network Emergency Call Support
Definitions and abbreviations
Definitions
For the purposes of the present document, the following terms and definitions apply.
Emergency registration: A special registration that relates to an emergency public user identity.
Initial emergency registration: An emergency registration that is also an initial registration.
Emergency reregistration: An emergency registration that is also a reregistration.
For the purposes of the present document, the following terms and definitions given in 3GPP2
X.S0049 [This Document] apply:
Emergency-CSCF (E-CSCF)
8 Procedures Related to Establishment of IMS
Emergency Session
3
6
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
Geographical location information
2
Location identifier
3
4
Location information
5
6
For the purposes of the present document, the following terms and definitions given in draft-ietf-ecritrequirements [91] apply:
7
8
9
Emergency service identifier
10
Emergency service URN
11
12
Public Safety Answering Point (PSAP)
13
14
PSAP URI
15
16
17
18
19
20
4
General
21
22
23
24
25
4.1
Conformance of IM CN subsystem entities to SIP,
SDP and other protocols
26
27
START OF CHANGE
28
29
30
31
32
NOTE 1: Subclause 5.7 and its subclauses define only the requirements on the AS that relate to
SIP. Other requirements are defined in [5].

The MRFC shall provide the UA role, with the exceptions and additional capabilities as
described in subclause 5.8, and with the exceptions and additional capabilities to SDP as
described in subclause 6.5.

The E-CSCF shall provide the proxy role, with the exceptions and additional capabilities as
described in subclause 5.11.
33
34
35
36
37
38
39
40
41
In addition to the roles specified above, the P-CSCF, the I-CSCF, the S-CSCF, the BGCF can act as a
UA when providing server functionality to return a final response for any of the reasons specified in
[26].
42
43
44
45
46
47
48
49
50
51
52
53
54
NOTE 2: Annex A can change the status of requirements in referenced specifications. Particular
attention is drawn to table A.4 and table A.162 for capabilities within referenced SIP
specifications, and to table A.317 and table A.328 for capabilities within referenced SDP
specifications. The remaining tables build on these initial tables.
NOTE 3: The allocated roles defined in this clause are the starting point of the requirements from
the IETF SIP specifications, and are then the basis for the description of further requirements.
Some of these extra requirements formally change the proxy role into a B2BUA. In all other
respects other than those more completely described in subclause 5.2 a P-CSCF implements proxy
requirements. Despite being a B2BUA a P-CSCF does not implement UA requirements from the
IETF RFCs, except as indicated in this specification, e.g., relating to registration event
subscription.
55
56
57
58
All the above entities are functional entities that could be implemented in a number of different
physical platforms coexisting with a number of other functional entities. The implementation shall
give priority to transactions at one functional entity, e.g., that of the E-CSCF, over non-emergency
59
37
Annex D
transactions at other entities on the same physical implementation. Such priority is similar to the
priority within the functional entities themselves specified elsewhere in this document.
END OF CHANGE
4.2
URI and address assignments
In order for SIP and SDP to operate, the following preconditions apply:
START OF CHANGE
7.
The allocation of IP address for UE is also based on the requirements of [7] subclause 4.3.
8.
For the purpose of emergency service, the UE shall use at least two emergency public user
identities, of which one is a SIP URI derived as specified in Annex E of [X.S0049] and the
second is a tel URI
END OF CHANGE
4.2A Transport mechanisms
START OF CHANGE.
The UE and the P-CSCF shall send and receive request and responses other than initial REGISTER
requests on the protected ports as described in [19].
In case of an emergency session if the UE does not have sufficient credentials to authenticate with the
IM CN subsystem and regulations allow, the UE and P-CSCF shall send request and responses other
than initial REGISTER requests on non protected ports.
END OF CHANGE
4.3
Routing principles of IM CN subsystem entities
Each IM CN subsystem functional entity shall apply loose routing policy as described in [26], when
processing a SIP request. In cases where the I-CSCF, E-CSCF, or the S-CSCF may interact with SIP
entities in non IM CN subsystem networks that apply strict routing policy, the routing procedures
defined in [26] that ensure interoperability with these SIP entities shall be used by the I-CSCF, ECSCF and S-CSCF.
4.4
Trust domain
START OF CHANGE
8 Procedures Related to Establishment of IMS
Emergency Session
3
8
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
[34] provides for the existence and trust of an asserted identity within a trust domain. For the IM CN
subsystem, this trust domain consists of the functional entities that belong to the same operator’s
domain (P-CSCF, the E-CSCF, the I-CSCF, the S-CSCF, the BGCF, the MGCF, the MRFC, and all
ASs that are not provided by third-party service providers). Additionally, other IMS nodes that are not
part of the same operator’s domain may or may not be part of the trust domain, depending on whether
an interconnect agreement exists with the remote network. SIP functional entities that belong to a
network for which there is an interconnect agreement are part of the trust domain. ASs provided by
third-party service providers are outside the trust domain. SIP functional entities within the trust
domain will need to take an action on the removal of the P-Asserted-Identity header when SIP
signaling crosses the boundary of the trust domain.
2
3
4
5
6
7
8
9
10
11
12
END OF CHANGE
13
14
15
16
17
4.7
Emergency service
18
The need for support of emergency calls in the IM CN subsystem is determined by national regulatory
requirements.
19
20
21
If the UE cannot detect the emergency call attempt, the UE initiates the request as per normal
procedures as described in subclause 5.1.2A. Depending on network policies, for a non-roaming UE
an emergency call attempt can succeed even if the UE did not detect that an emergency session is
being requested, otherwise the network rejects the request indicating to the UE that the attempt was for
an emergency service.
22
23
24
25
26
27
The UE procedures for UE detectable emergency calls are defined in subclause 5.1.6.
28
29
The P CSCF and E-CSCF procedures for emergency service are described in subclause 5.2.10 and
5.11, respectively.
30
31
32
Access dependent aspects of emergency service (e.g., emergency registration support and location
provision) are defined in the access technology specific annexes for each access technology.
33
34
35
36
37
38
5
Application usage of SIP
39
40
41
42
5.1
Procedures at the UE
43
44
45
5.1.3.1 Initial INVITE request
46
47
48
49
50
51
52
53
54
55
56
START OF CHANGE.
Upon generating an initial INVITE request, the UE shall include the Accept header with
“application/sdp”, the MIME type associated with the 3GPP2 IMS XML body (see subclause 7.6.1)
and any other MIME type the UE is willing and capable to accept.
In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response
containing a XML body that includes an <alternative service> element with the <type> child element
set to “emergency”, the UE shall attempt an emergency call as described in subclause 5.1.6.
57
58
END OF CHANGE
59
39
Annex D
5.1.6
5.1.6.1
Emergency service
General
A CS and IM CN subsystem capable UE shall follow the conventions and rules specified in [X.S0049]
to select the domain for the emergency call attempt. If the CS domain is selected, the UE shall attempt
an emergency call setup according to the procedures described in [J-STD-036].
The UE shall determine, whether it is currently attached to its home operator’s network or to a
different network than its home operator’s network by applying access technology specific procedures
described in the access technology specific annexes.
If the IM CN subsystem is selected and the UE is currently attached to its home operator’s network
and the UE is currently registered, the UE shall attempt an emergency call as described in subclause
5.1.6.8.4.
If the IM CN subsystem is selected and the UE is currently attached to its home operator’s network
and the UE is not currently registered, the UE shall:
1.
perform an initial emergency registration, as described in subclause 5.1.6.2; and
2.
attempt an emergency call as described in subclause 5.1.6.8.3.
If the IM CN subsystem is selected and the UE is attached to a different network than its home
operator’s network and the assigned P-CSCF is located in its home operator’s network , the UE shall:
1.
perform an initial emergency registration, as described in subclause 5.1.6.2; and
2.
attempt an emergency call as described in subclause 5.1.6.8.3.
If the IM CN subsystem is selected and the UE has no credentials the UE can make an emergency call
without being registered. The UE shall attempt an emergency call as described in subclause 5.1.6.8.2.
The IP-CAN can, depending on its capabilities, provide local emergency numbers to the UE which has
that capability, in order for the UE to recognize these numbers as emergency call.
5.1.6.2
Initial emergency registration
When the user initiates an emergency call, if emergency registration is needed, the UE shall perform
an emergency registration prior to sending the SIP request related to the emergency call.
IP-CAN procedures for emergency registration are defined in [X.S0049] and Annex B.
When a UE performs an initial emergency registration the UE shall perform the actions as specified in
subclause 5.1.1.2 with the following additions:

the UE shall populate the To and From header in the REGISTER request with the emergency
public user identity as specified in Annex E of [X.S0049].
When the UE performs an initial emergency registration and whilst this emergency registration is
active, the UE shall:

handle the emergency registration independently from any other ongoing registration to the
IM CN subsystem;
8 Procedures Related to Establishment of IMS
Emergency Session
4
0
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0

handle any signaling or media related IP-CAN for the purpose of emergency calls
independently from any other established IP-CAN for IM CN subsystem related signaling or
media; and

handle all SIP signaling and all media related to the emergency call independently from any
other ongoing IM CN subsystem signaling and media.
2
3
4
5
6
7
8
9
5.1.6.2A New initial emergency registration
10
The UE shall perform a new initial emergency registration, as specified in subclause 5.1.6.2, if the UE
determines that:
11
12
13
14
15

it has previously performed an emergency registration which has not yet expired; and

it has obtained an IP address from the serving IP-CAN, as specified in subclause 9.2.1,
different than the IP address used for the emergency registration.
16
17
18
19
5.1.6.3
20
Initial subscription to the registration-state event package
The UE shall not subscribe to the reg event package for any emergency public user identity.
21
22
23
5.1.6.4
User-initiated emergency reregistration
24
The UE shall perform user-initiated emergency reregistration as specified in subclause 5.1.1.4 if:
25
26

27
28
29
30
31
32
half of the time for the emergency registration has expired and:
–
the UE has emergency related ongoing dialog or if standalone transactions exist; or
–
the user initiates an emergency call.
The UE shall not perform user-initiated emergency reregistration in any other cases.
33
34
35
5.1.6.5
36
Authentication
When a UE performs authentication a UE shall perform the procedures as specified in subclause
5.1.1.5.
37
38
39
40
41
5.1.6.6
User-initiated emergency deregistration
The UE shall not perform user-initiated deregistration of any registered emergency public user
identity.
42
43
44
NOTE: The UE will be deregistered when the emergency registration expires.
45
46
47
48
5.1.6.7
49
Network-initiated emergency deregistration
An emergency registration will not be deregistered by the network (see subclause 5.4.8.4).
50
51
52
5.1.6.8
Emergency session setup
53
54
5.1.6.8.1
General
55
56
57
The UE shall translate any user indicated emergency number as specified in [X.S0049] to an
emergency service URN, i.e., an URN with “sos” service type as specified in draft-ietf-ecrit-service-
58
59
41
Annex D
urn [69]. An additional sub-service type can be added if information on the type of emergency service
is known.
In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response
containing a XML body that includes an <alternative service> element with the <type> child element
set to “emergency”, the UE shall automatically send an ACK request to the P-CSCF as per normal SIP
procedures and terminate the session.
NOTE 1: The UE can attempt an emergency call setup according to the procedures described in
[J-STD-036-B].
NOTE 2: Emergency numbers which the UE does not detect, will be treated as a normal call.
5.1.6.8.2
Emergency session set-up in case of no registration
When establishing an emergency session for an unregistered user, the UE shall be allowed to receive
responses to emergency requests and requests inside an established emergency session on the
unprotected ports. All other messages not arriving on a protected port shall be rejected or silently
discarded by the UE.
Prior to establishing an emergency session for an unregistered user, the UE shall acquire a local IP
address, discover a P-CSCF, and establish an IP-CAN bearer that can be used for SIP signaling. The
UE shall send only the initial INVITE requests to the port advertised to the UE during the P-CSCF
discovery procedure. If the UE does not receive any specific port information during the P-CSCF
discovery procedure, the UE shall send the initial INVITE request to the SIP default port values as
specified in RFC 3261 [26].
The UE shall apply the procedures as specified in subclause 5.1.2A.1 and subclause 5.1.3 with the
following additions:
1.
the UE shall set the From header field of the INVITE request to “Anonymous” as specified in
RFC 3261 [26];
2.
the UE shall include a Request-URI in the initial INVITE request that contains an emergency
service URN, i.e., with “sos” service type as specified in draft ietf-ecrit-service-urn [69]. An
additional sub-service type can be added if information on the type of emergency service is
known;
NOTE 1: Other specifications make provision for emergency service identifiers that are not
specifically the emergency service URN, to be recognized in the UE. Emergency service
identifiers which the UE does not detect will be treated as a normal call by the UE.
3.
the UE shall insert in the INVITE request, a To header with:
–
the same emergency service URN as in the Request URI; or
–
if the UE cannot perform local dialstring interpretation for the dialed digits, a dialstring
URI representing the dialed digits in accordance with RFC 4967 [103] or a tel URL
representing the dialed digits;
NOTE 2: This version of this document does not provide any specified handling of a URI
with the dialed digits in accordance with RFC 4967 [103] at an entity within the IM CM
subsystem. Behavior when this is used is therefore not defined.
4.
if available to the UE (as defined in the access technology specific annexes for each access
technology), the UE shall include in the P-Access-Network-Info header in any request for a
dialog, any subsequent request (except ACK requests and CANCEL requests) or response
8 Procedures Related to Establishment of IMS
Emergency Session
4
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
(except CANCEL responses) within a dialog or any request. The UE shall populate the PAccess-Network-Info header with the current point of attachment to the IP-CAN as specified
for the access network technology (see subclause 7.2A.4). The P-Access-Network-Info
header contains the location identifier such as the cell id or the identity of the I-WLAN access
node, which is relevant for routing the IMS emergency call;
2
3
4
5
6
7
X.S0049-0 v1.0
5.
the UE shall populate the P-Preferred-Identity header in the INVITE request with an
equipment identifier as a SIP URI. The special details of the equipment identifier to use
depends on the IP-CAN;
6.
a Contact header set to include SIP URI that contains in the hostport parameter the IP address
of the UE and an unprotected port where the UE will receive incoming requests belonging to
this dialog. The UE shall not include either the public or temporary GRUU in the Contact
header;
7.
a Via header set to include the IP address of the UE in the sent-by field and for the UDP the
unprotected server port value where the UE will receive response to the emergency request,
while for the TCP, the response is received on the TCP connection on which the emergency
request was sent;
8.
if the UE has its location information available, it shall include the location information in the
INVITE request in the following way:
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
–
if the UE is aware of the URI that points to where the UE’s location is stored, include the
URI in the Geolocation header in accordance with draft-ietf-sip-location-conveyance
[89]; or
–
if the geographical location information of the UE is available to the UE, include its
geographical location information as PIDF location object in accordance with RFC 4119
[90] and include the location object in a message body with the content type
application/pidf+xml in accordance with draft-ietf-sip-location-conveyance [89]. The
Geolocation header is set to a Content ID in accordance with draft-ietf-sip-locationconveyance [89]; and
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
9.
if the UE has no geographical location information available, the UE shall not include any
geographical location information as specified in draft-ietf-sip-location-conveyance [89] in
the INVITE request.
NOTE 3: It is suggested that UE’s only use the option of providing a URI when the domain
part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the
network operator needs to provide guidance to the end user. A URI that is only resolvable to
the UE which is making the emergency call is not desirable.
NOTE 4: During the dialog, the points of attachment to the IP-CAN of the UE can change
(e.g., UE connects to different cells). The UE will populate the P-Access-Network-Info
header in any request or response within a dialog with the current point of attachment to the
IP-CAN (e.g., the current cell information).
The UE shall build a proper preloaded Route header value for all new dialogs. The UE shall build a
Route header value containing only the P-CSCF URI (containing the unprotected port number and the
IP address or the FQDN learnt through the P-CSCF discovery procedures).
51
52
53
When a SIP transaction times out, i.e., timer B, timer F or timer H expires at the UE, the UE may
behave as if timer F expired, as described in subclause 5.1.1.4.
54
55
56
NOTE 5: It is an implementation option whether these actions are also triggered by other
means.
57
58
59
NOTE 6: A number of headers can reveal information about the identity of the user. Where
privacy is required, implementers should also give consideration to other headers that can
43
Annex D
reveal identity information. RFC 3323 [33] subclause 4.1 gives considerations relating to a
number of headers.
NOTE 7: RFC 3261 [26] provides for the use of the Priority header field with a suggested
value of “emergency”. It is not precluded that emergency sessions contain this value, but
such usage will have no impact on the processing within the IM CN subsystem.
5.1.6.8.3
Emergency session set-up within an emergency registration
After a successful initial emergency registration, the UE shall apply the procedures as specified in
subclause 5.1.2A, 5.1.3 and 5.1.4 with the following additions:
1.
the UE shall insert in the INVITE request, a From header that includes the emergency public
user identity or the tel URI associated with the emergency public user identity, as described in
subclause 4.2;
2.
the UE shall include a Request URI in the INVITE request that contains an emergency
service URN, i.e., with “sos” service type as specified in draft-ietf-ecrit-service-urn [69]. An
additional sub-service type can be added if information on the type of emergency service is
known;
3.
the UE shall insert in the INVITE request, a To header with:
–
the same emergency service URN as in the Request URI; or
–
if the UE cannot perform local dialstring interpretation for the dialed digits, a dialstring
URI representing the dialed digits in accordance with RFC 4967 [103] or a tel URL
representing the dialed digits;
NOTE 1: This version of this document does not provide any specified handling of a URI
with the dialed digits in accordance with RFC 4967 [103] at any entity within the IM CM
subsystem. Behavior when this is used is therefore not defined.
4.
if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the
P-Access-Network-Info header shall contain a location identifier such as the cell id, which is
relevant for routing the IMS emergency call
NOTE 2: This document describes several methods how the UE can get its location
information from the access network or from a server. Such methods are not in the scope of
this specification.
5.
the UE shall insert in the INVITE request, a P-Preferred-Identity header that includes the
emergency public user identity or the tel URI associated with the emergency public user
identity as described in subclause 4.2;
6.
if the UE has its location information available, it shall include it in the INVITE request in the
following way:
–
if the UE is aware of the URI that points to where the UE’s location is stored, include the
URI in the Geolocation header in accordance with draft-ietf-sip-location-conveyance
[89]; or
–
if the geographical location information of the UE is available to the UE, include its
geographical location information as PIDF location object in accordance with RFC 4119
[90] and include the location object in a message body with the content type
application/pidf+xml in accordance with draft-ietf-sip-location-conveyance [89]. The
8 Procedures Related to Establishment of IMS
Emergency Session
4
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
Geolocation header is set to a Content ID in accordance with draft-ietf-sip-locationconveyance [89];
2
3
NOTE 3: It is suggested that UE’s only use the option of providing a URI when the domain
part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the
network operator needs to provide guidance to the end user. A URI that is only resolvable to
the UE which is making the emergency call is not desirable.
4
5
6
7
8
7.
9
10
11
if the UE has no geographical location information available, the UE shall not include any
geographical location information as specified in draft-ietf-sip-location-conveyance [89] in
the INVITE request; and
12
NOTE 4: RFC 3261 [26] provides for the use of the Priority header field with a suggested
value of “emergency”. It is not precluded that emergency sessions contain this value, but
such usage will have no impact on the processing within the IM CN subsystem.
13
14
15
16
Upon receiving a 380 (Alternative Service) response to the INVITE request, with the 380 (Alternative
Service) response including a IM CN subsystem XML body, with the type element set to “emergency”
and the action element set to “emergency-registration” the UE shall:
17
18
19
20
21

perform an initial emergency registration using a different visited network if available, as
described in subclause 5.1.6.2 and if the new emergency registration succeeded, attempt an
emergency call as described in this subclause;

attempt emergency call via CS domain according to the procedures described in [J-STD-036],
if available and not already tried; or

perform implementation specific actions to establish the emergency call.
22
23
24
25
26
27
28
29
30
31
32
5.1.6.8.4
Emergency session setup within a non-emergency registration
The UE shall apply the procedures as specified in subclauses 5.1.2A, 5.1.3 and 5.1.4 with the
following additions:
33
34
1.
the UE shall include a Request URI in the INVITE request that contains an emergency
service URN, i.e., with “sos” service type as specified in draft-ietf-ecrit-service-urn [69]. An
additional sub-service type can be added if information on the type of emergency service is
known;
2.
the UE shall insert in the INVITE request, a To header with:
35
36
37
38
39
40
41
42
43
44
45
46
the same emergency service URN as in the Request URI; or
–
if the UE cannot perform local dialstring interpretation for the dialed digits, a dialstring
URI representing the dialed digits in accordance with RFC 4967 [103] or a tel URL
representing the dialed digits;
NOTE 1: This version of this document does not provide any specified handling of a URI
with the dialed digits in accordance with RFC 4967 [103] at any entity within the IM CM
subsystem. Behavior when this is used is therefore not defined.
47
48
49
50
–
3.
the UE shall insert in the INVITE request, a From header that includes the public user identity
or the tel URI associated with the public user identity, as described in subclause 4.2;
4.
if available to the UE, and if defined for the access type as specified in subclause 7.2A.4, the
P-Access-Network-Info header shall contain a location identifier such as the cell id, which is
relevant for routing the IMS emergency call
51
52
53
54
55
56
57
58
59
NOTE 2: This document describes several methods how the UE can get its location
information from the access network or from a server. Such methods are not in the scope of
this specification
45
Annex D
5.
.the UE shall insert in the INVITE request a P-Preferred-Identity that includes the public user
identity or the tel URI associated with the public user identity as described in subclause 4.2;
6.
if the UE has its location information available, it shall include it in the INVITE request in the
following way:
7.
–
if the UE is aware of the URI that points to where the UE’s location is stored, include the
URI in the Geolocation header in accordance with draft-ietf-sip-location-conveyance
[89]; or
–
if the geographical location information of the UE is available to the UE, include its
geographical location information as PIDF location object in accordance with RFC 4119
[90] and include the location object in a message body with the content type
application/pidf+xml in accordance with draft-ietf-sip-location-conveyance [89]. The
Geolocation header is set to a Content ID in accordance with draft-ietf-sip-locationconveyance [89];
if the UE has no geographical location information available, the UE shall not include any
geographical location information as specified in draft-ietf-sip-location-conveyance [89] in
the INVITE request.
NOTE 3: It is suggested that UE’s only use the option of providing a URI when the domain
part belongs to the current P-CSCF or S-CSCF provider. This is an issue on which the
network operator needs to provide guidance to the end user. A URI that is only resolvable to
the UE which is making the emergency call is not desirable.
Upon receiving a 380 (Alternative Service) response to the INVITE request, with the 380 (Alternative
Service) response include a IM CN subsystem XML body, with the type element set to “emergency”
and the action element set to “emergency-registration” the UE shall:
1.
perform an initial emergency registration, as described in subclause 5.1.6.2; and
–
attempt an emergency call as described in subclause 5.1.6.8.3.
2.
attempt emergency call via CS domain according to the procedures described in [23], if
available and not already tried; or
3.
perform implementation specific actions to establish the emergency call.
NOTE 3: The IMS emergency specification in [X.S0049] describes several methods how the
UE can get its location information from the access network or from a server. Such methods
are not in the scope of this specification.
NOTE 4: RFC 3261 [26] provides for the use of the Priority header field with a suggested
value of “emergency”. It is not precluded that emergency sessions contain this value, but
such usage will have no impact on the processing within the IM CN subsystem.
5.1.6.9
Emergency session release
Normal call release procedure shall apply, as specified in the subclause 5.1.5.
8 Procedures Related to Establishment of IMS
Emergency Session
4
6
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
3
4
5.2
X.S0049-0 v1.0
Procedures at the P-CSCF
5.2.10 Emergency service
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
5.2.10.1 General
If the P-CSCF belongs to a network where the registration is not required to obtain emergency service,
the P-CSCF shall accept any unprotected request on the IP address and port advertised to the UE
during the P-CSCF discovery procedure. The P-CSCF shall also accept any unprotected request on the
same IP address and the default port as specified in RFC 3261 [26].
The P-CSCF can handle emergency session and other requests from both a registered user as well as
an unregistered user. Certain networks only allow emergency session from registered users.
NOTE 1: If only emergency setup from registered users is allowed, a request from an
unregistered user is ignored since it is received outside of the security association.
The P-CSCF can handle emergency session establishment within a non-emergency registration.
20
21
The P-CSCF shall not subscribe to the reg event package for any emergency public user identity.
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
The P-CSCF shall store a configurable list of local emergency service identifiers, i.e., emergency
numbers and the emergency service URN, which are valid for the operator to which the P-CSCF
belongs to. In addition to that, the P-CSCF shall store a configurable list of roaming partners’
emergency service identifiers.
NOTE 2: The emergency service URN are common to all networks, although subtypes may either
not necessarily be in use, or a different set of subtypes is in use. The above requirements do not
apply to subtypes of the emergency service URN.
Access technology specific procedures are described in each access technology specific annex to
determine whether the initial request for a dialog or standalone transaction or an unknown method is
destined for a PSAP.
NOTE 3: Depending on local operator policy, the P-CSCF has the capability to reject requests
relating to specific methods in accordance with RFC 3261 [26], as an alternative to the
functionality described above.
For all SIP transactions identified as relating to an emergency, the P-CSCF shall give priority over
other transactions. This allows special treatment of such transactions or dialogs.
41
42
43
44
NOTE 4: This special treatment can include filtering, higher priority, routing or call gapping.
The exact meaning of priority is not defined further in this document, but is left to national
regulation and network configuration.
45
46
47
48
5.2.10.2 General treatment for all dialogs and standalone transactions
excluding the REGISTER method - from an unregistered user
49
50
51
52
53
54
If the P-CSCF receives an initial request for a dialog or standalone transaction, or an unknown method
for an unregistered user on the IP address and the unprotected port advertised to the UE during the PCSCF discovery or the SIP default port, the P-CSCF shall inspect the Request URI independent of
values of possible entries in the received Route headers for known emergency service identifiers, i.e.,
emergency numbers and the emergency service URN from the configurable lists.
55
56
57
58
If the P-CSCF detects that the Request-URI of the initial request for a dialog or standalone transaction,
or unknown method matches one of the emergency service identifiers in any of these lists, the P-CSCF
shall:
59
47
Annex D
1.
2.
include in the Request-URI an emergency service URN, i.e., with a service type of “sos” in
accordance with [69]. An additional sub-service type can be added if information on the type
of emergency service is known. The entry in the Request-URI that the P-CSCF includes may
either be:
–
as received in the Request URI from the UE in accordance with [69]; or
–
as deduced from the Request-URI received from the UE;
select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header; and
NOTE 1: How the list of E-CSCF is obtained by the P-CSCF is implementation dependent.
3.
execute the procedure described in subclause 5.2.6.3 dealing with the procedure when the PCSCF receives an initial request from the UE and subclause 5.2.7.2 except for:
–
verifying the preloaded route against the received Service-Route header;
–
removing the P-Preferred-Identity header; and
–
inserting a P-Asserted-Identity header.
When the P-CSCF receives any 1xx or 2xx response to the above requests, the P-CSCF shall execute
the appropriate procedure for the type of request described in subclause 5.2.6.3, except that the PCSCF may rewrite the port number of its own Record-Route entry to an unprotected port where the PCSCF wants to receive the subsequent incoming requests from the UE belonging to this dialog.
If the P-CSCF does not receive any response to the initial request for a dialog or standalone transaction
or unknown method (including its retransmissions); or receives a 3xx response or 480 (Temporarily
Unavailable) response to an INVITE request, the P-CSCF shall select a new E-CSCF and forward the
request.
When the P-CSCF receives a target refresh request from the UE for a dialog, the P-CSCF shall execute
the procedure described in steps 1 to 5, in paragraph of subclause 5.2.6.3 describing the procedure
when the P-CSCF receives a target refresh request.
When the P-CSCF receives from the UE subsequent requests other than a target refresh request
(including requests relating to an existing dialog where the method is unknown), the P-CSCF shall
execute the procedure described in steps 1 to 4, in the paragraph of subclause 5.2.6.3 describing the
procedure when the P-CSCF receives a subsequent request.
When the P-CSCF receives any 1xx or 2xx response to the above requests, the P-CSCF shall execute
the appropriate procedure for the type of request described in subclause 5.2.6.3.
When the P-CSCF receives, destined for the UE, a target refresh request for a dialog, prior to
forwarding the request, the P-CSCF shall execute the procedure described in step 3, the paragraph of
subclause 5.2.6.4 describing when the P-CSCF receives a target refresh request.
When the P-CSCF receives a 1xx or 2xx response to the above request the P-CSCF shall execute the
procedure described in steps 1 to 3 in the paragraph of subclause 5.2.6.4 describing when the P-CSCF
receives 1xx or 2xx response to a target request.
When the P-CSCF receives any other response to the above request the P-CSCF shall execute the
procedure described in steps 1 to 2 in the paragraph of subclause 5.2.6.4 describing when the P-CSCF
receives any other response to a target request.
When the P-CSCF receives, destined for the UE, a subsequent request for a dialog that is not a target
refresh request (including requests relating to an existing dialog where the method is unknown), prior
8 Procedures Related to Establishment of IMS
Emergency Session
4
8
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
2
X.S0049-0 v1.0
to forwarding the request, the P-CSCF shall execute the procedure described in steps 2 and 3 of
subclause 5.2.6.4 describing when a P-CSCF receives a subsequent request.
3
4
5
6
When the P-CSCF receives any other response to the above request the P-CSCF shall execute the
procedure described in step 1 in the paragraph of subclause 5.2.6.4 describing when the P-CSCF
receives any other response to a subsequent request.
7
8
9
10
5.2.10.3 General treatment for all dialogs and standalone transactions
excluding the REGISTER method after emergency registration
11
12
13
14
15
16
If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown
method, for a registered user over the security association that was created during the emergency
registration, the P-CSCF shall inspect the Request URI independent of values of possible entries in the
received Route headers for known emergency service identifiers, i.e., emergency numbers and the
emergency service URN from these configurable lists.
17
18
19
20
21
22
23
24
25
26
If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone
transaction, or an unknown method does not match any one of the emergency service identifiers in any
of these lists, the P-CSCF shall reject the request by returning a 403 (Forbidden) response to the UE.
If the P-CSCF detects that the Request-URI of the initial request for a dialog, or a standalone
transaction, or an unknown method matches one of the emergency service identifiers in any of these
lists, the P-CSCF shall:
1.
27
28
29
30
31
32
include in the Request-URI an emergency service URN, i.e., with a service type of “sos” as
specified in [69], if necessary, and execute the procedure described in steps 3, 4, 5, and 6, in
subclause 5.2.6.3 dealing with the procedure when the P-CSCF receives an initial request
from the UE. The entry in the Request-URI that the P-CSCF includes may either be:
–
as received from the UE in the Request URI in accordance with [69]; or
–
as deduced from the Request-URI received from the UE.
33
34
35
In addition the P-CSCF shall execute the procedures as specified in subclause 5.2 with the following
additions:
36
37
38
39
2.
the P-CSCF shall:
–
if the registered emergency public user identity is included in the P-Preferred-Identity
header, remove the P-Preferred-Identity header from the received request and insert a PAsserted-Identity header that includes the emergency public user identity that was
present in the P-Preferred-Identity header. Add a second P-Asserted identity header that
contains the tel URI associated with the emergency public user identity. If the tel URI
associated with the registered emergency public user identity is included in the PPreferred-Identity header, check the validity of the tel URI, remove the P-PreferredIdentity header and insert a P-Asserted-Identity header that includes the tel URI that was
present in the P-Preferred-Identity header. Add a second P-Asserted-Identity header that
contains the emergency public user identity; and
–
select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header.
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
NOTE: It is implementation dependant as to how the P-CSCF obtains the list of E-CSCFs.
If the P-CSCF does not receive any response to the INVITE request (including its retransmissions); or
receives a 3xx response or 480 (Temporarily Unavailable) response to an INVITE request, the P-CSCF
shall select a new E-CSCF and forward the INVITE request.
56
57
58
59
49
Annex D
5.2.10.4 General treatment for all dialogs and standalone transactions
excluding the REGISTER method - non-emergency registration
If the P-CSCF receives an initial request for a dialog, or a standalone transaction, or an unknown
method, for a registered user the P-CSCF shall inspect the Request URI independent of values of
possible entries in the received Route headers for known emergency service identifiers, i.e., emergency
numbers and the emergency service URN from these configurable lists. If the P-CSCF detects that the
Request-URI of the initial request for a dialog, or a standalone transaction, or an unknown method
matches one of the emergency service identifiers in any of these lists, the P-CSCF shall:
0.
determine the geographic location of the UE. Access technology specific procedures are
described in each access technology specific annex. If the UE is roaming or the P-CSCF is in
a different network than the UE’s home operator’s network, then the P-CSCF:
–
shall reject the request by returning a 380 (Alternative Service) response to the UE;
–
shall assume that the UE supports version 1 of the XML Schema for the IM CN
subsystem XML body if support for the 3GPP2 IMS XML body in the Accept header is
not indicated; and
–
shall include in the 380 (Alternative Service) response:
–
a Content-Type header field with the value set to associated MIME type of the 3GPP2
IMS XML body as described in subclause 7.6.1.
The body shall contain:
NOTE 1: Roaming is when a UE is in a geographic area that is outside the serving
geographic area of the home IM CN subsystem.
a)
an <alternative-service> element, set to the parameters of the alternative service;
b) a <type> child element, set to “emergency” to indicate that it was an emergency call;
c)
a <reason> child element, set to an operator configurable reason; and
d) an <action> child element, set to “emergency-registration” if the request included an
emergency service URN in the Request-URI.
NOTE 2: Emergency service URN in the request-URI indicates for the network that the
emergency call attempt is recognized by the UE.
1.
include in the Request-URI an emergency service URN, i.e., with a service type of “sos” as
specified in [69], if necessary, and execute the procedure described in steps 2, 3, 4, 5, and 6,
in subclause 5.2.6.3 dealing with the procedure when the P-CSCF receives an initial request
from the UE. The entry in the Request-URI that the P-CSCF includes may either be:
–
as received from the UE in the Request URI in accordance with [69]; or
–
as deduced from the Request-URI received from the UE.
In addition the P-CSCF shall execute the procedures as specified in subclause 5.2 with the following
additions:
2.
the P-CSCF shall:
–
if the public user identity included in the P-Preferred-Identity header matches one of the
registered public user identities, remove the P-Preferred-Identity header from the
received request and insert a P-Asserted-Identity header that includes the public user
8 Procedures Related to Establishment of IMS
Emergency Session
5
0
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
identity that was present in the P-Preferred-Identity header. Add a second P-Asserted
identity header that contains the tel URI associated with the public user identity. If the
tel URI associated with one of the registered public user identities is included in the PPreferred-Identity header, check the validity of the tel URI, remove the P-PreferredIdentity header and insert a P-Asserted-Identity header that includes the tel URI that was
present in the P-Preferred-Identity header. Add a second P-Asserted-Identity header that
contains a public user identity associated with the tel URI;
2
3
4
5
6
7
8
–
9
select an E-CSCF and add the URI of the selected E-CSCF to the topmost Route header.
10
NOTE: It is implementation dependant as to how the P-CSCF obtains the list of E-CSCFs.
11
12
13
14
15
If the P-CSCF does not receive any response to the INVITE request (including its retransmissions); or
receives a 3xx response or 480 (Temporarily Unavailable) response to an INVITE request, the P-CSCF
shall select a new E-CSCF and forward the INVITE request.
16
17
18
19
20
21
22
23
24
25
5.2.10.5 Abnormal cases
If the IM CN subsystem to where the P-CSCF belongs to is not capable to handle emergency sessions
or due to local policy does not handle emergency sessions or only handles certain type of emergency
session request or does not support emergency sessions for either the geographical location of the UE
is located or the IP-CAN to which the UE is attached,, the P-CSCF shall not forward the INVITE
request. The P-CSCF

shall respond to the INVITE request with a 380 (Alternative Service) response, see subclause
5.2.10.1.

shall assume that the UE supports version 1 of the XML Schema for the IM CN subsystem
XML body if support for the 3GPP2 IMS XML body in the Accept header is not indicated;
and

shall include in the 380 (Alternative Service) response:
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
–
a Content-Type header field with the value set to associated MIME type of the 3GPP2
IMS XML body as described in subclause 7.6.1.
The body shall contain:
a)
an <alternative-service> element, set to the parameters of the alternative service;
b) a <type> child element, set to “emergency” to indicate that it was an emergency call;
41
42
43
44
45
46
47
48
49
50
51
52
c)
a <reason> child element, set to an operator configurable reason; and
d) an <action> child element, set to “emergency-registration” if the request included an
emergency service URN in the Request-URI.
NOTE 1: Emergency service URN in the request-URI indicates for the network that the
emergency call attempt is recognized by the UE.
NOTE 2: Some networks only allow session requests with a Request-URI containing an
emergency service URN, i.e., a service URN with a top-level service type of “sos” as
specified in [69].
53
54
55
56
57
58
59
51
Annex D
5.4
Procedures at the S-CSCF
5.4.8
5.4.8.1
Emergency service
General
S-CSCF shall handle the emergency registration as per the needs of the normal registration.
For all registrations identified as relating to an emergency public user identity, the S-CSCF shall give
priority over other transactions. This allows special treatment of such registrations.
This special treatment can include (e.g., with respect to filtering, higher priority, routing or call
gapping) of emergency sessions. The exact meaning of priority is not defined further in this document,
but is left to national regulation and network configuration.
5.4.8.2
Initial emergency registration or user-initiated emergency
reregistration
When the S-CSCF receives a REGISTER request without an “integrity-protected” parameter, or with
the “integrity-protected” parameter in the Authorization header set to “no” and the To header includes
an emergency public user identity the S-CSCF shall perform the actions as specified in subclause
5.4.1.2.1 with the following additions:

if the emergency user identity is linked to a private user identity that has a registered
emergency public user identity but with a new contact address, and the authentication has
been successful and if the previous emergency registration has not expired, the S-CSCF shall
delete the previous contact information. Contacts related to non-emergency registration shall
not be deregistered.
When the S-CSCF receives a REGISTER request with the “integrity-protected” parameter in the
Authorization header set to “yes”, the S-CSCF shall identify the user by the public user identity as
received in the To header and the private user identity as received in the Authorization header of the
REGISTER request the S-CSCF shall perform the actions as specified in subclause 5.4.1.2.2 with the
following additions:

the S-CSCF shall not include a Service-Route in the 200 (OK) to the REGISTER request;

store the Path header and the contact information including all header parameters contained in
the Contact header. The S-CSCF shall use the Path header and the contact information
obtained during the emergency registration to build a preloaded Route header values for the
emergency dialogs destined for the UE; and
NOTE 1: The Path header and contact information used for the emergency dialogs destined
for the UE and obtained during the emergency registration can be different than the Path
header used for the non-emergency communication and obtained during the non-emergency
registration.
NOTE 2: If the previous emergency registration with different contact information or
emergency Path header has not expired, the S-CSCF will not perform the network initiated
deregistration procedure for the previous emergency registration, but will let it expire.

the S-CSCF shall not send any third-party REGISTER requests to any AS.

determine the duration of the registration time by checking the value of the Expires header in
the received REGISTER request and based on local policy.
8 Procedures Related to Establishment of IMS
Emergency Session
5
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
NOTE 3: The value of the emergency registration time is subject to national regulation and
can be subject to roaming agreements.
2
3
4
5
5.4.8.3
User-initiated emergency deregistration
6
When S-CSCF receives a REGISTER request with the Expires header field containing the value zero
and the To header includes an emergency public user identity as specified in Annex E of [X.S0049],
the S-CSCF shall reject the REGISTER request by sending a 501 (Not Implemented) response.
7
8
9
10
NOTE: The UE cannot deregister its emergency public user identity.
11
12
13
5.4.8.4
Network-initiated emergency deregistration
14
The S-CSCF shall not perform a network-initiated emergency deregistration for an emergency public
user identity.
15
16
17
18
19
5.4.8.5
20
Network-initiated emergency reauthentication
The S-CSCF shall not reauthenticate an emergency public user identity.
21
22
23
5.4.8.6
Subscription to the event providing registration state
24
If a S-CSCF receives a SUBSCRIBE request addressed to S-CSCF containing the Event header with
the reg event package with a emergency public user identity in the To header, the S-CSCF shall reject
the SUBSCRIBE request for the reg-event package by sending a 489 (Bad Event) response.
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
5.4.8.7
Notification of the registration state
The S-CSCF shall not send a NOTIFY request addressed to an emergency public user identity
regarding its subscription state.
When the user performs an emergency registration or when the emergency registration expires, the SCSCF shall not send a NOTIFY request to the subscribers to the reg event package of the respective
user.
The emergency public user identities shall not be included in the NOTIFY requests sent to the
subscribers to the reg event package of the user.
40
41
42
43
5.11 Procedures at the E-CSCF
44
45
46
47
5.11.1 General
The PSAP may either be directly connected to the IM CN subsystem or via the PSTN.
48
49
50
51
The E-CSCF retrieves a PSAP URI, based on the location of the UE. The PSAP URI can be retrieved
from LRF or from local configuration. The PSAP address will either point to a PSAP connected to the
IM CN subsystem or to a PSAP connected to the PSTN.
52
53
54
55
56
If the E-CSCF fails to select a PSAP based on the received location information contained in an
INVITE request, the E-CSCF can interrogate the LRF in order to retrieve location information.
NOTE: The protocol between the E-CSCF and LRF is not specified.
57
58
59
53
Annex D
5.11.2 UE originating case
The E-CSCF may either forward the call to a PSAP in the IP network or forward the call to a PSAP in
the PSTN. In the latter case the call will pass a BGCF and a MGCF before entering the PSTN.
Upon receipt of an initial request for a dialog, or a standalone transaction, or an unknown method
including a Request-URI with an emergency service URN in accordance with [69] or an emergency
number the E-CSCF shall:
1.
remove its own SIP URI from the topmost Route header;
2.
if the PSAP is the next hop, store the value of the icid parameter received in the P-ChargingVector header and remove the received information in the P-Charging-Vector header, else
keep the P-Charging-Vector if the next hop is a BGCF;
3.
if the PSAP is the next hop remove the P-Charging-Function-Addresses headers, if present,
else keep the P-Charging-Function-Addresses headers if the next hop is or an BGCF;
4.
if a BGCF is the next hop insert a type 2 orig-ioi parameter into the P-Charging-Vector
header. The E-CSCF shall set the type 2 orig-ioi parameter to a value that identifies the
sending network. The E-CSCF shall not include the term-ioi parameter;
5.
get location information as
6.
–
geographical location information received as a location object from a message body
with the content type application/pidf+xml in accordance with [89]; and
–
location identifier as derived from the P-Access-Network-Info header, if available.
select, based on location information and optionally type of emergency service:
–
a PSAP connected to the IM CN subsystem network and add the PSAP URI to the
topmost Route header; or
NOTE 1: The E-CSCF conveys the P-Access-Network-Info header containing the location
identifier, if defined for the access type as specified in subclause 7.2A.4, to the PSAP.
–
a PSAP in the PSTN, add the BGCF URI to the topmost Route header and add a PSAP
URI in tel URI format to the Request-URI with an entry used in the PSTN/CS domain to
address the PSAP;
NOTE 2: The E-CSCF conveys the P-Access-Network-Info header containing the location
identifier, if defined for the access type as specified in subclause 7.2A.4, towards the MGCF.
NOTE 3: The E-CSCF can request location information and routing information from the
LRF. The E-CSCF can for example send the location identifier to LRF and LRF maps the
location identifier into the corresponding geographical location information that LRF sends to
E-CSCF. The LRF can invoke an RDF to convert the location information into a proper
PSAP/EC URI. Both the location information and the PSAP URI are returned to the ECSCF.
NOTE 4: The way the E-CSCF determines the next hop address when the PSAP address is a
tel URI is implementation dependent.
7.
if the E-CSCF receives a reference number from the LRF the E-CSCF shall include the
reference number in the P-Asserted-Identity header;
NOTE 5: The reference number is used in the communication between the PSAP and LRF.
8 Procedures Related to Establishment of IMS
Emergency Session
5
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
1
X.S0049-0 v1.0
8.
Void;
9.
create a Record-Route header containing its own SIP URI
2
3
4
5
10.
if the request is an INVITE request, save the Contact, Cseq and Record-Route header field
values received in the request such that the E-CSCF is able to release the session if needed;
and
11.
route the request based on SIP routing procedures.
6
7
8
9
10
NOTE 6: Depending on local operator policy, the E-CSCF has the capability to reject
requests relating to specific methods in accordance with RFC 3261 [26], as an alternative to
the functionality described above.
11
12
13
14
Upon receipt of an initial request for a dialog, a standalone transaction, or an unknown method, that
does not include a Request-URI with an emergency service URN or an emergency number, the ECSCF shall reject the call by sending a 403 (Forbidden) response.
15
16
17
When the E-CSCF receives the request containing the access-network-charging-info parameter in the
P-Charging-Vector, the E-CSCF shall store the access-network-charging-info parameter from the PCharging-Vector header. The E-CSCF shall retain access-network-charging-info parameter in the PCharging-Vector header.
18
19
20
21
22
When the E-CSCF receives any request or response (excluding ACK requests and CANCEL requests
and responses) related to a UE-originated dialog or standalone transaction, the E-CSCF may insert
previously saved values into P-Charging-Vector and P-Charging-Function-Addresses headers before
forwarding the message.
23
24
25
26
27
When the E-CSCF receives an INVITE request from the UE, the E-CSCF may require the periodic
refreshment of the session to avoid hung states in the E-CSCF. If the E-CSCF requires the session to
be refreshed, it shall apply the procedures described in RFC 4028 [58] clause 8.
28
29
30
31
NOTE 7: Requesting the session to be refreshed requires support by at least the UE or the PSAP
or MGCF. This functionality cannot automatically be granted, i.e., at least one of the involved
UAs needs to support it in order to make it work.
32
33
34
35
When the session is terminated, the E-CSCF may request the LRF to release the call record.
36
37
38
39
40
41
7
Extensions within the present document
42
43
44
7.6
3GPP2 IM CN subsystem XML body, version 1
45
46
47
48
49
50
51
52
53
54
55
7.6.1
General
This subclause describes the Document Type Definition that is applicable for the 3GPP2 IM CN
Subsystem XML body.
Any SIP User Agent or proxy may insert or remove the 3GPP2 IM CN subsystem XML body or parts
of it, as required, in any SIP message. The 3GPP2 IM CN subsystem XML body shall not be
forwarded outside a 3GPP2 network.
The associated MIME type with the 3GPP2 IMS XML body is “application/3gpp-ims+xml”.
56
57
58
59
55
Annex D
7.6.2
Document Type Definition
The Document Type Definition, according to XML syntax definitions, is defined in table 7.7.
Table 7.7: IM CN subsystem XML body, version 1 DTD
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:complexType name="tIMS3GPP">
<xs:choice>
<xs:element name="alternative-service" type="tAlternativeService"/>
<xs:element name="service-info" type="xs:string"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="tAlternativeService">
<xs:sequence>
<xs:element name="type" type="tType"/>
<xs:element name="action" type="tAction" minOccurs="0"/>
<xs:element name="reason" type="xs:string"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="tType">
<xs:sequence>
<xs:element name="emergency" minOccurs="0" maxOccurs="1">
<xs:complexType/>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="tAction">
<xs:sequence>
<xs:element name="emergency-registration" minOccurs="0" maxOccurs="1">
<xs:complexType/>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="ims-3gpp" type="tIMS3GPP"/>
</xs:schema>
7.6.3
DTD description
This subclause describes the elements of the IMS Document Type Definition as defined in table 7.7.
<ims-3gpp>: This is the root element of the IMS XML body. It shall always be present. The
version described in the present document is 1.
<service-info>: the transparent element received from the HSS for a particular trigger point are
placed within this optional element.
<alternative-service>: in the present document, the alternative service is used as a response for an
attempt to establish an emergency session within the IM CN subsystem. The element describes an
alternative service where the call should succeed. The alternative service is described by the type
of service information. A possible reason cause why an alternative service is suggested may be
included.
The <alternative-service> element contains a <type> element that indicates the type of
alternative service and an <action> element, an optional element.
8 Procedures Related to Establishment of IMS
Emergency Session
5
6
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
X.S0049-0 v1.0
The <type> element contains only the value “emergency” in the present document.
1
2
The <action> element contains only the value “emergency-registration” in the present
document.
3
4
5
The <reason> element contains an explanatory text with the reason why the session setup has
been redirected. A UE may use this information to give an indication to the user.
6
7
8
9
10
11
12
9
13
14
IP-Connectivity Access Network aspects
when connected to the IM CN subsystem
15
16
9.2.2
Handling of the IP-CAN
17
The UE shall ensure that appropriate resources are available for the media flow(s) on the IP-CAN(s)
related to a SIP-session. The means to ensure this is dependant on the characteristics for each IPCAN, and is described separately for each IP-CAN in question. The procedures related to
cdma2000®1 IP-CAN is specified in annex B. If a particular handling of the IP-CAN is needed for
emergency calls, this is described in the annex for each access technology.
18
19
20
21
22
23
24
25
26
27
28
29
Annex A (Normative): Profiles of IETF RFCs
for 3GPP2 usage
30
31
32
33
A.1
Profiles
34
Table A.3: Roles specific to this profile
35
36
Item
Roles
Reference
RFC status
Profile status
37
38
1
UE
5.1
n/a
o.1
2
P-CSCF
5.2
n/a
o.1
3
I-CSCF
5.3
n/a
o.1
I-CSCF (THIG)
5.3
n/a
c1
4
S-CSCF
5.4
n/a
o.1
5
BGCF
5.6
n/a
o.1
6
MGCF
5.5
n/a
o.1
7
AS
5.7
n/a
o.1
5.7.2
n/a
c2
39
40
41
42
43
3A
44
45
46
47
48
49
50
51
52
53
7A
AS acting as terminating UA, or redirect
server
54
55
56
57
58
59
1 cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the
Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a
registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
57
Annex D
Item
Roles
Reference
RFC status
Profile status
7B
AS acting as originating UA
5.7.3
n/a
c2
7C
AS acting as a SIP proxy
5.7.4
n/a
c2
7D
AS performing 3rd party call control
5.7.5
n/a
c2
8
MRFC
5.8
n/a
o.1
11
E-CSCF
5.11
n/a
o.1
c1:
c2:
o.1:
o.2:
IF A.3/3 THEN o ELSE x - - I-CSCF.
IF A.3/7 THEN o.2 ELSE n/a - - AS.
It is mandatory to support exactly one of these items.
It is mandatory to support at least one of these items.
NOTE: For the purposes of the present document it has been chosen to keep the specification simple by the tables
specifying only one role at a time. This does not preclude implementations providing two roles, but an entirely separate
assessment of the tables shall be made for each role.
A.2.2
A.2.2.2
Proxy role
Major capabilities
Table A.162: Major capabilities
Item
Does the implementation support
Reference
RFC status
Profile status
[26] 16
x
c27
Capabilities within main protocol
3
initiate session release?
4
stateless proxy behavior?
[26] 16.11
o.1
c28
5
stateful proxy behavior?
[26] 16.2
o.1
c29
6
forking of initial requests?
[26] 16.1
c1
c31
7
support of indication of TLS connections in the
Record-Route header on the upstream side?
[26] 16.7
o
n/a
8
support of indication TLS connections in the RecordRoute header on the downstream side?
[26] 16.7
o
n/a
[26] 20.28, 22.3
o
x
8A
authentication between UA and proxy?
9
insertion of date in requests and responses?
[26] 20.17
o
o
10
suppression or modification of alerting information
data?
[26] 20.4
o
o
11
reading the contents of the Require header before
proxying the request or response?
[26] 20.32
o
o
12
adding or modifying the contents of the Require
header before proxying the REGISTER request or
response
[26] 20.32
o
m
8 Procedures Related to Establishment of IMS
Emergency Session
5
8
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
Item
3
6
RFC status
Profile status
13
adding or modifying the contents of the Require
header before proxying the request or response for
methods other than REGISTER?
[26] 20.32
o
o
14
being able to insert itself in the subsequent
transactions in a dialog (record-routing)?
[26] 16.6
o
c2
15
the requirement to be able to use separate URIs in
the upstream direction and downstream direction
when record routing?
[26] 16.7
c3
c3
16
reading the contents of the Supported header before
proxying the response?
[26] 20.37
o
o
17
reading the contents of the Unsupported header
before proxying the 420 response to a REGISTER?
[26] 20.40
o
m
18
reading the contents of the Unsupported header
before proxying the 420 response to a method other
than REGISTER?
[26] 20.40
o
o
19
the inclusion of the Error-Info header in 3xx - 6xx
responses?
[26] 20.18
o
o
19A
reading the contents of the Organization header
before proxying the request or response?
[26] 20.25
o
o
19B
adding or concatenating the Organization header
before proxying the request or response?
[26] 20.25
o
o
19C
reading the contents of the Call-Info header before
proxying the request or response?
[26] 20.25
o
o
19D
adding or concatenating the Call-Info header before
proxying the request or response?
[26] 20.25
o
o
19E
delete Contact headers from 3xx responses prior to
relaying the response?
[26] 20
o
o
7
8
9
Reference
Capabilities within main protocol
4
5
Does the implementation support
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
Extensions
41
42
43
44
45
46
20
the SIP INFO method?
[25]
o
o
21
reliability of provisional responses in SIP?
[27]
o
i
22
the REFER method?
[36]
o
o
23
integration of resource management and SIP?
[30] [64]
o
i
24
the SIP UPDATE method?
[29]
c4
i
26
SIP extensions for media authorization?
[31]
o
c7
27
SIP specific event notification
[28]
o
i
28
the use of NOTIFY to establish a dialog
[28] 4.2
o
n/a
29
Session Initiation Protocol Extension Header Field
for Registering Non-Adjacent Contacts
[35]
o
c6
47
48
49
50
51
52
53
54
55
56
57
58
59
59
Annex D
Item
Does the implementation support
Reference
RFC status
Profile status
extensions to the Session Initiation Protocol (SIP)
for asserted identity within trusted networks
[34]
o
m
30A
act as first entity within the trust domain for asserted
identity
[34]
c5
c8
30B
act as subsequent entity within trust network that
can route outside the trust network
[34]
c5
c9
31
a privacy mechanism for the Session Initiation
Protocol (SIP)
[33]
o
m
31A
request of privacy by the inclusion of a Privacy
header
[33]
n/a
n/a
31B
application of privacy based on the received Privacy
header
[33]
c10
c12
31C
passing on of the Privacy header transparently
[33]
c10
c13
31D
application of the privacy option “header” such that
those headers which cannot be completely
expunged of identifying information without the
assistance of intermediaries are obscured?
[33] 5.1
x
x
31E
application of the privacy option “session” such that
anonymization for the session(s) initiated by this
message occurs?
[33] 5.2
n/a
n/a
31F
application of the privacy option “user” such that
user level privacy functions are provided by the
network?
[33] 5.3
n/a
n/a
31G
application of the privacy option “id” such that
privacy of the network asserted identity is provided
by the network?
[34] 7
c11
c12
32
Session Initiation Protocol Extension Header Field
for Service Route Discovery During Registration
[38]
o
c30
33
a messaging mechanism for the Session Initiation
Protocol (SIP)
[50]
o
m
34
Compressing the Session Initiation Protocol
[55]
o
c7
35
private header extensions to the session initiation
protocol for the 3rd-Generation Partnership Project
(3GPP)?
[52]
o
m
36
the P-Associated-URI header extension?
[52] 4.1
c14
c15
37
the P-Called-Party-ID header extension?
[52] 4.2
c14
c16
38
the P-Visited-Network-ID header extension?
[52] 4.3
c14
c17
Capabilities within main protocol
30
8 Procedures Related to Establishment of IMS
Emergency Session
6
0
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
Item
3
6
RFC status
Profile status
39
reading, or deleting the P-Visited-Network-ID header
before proxying the request or response?
[52] 4.3
c18
n/a
41
the P-Access-Network-Info header extension?
[52] 4.4
c14
c19
42
act as first entity within the trust domain for access
network information?
[52] 4.4
c20
c21
43
act as subsequent entity within trust network for
access network information that can route outside
the trust network?
[52] 4.4
c20
c22
44
the P-Charging-Function-Addresses header
extension?
[52] 4.5
c14
m
adding, deleting or reading the P-ChargingFunction-Addresses header before proxying the
request or response?
[52] 4.6
c25
c26
45
the P-Charging-Vector header extension?
[52] 4.6
c14
m
46
adding, deleting, reading or modifying the PCharging-Vector header before proxying the request
or response?
[52] 4.6
c23
c24
47
security mechanism agreement for the session
initiation protocol?
[48]
o
c7
48
the Reason header field for the session initiation
protocol
[34A]
o
o
49
an extension to the session initiation protocol for
symmetric response routing
[56A]
o
x
50
caller preferences for the session initiation protocol?
[56B]
c33
c33
7
8
Reference
Capabilities within main protocol
4
5
Does the implementation support
9
10
11
12
13
14
15
16
17
18
19
44A
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
50A
the proxy-directive within caller-preferences?
[56B] 9.1
o.4
o.4
50B
the cancel-directive within caller-preferences?
[56B] 9.1
o.4
o.4
50C
the fork-directive within caller-preferences?
[56B] 9.1
o.4
c32
50D
the recurse-directive within caller-preferences?
[56B] 9.1
o.4
o.4
50E
the parallel-directive within caller-preferences?
[56B] 9.1
o.4
c32
50F
the queue-directive within caller-preferences?
[56B] 9.1
o.4
o.4
39
40
41
42
43
44
45
46
47
48
49
51
an event state publication extension to the session
initiation protocol?
[70]
o
m
52
SIP session timer?
[58]
o
o
53
the SIP Referred-By mechanism?
[59]
o
o
54
the Session Inititation Protocol (SIP) “Replaces”
header?
[60]
o
o
55
the Session Inititation Protocol (SIP) “Join” header?
[61]
o
o
50
51
52
53
54
55
56
57
58
59
61
Annex D
Item
Does the implementation support
Reference
RFC status
Profile status
Capabilities within main protocol
56
the callee capabillities?
[62]
o
o
62
a uniform resouces name for services
[69]
n/a
c35
c1: IF A.162/5 THEN o ELSE n/a - - stateful proxy behavior.
c2: IF A.3/2 OR A.3/3A OR A.3/4 THEN m ELSE o - - P-CSCF, I-CSCF(THIG) or S-CSCF.
c3: IF (A.162/7 AND NOT A.162/8) OR (NOT A.162/7 AND A.162/8) THEN m ELSE IF A.162/14 THEN o ELSE n/a - TLS interworking with non-TLS else proxy insertion.
c4: IF A.162/23 THEN m ELSE o - - integration of resource management and SIP.
c5: IF A.162/30 THEN o ELSE n/a - - extensions to the Session Initiation Protocol (SIP) for asserted identity within
trusted networks.
c6: IF A.3/2 OR A.3/3A THEN m ELSE n/a - - P-CSCF or I-CSCF (THIG).
c7: IF A.3/2 THEN m ELSE n/a - - P-CSCF.
c8: IF A.3/2 AND A.162/30 THEN m ELSE n/a - - P-CSCF and extensions to the Session Initiation Protocol (SIP) for
asserted identity within trusted networks.
c9: IF A.3/2 AND A.162/30 THEN m ELSE IF A.3/7C AND A.162/30 THEN o ELSE n/a - - S-CSCF or AS acting as
proxy and extensions to the Session Initiation Protocol (SIP) for asserted identity within
trusted networks (NOTE).
c10: IF A.162/31 THEN o.2 ELSE n/a - - a privacy mechanism for the Session Initiation Protocol (SIP).
c11: IF A.162/31B THEN o ELSE x - - application of privacy based on the received Privacy header.
c12: IF A.162/31 AND A.3/4 THEN m ELSE n/a - - S-CSCF.
c13: IF A.162/31 AND (A.3/2 OR A.3/3 OR A.3/7C) THEN m ELSE n/a - - P-CSCF OR I-CSCF OR AS acting as a SIP
proxy.
c14: IF A.162/35 THEN o.3 ELSE n/a - - private header extensions to the session initiation protocol for the 3rdGeneration Partnership Project (3GPP).
c15: IF A.162/35 AND (A.3/2 OR A.3/3) THEN m THEN o ELSE n/a - - private header extensions to the session
initiation protocol for the 3rd-Generation Partnership Project (3GPP) and P-CSCF or I-CSCF.
c16: IF A.162/35 AND (A.3/2 OR A.3/3 OR A.3/4) THEN m ELSE n/a - - private header extensions to the session
initiation protocol for the 3rd-Generation Partnership Project (3GPP) and P-CSCF or I-CSCF
or S-CSCF.
c17: IF A.162/35 AND (A.3/2 OR A.3/3) THEN m ELSE n/a - - private header extensions to the session initiation
protocol for the 3rd-Generation Partnership Project (3GPP) and P-CSCF or I-CSCF.
c18: IF A.162/38 THEN o ELSE n/a - - the P-Visited-Network-ID header extension.
c19: IF A.162/35 AND (A.3/2 OR A.3.3 OR A.3/4 OR A.3/7 THEN m ELSE n/a - - private header extensions to the
session initiation protocol for the 3rd-Generation Partnership Project (3GPP) and P-CSCF, ICSCF, S-CSCF, AS acting as a proxy.
c20: IF A.162/41 THEN o ELSE n/a - - the P-Access-Network-Info header extension.
c21: IF A.162/41 AND A.3/2 THEN m ELSE n/a - - the P-Access-Network-Info header extension and P-CSCF.
8 Procedures Related to Establishment of IMS
Emergency Session
6
2
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
All-IP Network Emergency Call Support
X.S0049-0 v1.0
1
2
Item
Does the implementation support
3
6
7
RFC status
Profile status
Capabilities within main protocol
4
5
Reference
c22: IF A.162/41 AND A.3/4 THEN m ELSE n/a - - the P-Access-Network-Info header extension and S-CSCF.
c23: IF A.162/45 THEN o ELSE n/a - - the P-Charging-Vector header extension.
8
9
10
11
12
c24: IF A.162/45 THEN m ELSE n/a - - the P-Charging-Vector header extension.
c25: IF A.162/44 THEN o ELSE n/a - - the P-Charging-Function-Addresses header extension.
c26: IF A.162/44 THEN m ELSE n/a - - the P-Charging-Function Addresses header extension.
13
14
15
16
17
c27: IF A.3/2 OR A.3/4 THEN m ELSE x - - P-CSCF or S-CSCF.
c28: IF A.3/2 OR A.3/4 OR A.3/6 then m ELSE o - - P-CSCF or S-CSCF of MGCF.
c29: IF A.3/2 OR A.3/4 OR A.3/6 then o ELSE m - - P-CSCF or S-CSCF of MGCF.
18
19
20
21
22
c30: IF A.3/2 o ELSE i - - P-CSCF.
c31: IF A.3/4 THEN m ELSE x - - S-CSCF.
c32: IF A.3/4 THEN m ELSE o.4 - - S-CSCF.
23
24
25
26
27
28
c33: IF A.162/50A OR A.162/50B OR A.162/50C OR A.162/50D OR A.162/50E OR A.162/50F THEN m ELSE n/a - support of any directives within caller preferences for the session initiation protocol.
c35: IF A.3/2 OR A.3/11 THEN m ELSE n/a - - P-CSCF, E-CSCF.
o.1: It is mandatory to support at least one of these items.
29
30
31
32
33
o.2: It is mandatory to support at least one of these items.
o.3: It is mandatory to support at least one of these items.
o.4: At least one of these capabilities is supported.
34
35
36
37
38
NOTE: An AS acting as a proxy may be outside the trust domain, and therefore not able to support the capability for that
reason; in this case it is perfectly reasonable for the header to be passed on transparently, as specified in the PDU parts
of the profile.
39
40
41
42
43
44
45
46
47
Annex B (normative): IP-Connectivity Access
Network specific concepts when using
cdma2000 to access IM CN subsystem
48
49
50
B.3.1
Procedures at the UE
B.3.1.1
Additional coding rules for P-Access-Network-Info header
51
52
53
54
55
56
57
58
59
START OF CHANGE
3) if the access type field is set to “3GPP2-1X-HRPD”, a ci-3gpp2 parameter set to the ASCII representation of the
hexadecimal value of the string obtained by the concatenation of Sector ID (128 bits) Subnet length (8 bits) (see
[81]) and CarrierId [X.S0049] in the specified order. The length of the ci-3gpp2 parameter shall be 40
63
Annex D
hexadecimal characters. The hexadecimal characters (A through F) shall be coded using the uppercase ASCII
characters.
EXAMPLE:
If the Sector ID = 0x12341234123412341234123412341234, Subnet length = 0x11, and the
CarrierId=0x555555444444, the ci-3gpp2 value is set to the string
“1234123412341234123412341234123411555555444444”.
END OF CHANGE
START OF CHANGE
B.2.2.4
Void
B.2.2.5
Void
B.2.2.6
Emergency service
When establishing an HRPD session to perform emergency registration, based on the conditions in
subclause 5.1.6.1 of this specification, the UE shall follow the procedures defined in Annex A of
X.S0049.
In order to find out whether the UE is attached to the home network or to the visited network, the UE
shall compare the Carrier ID values obtained per Annex C of X.S0049. If the Carrier ID of the
network the UE is attached to does not match with the provisioned Carrier ID, then for the purpose of
emergency calls in the IM CN subsystem the UE shall consider to be attached to a visited network.
END OF CHANGE
B.3.2
B.3.2.1
Procedures at the P-CSCF
Detecting requests destined for a PSAP
In order to determine whether the initial request for a dialog or standalone transaction or an unknown
method is destined for a PSAP the P-CSCF shall compare the Carrier ID field received in the PAccess-Network-Info header against a list of supported Carrier IDs to determine if the call is routable.
8 Procedures Related to Establishment of IMS
Emergency Session
6
4
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.
Error! Use the Home tab to apply Heading 2
nb to the text that you want to appear here.