5.19 Support for Transit scenarios in IMS

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

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

5.19.1 General

This clause presents some high level flows to describe the procedures for supporting IMS transit network scenarios.

The IMS Transit Functions perform an analysis of the destination address, and determine where to route the session. The session may be routed directly to an MGCF, BGCF, or to another IMS entity in the same network, to another IMS network, or to a CS domain or PSTN. The address analysis may use public (e.g. DNS, ENUM) and/or private database lookups, and/or locally configured data. As described in clause 4.15 there are various transit configurations possible that may be supported.

For the case where an operator is providing transit functions for other operators and/or enterprise networks, the configuration is as shown in Figure 5.49. The configuration in Figure 5.49 is also intended to cover scenarios where an operator routes traffic from other IMS- or SIP-networks to CS domain or PSTN customers through the IMS transit network. In this case the terminating network as shown in the figure indicates the operator’s CS domain or PSTN.

Figure 5.49: IMS transit network

For the transit operator in Figure 5.49, ISUP messages that arrive at a configured MGCF, are translated into SIP, and are passed to the IMS Transit Functions. SIP messages may arrive directly at the configured entity supporting the transit functions or first pass through an IBCF before arriving at the IMS Transit Functions. The IMS Transit Functions determine whether to route directly to an MGCF, BGCF, or to another IP entity on the path (e.g. an IBCF). In this transit operator configuration, the IMS Transit Functions might reside in a stand-alone entity or might be combined with the functionality of an MGCF, a BGCF, an I‑CSCF, an S‑CSCF or an IBCF. When residing in a stand-alone entity the IMS Transit Functions shall be able to generate CDRs.

For the case where the operator is the terminating network operator handling a terminating service for its own customers, the configuration and operation may be more complex as shown in figure 5.50.

NOTE 1: In the case of Fixed Broadband Access to IMS the term "CS domain" in the following text and in figure 5.50 may be replaced by the term "PSTN".

Figure 5.50: Terminating IMS network with transit support, Transit Functions first

For the operator in figure 5.50, ISUP messages arriving at an MGCF may be destined for an IMS or a CS domain customer (see clause 4.15). The ISUP messages are translated into SIP.

The operator can choose whether to route all traffic through the IMS Transit Functions, which subsequently route to the I‑CSCF for IMS terminating call scenarios or to an MGCF for the case of CS domain subscribers as described above. This is depicted in figure 5.50. In this case, there may be an additional delay for terminating sessions destined for IMS subscribers.

NOTE 2: In this case, the IMS Transit Functions perform selection of the appropriate domain to terminate the call to, followed by routing to the CS domain (for CS domain destined traffic).

As an alternative, the operator may choose to route all traffic to the I‑CSCF directly and then identify those sessions that are not destined to IMS subscribers based on an HSS query. Based on the response from the HSS, sessions are either routed to an S‑CSCF or to the CS domain (optionally via Transit Functions). In this case there may be an additional delay for terminating sessions destined for the CS domain subscribers.

NOTE 3: If in this case, the I‑CSCF becomes aware that the call is not destined to an IMS subscriber and forwards it to the Transit Function for further routing, then the Transit Functions only perform routing to the CS domain.

It is the operator’s choice to determine which way to route the SIP messages, first through IMS Transit Functions or first to an I‑CSCF. This may depend on whether the majority of the sessions that enter the IMS network, are destined to IMS or CS domain subscribers.

NOTE 4: In either configuration of the terminating network scenario, once it is determined that the call is not destined for an IMS subscriber, it is necessary to verify that the call is destined for a CS domain subscriber rather than to a ported number or to a wrong number. At which stage of the session establishment this decision is made is FFS.

In the terminating network configuration shown in figure 5.50, the IMS Transit Functions might reside in a stand-alone entity or might be combined with the functionality of an MGCF, a BGCF, an I‑CSCF, an S‑CSCF, or an IBCF. When residing in a stand-alone entity the IMS Transit Functions shall be able to generate CDRs.

For the case where an IMS network serves as a transit network and as a terminating network (depending on the destination of the session), the configuration and operation resembles that of the previous case as shown in figure 5.50a and figure 5.50b.

Figure 5.50a: Terminating/Transit IMS network, Transit Functions first

Figure 5.50b: Terminating/Transit IMS network, I-CSCF first

For the operator in figure 5.50a and figure 5.50b, ISUP messages arriving at an MGCF may be destined for the own IMS network of for a succeeding network. The ISUP messages are translated into SIP. This is not depicted in figure 5.50a and figure 5.50b.

The operator can choose whether to route all traffic through the IMS Transit Functions, which subsequently route to the I‑CSCF for sessions destined for subscribers of the own IMS network, to the own CS domain for sessions destined to subscribers of the own CS domain, or to a succeeding network for sessions not destined for subscribers of the own IMS network or the own CS domain. This is depicted in figure 5.50a. In this case there may be an additional delay for sessions destined to subscribers of the own network.

NOTE 5: In this case, the Transit Functions perform selection of the appropriate domain to terminate the call to, for subscribers of the own network, followed by routing to another network (if the session is not destined to the own network).

As an alternative, the operator may choose to route all traffic to the I‑CSCF directly and then identify those sessions that are not destined to IMS subscribers of the own IMS network based on an HSS query. Based on the response from the HSS, sessions are either routed to an S‑CSCF of the own IMS network or to Transit Functions. The Transit Functions subsequently route the session to either the CS domain of the own network or to a succeeding network. This is depicted in figure 5.50b. In this case there may be an additional delay for sessions not destined to subscribers of the own IMS network.

In the terminating/transit network configuration shown in figure 5.50a and figure 5.50b, the IMS Transit Functions might reside in a stand-alone entity or might be combined with the functionality of an MGCF, a BGCF, an I‑CSCF, an S‑CSCF, or an IBCF. When residing in a stand-alone entity the IMS Transit Functions shall be able to generate CDRs.

5.19.2 Providing IMS application services in transit network scenarios

This clause provides an overview of how IMS application services in transit network scenarios are provided.

Figure 5.50c: IMS application services in transit network

The procedure for IMS application services in transit network is as follows:

1. The Transit function receives an incoming request from a preceding network.

2. Based on local configured Transit invocation criteria, the Transit function determines whether one or more services are to be performed.

If the preceding network is the served network, for which special services are invoked, the invocation criteria will trigger and invoke the related services based on the origination of the request.

If the succeeding network is the served network, for which special services are invoked, the invocation criteria will trigger and invoke the related services based on the termination point of the request.

The related service(s) are invoked.

3. The Transit function performs the transit routing according to clause 5.19.1 and forwards the Session Request towards the succeeding network.

NOTE: An AS that acts as a B2BUA can decide to not route back the call to the transit function. In this case, it will use the terminating UA mode of operation for request from the Transit function. It can apply originating UA procedures according to TS 23.218 [71].