5.4 Procedures for IP multi-media sessions

23.2283GPPIP Multimedia Subsystem (IMS)Release 18Stage 2TS

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

5.4.0 General

Basic IMS sessions between users will always involve two S‑CSCFs (one S‑CSCF for each). The session flow is decomposed into two parts: an origination part between the UE & the S‑CSCF and termination part between the S‑CSCF and the UE, including all network elements in the path.

A basic session between a user and a PSTN endpoint involves an S‑CSCF for the UE, a BGCF to select the PSTN gateway, and an MGCF for the PSTN.

The session flow is decomposed into three parts – an origination part, an inter-Serving‑CSCF/ MGCF part, and a termination part. The origination part covers all network elements between the UE (or PSTN) and the S‑CSCF for that UE (or MGCF serving the MGW). The termination part covers all network elements between the S‑CSCF for the UE (or MGCF serving the MGW) and the UE (or PSTN).

5.4.1 Bearer interworking concepts

Voice bearers from the IM CN subsystem need to be connected with the voice bearers of other networks. Elements such as Media Gateway Functions (MGW) are provided to support such bearer interworking. One of the functions of the MGW may be to support transcoding between a codec used by the UE in the IM CN subsystem and the codec being used in the network of the other party.

Default codecs to be supported within the UE are IP‑CAN dependent and hence are defined in the respective IP‑CAN specific documents. The use of default codecs within the UE enables the IM CN subsystem to interwork with other networks on an end to end basis or through transcoding.

The IM CN subsystem is also able to interwork with the CS networks (e.g. PSTN, ISDN, CS domain of some PLMN) by supporting transcoding in the IMS MGW element. Furthermore to allow interworking between users of the IM CN subsystem and IP multimedia fixed terminals and other codecs may (this is implementation dependent) be supported by the MGW.

In order to support existing network capabilities, it is required that IMS supports endpoints (e.g., UE, MRFP, MGCF for interworking with the PSTN) able to send or receive DTMF tone indications using the bearer, i.e. inband signalling. An additional element for bearer interworking is the interworking of these DTMF tones and out-of-band signalling between one network and another. In such a case, the MGW shall provide tone generation and may provide detection under the control of the MGCF.

5.4.2 Interworking with Internet

Depending on operator policy, the S‑CSCF may forward the SIP request or response to another SIP server located within an ISP domain outside of the IM CN subsystem.

It is possible that the external SIP client does not support one or more of the SIP extensions required for IMS end points to set up IMS sessions (e.g. Preconditions, Update, 100Rel) as described in TS 24.229 [10a], then the UE or other SIP user agents within the IMS should be able to fall back to SIP procedures which allow interworking towards the external client. Depending on the home network operator policy, the network may restrict session initiation requests towards and from external SIP clients without the support of SIP extensions defined for IMS sessions.

5.4.2a IP version interworking

Following interworking scenarios exist:

Application Level Interworking

It should be possible for users connected to an IMS network to communicate with users that are connected to SIP based networks that use a different IP version via interworking or that are in a separate addressing range (e.g. NA(P)T functionality is set at the border of the IMS). Annex I describes in more detail how such interworking is performed for IMS.

Transport Level Interworking

Inter-working also includes tunnelling level interconnection of IMS networks via transit networks that use a different IP version using for example, configured tunnels as described in TS 23.221 [7]. Figure 5.5b below shows an example configuration scenario where two IPv6 IMS networks are connected via an IPv4 network.

Figure 5.5b: Example tunnelling of IPv6 traffic over IPv4 networks

5.4.3 Interworking with PSTN

The S‑CSCF, possibly in conjunction with an Application Server, shall determine that the session should be forwarded to the PSTN. The S‑CSCF will forward the Invite information flow to the BGCF in the same network.

The BGCF selects the network in which the interworking should occur, and the selection of the interworking network is based on local policy.

If the BGCF determines that the interworking should occur in the same network, then the BGCF selects the MGCF which will perform the interworking, otherwise the BGCF forward the invite information flow to the BGCF in the selected network.

The MGCF will perform the interworking to the PSTN and control the MG for the media conversions.

The high level overview of the network initiated PSTN interworking process is shown in figure 5.6.

Figure 5.6: Network based PSTN interworking breakout process

5.4.4 Requirements for IP multi-media session control

