4.13 Identification of IMS communication Services

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

4.13.1 General

This clause describes the architectural requirements for the identification of IMS communication services.

4.13.2 Identification of IMS communication Services

An IMS Communication Service Identifier (ICSI) provides a framework for the identification of IMS communication services utilising the IMS enablers. An IMS communication service is provided via the use of the IMS enablers. At terminals, the use of a communication service identifier is similar to the use of the port concept in TCP/IP, in that it allows applications in a terminal and the network that use SIP for communication purposes to be identified. In the terminal this means dispatching a SIP message to the correct application, and in the network it means selection of the correct application server over ISC. Examples of IMS based applications and communication services are OMA messaging and OMA PoC.

An IMS communication service defines restrictions to which SIP procedures are possible within a single SIP session or standalone transaction and how those SIP procedures are used. The IMS communication service contains an aggregation of zero, one, or several media components and the service logic managing the aggregation, represented in the protocols used. Its behaviour and characteristics may be standardized as done for the two examples above, or proprietary and specific for e.g. an operator or an enterprise.

A service description specifies this behaviour and states e.g. the allowed media combinations and state transitions as a consequence of signalling and use of IMS enablers in the network and terminals.

NOTE 1: The application server(s) required to support the IMS communication service are required to be included in the path of the standalone transaction or SIP session at the establishment of the SIP dialogue and therefore can not be linked in after the initial SIP request, i.e. once a SIP session has been established, it is not possible to change the IMS communication service for that session. A UE can establish a new SIP session with another IMS communication service identifier if it is required to add a media that is not supported by the existing IMS communication service.

The need of applying a service identifier is to be taken within the specification of each individual service.

The communication service identifier identifies IMS communication services and shall be included in the relevant SIP methods.

The IMS communication service identifier shall fulfil the following requirements:

1. It shall be possible for the UE and an Application Server (AS) to set the IMS communication service identifier in a SIP request, e.g. in the REGISTER and INVITE request.

2. Based on operator policy the S‑CSCF or an AS shall be able to validate an IMS communication service identifier in a SIP request. This includes e.g. to check the syntactical correctness of a service identifier, and policing the usage of a communication service identifier. It shall also be possible for the S‑CSCF and an AS to indicate that the value of the IMS communication service is validated. An asserted IMS communication service identifier shall be able to be indicated by the service in SIP responses to the SIP request along with information that the IMS communication service identifier is asserted.

NOTE 2: If the asserted IMS communication service provided in the SIP response differs from the requested IMS communication service, the UE can make a local decision on whether it wish to continue the session. The UE will ignore any IMS communication service it does not support. User interaction is not needed.

NOTE 3: If the asserted IMS communication service provided in the SIP response differs from the requested IMS communication service, the VPLMN can make a local decision on whether it wish to continue the session. If continuing, the asserted IMS communication service is used in VPLMN for the remainder of the session (e.g. to provide service aware charging).

3. It shall be possible, e.g. for the UE, S‑CSCF and AS, to identify an IMS service uniquely by the IMS communication service identifier.

4. It shall be possible for the S‑CSCF to invoke appropriate service logic based on the IMS communication service identifier contained in a SIP request, e.g. route a SIP request containing a service identifier based on initial filter criteria to the correct AS.

5. It shall be possible for the UE to invoke appropriate application based on the IMS communication service identifier contained in a received SIP request.

6. It shall be possible for the UE to indicate its service capabilities to the network, e.g. during registration, using the IMS communication service identifier.

NOTE 4: The UE does not need to indicate all the service capabilities it supports to the network.

7. It shall be possible for the network to inform the UE about service capabilities, represented by ICSIs, of the network.

8. The structure of the IMS communication service identifier shall be as simple as possible, i.e. the IMS communication service identifier shall be limited to identify a service.

9. Based on operator policy S‑CSCF and AS shall consider the IMS communication service identifier for online and offline charging, e.g. put appropriate data into call detailed records.

10. The communication service identifier shall be capable of being an input into the policy control and charging rules.

11. It shall be possible to use the IMS communication service identifier as a means to authorize whether a subscriber is allowed to initiate or receive request for a communication service.

12. The communication service identifier shall be taken into account when selecting the correct UE(s), if multiple UEs are registered for the same Public User Identity(s).

13. The usage of communication service identifiers shall not adversely affect interoperability between IMS networks and interoperability with external SIP networks and CS networks. The behaviour of a network receiving the IMS requests without an IMS communication service identifier is a matter of operator policy. Usage of communication service identifiers shall not decrease the level of interoperability with networks and UEs that are unaware of the communication service identifier.

14. It shall be possible for the IMS network and UE to support communications that do not use a communication service identifier. In the case that an IMS communication service identifier is not present then the network may assume a particular IMS communication service.

15. The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.

16. The usage of communication service identifiers shall not require additional user interaction, i.e. the communication service identifier is assumed to be "added" by the UE that initiates the communication.

17. Where a communication service needs to be identified, one requested IMS communication service identifier shall be included by the originator of the session in the SIP method that initiates a SIP dialogue or standalone transaction. In addition to the requested IMS communication service, the supported IMS communication services may be included.

18. This version of the specification does not require the capability to use multiple requested IMS communication service identifiers in the SIP method that initiates a SIP dialogue or standalone transaction. However, the protocol implementation shall nonetheless be prepared to transport more than one requested IMS communication service identifier and the network shall be prepared to handle the situation if multiple IMS communication service identifiers are received but the network is only required to take action on one of the values. The same applies for the UE.

19. To facilitate service aware charging for roaming, it shall be possible to provide an asserted IMS communication identifier service to the VPLMN.

The network and the terminal shall be able to continue operation as defined in 3GPP Release 5 and 3GPP Release 6.

The communication service identifier shall be available at least in the following interfaces:

– ISC, Gm, Ma, Mi, Mj, Mk, Mw, Mg, Mr, Mr′;

– Cx; Dx (e.g. as part of the iFC);

– Rx, N5;

– Rf, Ro.

NOTE 5: The communication service identifier does not replace the public service identity (PSI). The communication service identifier would be used to indicate the communication service used to access the service addressed via a PSI, and is required to identify the communication service even when SIP requests are sent towards another entity without using a PSI.

4.13.3 Identification of IMS applications

An IMS application is an application that uses an IMS communication service(s) in order to provide a specific service to the end-user. The IMS application uses specific IMS Communication Service(s) and provides the end user service through the reuse of the SIP communication part of service. The IMS application does not extend the definition of the IMS communication service. The IMS application reference identifies the application utilising the IMS communication service.

Figure 4.13-1: IMS applications on top of an IMS communication service

The IMS application reference is used to identify the IMS applications other than the default for the IMS communication service. The IMS application reference has significance at the UE and the SIP AS behaving as SIP endpoints. The means to transport the IMS application reference is defined within the IMS communication services. When used, it shall be possible to transport the IMS application reference on at least on the following interfaces:

– ISC, Gm, Ma; Mi, Mj, Mk, Mw, Mg, Mr, Mr′, Rx, N5, Rf, Ro.

It shall be possible to register the IMS application reference. The IMS application reference can be taken into account when selecting the correct UE(s), if multiple UEs are registered for the same Public User Identity(s).