Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  18.4.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

R (Normative)  IP-Connectivity Access Network specific concepts when using the EPC via WLAN to access IM CN subsystem |R11|p. 938

R.1  Scopep. 938

The present annex defines IP-CAN specific requirements for a call control protocol for use in the IM CN subsystem based on the Session Initiation Protocol (SIP), and the associated Session Description Protocol (SDP), where the IP-CAN is the Evolved Packet Core (EPC) via Wireless Local Access Network (WLAN).

R.2  IP-CAN aspects when connected to the IM CN subsystemp. 938

R.2.1  Introductionp. 938

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the EPC and the WLAN to provide packet-mode communication between the UE and the IM CN subsystem.
Requirements for the UE on the use of these packet-mode services are specified in this clause.

R.2.2  Procedures at the UEp. 938

R.2.2.1  Establishment of IP-CAN bearer and P-CSCF discoveryp. 938

Prior to communication with the IM CN subsystem:
a)
the UE establishes an IP-CAN bearer for SIP signalling as follows:
  1. if the UE attaches to the EPC via S2b using untrusted WLAN IP access:
    1. the UE shall obtain a local IP address using the WLAN IP access;
    2. if the UE does not support procedures for access to the EPC via restrictive non-3GPP access network or unless the UE determines that the WLAN used is a restrictive non-3GPP access network, then the UE shall establish an IKEv2 security association and an IPsec ESP security association with ePDG as described in TS 24.302. If the UE supports the Fixed Access Broadband interworking, the UE shall apply the establishment of tunnel specified in TS 24.139;
    3. if the UE supports procedures for access to the EPC via restrictive non-3GPP access network, and if the UE determines that the WLAN used is a restrictive non-3GPP access network, then the UE may perform procedures for access to the EPC via restrictive non-3GPP access network as described in TS 24.302, and may establish an IKEv2 security association and an IPsec ESP security association with ePDG via the firewall traversal tunnel;
    4. the IKEv2 security association and the IPsec ESP security association (tunnel) shall remain active throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration; and
    5. the UE may carry both signalling and media on an IPsec ESP security association;
  2. if the UE attaches to the EPC via S2c using the WLAN IP access:
    1. the UE shall obtain a local IP address;
    2. the UE shall establish an IKEv2 security association and an IPsec ESP security association as described in TS 24.302 and TS 24.303. If the UE supports the Fixed Access Broadband interworking, the UE shall apply the establishment of tunnel specified in TS 24.139;
    3. the IKEv2 security association and the IPsec ESP security association (tunnel) shall remain active throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration;and
    4. the UE may carry both signalling and media on an IPsec ESP security association.
  3. if the UE attaches to the EPC via S2a using a trusted WLAN IP access:
    1. the IPv4 address and/or IPv6 prefix is allocated as specified in TS 24.302; and
    2. the UE IP address shall remain valid throughout the period the UE is connected to the IM CN subsystem, i.e. from the initial registration and at least until the deregistration;
The UE can determine trust relationship of a non-3GPP IP access network as specified in TS 24.302; and
b)
the UE shall aquire a P-CSCF address(es).
The methods for P-CSCF discovery are:
  1. Use DHCP mechanism
  2. Use DNS
    When using IPv4, the UE may request a DNS Server IPv4 address(es) via RFC 2132. When using IPv6, the UE may request a DNS Server IPv6 address(es) via RFC 3315 and RFC 3646.
  3. Obtain the list of P-CSCF address(es) from the IMS management object
  4. Obtain P-CSCF address(es) using signalling for access to the EPC via WLAN.
    If the UE attaches to the EPC via S2b using untrusted WLAN IP access, the UE shall request P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both using the P_CSCF_IP4_ADDRESS attribute, the P_CSCF_IP6_ADDRESS attribute or both in the CFG_REQUEST configuration payload as described in TS 24.302. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both using the P_CSCF_IP4_ADDRESS attribute, the P_CSCF_IP6_ADDRESS attribute or both in the CFG_REPLY configuration payload as described in TS 24.302. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the CFG_REPLY configuration payload as the P-CSCF address having the highest preference and the last P-CSCF address within the CFG_REPLY configuration payload as the P-CSCF address having the lowest preference.
    If the UE attaches to the EPC via S2a using trusted WLAN IP access using single-connection mode, the UE shall indicate request for P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the PROTOCOL_CONFIGURATION_OPTIONS item of the message with SCM_REQUEST message type as described in TS 24.302. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the PROTOCOL_CONFIGURATION_OPTIONS item of the message with SCM_RESPONSE message type as described in TS 24.302. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the PROTOCOL_CONFIGURATION_OPTIONS item as the P-CSCF address having the highest preference and the last P-CSCF address within the PROTOCOL_CONFIGURATION_OPTIONS item as the P-CSCF address having the lowest preference.
    If the UE attaches to the EPC via S2a using trusted WLAN IP access using multi-connection mode, the UE shall indicate request for P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the Protocol Configuration Options information element of the PDN CONNECTIVITY REQUEST message as described in TS 24.244. The network can provide the UE with the P-CSCF IPv4 address(es), P-CSCF IPv6 address(es) or both within the Protocol Configuration Options information element of the PDN CONNECTIVITY ACCEPT message as described in TS 24.244. If the UE receives multiple P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is ordered top-down with the first P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address having the highest preference and the last P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address having the lowest preference.
