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…

S.1 Scope S.2 DVB-RCS2 aspects when connected to the IM CN subsystem S.2A Usage of SDP S.3 Application usage of SIP S.4 3GPP specific encoding for SIP header field extensions S.5 Use of circuit-switched domain T.1 Scope T.2 Application of network policy for the support of transcoding
...

S (Normative) IP-Connectivity Access Network specific concepts when using DVB-RCS2 to access IM CN subsystem |R11| p. 954

S.1 Scope p. 954

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 DVB-RCS2 satellite access network.

DVB-RCS2 (Second Generation DVB Interactive Satellite System) is a term referring to the ETSI standard ETSI TS 101 454-1 [193], ETSI EN 301 545-2 [194], ETSI TS 101 545-3 [195] for 2nd generation DVB satellite based access network technology with a return channel for two-way communication.

S.2 DVB-RCS2 aspects when connected to the IM CN subsystem p. 954

S.2.1 Introduction p. 954

A UE accessing the IM CN subsystem, and the IM CN subsystem itself, utilise the services provided by the DVB-RCS2 satellite 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 DVB-RCS2 IP-CAN to establish IP-CAN bearer(s) for media flow(s), on behalf of the UE.

S.2.2 Procedures at the UE p. 954

S.2.2.1 Activation and P-CSCF discovery p. 954

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

establish a connection to a DVB-RCS2 RCST depending on local configuration; the RCST shall have completed the RCST commissioning and initialization procedures as described in ETSI TS 101 545-3 [195], and thus have achieved IP connectivity to the NCC of an SVN;
obtain an IP address using the standard IETF protocols (e.g., DHCP or IPCP). The UE shall fix the obtained IP address 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; and
acquire a P-CSCF address(es), according to one of the methods described in subclause 9.2.1; the method available to the UE is determined by the SVN to which the RCST is connected.

S.2.2.1A Modification of IP-CAN bearer used for SIP signalling p. 954

Not applicable.

S.2.2.1B Re-establishment of IP-CAN bearer used for SIP signalling p. 954

Not applicable.

S.2.2.1C P-CSCF restoration procedure p. 955

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 keep-alive requests the UE shall acquire a different P-CSCF address using any of the methods described in the subclause S.2.2.1 and perform an initial registration as specified in subclause 5.1.

S.2.2.2 Void

S.2.2.3 Void

S.2.2.4 Void

S.2.2.5 Handling of the IP-CAN for media p. 955

S.2.2.5.1 General requirements p. 955

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

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

Not applicable.

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

Not applicable.

S.2.2.5.1C Deactivation of IP-CAN for media p. 955

Not applicable.

S.2.2.5.2 Special requirements applying to forked responses p. 955

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

S.2.2.5.3 Unsuccessful situations p. 955

Not applicable.

S.2.2.6 Emergency service p. 955

S.2.2.6.1 General |R14| p. 955

Emergency service is not supported when the IP-CAN is a DVB-RCS2 satellite access network.

S.2.2.6.1A Type of emergency service derived from emergency service category value |R15| p. 955

Not applicable.

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

Not applicable.

S.2.2.6.2 eCall type of emergency service |R14| p. 956

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

S.2.2.6.3 Current location discovery during an emergency call |R14| p. 956

Void.

S.2A Usage of SDP p. 956

S.2A.0 General p. 956

Not applicable.

S.2A.1 Impact on SDP offer / answer of activation or modification of satellite bearer for media by the network p. 956

Not applicable.

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

Not applicable.

S.2A.3 Emergency service p. 956

No additional procedures defined.

S.3 Application usage of SIP p. 956

S.3.1 Procedures at the UE p. 956

S.3.1.0 Void

S.3.1.0a IMS_Registration_handling policy |R15| p. 956

Not applicable.

S.3.1.1 P-Access-Network-Info header field p. 956

The UE may, but need not, include the P-Access-Network-Info header field where indicated in subclause 5.1.

S.3.1.1A Cellular-Network-Info header field |R13| p. 956

