Content for TS 24.229 Word version: 17.1.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… 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| Word‑p. 932

S.1 Scope

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

S.2.1 Introduction

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

S.2.2.1 Activation and P-CSCF discovery

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

Not applicable.

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

Not applicable.

S.2.2.1C P-CSCF restoration procedure Word‑p. 933

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

S.2.2.5.1 General requirements

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

Not applicable.

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

Not applicable.

S.2.2.5.1C Deactivation of IP-CAN for media

Not applicable.

S.2.2.5.2 Special requirements applying to forked responses

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

Not applicable.

S.2.2.6 Emergency service

S.2.2.6.1 General |R14|

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|

Not applicable.

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

Not applicable.

S.2.2.6.2 eCall type of emergency service |R14| Word‑p. 934

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|

Void.

S.2A Usage of SDP

S.2A.0 General

Not applicable.

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

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

Not applicable.

S.2A.3 Emergency service

No additional procedures defined.

S.3 Application usage of SIP

S.3.1 Procedures at the UE

S.3.1.0 Void

S.3.1.0a IMS_Registration_handling policy |R15|

Not applicable.

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

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|

Not applicable.

S.3.1.2 Availability for calls Word‑p. 935

Not applicable.

S.3.1.2A Availability for SMS

Void.

S.3.1.3 Authorization header field

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

Not applicable.

S.3.1.5 3GPP PS data off |R14|

Not applicable.

S.3.1.6 Transport mechanisms |R15|

No additional requirements are defined.

S.3.1.7 RLOS |R16|

Not applicable.

S.3.2 Procedures at the P-CSCF

S.3.2.0 Registration and authentication |R12|

Void.

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

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

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|

Not applicable.

S.3.2.7 Priority sharing |R13|

Not applicable.

S.3.2.8 RLOS |R16|

Not applicable.

S.3.3 Procedures at the S-CSCF

S.3.3.1 Notification of AS about registration status

Not applicable

S.3.3.2 RLOS |R16|

Not applicable.

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

S.4.1 Void

S.5 Use of circuit-switched domain

There is no CS domain in this access technology.

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

T.1 Scope

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

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.