The UE shall use method III to select a P-CSCF, if a P-CSCF is to be discovered in the home network and the WLAN, to which the UE is attached, is connected to a visited network.
The UE can freely select method I, II, III or IV for P-CSCF discovery if:
  • the UE is in the home network; or
  • the WLAN, to which the UE is attached, is connected to a visited network and the P-CSCF is to be discovered in the visited network.
    If DHCP is used, the following procedures apply:
    Upon establishing an IP-CAN, the UE may use the Dynamic Host Configuration Protocol (DHCP) specified in RFC 2131 or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specified in RFC 3315 to discover the P-CSCF.
    Prior to accessing the DHCP server, the UE will have obtained an IP address via means other than DHCP and DHCPv6.
    If the UE uses DHCP for P-CSCF discovery and the UE is unaware of the address of the DHCP server, the UE sends the DHCPINFORM using the limited broadcast IP address (i.e., 255.255.255.255) and UDP port 67. If the UE knows the IP address of the DHCP server, the UE shall send the DHCPINFORM to the DHCP server's unicast IP address and UDP port 67. The DHCP server sends the DHCPACK on the IP address specified in the Client IP Address field of the DHCPINFORM. The DHCP server can include, in the DHCPACK, the SIP Server DHCP Option specified in RFC 3361, which carries either a list of IPv4 address(es) of the P-CSCF(s) or a list of DNS fully qualified domain name(s) that can be mapped to one or more P-CSCF(s). If the UE uses DHCPv6 for P-CSCF discovery and the UE is unaware of the address of the DHCP Server, the UE shall send an Information Request using the IPv6 multicast address FF02::1:2 and the UDP port 547. If the UE knows the IP address of the DHCPv6 server, the UE shall send the Information Request message to the DHCPv6 server's IP address and UDP port 547. In the Information Request, the UE can request either one or both the SIP Servers Domain Name List option and the SIP Servers IPv6 Address List option specified in RFC 3319. The DHCP server sends the Reply to the IP address specified in the Information Request. The DHCP server can include in the Reply either one or both the SIP Servers Domain Name List option and the SIP Servers IPv6 Address List option, as requested by the UE.
    If the UE supports the optional configuration parameter "Access_Point_Name_Parameter_Reading_Rule", as defined in TS 24.167 and has been configured with this parameter, then the UE shall use it to retrieve the access point name to use in the establishment of IP-CAN bearer.
    In case several P-CSCF's IP addresses or domain names are provided to the UE, the UE shall perform P-CSCF selection according to RFC 3361 or RFC 3319. The UE shall perform the procedure for the resolution of domain name according to RFC 3263. If sufficient information for P-CSCF address selection is not available, selection of the P-CSCF address by the UE is implementation specific.
  • When:
    • the UE obtains an IP-CAN bearer for SIP signalling by performing handover of the connection from another IP-CAN;
    • IP address of the UE is not changed during the handover; and
    • the UE already communicates with the IM CN subsystem via the connection with the other IP-CAN, e.g. the UE determines that its contact with host portion set to the UE IP address (or FQDN of the UE) associated with the connection with the other IP-CAN has been bound to a public user identity;
    the UE shall continue using the P-CSCF address(es) acquired in the other IP-CAN.
    The UE may support the policy on when a UE roaming in a VPLMN is allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS as specified in subclause L.2.1.1. If the UE roams in the EPS IP-CAN, has a session and the policy indicates "roaming in a VPLMN and having an ongoing session, is not allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS", the UE shall not handover the PDN connection providing access to IMS from EPS to EPC via WLAN.
    If the UE roams in the EPS IP-CAN, has a session and the policy indicates "roaming in a VPLMN and having an ongoing session, is allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS", the UE shall, if not prevented by other rules or policies, handover the PDN connection providing access to IMS from EPS to EPC via WLAN.
    If the UE roams in the EPS IP-CAN and the policy indicates "roaming in a VPLMN is not allowed to transfer the PDN connection providing access to IMS between EPC via WLAN and EPS, irrespective of if the UE is in a session or not", the UE shall not handover the PDN connection providing access to IMS from EPS to EPC via WLAN. The UE can re-establish a new PDN connection to another IP-CAN type in idle mode, e.g. due to UE domain preference.
    The UE may support the policy on when a UE is allowed to transfer a PDN connection providing access to IMS between EPC via WLAN and 5GS as specified in subclause U.2.1.1. If the UE is in a session and the policy indicates "is not allowed to transfer the PDN connection providing access to IMS between EPC via non-3GPP access and 5GCN via NG-RAN" or if the UE is roaming when in a session and the policy indicates "a UE roaming in a VPLMN and having an ongoing IMS session, is not allowed to transfer the PDN connection providing access to IMS between EPC via non-3GPP access and 5GCN via NG-RAN" the UE shall not handover the PDN connection providing access to IMS from 5GS to EPC via WLAN.
    If the UE is in a seesion in the EPS IP-CAN and the policy indicates "a UE having an ongoing IMS session, is allowed to transfer the PDN connection providing access to IMS between EPC via non-3GPP access and 5GCN via NG-RAN" or the UE is roaming in an EPS IP-CAN and the policy indicates "a UE roaming in a VPLMN and having an ongoing IMS session, is allowed to transfer the PDN connection providing access to IMS between EPC via non-3GPP access and 5GCN via NG-RAN" the UE shall, if not prevented by other rules or policies, handover the PDN connection providing access to IMS from 5GS to EPC via WLAN.
    If the UE is in a 5GS IP-CAN and the policy indicates "a UE is not allowed to transfer a PDN connection providing access to IMS, if any, between EPC via non-3GPP access and 5GCN via NG-RAN, irrespective of if the UE has an ongoing IMS session or not" or the UE is roaming in a 5GS IP-CAN and the policy indicates "a UE roaming in a VPLMN is not allowed to transfer a PDN connection providing access to IMS, if any, between EPC via non-3GPP access and 5GCN via NG-RAN, irrespective of if the UE has an ongoing IMS session or not" the UE shall not handover the PDU session providing access to IMS from 5GS to EPC via WLAN.
    Up

    R.2.2.1A  Modification of an IP-CAN used for SIP signallingp. 941

    Not applicable.

    R.2.2.1B  Re-establishment of the IP-CAN used for SIP signallingp. 941

    If the UE registered a public user identity with an IP address allocated for the APN of the IP-CAN bearer for SIP signalling, the IP-CAN bearer for SIP signalling is deactivated as result of signalling from the network, and:
    1. the signalling from the network results in requiring the UE to initiate activation of the IP-CAN bearer for SIP signalling; or
    2. the UE needs to continue having a public user identity registered with an IP address allocated for the APN;
    and the UE is allowed to activate the IP-CAN bearer for SIP signalling, the UE shall:
    1. if the non-access stratum is performing activation of the IP-CAN bearer for SIP signalling for the APN triggered as result of the signalling from the network, wait until the activation of the IP-CAN bearer for SIP signalling for the APN finishes;
    2. if the non-access stratum is not performing activation of the IP-CAN bearer for SIP signalling for the APN, perform the procedures in subclause R.2.2.1, bullet a); and
    3. if the IP-CAN bearer for SIP signalling is available:
    Up

    R.2.2.1C  P-CSCF restoration procedurep. 942

    A UE supporting the P-CSCF restoration procedure performs one of the following procedures:
    1. if the UE used method IV for P-CSCF discovery, the UE has previously sent the "P-CSCF Re-selection support" PCO indicator (in trusted non-3GPP access network) or the P-CSCF_RESELECTION_SUPPORT IKEv2 attribute (in untrusted non-3GPP access network) during the PDN connection establishment, and the UE receives one or more P-CSCF address(es) during the TWAG initiated PDN connectivity modification procedure (in trusted non-3GPP access network) or the ePDG initiated modification (in untrusted non-3GPP access network), then the UE shall acquire a P-CSCF address from the one or more P-CSCF addresse(s). If more than one P-CSCF addresses of the same IP address type are included, then the UE shall assume that the more than one P-CSCF addresses of the same IP address type are prioritised with the first P-CSCF address within the Protocol Configuration Options information element or within the IKEv2 configuration payload as the P-CSCF address having the highest priority; and
    2. if the UE uses RFC 6223 as part of P-CSCF restoration procedures, and the P-CSCF fails to respond to keep-alive requests, then the UE shall acquire a different P-CSCF address using any of the methods described in the subclause R.2.2.1.
    When the UE has acquired the P-CSCF address, the UE shall perform an initial registration as specified in subclause 5.1.
    Up

    R.2.2.2Void

    R.2.2.3  IP-CAN support of DHCP based P-CSCF discoveryp. 942

    When using WLAN IP access via S2c to access the EPC, the Home Agent (HA) in case of Mobile IP with reverse tunneling, can forward the packet to one or more local DHCP servers, or relay the packet to a specific DHCP server. The HA in case of Mobile IP with reverse tunnelling, does not forward the DHCPINFORM (or Information-Request) to any UE.
    Up

    R.2.2.4Void

    R.2.2.5  Tunnel procedures for mediap. 942

    R.2.2.5.1  General requirementsp. 942
    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.
    Up
    R.2.2.5.1A  Modification of tunnel for media by the UEp. 943
    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.
    R.2.2.5.1B  Modification of tunnel for media by the networkp. 943
    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.
    Up
    R.2.2.5.1C  Deactivation of tunnel for mediap. 943
    Not applicable.
    R.2.2.5.2  Special requirements applying to forked responsesp. 943
    Since the UE is unable to perform bearer modification, forked responses place no special requirements on the UE.
    R.2.2.5.3  Unsuccessful situationsp. 943
    Not applicable.

    R.2.2.6  Emergency servicep. 944

    R.2.2.6.1  General |R14|p. 944
    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.
  • Up
    R.2.2.6.1A  Type of emergency service derived from emergency service category value |R15|p. 946
    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".
    Type of emergency service Emergency service URN
    Policeurn:service:sos.police
    Ambulanceurn:service:sos.ambulance
    Fire Brigadeurn:service:sos.fire
    Marine Guardurn:service:sos.marine
    Mountain Rescueurn:service:sos.mountain
    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.
    Up
    R.2.2.6.1B  Type of emergency service derived from extended local emergency number list |R15|p. 947
    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:
    For a detected number, if the sub-service is "gas", then the UE constructs "urn:service:sos.gas" as the associated emergency service URN.
    EXAMPLE 2:
    For a detected number, if no sub-service is provided, then the UE uses "urn:service:sos" as the associated emergency service URN.
    Up
    R.2.2.6.2  eCall type of emergency service |R14|p. 948
    The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".
    R.2.2.6.3  Current location discovery during an emergency call |R14|p. 948
    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.

    R.2A  Usage of SDPp. 948

    R.2A.0  Generalp. 948

    Not applicable.

    R.2A.1  Impact on SDP offer / answer of activation or modification of IP-CAN for media by the networkp. 948

    If the UE is attached 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 an additional IPSec ESP tunnel is established according to TS 24.302 and the related SDP media description needs to be changed, the UE shall update the related SDP information by sending a new SDP offer within a SIP request, which is sent over the existing SIP dialog; and
    2. if an IPSec ESP tunnel is modified according to TS 24.302 and the related SDP media description need to be changed, the UE shall update the related SDP information by sending a new SDP offer within a SIP request, that is sent over the existing SIP dialog.
    Up

    R.2A.2  Handling of SDP at the terminating UE when originating UE has resources available and IP-CAN performs network-initiated resource reservation for terminating UEp. 948

    Not applicable.

    R.2A.3  Emergency servicep. 948

    No additional procedures defined.

    R.3  Application usage of SIPp. 949

    R.3.1  Procedures at the UEp. 949

    R.3.1.0  Registration and authentication |R12|p. 949

    In order to reach the IM CN subsystem in some untrusted access networks, the UE may support:
    • address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in Annex F and Annex K; or
    • the IP UE requested FTT-IMS establishment procedure specified in TS 24.322, which is applicable to direct access to an external IP network and not applicable to access through a PLMN.
    If a UE supports one or both of these capabilities then a UE may progressively try them to overcome failure to reach the IPM CN subsystem. Use of these capabilities shall have the following priority order:
    1. UE does not use capability because reaching the IMS without an intervening NA(P)T, NA(P)T-PT, or tunnel is preferred.
    2. UE may use address and/or port number conversions provided by a NA(P)T or NA(P)T-PT as described in either Annex F or Annex K.
    3. UE may use the UE requested FTT-IMS establishment procedure specified in TS 24.322. If the UE uses the UE-requested FTT-IMS establishment procedure specified in TS 24.322, the UE considers itself to:
      • be configured to send keep-alives;
      • be directly connected to an IP-CAN for which usage of NAT is defined; and
      • be behind a NAT.
    Optional procedures apply when the UE is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:
    1. the protection of SIP messages is provided by utilizing TLS as defined in TS 33.203;
    2. the mechanisms specified in this Annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);
    3. the UE shall establish the TLS connection to the P-CSCF on port 443 as defined in TS 33.203. The UE shall use SIP digest with TLS for registration as specified in subclause 5.1. If the TLS connection is established successfully, the UE sends SIP signalling over the TLS connection to the P-CSCF;
    4. the UE shall support the keep-alive procedures described in RFC 6223;
    5. the procedures described in subclause K.5.2 apply with the additional procedures described in the present subclause;
    6. when using the ICE procedures for traversal of restrictive non-3GPP access network, the UE shall support the ICE TCP as specified in RFC 6544 and TURN TCP as specified in RFC 6062.
    7. if the UE is configured to use TURN over TCP on port 80, the UE shall establish the TCP connection to TURN server on port 80. If the UE is configured to use TURN over TLS on port 443, the UE shall establish the TLS connection to the TURN server on port 443 as defined in TS 33.203. If the UE is configured to use both, the UE should prefer to use TURN over TCP on port 80 to avoid TLS overhead;
    8. if the connection is established successfully, the UE sends TURN control messages and media packets over the connection as defined in RFC 5766.
    The UE shall perform reregistration of a previously registered public user identity bound to any one of its contact addresses when changing to an IP-CAN for which usage is specified in Annex B, Annex L or Annex U. The reregistration is performed using the new IP-CAN.
    Up

    R.3.1.0a  IMS_Registration_handling policy |R15|p. 950

    Not applicable.

    R.3.1.1  P-Access-Network-Info header fieldp. 950

    The UE shall always include the P-Access-Network-Info header field where indicated in subclause 5.1.

    R.3.1.1A  Cellular-Network-Info header field |R13|p. 950

    The UE:
    1. using the Evolved Packet Core (EPC) via Untrusted Wireless Local Access Network (WLAN) as IP-CAN to access the IM CN subsystem; and
    2. supporting one or more cellular radio access technology (e.g. E-UTRAN);
    shall always include the Cellular-Network-Info header field specified in subclause 7.2.15, if the information is available, in every request or response in which the P-Access-Network-Info header field is present.
    Up

    R.3.1.2  Availability for callsp. 950

    Not applicable.

    R.3.1.2A  Availability for SMSp. 950

    Void.

    R.3.1.3  Authorization header fieldp. 950

    When using SIP digest or SIP digest without TLS, the UE need not include an Authorization header field on sending a REGISTER request, as defined in subclause 5.1.1.2.1.
    Up

    R.3.1.4  SIP handling at the terminating UE when precondition is not supported in the received INVITE request, the terminating UE does not have resources available and IP-CAN performs network-initiated resource reservation for the terminating UEp. 951

    Not applicable.

    R.3.1.5  3GPP PS data off |R14|p. 951

    Not applicable.

    R.3.1.6  Transport mechanisms |R15|p. 951

    The transport mechansims as defined in subclause 4.2A are used with an additional requirement:
    1. If the UE has attached to the EPC via untrusted non-3gpp access and uses IPSec tunnel mode, in order to reduce the risk of UDP fragmentation, the UE shall decrement the IPSec tunnel overhead from the path MTU between the UE and the ePDG prior applying the transport selection for SIP requests as defined in Section 18.1.1 of RFC 3261.
    Up

    R.3.1.7  RLOS |R16|p. 951

    Not applicable.

    R.3.2  Procedures at the P-CSCFp. 951

    R.3.2.0  Registration and authentication |R12|p. 951

    The P-CSCF may support UEs connected via restrictive non-3GPP access network.
    If the P-CSCF supports UEs connected via restrictive non-3GPP access network, when the P-CSCF receives a 200 (OK) response to a REGISTER request, if the contact address of REGISTER request contains an IP address assigned by the EFTF, and the UE's Via header field contains a "keep" header field parameter, then the P-CSCF shall add a value to the "keep" header field parameter of the UE's Via header field of the 200 (OK) response as defined in RFC 6223.
    Optional procedures apply when the P-CSCF is supporting traversal of restrictive non-3GPP access network using STUN/TURN/ICE, as follows:
    1. the protection of SIP messages is provided by utilizing TLS as defined in TS 33.203;
    2. the P-CSCF supporting these additional procedures should use SIP digest with TLS as defined in subclause 5 and the P-CSCF should inserts an IMS-ALG on the media plane;
    3. the mechanisms specified in this annex shall only be applicable when the IP traffic to the IMS core does not traverse through the Evolved Packet Core (EPC);
    4. the P-CSCF shall support the procedures defined in subclause 5.2, with the exception that the P-CSCF shall use SIP over TLS on port 443 as defined in TS 33.203;
    5. when the UE has indicated support of the keep-alive mechanism defined in RFC 6223, the P-CSCF shall indicate to the UE that it supports the keep-alive mechanism; and
    6. the IMS-ALG in the P-CSCF shall support ICE procedures, as defined in subclause 6.7.2.7.
    Up

    R.3.2.1  Determining network to which the originating user is attachedp. 952

    If the P-CSCF is configured to handle emergency requests, in order to determine from which network the request was originated the P-CSCF shall,
    • if PCRF is used for this UE and 3GPP-User-Location-Info as specified in TS 29.214 is available (see subclause 5.2.1), check the MCC and MNC received in 3GPP-User-Location-Info; and
    • if PCRF is not used for this UE or 3GPP-User-Location-Info is not available, check the MCC and MNC fields received in the Cellular-Network-Info header field in the emergency request.
    Up

    R.3.2.2  Location information handlingp. 952

    Void.

    R.3.2.3  Prohibited usage of PDN connection for emergency bearer services |R15|p. 952

    If the P-CSCF detects that a UE uses a PDN connection for emergency bearer services for a non-emergency REGISTER request, the P-CSCF shall reject that request by a 403 (Forbidden) response.

    R.3.2.4Void

    R.3.2.5Void

    R.3.2.6  Resource sharing |R13|p. 952

    If PCC is supported for this access technology a P-CSCF supporting resource sharing shall apply the procedures in subclause L.3.2.6.
    Up

    R.3.2.7  Priority sharing |R13|p. 953

    If PCC is supported for this access technology a P-CSCF supporting priority sharing and if according to operator policy shall apply the procedures in subclause L.3.2.7.

    R.3.2.8  RLOS |R16|p. 953

    Not applicable.

    R.3.3  Procedures at the S-CSCFp. 953

    R.3.3.1  Notification of AS about registration statusp. 953

    Not applicable.

    R.3.3.2  RLOS |R16|p. 953

    Not applicable.

    R.4  3GPP specific encoding for SIP header field extensionsp. 953

    R.5  Use of circuit-switched domainp. 953

    Void.

    Up   Top   ToC