finally an intelligent migration path to ims

15
White Paper Finally, an Intelligent Migration Path to IMS

Upload: louie-mabini

Post on 13-Jul-2016

20 views

Category:

Documents


3 download

DESCRIPTION

ims

TRANSCRIPT

Page 1: Finally an Intelligent Migration Path to IMS

White Paper

Finally, an Intelligent Migration Path to IMS

Page 2: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

2

Executive SummaryWhile IMS has far reaching implications for both wired and wireless networks, the telecom community has been intently focused

on the arrival of Long-Term Evolution (LTE) networks. In fact, more than 300 LTE networks have been deployed worldwide as of

2014, with hundreds more to be added. This has led to many communications service providers (CSPs) finding themselves at a

crossroads between the past and the future as they look to migrate off their legacy network equipment and embrace new network

architectures such as Voice over LTE (VoLTE) and IP Multimedia Subsystem (IMS). But over time, more and more CSPs are indeed

going ahead and strategically replacing their circuit-switched equipment with packet-switched technology (including softswitches,

media servers and session border controllers) in an effort to reduce costs and converge voice, data and video communications into

richer multimedia sessions using the Session Initiation Protocol (SIP) standard.

This has led to a phased migration period, where VoLTE/IMS networks, IP-based Next-Generation Networks (NGNs) and circuit-

switched networks not only continue to co-exist, but also are poised to do so for many years to come, requiring interworking

between these different network architectures. The need for interworking across multi-generation networks through an IP-based

foundation is something that the industry has long anticipated and what the IMS architecture is designed to do. IMS provides a

network model that addresses two key considerations facing CSPs as they migrate to modern networks:

• The delivery of converged media-rich applications over packet-switched, all-IP networks

• The critical interworking needed to support voice communications between 4G (LTE), 3G, 2G and fixed legacy and NGN

networks

A challenge for CSPs today is how to manage this migration without incurring high costs or disrupting customer service. In a market

climate where the average revenue per user (ARPU) is either flat or growing at a minimal rate, and where low-cost or free over-the-

top (OTT) communications applications are eroding market share, often the prevailing sentiment is that CSPs need to manage their

migration carefully and leverage their existing network assets for as long as is practically possible. CSPs are looking for a smart

approach that will provide a seamless transition from legacy to NGN to IMS/VoLTE. This is achieved through a migration strategy

that allows them to:

• Leverage NGN network elements well into the future through built-in IMS capabilities

• Support Network Function Virtualization (NFV) initiatives

• Adhere to industry standards and open concepts to support broad integration with best-of-breed IMS network components

This whitepaper will provide insight on how NGN architectures have evolved into IMS/VoLTE and outline key considerations to

establish an intelligent migration path to IMS. Included in the paper are concrete examples of how Dialogic’s products enable a

seamless and cost-effective migration to IMS/VoLTE networks by facilitating circuit- and packet-switched network interoperability,

safeguarding network security, delivering advanced media capabilities and providing Diameter signaling services.

Page 3: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

3

Table of ContentsAn Introduction to IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

The IMS Architecture: an Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

Services Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Session Control Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

An Intelligent Migration Path to IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

Three Key Initiatives Drive IMS Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

Circuit-to-IP Call Control Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Case Study: Turkcell Superonline Transforms Its IMS and Core Switching Networks . . . . . . . . . . . . . . . . . . . . . .9

Enriched Multimedia Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Diameter Signaling Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

WebRTC and IMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

About Dialogic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

Page 4: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

4

An Introduction to IMSThe origins of IMS date back to the development of 3rd Generation (3G) wireless networks, which soon brought IMS under the direction of the 3rd Generation Partnership Project (3GPP). Early versions of IMS featured the SIP signaling standard, which supports different kinds of media—voice, data, video and texting—in a single communications session. Since SIP was based on IP, it was seen as a natural fit for Voice over IP (VoIP) applications and became a foundational technology in NGN architectures.

