Content for  TS 23.228  Word version:  18.5.0

The Telephony Application Server is a SIP AS providing the network support for the multimedia telephony service, TS 22.173. If specific procedures and message flows include or require media interaction, the TAS and MRFC may be collocated.

The multimedia telephony communication service shall be associated with a communication service identifier to allow easy identification of the service. When multimedia telephony is supported in a network, Voice/video calls originating from the PSTN/CS domain shall be marked with the communication service identifier associated with multimedia telephony communication service.

When establishment of UE initiated IP-CAN bearer(s) for the media is required it is recommended to reserve IP-CAN bearer(s) at the reception of the SDP answer. If the UE has been made aware of the operator policies with regards to allowed media for the multimedia telephony service, then the UE may reserve IP-CAN bearer(s) at the sending of the SIP INVITE request. For multimedia telephony, the UE should only mark resource reservation as required for voice and video. When there are no requirements for resource reservation or when required resources are available on the originating side, the P-CSCF on the terminating side may send available session information to the PCRF/PCF at the reception of the SDP offer, as in such cases the UE can attempt resource reservation before sending the SDP answer. If configured through policies, the telephony AS, or any other AS, may perform for originating requests attestation of the identity of the originating subscriber. If configured through policies, the telephony AS, or any other AS, may perform for originating IMS priority sessions, assertion of authorization for the Resource-Priority information. If configured through operator policies, the telephony AS may perform for diverted sessions attestation of the identity of the diverting subscriber initiating the diversion, In addition, and if configured through policies, the telephony AS, or any other AS, may perform for terminating requests signature verifications, if one or more signatures is included.

The IP-SM-GW acts as an SIP-AS in the IMS domain to provide the protocol interworking for the delivery of the short message between the UE and the Service Centre. All functionalities and interfaces of IP-SM-GW are defined in TS 23.204.

Number portability (NP) allows a user to retain their E.164 number when changing subscriptions from one network operator to another. As such, NP applies to TEL URIs and SIP URIs representing E.164 addresses. NP is subject to regional requirements and is accomplished through the retrieval of ported data from those databases. The specification of these databases is out of the scope of this document, but the NP data may be accessed through ENUM/DNS or accessed via existing (PSTN- and CS-domain) NP databases using the legacy PSTN/CS-domain protocols, such as TCAP. Support of NP within a network and the exact means to make the number portability data available to IMS, is subject to and configured per operator policy. NP is not mandated by this specification on any network operator. As configured per operator policy, IMS ENUM interfaces can be updated to support handling of the PSTN ENUM service per RFC 4769, which provides a URI containing an E.164 number with NP routing information and NP dip indicators. The IMS entity receiving NP information as a result of an ENUM/DNS query (e.g. S-CSCF), needs to support NP protocol parameters retrieved as part of ENUM/DNS procedures contained in clause 4.3.5. This IMS entity and any subsequent IMS entities/network elements used to process the call to the PSTN shall not remove the NP protocol parameters inserted in SIP messaging as part of the NP data retrieval procedure. NP data can also be made available by means of direct access to PSTN/CS-domain NP Databases using the legacy PSTN/CS-Domain interfaces and protocols. To support this existing interface within the network, the requesting and subsequent network elements need to support, or not remove, NP protocol parameters within SIP messages that result from the NP data retrieval procedures. The procedures to retrieve the NP data using the legacy PSTN/CS-domain interfaces are out of scope of this specification. Alternatively, per operator policy, the BGCF can retrieve NP data as part of the procedures to select an MGCF for PSTN connection. The interface used at the BGCF to retrieve the NP data is out of scope of this specification. When clause 4.15a (Roaming Architecture for Voice over IMS with Local Breakout) is in use, and the Home Network decides to loop-back the call to the visited network, the Home network can choose not to retrieve NP data, and leave it to the visited network. Alternatively, per operator policy, the MGCF may support legacy interfaces to retrieve number portability data.

