Content for  TS 23.228  Word version:  16.6.0

5.4.8  QoS-Assured Preconditions

5.4.9  Event and information distribution  Word‑p. 96

5.4.9.0  General |R6|

The S-CSCF and Application Servers (SIP-AS, IM-SSF, OSA-SCS) shall be able to send service information messages to endpoints. This shall be done based on a SIP Request/Response information exchange containing the service information and/or a list of URI(s) pointing to the location of information represented in other media formats. The stimulus for initiating the service event related information message may come from e.g. a service logic residing in an Application Server.

In addition, the end points shall also be able to send information to each other. This information shall be delivered using SIP based messages. The corresponding SIP messages shall be forwarded along the IMS SIP signalling path. This includes the S-CSCF but may also include SIP Application Servers. The information may be related or unrelated to any ongoing session and/or may be independent of any session. Applicable mechanisms (for e.g. routing, security, charging, etc) defined for IMS SIP sessions shall also be applied for the SIP based messages delivering the end-point information. The length of the information transferred is restricted by the message size (e.g. the MTU), so fragmentation and re-assembly of the information is not required to be supported in the UE. This information may include e.g. text message, http url, etc.

This mechanism considers the following issues:

• The IMS has the capability to handle different kinds of media. That is, it is possible to provide information contained within several different media formats e.g. text, pictures or video.
• The UE's level of supporting service event related information and its exchange may depend on the UE's capabilities and configuration.
• A UE not participating in the service related information exchange shall not be effected by a service related information exchange possibly being performed with another UE of the session.

(not reproduced yet)

Figure 5.8: Providing service event related information to related endpoint

Step 1.

When a service event occurs that the S-CSCF or the Application Server wishes to inform an endpoint about, the S-CSCF or the Application Server generates a message request containing information to be presented to the user. The contents may include text describing the service event, a list of URI(s) or other service modification information.

Step 2.

P-CSCF forwards the message request.

Step 3.

UE presents the service-related information, to the extent that it conforms to its capabilities and configuration, to the user.

Step 4.

Possibly after interaction with the user, the UE will be able to include information in the response to the S-CSCF.

Step 5.

P-CSCF forwards the response.

5.4.9.1  Subscription to event notifications |R6|  Word‑p. 97

The SIP-event notification mechanism allows a SIP entity to request notification from remote nodes indicating that certain standardised events have occurred. Examples of such of events are changes in presence states, changes in registration states, changes in Subscription authorization policies (see TS 23.141) and other events that are caused by information changes in e.g. Application Servers or S-CSCF.

It shall be possible to either fetch relevant information once or monitor changes over a defined time. It shall be possible for a user to subscribe to events related to his/her own subscription (e.g. when the user subscribes to his own registration state) or to events related to other users' subscription (an example is when a watcher subscribes to presence information of a presentity, see TS 23.141).

The S-CSCF is not mandated to stay in the path after the initial SubscribeEvent request and ACK has been exchanged, if the S-CSCF does not execute any functions for the subsequent requests and responses of the dialog. The example, in Figure 5.8a below, assumes that the S-CSCF does not want to execute any functions for the subsequent requests.

(not reproduced yet)

Figure 5.8a: Subscription to event in AS

Step 1.

The UE initiates a subscription to an AS requesting notification of any changes in specified information stored in the control of the AS

Step 2.

The P-CSCF remembers (from the registration process) the next hop CSCF for this UE, i.e., the SubscribeEvent is forwarded to the S-CSCF in the home network.

Step 3.

The S-CSCF invokes whatever service logic procedures are appropriate for this request.

Step 4.

The S-CSCF applies regular routing procedures and forwards the request to the next hop.

Step 5.

The AS acknowledges the SubscribeEvent request.

Step 6.

The S-CSCF forwards the acknowledgement to the P-CSCF.

Step 7.

The P-CSCF forwards the acknowledgement to the UE.

Step 8.