In order for operators to be able to offer a "carrier-grade" IP multimedia service, and to require bearers whose features (e.g. Bandwidth) are coherent with the media components negotiated through CSCFs, the following features shall be offered:

1. Both end points of the session shall be able to negotiate (according to service /UE settings,) which resources (i.e. which media components) need to be established before the destination party is alerted. The session signalling shall ensure that these resources (including IP-Connectivity Access Network resources and IP multimedia backbone resources) are made available or reserved before the destination UE rings.

This should nevertheless not prevent the UE from offering to the end-user the choice of accepting or rejecting the components of the session before establishing the bearers.

2. Depending on regulatory requirements, the IP multimedia service shall be able to charge the originating party for the IP-Connectivity Access Network service of both originating and destination side or when reverse charging applies to charge the terminating party for the IP-Connectivity Access Network service of both originating and terminating side. This implies that it should be easy to correlate CDR held by the IP-Connectivity Access Network service with a session.

3. The session control function of IP multimedia network of an operator (CSCF) shall be able (according to operator choice) to have a strict control (e.g. on source /destination IP address, QoS) on the flows associated with session established through SIP entering the IP multimedia bearer network from IP-Connectivity Access Network service. This does not mean that CSCF is the enforcement point (which actually is the Gateway between the IP-Connectivity Access Network and the IP multimedia network) but that the CSCF may be the final decision point for this control.

4. The session control and bearer control mechanisms shall allow the session control to decide when user plane traffic between end-points of a SIP session may start/shall stop. This allows this traffic to start/stop in synchronisation with the start/stop of charging for a session.

5. The IP-Connectivity Access Network service shall be able to notify the IP multimedia session control when the IP-Connectivity Access Network service has either modified or suspended or released the bearer(s) of a user associated with a session (because e.g. the user is no longer reachable).

6. The solution shall comply with the architectural rules relating to separation of bearer level, session control level, and service level.

5.4.5 Session Path Information

5.4.5.1 Session Path Information during Registration and Session Initiation

During registration and session initiation there are SIP mechanisms, which provide the means to determine the session path.

After registration the P‑CSCF stores the S‑CSCF name, possibly IBCF names and the S‑CSCF stores the P‑CSCF name and possibly IBCF names (see 4.3.4) as part of the UE related information.

There is a need to store the session path that is determined during the session initiation request in order to route the subsequent session requests through this determined path. This is needed in order to route these session requests through certain nodes, e.g. the ones performing Service Control, or interconnect functions. CSCFs are assumed to perform certain actions:

1. CSCFs (Proxy and Serving) store a certain part of the session path determined during session initiation. This allows CSCFs to generate requests that traverse all elements on a Route path.

2. The P‑CSCF shall check correct usage of the header values. Should an UE build inaccurate header(s) in a SIP request, the P‑CSCF may reject the request. If an operator policy requires enforcing the routes stored in P‑CSCF, the P‑CSCF shall overwrite the header(s) provided by the UE with the appropriate values.

5.4.5.2 P‑CSCF in the Session Path

All SIP signalling to or from the UE traverses the P‑CSCF.

5.4.5.3 S‑CSCF in the Session Path

All initial requests to or from the UE traverse the S‑CSCF assigned to the UE. The S‑CSCF uses the "Record-Route" mechanism defined in IETF RFC 3261 [12] to remain in the signalling path for subsequent requests too; in short terms: the S‑CSCF "record-routes". This is considered the default behaviour for all IMS communication. However, if Application Servers under operator control guarantee the home control of the session, then it may not be required that all subsequent requests traverse the S‑CSCF. In such cases the operator may choose that the S‑CSCF does not "record-route". The detailed record-route behaviour is configured in the S‑CSCF, e.g. on a per-service basis. The S‑CSCF decides whether it performs record-routing or not based on operator configuration in the S‑CSCF.

See also Annex F for background information.

5.4.6 End-user preferences and terminal capabilities

5.4.6.0 General

Due to different capabilities of the originating and terminating terminals, it might not be possible to establish all the media suggested by the originator for a particular session. In addition, the destination user may have different preferences of type of media depending on who is originating and on the situation e.g. being in a meeting or driving the car, etc.

5.4.6.1 Objectives

The general objectives concerning terminal capabilities and end-user behaviour are listed below.

