hr diameter control plane orchestration wp

White Paper

Control Plane Orchestration:

The Evolution of Service

Innovation Attributes

Prepared by

Jim Hodges

Senior Analyst, Heavy Reading

www.heavyreading.com

on behalf of

www.dialogic.com

June 2014

http://www.heavyreading.com/

http://www.dialogic.com/

HEAVY READING | JUNE 2014 | WHITE PAPER | CONTROL PLANE ORCHESTRATION 2

Introduction Over the past 18 months, there has been a profound change in the role and relative

importance of the control plane, as the telecom industry evolves to a software-

centric architecture and services model built around software-defined networking

(SDN) and network functions virtualization (NFV).

Given that the control plane is protocol-centric, there is a high degree of interest in

leveraging protocols such as Diameter in more innovative ways to drive the next

phases of service innovation, and ultimately create a services-agnostic orchestra-

tion layer.

Accordingly, the focus of this white paper is to document the role and evolutionary

phases that Diameter nodes – specifically, centralized Diameter Signaling Control-

lers (DSCs) – play in this new model, and how they are expanding past supporting

just Diameter to address the requirements for multi-protocol signaling orchestration.


Orchestrating the Control Plane As touched upon in the introduction, the end-to-end services policy-driven orches-

tration model driven by SDN and NFV is fundamentally changing how the control

plane is utilized in next-generation virtualized IP networks. In this section of the white

paper, we explore what this means for Diameter-based control plane nodes and

why they are positioned to assume a greater role in service orchestration.

The Role of Diameter & DSCs

More than 10 years ago, before the vision of all-IP networks had solidified from an

architecture perspective, there was industry consensus that existing control plane

authentication and authorization protocols such as SS7 and even the more modern

RADIUS would not meet the payload and extensibility requirements that IP networks

would vitally need to provide support for mobile broadband services. Specifically,

what was required was a protocol that could flexibly meet the requirements asso-

ciated with authentication, authorization and accounting.

Accordingly, the industry, via several standards bodies, collaborated to create the

Diameter protocol, which utilizes TCP or SCTP transport, supports transport layer se-

curity and, perhaps most importantly, provides a large and flexible address space

(32 bits) to meet new services requirements.

To meet these requirements, Diameter was designed to support attribute value pairs

(AVPs) – open-ended data structures with values that can be added, deleted or

modified based on unique service requirements of either the origination or destina-

tion node. In a services context, this means Diameter can support new value-added

services on the control plane without impacting existing defined service values. In

addition, Diameter supports both stateful and stateless service request models,

which delivers even greater implementation flexibility.

Following the completion of Diameter protocol standardization, it was adopted as

the control plane protocol interfaces for IP Multimedia Subsystem (IMS) core, packet

core and billing systems. Although this was a very positive step, the original archi-

tecture advocated a peer-to-peer model in which each network node managed

its own point-to-point signaling interfaces.

However, following several peer-to-peer-based "signaling storm" incidents in 2012

by operators such as NTT Docomo, a standalone and centralized node that could

handle all Diameter interfaces was standardized both in the core (a Diameter Rout-

ing Agent, or DRA) and at the network's edge (a Diameter Edge Agent, or DEA), to

deliver control plane elasticity and simplify interface administration. A Diameter node

that supports these capabilities and interfaces is generically referred to as a DSC.

Therefore, strategically, as shown in Figure 1, the DSC has become an indispensable

component of next-generation network control planes, because not only can it

route messages between the operations/business support system (OSS/BSS), service

control/applications and Evolved Packet Core (EPC) layers, it was designed with

several distinct agent capabilities to either modify, translate or simply relay AVP-

based messages.

Moreover, this central network position means that the DSC can play a central role

in managing service quality by managing session and node failover, since DSCs are

session-aware and able to manage a large number of AVPs, depending on specific


service requirements. The addition of protocol translation functions also means that

a DSC is able to interwork with legacy and other non-Diameter network control

plane protocols and nodes to ensure ubiquitous services interworking. However, it is

important to note that not all DSCs automatically support all four agent functions.

