Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TR 23.869  Word version:  9.0.0

Top   Top   None   None   Next
1…   5…

 

0  IntroductionWord‑p. 6

This Technical Report documents functionality being specified to support IMS Emergency Calls over GPRS and EPS. Because IMS emergency call support is expected to impact several functional areas, this TR will describe the functionality as it is being developed. Once a functional component is complete the appropriate Technical Specifications will be updated accordingly.

1  ScopeWord‑p. 7

1.1  Objective

This TR has been created for the purpose of having a single source for documenting the GPRS and EPS enhancements to support emergency calls. As solutions to particular aspects are agreed, CRs will be created for the associated TSs. This TR is not a study. The IMS Emergency Services study is available in TR 23.867 [5].
The present document includes the following:
  • Functionality needed to meet the requirements as defined in TS 22.101 and TS 23.167 for handling IMS emergency calls over the GPRS using GERAN and UTRAN access both in the case where the UE is in normal service mode (e.g., UE has sufficient credentials and is authorized to receive the service) and where the UE is in limited service mode (e.g. the UE does not have sufficient credentials or is not authorized to receive GPRS service).
  • Functionality needed to meet the requirements as defined in TS 22.101 and TS 23.167 for handling IMS emergency calls over the EPS using E-UTRAN access both in the case where the UE is in normal service mode (e.g., UE has sufficient credentials and is authorized to receive the service) and where the UE is in limited service mode (e.g. the UE does not have sufficient credentials or is not authorized to receive EPS service).
  • EPS functionality needed to support IMS emergency call handovers between 3GPP accesses and between 3GPP and non-3GPP accesses.
  • EPS functionality to support of IMS emergency calls that complies with applicable requirements for provision of location information as defined in TS 23.167.
Up

2  Background

GPRS Emergency Services procedures were partially complete in Release 7. A decision was made at SA#36 to remove GPRS Emergency Services support from Release 7 so that a complete solution could be developed in Release 9 (see clause 9.17 of the SA#36 meeting report [4]). The functionality provided support for valid subscribers initiating an IMS Emergency Call over UTRAN while in their home network or while roaming. The GPRS enhancements included:
  1. Definition of an Emergency APN: A UE that needs to do IMS emergency registration (for example always in VPLMN) shall start by requesting a PDP context with the emergency APN in GPRS. The emergency APN is the basic part of the Rel-7 solution, because it enables IMS emergency services with local break-out for roaming UEs in VPLMN. In a home network, a PDP context to an emergency APN also provides a way for GPRS to identify a session for emergency services so that special GPRS handling, that may override subscription, can be allowed.(e.g., QoS and ARP). This capability is critical for the most basic solution that could be supported and should be the highest priority functionality to be specified.
  2. UE QoS indication of emergency: The UE shall include an emergency indication in the UMTS bearer QoS IE when establishing or modifying the PDP context used for the emergency service. It has been determined that this is not needed. QoS can be provided by either establishment of the emergency PDP context or through PCC.
  3. QoS Negotiation: SGSN handling of the ARP is modified to not re-verify the value received from the GGSN against the subscription. This allows the GGSN to change the ARP for emergency services to a high priority so the call will not be pre-empted. This is functionality is important for overriding subscription in order to override ARP subscription limits.
  4. Network support indication: The SGSN shall indicate in the Attach Accept and RAU Accept messages whether GPRS emergency functions are supported in the network. This indicator improves functional efficiency.
Up

3  ReferencesWord‑p. 8

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.
  • 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 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.
[1]
TR 21.905: "Vocabulary for 3GPP Specifications".
[2]
TS 22.101: "Service aspects; Service principles".
[3]
TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions".
[4]
3GPP TSG SA#36 meeting report: http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_36/Report.
[5]
TR 23.867: "Internet Protocol (IP) based IP Multimedia Subsystem (IMS) emergency sessions".
[6]
3GPP TSG SA#36 TD SP-070427 by Nokia/NSN: "IMS emergency services using GPRS access in Rel 7".
[7]
TS 23.167: v7.4.0, 2007-03-20 "IP Multimedia Subsystem (IMS) emergency sessions".
[8]
3GPP TSG SA#37 meeting report: http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_37/Report.
[9]
TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2".
[10]
TS 23.107: "Quality of Service (QoS) concept and architecture".
[11]
TS 23.221: "Architectural requirements".
[12]
TS 23.228: "IP Multimedia Subsystem (IMS); Stage 2".
[13]
TS 23.203: "Policy and charging control architecture".
[14]
TS 23.401: "General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access".
[15]
TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode".
[16]
OMA AD SUPL: "Secure User Plane Location Architecture", http://www.openmobileallieance.org.
[17]
TR 23.891: "Evaluation of LCS Control Plane Solutions for EPS".
[18]
TS 25.413: "UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling".
[19]
TS 36.413: "Evolved Universal Terrestrial Radio Access (E-UTRA); S1 Application Protocol (S1AP)".
[20]
TS 23.402: "Architecture enhancements for non-3GPP accesses".
[21]
3GPP2 X.S0060, "HRPD Support for Emergency Services", http://www.3gpp2.org.
Up

4  Definitions and abbreviationsWord‑p. 9

4.1  Definitions

For the purposes of the present document, the terms and definitions given in TR 21.905, TS 23.167 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 or TS 23.167.
Limited Service Mode:
The UE state that only allows emergency calls. This state is entered when a UE is unable to find a suitable cell to camp on, or the SIM is not inserted, or if it receives certain responses to a Location Registration request (e.g., "illegal UE"), it attempts to camp on a cell irrespective of the PLMN identity. See TS 23.122.
Invalid UICC:
A UE that does not have a UICC or a UE with an IMSI that does not have corresponding subscription information in the HLR.
Local regulation categories:
  1. Normal Mode: Only subscribers are supported. Meaning, an emergency call is treated by the network as any other call regarding subscription. The UE must be authenticated and authorized for service in their current location in order to gain network access for emergency calling.
  2. Valid IMSI limited: Only subscribers with a valid IMSI that can be authenticated are supported by the network. They may not be authorized for PS service in their current location but are allowed to over ride subscription restrictions to initiate an IMS emergency call.
  3. All Emergency Calls (All-EmCalls): Regulation requires all UEs to be able to access the network to initiate an emergency call, regardless of authentication or authorization status. Therefore, even a UE without valid credentials should be served (e.g. UE's without an UICC, UE's that received "IMSI unknown in HLR" or "PLMN not allowed" rejects).
Up

4.2  Abbreviations

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905.

Up   Top   ToC