IMS is a network architecture for operators offering end-user services in All-IP networks

IMS is a service enabler. Examples of standardized IMS-based services are conferencing, presence, messaging and IPTV (4). On top of IMS we can also have various non-standardized services.

The main RFCs of interest in IMS are those related to protocols (1) such as RFC3261 for SIP, RFC 2327 for SDP, RFC 3588 for Diameter and RFC 3550 for RTP. IMS Related specifications are mainly found in the 23 & 24 Series of specifications. IMS-Related Specifications:

TS 23.218 IP Multimedia (IM) session handling; IM call model; Stage 2 TS 23.228 IP Multimedia Subsystem (IMS); Stage 2 TS 24.228 Signaling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 the GSMA is establishing an industry wide, standardized, IMS based solution for voice and SMS over LTE.

IR.92 IMS Profile for Voice and SMS (1) is the main specification for VoLTE. It defines a number of EUTRAN, Evolved Packet Core, IMS core and UE features which are essential to guarantee an interoperable, high quality IMS-based telephony service over LTE radio access.

IR.94 (2) Defines a minimum mandatory set of features from 3GPP specifications that a wireless device and a network are required to implement to guarantee an interoperable, high quality IMS-based conversational video service over LTE radio access.

IR.64 (3) Provides guidelines for the centralization of IMS services and IMS based service continuity for single radio devices by listing a number of Evolved Packet Core, IMS core, and User Equipment (UE) features on top of the features defined in IR.92. The goal is for the user to be able to receive services in

a consistent manner no matter if hes accessing IMS via the Circuit Switched (CS) or the Packet Switched (PS) domain.

The goal of IR.65 (4) is to ensure that crucial issues, such as interworking and roaming, are handled correctly following the introduction of IMS. It introduces: guidelines for the usage of inter-Service Provider connections in the IMS environment IMS requirements for the Inter-Service Provider IP Backbone network other issues, such as addressing and routing implications of IMS

IR.88 (5) aims to provide a standardized view on how LTE networks can interwork in order to provide Next Generation Mobile Network capabilities when users roam onto a network different from their home network.

IR.58 (6) defines a voice over HSPA IMS profile by profiling a number of HSPA, (Evolved) Packet Core, IMS core, and UE features which are considered essential to launch interoperable IMS based voice on HSPA. There are also other VoLTE-related PRDs produced by GSMA: (1) IR.58 IMS voice on HSPA (2) IR.94 Video call additions (3) IR.64 SR-VCC (Single Radio Voice Call Continuity) and ICS (IMS Centralized Services) to handle VoLTE and 2G/3G coexistance. (4) IR.65 IMS roaming

(5) IR.88 LTE roaming

Circuit Switched Fall Back (CSFB) 3GPP TS 23.272

Single Radio Voice Call Continuity (SRVCC)

3GPP TS 23.216

IMS Centralized Services (ICS) 3GPP TS 23.292

IMS Centralized Services provides communication services such that all services, and service control, are based on IMS mechanisms and enablers. It enables IMS service control when using CS access for the media bearer to provide the same end user experience to subscribers as if they were using LTE access. By using only one service engine regardless of CS or PS access it will enable: (1) The same user experience regardless of access (2) No need for service synchronization between PS and CS (3) And easier service evolution by having a single point of service provisioning.

In the early stages of ICS deployment there is no need to have specific ICS functionality in the User Equipment.

P-CSCF is the first contact point in the IMS network.

There are four unique tasks assigned for the P-CSCF: SIP compression, IPSec security association, interaction with Policy and Charging Rules Function (PCRF) and emergency session detection.

It behaves as a stateful proxy and performs the following main tasks: Keeps track of registrations and active call sessions. Stores the UE Contact info (IP address and port). Enforces min/max registration times. Forwards SIP messages from the access network to the SIP server in the home network (and vice versa). Compression of Messages

The I-CSCF is the entry point for all connections terminating in the subscriber home IMS network.

