5 Functional requirements of network entities

23.2183GPPIM call modelIP Multimedia (IM) session handlingRelease 17Stage 2TS

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

5.1 Architecture for service provision for IP multimedia subsystem

5.1.1 General

NOTE: Not all interfaces shown are within the scope of this document.

Figure 5.1.1: Functional architecture for support of service provision for IP multimedia subsystem

Figure 5.1.1 illustrates the architecture with the S-CSCF communicating to Application Servers via the IP multimedia service control (ISC) interface. The Application Servers can be:

– SIP Application Servers – which may host and execute services. It is intended to allow the SIP Application Server to influence and impact the SIP session on behalf of the services;

– the IM-SSF – which is a particular type of application server the purpose of which is to host the CAMEL network features (i.e. trigger detection points, CAMEL Service Switching Finite State Machine, etc) and to interface to CAP as specified in 3GPP TS 29.078 [14];

– the OSA service capability server (OSA SCS) which interfaces to the OSA framework Application Server and which provides a standardized way for third party secure access to the IM subsystem. The OSA reference architecture defines an OSA Application Server as an entity that provides the service logic execution environment for client applications using the OSA API as specified in 3GPP TS 29.198 [12]. This definition of Application Server differs from the definition of Application Server in the context of service provisioning for the IM subsystem, i.e. the entity communicating to the S-CSCF via the ISC interface;

– in addition a specialized type of SIP Application Server, the service capability interaction manager (SCIM) which performs the role of interaction management between other application servers.

All the Application Servers, (including the IM-SSF and the OSA SCS) behave as SIP application servers on the ISC interface.

5.1.2 Provision of media resources

In addition the Application Servers can also interact with the MRFC via the S-CSCF (ISC, Mr), directly via the Mr’ interface and via the Cr interface in order to control Multimedia Resource Function processing and can interact with the MRB (Rc interface, or Mr, and Mr’ interfaces) in order for appropriate media resources to be assigned to calls (see clause 8 and clause 13). This is shown in figure 5.1.2. The AS can request MRF resources directly based on preconfigured addresses and DNS lookup, or indirectly using an MRB function, which will determine the most suitable resource (see clause 13).

An application server can provide the MRB with information to assist the MRB in determining the most appropriate resource. Aside from information on type of resource required, this can include information on other supporting MRBs in other networks, e.g. the visited network of a roaming user, or more information on the location of the endpoint to which the media is to be delivered, such that this may assist in determining the best location for proving the MRF.

NOTE: In this release direct interaction between an MRFC and a Transit Function has not been specified.

NOTE: An I-CSCF, S-CSCF can also use the resources of the MRF directly, or via an MRB, without going via an AS.

Figure 5.1.2: Functional architecture for support of media resources for IP multimedia subsystem

5.1.2A Border control concepts for the ISC interface

3GPP TS 23.228 [7] subclause 4.14 identifies the possibility of border control functions between two IM CN subsystems or between an IM CN subsystem and other SIP based multimedia network. Additional functionality may also be required on the ISC interface where an application server provided by a third-party service provider is supported.

An additional functionality called an ISC gateway function is defined as shown in figure 5.1.2A.

Figure 5.1.2A: ISC gateway function

The functions of the ISC gateway function are as follows:

– network configuration hiding (as for the IBCF);

– application level gateway (transcoding is not applicable for ISC gateway function);

– transport plane control, i.e. QoS control (as for the IBCF); and

– screening of SIP signalling (as for the IBCF).

NOTE 1: Additional functionality may be determined in later releases of this document. As future functionality could require knowledge of all transactions associated with an AS from the S-CSCF for a particular session / dialog, care is needed to route all such transactions through the same ISC gateway function.

While the ISC gateway function can alter the contents of the protocol on the ISC interface, the information carried should still conform to that required for the ISC interface.

NOTE 2: When this functionality is used, the effect can be to remove information that is required by subsequent AS in the filter criteria chain. Therefore care needs to be excercised both in the order in which AS appear in the filter criteria chain, and in the functionality applies in this functional entity.

NOTE 3: If the ISC gateway function modifies SIP information elements (SIP header fields, SIP message bodies) caution needs to be taken that SIP functionality (e.g. routing, iFC chain and AS application) is not impacted in a way that could create interoperability problems with networks that assume that this information is not modified.