Not applicable.

S.3.1.2 Availability for calls p. 957

Not applicable.

S.3.1.2A Availability for SMS p. 957

Void.

S.3.1.3 Authorization header field p. 957

Void

S.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 p. 957

Not applicable.

S.3.1.5 3GPP PS data off |R14| p. 957

Not applicable.

S.3.1.6 Transport mechanisms |R15| p. 957

No additional requirements are defined.

S.3.1.7 RLOS |R16| p. 957

Not applicable.

S.3.2 Procedures at the P-CSCF p. 957

S.3.2.0 Registration and authentication |R12| p. 957

Void.

S.3.2.1 Determining network to which the originating user is attached p. 957

In order to determine from which network the request was originated the P-CSCF shall check if the location information received in the network provided and/or UE provided "dvb-rcs2-node-id" parameter in the P-Access-Network-Info header field(s) indicates that the UE is connected to the same network as the P-CSCF or not.

S.3.2.2 Location information handling p. 958

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. The value of the "dvb-rcs2-node-id" parameter shall be provided by the IP-CAN.

S.3.2.3 Void

S.3.2.4 Void

S.3.2.5 Void

S.3.2.6 Resource sharing |R13| p. 958

Not applicable.

S.3.2.7 Priority sharing |R13| p. 958

Not applicable.

S.3.2.8 RLOS |R16| p. 958

Not applicable.

S.3.3 Procedures at the S-CSCF p. 958

S.3.3.1 Notification of AS about registration status p. 958

Not applicable

S.3.3.2 RLOS |R16| p. 958

Not applicable.

S.4 3GPP specific encoding for SIP header field extensions p. 958

S.4.1 Void

S.5 Use of circuit-switched domain p. 958

There is no CS domain in this access technology.

T (Normative) Network policy requirements for the IM CN subsystem |R12| p. 959

T.1 Scope p. 959

This annex details areas where network policy is subject to additional requirements to those specified in the main part of this document.

T.2 Application of network policy for the support of transcoding p. 959

When providing transcoding functions at the P-CSCF, at the IBCF and at an AS, the set of codecs to be forwarded as the SDP offer to the remote user is subject to network policy. In order to give support to the codecs and media quality originally requested by the offerer, the network policy shall meet the following requirements.

An intermediate entity should attempt to support the original request for codecs from the UE.
An intermediate entity should only remove a codec from the codec list to meet policy requirements of the local access of the user.
A modification (i.e. any combination of reordering, removal or addition) to the codec list should only be made, such that the resultant SDP offer / answer exchange results in media of equal or better end-to-end quality than if the modification had not been made, subject to policy restrictions of the access of the local user.

NOTE 2:
Transcoding between codecs of higher quality can provide better end-to-end quality than using a common codec of lower quality.
A modification (i.e. any combination of reordering, removal or addition) to the codec list should only be made, such that the resultant SDP offer / answer exchange prefers solutions that do not use a transcoder rather than ones that do use transcoder, subject to meeting the policy restrictions in B) and meeting the best end-to-end media quality in C) above.
Additions to the codec list that are provided by the network entity shall be supported by transcoding between at least one of the offered codecs contained in the SDP offer and the added codecs.
An intermediate entity shall not insert a codec to the codec list if end-to-end media security mechanism is required for the related media.
If an intermediate entity performs transcoding during an ongoing session and receives a SIP message containing a subsequent SDP offer including the codec that is currently in use on the incoming call leg, the entity should include the codec that is currently in use on the outgoing call leg when forwarding the SIP message.
If an intermediate entity performs transcoding during an ongoing session and receives a SIP message containing a subsequent SDP offer not including the codec that is currently in use on the incoming call leg, the entity should include the codec that is currently in use on the outgoing call leg when forwarding the SIP message, subject to meeting the policy restrictions in E).
If an intermediate entity does not perform transcoding during an ongoing session and receives a SIP message containing a subsequent SDP offer including the codec that is currently in use, the entity should not add any codecs in the subsequent SDP offer.