The four agent functions are defined as follows:

Relay: Relay agents can insert and remove routing information but don't

make any other AVP changes. They perform a basic relay message func-

tion and do not maintain session state.

Proxy: In addition to relay, can modify message AVPs. Proxies maintain ses-

sion state and are application-aware.

Redirect: A redirect agent is not used to relay messages, but only provides

information to a Diameter node, so that it can communicate with another

Diameter node. Redirect agents do not maintain session state.

Translation: Translation agents translate and interwork Diameter with other

protocols, such as GSM MAP and RADIUS. This functionality can also be used

to interwork vendor-specific Diameter-to-Diameter protocol implementa-

tions. Translation agents maintain session state.

Since 2012, network and services requirements have continued to evolve at a rapid

pace. As a result, as captured in Figure 2, three distinct DSC evolutionary phases

can already be identified.

Figure 1: DSC Connectivity Model

Source: Heavy Reading


DSC Evolution Phase 1: 2010-2012

Deployment Drivers and Functionality: Focused on basic Diameter relay message

routing and typically support little or no message modification capabilities. Many of

the earlier projects were deployed as one-off custom interworking solutions, or as a

front-end proxy for a Diameter Server Agent.

DSC Design Characteristics: DSCs in this phase often utilize a monolithic "purpose-

built" design to maximize throughput. They are more hardware- than software-cen-

tric, and are not well suited to managing call state and policy enforcement.

DSC Evolution Phase 2: 2013-

Deployment Drivers and Functionality: In this phase, DSC functionality expands to

include additional proxy and more advanced translation capabilities, such as multi-

protocol translation (including the IWF function) and service orchestration, to assist

with managing complex policy-based message flows. Orchestration scope includes

the ability to translate Diameter and non-Diameter message flows with intelligence

from external data repositories, as well as apply conditional statements based on

deep packet inspection of events and AVP attributes (e.g., International Mobile

Subscriber Identity, or IMSI).

DSC Design Characteristics: DSCs in this phase no longer follow a monolithic design

and are more software- than hardware-centric, given the additional software intel-

ligence to maintain session state and application awareness. DSCs in this phase start

to be deployed on commercial-off-the-shelf (COTS) hardware.

DSC Evolution Phase 3: 2014-

Deployment Drivers and Functionality: In late 2012, the telecom world underwent

an unprecedented change with the conceptual emergence of NFV, which advo-

cates software virtualization of network functions, and SDN, which defines a distinct

Layer 2/3 access network control plane to facilitate a common policy and service

orchestration routing framework. Therefore, while the DSC was not originally envis-

aged to support virtualized service orchestration, the DSC that is emerging in this

third evolution phase is positioned to play a key role.

DSC Design Characteristics: This phase sees the introduction of even more intelli-

gent, purely software-centric DSCs, which not only serve as an integrated software-

Figure 2: DSC Evolutionary Phases



based platform for routing and protocol interworking and mediation, but can also

support virtualized applications to empower a new generation of cloud-based

value-added services. One of the most visible design characteristics of a DSC from

this phase is the ability to leverage this additional software intelligence to manage

more complex orchestration functionality with no specific hardware dependencies.

From an investment protection perspective, while a monolithic Phase 1 DSC is highly

unlikely to support Phase 3 requirements, a Phase 2 DSC has the potential, but it is

not as straightforward as it may seem. To really take advantage of the elasticity,

orchestration and on-demand capabilities of the cloud, it is important to have the

foresight to implement an open, modular and extensible software design model.

The Impact of Control Plane Virtualization on Service Orchestration

As noted above, NFV introduces the concept of virtualized service orchestration. As

defined in the most recent ETSI white papers, the orchestrator function, illustrated in

Figure 3, manages the execution of the various virtualized network functions (VNFs)

in the services control/application, EPC or even OSS/BSS layers.

While the objectives of service orchestration are easy to grasp, the implementation is

inherently complex, since VNFs can run either in the data center or on customer prem-

ises, to minimize application latency. Further complexity stems from the fact that the