NOTE 4: In this release the ISC gateway function does not have functionalities to save screened information in outgoing message and recover the screened information in incoming message so care is needed both in the order in which the AS appear in the filter criteria chain, and in the functionality applied in the ISC gateway.

5.1.3 Border control concepts for other interfaces

3GPP TS 23.228 [7] subclause 4.14 identifies the possibility of border control functions between two IM CN subsystems or between an IM CN subsystem and other SIP based multimedia network. A number of the interfaces identified in the architecture in subclause 5.1.1 and subclause 5.1.2 can be between the networks controlled by different operators, specifically the Mr, Mr’ and Cr interfaces (for example between a third-party service provider and the visited network, or between the home network and the visited network.

When used on the Mr, and Mr’ interfaces, the IBCF should not be used to duplicate the functions normally performed by the MRF, even if the MRF is being accessed for another unrelated function. Rather, an MRF should be used for supporting those functions.

Both the SIP control package on the Cr interface, and the Mr interface when used in in-line aware MRB mode, can contain information that an operator, for example, would prefer not to exchange with another network operator. For this information, it may be appropriate to use the MRB either in the network of the application server, or the MRB in the network where the MRF is sought, to operate in in-line aware MRB mode and to remove such information.

The IBCF is not used on the Cr interface.

In normal operation, the communication between the application server and the MRF is a communication where those functional entities form the endpoint of the communication. Therefore any information included in the signalling is deemed by one endpoint to be essential to the functionality performed by the other. As such, configuration hiding, screening and privacy functions are not expected to be critical functions on any of these interfaces.

If the network is supporting optimisation of media paths, then the IBCF could well be required on the Mr and Mr’ interfaces to support optimal media routeing.

For the Mr and Mr’ interfaces, the IBCF may be used to support communication between the AS and the MRB, between the AS and the MRFC, between the S-CSCF and the MRB, between the S-CSCF and the MRFC.

Where this occurs, requests to the IBCF are sent over the Mx interface and requests from the IBCF are sent over the Mm interface (see subclause I.2 of 3GPP TS 23.228 [7]). Two IBCFs on either side of an interoperator boundary use the Ici interface (see subclause K.2 of 3GPP TS 23.228 [7]).

The IBCF providing IMS-ALG functions would be supported by TrGW functions using the Ix interface (see subclause I.2 of 3GPP TS 23.228 [7]), so the media from an MRFP may pass through the Izi interface where two TrGWs exist on either side of an interoperator boundary.

For the Rc interface, border control functionality can exist, but the mechanism are not specified. The IBCF is not used. Many techniques exist and are deployed for supporting border functions in HTTP, and any of these can be used on the Rc interface if they meet the needs of the deployer.

NOTE: For the Rc interface, the server can be decomposed into a front end https proxy and a back end MRB. The MRB will need to be available both to internal and external clients in different address spaces and with different security requirements. This could be done with a single server but then there will be two interfaces to it (internal and external) rather than one.

5.1A IMS communication service identifier (ICSI)

The purpose of identifying IMS communication services is to help triggering to application servers and internal routing in UEs. See 3GPP TS 23.228 [7] for further information on IMS communication services. This clause describes the IMS communication service concept principles.

An initial request for a dialog or a standalone transaction that is used for an IMS communication service can contain an identifier that identifies the IMS communication service related to this request or stand alone transaction. The identifiers for the IMS communication service are included by the originating UE in the initial request for a dialog or standalone transaction but these are unauthenticated. The initial request for a dialog or standalone transaction can also contain identifiers for the IMS communication services supported by the originating UE. The response to an initial request for a dialog or standalone transaction can contain identifiers for the IMS communication services that the responding UE supports. These identifiers are ICSI values. An ICSI value can be used as an SPT by iFC to route the initial requests for a dialog to AS that implement service logic as part of the IMS communication service provided it is first authenticated by the S-CSCF as a subscribed service for that user and that the contents of the request (SDP Media Types etc) are compatible with the IMS communication service identified by the ICSI value. An authenticated ICSI value can be included by the S-CSCF by analyzing the contents of the request (SIP header fields, SDP Media Types etc). The Authenticated ICSI value acts as a summary of the contents of a request. Care should be taken when designing services that for a given subscriber in a given network, the contents of any request (SIP header fields, SDP Media Types etc) correspond to zero or one ICSI so that the network can include the correct Authenticated ICSI value in the request. The ICSI value can be sent to ASes. An AS that is part of the trust domain can include an authenticated ICSI value and an AS that is outside the trust domain can include an unauthenticated ICSI value.

5.1B IMS Application Reference Identifier (IARI)

The IARI value identifies the application to be invoked by the terminating UE. When no IARI value is present in a request, the default application is assumed.

5.2 Service interaction with IP multimedia subsystem

5.2.1 Service Point Triggers (SPTs)

Service Point Triggers (SPTs) are those points in the SIP signalling on which Filter Criteria can be set. The following SPTs are defined:

– any initial known or unknown SIP method;

– registration type – indicates if the REGISTER request is initial registration, re-registration, or de-registration;

– presence or absence of any known or unknown header field;

– content of any known or unknown header field or of the Request-URI;

NOTE 1: The presence of a "gruu" parameter in the Request-URI as defined in IETF RFC 5627 [22] indicates that the request is targeted towards a GRUU. Requests targeted towards GRUUs can need different service logic handling to those targeted towards a public user identity. e,g a request targeted towards a GRUU normally would not be routed to voicemail.

– direction of the request with respect to the served user – either UE-originating or UE-terminating to registered user; UE-terminating to unregistered user or UE-originating for unregistered user; see 3GPP TS 29.228 [8] for the details of the direction information in service point trigger;

NOTE 2: REGISTER is considered part of the UE-originating. See 3GPP TS 24.229 [5] for further information about how to determine UE-originating or UE-terminating.

NOTE 3: The S-CSCF shall verify if the end user is barred before checking if any trigger applies for that end user.

– session description information.

5.2.2 Filter Criteria

A Filter Criteria triggers one or more SPTs in order to send the related request to one specific application server. The set of Filter Criteria that is stored for a service profile of a specific user is called "Application Server Subscription Information". In order to allow the S-CSCF to handle the different Filter Criteria in the right sequence, a priority shall be assigned to each of them. If the S-CSCF can not reach the specified Application Server, the S-CSCF shall apply the default handling associated with the trigger. This default handling shall be :

– to continue verifying if the triggers of lower priority in the list match; or

– to abandon verification of matching of the triggers of lower priority in the list; and to release the dialogue.

Therefore a Filter Criteria shall contain the following information:

– address of the Application Server to be contacted;

– priority of the Filter Criteria providing the sequence in which the criteria shall be applied;

– Trigger Point composed by 1 to n instances of the Service Point Triggers (SPTs). The SPTs may be linked by means of logical expressions (AND, OR, NOT, etc.);

– default handling ( as described above);

– optional Service Information that shall be added to the message body before it is sent to the Application Server (as an example this may include the IMSI for the IM-SSF).

– optionally an indication to include the incoming REGISTER request in the third party REGISTER request.

– optionally an indication to include the final response to the incoming REGISTER request in the third party REGISTER request.

The same priority shall not be assigned to more than one initial Filter Criteria for a given served user.

5.2.3 S-CSCF Filter Criteria processing

The S-CSCF shall request from the HSS the relevant set of iFCs that applies to the served user (i.e., registered, unregistered, or both). If the S-CSCF has a set of iFCs that is deemed valid (e.g., from a previous request), the S-CSCF need not request a new set.

In the case that multiple Filter Criteria are sent from the HSS to the S-CSCF, the S-CSCF shall check the filter criteria one by one according to their indicated priority when the S-CSCF receives a message via the Mw interface.

On reception of a REGISTER request, the S-CSCF shall send a third-party REGISTER request to each Application Server that matches the Filter Criteria sent from the HSS for the REGISTER request. The S-CSCF shall include in the third-party REGISTER request the incoming REGISTER request if indicated by the Filter Criteria. The S-CSCF shall include in the third-party REGISTER request the final response to the incoming REGISTER request if indicated by the Filter Criteria.

On an event that causes network-initiated deregistration, the S-CSCF shall send a third-party REGISTER request to each Application Server that matches the Filter Criteria sent from the HSS as if a equivalent REGISTER request had been received from the user deregistering that public user identity, or combination of public user identities.

On reception of any other request the S-CSCF shall:

1. set up the list of filter criteria for that request according to their priority – the sequence of the filter criteria shall not be changed until the request finally leaves the S-CSCF via the Mw interface again;

2. parse the received request in order to find out the Service Point Triggers (SPTs) that are included in it;

3. check whether the trigger points of the filter criteria with the next highest priority are matched by the SPTs of the request and

a) if it does not match the S-CSCF shall immediately proceed with step 4;

