Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.5.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…   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 (Normative)  IP-Connectivity Access Network specific concepts when using DVB-RCS2 to access IM CN subsystem |R11|Word‑p. 938

S.1  ScopeWord‑p. 938

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 subsystemWord‑p. 938

S.2.1  IntroductionWord‑p. 938

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 UEWord‑p. 938

S.2.2.1  Activation and P-CSCF discoveryWord‑p. 938

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 signallingWord‑p. 938

Not applicable.

S.2.2.1B  Re-establishment of IP-CAN bearer used for SIP signallingWord‑p. 938

Not applicable.

S.2.2.1C  P-CSCF restoration procedureWord‑p. 939

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

S.2.2.2Void

S.2.2.3Void

S.2.2.4Void

S.2.2.5  Handling of the IP-CAN for mediaWord‑p. 939

S.2.2.5.1  General requirementsWord‑p. 939
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 UEWord‑p. 939
Not applicable.
S.2.2.5.1B  Activation or modification of IP-CAN for media by the networkWord‑p. 939
Not applicable.
S.2.2.5.1C  Deactivation of IP-CAN for mediaWord‑p. 939
Not applicable.
S.2.2.5.2  Special requirements applying to forked responsesWord‑p. 939
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 situationsWord‑p. 939
Not applicable.

S.2.2.6  Emergency serviceWord‑p. 939

S.2.2.6.1  General |R14|Word‑p. 939
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|Word‑p. 939
Not applicable.
S.2.2.6.1B  Type of emergency service derived from extended local emergency number list |R15|Word‑p. 939
Not applicable.
S.2.2.6.2  eCall type of emergency service |R14|Word‑p. 940
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|Word‑p. 940
Void.

S.2A  Usage of SDPWord‑p. 940

S.3  Application usage of SIPWord‑p. 940

S.3.1  Procedures at the UEWord‑p. 940

S.3.1.0Void

S.3.1.0a  IMS_Registration_handling policy |R15|Word‑p. 940

Not applicable.

S.3.1.1  P-Access-Network-Info header fieldWord‑p. 940

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

Not applicable.

S.3.1.2  Availability for callsWord‑p. 941

Not applicable.

S.3.1.2A  Availability for SMSWord‑p. 941

Void.

S.3.1.3  Authorization header fieldWord‑p. 941

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 UEWord‑p. 941

Not applicable.

S.3.1.5  3GPP PS data off |R14|Word‑p. 941

Not applicable.

S.3.1.6  Transport mechanisms |R15|Word‑p. 941

No additional requirements are defined.

S.3.1.7  RLOS |R16|Word‑p. 941

Not applicable.

S.3.2  Procedures at the P-CSCFWord‑p. 941

S.3.2.0  Registration and authentication |R12|Word‑p. 941

Void.

S.3.2.1  Determining network to which the originating user is attachedWord‑p. 941

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

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

Not applicable.

S.3.2.7  Priority sharing |R13|Word‑p. 942

Not applicable.

S.3.2.8  RLOS |R16|Word‑p. 942

Not applicable.

S.3.3  Procedures at the S-CSCFWord‑p. 942

S.3.3.1  Notification of AS about registration statusWord‑p. 942

Not applicable

S.3.3.2  RLOS |R16|Word‑p. 942

Not applicable.

S.4  3GPP specific encoding for SIP header field extensionsWord‑p. 942

S.5  Use of circuit-switched domainWord‑p. 942

There is no CS domain in this access technology.

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

T.1  ScopeWord‑p. 943

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 transcodingWord‑p. 943

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