– The capabilities of the terminal have impact on the SDP description in the SIP session flows, since different terminals may support different media types (such as video, audio, application or data) and may have implemented different set of codecs for audio and video. Note that the capabilities of the terminal may change when an external device, such as a video camera is attached to the terminal.

– The configuration of the terminal changes the capabilities of the terminal. This can be done by attaching external devices or possibly by a user setting of certain parameters or profiles in the terminal.

– The preferences of the destination user may depend on who is originating the session and on the situation. Cost, associated with the session, may also be another factor, i.e. depending on time of the day or day of the week etc. Due to this reason the user may want to accept or reject certain media components.

– The available resources in the network play an important role, as certain media streams, consuming high bandwidth, may be denied. Therefore, before the user is alerted that the session set up is successful, it is assumed that the network has guaranteed and has reserved the needed resources for one or several media streams of the session. This does not preclude the possibility for the user to indicate his/her preferences regarding the session also after the alerting, in which case the initial resource reservations may have to be modified.

– End-to-end quality of service may be provided by using a variety of mechanisms, including guaranteed end-to-end QoS and best effort. The network may not be able to guarantee the requested end-to-end QoS. This may be the case when the user is establishing sessions through the public Internet. On the other hand, certain sessions, with the agreement of the initiating and terminating endpoints, should have the right to go through even without having the requested QoS guarantee.

5.4.6.2 End-user expectations

From the end-user point of view the following user interactions can be listed:

– For outgoing sessions, it is assumed that the user would like to select certain parameters that define the proposed session. This can be pre-configured as preferences or defined on a per session basis.

– For incoming sessions, it is assumed that the terminal will establish a dialogue with the user. Such dialogue allows the user to manually accept some of the proposed parameters by the originator. This is typically media type (audio, video, whiteboard) and different quality parameters per media type. As an alternative, the user preferences may be pre-configured.

– Before establishing or accepting a new session, the user may define or agree on the following parameters. Some of these parameters may be pre-configured and others are defined on a per session basis.

1. Type of media, i.e. audio, video, whiteboard, etc. This represents the user preferences of media types.

2. Combination of QoS attributes and selection of codec. This represents the quality of the media component, the cost and the probability of availability of resources both in the access network and in the core network.

3. Subset of capabilities used in the terminal. Terminals can have different set of capabilities. However, the user may or may not want to use the maximum set of capabilities. For instance, a user might want to establish a low cost video session with a small window on the screen.

4. End-to-end quality of service. For certain media streams, the user may want assured end-to-end QoS while for other streams the QoS may be optional or even not desired at all (best effort).

5.4.6.3 Mechanism for bearer establishment

In order to fulfil the above requirements, it is needed that the destination user can be pre-alerted before the bearer establishment and negotiation and IP-Connectivity Access Network bearer activation has taken place. This gives room for the destination user to choose the media streams and codecs required before an expensive resource (as the air interface is) is established.

Figure 5.7 shows the mechanism for the bearer establishment in which the pre-alerting occurs before the initial bearer creation procedures are performed. Furthermore, a user interaction may also occur after the initial bearers are created as shown in figure 5.7. If the session originator receives multiple provisional responses for the same session indicating that the session has been forked in the network, the UE may choose to process a pre-configured number of responses. In the case of multiple responses, the resources requested by the UE shall be the "logical OR" (i.e. least upper bound) of the resources indicated in the multiple responses to avoid allocation of unnecessary resources. The UE shall never request more resources then was originally proposed in the Original INVITE.

The "Other x‑CSCFs" entity in figure 5.7 comprises several CSCFs: I‑CSCF and S‑CSCFs. For the sake of simplicity only the IP-Connectivity Access Network is shown, and the Policy Decision Functions have been omitted from the diagram.

Figure 5.7: Bearer establishment showing optional pre-alerting

1. UE(A) starts a Session Initiation procedure to UE(B) that includes an SDP proposal.

The steps 2-4 are optional and may depend on terminal implementation and/or terminal pre-configured settings.

2. The user at UE(B) is pre-alerted.

3. An indication of the pre-alerting may be sent towards UE(A).

4. User at UE(B) will then interact and express his/her wishes regarding the actual session.

5. UE(B) generates accepted SDP based on terminal settings, terminal pre-configured profiles and optionally the user’s wishes.

6. The accepted SDP is forwarded to UE(A) in the payload of a reliable SIP response.