NFV orchestrator by default must be aware of all active VNFs running in the network.

However, while the above diagram does not capture the role that Diameter or DSCs

play in the orchestration process, it is important to note – as illustrated in Figure 4 –

Figure 3: ETSI Orchestration Framework

Source: ETSI Network Functions Virtualisation – Update White Paper, October 2013

http://portal.etsi.org/nfv/nfv_white_paper2.pdf


that a DSC is in-path of the orchestration function, by virtue of the fact that it sup-

ports all the OSS/BSS, service control/applications and EPC virtualized interfaces.

Furthermore, as a central node with knowledge of VNF application invocation, rout-

ing and session state, a DSC has visibility into all of the AVP data that nodes are

exchanging, and that an orchestrator will require to dynamically manage more

complex value-added services.

As a result, as shown in Figure 4, Heavy Reading views a Phase 3 DSC emerging as

an invaluable node for providing real-time support to NFV network management

and orchestration. More specifically, we see a role for the DSC to simplify the man-

agement of decomposed applications to support "service chaining," which intro-

duces the requirement to manage the virtualized state machine in real time. This is

accomplished by utilizing the DSC as single holistic VNF-aware controller with the

capability to translate/interwork in a multi-vendor VNF environment.

Diameter SDN Orchestration Integration

SDN is not typically associated with Diameter signaling, since it was originally de-

signed to support interfacing of Layer 4-7 core, packet and billing nodes. In contrast,

SDN is focused on application of policy on the control plane of Layer 2-3 access

nodes, including routers, packet optical and Ethernet switches. And yet, in order to

ensure a holistic network security model, understanding and managing SDN and

NFV interactions is necessary.

Figure 4: DSC In-Path NFV Orchestration



Without such an approach, there is the potential to have malicious control plane

packets processed by virtualized DSC servers with adverse outcomes. To mitigate

this risk, there is a requirement to provide the SDN controller with real-time infor-

mation on how to forward service-critical control plane traffic.

Heavy Reading views this as uniquely new territory, since never before has the tele-

com industry experienced the simultaneous emergence of two foundational shifting

disruptive technology trends that are complementary. Normally, one disruptive

technology simply overpowers the other. As a result, ETSI and ONF recently an-

nounced that both bodies will collaborate to provide a layer-agnostic reference

architecture that will allow network operators to leverage SDN to support "auto-

mated, open and programmable network connectivity to support NFV."

Therefore, while still very early in the discussion phase, with many scenarios to be

considered, one scenario we consider plausible is to utilize an OpenFlow application

programming interface (API) to enable the EPC to access an OpenFlow SDN con-

troller, as depicted in Figure 5. In this case, the DSC acts as an intermediary between

the SDN controller and the NFV orchestrator to support layer-agnostic policy control.

To be clear, we are not proposing that the DSC perform the function of an SDN

controller, but rather that it is well equipped to support an intermediary function. For

example, as we have seen, a DSC supports the protocol Translation agent function.

While this capability was originally designed to support interworking with 2G and

legacy protocols, given that OpenFlow is a protocol, we see no reason a DSC could

not also interwork with modern and future protocols as part of its evolving Phase 3

mandate, if it supports the requisite levels of software modularity and extensibility.

Figure 5: NFV & SDN Interworking Scenario



Control Plane Orchestration Use Cases This section of the white paper provides two use cases examining the impact and

benefit of utilizing a DSC to facilitate control plane orchestration.

The first use case – Diameter to MAP interworking – presents a current DSC Phase 2

interworking and orchestration scenario; the second – Long Term Evolution (LTE) and

Wi-Fi service orchestration – addresses a use case that is applicable to a DSC Phase

3 virtualized environment.

Diameter to MAP Interworking

One of the ongoing challenges that operators currently face on the control plane

is interworking legacy and next-generation protocols. This need for interworking is

woven into almost every facet of service delivery, as operators strive to provide

seamless coverage across 3G, 4G and Wi-Fi access. And as we have seen, the DSC

via the translation agent can simplify this process.