CSP interest in VoIP stemmed (and still does) from its potential to reduce network costs and complexity. In the early 2000s, fixed service providers were among the first to migrate their core networks to an IP-based NGN architecture, replacing vast systems of circuit-based Class 4 switches with consolidated softswitches. Mobile service providers eventually followed suit; but as “smart” mobile devices have evolved, the focus on VoIP has shifted such that, in essence, voice has become simply one more application on a mobile device. Today’s subscribers are just as likely to be texting, talking, web browsing, sharing images and watching video from their smartphones and tablets, which requires CSPs to expand the scope of their networks to support this wide variety of devices and applications.

Envisioning the need for a network that could support multiple media types and network architectures based on a common IP platform, 3GPP developed the IMS architecture. As IMS networks handle session control and services differently than an NGN network, there are a variety of IMS concepts and features not found in the NGN architecture, such as Diameter signaling interfaces, separate subscriber databases and the decoupling of services from session control and transport. LTE supports the Radio Access Network (RAN) portion of a 4G mobile network, while the core mobile network was based on the System Architecture Evolution - Evolved Packet Core (SAE-EPC) introduced in 3GPP Release 8 specifications. LTE and EPC are thus complementary technologies to IMS. In fact, IMS is the core architecture for VoLTE, and thus many mobile service providers have accepted IMS as part of their future network migration path.

So where does that leave CSPs today? In many cases, CSPs are conflicted with one half their network still tied legacy systems (particularly in their access networks), half the network upgraded to NGN, and aspirations of evolving to IMS/VoLTE. For this reason, it’s critical that CSPs identify products that accelerate IP-based network transformation and provide a seamless transition to IMS with built-in capabilities that allow NGN elements to be re-purposed as IMS network functions.

The IMS Architecture: an OverviewAs networked communications standards have changed and evolved over the years, the IMS architecture has as well. 3GPP architectural specifications for IMS network have more than a dozen separate and well-defined network functions. The following sections will introduce some of these network functions as they appear in IMS across the services, session control and transport layers.

Page 5: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

5

Figure 1. An architectural overview of IMS

Services LayerSIP-based multimedia services such as voice, video and mobile apps are central to the IMS experience. These services are hosted and served through a variety of SIP Application Servers. IMS networks can also interface with legacy applications that use the CAMEL (Customized Applications for Mobile Enhanced Logic) protocol through the IP Multimedia Service Switching Function (IM SSF). This allows IMS networks to provide service continuity as networks transition from 3G to 4G.

Another important element in the Services layer is the Home Subscriber Server (HSS), which hosts the subscriber data (including numbers and location information). The Home Location Register (HLR) plays a similar role in traditional 2G/3G network. The subscriber data, allowed services, policies and location information in the HSS element are critical for authentication, authorization and accounting in the IMS network.

Session Control LayerUnlike NGN architectures, which use SIP as the primary signaling protocol, IMS uses two main signaling protocols: SIP and Diameter. Diameter is responsible for internal communications between network elements that involve billing, authentication, authorization, charging and policy requests. Both NGN and IMS networks also use the H.248 signaling protocol to manage media gateways via the media gateway controller.

IMS has defined several Call Session Control Functions (CSCFs) to handle SIP communications in the network:

• The Serving-CSCF (S-CSCF) acts as the user registrar and application interface

• The Proxy-CSCF (P-CSCF) serves as the edge-signaling element between the user equipment (UE) and the IMS network for registration and service requests and responses. The P-CSCF forwards SIP messages received from the subscriber’s UE. The P-CSCF also interfaces with the Policy and Charging Rules Function (PCRF) in the mobile network’s EPC (via Diameter) to establish the appropriate policy rules and quality of service levels applied to the user session

• The Interrogating-CSCF (I-CSCF) identifies the appropriate S-CSCF for the subscriber. It performs this task by querying the HSS to determine which S-CSCF is serving the subscriber so it can then forward the SIP messages accordingly. Later releases of IMS de-couple the external network interface function from the I-CSCF and replace it with a separate device, the Interconnect Border Control Function (ICBF), which acts as a secure gateway between the I-CSCF and external networks

Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