Preferred Circuit Carrier Access allows the network operator to configure a preferred long distance circuit carrier for a subscriber, set of subscribers or all subscribers on the network. All long distance calls from a subscriber are routed to the long distance circuit carrier when preferred circuit carrier access applies. A SIP message parameter indicates the preferred circuit carrier selected. This parameter can be delivered to the PSTN. An application server can be used to insert preferred circuit carrier parameters. The BGCF needs to consider, and can insert, the preferred circuit carrier parameters when routing calls towards an MGCF. Preferred Circuit Carrier Selection per call, also known as Dial-around, allows the subscriber to request a long distance carrier for a specific call. A dial-around request is dialled by the subscriber along with the called party number at call origination. As configured per operator policy, the dial-around circuit carrier selection can take precedence over other preferred circuit carrier selection that can be configured in the network. Therefore, based on operator policy, the preferred circuit carrier parameter is not to be replaced if already present in a SIP message with a dial-around indicator. A SIP message parameter indicates the preferred circuit carrier selected with a dial-around indicator. This parameter is delivered to the PSTN. Support of preferred circuit carrier access and dial-around is optional within a network and is subject to, and configured per, operator policy.

The ECN profile used to trigger codec rate adaptation for Multimedia Telephony is defined in TS 26.114 and affects the following IMS entities: UE, MGCF/IM-MGW, IBCF/TrGW, IMS-ALG/ IMS-AGW, MRFP/MRFC, and the MSC Server enhanced for ICS/MSC Server enhanced for SRVCC with SIP/CS-MGW. As specified in TS 26.114:

• an MGCF/IM-MGW can be used for inter-working between an ECN-capable client in a 3GPP network that properly handles ECN-marked packets and a CS network;
• an IBCF/TrGW supporting Multimedia Telephony can be used for interworking between an ECN-capable entity in a 3GPP network that properly handles ECN-marked packets, and:
  • a remote entity that does not use ECN;
  • a remote entity that supports ECN in different way than what is specified for Multimedia Telephony clients;
  • a network which does not handle ECN-marked packets properly.

A UE supporting Multimedia Telephony and ECN shall support the procedures described in TS 26.114.

If MGCF/IM-MGW supports Multimedia Telephony compliant ECN, it shall:

• support ECN Multimedia Telephony client procedures as described in TS 26.114, except that the MGCF and IM-MGW do not determine whether ECN can be used based on the Radio Access Technology that is used towards the client; the MGCF/ IM-MGW act as an ECN endpoint towards the Multimedia Telephony terminal;
• support SDP ability to negotiate to ECN according to TS 26.114;
• be capable of enabling end-to-end rate adaptation between Multimedia Telephony terminal and the CS terminal or IM-MGW by performing the following:
  • negotiate the use of ECN with the Multimedia Telephony terminal, if it can be confirmed that the network used towards the Multimedia Telephony terminal properly handles ECN-marked packets;
  • trigger rate adaptation request towards the Multimedia Telephony terminal when receiving in the incoming IMS media flow IP packets marked with ECN-CE, regardless of whether the IM-MGW applies or does not apply transcoding;
  • inter-work adaptation requests between the Multimedia Telephony terminal and the CS GERAN/UTRAN when the IM-MGW bridges compatible codec configurations between the interfaces without applying a transcoding function; if the IM-MGW prefers to receive a lower codec mode rate from the Multimedia Telephony terminal than what the CS network indicates, e.g. after having received IP packets with ECN-CE, the IM-MGW may replace the codec mode requested from the CS side with the codec mode that the IM-MGW prefers;
  • perform media adaptation (e.g. reduce media bit-rate) towards the Multimedia Telephony terminal when receiving from the latter an adaptation request and the IM-MGW applies transcoding.

An IBCF/TrGW may support Multimedia Telephony using ECN and can be used to enable ECN within the local network when either the remote network cannot be confirmed to properly handle ECN-marked packets or the remote entity does not support or use ECN. In order to support Multimedia Telephony using ECN when interworking with a remote network that cannot be confirmed to properly handle ECN-marked packets and/or with a remote terminal does not support or use ECN, the IBCF/TrGW shall:

