5.7 Termination procedures

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

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

5.7.0 General

This clause presents the detailed application level flows to define the Procedures for session terminations.

The flows presented in the clause assume the use of Policy and Charging Control for the establishment of QoS-Assured Sessions.

The session termination procedures specify the signalling path between the Serving‑CSCF assigned to perform the session termination service and the UE. This signalling path is determined at the time of UE registration, and remains fixed for the life of the registration.

A UE always has a proxy (P‑CSCF) associated with it. This P‑CSCF performs resource authorization for the sessions to the UE and may have additional functions in handling of priority sessions. The P‑CSCF is determined by the CSCF discovery process, described in clause 5.1.1 (Local CSCF Discovery).

As a result of the registration procedure, the P‑CSCF knows the address of the UE. The assigned S‑CSCF, knows the name/address of the P‑CSCF (procedure MT#3, and MT#4, depending on the location of S‑CSCF and P‑CSCF).

Sessions destined to the PSTN are a special case of the Termination procedures. The MGCF uses H.248 to control a Media Gateway, and communicates with the SS7 network. The MGCF receives and processes SIP requests, and subsequent nodes consider the signalling as if it came from a S‑CSCF.

5.7.1 (MT#1) Mobile termination, roaming

This termination procedure applies to roaming users.

The UE is located in a visited network, and determines the P‑CSCF via the CSCF discovery procedure described in clause 5.1.1. The home network advertises the S‑CSCF as the entry point from the visited network.

When registration is complete, S‑CSCF knows the name/address of its next hop in the signalling path, the P‑CSCF and P‑CSCF knows the name/address of the UE.

Figure 5.17: Mobile termination procedure – roaming

Procedure MT#1 is as follows:

1. The originating party sends the SIP INVITE request, containing an initial SDP, via one of the origination procedures, and via one of the Inter-Serving procedures, to the Serving‑CSCF for the terminating users.

2. S‑CSCF validates the service profile, and invokes any termination service logic required for this user. This includes authorization of the requested SDP based on the user’s subscription for multi-media services.

3. S‑CSCF remembers (from the registration procedure) the next hop CSCF for this UE. It forwards the INVITE to the P‑CSCF in the visited network.

4. If the P-CSCF determines that the termination is for an MPS session, the P-CSCF derives the session information and invokes dynamic policy sending the derived session information to the PCRF/PCF. The P‑CSCF remembers (from the registration procedure) the UE address, and forwards the INVITE to the UE.

5. UE determines the subset of the media flows proposed by the originating endpoint that it supports, and responds with an Offer Response message back to the originator. The SDP may represent one or more media for a multi-media session. This response is sent to P‑CSCF.

6. P‑CSCF instructs the PCRF/PCF to authorize the resources necessary for this session.

NOTE: P‑CSCF can additionally authorize the resources in step 4 in scenarios where request indicates 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.

7. P‑CSCF forwards the Offer Response message to S‑CSCF.

8. S‑CSCF forwards the Offer Response message to the originator, per the S-S procedure.

9. The originating endpoint sends a Response Confirmation via the S-S procedure, to S‑CSCF. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response sent in Step 8 or a subset. If new media are defined by this SDP, a new authorization (as in Step 6) will be done following Step 12. The originating UE is free to continue to offer new media on this operation or on subsequent exchanges using the Update method. Each offer/answer exchange will cause the P‑CSCF to repeat the Step 6 again.

10. S‑CSCF forwards the Response Confirmation to P‑CSCF. This may possibly be routed through the I‑CSCF depending on operator configuration of the I‑CSCF.

11. P‑CSCF forwards the Response Confirmation to UE.

12. UE responds to the Response Confirmation with an acknowledgement. If Optional SDP is contained in the Response Confirmation, the Confirmation Ack will also contain an SDP response. If the SDP has changed, the P‑CSCF authorizes that the resources are allowed to be used.

13. Depending on the bearer establishment mode selected for the IP‑CAN session, resource reservation shall be initiated either by the UE or by the IP‑CAN itself. The UE initiates the reservation procedures for the resources needed for this session as shown in Figure 5.17. Otherwise, the IP‑CAN initiates the reservation of required resources after step 6.

14-15. PCSCF forwards the Confirmation Ack to the S‑CSCF and then to the originating end point via session path. Step 14 may be similar to Step 7 depending on whether or not configuration hiding is used.

16-18. When the originating endpoint has completed its resource reservation, it sends the successful Resource Reservation message to S‑CSCF, via the S-S procedures. The S‑CSCF forwards the message toward the terminating endpoint along the signalling path.

19. UE#2 alerts the destination user of an incoming session setup attempt.

20-22. UE#2 responds to the successful resource reservation towards the originating end point.

23-25. UE may alert the user and wait for an indication from the user before completing the session setup. If so, it indicates this to the originating party by a provisional response indicating Ringing. This message is sent to P‑CSCF and along the signalling path to the originating end.

26. When the destination party answers, the UE sends a SIP 200-OK final response to P‑CSCF.

27. P‑CSCF indicates to PCRF/PCF that the media flows for this session should now be enabled.

28. UE starts the media flow(s) for this session.

29-30. P‑CSCF sends a SIP 200-OK final response along the signalling path back to the S‑CSCF.

31-33. The originating party responds to the 200-OK final response with a SIP ACK message that is sent to S‑CSCF via the S-S procedure and forwarded to the terminating end along the signalling path.

5.7.2 (MT#2) Mobile termination, home

This termination procedure applies to users located in their home service area.

The UE is located in the home network, and determines the P‑CSCF via the CSCF discovery procedures described in clause 5.1.1.

When registration is complete, S‑CSCF knows the name/address of P‑CSCF, and P‑CSCF knows the name/address of the UE.

Figure 5.18: Mobile termination procedure – home

Procedure MT#2 is as follows:

1. UE#1 sends the SIP INVITE request, containing an initial SDP, via one of the origination procedures, and via one of the Serving to Serving‑CSCF procedures, to the Serving‑CSCF for the terminating user.

3. S‑CSCF remembers (from the registration procedure) the next hop CSCF for this UE. It forwards the INVITE to the P‑CSCF in the home network.

6. P‑CSCF instructs PCRF/PCF to authorize the resources necessary for this session.

NOTE: P‑CSCF can additionally authorize the resources in step 4 in scenarios where 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.

7. P‑CSCF forwards the Offer Response message to S‑CSCF.

8. S‑CSCF forwards the Offer Response message to the originator, per the S-S procedure.

10. S‑CSCF forwards the Response Confirmation to P‑CSCF.

11. P‑CSCF forwards the Response Confirmation to UE.

13. Depending on the bearer establishment mode selected for the IP‑CAN session, resource reservation shall be initiated either by the UE or by the IP‑CAN itself. The UE initiates the reservation procedures for the resources needed for this session as shown in Figure 5.18. Otherwise, the IP‑CAN initiates the reservation of required resources after step 6.

14-15. The response is forwarded to the originating end point.

19. UE#2 alerts the destination user of an incoming session setup attempt.

20-22. UE#2 responds to the successful resource reservation and the message is forwarded to the originating end.

23-25. UE may alert the user and wait for an indication from the user before completing the session. If so, it indicates this to the originating party by a provisional response indicating Ringing. This message is sent to P‑CSCF and along the signalling path to the originating end.

26. When the destination party answers, UE sends a SIP 200-OK final response to P‑CSCF.

27. P‑CSCF indicates that the authorized media flows for this session should now be enabled.

28. UE starts the media flow(s) for this session.

29-30. P‑CSCF forwards the 200-OK to S‑CSCF, following the signalling path.

31-33. The session originator responds to the 200-OK by sending the ACK message to S‑CSCF via the S-S procedure and it is forwarded to the terminating end along the signalling path.

5.7.2a (MT#3) Mobile termination, CS Domain roaming

This termination procedure applies to a user registered for CS services, either in the home network or in a visited network. The user has both IMS and CS subscriptions but is unregistered for IMS services

Figure 5.18a: Mobile Terminating procedures to a user that is unregistered for IMS services but is registered for CS services

1. If the terminating user does not have an S‑CSCF allocated, the session attempt is routed according to the clause 5.12.1 (Mobile Terminating procedures to unregistered IMS user that has services related to unregistered state).

2. S‑CSCF invokes service control appropriate for this session setup attempt, which may result in e.g. re-routing the session to a messaging service, or continued routing towards the user’s CS domain termination address (e.g. E.164).

3. S‑CSCF performs whatever further actions are appropriate for this session setup attempt. In the case of routing towards the user’s CS domain termination address, the S‑CSCF performs an analysis of this address. From the analysis of the destination address, S‑CSCF determines that this is for the CS domain, and passes the request to the BGCF.

4. The BGCF forwards the SIP INVITE message to the appropriate MGCF in the home network, or to a BGCF in another network. This depends on the PSTN interworking configuration of the IMS network. Eventually, the session initiation arrives to an MGCF.

5. Normal session setup continues according to PSTN-T flow as described in clause 5.7.3.

5.7.3 (PSTN-T) PSTN termination

The MGCF in the IM CN subsystem is a SIP endpoint that initiates and receives requests on behalf of the PSTN and Media Gateway (MGW).Other nodes consider the signalling as if it came from a S‑CSCF. The MGCF incorporates the network security functionality of the S‑CSCF.

PSTN termination may be done in the same operator’s network as the S‑CSCF of the session originator. Therefore, the location of the MGCF/MGW are given only as "Terminating Network" rather than "Home Network" or "Visited Network".

Further, agreements between network operators may allow PSTN termination in a network other than the originator’s visited network or home network. This may be done, for example, to avoid long distance or international tariffs.

Figure 5.19: PSTN termination procedure

The PSTN termination procedure is as follows:

1. MGCF receives an INVITE request, containing an initial SDP, through one of the origination procedures and via one of the inter-serving procedures.

2. MGCF initiates a H.248 interaction to pick an outgoing channel and determine media capabilities of the MGW.

3. MGCF determines the subset of the media flows proposed by the originating endpoint that it supports, and responds with an Offer Response message back to the originator. This response is sent via the S-S procedure.

4. The originating endpoint sends a Response Confirmation. The Response Confirmation may also contain SDP. This may be the same SDP as in the Offer Response sent in Step 3 or a subset. The originating UE is free to continue to offer new media on this operation or on subsequent exchanges using the Update method.

5. MGCF initiates a H.248 interaction to modify the connection established in step #2 and instruct MGW to reserve the resources necessary for the media streams.

6. MGCF responds to the offered media towards the originating party.

7. GW reserved the resources necessary for the media streams.

8. When the originating endpoint has completed its resource reservation, it sends the successful Resource Reservation message to MGCF, via the S-S procedures.

9. MGCF sends an IAM message to the PSTN.

10. MGCF sends response to the successful resource reservation towards originating end.

11. The PSTN establishes the path to the destination. It may optionally alert the destination user before completing the session. If so, it responds with an ACM message.

12. If the PSTN is alerting the destination user, MGCF indicates this to the originating party by a provisional response indicating Ringing. This message is sent via the S-S procedures.

13. When the destination party answers, the PSTN sends an ANM message to MGCF.

14. MGCF initiates a H.248 interaction to make the connection in the MGW bi-directional.

15. MGCF sends a SIP 200-OK final response along the signalling path back to the session originator.

16. The Originating party acknowledges the final response with a SIP ACK message.

5.7.4 (NI-T) Non-IMS Termination to an external SIP client

This clause describes the IMS session setup procedures towards external SIP clients that don’t support the required IMS SIP extensions.

In this scenario, the UE originates an IMS session without requiring the support for precondition capabilities, towards an external SIP entity that does not support those capabilities. Since required resources are not yet available at the UE, all the media components are set to inactive. In this example the external SIP client does not support the Precondition extension of SIP so the related precondition information within SIP/SDP is ignored.

When both parties have agreed to the session and media parameters and the UE has established resources for the media, the UE initiates session modification setting the status of the media components to active and is thus enabling the media transfer to start. Figures 5.19b and 5.19c together illustrate session flows for one possible originating session establishment towards a non-IMS client in an external network with QoS authorization and Policy and Charging Control support.

For illustration purposes these session flows show the case of a non-roaming origination. This flow is a variant of MO#2 defined in clause 5.6.2. The same principles apply in roaming cases, i.e. analogous variants of MO#1 defined in clause 5.6.1 are also supported for interworking with SIP clients that do not support the required IMS procedures.

Figure 5.19a: Void

Figure 5.19b: Terminating session towards external SIP client, initiate session set up not requiring precondition capabilities and with inactive media

The UE initiates an INVITE message, which indicates the support of the precondition capability Since required resources are not yet available, the UE sets all media components to inactive state, as shown in figure 5.19b.

1‑3. UE initiates a new IMS session indicating the support of the precondition capability and setting all media components to inactive state.

4‑5. Acknowledgement of the session and media parameters are sent from the terminating side to the P‑CSCF.

6. The P‑CSCF may at this point instruct PCRF/PCF to authorize the resources being negotiated.

7. The acknowledgement of the session and media parameters forwarded towards the originating UE.

8‑10. The session is established, but media transfer is not allowed yet.

11. Depending on the bearer establishment mode selected for the IP‑CAN session, resource reservation shall be initiated either by the UE or by the IP‑CAN itself. The UE starts the resource reservation for the media as shown in Figure 5.19b. Otherwise, the IP‑CAN initiates the reservation of required resources after step 6.

Figure 5.19c: Continuation of terminating session towards external SIP client, session set up with active media

Once the session parameters have been agreed and the UE has successfully reserved resources for the media components, the session set-up continues by setting the media components to active, as shown in session flow 5.19c.

12‑14. UE initiates activation of media by initiating an INVITE procedure towards the terminating party.

15‑16. The terminating party accepts media activation, and corresponding signalling is passed back towards the originating party along the session path.

17. The P‑CSCF receives the acceptance of media activation. At this point, the P‑CSCF may instruct the PCRF/PCF to enable the media flows that have been authorized for the session.

18. The P‑CSCF forwards the signalling message to the originating UE indicating that the session setup can continue and activation of media is performed.

19‑21. The Session establishment is then acknowledged through the session path.

At this point in time, the session is established between the two parties.

5.7.5 (AS-T#1) PSI based Application Server termination – direct

This clause depicts a routing example for incoming session where the session request is routed directly to the AS hosting the PSI.

Figure 5.19d: Incoming session, direct route towards the AS

1. I‑CSCF receives a request destined to the PSI.

2-3. I‑CSCF queries the HSS in order to determine the next hop in the routing path for the PSI.

4. HSS determines the routing information, i.e., the address of the AS hosting the PSI.

5. HSS returns the AS address to the I‑CSCF.

6-7. I‑CSCF forwards the request to the address received from the query.

8-9. Session setup continues as per existing procedures.

5.7.6 (AS-T#2) PSI based Application Server termination – indirect

This clause depicts an example routing scenario where the basic IMS routing via S‑CSCF is used to route the session.

Figure 5.19e: Incoming session, indirect route to AS via S‑CSCF

1. I‑CSCF receives a request destined to the PSI.

2-3. I‑CSCF queries HSS in order to determine the next hop in the routing path for the PSI.

4. HSS determines the routing information, which is the S‑CSCF defined for the "PSI user".

5. HSS returns the S‑CSCF address/capabilities to the I‑CSCF.

6-7. I‑CSCF, as per existing procedures, forwards the request towards the entity (i.e., S‑CSCF) received from the query, or the I‑CSCF selects a new S‑CSCF if required.

8. S‑CSCF evaluates the filter criteria and gets the AS address where to forward the request.

9. The request is then routed towards the AS identified by the filter criteria.

10-12. Session setup continues as per existing procedures.

5.7.7 (AS-T#3) PSI based Application Server termination – DNS routing

This clause 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.

Figure 5.19f: Incoming session, direct route to AS using DNS

1. I‑CSCF receives a request that is destined to the PSI.

2. I‑CSCF has been configured with the list of supported domains/network names, or it may have been configured to directly query a local DNS server.

3. In this case the I‑CSCF checks the list and finds a match.

4. I‑CSCF sends DNS query to find the route.

5. DNS server returns the IP address of the AS hosting the PSI.

6-7. I‑CSCF forwards the request towards the IP address received from the query.

8-9. Session setup continues as per existing procedures.

5.7.8 (AST#4) Termination at Application Server based on service logic

This termination procedure applies to an Application Server that terminates a session. In this case the addressed user is a UE and is not hosted by the AS. Based on the invoked service logic at the Application Server the session is terminated at the AS.

The procedure described below assumes that the Application Server takes care of the user plane connection.

Figure 5.19g: Application Server termination

1. I‑CSCF receives a request destined to the user.

2-3. I‑CSCF queries HSS in order to determine the next hop in the routing path for the user.

4. HSS determines the routing information, which is the S‑CSCF defined for the user.

5. HSS returns the S‑CSCF address/capabilities to the I‑CSCF.

6-7. I‑CSCF, as per existing procedures, forwards the request to S‑CSCF that will handle the session termination.

8. S‑CSCF evaluates the filter criteria and gets the AS address where to forward the request.

9. The request is then routed towards the AS identified by the filter criteria. The AS terminates the session instead of allowing it to continue on to the address end user.

10-12. Session setup continues as per existing procedures.