Application Services

CSCFI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

IBCF

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Page 6: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

6

A Diameter Signaling Controller (DSC) provides management, security, routing and interworking of Diameter messages between nodes in the IMS and EPC networks. The Diameter Routing Agent (DRA) provides a subset of the overall functionality and use cases supported by a DSC. A DRA can be used to manage and address the routing and session binding requirements of Diameter communications between IMS and EPC nodes. A DRA may also act as a centralized platform that eliminates the complex logical mesh of Diameter connections otherwise required. In addition, the DRA provides a way to implement highly granular routing, load balancing, prioritization, overload control and mediation of messages between Diameter-aware nodes in packet-switched networks.

The Diameter Edge Agent (DEA) supports specific functions for Diameter-based connections between networks. For IMS roaming applications, network operators may wish to have dynamic policy and charging control extend from the home to the visited network; in this case, the DEA would provide proxy, mediation and security capabilities between the PCRF elements in the visited and home networks. A DEA also provides security, Diameter relay and Diameter proxy functionality to inter-network Diameter interfaces involved in supporting roaming between CSPs.

DSCs can also serve as the Interworking Function (IWF) between Diameter and other signaling protocols. For example, the IWF can convert Diameter messages to SS7 messages for specific roaming applications between 3G and 4G networks.

IMS networks make use of media gateways to provide transcoding and transrating services between different media types. These are controlled by the Media Gateway Control Function (MGCF) in an almost identical role to the softswitch as defined in the NGN architecture. An additional element, the Breakout Gateway Control Function (BGCF), provides the call/session routing to and from legacy, non-SIP networks.

Transport LayerCommunications in an IMS network are based on IP; yet outside the IMS network there will exist a mixture of IP and non-IP devices. The transport layer communicates with these devices through various Signaling Gateways and Media Gateways (SGWs, MGWs). Also included in this layer is the Border Gateway (BG), which acts as an advanced security firewall between the IMS network and other external IP networks.

Media services such as tones, announcements and conferencing are handled in the transport layer via the Media Resource Function (MRF), which provides media handling and manipulation, and the Media Resource Broker (MRB), which mediates communications between MRF pools and application servers.

An Intelligent Migration Path to IMSWith nearly all-new and transformative technologies, adoption and migration happens gradually. Migration from legacy, circuit-switched systems to IP-based networks has not been an exception. What’s more - although the migration to IP technology is already well underway, the industry still expects to support the Public Switched Telephone Network (PSTN) until at least 2020 because of factors such as migration issues, regulatory considerations and lagging adoption of new technology.

The adoption of IMS is following a similar pattern. Some IMS network elements facilitate a phased and gradual migration by providing interworking with the PSTN, 2G/3G wireless networks and first-generation VoIP networks. And although the migration from circuit-switched to packet-switched networks has required a sometimes painstaking and often costly “rip-and-replace” strategy, the migration from NGN to IMS has been less painful and costly due to the ability to re-purpose many of the NGN elements within the new IMS framework. Today, many of the elements in an NGN architecture (see Figure 2) have transitioned into a corresponding function within an IMS network (see Figure 3). The longstanding industry awareness of the need for an IMS-styled network has led some network equipment vendors to develop NGN elements with built-in IMS compatibilities for this purpose.

Page 7: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

7

NGN Function IMS Function

Media Server Media Resource Function/Broker (MRF/MRB)

Media Gateway IMS Media Gateway (IMS MGW)

Softswitch Media Gateway Control Function (MGCF), Breakout Gateway Control Function (BGCF)

Signaling Transfer Point Diameter Routing Agent (DRA), Interworking Function (IWF)

Signaling Gateway Signaling Gateway (SGW)

Session Border Controller Proxy Call Session Control Function (P-CSCF), Interconnection Border Control Function (IBCF)

Figure 2. Example of an NGN architecture

