Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.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…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

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

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

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

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

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 procedureWord‑p. 931
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.2Void

S.2.2.3Void

S.2.2.4Void

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. 932
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.3  Application usage of SIP

S.3.1  Procedures at the UE

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

S.3.2.2  Location information handlingWord‑p. 934
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.3Void

S.3.2.4Void

S.3.2.5Void

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.4  3GPP specific encoding for SIP header field extensions

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

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.
  1. An intermediate entity should attempt to support the original request for codecs from the UE.
  2. An intermediate entity should only remove a codec from the codec list to meet policy requirements of the local access of the user.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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).
  9. 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.
Up

Up   Top   ToC