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:
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.
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.
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.
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.
It shall be possible for the UE to invoke appropriate application based on the IMS communication service identifier contained in a received SIP request.
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.
It shall be possible for the network to inform the UE about service capabilities, represented by ICSIs, of the network.
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.
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.
The communication service identifier shall be capable of being an input into the policy control and charging rules.
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.
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).
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.
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.
The usage of communication service identifiers shall not restrict the inherent capabilities of SIP.
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.
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.
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.
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:
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.
(not reproduced yet)
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:
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).
Based on operator preference, border control functions may be applied between two IM CN subsystem networks or between an IM CN subsystem network and other SIP based multimedia network. These functions are provided by the IBCF and include:
Controlling transport plane functions;
Supporting functions to allow establishing communication between disparate address realms' SIP applications;
Supporting functions to allow establishing communication between IM CN subsystems using different media codecs based on the interworking agreement and session information;
Providing network configuration hiding to restrict the following information from being passed outside of an operator's network: exact number of S-CSCFs, capabilities of S-CSCFs, or capacity of the network, etc;
Screening SIP signalling information based on source/destination and operator policy (e.g. remove information that is of local significance to an operator) and optionally, for an IBCF located in the home network, policing the IMS Communication Service ID;
Generation of CDRs;
Invoking an IWF when interworking between different SIP profiles or different protocols (e.g., SIP and H.323) is necessary; in this case the IWF acts as an entry point for the IMS network;
Selecting the appropriate signalling interconnect.
Indicating whether an incoming SIP request is to be handled as an originating request by subsequent nodes in the IMS network.
For an originating session leaving an IBCF, the IBCF of the originating network, if configured through operator policies, invokes an AS for the signing of attestation and identity information if available in the incoming request. The IBCF includes the signed information in the outgoing request.
For a terminating session entering the IBCF without attestation information, the IBCF adds, if configured through policies, gateway attestation information based on the network from which the request was received.
For a terminating session entering the IBCF with signed attestation information, the IBCF, if configured through policies, invokes an AS for signature verification.
If border control concepts are to be applied in an IMS network, the IBCF acts as an entry point for this network (instead of the I-CSCF), and also acts as an exit point for this network.
Based on local configuration, the IBCF may perform transit routing functions (see clause 5.19).
More detailed description of these functions is provided in Annex I.
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:
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.
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.
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.
(not reproduced yet)
Figure 4.15.3-1: IMS application services reference point for transit network scenarios
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:
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.
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.
The Transit and Roaming Function is the combined functionalities of the transit network functions as defined in clause 4.15 and the roaming specific functions defined in this clause.
The following architectural requirements apply:
The P-CSCF, S-CSCF, the Transit and Roaming Function, and other nodes performing routing procedures in different networks may control the application of OMR procedures by indicating in the signalling whether an IBCF/TrGW should not apply OMR.
In order to allow scenarios where the media is not routed through the originating HPLMN, IBCFs handling incoming requests to the network should support OMR and allow bypass of TrGWs. Anchoring of media may be controlled via outgoing IBCFs.
The HPLMN shall decide whether to perform the loopback procedure based on local policy and on knowledge of the support of the procedure in the VPLMN.
The VPLMN shall be provided by the HPLMN with enough information to determine whether home routing has been applied (or has not been applied):
The HPLMN shall send an indication to the VPLMN that this session set-up is a loopback to allow differentiation from any other incoming call. By this means the VPLMN is able to apply the correct treatment for this looped incoming leg incl. charging and routing decisions.
If local policy requires access to BGCF routing data to make the loopback decision for a particular originating INVITE request, then the loopback decision should be performed in the BGCF. Else it should be performed in the S-CSCF.
The Transit and Roaming Function shall perform call routing towards the terminating network by selecting appropriate egress point (e.g., MGCF for CS/PSTN, IBCF to other IMS networks, or I-CSCF for termination in own network). The Transit and Roaming Function may use information such as originating UE location information to select a nearby egress point for media anchoring.
The VPLMN may provide the HPLMN with a reference to the preferred Transit and Roaming Function to steer the selection of the Transit and Roaming Function. If the VPLMN does not provide the Transit and Roaming Function address then the HPLMN shall use the default derived address for the VPLMN.
When the HPLMN operator does not use loopback to the Transit and Roaming Function in VPLMN, the HPLMN shall be able to anchor the media. This ensures that the signalling and media are routed together.
An overview of the principles and flows of the Roaming Architecture for Voice over IMS with Local Breakout are depicted in Annex M, clause M.3.
In this scenario, the anchor point for the IP address for both the IMS signalling and media traffic is in the home network for a roaming UE, i.e. for 3GPP systems, the GGSN, PGW or UPF for a roaming UE is in the HPLMN of the UE.
The following architecture requirements apply:
The P-CSCF is located in the HPLMN
Additional architecture requirements and functions that are needed to support IMS services with home routed traffic are depicted in Annex W for EPS and in Annex Y for 5GS.