Have you heard about the IMS Centralized Services (ICS)? The basic idea is fairly simple. We want to apply services for IMS subscribers, regardless what access network they use. We know that in IMS we can do it for all IP-based access domains. But if the subscriber is accessing through the legacy CS network (e.g. because of a low LTE coverage in her area), we are still triggering the services in the CS Core network … right, unless we have the ICS in place. So ICS enables the IMS services even when one is using CS access for the media bearer.
IMS Centralized Services
The ICS is specified in GSMA IR.64 and 3GPP TS 23.292, 23.237 and 23.216. The scope of the specification includes:
- Session establishment when using CS access for media transmission for an IMS service
- Support of Service Continuity
- Support of Single Radio Voice Call Continuity
- Access Domain Selection (ADS)
- IMS control of services where the media is transported via the CS network (e.g. managing of mid-call services)
- Service data management
The solution is applicable for UEs with or even without ICS functionality. As the first step all the sessions have to be anchored in the IMS. That is a job for Service Centralization and Continuity Application Server (SCC AS). The SCC AS is on the signalling path for both the originating and terminating services. Using the initial Filter Criteria (IFC), the SCC AS is triggered as the first AS for originating sessions and as the last for terminating sessions.
In principle we have to distinguish whether or not the MSC server is enhanced for ICS (see 23.292). Moreover UE can be also ICS enhanced and we can have a mix of ICS and non-ICS UEs in the network. Last but not least ICS UEs may implement I1 interface towards SCC AS.
ICS enhanced MSC
The ICS enhanced MSC does use I2 interfaces towards IMS Core. It is a SIP interface and it is specified in 29.292. For IMS network it basically means that the user can be treated as any other subscriber. Once the user is registered, she can place or receive calls.
Registration over I2 Reference Point
After the registration all the signalling goes as usually, just instead of the P-CSCF, the IMS Core communicates with the ICS enhanced MCS.
Originating Call
Originating Services using ICS enhanced MSC
To initiate a session the UE A sends a CS call setup message containing the B-party number to the MSC Server enhanced for ICS according to standard CS originating procedures. The Originated sessions are routed by the MSC to the S-CSCF in HPLMN, INVITE to the S‑CSCF contains the Request-URI set to the B-party number. The SCC AS is invoked as first and then the S-CSCF triggers TAS.
Terminating Call
For Terminating sessions the TAS is triggered as first and the SCC AS gets the INVITE message as the second one. The SCC AS establishes a new session by sending an INVITE to the UE B via the S‑CSCF. The S‑CSCF forwards the INVITE to the MSC Server based on the contact address stored during registration, using the standard IMS procedures.
Terminating Services using ICS enhanced MSC
ICS non-enhanced MSC
For non-ICS UEs we can’t do any registration. So IMS Core doesn’t treat the CS users as IMS registered subscribers. That requires some more network elements to be involved and also the flows are a bit more complex .
The originated and terminated services are also provided in the IMS, but mid-call and presentation services are provided in the subscriber data sent to the MSC so it provides these services.
For the routing between CS and IMS domain this time instead of B-Number in Request URI we make use Routing Numbers.
For routing towards IMS IP Multimedia Routing Number (IMRN) is used. IMRN is a routable number that points to an SCC AS (so it is a PSI). In a roaming scenario, the IMRN has the same structure as an international ISDN number. IMRN is retrieved from SSC AS via CAMEL (SCC AS implements Service Control Point (SCP)) or via I1 reference point (ICS enhanced UEs).
For routing towards the CS network we need to retrieve either CS domain Routing Number (CSRN) from HSS or alternatively we can also use Mobile Station Routing Number (MSRN) which can be retrieved from HLR. Some more details will be mentioned later in the post or you may refer to TS 23.003.
Originating Call
Originating Services for Non-ICS MSC
The originated sessions from the MSC to the IMS is routed using the IMRN. Originated session signalling goes from the MSC Server in the VPLMN via MGCF in the HPLMN. The MGCF initiates an INVITE towards the I‑CSCF. The I‑CSCF routes the INVITE based on one of the “PSI based Application Server termination – direct and PSI based Application Server termination – indirect” procedures specified in TS 23.228. The routing is done either directly to the SCC AS or via the S‑CSCF. The SCC AS provides the session anchoring and sets the original called number and the calling party number to setup the outgoing call leg to party-B. The SCC AS sends the INVITE back to IMS Core. The S-CSCF then forwards the SIP INVITE message to TAS as usually.
Example of Originating flow for non-ICS
Terminating Call
Terminating Services for Non-ICS MSC
In the Terminating Flow, after we apply the terminating services on TAS, the S-CSCF forwards the INVITE to the SCC AS for terminating access domain selection (T-ADS).
The T-ADS selects the CS access for termination in the following cases:
- The UE is not registered in the IMS.
- The UE is registered in the IMS but not camping on an IMS Voice over PS capable access.
- The UE is only registered in the IMS by an MSC Server enhanced for ICS.
When the SCC AS decides that the call is to be routed into the CS network, the SCC AS allocates a specific CSRN. The specific CSRN can be an MSISDN with added prefix digits. There are several options how to resolve the MSISDN of original called party from the CSRN.
Note, if there is an existing IMS voice session for a UE, then the T-ADS in the SCC AS routes all further IMS voice sessions for the same UE (and the same domain!) as the existing IMS voice session without querying the HSS.
Use of a specific CSRN to indicate the anchored call
- MGCF resolution: In this case, the SCC AS forwards the call to the MGCF (which provides also a GMSC function). The specific CSRN is used by the MGCF to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The MGCF resolves the MSISDN from the CSRN and invokes GMSC functionality integrated in the MGCF for handling the CS call terminating procedure. In particular, the MGCF/GMSC includes the “Suppress T-CSI” parameter in the MAP SRI sent to the HSS.
- GMSC resolution: Other possibility is that the SCC AS forwards the call to the MGCF, which then forwards the call on to GSMC. The specific CSRN is used by the GSMC to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The GMSC resolves the MSISDN from the CSRN and invokes the CS call terminating procedure. In particular, the GMSC includes the “Suppress T CSI” parameter in the MAP SRI sent to the HSS.
- HSS resolution: In this option, the SCC AS forwards the call to the GMSC. The GMSC treats the call as a normal terminating call and sends a MAP SRI request to the HSS for the specific CSRN. The specific CSRN is used by the HSS to recognise that the SCC AS has already anchored the call in IMS, and that the call will be terminated in the CS domain. The HSS resolves the MSISDN from the CSRN and uses CS call terminating procedures to obtain routing information from the MSC/MSC-Server.
Use of a dynamically allocated CSRN to route via the GMSC
This option uses a dynamically allocated CSRN to divert the call to the appropriate GMSC as described below:
– The SCC AS allocates a CSRN that maps to an appropriate GMSC. Standard CS termination procedures are then executed at the GMSC.
– The GMSC is configured with N-CSI and criteria corresponding to the CSRN. This causes the GMSC to issue an InitialDP containing the CSRN to the gsmSCF.
– The gsmSCF performs a function on the CSRN to obtain the MSISDN of the called party number and the MSISDN is returned to the GMSC in a CONNECT operation together with the CSRN as a Re-direction ID.
– The GMSC continues the normal CS call termination procedure by issuing an SRI to the HSS using the MSISDN, which causes T-CSI to be returned back to the GMSC.
– The GMSC issues another InitialDP containing both MSISDN and CSRN to the gsmSCF. The gsmSCF recognises that it has been triggered for the second time (due to the presence of the CSRN) and therefore returns a CONTINUE for the MSISDN, thus avoiding a circular loop.
– The GMSC sends a MAP SRI query to the HSS with the “Suppress T CSI” parameter, thus allowing the HSS to obtain the MSRN through standard call terminating procedures.
Instead of CSRN, the SCC AS can also use MSRN to route the message.
Use of SCC AS for deriving the MSRN
When the SCC AS decides that the call is to be terminated in the CS domain, the SCC AS retrieves the MSRN from the MSC/MSC-Server from HSS/HLR using either:
- MAP SRI Query: This option makes use of a MAP Interface between the SCC AS and the HSS to request allocation of an MSRN from the HSS for routing of the call to the MSC/MSC-Server currently serving the subscriber.
- Sh UDR Query: This option makes use of the Sh interface between the SCC AS and the HSS. The SCC AS sends a Sh UDR query to the HSS to request allocation of an MSRN for routing of the call to the MSC/MSC-Server currently serving the subscriber.
Example of Terminating flow for Non-ICS MSC
The exact flows differ operator to operator based on their support and internal requirements. Note that there are many other constrains related to provisioning, data convergence, Number Portability, Roaming support etc.
Related posts:
Real Time Communication 