Content for TS 24.229 Word version: 18.4.0

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…

M.1 Scope M.2 cdma2000® packet data subsystem aspects when connected to the IM CN subsystem M.2A Usage of SDP M.3 Application usage of SIP M.4 3GPP specific encoding for SIP header field extensions M.5 Use of circuit switched domain
...

M (Normative) IP-Connectivity Access Network specific concepts when using cdma2000® packet data subsystem to access IM CN subsystem |R8| p. 912

M.1 Scope p. 912

This annex defines IP-CAN specific requirements for 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 cdma2000® packet data subsystem. It also defines procedures for invoking CS domain services.

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

M.2.1 Introduction p. 912

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 p. 912

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

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

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;

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:

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.
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

discover a P-CSCF.

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-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 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, 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, 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.

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

Not applicable.

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

Not applicable.

M.2.2.1C P-CSCF restoration procedure |R9| p. 913

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

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 p. 913

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.

M.2.2.4 Void

M.2.2.5 Handling of the IP-CAN for media p. 914

M.2.2.5.1 General requirements p. 914

Not applicable.

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

Not applicable.

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

Not applicable.

M.2.2.5.1C Deactivation of IP-CAN for media |R11| p. 914

Not applicable.

M.2.2.5.2 Special requirements applying to forked responses p. 914

Not applicable.

M.2.2.5.3 Unsuccessful situations p. 914

Not applicable.

M.2.2.6 Emergency service p. 914

M.2.2.6.1 General |R14| p. 914

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.

M.2.2.6.1A Type of emergency service derived from emergency service category value |R15| p. 914

Not applicable.

M.2.2.6.1B Type of emergency service derived from extended local emergency number list |R15| p. 915

Not applicable.

M.2.2.6.2 eCall type of emergency service |R14| p. 915

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 |R14| p. 915

Void.

M.2A Usage of SDP p. 915

M.2A.0 General |R9| p. 915

Not applicable.

M.2A.1 Impact on SDP offer / answer of activation or modification of IP-CAN for media by the network p. 915

Not applicable.

M.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 UE p. 915

Not applicable.

M.2A.3 Emergency service |R11| p. 915

No additional procedures defined.

M.3 Application usage of SIP p. 915

M.3.1 Procedures at the UE p. 915

M.3.1.0 Void

M.3.1.0a IMS_Registration_handling policy |R15| p. 915

Not applicable.

M.3.1.1 P-Access-Network-Info header field p. 915

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

M.3.1.1A Cellular-Network-Info header field |R13| p. 916

Not applicable.

M.3.1.2 Availability for calls p. 916

Not applicable.

M.3.1.2A Availability for SMS |R11| p. 916

Void.

M.3.1.3 Authorization header field |R10| p. 916

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.

NOTE:

In case the Authorization header field is absent, the mechanism only supports that one public user identity is associated with only one private user identity. The public user identity is set so that it is possible to derive the private user identity from the public user identity by removing SIP URI scheme and the following parts of the SIP URI if present: port number, URI parameters, and To header field parameters. Therefore, the public user identity used for registration in this case cannot be shared across multiple UEs. Deployment scenarios that require public user identities to be shared across multiple UEs that don't include an private user identity in the initial REGISTER request can be supported as follows:

Assign each sharing UE a unique public user identity to be used for registration,
Assign the shared public user identitiess to the implicit registration set of the unique registering public user identities assigned to each sharing UE.

M.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 UE |R10| p. 916

Not applicable.

M.3.1.5 3GPP PS data off |R14| p. 916

Not applicable.

M.3.1.6 Transport mechanisms |R15| p. 916

No additional requirements are defined.

M.3.1.7 RLOS |R16| p. 916

Not applicable.

M.3.2 Procedures at the P-CSCF p. 916

M.3.2.0 Registration and authentication |R12| p. 916

Void.

M.3.2.1 Determining network to which the originating user is attached p. 917

For an HRPD UE, after the initial request for a dialog or standalone transaction or an unknown method is received the P-CSCF shall check the Carrier ID field received in the P-Access-Network-Info header field to determine from which network the request was originated.

M.3.2.2 Location information handling p. 917

Void

M.3.2.3 Void

M.3.2.4 Void

M.3.2.5 Void

M.3.2.6 Resource sharing |R13| p. 917

Not applicable.

M.3.2.7 Priority sharing |R13| p. 917

Not applicable.

M.3.2.8 RLOS |R16| p. 917

Not applicable.

M.3.3 Procedures at the S-CSCF p. 917

M.3.3.1 Notification of AS about registration status p. 917

The procedures described in subclause 5.4.1.7 apply with the additional procedures described in the present subclause:

in case the received REGISTER request contained a Timestamp header field, the S-CSCF shall insert a Timestamp header field with the value of the Timestamp header field from the received REGISTER request.

M.3.3.2 RLOS |R16| p. 917

Not applicable.

M.4 3GPP specific encoding for SIP header field extensions p. 918

M.4.1 Void

M.5 Use of circuit switched domain p. 918

When an emergency call is to be set up over the CS domain, the UE shall attempt it according to the procedures described in 3GPP2 C.S0005-D [85].