It performs the following main tasks: Assigns an S-CSCF during initial registration, in cooperation with the HSS. Routes SIP requests received from another network towards the S-CSCF.
Three unique tasks assigned for the I-CSCF: Obtaining the name of the next hop (either S-CSCF or application server) from the Home Subscriber Server (HSS). Assigning an S-CSCF based on received capabilities from the HSS. The assignment of the S-CSCF will take place when a user is registering with the network or a user receives a SIP request while they are unregistered from the network but has services related to an unregistered state (e.g., voice mail). This procedure is described in more detail in Section 3.9. Routing incoming requests further to an assigned S-CSCF or the application server (in the case of public service identity.

S-CSCF performs session control services including: Subscriber registration, acting as a SIP Registrar, and authentication. Downloading the user profile with service trigger data from HSS. Triggering of the Application Servers in order to provide multimedia services. SIP Message Routing. Number Normalization from local numbers to global E.164 numbers. Querying the ENUM DNS for translation of E.164 numbers to routable SIP URIs. Breakout. Supervision of ongoing sessions using the session timer. Accounting data output.

Home Subscriber Server (HSS) is the network master database for SIP traffic handling, and contains user and subscriber information. The HSS provides the following capabilities:

Identification of users. Authentication and authorization of user access. It keeps track of which S-CSCF the user is registered to. It performs service information support triggers and application server identities are stored in the user profiles.

ENUM Domain Name Server (ENUM DNS), or IPWorks, as it's called in Ericsson IMS, provides translation of E.164 numbers into public, routable SIP URIs. This enables the user to have a public E.164 number that can be used as an address for calls towards the user. The ENUM DNS node also provides standard DNS functions, for example to resolve FQDNs to IP Addresses, and DHCP support for IPv4 and v6 networks. The MMTel Application Server provides end-user telephony services for the user. An example of a valueadd service provided by MTAS is call forwarding. The Application Server triggering is handled by the S-CSCF (1). MTAS stores user information in HSS (2) for redundancy purposes.
The PCRF is responsible for making policy and charging control decisions based on session and media-related information obtained from the P-CSCF. If an operator applies the policy and charging control, then the P-CSCF will forward the relevant SDP information to the PCRF together with an indication of the originator. The PCRF generates charging rules and authorizes the IP flows of the chosen media components by mapping from SDP parameters to authorized IP QoS parameters for transfer to the access network e.g., GGSN in case of UMTS/GPRS access.

The Session Border Gateway (SBG) enables management of IP sessions across the system network borders in order to ensure security and quality of service, enforce service level agreements, Network Address Translation and Firewall traversal, and so on.

What is Border Control / SBC Solving? Connectivity with different devices, services and access networks Service continuity VoLTE-3G, Private IP assigned by e.g. WiFi AP eSRVCC, Far End NAT, Voice and Multimedia Services Security and confidentiality for the user

Encryption of signaling and media VoLTE IMS AKA/IPSec and WiFi IMS AKA/TLS authentication Protection for the IMS core network Protection for attacks such as DoS Topology Hiding for IMS Core Interworking between different protocols and codecs Interworking (IPv4-6) and Transcoding (Wideband, Narrow Band) Protocol (SIP, Codec) normalization Regulatory requirements Lawful Intercept

EMA provides one uniform interface for provisioning, through which all databases can be accessed from the Customer Administration System (CAS).

Following are various Solution Design we can offer: OTT Voice SIP to vMSC VoLTEvG CS in EPS CS o LTE IMS VoIP IMS MMTel MSC AS IMS-GW-MSS Localized IMS

CS Fallback the One Voice initiative, an IMS-based strategy created to align operators and terminal vendors. The One voice base feature set has been agreed to by the operators and vendors supporting the initiative. IR.92 specifies the User-to-Network Interface for VoLTE, including: (1) Definition of MMTel telephony and supplementary services (2) Definition of IMS control and media handling How to handle SMS over IP in IMS How to handle emergency calls in IMS (3) Definition of EPC IP flow and bearer management

(4) What LTE radio capabilities to be used VoLTE IR.92 profile is a Minimum set of already existing standards to enable early network and terminal interoperability. (1) Still, it is an Extendable Profile: It is upwards compatible with full IMS multimedia telephony. (2) The profile enables a full network implementation towards a limited (VoLTE) device, and vice versa Add on of multiple devices is possible (3), as well as Additional media capabilities (HD Voice, Video etc) (4) Further accesses (5), and an Extended Supplementary Service set (6)

All to enable a future enriched communication service offering

In order to handle SRVCC handover signaling there is a new interface introduced between the MME and the MSC-server, the Sv Interface. The GTP-C protocol over UDP is used over the Sv interface. The MSC Server enhanced for SRVCC will also initiate a session towards SCC AS via the I2 Interface in order to connect the CS-leg to IMS. SCC-AS executes the actual access transfer between the CS and PS access domains. SRVCC Call handover and re-establishment phase:

1. The eNodeB decides to do a SRVCC handover based on signal strength measurements. (1) 2. The MME handles the SRVCC handover via the Sv interface. (2) 3a. The MSC-Server and RAN prepares to receive a handover. (3) 3b. The MSC-Server sets up a call to the ATCF using the Session Transfer Number for SRVCC (STN-SR) and performs handover towards the CS Access Network. (4) The STN-SR is an E.164 number used as B-number in a SIP INVITE or ISUP IAM. It identifies the SRVCC service in SCC AS. 4. The ATCF finds the anchored call and executes session transfer. (5) 5. The ATGw is updated with a new media destination for the transferred party. (6) 6. Media is re-established over CS-access towards the UE. (7)

On receipt of the REGISTER message the IMS network: Checks if the user belongs to the home domain and has a subscription. Authenticates the user, if required. Allows the user to register in the system.

Authentication is the procedure used to verify the identity of a user when Registering or sending messages. Four types of authentication are used in IMS. When using HTTP Digest Authentication, the User is challenged by the S-CSCF. It receives a nonce, which it uses together with a password to calculate a response. The S-CSCF calculates its own response, using information from the HSS, and if it matches the one from the user, the authentication is successful. The HTTP Digest mechanism requires the user password to be stored in HSS and in the UE. When using GIBA, neither the UE nor the IMS System need to provide a user password. GIBA relies on the user being authenticated when attaching to GPRS. The GGSN will send the UE IP address and the MSISDN and IMSI of the user to HSS using RADIUS. This triplet is referred to as the master session. It is compared to the information received in the REGISTER.

NBA is similar to GIBA, but for fixed users. It implies that the user is authenticated when gaining IP access to the operator's access network. The lineID from which the user will be authenticated is provisioned in HSS, and compared to the information in the SIP REGISTER. If there is a match, authentication is successful. The IMS AKA procedure is similar to the SIP Digest authentication, but requires a specific set of SIP headers and parameters to establish IPSec associations between the UE and the P-CSCF. When the IMS AKA procedure is done, all subsequent SIP messages between the UE and P-CSCF will be protected by IPSec.

A first REGISTER request is sent from the UE to the S-CSCF. It contains an Authorization header, but the nonce and response values in the header are empty, since no nonce has been received yet. As a consequence of this, the S-CSCF returns a 401 Unauthorized, providing a nonce-value to the UE.

The UE uses the nonce and his password to calculate a response using the specified algorithm. He then provides the response to the S-CSCF in a second REGISTER. The S-CSCF calculates his own response, using information provided by the HSS, and makes sure that this response matches the one received from the UE. It does, and a 200 OK is sent back, indicating that the registration was successful.

the dedicated EPS bearer establishment procedure. 1. The MMTel applications negotiate a SIP session. 2. The P-CSCF gets to know the session information (negotiated codec rates, negotiated IP addresses and ports, etc.) from the SDP answer and sends a corresponding authorization via Rx. 3. The PCRF receives the session information, generates a dynamic PCC (Policy Control and Charging) rule per media stream, and sends the rules via Gx. 4. The PCC rule triggers the establishment of a dedicated bearer. The media stream is started and mapped to the corresponding dedicated bearer.

SIP is the main protocol used in IMS, the IP Multimedia Subsystem. It is used to set up multimedia sessions, to update them, and to release them once they are over. It is also used to transport session descriptions, to enable users to negotiate the media in a session.

A SIP server can also act as a Back-to-Back User Agent. Logically, a Back-to-Back User Agent consists of two user agents. Signaling for a call enters one of the UAs, acting as a UAS, and leaves through the other UA, acting as a UAC. The difference compared to a proxy is that the B2BUA can modify the payload, for example the SDP. When a Back-to-Back user agent is used, the connection will consist of two call legs, one on each side of the server. In IMS, the Application Servers, SBGs and MGCs act as Back-to-Back User Agents.

OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, and so on, without "ringing" the other party. OPTIONS can be used for checking both signaling and media capabilities.

Loose routing--If a proxy has to remain in the SIP dialogue, even after the establishment phase, so-called loose routing can be used. This means that all messages will transit that proxy. The reason for this could include charging, security or service requirements. Loose routing make used of the two header fields Record-Route and Route. The proxy, that wants to remain in the dialogue, will add its URI in a Record-Route header in the request and an lr flag indicating that loose routing should be applied. The UAS will store the addresses from included Record-Route fields and also forward them to the UAC.

Session Description Protocol SDP (RFC2327) specifies a way to describe a session in text format. However it was originally conceived as a way to describe multicast sessions. Since many VoIP sessions are unicast there is a need for the two participants to negotiate and agree on session properties both ways. RFC3264 describes how SDP can be used in such a context, sending offers and answers, with the possibility to decide on common settings.

Message example INVITE sip: +46812345678@operator.net SIP/2.0 Via: SIP/2.0/UDP tes1.operator.net; branch=z9hG4bKjjadfhaiud Max-Forwards: 70 To: phone <sip: +46812345678@operator.net> From: phone <sip: +46887654321@domain.net>; tag=1928301774 Call-Id: sa8l5d2kj7ha@tes1.operator.net Cseq: 2435 INVITE Contact: <sip: +46887654321@tes1.operator.net> Content-Type: application/sdp Content-Length: 141 v=0 o=- 4574163516 4574163516 IN IP4 tes1.operator.net s=c=IN IP4 192.0.100.2 t=0 0

m=audio 20000 RTP/AVP 8 a=rtpmap:8 PCMA/8000