As soon as the AS sends an acknowledgement to accept the subscription, the AS sends an EventNotification message with the current information the UE subscribed to. The EventNotification is sent along the path set-up by the SubscribeEvent dialog to the P-CSCF allocated to the UE. Further notifications, if monitor of changes was requested, sent by the AS is sent along the same path.

Step 9.

The P-CSCF forwards the EventNotification to the UE.

Step 10.

The UE acknowledges the EventNotification.

Step 11.

The P-CSCF forwards the acknowledgement to the AS.

5.4.10  Void

5.4.11  Signalling Transport Interworking  Word‑p. 99

A Signalling gateway function (S-GW) is used to interconnect different signalling networks i.e. SCTP/IP based signalling networks and SS7 signalling networks. The signalling gateway function may be implemented as a stand alone entity or inside another entity (see TS 23.002). The session flows in this specification do not show the S-GW, but when interworking with PSTN/CS domain, it is assumed that there is a S-GW for signalling transport conversion.

5.4.12  Configuration and Routing principles for Public Service Identities |R6|

5.4.12.0  General

Depending on the service nature, different mechanisms may be used for configuration and routing of PSIs according to operator preference.

When PSIs are created, the uniqueness of a PSI shall be ensured. Note that only the username part of a PSI is definable within a predefined hostname(s).

Whenever possible, routing to/from a Public Service Identity (PSI) should be provided using basic principles used for IMS routing.

5.4.12.1  PSIs on the originating side

The Application Server hosting the PSI may be invoked as an originating Application Server. This can be achieved by modifying the filter information within the subscription information of the users intending to use the service identified by the PSI. The PSI is then made available to these users.

The SIP requests are directed to the corresponding Application Server hosting the service according to the originating filtering rules in the S-CSCF of the user who is using the service.

Such statically pre-configured PSIs are only accessible internally from within the IMS of the operator's domain where the PSI is configured.

5.4.12.2  PSIs on the terminating side

The Application Server hosting the PSI may be invoked as a terminating Application Server via information stored in the HSS. Such PSIs are globally routable and can be made available to users within and outside the operator domain, and can take the following form:

• Distinct PSIs are defined in TS 23.003. Distinct PSIs can be created, modified and deleted in the HSS by the operator via O&M mechanisms. Distinct PSIs can also be created and deleted by users using the Ut interface using the means described in clause 5.4.12.3 for subdomain-based PSIs.
• The distinct PSI may be activated in the HSS by the AS using the Sh interface.
• Wildcarded PSIs are defined in TS 23.003. Wildcarded PSI ranges can be created, modified and deleted in the HSS by the operator via O&M mechanisms. Specific PSIs within a wildcarded range can be created and deleted by users using the Ut interface to the AS hosting the wildcarded range, or by the operator via O&M mechanisms.

For both the distinct PSIs and wildcarded PSIs, there are two ways to route towards the AS hosting the PSI:

1. The HSS maintains the assigned S-CSCF information and ISC Filter Criteria information for the "PSI user" to route to the AS hosting the PSI according to IMS routing principles. In this case, the I-CSCF receives SIP requests at the terminating side, queries the HSS and directs the request to the S-CSCF assigned to the "PSI user". The S-CSCF forwards the session to the Application Server hosting the PSI according to the terminating ISC Filter Criteria.
2. The HSS maintains the address information of the AS hosting the PSI for the "PSI user". In this case, the AS address information for the PSI is returned to the I-CSCF in the location query response, in which case the I-CSCF will forward the request directly to the AS hosting the PSI.
   The AS hosting the PSI in combination with its entry in the HSS is referred to as "PSI user".

Figure 5.19d depicts a routing example for incoming session where the session request is routed directly to the AS hosting the PSI.

Figure 5.19e depicts an example routing scenario where the basic IMS routing via S-CSCF is used to route the session.

5.4.12.3  Subdomain based PSIs  Word‑p. 100

Subdomains defined for PSIs allow both operators and users to define specific PSIs within subdomains for specific applications. For this purpose, subdomains can be defined by the operator in the DNS infrastructure. Specific PSIs within a subdomain can be created and deleted by users using the Ut interface to the AS hosting the subdomain, or by the operator via O&M mechanisms.

