Content for TS 24.229 Word version: 19.3.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…

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

H (Normative) IP-Connectivity Access Network specific concepts when using DOCSIS to access IM CN subsystem |R7| p. 857

H.1 Scope p. 857

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 a DOCSIS cable access network.

DOCSIS (Data Over Cable Service Interface Specification) is a term referring to the Recommendation ITU-T J112 [87] Annex B standard for cable modem systems.

H.2 DOCSIS aspects when connected to the IM CN subsystem p. 857

H.2.1 Introduction p. 857

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the DOCSIS cable access network to provide packet-mode communication between the UE and the IM CN subsystem.

From the perspective of the UE, the necessary IP-CAN bearer for signalling is transparently available to the UE.

The UE is not directly involved in requests for IP-CAN bearer(s) for media flow(s). The IM CN interacts with the PCRF in the DOCSIS IP-CAN to establish IP-CAN bearer(s) for media flow(s), on behalf of the UE.

H.2.2 Procedures at the UE p. 857

H.2.2.1 Activation and P-CSCF discovery p. 857

Prior to communication with the IM CN subsystem, the UE shall perform a Network Attachment procedure as defined in the CableLabs PacketCable specifications PKT-TR-ARCH-FRM [88]. When using DOCSIS, both IPv4 and IPv6 UEs may access the IM CN subsystem. The procedures for P-CSCF discovery defined in subclause 9.2.1 of this document apply.

H.2.2.1A Modification of IP-CAN used for SIP signalling p. 857

Not applicable.

H.2.2.1B Re-establishment of the IP-CAN used for SIP signalling p. 857

Not applicable.

H.2.2.1C P-CSCF restoration procedure |R9| p. 857

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 H.2.2.1 and perform an initial registration as specified in subclause 5.1.

H.2.2.2 Void

H.2.2.3 Void

H.2.2.4 Void

H.2.2.5 Handling of the IP-CAN for media p. 858

H.2.2.5.1 General requirements p. 858

The UE does not directly request resources for media flow(s).

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

Not applicable.

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

Not applicable.

H.2.2.5.1C Deactivation of IP-CAN for media |R11| p. 858

Not applicable.

H.2.2.5.2 Special requirements applying to forked responses p. 858

The UE does not directly request resources for media flow(s). As a result there are no special UE requirements applying to forked responses.

H.2.2.5.3 Unsuccessful situations p. 858

Not applicable.

H.2.2.6 Emergency service p. 858

H.2.2.6.1 General |R14| p. 858

If attached to network via DOCSIS access technology, the UE shall always consider being attached to its home operator's network for the purpose of emergency calls.

H.2.2.6.1A Type of emergency service derived from emergency service category value |R15| p. 858

Not applicable.

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

Not applicable.

H.2.2.6.2 eCall type of emergency service |R14| p. 859

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

H.2.2.6.3 Current location discovery during an emergency call |R14| p. 859

Void.

H.2A Usage of SDP |R8| p. 859

H.2A.0 General |R9| p. 859

Not applicable.

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

Not applicable.

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

Not applicable.

H.2A.3 Emergency service |R11| p. 859

No additional procedures defined.

H.3 Application usage of SIP p. 859

H.3.1 Procedures at the UE p. 859

H.3.1.0 Void

H.3.1.0a IMS_Registration_handling policy |R15| p. 859

Not applicable.

H.3.1.1 P-Access-Network-Info header field p. 859

If the UE is aware of the access technology, the UE shall include the P-Access-Network-Info header field where indicated in subclause 5.1.

H.3.1.1A Cellular-Network-Info header field |R13| p. 859

Not applicable.

H.3.1.2 Availability for calls |R8| p. 860

Not applicable.

H.3.1.2A Availability for SMS |R11| p. 860

Void.

H.3.1.3 Authorization header field |R10| p. 860

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.

H.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 |R13| p. 860

Not applicable.

H.3.1.5 3GPP PS data off |R14| p. 860

Not applicable.

H.3.1.6 Transport mechanisms |R15| p. 860

No additional requirements are defined.

H.3.1.7 RLOS |R16| p. 860

Not applicable.

H.3.2 Procedures at the P-CSCF p. 860

H.3.2.0 Registration and authentication |R12| p. 860

Void.

H.3.2.1 Determining network to which the originating user is attached p. 860

If the access-type field in the P-Access-Network-Info header field indicated DOCSIS access the P-CSCF shall assume that the initial request for a dialog or standalone transaction or an unknown method destined for a PSAP is initiated in the same country.

H.3.2.2 Location information handling p. 861

Upon receipt of an initial request for a dialog or standalone transaction or an unknown method, the P-CSCF based on local policy may include a P-Access-Network-Info header field.

Content for TS 24.229 Word version: 19.3.0

H (Normative) IP-Connectivity Access Network specific concepts when using DOCSIS to access IM CN subsystem |R7| p. 857

H.1 Scope p. 857

H.2 DOCSIS aspects when connected to the IM CN subsystem p. 857

H.2.1 Introduction p. 857

H.2.2 Procedures at the UE p. 857

H.2.2.1 Activation and P-CSCF discovery p. 857

H.2.2.1A Modification of IP-CAN used for SIP signalling p. 857

H.2.2.1B Re-establishment of the IP-CAN used for SIP signalling p. 857

H.2.2.1C P-CSCF restoration procedure |R9| p. 857

H.2.2.5 Handling of the IP-CAN for media p. 858

H.2.2.5.1 General requirements p. 858

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

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

H.2.2.5.1C Deactivation of IP-CAN for media |R11| p. 858

H.2.2.5.2 Special requirements applying to forked responses p. 858

H.2.2.5.3 Unsuccessful situations p. 858

H.2.2.6 Emergency service p. 858

H.2.2.6.1 General |R14| p. 858

H.2.2.6.1A Type of emergency service derived from emergency service category value |R15| p. 858

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

H.2.2.6.2 eCall type of emergency service |R14| p. 859

H.2.2.6.3 Current location discovery during an emergency call |R14| p. 859

H.2A Usage of SDP |R8| p. 859

H.2A.0 General |R9| p. 859

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

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

H.2A.3 Emergency service |R11| p. 859

H.3 Application usage of SIP p. 859

H.3.1 Procedures at the UE p. 859

H.3.1.0a IMS_Registration_handling policy |R15| p. 859

H.3.1.1 P-Access-Network-Info header field p. 859

H.3.1.1A Cellular-Network-Info header field |R13| p. 859

H.3.1.2 Availability for calls |R8| p. 860

H.3.1.2A Availability for SMS |R11| p. 860

H.3.1.3 Authorization header field |R10| p. 860

H.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 |R13| p. 860

H.3.1.5 3GPP PS data off |R14| p. 860

H.3.1.6 Transport mechanisms |R15| p. 860

H.3.1.7 RLOS |R16| p. 860

H.3.2 Procedures at the P-CSCF p. 860

H.3.2.0 Registration and authentication |R12| p. 860

H.3.2.1 Determining network to which the originating user is attached p. 860

H.3.2.2 Location information handling p. 861

H.3.2.6 Resource sharing |R13| p. 861

H.3.2.7 RLOS |R16| p. 861

H.3.3 Procedures at the S-CSCF |R8| p. 861

H.3.3.1 Notification of AS about registration status p. 861

H.3.3.2 RLOS |R16| p. 861

H.4 3GPP specific encoding for SIP header field extensions p. 861

H.5 Use of circuit-switched domain |R8| p. 861