Content for TS 23.228 Word version: 19.0.0

1… 3… 4… 4.2.4… 4.3… 4.4… 4.13… 4.16… 5… 5.2… 5.3… 5.4… 5.4.7… 5.4.8… 5.4a… 5.5… 5.5.3… 5.6… 5.6.3… 5.7… 5.7.3… 5.7.5… 5.7.8… 5.8… 5.10… 5.11… 5.11.3… 5.11.3.3 5.11.3.4 5.11.4… 5.11.5… 5.11.5.3… 5.11.6… 5.12… 5.16… 5.16.2… 5.19… 5.20… A… E… E.2.2… G… G.5… H I… J… K… L… M… M.3… N… P… Q… Q.2.5… R… S… T… U… U.2… V… W… X… Y… Z… AA… AA.3… AB… AC… AC.7… AC.7.2… AC.7.2.2 AC.7.2.3… AC.7.4… AC.9… AC.10…

4.0 General 4.1 Relationship to CS domain and the IP-Connectivity Access Network 4.2 IMS services concepts 4.2.1 Home-network based services 4.2.1.1 Support of CAMEL or IN 4.2.1.2 Support of OSA 4.2.1.3 Dynamic services interactions handling 4.2.1.3.1 Service information exchanged between Application Servers 4.2.1.3.2 Handling by the Application Server 4.2.1.3.3 Deletion of services interaction information 4.2.2 Support of numbers in non-international format in the IMS 4.2.3 Support of roaming users
...

4 IP multimedia subsystem concepts p. 28

4.0 General |R6| p. 28

The IP Multimedia CN subsystem comprises all CN elements for provision of multimedia services. This includes the collection of signalling and media related network elements as defined in TS 23.002. IP multimedia services are based on an IETF defined session control capability which, along with multimedia transport capabilities, utilises the IP-Connectivity Access Network (this may include an equivalent set of services to the relevant subset of CS Services).

In order to achieve access independence and to maintain a smooth interoperation with wireline terminals across the Internet, the IP multimedia subsystem attempts to be conformant to IETF "Internet standards". Therefore, the interfaces specified conform as far as possible to IETF "Internet standards" for the cases where an IETF protocol has been selected, e.g. SIP and RTP.

The IP multimedia core network (IM CN) subsystem enables operators to offer their subscribers multimedia services. The IM CN subsystem should enable the convergence of, and access to, voice, video, messaging, data and web-based technologies for the wireless and wireline user.

The complete solution for the support of IP multimedia applications consists of terminals, IP-Connectivity Access Networks (IP-CAN), and the specific functional elements of the IM CN subsystem described in this technical specification. Examples of IP-Connectivity Access Network are:

the GPRS core network with GERAN and/or UTRAN radio access networks; and
EPC core network and E-UTRAN radio access network; and
5GS access network.

Figure 4.0 below represents the IMS reference architecture including interfaces towards CS network and other IP based multimedia Networks. Details of the roles of these nodes are described in clause 4.6, clause 4.7 and clause 4.7a.

Reproduction of 3GPP TS 23.228, Fig. 4.0: Reference Architecture of the IP Multimedia Core Network Subsystem

Figure 4.0: Reference Architecture of the IP Multimedia Core Network Subsystem

A description of the functional entities can be found in TS 23.002.

4.1 Relationship to CS domain and the IP-Connectivity Access Network p. 29

The IP multimedia subsystem utilizes the IP-CAN to transport multimedia signalling and bearer traffic. IP-CANs that maintain the service while the terminal moves, hide these moves from the IP multimedia subsystem.

The IP multimedia subsystem is independent of the CS domain although some network elements may be common with the CS domain. This means that it is not necessary to deploy a CS domain in order to support an IP multimedia subsystem based network.

4.2 IMS services concepts p. 29

4.2.1 Home-network based services p. 29

4.2.1.1 Support of CAMEL or IN p. 29

It shall be possible for an operator to offer access to services based on the CSE or IN Service Environment for its IM CN subsystem subscribers. It should be noted that there is no requirement for any operator to support CAMEL or IN services for their IM CN subsystem subscribers or for inbound roamers.

For more information refer to clause 4.2.4.

4.2.1.2 Support of OSA p. 30

It shall be possible for an operator to offer access to services based on OSA for its IM CN subsystem subscribers. This shall be supported by an OSA API between the Application Server (AS) and the network.

For more information refer to clause 4.2.4.

4.2.1.3 Dynamic services interactions handling |R11| p. 30

4.2.1.3.1 Service information exchanged between Application Servers p. 30

To avoid conflicting interactions between services they execute, different ASs involved in the same IMS session (within an operator network or across networks) shall be able to exchange the following service interaction information:

indication of services that have been performed, and
optionally, additional indication of services that should be further avoided.

4.2.1.3.2 Handling by the Application Server p. 30

If an AS provides one or more services, the AS may include service interaction information in SIP signalling, identifying the service that it has executed.

