Evolve IMSWorkX IMS Suite¶

IMS Core¶

The IMS Suite provides complete IMS core functionality with the following call session control elements:

• The Interrogating - Call Session Control Function (I-CSCF) is responsible for authentication and session routing and management. It is the contact point within the network for all connections destined to a user of that network. Its main functions are to interrogate the Home Subscriber Server (HSS) during IMS registration to determine which S-CSCF is suitable for routing registration requests to and during call termination to determine which S-CSCF the user is registered on.

• The Serving - Call Session Control Function (S-CSCF) is a Session Initiation Protocol (SIP) server responsible for basic IMS services including providing session setup and tear-down, session control, and routing functions. It generates records for billing purposes and invokes Application Servers based on Initial Filter Criteria (IFC) received from the HSS. The S-CSCF acts as SIP registrar for the User Equipment (UE) that is assigned to it. Via the Diameter Cx Interface, the S-CSCF queries the HSS for the applicable subscriber profiles and handles calls involving these end points.

• The Emergency - Call Session Control Function (E-CSCF) is responsible for receiving emergency INVITE messages from a UE and sending any included location information to a Location Retrieval Function (LRF). Based on the response from the LRF, the E-CSCF will then forward the INVITE to an appropriate public-safety answering point (PSAP). If there is not an LRF or the LRF cannot be contacted, the INVITE will be forwarded to a default PSAP. The E-CSCF permits registration without authentication. On receipt of a REGISTER, the E-CSCF will store information from the registration necessary to permit a call back and fill in the P-Asserted-Identity Header on an INVITE. If a UE attempts to make a call without a corresponding registration, the E-CSCF will send a “380 Alternative Service” message in an attempt to convince the UE to make an emergency registration.

The I-CSCF and S-CSCF are not responsible for voice or SMS service; that is the role of the Application Server. Application Servers provide support for a minimum set of mandatory services and Transport Level Interworking (TLI) as defined by 3rd Generation Partnership Project (3GPP) standards and profiled within the GSMA Permanent Reference Document (PRD) IR.92 - IMS Profile for Voice and SMS.

In a configuration of the IMS Suite, there is always at least two telephony Application Servers and two S-CSCFs involved on a path from originator to recipient, as one applies originating services and the other applies terminating services. The particular services applied is based on configuration of the Application Servers and by data stored in the HSS.

Telephony Application Server (TAS)¶

The flexible and all-encompassing TAS provides call establishment and anchoring of VoLTE calls. Carrier-grade and feature-rich, our TAS conforms to 3GPP standards that UE and networks are required to meet to guarantee interoperability and the highest quality of service.

A TAS in an IMS network is the basic building block of voice and other media services. While not strictly necessary to enable UE-to-UE direct calling, the TAS provides network operators with a full configurable platform to manage policy, routing, and any other operational and deployment considerations to enable the IMS network to provide service to subscribers.

IP-Short-Message-Gateway (IP-SM-GW)¶

To support SMS over IP (SMSoIP) per VoLTE specification, there is a dedicated IP-SM-GW Application Server in the IMS architecture. This element bridges an IP-only IMS subscriber’s device to the existing Short Message Service Center (SMSC). It is a Service Level Interworking (SLI) which can work with Session or Pager Mode Messaging and a Transport Level Interworking (TLI) which can work with SMSoIP only.

Message Signaling

MT SMS

MO SMS

Apex Outbound SMS

Service Centralization and Continuity Application Server (SCC AS)¶

The SCC AS uses methods defined by 3GPP as part of IMS Centralized Services (ICS) to anchor calls and is therefore a key component in delivering reliable VoLTE service. For all calls that are anchored, the SCC AS acts as a Back-to-Back User Agent (B2BUA) establishing call legs to all endpoints in the call from start to finish, ensuring the continuity of calls and call services when switching access networks and when switching between the Circuit Switched (CS) and Packet Switched (PS) access domains. Additionally, it provides the set of basic services defined by ICS for use in both domains.

