M.2 cdma2000® packet data subsystem aspects when connected to the IM CN subsystem

M.2 cdma2000^® packet data subsystem aspects when connected to the IM CN subsystem

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

M.2.1 Introduction

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the cdma2000^® packet data subsystem 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 subclause. Requirements for the IP-CAN bearer control point (i.e. the point where the UE has attached itself to the cdma2000^® packet data subsystem) support of this communication are specified in 3GPP2 X.S0011-E [127].

M.2.2 Procedures at the UE

M.2.2.1 Establishment of IP-CAN bearer and P-CSCF discovery

Prior to communication with the IM CN subsystem, the UE shall:

a) establish a connection with the cdma2000^® wireless IP network specified in 3GPP2 X.S0011-E [127]. Upon establishment a connection with the cdma2000^® wireless IP network, the UE can have an IPv4 address only, an IPv6 address only, or both IPv4 and IPv6 addresses simultaneously;

b) ensure that an IP-CAN bearer used for SIP signalling is available. This IP-CAN bearer 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 last deregistration;

The UE shall choose one of the following options when performing establishment of this IP-CAN bearer:

I. A dedicated IP-CAN bearer for SIP signalling:

The UE shall indicate to the IP-CAN bearer control point that this is an IP-CAN bearer intended to carry IM CN subsystem-related signalling only. The UE may also use this IP-CAN bearer for DNS and DHCP access.

II. A general-purpose IP-CAN bearer:

The UE may decide to use a general-purpose IP-CAN bearer to carry IM CN subsystem-related signalling. The UE may carry both signalling and media on the general-purpose IP-CAN bearer; and

c) discover a P-CSCF.

The methods for P-CSCF discovery are:

I. Use DHCP mechanism

II Retrieve the list of P-CSCF address(es) stored in the IMC

III Obtain the list of P-CSCF address(es) from the IMS management object

The UE can freely select method I, II, or III 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 [40A] or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specified in RFC 3315 [40] 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, see 3GPP2 X.S0011-E [127].

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 [35A], 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 [41]. 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 [35A] or RFC 3319 [41]. The UE shall perform the procedure for the resolution of domain name according to RFC 3263 [27A].

M.2.2.1A Modification of IP-CAN used for SIP signalling

Not applicable.

M.2.2.1B Re-establishment of the IP-CAN used for SIP signalling

Not applicable.

M.2.2.1C P-CSCF restoration procedure

A UE supporting the P-CSCF restoration procedure uses the keep-alive procedures described in RFC 6223 [143].

If the P-CSCF fails to respond to the keep-alive request the UE shall acquire a different P-CSCF address using any of the methods described in the subclause M.2.2.1 and perform an initial registration as specified in subclause 5.1.

M.2.2.2 Void

M.2.2.3 IP-CAN bearer control point support of DHCP based P-CSCF discovery

The IP-CAN bearer control point, or Home Agent in case of Mobile IP with reverse tunneling, may forward the packet to one or more local DHCP servers, or relay the packet to a specific DHCP server. The IP-CAN bearer control point, or Home Agent in case of Mobile IP with reverse tunnelling, shall not forward the DHCPINFORM (or Information-Request) to any UE.

NOTE 1: For forwarding the DHCPINFORM or Information-Request, the IP-CAN bearer control point, or Home Agent in case of Mobile IP with reverse tunnelling, does not change the destination IP address of the packet.

NOTE 2: For relaying the DHCPINFORM or Information-Request, the IP-CAN bearer control point, or Home Agent in case of Mobile IP with reverse tunnelling inserts a DHCP server’s IP address in the destination IP address field of the packet.

M.2.2.4 Void

M.2.2.5 Handling of the IP-CAN for media

M.2.2.5.1 General requirements

Not applicable.

M.2.2.5.1A Activation or modification of IP-CAN for media by the UE

Not applicable.

M.2.2.5.1B Activation or modification of IP-CAN for media by the network

Not applicable.

M.2.2.5.1C Deactivation of IP-CAN for media

Not applicable.

M.2.2.5.2 Special requirements applying to forked responses

Not applicable.

M.2.2.5.3 Unsuccessful situations

Not applicable.

M.2.2.6 Emergency service

M.2.2.6.1 General

When establishing an HRPD session to perform emergency registration, the UE shall follow the procedures defined in 3GPP2 X.S0060 [86B].

To determine whether the HRPD UE is attached to the home network or to the visited network, the UE shall compare the Carrier ID values obtained per 3GPP2 X.S0060 [86B]. If the Carrier ID of the network the UE is attached to does not match with the provisioned Carrier ID, then for the purpose of emergency calls in the IM CN subsystem the UE shall consider to be attached to a visited network.

NOTE: For 3GPP2-1X and 3GPP2-UMB, no IP-CAN specific support is provided in the current release. No carrier identification is provided for 3GPP2-1X or 3GPP2-UMB in the P-Access-Network-Info header field, and thus there is no IMS specific procedure for identifying that the UE is in the home network.

M.2.2.6.1A Type of emergency service derived from emergency service category value

Not applicable.

M.2.2.6.1B Type of emergency service derived from extended local emergency number list

Not applicable.

M.2.2.6.2 eCall type of emergency service

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

M.2.2.6.3 Current location discovery during an emergency call

Void.