The UE can establish media streams that belong to different SIP sessions on the same tunnel when accessing the EPC via untrusted WLAN. During establishment of a session, the UE establishes data streams(s) for media related to the session. When using untrusted WLAN IP access via S2c to access the EPC, such data stream(s) may result in activation of additional IPsec ESP security associations (tunnels). If the capabilities of the originating UE, or operator policy at the ePDG prevents the originating UE from establishment of additional IPsec ESP security associations (tunnels) according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524, the UE will not establish such grouping of media streams. Instead, the originating UE shall negotiate media parameters for the session according to RFC 3264. If the capabilities of the terminating UE or operator policy at the ePDG prevents the originating UE from establishment of additional IPsec ESP security associations (tunnels) according to the media grouping attributes given by the P-CSCF in accordance with RFC 3524, the UE will not establish such grouping of media streams. Instead, the terminating UE shall handle such SDP offers in accordance with RFC 3388. The UE can receive a media authorization token in the P-Media-Authorization header field from the P-CSCF according to RFC 3313. If a media authorization token is received in the P-Media-Authorization header field when a SIP session is initiated, the UE shall reuse the existing tunnel and ignore the media authorization token.

The tunnel modification procedure for the UE shall follow the procedures specified in TS 24.302. If the UE supports the Fixed Access Broadband interworking, the modification of tunnel specified in TS 24.139 shall be applied.

The UE shall follow the procedure specified in TS 24.302 for the modification of tunnel. If the UE supports the Fixed Access Broadband interworking, the modification of tunnel specified in TS 24.139 shall be applied. If the UE attaches to the EPC via S2b using untrusted WLAN IP access, and IKEv2 multiple bearer PDN connectivity is used in the PDN connection according to TS 24.302, then:

1. if:
   1. an additional IPSec ESP tunnel is established according to TS 24.302; or
   2. an IPSec ESP tunnel is modified according to TS 24.302;
   the UE shall, based on the information contained in the TFT Notify payload, correlate the media IPSec ESP tunnel with SDP media descriptions of a currently ongoing SIP session establishment or SIP session modification.

Not applicable.

Since the UE is unable to perform bearer modification, forked responses place no special requirements on the UE.

Not applicable.

In this release of the specification, a WLAN, conforming to the requirements in this annex, defines emergency bearers. Emergency session is supported over the WLAN access if the UE has failed or has not been able to use 3GPP access to set up an emergency session as described in TS 23.167 annex J. IMS emergency session is also supported for UEs with unavailable IMSI (i.e. a UE without USIM) or unauthenticated IMSI. Some jurisdictions allow emergency calls to be made when the UE does not contain an ISIM or USIM, or where the credentials are not accepted. When the UE is attached over a WLAN access and detects an emergency call attempt, if the UE supports the emerg-non3gpp timer defined in Table 7.8.1, the UE shall start the emerg-non3gpp timer when starting a domain selection searching for a 3GPP access usable to establish an emergency call. The UE shall stop the timer when a 3GPP access supporting emergency call is found. When the emerg-non3gpp timer expires, the UE shall consider that it has failed to use 3GPP access to setup the emergency call and shall attempt to setup the emergency call over the available WLAN access. The UE may support being configured for the emerg-non3gpp timer using one or more of the following methods:

1. the Timer_Emerg_non3gpp leaf of the EFIMSConfigData file described in TS 31.102;
2. the Timer_Emerg_non3gpp leaf of the EFIMSConfigData file described in TS 31.103; and
3. the Timer_Emerg_non3gpp leaf of TS 24.167.

EPC procedures for emergency session using WLAN are defined for both trusted WLAN access via S2a, depending on the TWAN usage mode, and untrusted WLAN access via S2b to access EPC. When the IM CN subsystem is selected as the domain for the emergency call attempt, and the UE uses:

• untrusted WLAN access via S2b, the UE determines that the EPC supports emergency bearer services by selecting or using an ePDG that has indicated its capability of support for emergency services, as specified in subclause 7.2.1A of TS 24.302; or
• trusted WLAN access via S2a, the UE determines that the EPC, accessed in usage modes multi-connection mode or single-connection mode, supports emergency bearer services if the CONNECTION_MODE_CAPABILITY item in the EAP-Request/AKA'-Challenge message indicates support of emergency services, as specified in TS 24.302.