Three Key Initiatives Drive IMS MigrationThe road to IMS is rarely a straight line; rather, each IMS network migration differs based on where a CSP currently is with its network deployment versus where it needs to be down the road. But it’s generally called for that CSPs focus their migration around three key initiatives:

• Circuit-to-IP call control transformation

• Enhanced multimedia capabilities

• Diameter signaling services

Dialogic’s service provider infrastructure solutions provide much of the IMS core network functionality (see Figure 3), positioning Dialogic customers to transition their networks seamlessly and cost-effectively to an IMS-based architecture with minimal disruption to their existing network, subscribers and services.

Circuit Network (Wireline + Wireless) Packet Network

Circuit Media Server Application Server

Signal Gateway Softswitch IP Media Server

Media GatewayCentral Office

STP

SCP

IP Network

LAN

Broadband

2G, 2.5G, 3G, UMTS, GSM,

CDMA, etc.

NGN

Page 8: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

8

Figure 3. Dialogic provides much of the core functionality required in an IMS network today

Circuit-to-IP Call Control TransformationIMS defines several functions for intelligent call control, including support for SIP-based sessions and TDM-based voice calls. The MGCF provides the interworking between SIP- and TDM-based communications fulfilling nearly the same role in IMS networks that a Class 4 softswitch acting as an MGCF does in NGN networks. The Dialogic® ControlSwitch™ System softswitch performs the role of an MGCF in an NGN environment, and seamlessly transitions to serve as both MGCF and BGCF in an IMS network. A single instance of the ControlSwitch System can perform both of these roles simultaneously, if desired, or act as a dedicated MGCF or BGCF (see Figure 4).

Figure 4. Dialogic ControlSwitch as the MGCF/BGCF in an IMS network.

Dialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

Dialogic® ControlSwitch™ System

SIP AS CAMEL OSA AS

IMS

Dialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

Application Services

CSCFI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

IBCF

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Page 9: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

9

As an MGCF in an IMS network, the ControlSwitch System provides interworking with the PSTN. It controls the media interworking by communicating with media gateways (including for example, Dialogic® I-Gate® 4000 PRO and/or EDGE Media Gateways) using the H.248 protocol, and controls the signaling communications with PSTN switches using SIP-to-ISUP (ISDN User Part) interworking.

As a BGCF, the ControlSwitch System helps determine when and how IMS-to-PSTN calls exit (i.e., break out of) the IMS network and gets routed to a PSTN-served endpoint. The ControlSwitch System BGCF functionality uses SIP to either route the call internally to an MGCF in the IMS network or to another BGCF in a different IMS network.

A sample call flow for an IMS-to-PSTN call using the ControlSwitch System as a combined MGCF/BGCF can be:

1) A smartphone sends a SIP INVITE to the host network’s P-CSCF

2) The P-CSCF forwards the invite to the appropriate S-CSCF (as selected by the I-CSCF)

3) The S-CSCF sends the invite to the ControlSwitch System (as the BGCF)

4) Because the ControlSwitch System also fulfills the function of the MGCF, a separate SIP message from the BGCF to the MGCF is not required. Instead, the ControlSwitch System (as the MGCF) sends an ISUP message to the PSTN switch to open the session and an H.248 message to the IMS Media Gateway to open the media path for the call

Case Study: Turkcell Superonline Transforms Its IMS and Core Switching NetworksTurkcell Superonline is part of the Turkcell Group, a leading information and communications technology provider with approximately 61.7 million subscribers across nine countries. Turkcell Superonline provides comprehensive voice and data telecommunications for wholesale, corporate and residential customers. Turkcell was motivated to find a long-term replacement to its core switching platform when its softswitch vendor announced it was discontinuing the softswitch. Because of plans to migrate to IMS, Turkcell sought a new solution that would provide the TDM-to-IP connectivity it needed today as well as the TDM-to-IP-to-IMS connectivity it would need tomorrow.