b) if it matches the S-CSCF shall:

i) add an Original Dialog Identifier (ODI) to the request which will allow the S-CSCF to identify the message on the incoming side, even if its dialog identification has been changed e.g. due to the Application Server performing third party call control;

ii) forward the request via the ISC interface to the Application Server indicated in the current filter criteria. The Application Server then performs the service logic, may modify the request and may send the request back to the S-CSCF via the ISC interface;

iii) proceed with step 4 if a request with the same ODI is received from the Application Server via the ISC interface;

4. repeat the above steps 2 and 3 for every filter criteria which was initially set up (in step 1) until the last filter criteria has been checked;

5. route the request based on normal SIP routing behaviour.

If an Application Server decides to locally terminate a request and sends back a final response for that request via the ISC interface to the S-CSCF, the S-CSCF shall abandon verification of the matching of the triggers of lower priority in the list.

NOTE 4: If AS has service logic whereby it wishes to send a request to the S-CSCF to continue with filter criteria evaluation from where it left off with the final response to the previous request, then a new request must be sent with data that can be used by the S-CSCF to determine where it left off with filter criteria evaluation. For example, a parameter can be included in the request that is also defined in a service point trigger.

Figure 5.2.1: Application triggering architecture

Each invoked Application Server/service logic may decide not to be engaged with the invoked session by indicating that during the very first SIP transaction when the Record-Route/Route is generated for subsequent SIP requests. The denial shall mean that subsequent requests shall not be routed to such Application Servers/service logic any more during the lifetime of that session. Any Application Server, which has determined that it will not receive subsequent requests for a session cannot revoke this determination by means of Initial Filter Criteria (iFC).