When the IM CN subsystem is selected as the domain for the emergency call attempt, and the UE uses untrusted WLAN access via S2b, the UE determines whether it is currently attached to its home operator's network (e.g. HPLMN) or not (e.g. VPLMN) after it has determined that the core network supports emergency bearer services. When establishing an IMS emergency session using trusted WLAN access via S2a, the UE shall establish an IMS emergency session over trusted WLAN access depending on the usage mode used to access EPC. When using the usage mode single-connection mode, subclause 6.4.2.6.2A of TS 24.302 applies. When using the usage mode multi-connection mode, subclause 6.4.2.6.3A of TS 24.302 applies. The procedures for attaching to the EPC via S2a using a trusted WLAN IP access, as described in subclause R.2.2.1 of this specification apply accordingly. When establishing an IMS emergency session using untrusted WLAN access via S2b, the UE shall establish an IMS emergency session over untrusted non-3GPP access as specified in TS 24.302. The procedures for attaching to the EPC via S2b using untrusted WLAN IP access, as described in subclause R.2.2.1 of this specification apply accordingly. If the ME is equipped with a UICC, in order to find out whether the UE is attached to the home PLMN or to the visited PLMN, the UE shall compare the MCC and MNC values derived from its IMSI with the MCC and MNC of the PLMN the UE is attached to. If the MCC and MNC of the PLMN the UE is attached to do not match with the MCC and MNC derived from the IMSI, then for the purposes of emergency calls in the IM CN subsystem the UE shall consider to be attached to a VPLMN. If the ME is not equipped with a UICC, the procedure to find d out whether the UE is attached to the home PLMN or to the visited PLMN for the purpose of emergency calls in the IM CN subsystem, is implementation specific. If the UE detected an emergency number, the UE subsequently uses a different PLMN than the PLMN from which the UE received the last Extended Local Emergency Number List:

• the dialled number is not stored in the ME, in the USIM and in the Local Emergency Number List;

then:

1. if the UE supports provision and handling of local emergency numbers as defined in TS 24.302, the UE has received the local emergency numbers using any of the methods defined in subclause 4.7 in TS 24.302, the dialled number matches a received local emergency number, then the UE derives a URN as defined in TS 24.302 or using the procedures in subclause R.2.2.6.1A, depending on the method used to provision the local emergency number;
2. otherwise, the UE shall attempt UE procedures for SIP that relate to emergency using emergency service URN "urn:service:sos".

If the dialled number is equal to a local emergency number stored in the Extended Local Emergency Number List (as defined in TS 24.301), then the UE shall recognize such a number as for an emergency call and:

• if the dialled number is equal to an emergency number stored in the ME, or in the USIM, then the UE shall perform either procedures in the subclause R.2.2.6.1B or the procedures in subclause R.2.2.6.1A; and
• if the dialled number in not equal to an emergency number stored in the ME, or in the USIM, then the UE shall perform procedures in the subclause R.2.2.6.1B.

If the dialled number is not equal to a local emergency number stored in the Extended Local Emergency Number List (as defined in TS 24.301) and:

• if the dialled number is equal to an emergency number stored in the ME, in the USIM or in the Local Emergency Number List (as defined in TS 24.008), then the UE shall recognize such a number as for an emergency call and performs the procedures in subclause R.2.2.6.1A.

Once IPsec tunnel setup is completed, the UE shall follow the procedures described in subclause R.2.2.1 of this specification for establishment of IP-CAN bearer and P-CSCF discovery accordingly. Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, if:

• the 380 (Alternate Service) response contains a Contact header field;
• the value of the Contact header field is a service URN; and
• the service URN has a top-level service type of "sos";