• determine from local configuration if the remote network properly handles ECN-marked packets;
• determine with SDP offer/answer procedures if the remote entity supports ECN;
• support SDP ability to negotiate to ECN according to TS 26.114;
• be capable of enabling end-to-end rate adaptation between the local Multimedia Telephony terminal and the remote entity or TrGW by performing the following towards the local Multimedia Telephony terminal:
  • negotiate the use of ECN;
  • support ECN Multimedia Telephony client procedures as described in TS 26.114, except that the IBCF/TrGW does not determine whether ECN can be used based on the Radio Access Technology; the IBCF/TrGW acts as an ECN endpoint towards the ECN capable Multimedia Telephony terminal;
  • trigger rate adaptation request towards the Multimedia Telephony terminal when receiving in the incoming IMS media flow IP packets marked with ECN-CE, regardless of whether the TrGW applies or does not apply transcoding; this requires that the IBCF provides the TrGW with the media configuration, even if transcoding is not supported or applied, when the IP termination is configured with ECN;
  • forward adaptation requests between the Multimedia Telephony terminal and the remote entity when the TrGW bridges compatible codec configurations between the interfaces without applying a transcoding function; if the TrGW prefers to receive a lower codec mode rate from the Multimedia Telephony terminal than what the other SIP network indicates, e.g. after having received IP packets with ECN-CE, the TrGW may replace the codec mode requested from the other SIP network with the codec mode that the TrGW prefers;
  • perform media adaptation (e.g. reduce media bit-rate) towards the Multimedia Telephony terminal when receiving from the latter an adaptation request and the TrGW applies transcoding.

An IBCF/TrGW supporting Multimedia Telephony compliant ECN can also be used to enable ECN end-to-end if the remote entity uses ECN in a different way than what is described in TS 26.114, e.g. if the remote entity only supports probing for the ECN initiation phase or it needs the ECN feedback.

The P-CSCF shall be able to disallow the negotiation of ECN during SDP offer/answer exchanges if the IMS-AGW does not support transparent forwarding of the ECN bits or if the IMS core network or the access network used towards the Multimedia Telephony terminal do not properly handle ECN-marked packets. An IMS-AGW supporting ECN shall be able to forward the ECN bits as instructed by the IMS-ALG. The IMS-ALG/IMS-AGW may act as an ECN endpoint towards the access network and/or the IMS Core Network to enable ECN when the ECN connection cannot be established or maintained transparently (e.g. after PS-CS Access Transfer). When acting as an ECN endpoint the IMS-AGW shall support end-to-end rate adaptation between the local terminal and the remote entity by performing the following:

• trigger rate adaptation request towards the ECN-capable peer when receiving in the incoming IMS media flow IP packets marked with ECN-CE, regardless of whether the IMS-AGW applies or does not apply transcoding;
• forward adaptation requests between the local and the remote peer when the IMS-AGW bridges compatible codec configurations between the interfaces without applying a transcoding function;
• perform media adaptation (e.g. reduce media bit-rate) towards the ECN-capable peer when receiving from the latter an adaptation request and the IMS-AGW applies transcoding.

An MRFC/MRFP may support Multimedia Telephony using ECN and may act as an ECN endpoint to enable ECN with a local ECN-capable terminal within a local network that properly handles ECN-marked packets (see TS 23.333). This requires that the MRFC/MRFP performs the following:

• support SDP ability to negotiate to ECN according to TS 26.114;
• be capable of enabling end-to-end rate adaptation between the local Multimedia Telephony terminal and the MRFP by performing the following towards the local Multimedia Telephony terminal:
  • negotiate the use of ECN;
  • support ECN Multimedia Telephony client procedures as described in TS 26.114, except that the MRFC/MRFP does not determine whether ECN can be used based on the Radio Access Technology; the MRFC/MRFP acts as an ECN endpoint towards the ECN capable Multimedia Telephony terminal;
  • trigger rate adaptation request towards the Multimedia Telephony terminal when receiving in the incoming IMS media flow IP packets marked with ECN-CE;
  • perform media adaptation (e.g. reduce media bit-rate) towards the Multimedia Telephony terminal when receiving from the latter an adaptation request.

If the MSC Server enhanced for ICS/MSC Server enhanced for SRVCC with SIP/CS-MGW supports Multimedia Telephony compliant ECN, it shall support the procedures specified in clause 4.22.2 respectively for the MGCF and IM-MGW.

An IMS network may implement functionality for IMS serving network nodes (S-CSCF, Transit Function) to handle load balancing, i.e. the technique to distribute workload evenly across two or more network nodes implementing the same functions, in order to get optimal resource utilization. For S-CSCFs, load balancing may be applied for received initial registration requests (see clause 4.23.2). For Transit Functions, load balancing may be applied for received service requests, i.e. initial SIP requests requesting a service (see clause 4.23.3).