For example, as illustrated in Figure 6, commercially available Phase 2 DSCs typically

support the interworking function (IWF), which is specifically designed to convert

and interwork Diameter and SS7 based GSM MAP signaling.

The addition of this capability means that network operators can ensure that LTE

roamers will have seamless coverage when they roam into other carrier networks

where LTE and IMS access are not supported, or within their own network that has

only "islands" of LTE coverage available. Similarly, this approach can also support

the roaming of 2G smartphone subscribers into 3G or 4G network.

DSC Role in Enabling Orchestration: In this use case, a DSC can play a valuable role

in enabling orchestration on several network levels.

Figure 6: DSC Evolution Phase 2 – Diameter to MAP Interworking



Proxy Function: In this scenario, the DSC utilizes session state to assist in the orches-

tration of value-added services. An example would be to temporarily suspend ac-

tive sessions until the identity of the user can be validated if the device and end-

user calling and data consumption patterns change drastically while roaming.

Translation Function: In addition to utilizing the IWF function for Diameter to GSM

MAP conversion, the DSC can assist in providing services execution for roamers

when the roaming network has deployed another vendor implementation that

utilizes optional parameters or IDs.

In this use case, the DSC can modify optional parameters and AVPs so that it can

enable the roaming network to send updates on which services have been in-

voked. In turn, this capability can be utilized in the OSS/BSS to modify billing AVPs

such as Accounting Session-ID and Credit Control Request, so that they meet the

requirements of the home billing network to support seamless charging and negate

the need for opex-heavy, billing-specific "workarounds."

This approach could be applied to both post-paid and (perhaps more importantly)

pre-paid subscribers, which require ongoing balance checks before application in-

vocation.

LTE & Wi-Fi Services Interworking

The continued ramp of LTE deployments is good news for mobile operators and sub-

scribers alike. Not only will LTE deliver a much-needed boost in mobile broadband

performance, it also puts in place a totally IP-based network framework to leverage

going forward.

However, the adoption curve of LTE is also slower than anticipated in some regions

due to several factors, ranging from regulatory readiness to market forces. For

example, Heavy Reading estimates that only 8 percent of Latin America subscribers

will utilize 4G technology in 2018. And in this market forces category, the impact of

Wi-Fi offload must be considered.

When carriers first deployed Wi-Fi it was often viewed as necessary to offload data

traffic from their 3G networks. However, over time, as Wi-Fi network performance

increased, mobile subscribers became increasingly loyal to the service, given the

low-price access model. The other concern for network operators is that Wi-Fi net-

works do not support traditional billing and data analytics models, which makes it

difficult to support customer loyalty and churn reduction initiatives.

In response to this, the industry with initiatives such as Hotspot 2.0 is moving to imple-

ment a model where Wi-Fi access can be integrated into a traditional network

model to ensure consistent billing and secure access, and to provide subscriber-

level personalization of services (e.g., special treatment for specific IMSIs when they

roam into Wi-Fi environments).

This approach is even more relevant in an NFV virtualization context because it em-

powers the use of a common policy control model regardless of underlying access

technology and supports the ability to evenly distribute where this policy is enforced

(RAN vs. hotspot) to minimize latency and maximize performance.

Accordingly, as illustrated in Figure 7, not only can a DSC be utilized to perform RA-

DIUS to Diameter interworking, which is necessary given Wi-Fi networks typically uti-

lize RADIUS for authentication and accounting, it can provide the NFV orchestrator


with the same level of billing and session state data to enable it to more efficiently

manage virtualized sessions.

DSC Role in Enabling Orchestration: As in the first use case, the Proxy and Translation

agent functions are the keys to enabling service orchestration. However, as deline-

ated below, the inherent flexibility of these functions means that they can also be

utilized to accommodate more complex outcomes.

For example, since Phase 2 DSCs can inspect and analyze the AVP information, they

have the ability to perform real-time comparison with data cached in external

sources to affect how message flows are processed. In this manner, they can ac-

cess external black lists or identify and provide additional capabilities to high-value