In assessing its requirements for a replacement to its existing softswitch implementation, Turkcell Superonline saw the Dialogic ControlSwitch System as providing a carrier-class, IP-based solution that was uniquely suited to meet its immediate replacement

needs and also provide an IMS-ready MGCF platform. The Dialogic solution enabled Turkcell Superonline to replace both of its legacy softswitches with a single ControlSwitch System softswitch, and allowed Turkcell Superonline to still utilize its legacy universal gateways, which resulted in substantial savings. Turkcell Superonline also selected Dialogic I-Gate 4000 media gateways to provide SS7 connectivity and optimize network bandwidth.

“(The Dialogic ControlSwitch System) provided us with a cost-effective and operationally efficient way to leverage our existing base of Cisco gateways and seamlessly interconnect to our Ericsson IMS core network. Dialogic’s commitment to the technology and its experience with successfully transitioning service providers like us from legacy switching platforms… gave us confidence that our customers would be minimally impacted.”

-- Barbados Ozdemir, Director of Corporate Business Management, Turkcell Superonline.

Dialogic’s BorderNet™ 4000 Session Border Controller (SBC) transitions seamlessly to serve the role of the P-CSCF in an IMS network (see Figure 5). The BorderNet 4000 SBC supports up to 32,000 simultaneous SIP sessions and easily accommodates variations in SIP signaling implementations. As part of Dialogic’s proven NGN portfolio, the BorderNet 4000 SBC integrates “out of the box” with the ControlSwitch System, providing interoperability between the MGCF, BGCF and P-CSCF elements from day one. The BorderNet 4000 can also serve as an IBCF, providing network security and Network Address Translation (NAT) services between the I-CSCF and external networks.

Page 10: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

10

Figure 5. Dialogic’s BorderNet 4000 SBC as the Proxy-CSCF in an IMS network

Enriched Multimedia CapabilitiesMultimedia is at the center of IMS, and there are several new media functions defined in the IMS architecture that enable CSPs to enhance and enrich multimedia sessions, from media servers to media gateways. The Dialogic® I-Gate® 4000 EDGE and PRO Media Gateways provide high reliability/availability, media transcoding and bandwidth optimization for NGN and IMS/VoLTE architectures. Both the smaller EDGE series and the larger PRO series help smooth the transition to IMS architectures by serving the function of an IMS Media Gateway (IMS MGW) (see Figure 6). IMS MGWs act as the point of interconnection between circuit-switched bearer channels with IP packet-based media streams. IMS MGW functionality includes conversion of media formats (transcoding) to support the different end-point codecs in the network. The I-Gate 4000 EDGE and PRO provide robust interworking capabilities in an IMS network, including IP-to-IP and IP-to-TDM media transcoding, media optimization, RFC 4117 support, SIP/H.248 signaling and support for function-specific IMS signaling interfaces.

Figure 6. The Dialogic I-Gate 4000 EDGE/PRO as an IMS Gateway/Media Gateway.

Dialogic® BorderNet™ 4000 SBCDialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFCSCI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Dialogic® I-Gate® 4000 EDGE / Dialogic® I-Gate® 4000 PRODialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFCSCI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Page 11: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

11

The SGW converts the SS7 TDM based signaling to IP or SIGTRAN. An I-Gate 4000 PRO/EDGE media gateway can act as an SGW in instances where Dialogic’s ControlSwitch System is deployed as the MGCF. In IMS networks where a third-party MGCF is deployed, a Dialogic® DSI Signaling Interface Unit can easily transition to act as the SGW (see Figure 7).

Figure 7: Both Dialogic’s I-Gate 4000 EDGE/PRO media gateways and DSI Signaling Interface Unit can serve as the IMS SGW depending on the MGCF selected.

Dialogic’s PowerMedia™ XMS is a powerful media server that can fulfill the joint roles of MRF and MRB in an IMS network (see Figure 8). PowerMedia XMS features advanced multimedia capabilities including support for the Opus audio codec, VP8 video codec and HTML5 browsers, enabling it to also serve as a media gateway between IMS and Web Real-Time Communication (WebRTC) networks. The PowerMedia XMS supports the Media Server Markup Language (MSML) interfaces (RFC 5707) for multimedia control in an IMS network.

