The present annex defines IP-CAN specific requirements for a call control protocol for use in the IP Multimedia (IM) Core Network (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 a cdma2000® HRPD access network.
A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the EPC and cdma2000® HRPD access network as specified by 3GPP2 X.P0057 [86C] 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. Requirements for the P-GW in support of this communication are specified in TS 29.061 and TS 29.212.
Requirements for the use of the EPC via packet cdma2000® HRPD as an IP-CAN are specified in 3GPP2 X.P0057 [86C].
establish a connection with the IP-CAN via the cdma2000® HRPD wireless IP network specified in 3GPP2 X.P0057 [86C]. Upon establishing a connection with the cdma2000® eHRPD wireless IP network, the UE can have an IPv4 address only, an IPv6 address only, or both IPv4 and IPv6 addresses simultaneously;
ensure that a IP-CAN bearer context used for SIP signalling is available, according to the APN and P-GW selection criteria described in TS 23.402. This IP-CAN bearer context 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
acquire a P-CSCF address(es).
The methods for P-CSCF discovery are:
Use DHCP mechanism
Retrieve the list of P-CSCF address(es) stored in the IMC
Obtain the list of P-CSCFaddress(es) from the IMS management object
Transfer P-CSCF address(es) within the IP-CAN bearer context activation procedure.
The UE shall indicate the request for a P-CSCF address to the network within the Protocol Configuration Options information element of the during PDN connectivity establishment as specified in 3GPP2 X.P0057 [86C].
If the network provides the UE with a list of P-CSCF IPv4 or IPv6 addresses, the UE shall assume that the list is prioritised with the first address within the Protocol Configuration Options information element as the P-CSCF address with the highest priority.
The UE can freely select method I, II, III, or IV for P-CSCF discovery. If DHCP is used, the following procedures apply:
Upon establishing an IP-CAN bearer, 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 shall send 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 shall send the DHCPACK on the IP address specified in the Client IP Address field of the DHCPINFORM. The DHCP server may 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 may 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 shall send the Reply to the IP address specified in the Information Request. The DHCP server may 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.
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.
The UE shall not modify the IP-CAN bearer from being used exclusively for SIP signalling to a general purpose IP-CAN bearer and vice versa.
After the establishment of a SIP bearer context used for SIP signalling, the UE shall not indicate the request for a P-CSCF address to the network when requesting an IP-CAN bearer modification for that APN. The UE shall ignore P-CSCF address(es) if received from the network as part of the bearer modification procedure.
A UE supporting the P-CSCF restoration procedure performs one of the following procedures:
if the UE used method II for P-CSCF discovery and if the UE receives one or more P-CSCF address(es) in an VSNCP Configure-Request message and the one or more P-CSCF addresse(s) do not include the address of the currently used P-CSCF, then the UE shall acquire a different P-CSCF address from the one or more P-CSCF addresse(s) in the VSNCP Configure-Request message. The UE shall assume that the more than one P-CSCF address are prioritised with the first P-CSCF address within the Protocol Configuration Options information element as the P-CSCF address with the highest priority;
if the UE uses RFC 6223 as part of P-CSCF restoration procedures, and if the P-CSCF fails to respond to a keep-alive request, then the UE shall acquire a different P-CSCF address using one of the methods I, II and III for P-CSCF discovery described in the subclause O.2.2.1.
When a different P-CSCF address is acquired the UE shall perform an initial registration as specified in subclause 5.1.
If the UE receives an activation request from the network for an IP-CAN bearer context which is associated with the IP-CAN bearer context used for signalling, the UE shall, based on the information contained in the Traffic Flow Template provided by the network, correlate the media IP-CAN bearer context with a currently ongoing SIP session establishment or SIP session modification.
If the UE receives a modification request from the network for an IP-CAN bearer context that is used for one or more media streams in an ongoing SIP session, the UE shall modify the related IP-CAN bearer context in accordance with the request received from the network.
Since the UE does not know that forking has occurred until a second, provisional response arrives, the UE requests resource allocation as required by the initial response received. If a subsequent provisional response is received, different alternative actions may be performed depending on the requirements in the SDP answer:
the bearer requirements of the subsequent SDP can be accommodated by the existing resources requested. The UE performs no further resource requests.
the subsequent SDP introduces different QoS requirements or additional IP flows. The UE requests further resource allocation according to subclause O.18.104.22.168.
the subsequent SDP introduces one or more additional IP flows. The UE requests further resource allocation according to subclause O.22.214.171.124.
When a final answer is received for one of the early dialogs, the UE proceeds to set up the SIP session. The UE shall release all the unneeded IP-CAN resources. Therefore, upon the reception of the first final 200 (OK) response for the INVITE request (in addition to the procedures defined in RFC 3261 subclause 126.96.36.199), the UE shall:
in case resources were established or modified as a consequence of the INVITE request and forked provisional responses that are not related to the accepted 200 (OK) response, send release request to release the unneeded resources.
If, due to the activation of an IP-CAN bearer context from the network 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,
If the UE receives a modification request from the network for an IP-CAN bearer context that is used for one or more media streams in an ongoing SIP session, the UE shall:
if, due to the modification of the IP-CAN bearer context, the related SDP media description need to be changed, update the related SDP information by sending a new SDP offer within a SIP request, that is sent over the existing SIP dialog, and respond to the IP-CAN bearer context modification request.
If the UE receives an SDP offer where the SDP offer includes all media streams for which the originating side indicated its local preconditions as met, if the precondition mechanism is supported by the terminating UE and the IP-CAN performs network-initiated resource reservation for the terminating UE and the available resources are not sufficient for the received offer the terminating UE shall indicate its local preconditions and provide the SDP answer to the originating side without waiting for resource reservation.