If an AS provides one or more services which are known to be negatively impacted by the subsequent execution of a service by another AS, the AS may include, in addition to the an indication of the services executed, service interaction information in SIP signalling, indicating the services that should be avoided.

An AS receiving a SIP message containing an indication

that a service has been executed previously, and/or
that a service should be avoided,

may, depending on local policy, take this information into account. The service interaction information shall be such that an AS receiving this information should not be able to misinterpret the information and shall ignore such information that it does not recognize.

Service interaction information for standardized services shall be standardized but there shall also be the ability to exchange globally unique service information for non-standardized services.

4.2.1.3.3 Deletion of services interaction information p. 30

The service interaction information shall be removed when it is sent to the UE via P-CSCF or to an entity outside the trust domain or when it is not in compliance with service level agreements with other domains.

4.2.2 Support of numbers in non-international format in the IMS |R7| p. 30

Phone or telephone numbers which are not in the international format can allow the access of the visited services (local service numbers) and the access of numbers in a local addressing plan. Since numbers in non-international format are widely used in legacy fixed and mobile CS networks the seamless co-operation with these networks require the support of numbers in non-international format (including local service numbers) in the IMS. It is up to the operator's policy when and which type of numbers in non-international format can be used. In the rest of this clause the term 'visited access network' is used to indicate the network in which the user is physically located. In the case of GPRS access this is the VPLMN. In the case of other access types this is most probably the IP-CAN provider.

The use of numbers in non-international format including local service numbers shall be provided in the following manner:

It shall be possible for the HPLMN to determine whether a user is using a number in non-international format according to an addressing plan used in the visited network or a geo-local service number. This shall be based upon an indication received from the UE. The same indication shall be used to access local services as well as to use a local addressing plan. This indication shall be included in the Request-URI of the SIP request. If a user intends to use a number according to an addressing plan used at his/her current physical location or a local service number at his/her current physical location, then there shall be information about the visited access network independently from the location of the P-CSCF included in the Request-URI of the SIP request.
The P-CSCF shall route the session towards the S-CSCF as per the session origination procedures.
Processing the Request-URI (e.g. address analysis and potential modification such as translation into globally routable format, e.g. a globally routable PSI) shall be performed by an Application Server in the subscriber's Home Network. The S-CSCF routes the SIP request towards this Home Network Application Server based upon filter criteria which are triggered by the information in the 'local indication' received from the UE. The AS may need to identify the visited access network, e.g. from information in SIP signalling or via the Sh interface.
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, and when the indication is received that the number is in accordance with the visited network numbering plan the Home network can choose to not translate numbers in non-international format, and pass on the non-international number as received, to the VPLMN.
When clause 4.15b (Roaming Architecture for Voice over IMS with home routed traffic) is in use, a translation to an international routable number may be needed, but this is beyond the scope of this specification e.g. an implementation specific NNI to the VPLMN (or other 3rd party in the visited country) is needed.
Then the AS passes the session request back to the S-CSCF with Request-URI that contains either a globally routable SIP URI or a Tel URI with number in international format, or a Tel URI with number in non-international format if clause 4.15a (Roaming Architecture for Voice over IMS with Local Breakout) is in use and the Home network does not translate the number in non-international format. The SIP request shall contain enough information to route to the network hosting the service or using the addressing plan and allow the terminating network to identify the intended end point (e.g. service).
The S-CSCF routes the SIP request, via normal IMS routing principles, towards its destination (e.g. a server in the visited access network identified by a PSI) using the Mw or Mm interfaces.

4.2.3 Support of roaming users p. 31

The architecture shall be based on the principle that the service control for Home subscribed services for a roaming subscriber is in the Home network, e.g. the Serving-CSCF is located in the Home network.

Reproduction of 3GPP TS 23.228, Fig. 4.1: Service Platform in Home Network

Figure 4.1: Service Platform in Home Network

Reproduction of 3GPP TS 23.228, Fig. 4.2: External Service Platform

Figure 4.2: External Service Platform

There are two possible scenarios to provide services:

via the service platform in the Home Network
via an external service platform (e.g. third party or visited network)

The external service platform entity could be located in either the visited network or in the 3rd party platform. The standardised way for secure 3rd party access to IMS services is via the OSA framework, see clause 4.2.4.

The roles that the CSCF plays are described below.

The Proxy-CSCF shall enable the session control to be passed to the Serving-CSCF.
The Serving-CSCF is located in the home network. The Serving-CSCF shall invoke service logic.

A Proxy-CSCF shall be supported in both roaming and non-roaming case, even when the Serving-CSCF is located in the same IM CN Subsystem.

Reassigning the Proxy-CSCF assigned during CSCF discovery is not a requirement in this release. Procedures to allow registration time Proxy-CSCF reassignment may be considered in future releases.

Procedures shall be supported to allow assigning different Proxy-CSCFs when a user registers from multiple UE(s) simultaneously.

Network initiated Proxy-CSCF reassignment is not a requirement.

The use of additional elements to be included in the SIP signalling path is optional. Such additional elements may provide functions as described in clause 4.14 and Annex I.