Figure 8. PowerMedia XMS media server acts as a unified MRF/MRB in IMS networks.

Dialogic® Signaling Interface Unit (When 3rd Party MGCF is utilized)Dialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFCSCI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Dialogic® PowerMedia™ XMSDialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFCSCI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Page 12: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

12

Diameter Signaling ServicesAlthough NGN networks use the Diameter signaling protocol, the increasing signaling traffic volume and sheer number of Diameter interfaces in EPC and IMS core networks are making DSCs indispensable. Diameter signaling traffic in an IMS network increases exponentially as the number of nodes grows, requiring a centralized device (i.e., the DSC) to manage the proliferation of billing, accounting, authorization, charging and policy messages between IMS and EPC nodes. Dialogic® Helix™ Signaling Controller is a next-generation DSC that integrates

multiprotocol Interworking, DEA functionality and DRA functionality in a single device (see Figure 9).

Figure 9. The Helix™ Signaling Controller (HSC) controls Diameter signaling in the IMS network.

CSPs can leverage the intuitive Diameter mediation capabilities of the Helix™ Signaling Controller (HSC) to rapidly address Diameter interoperability issues as well as provide support for proprietary Diameter protocol extensions between IMS and EPC nodes—without the need for time-consuming development work from their infrastructure vendors. This provides opportunities to save costs and accelerate revenue by speeding up implementation of IMS/VoLTE networks and associated services.

WebRTC and IMSWebRTC is an extension of IMS that is positioned to be both a popular and potentially disruptive technology. At a high level, WebRTC allows media sessions to be embedded in an HTML5-based browser rather than tied to a traditional SIP client such as a smartphone. With WebRTC, sessions can be launched, for example, on a web site or from a store kiosk, with end users connecting to these sessions anonymously without having to provide a phone number or user ID. Likely applications for WebRTC include OTT, call center and social media applications.

The 3GPP continues to look at ways to integrate WebRTC within the IMS architecture so that WebRTC sessions can take advantage of IMS services. For example, while WebRTC supports client-to-client media transmission, there are many reasons to believe that CSPs will adopt server-side media hosting in an effort to reduce latency, increase quality and conserve both battery life and data usage on mobile devices.

Dialogic® Helix™ Signaling ControllerDialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFCSCI/S-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

P-CSCF

BGCF

BG

TR-GW

MGCF

SGW

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Page 13: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

13

Figure 10. IMS architecture with WebRTC enhancements

WebRTC-IMS interworking requires that several functional elements be added to the IMS architecture: a dedicated access gateway, a dedicated P-CSCF and a dedicated media server (see Figure 10). The eIMS Access Gateway (eIMS-AGW) is a WebRTC-to-IMS gateway that achieves proper transcoding of WebRTC-encoded media (e.g., Opus audio codec or VP8/9 video codec) to the appropriate IMS codec. The eProxy-CSCF (eP-CSCF) is an SBC-based policy and routing engine that supports WebRTC-based signaling and roaming. The ability to route and bill WebRTC sessions is important since these sessions can be launched from a URL instead of a device with a Subscriber Identity Module (SIM) card. Also needed is an eMedia Resource Function (eMRF) to provide value-added media services (e.g., tones, announcements) in instances where no other media server is engaged in the WebRTC session.

ConclusionThe road to IMS will happen in stages for most CSPs as they look to migrate their legacy Class 4 switching networks to an all-IP infrastructure, embrace multimedia communications and enable Diameter services in their networks. Dialogic offers CSPs a “path of least resistance” with a product suite that fulfills the NGN needs of today — low CAPEX/OPEX, network consolidation, continued connection to PSTN networks, IP-based services — and at the same time addresses the IMS/VoLTE needs of tomorrow. Dialogic products deliver an open and standards-based foundation for IMS that seamlessly supports the deployment of additional elements (e.g., HSS) from other equipment vendors for a “best-of-breed” approach.

