This clause contains concepts for the relation between the resource reservation procedure and the procedure for end-to-end sessions.
A precondition is a set of constraints about the session, which are introduced during the session initiation. The recipient of the session generates an answer, but does not alert the user or otherwise proceed with session establishment until the preconditions are met. This can be known through a local event (such as a confirmation of a resource reservation), or through a new set of constraints sent by the caller.
The set-up of a "QoS-Assured" session will not complete until required resources have been allocated to the session. In a QoS-Assured session, the QoS bearer for the media stream shall be successfully established according to the QoS preconditions defined at the session level before the UE may indicate a successful response to complete the session and alert the other end point. The principles for when a UE shall regard QoS preconditions to be met are:
A minimum requirement to meet the QoS preconditions defined for a media stream in a certain direction, is that an appropriate IP-CAN bearer is established at the local access for that direction.
Segmented resource reservation is performed since the end points are responsible to make access network resource reservations via local mechanisms.
The end points shall offer the resources it may want to support for the session and negotiate to an agreed set. Multiple negotiation steps may be needed in order to agree on a set of media for the session. The final agreed set is then updated between the end points.
The action to take if a UE fails to fulfil the pre-conditions (e.g. failure in establishment of an RSVP session) depends on the reason for failure. If the reason is lack of resources in the network (e.g. an admission control function in the network rejects the request for resources), the UE shall fail to complete the session. For other reasons (e.g. lack of RSVP host or proxy along the path) the action to take is local decision within the UE. It may for example 1) choose to fail to complete the session, 2) attempt to complete the session by no longer requiring some of the additional actions.
The following cases exist in the context of using "QoS-Assured" preconditions for IMS:
The IMS session requires the reservation of additional bearer resources, and the UE requires confirmation from the other endpoint of the fulfilment of the pre-conditions related to this resource reservation. An endpoint may not require the reservation of bearer resources, and may therefore immediately indicate the local fulfilment of the pre-conditions. One example of such SIP endpoint is the MGCF used for PSTN interworking. In these cases, one or both of the reservation confirmation messages may not be sent.
The IMS session does not require the reservation of additional bearer resources, and both endpoints indicate in their initial session setup message that the pre-conditions are fulfilled.
The IMS session does not require the reservation of additional bearer resources, and the endpoints do not use the mechanism to indicate "QoS-Assured" pre-conditions.
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.
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.
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.
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.
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.
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.
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.
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 126.96.36.199 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:
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.
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.
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:
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 RFC 3263 may be used. For example, a NAPTR query and then a SRV query may be used to get the IP address of the AS.
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.
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.
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 RFC 3966), ENUM translation needs to be performed as described in clause 188.8.131.52, 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:
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.
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.
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.
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.