Load balancing of S-CSCFs for received initial registration requests may be based on load balancing functionality performed by an I-CSCF or it may be based on mechanisms outside IMS functional entities (such as DNS). An example of the DNS-based load balancing approach is the use of functionality that collects load information of S-CSCFs, applies a load balancing algorithm and provides the outcome to a (Dynamic) DNS, which subsequently is used implicitly by I-CSCFs. An I-CSCF that performs load balancing of S-CSCFs for initial registration requests shall assign a received registration request to one of the available and suitable S-CSCFs using a load balancing algorithm. Such load balancing algorithm may take load information of the S-CSCFs into consideration if available. Load information may be obtained via management interfaces, via proprietary interfaces, or via other mechanisms.

Load balancing of Transit Functions for received service requests may be based on load balancing functionality performed by an IMS functional entity that is the immediate source of the service request to the Transit Function (e.g. an IBCF or an I-CSCF), or it may be based on mechanisms outside IMS functional entities (such as DNS). An example of the DNS-based load balancing approach is the use of functionality that collects load information of Transit Functions, applies a load balancing algorithm and provides the outcome to a (Dynamic) DNS, which subsequently is used implicitly by IMS functional entities that require the IP-address of a Transit Function for routing a service request. An IMS functional entity that performs load balancing of Transit Functions for service requests shall assign a received service request to one of the available and suitable Transit Functions using a load balancing algorithm. Such load balancing algorithm may take load information of the Transit Functions into consideration if available. Load information may be obtained via management interfaces, via proprietary interfaces, or via other mechanisms.

Network elements within the IP Multimedia CN subsystem may have to cope with high volume of signalling traffic with significant traffic peaks. An IMS network may therefore implement overload control functionality in IMS network elements to prevent overload situations. For that purpose, two different mechanisms are provided:

• A mechanism based on next-hop monitoring of overload, where an IMS node acting as a SIP server may provide overload control feedback to its neighbours. This mechanism is described in clause 4.25.2.
• A filter-based mechanism where an IMS node acting as SIP server, may send load control filters to another IMS node that has subscribed for receiving this information. This mechanism is described in clause 4.25.3.

Emergency calls shall not be affected by the overload traffic restrictions due to overload control and MPS priority information shall be taken into account when applying by the overload traffic restrictions based on received indications.

For IMS entities supporting next-hop monitoring of overload, these IMS entities shall support a mechanism for monitoring overload of neighbour nodes with minimal overhead, to enable scenarios where the overload status needs to be adjusted frequently. IMS entities supporting SIP, e.g. S-CSCF, shall be able to provide overload control feedback to their neighbours by providing load reduction directives within SIP responses. The neighbour nodes shall be able to adapt the traffic sent to the overloaded node by restricting the traffic offered to the overloaded neighbour node in accordance with the overload status information received. It is recommended that when next-hop monitoring of overload is deployed for a specific function, all neighbour nodes also support the feedback of overload control status and support the overload traffic restriction procedures towards the specific function being monitored. The next hop monitoring of overload procedures should at least be possible to use for the following scenarios:

• Network internal overload control between core functions, e.g. between different CSCFs.
• Application Server overload control (i.e. between CSCF and AS).
• Roaming and Interconnect (e.g. between IBCFs of two different networks).
• Transit scenarios (e.g. between IBCF and Transit function).

When filter based Overload Control is deployed, an IMS entity supporting SIP overload control (e.g. originating AS or S-CSCF) may subscribe to traffic filter information of specific IMS SIP server destination which may be subject to overload (e.g. an 800 application overloaded by mass calling to a specific number), and perform overload traffic restriction according to the information received. Alternatively, when the destination is not in IMS, the IMS entity performing the overload traffic restrictions may subscribe to an IMS SIP server providing traffic filter information related to the destination, or can have configured overload traffic filter information for the specific destination. IMS entities supporting this mechanism shall match all SIP requests they send against received traffic filter information. If such a filter based mechanism is used, it is recommended that the function performing the overload traffic restrictions be as close to originating party as possible, while still having sufficiently aggregated traffic to perform restrictions on, e.g. by allowing the originating AS/S-CSCF to subscribe to the traffic filter information from a terminating AS.