Our SCC AS is compliant with the Global System for Mobile communications Association (GSMA) document IR.64 - IMS Service Centralization and Continuity Guidelines and provides support for the following supplementary services:

• Originating and Terminating Identification Presentation

• Originating and Terminating Identification Restriction

• Communication Forwarding Unconditional

• Communication Forwarding on not Logged in

• Communication Forwarding on Busy

• Communication Forwarding on not Reachable

• Communication Forwarding on No Reply

• Barring of All Incoming Calls

• Barring of All Outgoing Calls

• Barring of Outgoing International Calls

• Barring of Outgoing International Calls - except Home Country

• Barring of Outgoing International Calls - When Roaming

• Barring of Incoming Calls - When Roaming

• Communication Hold

• Message Waiting Indication

• Communication Waiting

• Ad-Hoc Multi Party Conference

The SCC AS is primarily a SIP Application Server in the IMS. In some scenarios, the SCC AS may be required to act as a GSM Service Control Function (gsmSCF) in order to assist in routing calls in the CS domain.

Multimedia Telephony Application Server (MMTel AS)¶

The IMS Suite provides MMTel AS call control for the following standardized media capabilities:

• Full-duplex speech

• Real-time video

• Text communication

• File transfer

• Picture, video clip, and audio clip sharing

• Add and drop media during a session

Signaling¶

The rest of this chapter details basic call flows in which the IMS Suite is involved.

Registering

VoLTE UE registration should automatically occur on a network that supports VoLTE. When registering the UE in the IMS network, the SCC AS is notified after the IFC match. The S-CSCF sends a third-party registration request to the SCC AS. This request contains in the message body a MIME multipart of both the REGISTER request and the response, as seen by the S-CSCF. This information informs the SCC AS of the subscriber’s state.

Originating

When an Access Transfer Control Function (ATCF) is present in the registration of a mobile-originated call, the P-CSCF sends the INVITE to the ATCF because the Feature-Caps header in the registration contained the an indication that the ATCF is used.

All other operations are done according to standard SIP. The SCC AS supports the tdialog and replaces capability tags and adds them in the “Supported” header if not present.

In some cases, call setup is on the CS access when the MSC Server registers on behalf of the UE in the CS domain and the UE has also registered over the PS domain. In that case, the MSC will send an INVITE into the IMS which will traverse the ATCF and Access Transfer Gateway (ATGW), causing the media to be anchored there.

Terminating

With the UE is registered in the PS and the CS domains (via the MSC), the ATCF is used to anchor the media of the call. The Terminating Access Domain Selection (T-ADS) is responsible for determining how to forward the request to the user.

Access Transferring CS-to-PS

At the point of connecting to a new IP Connectivity Access Network (IP-CAN), the UE A will register using the registration procedures with the IMS. This includes reserving resources on the IP-CAN. The UE A sends the INVITE to request transfer of the call to the PS domain, it is routed to the SCC AS, which performs the “Remote Leg Update” procedure. It reINVITEs the B leg (to UE B) using the newly supplied SDP from the received INVITE. When the IP bearer path is established (after the transactions are completed on both legs), the SCC AS sends a BYE to terminate the call leg that was previously used by UE A, clearing the CS bearer resources.

Access Transferring PS-to-CS

In this scenario, the UE A initiates a connection on the CS domain. The interworking entities eventually create an INVITE to the IP Multimedia Routing Number (IMRN), which is routed to the SCC AS. The flow after that is similar to any other transfer; a reINVITE is sent to the B leg and the previous A leg is disconnected after the new connection is established.

Access Transferring PS-to-PS

This flow is similar to the other transfer cases, but no interworking equipment is required, as the bearer is all IP. The call legs are anchored at the SCC AS, and the reINVITE procedure is applied as in any access transfer.

Emergency Calling

The following diagram shows a normal emergency call.

The following diagram shows an S8 home routing emergency call.