7. Initial bearer creation procedure is performed. During this bearer creation step the resources in the UE(A)’s and UE(B)’s IP‑CANs are reserved. Bearer resources in external networks may also be reserved at this point.

The steps 8-10 are also optional and may be skipped.

8. Terminal at UE(B) starts ringing.

9. The alerting indication is sent towards UE(A).

10. User at UE(B) may interact and express his/her wishes regarding the actual session.

11. UE(A) and UE(B) may perform bearer modification procedure at this point, if the initial bearers reserved in step 7 and the wishes of user at UE(B) are different. During this bearer modification step the resources in the IP‑CANs of UE(A) and UE(B) may be modified, and the resource reservation in the external network may also be modified.

12. Session initiation procedure is acknowledged.

5.4.6.4 Session progress indication to the originating UE

The pre-alerting or alerting indications returned to the originating UE shall enable the originating UE to inform the calling user of the session progress prior to the arrival of the incoming media (for example the originating UE may synthesise ringing locally).

5.4.7 Interaction between QoS and session signalling

5.4.7.0 General

At IP‑CAN bearer activation the user shall have access to either IP‑CAN services without Policy and Charging Control, or IP‑CAN services with Policy and Charging Control. It is operator choice whether to offer both or only one of these alternatives for accessing the IM Subsystem.

When using IP‑CAN without Policy and Charging Control, IP-CAN bearers are established according to the user’s subscription, local operator’s IP bearer resource based policy, local operator’s admission control function and roaming agreements.

When using IP‑CAN with Policy and Charging Control, PCC decisions (e.g., authorization and control) are also applied to the IP-CAN bearer.

The description in this clause and the following clauses (clauses 5.4.7.1 – 5.4.7.7) is applicable for the case when Policy and Charging Control is employed.

The IP-Connectivity Access Network contains a Policy and Charging Enforcement Function (PCEF, in 5GS corresponding to the combination of SMF and UPF) that has the capability of policing packet flow into the IP network, and restricting the set of IP destinations that may be reached from/through an IP‑CAN bearer according to a packet classifier.

NOTE: How PCEF is distributed in SMF and UPF in 5GS is specified in TS 23.501 [93] and TS 23.203 [54].

This policy ‘gate’ function has an external control interface that allows it to be selectively ‘opened’ or ‘closed’ on the basis of IP destination address and port. When open, the gate allows packets to pass through (to the destination specified in the classifier) and when closed, no packets are allowed to pass through. The control is performed by a PCRF/PCF (the interface between the PCRF/PCF and the P‑CSCF is the Rx interface standardised in TS 23.203 [54] or the N5 interface (using the Npcf_PolicyAutorization service), standardised in TS 23.503 [95] and TS 29.514 [96]).

There are eight interactions defined for Policy and Charging Control:

1. Authorize QoS Resources.

2. Resource Reservation.

3. Enabling of media flows authorized in (1), e.g. ‘open’ the ‘gate’.

4. Disabling of media flows authorized in (1), e.g. ‘close’ the ‘gate’.

5. Revoke Authorization for IP‑CAN and IP resources.

6. Indication of IP‑CAN bearer release from the PCEF in the IP-Connectivity Access Network to the PCRF/PCF.

7. Authorization of IP‑CAN bearer modification.

8. Indication of IP‑CAN bearer modification from the PCEF in the IP-Connectivity Access Network to the PCRF/PCF.

These requirements and functional description of these interactions are explained further in the following clauses. The complete specification of the interface between the PCRF/PCF and the PCEF is contained in TS 23.203 [54] and TS 23.503 [95].

The Policy and Charging Control can also be used to enable the P-CSCF to retrieve the user location and/or UE Time Zone information from the access network as specified in TS 23.203 [54] and TS 23.503 [95].

5.4.7.1 Authorize QoS Resources

The Authorize QoS Resources procedure is used during an establishment and a modification of a SIP session. The P‑CSCF shall use the SDP contained in the SIP signalling to derive the session information that is relevant for Policy and Charging Control and forwards it to the PCRF/PCF. The PCRF/PCF shall use the received information to calculate the proper authorization. This enables the PCRF/PCF to authorize the required QoS resources.

