Content for  TS 23.228  Word version:  19.0.0

This clause describes the architectural requirements for the 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. 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.
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.
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.

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.

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

IMS generally provides services to end user customers of a network operator by directly supporting multimedia communications services to or from that operator's customers. However IMS may also be used in a number of other configurations where the capabilities of IMS are used to support CS domain customers of an IMS operator or in various other kinds of business arrangements where the capabilities may be used to support interconnection of other networks. Clause 4.15.2 describes several types of configurations in which IMS might be used to support such network interconnection. These are not intended to represent all possible applications of IMS, but rather provide some basis for the mechanisms by which IMS provides these transit functionalities. Further description of IMS transit network procedures are found in Clause 5.4a.2 and Clause 5.19. Clause 4.15.3 describes the cases in which IMS application services can be provided in relation to the IMS transit traffic.

There are at least three general cases in which IMS may be used for transit network support. These could be classified as in the following:

1. IMS operator providing transit functionality for its own, non-IMS (CS domain), customers:
   In this case the operator is serving its own customers, some of which have been migrated to IMS while others are still CS Domain subscribers. In this case SIP traffic arrives at a configured entry point and PSTN traffic arrives at the operator's MGCF. This is similar to the normal Mobile Terminating cases for IMS, but in this case the CS domain subscribers do not have an IMS subscription. For the case where the destination user is not an IMS subscriber, the operator needs to route the session to the CS domain.
2. IMS operator providing transit functionality to enterprise networks:
   In this case the operator is serving as a transit network for an enterprise IP network and provides connectivity to both PSTN and IP endpoints. Traffic from the enterprise network arrives at a provisioned routing entity and needs to be routed to either an IP network or to the PSTN depending on the terminating endpoint.
3. IMS operator providing transit functionality to other network operators:
   In this case the operator is serving as an IMS session based routing backbone for a PSTN operator or another IP network and provides connectivity to both PSTN and IP endpoints (PSTN ↔ PSTN, IP ↔ IP, PSTN ↔ IP). Traffic from the PSTN operator arrives at configured MGCFs for translation to SIP. IMS traffic arrives at a configured entry point. In either case the operator needs to route the traffic to either an IP network or to the PSTN depending on the terminating endpoint.

An IMS operator can provide transit functionality as above in addition to (originating or terminating) IMS services. In these situations analysis of an incoming SIP request is required before it can be determined whether transit or terminating services need to be provided for this request.

When IMS provides transit functionality to other network operators or enterprise networks, the IMS may also provide IMS applications services to the network operator or enterprise network.

The Transit service invocation shall be performed based on local configured Transit invocation criteria that are provided for the specific transit scenario. The Transit invocation criteria for invocation shall have the possibility to take into account,

• (served) preceding network,
• (served) succeeding network, and
• other additional session information.

Similar to the initial filter criteria for a user profile, the Transit invocation criteria may have service point triggers based on different information in the request, such as source/destination, SIP method, session case, SIP header, and SIP body. The service invocation procedure shall support suppression/avoidance of conflicting services, multiple invocations of the same service and loopback scenarios. The IMS application services provided can be classified as:

1. Originating IMS application services:
   In this case the IMS operator provides IMS application services for SIP traffic being received from the served network operator or enterprise network. The application services, appropriate for the received SIP traffic, will be invoked when received from the served network, after which the traffic is routed towards the destination endpoint.
2. Terminating IMS application services:
   In this case the IMS operator provides IMS application services for SIP traffic destined to a served network operator or enterprise network. The application services, appropriate for the received SIP traffic, will be invoked when the served network has been identified as the next network, or when the traffic has been identified as destined to the served network.