E.10 Support of RAN Assisted Codec Adaptation

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

RAN assisted codec adaptation is a functionality that assists codec rate adaptation for Multimedia Telephony based on access network bitrate recommendation (ANBR) messages that the UE receives in the access stratum of the 3GPP access network (E-UTRA RAT). The functionality is defined in TS 26.114 [76] and affects the following system entities: UE, RAN, P-CSCF and PCRF/PCF.

During SIP registration or emergency registration if the network supports ANBR as specified in TS 26.114 [76] and RAN-assisted codec adaptation as specified in TS 36.300 [99] and TS 36.321 [100], the P-CSCF indicates ‘anbr’ support to the UE.

NOTE: When IMS services are provided in deployments with home routed traffic a supporting P-CSCF does not indicate its capability to handle the ‘anbr’ SDP attribute unless it is configured to know that the roaming partner supports RAN assisted codec adaptation with access network bitrate recommendation.

As specified in TS 26.114 [76]:

– support for RAN assisted codec adaptation can be used only if it is supported end-to-end.

– support for RAN assisted codec adaptation is assumed to be homogeneous in a PLMN i.e. all affected system entities in a PLMN including equivalent PLMNs need to support it. RAN support is required on E-UTRA.

– the UE includes the ‘anbr’ attribute in the SDP offer only if the P-CSCF has indicated its ability to handle it.

– the P-CSCF forwards the ‘anbr’ attribute if it has received it in the SDP offer from the UE.

– when the ‘anbr’ attribute is successfully negotiated end-to-end, the PCRF/PCF uses MBR>GBR setting for the corresponding IP-CAN bearer relying on RAN assisted codec adaptation.

A UE supporting Multimedia Telephony and RAN assisted codec adaptation shall support the procedures described in TS 26.114 [76].

Annex F (informative):
Routing subsequent requests through the S‑CSCF

This annex provides some background information related to clause 5.4.5.3.

The S‑CSCF is the focal point of home control. It guarantees operator control over sessions. Therefore IMS has been designed to guarantee that all initial session signalling requests goes through the Home S‑CSCF on both terminating and originating side. A number of tasks performed by the S‑CSCF are performed either at registration time or immediately during session set-up, e.g. evaluation of initial filter criteria. However, there are tasks of the S‑CSCF, which require the presence of the S‑CSCF in the signalling path afterwards:

– Media parameter control: If the S‑CSCF finds media parameters that local policy or the user’s subscriber profile does not allow to be used within an IMS session, it informs the originator. This requires record-routing in the S‑CSCF. For example, change of media parameters using UPDATE would by-pass a S‑CSCF, which does not record-route.

– CDR generation: The S‑CSCF generates CDRs, which are used for offline charging and for statistical purposes. A S‑CSCF, which does not record-route, would not even be aware of session termination. If the CDRs at the S‑CSCF are needed, then the S‑CSCF must record-route.

– Network initiated session release: The S‑CSCF may generate a network-initiated session release, e.g. for administrative reasons. For that purpose a S‑CSCF needs to be aware of ongoing sessions. In particular it must be aware of hard state dialogs that are required to be terminated by an explicit SIP request.

– If a UE registered to the S‑CSCF uses a Globally Routable User Agent URI (GRUU) assigned by the S‑CSCF as a contact address when establishing a dialog, then the S‑CSCF needs to remain in the signalling path in order to translate mid-dialog requests addressed to that contact address.

The above criteria are particularly important for "multimedia telephony" type peer-to-peer communication.

– Media parameter control guarantees that the user does not use services he or she did not pay for.

– For telephony type services the session charging component is the most important one.

– If a subscriber is administratively blocked, the network shall have the possibility to terminate ongoing communication.

More generally, all the tasks are needed; thus they need to be provided elsewhere if the S‑CSCF does not record-route.

On the other hand there are client-server based services, which may be offered by the home operator. An example of such service available today where the no record route principle is applied, is Presence, where notifications need not go through the S‑CSCF. Another example could be where the UE initiates a session to an Application Server (AS) in the home operator’s domain, e.g. video download. In such cases:

– The server implementation (or the server’s knowledge of user subscription data) may limit the allowed media parameters.

– Charging will be mostly event-based charging (content charging) and depends on the information provided from the AS.

– The AS can terminate sessions. And the dialogs may be soft state dialogs, which are not required to be terminated by an explicit SIP request (e.g. SUBSCRIBE dialogs).
However not in all cases the AS would receive the necessary information, which usually triggers session release (e.g. for administrative reasons).

Thus, for some client-server based services, it might not be necessary to keep the S‑CSCF in the path. It may be desirable for an operator to avoid the load in the S‑CSCF and control the service from the AS. For such services "no record-routing in S‑CSCF" may be configured together with the initial filter criteria, as defined in clause 5.4.5.3.

Annex G (normative):
Reference Architecture and procedures when the NAT is invoked between the UE and the IMS domain