NOTE 5: Care should be taken in design of the Initial Filter Criteria when designing services to avoid unintended loops being setup, where requests from an Application Server may be sent back to the same Application Server. This does not imply that it is not allowed for requests to be sent back to the same Application Server when that is intended behaviour as part of the design of the service and the Application Server is able to handle this correctly. Special care should be taken for the case when an Application Server may act as an originating UA or B2BUA and may originate an initial request causing evaluation of Initial Filter Criteria.

5.2.4 Transit Invocation Criteria

A Transit Invocation Criteria triggers one or more SPTs in order to send the related request to one specific application server. The set of Transit Invocation Criteria is not user specific, but instead is based on e.g. the originating and terminating networks.

The handling of Transit Invocation Criteria is identical to the handling of Filter Criteria, as defined in subclase 5.2.2.

NOTE: The procedures in subclause 5.2.2 associated with the handling of SIP REGISTER request do not apply to the handling of Transit Invocation Criteria.

5.2.5 Transit Function Transit Invocation Criteria processing

The Transit Invocation Criteria are locally configured.

In case that multiple Transit Invocation Criteria is configured, the Transit Function shall check the criteria one by one according to their indicated priority when the Transit Function receives a message.

On reception of an initial request, or a standalone request, the Transit Function shall:

1. set up the list of Transit Invocation Criteria for that request according to their priority – the sequence of the criteria shall not be changed until the request finally leaves the Transit Function towards the terminating network;

2. parse the received request in order to find out the Service Point Triggers (SPTs) that are included in it, and in priority order for each Transit Invocation Criteria:

a) check whether the trigger points of the Transit Invocation Criteria are matched by the SPTs of the request;

b) if it matches the Transit Function shall:

i) add an Original Dialog Identifier (ODI) to the request which will allow the Transit Function to identify the message on the incoming side, even if its dialog identification has been changed e.g. due to the Application Server performing third party call control;

iii) proceed with next Transit Invocation Criteria in a) if a request with the same ODI is received from the Application Server via the ISC interface;

c) if it does not match, proceed with next Transit Invocation Criteria in a) for every Transit Invocation Criteria which was initially set up (in step 1) until the last criteria has been checked;

3. route the request based on normal SIP routing behaviour.

If an Application Server decides to locally terminate a request and sends back a final response for that request via the ISC interface to Transit Function, the Transit Function shall abandon verification of the matching of the triggers of lower priority in the list.