Whether migrating to NGN or IMS/VoLTE, Dialogic’s core product strengths of intelligent call control, rich media and signaling processing, media servers and any-to-any connectivity across multiple technology domains help CSPs transform their networks. As CSPs look further ahead to WebRTC applications and virtualized Cloud platforms, they can continue to look to Dialogic for solutions that fuel the networks of tomorrow.

Dialogic® PowerMedia™ XMSDialogic product / planned product Signaling traffic Bearer traffic

SERVICES

SESSION CONTROL

TRANSPORT

IBCF

Application Services

CSCFCSCFI/S-CSCF

P-CSCF

eP-CSCF

SIP ASSLF SIP ASWebRTC SIP ASOSA SCS IM SSF

MRFMRB

BGCF

BGeIMS-MGW

TR-GW

MGCF

SGW

eMRF

IMS MGW

IWF

DEA

DRA

Charging Functions

Applications

3G UTRAN2.5G GERAN

IPX

MNO

IPV4/IPV6IP-CAN

HSS

IPX

IP Networks

Mobile and CS Networks

SIP AS CAMEL OSA AS

IMS

Page 14: Finally an Intelligent Migration Path to IMS

Finally, an Intelligent Migration Path to IMS White Paper

14

About DialogicDialogic, the Network Fuel® company, inspires the world’s leading service providers and application developers to elevate the performance of media-rich communications across the most advanced networks. We boost the reliability of any-to-any network connections, supercharge the impact of applications and amplify the capacity of congested networks. Forty-eight of the world’s top 50 mobile operators and nearly 3,000 application developers rely on Dialogic to redefine the possible and exceed user expectations.

To learn more about Dialogic’s IMS solutions portfolio and product roadmap, contact your local Dialogic representative or visit us on the Web at www.dialogic.com/IMS.

Page 15: Finally an Intelligent Migration Path to IMS

www.dialogic.com

For a list of Dialogic locations and offices, please visit: https://www.dialogic.com/contact.aspx

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH PRODUCTS OF DIALOGIC CORPORATION AND ITS AFFILIATES OR SUBSIDIARIES (“DIALOGIC”). NO LICENSE, EXPRESS OR IMPLIED, BY

ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN A SIGNED AGREEMENT BETWEEN YOU AND DIALOGIC, DIALOGIC ASSUMES NO

LIABILITY WHATSOEVER, AND DIALOGIC DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF DIALOGIC PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS

FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHT OF A THIRD PARTY.

Dialogic products are not intended for use in certain safety-affecting situations. Please see http://www.dialogic.com/company/terms-of-use.aspx for more details.

Dialogic may make changes to specifications, product descriptions, and plans at any time, without notice.

Dialogic is a registered trademark of Dialogic Corporation and its affiliates or subsidiaries. Dialogic’s trademarks may be used publicly only with permission from Dialogic. Such permission may only be

granted by Dialogic’s legal department at 6700 de la Cote-de-Liesse Road, Suite 100, Borough of Saint-Laurent, Montreal, Quebec, Canada H4T 2B5. Any authorized use of Dialogic’s trademarks will be subject

to full respect of the trademark guidelines published by Dialogic from time to time and any use of Dialogic’s trademarks requires proper acknowledgement.

This document discusses one or more open source products, systems and/or releases. Dialogic is not responsible for your decision to use open source in connection with Dialogic products (including

without limitation those referred to herein), nor is Dialogic responsible for any present or future effects such usage might have, including without limitation effects on your products, your business, or

your intellectual property rights.

Any use case(s) shown and/or described herein represent one or more examples of the various ways, scenarios or environments in which Dialogic® products can be used. Such use case(s) are non-limiting

and do not represent recommendations of Dialogic as to whether or how to use Dialogic products.

Copyright © 2015 Dialogic Corporation. All rights reserved. 03/15 14122-02