then the UE determines that "emergency service information is included" as described TS 23.167. Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.3.1, if the 380 (Alternate Service) response does not contain a Contact header field with service URN that has a top-level service type of "sos", then the UE determines that "no emergency service information is included" as described TS 23.167. Upon reception of a 380 (Alternative Service) response to an INVITE request as defined in subclause 5.1.2A.1.1 and subclause 5.1.3.1, the UE shall proceed as follows:

1. if a 3GPP access network is available and the UE has not already attempted to use a 3GPP access network to set up an emergency session as described in TS 23.167 annex J, when the UE selects a domain in accordance with the conventions and rules specified in TS 22.101 and TS 23.167, the UE shall attempt to select a domain of the 3GPP access network, and:
   • if the CS domain is selected, the UE behaviour is defined in subclause 7.1.2 of TS 23.167 and in annex B, annex L or annex U; and
   • if the IM CN subsystem is selected, the UE shall apply the procedures in subclause 5.1.6 with the exception of selecting a domain for the emergency call attempt;
   In addition, when the UE determines that "it has not been able to use 3GPP access to set up an emergency session" in accordance with subclause J.1 of TS 23.167, the UE shall apply the procedures in subclause 5.1.6 using WLAN, with the exception of selecting a domain for the emergency call attempt; and
2. if a 3GPP access network is not available, then the UE shall apply the procedures in subclause 5.1.6 using WLAN, with the exception of selecting a domain for the emergency call attempt.

When the emergency session ends, the UE:

1. shall release the tunnel as described in TS 24.302; and
2. if EPC via WLAN is the preferred IP-CAN to access IM CN subsystem or if no 3GPP access is available:
   1. if the UE did not select the currently selected ePDG using procedures for selection of ePDG for non-emergency services, shall select an ePDG for non-emergency services as described in TS 24.302;
   2. if the UE does not have an IP-CAN bearer for non-emergency SIP signalling, shall follow the procedures described in subclause R.2.2.1 for establishment of an IP-CAN bearer for SIP signalling and P-CSCF discovery; and
   3. if the UE determines that its contact associated with the IP-CAN bearer for non-emergency SIP signalling is not bound to a public user identity, shall perform an initial registration as specified in subclause 5.1.1.2 using the IP-CAN bearer for SIP signalling.

The type of emergency service for an emergency number is derived from the settings of the emergency service category value (bits 1 to 5 of the emergency service category value as specified in subclause 10.5.4.33 of TS 24.008). Table R.2.2.6.1 below specifies mappings between a type of emergency service and an emergency service URN. The UE shall use the mapping to match an emergency service URN and a type of emergency service. If a dialled number is an emergency number but does not map to a type of emergency service the service URN shall be "urn:service:sos".

If:

• the UE considers itself in the country of the HPLMN;
• multiple types of emergency services can be derived for a dialled number from the information configured on the USIM; and
• no IP-CAN provided a local emergency number that matches the dialled number (see subclause 5.1.6.1);
  then the UE shall map any one of these types of emergency service to an emergency service URN as specified in Table R.2.2.6.1.

If the UE considers itself in the country of the HPLMN and an IP-CAN provided a local emergency number that matches the dialled number (see subclause 5.1.6.1), and if the UE:

• can derive one or more types of emergency service from the information received from the IP-CAN for the dialled number and the UE cannot derive types of emergency service from the information configured on the USIM for the dialled number; or
• derives identical types of emergency service from both the information received from the IP-CAN for the dialled number and from the information configured on the USIM for the dialled number;

then the UE shall map any one of these emergency service types to an emergency service URN as specified in Table R.2.2.6.1.

The Extended Local Emergency Number List (defined in TS 24.301) can contain sub-services of the associated emergency service URN for the detected emergency number. If:

• the length of sub-services field is greater than "0", the UE shall construct the emergency service URN using "urn:service:sos" followed by adding a dot followed by the content of the sub-services field; and
• the length of sub-services field is "0", the UE shall use the emergency service URN "urn:service:sos".

EXAMPLE 1: EXAMPLE 2:

The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".

The UE may support the current location discovery during an emergency call specified in subclause 5.1.6.8.2, subclause 5.1.6.8.3, subclause 5.1.6.8.4, and subclause 5.1.6.12.