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

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

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:

a) 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;

b) 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

c) 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

A UE supporting the P-CSCF restoration procedure uses the keep-alive procedures described in RFC 6223 [143].

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

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

Not applicable.

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

Not applicable.

S.2.2.6.2 eCall type of emergency service

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

Void.