Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑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… 
O IP-Connectivity Access Network specific concepts when using the EPC via cdma2000® HRPD to access IM CN subsystem  O.1 Scope  O.2 IP-CAN aspects when connected to the IM CN subsystem  O.2A Usage of SDP  O.3 Application usage of SIP  O.4 3GPP specific encoding for SIP header field extensions  O.5 Use of circuit-switched domain 
...

 

O (Normative)  IP-Connectivity Access Network specific concepts when using the EPC via cdma2000® HRPD to access IM CN subsystem |R8|  p. 924

O.1  Scope  p. 924

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.

O.2  IP-CAN aspects when connected to the IM CN subsystem  p. 924

O.2.1  Introduction  p. 924

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

O.2.2  Procedures at the UE  p. 924

O.2.2.1  IP-CAN bearer context activation and P-CSCF discovery  p. 924

Prior to communication with the IM CN subsystem, the UE shall:
a)
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;
b)
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
c)
acquire a P-CSCF address(es).
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-CSCFaddress(es) from the IMS management object
  4. 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.
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 IP CAN bearer context activation procedure.
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.
Up

O.2.2.1A  Modification of an IP-CAN bearer context used for SIP signalling  p. 925

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.

O.2.2.1B  Re-establishment of the IP-CAN bearer context for SIP signalling  p. 925

If the IP-CAN bearer context for SIP signalling is lost and cannot be re-established:
  1. if the SIP signalling was carried over a dedicated IP-CAN bearer, the UE shall release all resources established as a result of SIP signalling by either:
    • requesting an IP-CAN bearer modification if there are IP-CAN bearers to this PDN that are not related SIP sessions; or
    • initiating disconnection of the PDN connection if all the bearers to this PDN are related to SIP sessions.
Up

O.2.2.1C  P-CSCF restoration procedure |R9|  p. 926

A UE supporting the P-CSCF restoration procedure performs one of the following procedures:
  1. 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;
  2. 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.
Up

O.2.2.2  Session management procedures  p. 926

The existing procedures for session management as described in 3GPP2 X.P0057 [86C] shall apply while the UE is connected to the IM CN subsystem.

O.2.2.3  Mobility management procedures  p. 926

The existing procedures for mobility management as described in 3GPP2 X.P0057 [86C] shall apply while the UE is connected to the IM CN subsystem.

O.2.2.4  Cell selection and lack of coverage  p. 926

The existing mechanisms and criteria for cell selection as described in 3GPP2 C.S0014-C [86D] shall apply while the UE is connected to the IM CN subsystem.

O.2.2.5  IP-CAN bearer contexts for media  p. 926

O.2.2.5.1  General requirements  p. 926
Up
O.2.2.5.1A  Activation or modification of IP-CAN bearer contexts for media by the UE  p. 926
No additional clarifications are needed for the use of the EPC via cdma2000® HRPD as an IP-CAN.
O.2.2.5.1B  Activation or modification of IP-CAN bearer contexts for media by the network  p. 927
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.
Up
O.2.2.5.1C  Deactivation of of IP-CAN bearer contexts for media |R11|  p. 927
Not applicable
O.2.2.5.2  Special requirements applying to forked responses  p. 927
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:
  1. the bearer requirements of the subsequent SDP can be accommodated by the existing resources requested. The UE performs no further resource requests.
  2. the subsequent SDP introduces different QoS requirements or additional IP flows. The UE requests further resource allocation according to subclause O.2.2.5.1.
  3. the subsequent SDP introduces one or more additional IP flows. The UE requests further resource allocation according to subclause O.2.2.5.1.
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 Section 13.2.2.4 of RFC 3261), the UE shall:
  1. 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.
Up
O.2.2.5.3  Unsuccessful situations  p. 927
Not applicable.

O.2.2.6  Emergency service  p. 927

O.2.2.6.1  General |R14|  p. 927
Emergency services is not supported when the IP-CAN is the EPC via a cdma2000® HRPD access network.
O.2.2.6.1A  Type of emergency service derived from emergency service category value |R15|  p. 927
Not applicable.
O.2.2.6.1B  Type of emergency service derived from extended local emergency number list |R15|  p. 928
Not applicable.
O.2.2.6.2  eCall type of emergency service |R14|  p. 928
The UE shall not send an INVITE request with Request-URI set to "urn:service:sos.ecall.manual" or "urn:service:sos.ecall.automatic".
O.2.2.6.3  Current location discovery during an emergency call |R14|  p. 928
Void.

O.2A  Usage of SDP  p. 928

O.2A.0  General |R9|  p. 928

Not applicable.

O.2A.1  Impact on SDP offer / answer of activation or modification of IP-CAN bearer context for media by the network  p. 928

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:
  1. 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.
Up

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

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

O.2A.3  Emergency service |R11|  p. 928

No additional procedures defined.

O.3  Application usage of SIP  p. 929

O.3.1  Procedures at the UE  p. 929

O.3.1.0  Void

O.3.1.0a  IMS_Registration_handling policy |R15|  p. 929

Not applicable.

O.3.1.1  P-Access-Network-Info header field  p. 929

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

O.3.1.1A  Cellular-Network-Info header field |R13|  p. 929

Not applicable.

O.3.1.2  Availability for calls  p. 929

Not applicable.

O.3.1.2A  Availability for SMS |R11|  p. 929

Void.

O.3.1.3  Authorization header field |R10|  p. 929

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

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

Not applicable.

O.3.1.5  3GPP PS data off |R14|  p. 929

Not applicable.

O.3.1.6  Transport mechanisms |R15|  p. 930

No additional requirements are defined.

O.3.1.7  RLOS |R16|  p. 930

Not applicable.

O.3.2  Procedures at the P-CSCF  p. 930

O.3.2.0  Registration and authentication |R12|  p. 930

Void.

O.3.2.1  Determining network to which the originating user is attached  p. 930

The P-CSCF handling is as defined in subclause M.3.2.
Up

O.3.2.2  Location information handling  p. 930

Void.

O.3.2.3  Void

O.3.2.4  Void

O.3.2.5  Void

O.3.2.6  Resource sharing |R13|  p. 930

If the P-CSCF supports resource sharing, PCC is supported for this access technology and if according to local policy, the P-CSCF shall apply the procedures in subclause L.3.2.6.

O.3.2.7  Priority sharing |R13|  p. 930

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

O.3.2.8  RLOS |R16|  p. 930

Not applicable.

O.3.3  Procedures at the S-CSCF  p. 931

O.3.3.1  Notification of AS about registration status |R16|  p. 931

The S-CSCF handling is as defined in subclause M.3.3.1.

O.3.3.2  RLOS |R16|  p. 931

Not applicable.

O.4  3GPP specific encoding for SIP header field extensions  p. 931

O.4.1  Void

O.5  Use of circuit-switched domain  p. 931

There is no CS domain in this access technology.

P  Void

Up   Top   ToC