Subdomain based PSIs are globally routable and can be made available to users within and outside the operator domain.

In this case, there are two ways to route towards the AS hosting the PSI:

1. When the subdomain name is defined in the global DNS, then the originating S-CSCF or a Transit Function receives the IP address of the AS hosting the PSI, when it queries DNS. The principles defined in IETF RFC 3263 [44] may be used. For example, a NAPTR query and then a SRV query may be used to get the IP address of the AS.
2. The PSI is resolved by the global DNS to an I-CSCF address in the domain where the AS hosting the PSI is located. The I-CSCF recognises the subdomain (and thus does not query the HSS). It resolves the same PSI to the address of the actual destination AS hosting the PSI using an internal DNS mechanism, and forwards the requests directly to the AS.

Figure 5.19f shows an example of DNS based routing of an incoming session from an external network. The routing from the external network leads to the entry point of the IMS subsystem hosting the subdomain of the PSI.

5.4.12.4  PSI configuration in the HSS

In order to support configuration of an AS hosting a PSI, the distinct PSIs and/or wildcarded PSI ranges hosted in the AS need to be configured in the HSS. The configuration shall include procedures to allow:

• Distinct PSIs and wildcarded PSI ranges to be configured in the HSS via operation and maintenance procedures,
• Authorization and verification of access as "PSI user" with the Public Service Identity hosted by the AS, e.g. for AS-originating requests,
• Access to "PSI user" information (e.g. the S-CSCF assigned) over the Cx reference point from the CSCF nodes,
• Defining the "PSI user" similar to the principle of IMS user, without requiring any subscription/access information (e.g. CS/PS domain data) that are required for IMS user.

Note that the PSI configuration in the HSS does not affect the filter criteria based access to an AS as defined in the user profiles.

5.4.12.5  Requests originated by the AS hosting the PSI

The AS hosting the PSI may originate requests with the PSI as the originating party. For such originating requests, the home IMS network shall be capable to perform the following functions:

• Network Domain Security, TS 33.210, shall be used where applicable.
• Charging requirements such as providing appropriate accounting and charging functions via the charging entities shall be supported according to TS 32.240.
• If the target identity is a Tel URI (as specified in IETF RFC 3966 [15]), ENUM translation needs to be performed as described in clause 4.3.5.2, and the request shall be routed based on the translation result appropriately.

Routing from the Originating AS hosting the PSI can be performed as follows:

1. If the AS supports routing capabilities (e.g. ENUM support, etc), the AS may forward the originating request to the destination network without involving a S-CSCF. If this option is applied where the target identity is a Tel URI, the AS shall perform an ENUM query and route the request based on the translation result.
2. If the AS does not support routing capabilities, the AS may forward the originating request to the IMS Transit Functions. The IMS Transit Functions will then route the session initiation request to the destination.
3. If the session requires the use of a S-CSCF: either the PSI has an S-CSCF assigned, in which case the AS forwards the originating request to this S-CSCF, which then processes the request as per regular originating S-CSCF procedures, or the PSI has no S-CSCF assigned, in which case the AS sends the session initiation request to an I-CSCF that will allocate an S-CSCF to the PSI.

To prevent fraudulent or unsecure IMS traffic possibly caused by AS originated requests, security and authentication procedures may be performed towards the AS.

5.4.13  Transcoding concepts |R8|  Word‑p. 101

IMS control plane entities, including the P-CSCF, Application Servers or (for inter-domain sessions) the IBCF, may check the SDP offer/answer information associated with session requests and responses, to determine the need for transcoding. If such a need is determined to exist, media transcoding resources are reserved from the MRFP (via the MRFC), the IMS-AGW, or the TrGW.

Transcoding requires knowledge of the codecs supported by the end points and may be invoked at the originating or terminating network based on interworking agreements (e.g. local policy) or service level agreement (SLA).

For more details concerning transcoding involving MRFC/MRFP interworking see clause 5.14, Annex P and TS 23.218, and for the IBCF/TrGW implementation consult clause 4.14 and Annex I, clause I.3.3.