NOTE: Although session information is incomplete in the terminating side P‑CSCF at the reception of the SDP offer, it can be sent to PCRF/PCF whenever the SDP offer (contained in the session establishment request or session modification request) indicates no requirements for resource reservation or that the required resources are already available on the originating side, as in such cases no SDP answer is received before the PCRF/PCF is requested to authorize the required QoS resources.

The authorization shall be expressed in terms of the IP resources to be authorized and shall include limits on media flows, and may include restrictions on IP destination address and port. The PCC shall authorize each SIP session independently (including additional parallel sessions, e.g. Call Waiting) and shall take into consideration the amount of IP resources the user’s subscription allows.

5.4.7.1a Resource Reservation with Policy and Charging Control

The IP‑CAN provides the Policy and Charging Enforcement Point that implements the policy decisions for performing admission control and authorising the IP‑CAN and IP BS QoS Resource request, and policing media flows entering the external IP network.

Authorization of IP‑CAN and IP QoS Resources shall be required for access to the IP Multimedia Subsystem. The IP‑CAN shall determine the need for authorization, possibly based on provisioning and/or based on requested parameters, which may be IP‑CAN specific.

Resource Reservation is initiated either by the UE or the IP‑CAN depending on the bearer establishment mode selected for the IP‑CAN session, see TS 23.203 [54] and TS 23.503 [95]:

– Resource reservation requests initiated from the UE shall (if possible for the used IP‑CAN) contain the traffic mapping information which enables the IP‑CAN to correctly match the reservation request to the corresponding authorization. The authorization is normally ‘Pulled’ from the PCRF/PCF by the PCEF within the IP‑CAN when the reservation request is received from the UE.

NOTE: When a UE combines multiple media flows onto a single IP‑CAN bearer, all the traffic mapping information related to those media flows are provided in the resource reservation request.

With a request for IP‑CAN QoS resources, the PCEF within the IP‑CAN shall verify the request is less than the sum of the authorized IP resources (within the error tolerance of the conversion mechanism) for all of the combined media flows.

– Resource reservation requests initiated by the IP‑CAN take place after successful authorization of QoS resources. The PCRF/PCF "Pushes" the authorization for IP‑CAN bearer resources to the PCEF within the IP‑CAN, which then enforces the authorization by either modifying the characteristics of one existing IP‑CAN bearer or requesting the establishment of a new one.

– Resource reservation requests initiated by the IP‑CAN shall (if possible for the used IP‑CAN) contain the traffic mapping information which enables the UE to correctly match the reservation request to the corresponding media of the SIP session.

5.4.7.2 Enabling of Media Flows

The PCRF/PCF makes policy decisions and provides an indication to the PCEF within the IP‑CAN that the user is now allowed to use the allocated QoS resources for per-session authorizations unless this was done based on Policy and Charging Control at the time of the Resource Reservation procedure. If there is more than one response for the same session, indicating that the session has been forked in the network, the PCRF/PCF may authorize the "logical OR" of the resources requested in the responses. When the session established indication has been received, if the PCRF/PCF earlier have authorized the "logical OR" of the resources then the PCRF/PCF will modify the authorization and enable the corresponding media flows according to the session established indication.

The PCEF within the IP‑CAN enforces the policy decisions. The IP‑CAN shall restrict any use of the IP resources prior to this indication from the PCRF/PCF, e.g. by keeping the gate closed and disabling the use of resources for the media flow. Based on local policy, IP‑CAN and/or IP resources may be allowed to be used by the user at the time they are authorized by the PCRF/PCF.

5.4.7.3 Disabling of Media Flows

The PCRF/PCF makes policy decisions and provides an indication to the PCEF within the IP‑CAN about revoking the user’s capacity to use the allocated QoS resources for per-session authorizations. The indication for disabling media flows shall be sent as a separate decision to the PCEF within the IP‑CAN corresponding to the previous request to enable media flows.

The PCEF within the IP‑CAN enforces the policy decisions. The IP‑CAN shall restrict any use of the IP resources after this indication from the PCRF/PCF, e.g. by closing the gate and blocking the media flow.

5.4.7.4 Revoke Authorization for IP-Connectivity Access Network and IP Resources

At IP multimedia session release, the UE should deactivate the IP‑CAN bearer(s) used for the IP multimedia session. In various cases the UE will be unable to perform this release itself. The PCRF/PCF provides indication to the PCEF within the IP‑CAN when the resources previous authorized, and possibly allocated by the UE, are to be released. The IP‑CAN shall deactivate the IP‑CAN bearer used for the IP multimedia session.

