Tech-invite3GPPspaceIETF RFCsSIP

Content for  TS 24.229  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5……   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4………   5.4.2   5.4.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…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…


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

M.1  Scope

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

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:
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:
  1. 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.
  2. 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:
  1. Use DHCP mechanism
  2. Retrieve the list of P-CSCF address(es) stored in the IMC
  3. 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., 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 signallingWord‑p. 891

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

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


M.2.2.5  Handling of the IP-CAN for mediaWord‑p. 892

M.2.2.6  Emergency service

M.  General |R14|
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.  Type of emergency service derived from emergency service category value |R15|
Not applicable.
M.  Type of emergency service derived from extended local emergency number list |R15|Word‑p. 893
Not applicable.
M.  eCall type of emergency service |R14|
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.  Current location discovery during an emergency call |R14|

M.2A  Usage of SDP

M.3  Application usage of SIP

M.3.1  Procedures at the UE


M.3.1.0a  IMS_Registration_handling policy |R15|

Not applicable.

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

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|Word‑p. 894

Not applicable.

M.3.1.2  Availability for calls

Not applicable.

M.3.1.2A  Availability for SMS |R11|


M.3.1.3  Authorization header field |R10|

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

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|

Not applicable.

M.3.1.5  3GPP PS data off |R14|

Not applicable.

M.3.1.6  Transport mechanisms |R15|

No additional requirements are defined.

M.3.1.7  RLOS |R16|

Not applicable.

M.3.2  Procedures at the P-CSCF

M.3.2.0  Registration and authentication |R12|


M.3.2.1  Determining network to which the originating user is attachedWord‑p. 895

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





M.3.2.6  Resource sharing |R13|

Not applicable.

M.3.2.7  Priority sharing |R13|

Not applicable.

M.3.2.8  RLOS |R16|

Not applicable.

M.3.3  Procedures at the S-CSCF

M.3.3.1  Notification of AS about registration status

The procedures described in subclause apply with the additional procedures described in the present subclause:
  1. 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|

Not applicable.

M.4  3GPP specific encoding for SIP header field extensionsWord‑p. 896

M.5  Use of circuit switched domain

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

Up   Top   ToC