It shall be possible to establish an emergency speech call or GTT  call (subject to national requirements). The term 'Emergency call' henceforth refers to speech calls, and GTT Emergency calls if applicable. The term "other media" henceforth refers to media other than speech and GTT. Support of other media types during an emergency call when the IM CN subsystem is used is referred to as 'IMS Multimedia Emergency Session' (MES) and is specified in subclause 10.4.2. Emergency calls will be routed to the emergency services in accordance with national regulations for where the subscriber is located. This may be based upon one or more default emergency call numbers stored in the ME. It shall be allowed to establish an emergency call without the need to dial a dedicated number to avoid the mis-connection in roaming case, such as menu, by use of a 'red button', or a linkage to a car air bag control. Emergency calls shall be supported by the UE without a SIM/USIM/ISIM being present. No other type shall be accepted without a SIM/USIM/ISIM than emergency calls and subject to operator policy and regional regulations, restricted local operator service access.
Emergency calls shall be supported by UEs that are subject to service restrictions, e.g. for UEs camping on a cell in a forbidden PLMN or in a forbidden LA (see TS 22.011), or on a CSG cell without the subscriber being a member of that CSG (see TS 22.220). Such emergency calls shall be accepted by the network if required by local regulation.
The Emergency service is required only if the UE supports voice.
It shall be possible to initiate emergency calls to different emergency call centres, depending on the type of emergency. The following types of emergency calls shall be possible:
Manually Initiated eCall (MIeC)
Automatically Initiated eCall (AIeC)
When a SIM/USIM is present, subscriber specific emergency call set-up MMI shall be provided. The Home Environment operator shall specify preferred emergency call numbers (e.g. 999 for UK citizens or 110, 118 and 119 for Japanese citizens). These emergency call numbers shall be stored in the SIM/USIM and the ME shall read this and use any entry of these digits to set up an emergency call. It shall be possible to store more than one instance of this field.
It shall be possible to tie any emergency call number to any single emergency call type or to any combination of emergency call types. The association between emergency call numbers and emergency call type shall be able to be programmed by the Home Environment operator into the SIM/USIM.
Police and Fire Brigade (Greek cities)
Ambulance and Fire Brigade (Belgium)
Police and Ambulance (Italy)
General emergency call, all categories (Sweden)
Fire Brigade (Italy)
If the UE does not recognise the emergency call numbers but the serving network recognises the dialled number as an emergency call number used in the country, a normal call set up shall take place over the radio interface and after the serving network has recognised the emergency number the call shall be routed as an emergency call.
The user friendly MMI that specifies the type of emergency call directly (e.g. menu) should be supported for use in any (i.e. home or visited) PLMN to avoid the misconnection in roaming case. This shall be allowed both with and without SIM/USIM being present.
When emergency call establishment is initiated, the emergency call type shall be sent by the UE if it is available.
The serving network may download emergency call numbers to the UE in order to ensure that local emergency call numbers are known to the UE. The UE shall regard these emergency numbers as valid in that country only (as identified by the MCC) and shall discard them when a new country is entered.
If permitted by local regulation, it shall be possible for the user to prevent the sending of his public user identifiers and the location information to the PSAP (i.e. emergency response centre).
Emergency calls over WLAN shall be supported as above with the following caveats:
The UE issues an Emergency session over WLAN access to EPC only when 3GPP access for emergency call is not possible or available (e.g. no 3GPP coverage).
UEs shall only be able to establish an Emergency session over WLAN when the UE has been provisioned with the WLAN access parameters.
Service continuity for an Emergency voice call moving from 3GPP access CS domain to WLAN access IMS domain is not supported.
The level of security should not be less than that which is currently applied to authenticated and unauthenticated CS or IMS emergency calls.
Emergency call numbers downloaded to the UE over WLAN from untrusted sources shall not be used by the UE.
NOTE 5: TS 23.402 establishes when WLAN is trusted or not.
Subject to local 3GPP operator policy, the UE may use additional emergency call number(s) received via WLAN access for emergency calls via 3GPP access or WLAN access, while in the country for which the numbers were received.
The ME shall identify an emergency number dialled by the end user as a valid emergency number and initiate emergency call establishment if it occurs under one or more of the following conditions. If it occurs outside of the following conditions, the ME should not initiate emergency call establishment but normal call establishment. Emergency number identification takes place before and takes precedence over any other (e.g. supplementary service related) number analysis.
112 and 911 shall always be available. These numbers shall be stored on the ME.
Any emergency call number stored on a SIM/USIM when the SIM/USIM is present.
000, 08, 110, 999, 118 and 119 when a SIM/USIM is not present. These numbers shall be stored on the ME.
Additional emergency call numbers that may have been downloaded by the serving network when the SIM/USIM is present.
A UE that is connected to a domain in which it is possible for the UE to make non emergency calls using the particular media requested by the user, shall use that domain to attempt an emergency call unless serving network policy (based on regulatory requirements and operator needs) requires the UE, including an unauthenticated UE, to attempt the emergency call on a specific domain first.
If the UE is connected to more than one domain in which it is possible for the UE to make non emergency calls using the particular media requested by the user, the UE shall attempt an emergency call on the same domain it would use to originate a non-emergency call using the same media unless serving network policy (based on regulatory requirements and operator needs) requires the UE, including an unauthenticated UE, to attempt the emergency call on a specific domain first.
In the case where an emergency call attempt by a UE fails, the UE should automatically make a second attempt on the other domain if the UE supports it.
If the user aborts the emergency call setup during the subsequent automatic attempt and immediately tries to set up an emergency call again, then the UE shall immediately attempt in the domain in which the user aborted the emergency call.
The following applies in addition to 10.1.2.1.
If an emergency call attempt that includes a request for both (i) voice and/or GTT and (ii) other media cannot be supported or fails in all connected access types in the PS CN domain, the UE shall attempt the emergency call in the CS domain if available and shall only include the request for voice and/or GTT.
Subject to local/regional regulations the network shall support a call-back from a PSAP.
It shall be possible to supply the user's Directory Number/MSISDN/SIP URI as the CLI to the PSAP to facilitate call-back. The CLI used on call-back shall allow the PSAP to contact the same terminal that originated the emergency call.
If the incoming call can be identified by the core network as a call-back to an emergency call (i.e. coming from a PSAP) then supplementary services at the terminating party shall be handled as described in TS 22.173 for Multimedia Telephony (e.g. Communication Diversion, Communication Hold, Communication Barring).
A call-back may be attempted for a period of time defined by local regulations after the emergency call release. In case of a UE in limited service state, call-back is not required.
A CS CN Domain shall support the emergency call teleservice as defined in TS 22.003 (TS12).
If a UE supports TS11 (Telephony) , then it shall also support TS12 (Emergency Calls) . It shall be possible to set up emergency calls initiated by an emergency call number.
The IM CN subsystem shall support IMS emergency calls. It shall be possible to set up emergency calls initiated by an emergency call number.
If a UE supports IMS Multimedia Telephony service with speech media as specified in TS 22.173 via an access network, then it shall also support IMS emergency calls via that access network.
Subject to the regulatory requirement, the IM CN subsystem shall be able to unambiguously identify each emergency service defined in the national numbering plan for the country in which the UE is located.
In accordance with national regulations for where the subscriber is located, if the UE does not recognise a dialled number as an emergency call number but the IM CN where the subscriber is located does recognise the dialled number as an emergency call number (e.g. a number used in the local emergency numbering plan) then the call shall be routed as an emergency call indicating the type of emergency service to the correct PSAP. Subject to operator setting the call may be prioritized.
The serving network may download emergency call numbers and emergency call types, together with a validity indication of this list, for use in the IM CN subsystem so that local emergency call numbers are made known to the UE . Depending on the validity indication, the UE shall regard these emergency numbers and emergency call types as valid in that country (as identified by the MCC) and shall discard them when a new country is entered , or the UE shall regard these emergency numbers and emergency call types as valid in that PLMN (as identified by the MCC and MNC) and shall discard them when the UE enters a new PLMN.
Emergency calls may be initiated using a private numbering plan .
Emergency calls may be initiated by a service when requested by the user.
An emergency call shall take precedence over any other services a UE may be engaged in, if required by local regulation.
Emergency calls from an unauthenticated UE (as far as the IM CN is concerned) shall be supported by the IM CN subsystem, if required by local regulation.
Subject to regulatory requirements, when UEs must be authenticated, both the network and the UE shall support the same authentication and security methods that are used for non-emergency sessions.
For IMS emergency calls towards IP PSAPs, other media types may be supported by the UE and the IMS, subject to regulatory requirements.
The media types that may be supported during an IMS MES include:
Real time video (simplex, full duplex), synchronized with speech if present;
Session mode text-based instant messaging;
Video clip sharing, picture sharing, audio clip sharing;
Real-Time Text .
To avoid interworking issues, a UE and IMS that supports text based instant messaging shall support a common session mode text-based instant messaging protocol.
IMS MES does not include support for legacy store and forward messaging such as the Short Messaging Service (SMS).
Calls from non-human associated devices (e.g. fire alarms) are outside the scope of this specification.
Adding, removing and modifying individual media to/from an IMS MES shall be supported.
An IMS MES is not a subscription service. A UE capable of IMS emergency calls and capable of supporting the other media types should also be able to support initiation of an IMSMES.
An IMS MES from an unauthenticated UE (as far as the IM CN is concerned) shall be supported by the IM CN subsystem, if required by local regulation.
IMS MES shall be supported by UEs that are subject to service restrictions, e.g. for UEs camping on a cell in a forbidden PLMN or in a forbidden LA (see TS 22.011), or on a CSG cell without the subscriber being a member of that CSG (see TS 22.220). Such IMS MES shall be accepted by the network if required by local regulation.
An IMS MES shall support providing the location of the UE, in a manner similar to IMS emergency voice calls.
An IMS UE that supports IMS MES shall identify an emergency number dialled by the end user as a valid emergency number utilizing the same mechanisms as used for IMS emergency voice calls as defined in subclause 10.1.1.
An originating network and UE may support some or all of these other media types, and support of any specific media by an originating network or UE may be subject to regulatory requirements.
Voice call continuity per clause 21 shall be supported when a UE with an active IMS MES with voice and other media moves out of IMS voice coverage and voice call continuity is supported by the UE and network. The remaining media (i.e. voice call) then becomes a CS emergency call e.g. TS12 call for 3GPP systems as defined in TS 22.003.
Other media shall be dropped when a UE with an active IMS MES moves out of IMS voice coverage, irrespective of whether or not there is an active voice session.
When IMS MES are supported by the UE, the following apply:
An IMS UE that supports IMS MES shall also support IMS emergency voice calls.
Once a UE is aware that an IMS MES has been initiated, the UE shall be able to (subject to user configuration) avoid drawing unnecessary attention to the user (e.g., playing audible tones or flashing brightly) and should confirm this to the user in as private a manner as is reasonable e.g. using text on the screen or audio if headphones are already connected. UE behaviour in an IMS MES may need to be different relative to the normal configuration.
The UE should clearly differentiate IMS emergency session-mode text based instant messaging from IMS non-emergency session-mode text based instant messaging on the user display.
The IMS UE supporting video transfer during an IMS MES should be able to deliver recorded media in a form that allows progressive playback. (It is desirable that all pre-recorded media sent during an emergency session be progressively viewable.)
When an IP PSAP attempts to add additional media to an existing IMS MES, the user shall be made aware of this. When additional media is requested by the PSAP, the user shall be able to permit or deny it.
The UE shall provide an indication to the user for each requested media, whether it was successfully or unsuccessfully established.
Further notifications of added and removed media shall be indicated to the user while the IMS MES is active.
If none of the media requested by the UE is successfully established, the IMS MES will fail and an IMS MES failure indication shall be provided to the user.
In handover of an IMS MES where other media is dropped when IMS MES is not supported, the UE shall indicate to the end user that the other media is not supported in this area.
The following requirements for IMS emergency voice calls also apply when an IMS MES is supported by the UE:
An IMS UE that supports IMS MES shall indicate to the network that the call is an IMS emergency call as is done for an IMS emergency voice call.
An IMS UE that supports IMS MES shall be able to receive an IMS call-back from a PSAP per clause 10.1.3 with voice, GTT or other media per clause 10.4.2.1.
An IMS UE that supports MES shall utilize the same trust and security mechanisms for the other media as utilized for an IMS emergency voice call.
When roaming, a UE shall originate an IMS MES in the serving network in the same manner as for IMS emergency voice calls.
When an IMS MES is enabled by the originating network, the following apply:
Other media shall only be supported in packet-based networks that support IMS emergency voice calls.
The originating network shall deliver all media to the same IP PSAP throughout the duration of the IMS MES.
The network shall indicate to the UE, for each requested media, whether it was successfully or unsuccessfully established.
Further notification of added and removed media shall be provided to the UE while the IMS MES is active.
If none of the media requested by the UE is successfully established, the IMS MES will fail and an IMS MES failure indication will be provided to the UE.
The following requirements for IMS emergency voice calls also apply when IMS MES is supported by the network:
Subject to regional regulatory requirements, the network shall be able to authenticate the UE using the same procedures as for IMS emergency voice calls.
The originating network shall provide the capability to enable an IMS UE supporting IMS MES to obtain local emergency numbers or other emergency address(es) (e.g. destination address) utilizing the same mechanism as used for IMS emergency voice calls.
An IMS MES shall be provided in the local serving network.
For an IMS MES, any kind of emergency addressing (e.g. SIP URIs, Tel URIs) and special indications for emergency sessions shall be treated in the same manner as IMS emergency voice calls.
The originating network should detect all IMS MESs regardless of the UE emergency call indication. According to operator policy, the originating network may either inform the UE to enable re-origination as an IMS MES or support origination of the initial call.
The originating network shall be responsible for routing the IMS MES towards the appropriate PSAP (e.g., based on emergency service type, location, or policy).
The network shall be able to provide integrity protection, and/or privacy for other media similar to that provided for IMS emergency voice calls.
An IMS MES shall utilize the same priority mechanisms as IMS emergency voice calls.
Detailed log records of the IMS MES shall be generated by the originating network in a similar manner to IMS emergency voice calls and subject to regulatory requirements.
All media content within the IMS MES shall be carried with an indication of the source, in a similar manner as for IMS emergency voice calls.
National regulations may require wireless networks to provide the emergency caller's location. This requirement typically overrides the caller's right to privacy with respect to their location being revealed, but remains in effect only as long as the authorities need to determine the caller's location. The interpretation of the duration of this privacy override may also be different, subject to national regulation. For example, some countries require location to be available from the wireless network only while the call is up, while others may allow PSAP's to unilaterally decide how long the location must be made available.
Therefore, the requirement for providing location availability is to allow the network to support providing a mobile caller's location to the authorities for as long as required by the national regulation in force for that network.
Emergency calls may be supplemented with emergency related data . Typically this data enables the accurate geographic location of a manually or automatically activated emergency calling device e.g. an in vehicle system (IVS), to be provided to the Public Safety Answering Point (PSAP).
The following requirements apply to UEs designed to be able to perform eCalls and to networks supporting eCall:
The data may be sent prior to, in parallel with, or at the start of the voice component of an eCall.
Should the PSAP request additional data then this may be possible during the established eCall.
The realisation of the transfer of data during an eCall shall minimise changes to the originating and transit networks.
Both the voice and data components of the eCall shall be routed to the same PSAP or designated emergency call centre.
The transmission of the data shall be acknowledged and, if necessary, data shall be retransmitted.
The UE shall indicate at call setup if the emergency call will carry supplementary data, i.e. is an eCall.
UEs designed to be able to perform eCalls and configured to only perform eCalls (eCall only mode) shall comply with the following additional requirements:
The UE shall not perform mobility management procedures, including registration on a PLMN, except when attempting to initiate and during an eCall, or to initiate a test or reconfiguration of the terminal upon request from the user.
For UEs that have the ability to be called back by the PSAP, the UE shall be capable to continue mobility management procedures for a limited duration following the termination of the eCall.
The UE shall contain an USIM application.
In the case where the user subscribes to other services provided by the PLMN, it shall be possible for the network operator to reconfigure the UE so that it can access the subscribed services.
It shall be possible for the user of the UE to change network operator/service provider (i.e. to use a different USIM) or for the subscriber to modify the existing subscription used with the UE.
It shall be possible for the UE upon request from the user to initiate a call to an operator designated non-emergency MSISDN for the purpose of accessing test and terminal reconfiguration services.
Additional national and regional requirements are as specified in Annex A.
Supplementary services that interrupt or divert the media path between a PSAP and the end device shall be handled as specified in TS 22.173 (e.g. Communication Hold) for Multimedia Telephony. No such Supplementary Services are applicable to CS Emergency Calls (TS12) according to TS 22.004.
A MUSIM UE shall be able to select a USIM to originate an emergency call in the following priority:
USIM in normal service
USIM in limited service state
The MUSIM UE shall avoid interruptions of emergency call procedures of one USIM by other services of other USIM.
Subject to regulatory requirements, call-back requirements defined in clause 10.1.3 apply to a MUSIM UE.