5.4.7.5 Indication of IP-Connectivity Access Network bearer release

Any release of IP‑CAN bearer(s) that were established based on authorization from the PCRF/PCF shall be reported to the PCRF/PCF by the PCEF within the IP‑CAN.

This indication is forwarded to the P‑CSCF and may be used by the P‑CSCF to initiate a session release towards the remote endpoint e.g. if all IP-CAN bearer(s) associated with the session were released, the procedures in clause 5.10.3.1 can be executed.

NOTE: If only a subset of IP-CAN bearer(s) were released, then the UE can update the ongoing session with the remainder of allowed media flows or a subset of allowed media flows.

5.4.7.6 Authorization of IP-Connectivity Access Network bearer modification

When an IP‑CAN bearer is modified by the UE, such that the requested QoS falls outside of the limits that were authorized at IP‑CAN bearer activation (or last modification) or such that new binding information is received, then the PCEF within the IP‑CAN shall verify the authorization of this IP‑CAN bearer modification.

If the PCEF within the IP‑CAN does not have sufficient information to authorize the IP‑CAN bearer modification request, the PCEF within the IP‑CAN shall send an authorization request to the PCRF. The PCRF authorizes the modified IP‑CAN bearer based on the current session information. Note that the P‑CSCF sends an update of the session information in the case of a modification of a SIP session which results in an update of the authorization as described in clause 5.4.7.1.

When the P‑CSCF sends an update of the session information and the bearer establishment is controlled by the IP‑CAN, the PCRF/PCF shall send an updated authorization to the PCEF. The PCEF within the IP‑CAN enforces the policy decision accordingly (e.g. by requesting the reservation of new IP‑CAN bearer resources in the case of the addition of a new media component to the session or release of previously reserved resources if a media component has been removed from the IP Multimedia session).

5.4.7.7 Indication of IP-Connectivity Access Network bearer modification

When an IP‑CAN bearer is modified such that the maximum bit rate (downlink and uplink) is downgraded to 0 kbit/s or changed from 0 kbit/s to a value that falls within the limits that were authorized at IP‑CAN bearer activation (or last modification) then the PCEF within the IP‑CAN shall report this to the PCRF/PCF.

This indication is forwarded to the P‑CSCF and may be used by the P‑CSCF to initiate a session release towards the remote endpoint.

5.4.7.8 Sharing of Resources for Network Detected Concurrent Sessions

5.4.7.8.1 Network Detected Concurrent Sessions

The following scenarios for concurrent sessions are subject to resource sharing:

– The UE is engaged in a session, puts the session on hold, then initiates a new session to a new UE.

– The UE is engaged in a session and receives an incoming session, puts the ongoing session on hold to accept the incoming session.

– The UE is engaged in multiple sessions, puts all sessions on hold and creates a conferencing session.

For a UE engaged in multiple sessions, with only one active session at any time, the network may be able to share resources for media components of the same type and that are common to these multiple sessions.

Resource sharing shall only be indicated for concurrent sessions that employ resource reservation based on TS 23.203 [54] or TS 23.503 [95].

When a UE puts a session on hold, it may put all or a subset of the media components of the session on hold. In such a case, the resource sharing applies only to the media components that are on hold and not to the rest of media components belonging to this IMS session

An emergency session shall not share resources with any other session.

NOTE: Resource sharing to be shared for any media component can be allowed for one direction as well as both directions. According to TS 24.229 [10a] and TS 24.610 [91] it is not prohibited that a UE may send media towards a held UE, i.e. uplink media can occur even when a UE puts a remote UE on hold. The P-CSCF or SIP AS can therefore be locally configured to allow resource sharing in both directions if the P-CSCF or SIP AS knows that the UE will not send media to a remote UE on hold.

5.4.7.8.2 Initiating Resource Sharing for Network Detected Concurrent Sessions

If the P-CSCF is configured to apply resource sharing, it may at establishment of a new Rx session or a new Npcf_PolicyAutorization application session context with the PCRF/PCF, indicate that resources may be shared in uplink and/or downlink direction by assigning an uplink and/or downlink tag to each media component of an IMS session unless it is an IMS emergency session.

NOTE: The assignment of tags to media components is regardless of any future sharing decision.