customers, or support targeted marketing campaigns to provide specific customers

with additional quota or roaming privileges based on subscriber profile data.

Proxy Function: A key challenge for NFV is managing the unlimited threshold of VNFs

that a network may deploy to meet demand. While in such a scenario, the NFV

orchestrator is key for managing these, the DSC also can provide important real-

time data related to authentication, authorization and accounting systems.

For example, the NFV orchestrator is not purely a billing node, so being able to apply

common billing policy based on subscriber IMSI is additional complexity that it may

Figure 7: DSC Evolution Phase 3 – LTE & Wi-Fi Services Interworking



not be able to support without a Phase 3 DSC that has intimate knowledge of all

billing and accounting practices. This includes linking Wi-Fi and 4G session service

usage for analytics purposes.

In the long term, Wi-Fi-specific AVPs could be developed to streamline two distinct

billing systems into one single, holistic system.

Translation Function: In this use case, in addition to simply translating RADIUS to Di-

ameter, the DSC can also be invaluable in enabling wider roaming capabilities by

translating between various interface-specific AVPs, as well as simplifying vendor

interoperating requirements for the NFV orchestrator.

However, unlike the previous use case, it is important to note that we believe mod-

ifying various vendor AVP implementations becomes a mandatory requirement in

a virtualized environment, since it is extremely unlikely that one single vendor will

develop all the VNFs and multi-tenant applications in the home network.


Conclusion The concept of the DSC has quickly moved beyond the earlier functionality of just

Diameter routing and security. It is now being seen not only as a platform to support

Diameter routing, mediation and security, but also as a means to interwork, orches-

trate and enhance other control plane signaling messages, such as RADIUS and SS7.

This is required due to the need to provide seamless coverage across existing and

new technology investments and take advantage of multiple access methodologies,

such as Wi-Fi. But it is also borne out of a desire by service providers to accelerate

services to market and provide more personalized connectivity to their customers.

When SDN and NFV burst onto the scene less than two years ago, it was unclear

what the impact would be on both network operators and vendors. Since then, a

wave of specification development has helped to create a clearer view of both

from a reference architecture perspective.

One of the most notable takeaways from these activities is that SDN and NFV have

in a very short period systematically redefined the role of the control plane. The most

visible characteristic, as we have documented, is the shift from a traditional session

set-up and tear-down model to a more intelligent model, which provides the foun-

dation for support of virtualized Phase 3 orchestration use cases.

Although it will take time to fully define and commercialize a fully service orches-

trated control plane, it is readily apparent that service providers won't be able to

take advantage of the full benefits of a signaling orchestration environment with

traditional Diameter routers. The new breed of Phase 2 and Phase 3 DSCs currently

coming to market are strategically and technically in a very strong position to sup-

port the new attributes required to usher in a new era of service innovation.


Background to This Paper This Heavy Reading white paper was commissioned by Dialogic, but is based on

independent research. The research and opinions expressed in this report are those

of Heavy Reading.

About the Author

Jim Hodges

Senior Analyst – Service Enabling Architecture and Software, Heavy Reading

Jim has worked in telecommunications for more than 20 years, with experience in

both marketing and technology roles. His primary areas of research coverage at

Heavy Reading include the media- and control-plane impact of NFV and SDN on

core and edge network components such as the IP Multimedia Subsystem (IMS),

session border controllers (SBCs) and Diameter Signaling Controllers (DSCs). Jim is

also focused on the impact of NFV and SDN on data center evolution, including the

role of application delivery controllers (ADCs), as well as managed services evolu-

tion, subscriber data management (SDM) and fixed-line TDM replacement.

Jim joined Heavy Reading from Nortel Networks, where he tracked the VoIP and

application server market landscape, as well as working on the development of

Wireless Intelligent Network (WIN) standards. Additional industry experience was

gained with Bell Canada, where he performed IN and SS7 network planning, num-

bering administration and definition of regulatory-based interconnection models.

Jim is based in Ottawa and can be reached at [email protected].

mailto:[email protected]

hr diameter control plane orchestration wp

Documents