If this is the first IMS session of a UE, the P-CSCF shall assign new tags. Upon detection by the P-CSCF that a UE is engaged in multiple sessions, it shall determine if these sessions fulfil the criteria specified in clause 5.4.7.8.1 and have common media components that can share resources. If so, the P-CSCF may activate resource sharing by assigning the same existing tag to each media component whose resources can be shared amongst the IMS sessions. Otherwise, the P-CSCF shall assign new tags that are different from any tag previously assigned for this UE. The PCRF/PCF may then authorize resource sharing based on these tags. For further information, see TS 23.203 [54].

Whenever resource sharing is active, the P-CSCF shall ensure that the UE can only receive the media flow for one session at a time by closing the gates for all other media flows that can share the same resource, i.e. having the same tag.

SIP AS may indicate to a supporting P-CSCF to apply resource sharing to each media lines included in SDP of an IMS session. When SIP AS is used, P-CSCF, based on the local policy, may follow the resource sharing policy from SIP AS. The interaction between P-CSCF and SIP AS for handling Resource sharing procedure is defined in TS 24.229 [10a].

5.4.7.8.3 Void

5.4.7.9 Priority sharing for concurrent sessions

The P-CSCF may indicate to the PCRF/PCF that the resource allocation for a media flow is allowed to use the same priority as other media flows of the same media type for the UE engaged in multiple sessions by providing a priority sharing indicator and an optional pre-emption control information in addition to the application identifier and the service priority. For MCPTT, the service priority and the priority sharing indicator are defined in TS 23.179 [92]. The pre-emption control information is used to indicate to the PCRF/PCF how to perform pre-emption in accordance to TS 23.203 [54] and TS 23.503 [95].

The following scenario is subject to priority sharing:

— The P-CSCF receives a priority sharing indicator associated with the media flow from the Application Server.

Upon detection by the P-CSCF that a session includes a priority sharing indicator for a media flow and may optionally include pre-emption control information, the P-CSCF shall convey to the PCRF/PCF the priority sharing indicator and, when available, the pre-emption control information as described in TS 23.203 [54] and TS 23.503 [95].

NOTE 1: The Application Server is not supposed to include the priority sharing indicator for an emergency session.

NOTE 2: The priority sharing enables the usage of one bearer per QCI/5QI for a UE having multiple sessions; otherwise sessions with different service priorities would end up in different bearers.

5.4.8 QoS-Assured Preconditions

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.

NOTE 1: To avoid unwanted session setup delay and IP‑CAN signalling load, QoS-Assured sessions needs to be used with care and it is decided per application which media that require resource reservation.

The following cases exist in the context of using "QoS-Assured" preconditions for IMS:

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

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

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

NOTE 2: The flows of clauses 5.5, 5.6 and 5.7 depict the case where both UEs require confirmation from each other of the fulfilment of the pre-conditions. The flow in clause 5.7a depicts the case where the IMS session does not require the reservation of additional bearer resources and the endpoints do not use pre-conditions.

5.4.9 Event and information distribution

5.4.9.0 General

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.

NOTE: The service event related information exchange may either take place in the context of a session, or independently outside the context of any existing session.

Figure 5.8: Providing service event related information to related endpoint

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.

2. P‑CSCF forwards the message request.

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

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

5. P‑CSCF forwards the response.

NOTE 1: The UE may retrieve service event related information using IP‑CAN or IMS procedures.

NOTE 2: transport aspects of the information transfer described above may require further considerations.

5.4.9.1 Subscription to event notifications

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 [36]) 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 [36]).

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.

Figure 5.8a: Subscription to event in AS

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

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.

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

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

5. The AS acknowledges the SubscribeEvent request.

6. The S‑CSCF forwards the acknowledgement to the P‑CSCF.

7. The P‑CSCF forwards the acknowledgement to the UE.

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.

9. The P‑CSCF forwards the EventNotification to the UE.

10. The UE acknowledges the EventNotification.

11. The P‑CSCF forwards the acknowledgement to the AS.

5.4.10 Void

5.4.11 Signalling Transport Interworking

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 [1]). 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

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 [24]. 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 [24]. 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:

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

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

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:

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

b) 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 [20], 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 [25].

– 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:

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

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

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

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 [71], and for the IBCF/TrGW implementation consult clause 4.14 and Annex I, clause I.3.3.