C h a r t i n g t h e f u t u r e o f i n n o v a t i o n v o l u m e 9 2 | 2 0 1 5 — 0 1 xxxx ✱
Review
Ericsson
Technology
TECHNOLOGY TRENDS
the latest in ICT
from the cto
WI-FI CALLING
EXTENDING VOICE
AND VIDEO
OVER LTE
#01, 2015
✱
Ericsson technology review
RADIO ACCESS AND
TRANSPORT networks
SHARe INFORMATION
1
✱ xxxxx
2
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
xxxx ✱
#01, 2015
✱
Ericsson technology review
3
contents ✱
Radio access and transport
network interaction — a concept
for improving QoE and resource
utilization
By adopting a holistic
approach to network architecture, one that
enables the radio and transport domains to
share information, proactive measures to
avoid congestion can be put into place, to
increase the number of users at or above the
desired QoE level.
OpenStack as the API framework
for NFV: the benefits, and the
extensions needed
08
(Originally published on July 3, 2015.)
Design, architects, and complex
communication systems:
painting the bigger picture
Modern communication systems are complex, and
not just at the system level. Today’s systems are
designed collaboratively, taking the viewpoints of many
stakeholders into consideration, and so
complexity also arises at the
organizational level. Good
systems design has become
a significant factor for cost
control.
Network Functions Virtualization (NFV) offers a
flexible and scalable way to deliver and deploy
Virtual Network Functions (VNF) services. Use of
virtualization and cloud computing is becoming
increasing popular as these techniques can
dramatically reduce time-to-market. However, the
transformation to VNF services and deployment
scenarios needs an API framework – and OpenStack is a suitable candidate. But is it enough, and what
improvements are needed?
(Originally published on April 2, 2015.)
Setting the future media
services architecture
Many industries are undergoing
transformation, moving away from
physical products and communication
to virtual products and massive
digitalization. The benefits of an ICT
transformation that takes advantage of
commercially available IT systems, networking
equipment, and cloud-based
services are many. The media
industry in particular stands
to benefit greatly. As we
move deeper into the
Networked Society,
media production and
consumption will take
on a more prominent
role in shaping
requirements related
to network design and
performance.
(Originally published on
February 24, 2015.)
44
(Originally published on
May 13, 2015.)
Gearing up
support
systems for
software
defined and
virtualized
networks
18
52
The global communication
infrastructure has created a new
market of digital services in which people
and organizations can expose digital assets,
which can be rapidly combined with partner
assets to create new, more useful, and more
interesting services. But, to capture the
digital market opportunity, both telecom
networks and support systems – OSS/BSS –
need to gear up.
(Originally published on June 5, 2015.)
Wi-Fi calling — extending the
reach of VoLTE to Wi-Fi
32
Technology trends
When it comes to technology,
relentless and continuous
development remains a
constant expectation.
Within this context, certain
significant shifts and
opportunities — or technology
trends — have a tendency to
stick out.
#01, 2015
✱
Ericsson technology review
Other devices
Using untrusted Wi-Fi to carry voice and video
communication is an opportunity to extend current
voice and video calling over lte (volte/
vilte) services in, for example,
indoor locations where cellular
coverage may be spotty.
Closely aligned with volte
architecture, Wi-Fi calling
supports mobility between
lte and Wi-Fi accesses.
(Originally published on
January 30, 2015.)
Mobile phones
Wireline devices
29
62
5
E r i css o n
Technology
Review
Bringing you insight into
some of the key emerging innovations
that are shaping the future of
information and communications
technology. Our aim is to encourage
an open discussion on the potential,
practicalities and benefits of a
wide range of technical developments,
and help provide an insight into what
the future has to offer.
ADDRE S S
Ericsson
SE-164 83 Stockholm, Sweden
Phone: +46 8 719 00 00
PUBLI S HING
All material and articles are published
on the Ericsson Technology Review
website: www.ericsson.com/ericssontechnology-review.
Additionally, articles are
available through the Ericsson
Technology Insights app,
which is available for Android and iOS
devices. The download links
are also available on the Ericsson
Technology Review website.
PUBLI S HER
Ulf Ewaldsson
EDITOR
Deirdre P. Doyle
[email protected]
TE C HNOLOGY
TREND S
Kristina Gold (Ericsson)
ART DIRE C TOR
Kajsa Dahlberg (Sitrus)
TE C HNI C AL
ILLU S TRATION S
Claes-Göran Andersson
[email protected]
ISSN:
0014-0171
Volume: 92, 2015
6
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
editorial ✱
embracing relentless
change in ict
First, I welcome you to the new Ericsson Technology
Review. For some months now, we have been
working on how to continue to deliver our in-depth
technical insights this journal is renowned for, but also
how to offer a broader perspective on technology
developments in ict. So here it is...
I am delighted to be able to share some of my
thoughts and the stories of Ericsson experts – their
perspectives, concerns, and insights on advancements
being made in technology.
Perhaps the most obvious change we’ve made
is the name of the journal. As industries merge,
overlap, and collaborate more, we find ourselves
changing too. I daresay the situation is the same
everywhere. Today, Ericsson’s experts have
different sets of skills compared with just a few
years ago. Our customers also have different
problems: subscribers are more demanding,
and technology is more complex as it
weaves its way deeper into the fabric
of our lives. Some of the people I
have conversations with today
work in businesses that didn’t
exist, even a couple of years ago.
So, in an attempt to clarify what
this journal is about (reviewing
technology), we added the word
technology to its name.
To our long-standing readers, I would
like to emphasize that the fundamental
nature of our content — in-depth analyses
of specific technologies, their consequences and
benefits — hasn’t changed.
The biggest change comes in the form of a new
technology trends section. As the cto of a global ict
player, I am in the fortunate position of hearing about
all kinds of innovations that are shaping our industry,
and I get to hear them from the multiple perspectives
of many different experts. And while technology
development often follows an innumerable set of
investigation paths, some of them tend to stick out.
So, together with a couple of Ericsson experts, I have
highlighted the five trends that I believe all of us in ict
should keep an eye on in the coming year. I'd say that
virtualization, network slices, more data, more mobile,
security, and billions
of things are today's
primary drivers in ict.
Otherwise, it’s
business as usual...
Every month, we
publish a new article
online. Perhaps not
surprisingly, 5g
is on the agenda,
including a vision for
the core network,
how transport networks will need to evolve, and
how 5g will enable remote control. We’ll round off
the year with some insights into cryptography and
designing secure algorithms.
You can access all of our content on the new
Ericsson Technology Review home page, download
the articles to your mobile device through our Ericsson
Technology Insights app, or read them on SlideShare.
90% of the
world’s population
over 6 years old
will have a mobile
phone by 2020*
All links can be found on our new website at: www.
ericsson.com/ericsson-technology-review.
Ulf Ewaldsson
Senior Vice President,
Group CTO, and head
of group function
technology
* Ericsson Mobility Report, 2015
#01, 2015
✱
Ericsson technology review
7
✱ Better customer experience
Radio access and
transport network
interaction
a concept for improving QoE
and resource utilization
In today’s networks, radio access and transport are largely unaware of each
other, but are inherently related, as impaired conditions in either domain
can adversely affect user experience. As QoE has a significant impact on
customer satisfaction and customer retention1, potential improvements in
user experience are of key business interest.
〉〉 S tefan Dah lfo rt
Shah ryar Khan
J o nas Rosen b erg
Anto n Sm ith
Sh uo Yan g
Mats Fo rsman
an d To mas Thyn i
8
t o i m p r o v e o v e r a l l QoE, a holistic
approach to network architecture is vital —
one that takes into consideration conditions
in both radio and transport domains, and that
results in the ­creation of proactive measures
for preventing congestion.
The concept of ran transport interaction (rti)
introduces coordination between the radio and
transport domains, and aims to provide the holistic
approach needed to improve QoE. In this article, the
principles and benefits of this concept are described,
as is the high-level set of building blocks for the
rti solution, and the whole is exemplified with a
few selected use cases. In some way, rti can be
viewed as an example of cross-domain interaction2.
Specifically, this article addresses the radio access
and transport components of the overall network.
Why the call for new technology?
The increasing global dependence on mobilenetworking services is causing congestion in
networks. The rate of uptake of mobile broadband,
for example, is set to rise significantly: in 2014, total
global subscriptions topped 7 billion, which are set
to rise to 9.2 billion by 20203. And so, congestion
issues will continue to be among the more significant
factors that impact user satisfaction.
While rapid developments in technology and
community foundations, such as exploitation of new
frequencies and concepts for energy conservation,
are shaping next generation networks4, perhaps
the most significant change factor today is how
society and individuals are using mobile-broadband
services. The current demand for such services and
capacity is on an upward curve that shows no signs of
leveling off.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Better customer experience ✱
As networking services like mobile broadband
rely on the entire network — including radio access,
the transport network, data centers and the global
internet — to ensure excellent QoE, applying a
holistic approach to network architecture is crucial.
As more information becomes available, related
to say location, magnitude, origin, and duration
of traffic, the easier it becomes to mitigate QoE
impairment. However, as radio and transport
domains do not share much information, they are
largely unaware of each other.
Consequently, an impairment in one domain may
go unnoticed by the other, making it difficult — or
even impossible — to optimize resource usage and
take the necessary actions to avoid the congestion.
The term impairment is used to indicate any
source of QoE degradation related to, for example,
traffic congestion, which results in packet delay,
delay variations or dropped packets. Typically,
sources of degradation tend to be interdependent
and are often an indication that network resources
are overutilized.
For example, traffic congestion may occur in the
transport network at certain times and locations,
and for given types of traffic. The radio access and/
or the transport domain could try to mitigate such
congestion but the lack of information sharing
between them makes this task complex, and in some
cases impossible to solve.
Not a one-to-one relationship
The transport network carries traffic to and from
different types of radio domain and user. Typically,
the transport network maps this traffic to the
relatively small number of QoS classes used by
transport network operators.
As a result, the transport network lacks the
necessary granularity to differentiate traffic, leading
to suboptimal network utilization, which has an
impact on QoE.
Encryption complications
To improve its understanding of the traffic
situation, the transport domain can use deep packet
inspection (dpi) to get more information about
granular flows at router ingress ports. For example,
the tunnel endpoint identifier (tied) included in
the gprs Tunneling Protocol (gtp)5 can be used to
encapsulate various QoS bearers. However, for this
to be useful, the transport network domain needs to
know what type of traffic is addressed by the specific
tied. Unfortunately, when encryption like ipsec6
is applied — an approach that is widely deployed in
lte networks — the tied cannot be read using dpi.
Inadequate measurements
Another possible way to improve the overall
understanding of traffic is for the radio domain
to access the transport domain’s performance
characteristics. This can be achieved through
passive or active metrics, which can be accessed
through, for example, application of the two-way
active measurement protocol (twamp)7.
However, metric-based methods may be too slow
to react to traffic impairments that are highly time
dependent. In addition, while measurement-based
approaches are useful for providing end-to-end
characteristics, they fall short of providing the
information needed to pinpoint congestion.
The measurement approach is consequently
inadequate for proactive network optimization,
and is further inhibited by the fact that the radio
Terms and abbreviations
be: best effort | dpi: deep packet inspection | ecmp—equal cost multipath | gtp—gprs Tunneling Protocol |
hqos—hierarchical QoS | lag—link aggregation group | mme—Mobility Management Entity | mpls—multi-protocol
label switching | pcrf—policy and charging rules function | qoe—quality of experience | ran—radio-access
network | rat—radio-access technology | rnc—radio network controller | rti—ran transport interaction | sdnc—
software-defined networking controller | s/pgw—pdn gateway | teid—tunnel endpoint identifier |
ue—user equipment
#01, 2015
✱
Ericsson technology review
9
✱ Better customer experience
Transport-unaware radio
RAN-unaware transport
Transport-aware
RAN
RAN-aware transport
RAN
Transport
Transport path load
and capacity
Granular RAN
traffic treatment
Better utilization of
available diverse paths
Optimal distribution of
RAN flows to help avoid
congestion in transport
Am I aware of congestion in
the transport path?
=> QoE impact
Reduction in network
state and energy waste
Am I aware of granular
RAN flows?
=> non-optimized transport paths
Figure 1 rti problem (left)
and opportunity
(right) formulations
1
Proactive
congestion
avoidance
Redistribute
Reroute
2
Congestion
handling
Fairness
(if congestion
avoidance fails)
Holistic network configuration
RAN
Transport
Figure 2
rti: a phased approach
to congestion mitigation
10
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Better customer experience ✱
domain is agnostic of the transport domain’s
capability to self-optimize — and so attempts to solve
a congestion issue (based on observed conditions)
may be futile if the problem has already been
addressed by transport.
Connecting radio and transport
Given the limitations of existing technology, devising
explicit interaction between the two — radio and
transport — domains is a more appropriate method
that offers significant advantages.
A number of models can be used to create the
connection between radio and transport, such
as a peer-to-peer or client-server model (with or
without hierarchies). The solution described in
this article uses an information-sharing model that
boasts one significant feature: each domain controls
the information that it shares with the other, and
dictates exactly where that information may be
used. Significantly, the decision to share or request
information never results in a feedback loop, as
explicit information sharing reduces or removes the
occurrences of failure to mitigate against certain
impairment conditions. The rti problem and
opportunity formulation is summarized in Figure 1.
The described approach
Solving congestion, as illustrated in Figure 2, is a
two-step process, which first aims to proactively
avoid congestion scenarios, and then to
handle any unavoidable congestion.
Proactively minimizing congestion can be
achieved by optimizing the use of available
resources in both the transport and radioaccess domains. Optimization in turn uses two
methods: redistribution and rerouting. In the case
of redistribution, the radio domain moves traffic
around (when possible), effectively load-balancing
in an optimal way across the backhaul transport
network. In the case of rerouting, the transport
network uses a number of techniques, like sdnbased traffic engineering, to make better use of
available alternate paths.
Mechanisms can be applied to relieve relative
starvation among the various radio-access
technologies (rats). For example, by applying a
#01, 2015
✱
Ericsson technology review
fairness mechanism, the transport network can
use information received from the radio network to
prevent starvation between different radio accesses
during congestion conditions.
Use cases and benefits
Example use case 1:
proactive congestion avoidance
As the number of connected mobile devices and
bandwidth consumption per user rises, the risk of
introducing temporary congestions in the transport
network increases accordingly. But in many cases,
congestion occurrences are temporary, and so
average bandwidth utilization in the transport
network tends to be moderate.
The best solution for cases where s­ izable
QoE degradations occur is to either mitigate or
circumvent congestion. This first example use case
— proactive congestion avoidance — addresses how
information provided by transport helps the radioaccess domain to make handover decisions that are
more holistic in nature.
To maintain connectivity between the ran and
a ue, traditional handover decisions are made on
the basis of radio signal quality, which is assessed
continuously. Handover to another cell is triggered
when radio conditions become more advantageous
in a neighboring cell. However, the level of transport
congestion in each cell is not part of the handover
decision-making process.
To increase availability, and to be able to
propagate traffic over multiple paths, mobile
transport includes a degree of redundancy in the
metro aggregation network — typically in terms
of different ring or necklace topologies that use
protection schemas and link aggregation groups
(lags). However, closer to the radio access,
transport networks tend to be built in a nonredundant tree shape and do not offer path diversity.
Congestion often occurs in the access aggregation
part of the network (see Figure 3), but may also arise
in the metro portion, where mobile traffic merges
with fixed residential and business traffic. Hop-byhop path characteristic measurements performed
in the transport network can be shared, providing
the radio access with knowledge about transport
11
✱ Better customer experience
CSR
CSR
RBS
CSR
CSR
Agg
CSR
20 GE
No congestion
CSR
CSR
Agg
RBS
RBS
PE
RNC
Agg
PE
xGW
Agg
10 GE
Congested link
Agg
10 GE
20 GE
Agg
CSR
CSR
LAG
RBS
CSR
CSR
Agg
CSR
CSR
Figure 3 Example use case: proactive congestion
avoidance
12
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Better customer experience ✱
CSR
CSR
RBS
CSR
CSR
Agg
CSR
High load
20 GE
High load
CSR
CSR
Agg
Agg
Agg
PE
RNC
Agg
PE
xGW
Low load
Low load
RBS
10 GE
10 GE Low load
20 GE
Agg
CSR
CSR
LAG
RBS
CSR
CSR
Agg
CSR
Figure 4 Example use
case: optimized load
balancing
CSR
BE flows
RAN flows
HQoS
threshold
BE flows
RAN flows
Access network
Agg
#01, 2015
✱
Ericsson technology review
Figure 5 Example use case:
fairness
13
✱ Better customer experience
congestion. This congestion information can be used
to enhance the handover procedure.
To avoid handover to a neighboring cell where the
radio access is connected to a congested transport
path, information about transport topology is
needed. This information enables handover to
neighboring cells that are connected to uncongested
transport paths.
The probability of a neighboring cell being
connected to an uncongested transport path
correlates to the system gain for proactive
congestion avoidance. The level of system gain
attainable is highly dependent on how the network is
built, in terms of cell density, transport topology and
technology. Urban areas, for example, tend to exhibit
high numbers of cells within reach of a ue. As a
result, the potential for improved system gain is high
in situations where the cells have diverse transport
paths.
Holistic handover decisions are thus formed
on the basis of transport congestion together
with the typical signal strength and neighboring
cell information — all of which are weighted.
By including transport utilization information,
more informed handover decisions can be made,
which together with an abstraction of the relevant
transport topology enables a cell to find a suitable
neighboring cell to handover to.
The benefits of rti for this use case can be
summarized as: by using congestion information
from the transport domain, the radio domain can
place user traffic optimally across radio cells, from
a combined point of view of radio and transport
characteristics. Figure 3 illustrates an example of
this proactive congestion avoidance, where the
second mile link is the congested part.
On a high level, the benefit for this use case relates
to the number of additional users or traffic for which
the QoE requirements can be met in relation to the
available radio resources (such as spectrum and
radio equipment). In this case, rti can be used to
handover traffic generated by users in a cell with
congested transport to another cell within the
coverage area that has uncongested transport. As
traffic is moved away from the congested cell, rti
has a positive impact on users that remain connected
to the original cell — users that cannot be handed
over to an uncongested cell because they are not
within coverage area, or cannot be handed over for
other reasons. This positive impact results from the
load drop in the original congested cell as proactive
handover actions are taken.
The potential gain for rti can be measured by the
increase in users at or above the desired QoE level
compared with a network without rti.
Naturally, actually calculating the gain depends
on the specific network case and needs to consider
factors such as the utilization of congested/noncongested transport and cells, user bandwidth and
priority, and difference in radio quality.
References
1. Ericsson, 2012, Why Superior Network Performance Matters, available at:
http://www.ericsson.com/news/120917_why_superior_network_performance_matters_244159018_c
2. Ericsson, 2014, Ericsson Review, Architecture evolution for automation and network programmability,
available at: http://www.ericsson.com/news/141128-er-architecture-evolution_244099435_c
3. Ericsson, June 2015, Mobility Report, available at: http://www.ericsson.com/mobility-report
4. Ericsson, 2015, Anticipating Opportunities with 5G, available at:
http://www.ericsson.com/news/150305-anticipating-opportunities-with-5g_244069647_c
5. 3gpp, ts 29.060, gprs Tunnelling Protocol (gtp) across the Gn and Gp interface, available at:
http://www.3gpp.org/DynaReport/29060.htm
6. ietf, 2005, RFC 4301 Security Architecture for the Internet Protocol, available at:
https://tools.ietf.org/html/rfc4301
7. ietf, 2008, RFC 5357, A Two-Way Active Measurement Protocol (twamp), available at:
https://tools.ietf.org/html/rfc5357
14
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Better customer experience ✱
Example use case 2:
optimized load-balancing
This use case addresses transport, and how it
can make better use of available resources by
obtaining relevant information from radio. As
mentioned, the transport domain lacks granularity,
and so the proposed solution is to announce traffic
information to the transport network in such a
way that existing standardized implementations
of the gtp or ipsec protocols require no change.
The additional information allows the transport
network to optimally load-balance traffic over equal
cost multipaths (ecmps) or a lag. In addition, the
proposed solution will work equally well for traffic
that is encrypted as for non-encrypted traffic.
The rti gain for the second use case is built on
the assumption that load balancing traffic in an
optimized fashion results in an overall improvement
of QoE and better utilization of transport resources,
see Figure 4.
Example use case 3: fairness
Today, transport networks cannot distinguish
between best-effort (be) traffic originating from
different radio access types. The radio-access
domain has more granular QoS profiles, but
mapping them onto the transport domain will
significantly increase the complexity of the QoS
solution for the transport network operator.
The result: be-marked traffic will experience
the same, shared per-hop behavior for all access
technologies, which may cause starvation of one
or several rats. By instead exchanging traffic
information and bandwidth ratios, the transport
network can prevent un-fairness by rate-limiting
selected traffic types. An example of this approach
for fairness is illustrated in Figure 5, which shows
a traditional method that will exhibit unfairness,
and an enhanced rti method that ensures fairness.
rti benefit and rti gains for this use case can be
formulated in the same way as for the previous
cases.
The building blocks
Based on the example use cases, Figure 6 illustrates
the building blocks of the rti solution. The main
#01, 2015
✱
Ericsson technology review
building blocks are generic to communication
systems and include radio access, transport and the
packet core.
Radio access
This part of the system includes multi-standard
mobile broadband systems — such as 2g/edge, 3g/
wcdma, and 4g/lte (with5g coming in the future)
— together with their controller functions like rnc
and bcs.
Transport
This part of the system includes routers and
switches (such as ip/mpls and l2) and physical
layer components (such as microwave and
optical transport) together with their respective
optional controller components. Specifically for
the transport domain, such an optional controller
component is illustrated in Figure 6 by the sdn
controller (sdnc).
Packet core
This part of the system includes connectivity and
routing/forwarding gateways (s/pgw), multimedia
control nodes (such as mmes) as well as policy
entities (such as the pcrf). As the packet core
contains relatively few elements compared with
radio access, scalability benefits can be gained
by sharing information between the transport
controller and the packet core.
Specifically, rti-application functions are
included in radio-access, transport and, optionally,
the packet-core networks in order to:
1. gather the information related to its domain;
2. handle the information flow between the transport and
radio domains; and
3. make intelligent decisions based on the shared
information.
The rti application consists of distributed rti
entities corresponding to the radio access, transport
and core networks, and offers the following benefits:
〉〉maximized flexibility and scalability; and
〉〉utilization of future technologies, such as advanced
analytics, self-organizing functions, and 5G mobile
broadband.
15
✱ Better customer experience
M
M
M
Domain
mgmt
OSS
BSS
OSS/BSS
RTI
entity
3GPP
3GPP
BSC/
RNC
xGW
RTI domain - radio
MME/S
GSN
PCRF
RTI domain - packet core
Traffic entry point
Optical
uWave
SDNc
Router
RTI domain - transport
Figure 6
RTI building blocks
Summary and conclusions
This article outlines the background, motivation,
example use cases and building blocks of rti — a
new concept for sharing information between radio
and transport domains to optimize QoE.
By illustrating the concept through selected
example use cases, the gain becomes clear. Proactive
congestion avoidance, for example, enables the radio
domain to make more intelligent handover decisions,
as it includes congestion information provided
by the transport domain in the decision-making
process. The result: improved QoE with the existing
set of available radio access and transport network
resources.
The other use cases — load balancing and fairness
— illustrate how the information from the radio
16
domain facilitates better utilization of available
transport resources. In the case of optimized loadbalancing, more finely grained information provided
by the radio domain enables the transport domain
to optimally redistribute traffic, and thereby ensure
better utilization of the network. In the case of
fairness, the information from the radio domain is
used to allocate bandwidth in ip routers for mobile
traffic carried by different generations fairly. For
each use case, an outline of the rti benefit
principles has been provided.
In summary, rti is an innovative concept that
enables a significant improvement in QoE for mobile
users in the context of the example use cases. In
addition, rti enables more optimal utilization of
network resources.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
the authors
Better customer experience ✱
Stefan Dahlfort
◆ Has a background
with incumbent telecom
operators and large telecom
vendors. He founded a startup before joining Ericsson
on strategic technologies
for orchestration and
assurance solutions in
mobile transport networks.
He holds an M.Sc. in
electrical engineering
from kth Royal Institute of
Technology in Stockholm.
Mats Forsman
◆ Joined Ericsson in 1999
to work with intelligent
product line. He has over
12 years’ of experience in
the IP vendor and service
provider industry, including
architecture, design and
operation of production
ip/mpls networks for
mobile backhaul and triple
play services at multiple
operators. He holds a
Bachelor of Information
Science from Massey
University, New Zealand.
Shuo Yang
◆ In 2007 as manager
for fttx research. He led
Ericsson’s research in the
area of broadband access
and transport in Silicon
Valley 2010-13, and since
then, he has been head
of Development Unit ip,
Systems and Technology.
He holds an M.Sc. and a
Ph.D. in optical networking
from kth Royal Institute of
Technology in Stockholm.
Jonas Rosenberg
networks. Since then
he has worked within
the IP, broadband and
optical networks areas.
Today, his focus is on new
concepts for transport
within ran at Ericsson
Radio; one such concept
area is ran and transport
interaction. He holds an
M.Sc. in mathematics and
natural science from Umeå
University, Sweden.
Anton Smith
◆ Is a senior product
manager for Ericsson’s
metro and backhaul
◆ Joined Ericsson in 2000
and is currently systems
and solution manager
at Development Unit ip,
Systems and Technology.
He is a senior specialist
in network architecture
and solutions with a focus
#01, 2015
✱
Ericsson technology review
◆ Joined Ericsson in 2009
and is currently a senior
system design engineer
at Development Unit IP,
Systems and Technology. He
holds an M.Sc. in electrical
engineering from Harbin
Institute of Technology,
China.
Prior to joining Ericsson,
he accumulated 15 years
of experience as an IP and
transport network designer
at various network
operators.
Shahryar Khan
◆ Has nearly two
decades of experience in
architecture design and
integration for multiservice
IP and transport networks
for telecom operators
and large enterprises.
He has managed diverse
roles within Ericsson,
and he recently worked
as a principal solution
architect for IP and SDN
in Engagement Practices
Tomas Thyni
◆ Is an expert in the area of
IP and transport networks.
A telecommunication
and network engineer, he
joined Ericsson in 2000
and has worked within the
IP, broadband and optical
networks areas. Today, he
works on new concepts
for transport in ran at
Ericsson Radio; one such
concept area is ran and
transport interaction.
for tier-1 customers. At
present, he is working
as an expert and chief
architect in multiservice
ip and transport networks
in Development Unit ip,
Systems and Technology
(Sweden).
17
✱ Illustrative architecture
Design, architects, and
complex communication
systems: Painting the
bigger
picture
〉〉 Ulf Olsson
Toni SiljamÄki
Francis Bordeleau
The task of building, maintaining and developing communication systems
is complex. The level of complexity rises as the number of stakeholders
involved in creating these systems increases.
As a result, vendors, system integrators, operators — and increasingly
their business partners — need to communicate more. And so, besides
understanding how their own systems work, modern designers and business
developers need to grasp how other stakeholder systems work, and to have
an appreciation of the various possible approaches to architecture design.
18
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Illustrative architecture ✱
The ability to grasp complex structures can be
greatly facilitated by using visualization tools.
A common illustration approach enables
modern system architects to share design
concepts. Support tools that help designers
to maintain, communicate and discuss
structures are a fundamental part of modern
systems architecture. This article presents
Ericsson’s methodology for developing such
support tools.
Designing the best system
e x p e r t s w h o build and maintain very
large systems are continuously looking for ways to
increase productivity and improve quality. Raising
the level of abstraction involved in system design
is one way of doing this. It releases designers (and
others) from the need to keep track of an everincreasing number of details and dependencies — a
number that rises exponentially with system size and
complexity, product range and stakeholder count.
Model-based engineering has been used
successfully for many years to achieve the best
combination of compute power and design
knowledge. To capture the structure of a system, this
methodology uses a logical model of aggregation
and dependencies — which are visualized in a
graphical format. In this way, proposed models can
be validated and modified easily.
Owing to the complexity of modern
communication networks, systems architecture
is often split into various domains, each with an
assigned group of architects. In addition to designing
and modeling their respective domains, these
architects are responsible for ensuring that all of
their peers have a common understanding of the
domain interfaces and functional allocations.
Model-based engineering offers the level of
person-to-person information transfer needed to
design large, modern, complex systems efficiently.
However, designing modern systems requires a
toolset: one that is capable of being adapted to a wide
range of constantly evolving demands, posed by
many different stakeholders — including producers,
systems maintainers, and the actual users of the
designs.
The wanted output is a complete, coherent,
consistent and revisable network description — one
that enables the network to evolve in a controlled
manner, address new challenges, and absorb new
technologies.
But to create the best system, facilitating a mutual
understanding among architects is only one key
ingredient. Architects also need a set of companion
tools — tools that can, for example, help them to
validate proposed models, analyze the potential
impact of suggested changes, detect inconsistencies,
and ease the implementation process.
Support tools for software and hardware design
have existed for decades, but, unfortunately, they
do not address how to bridge the gap between the
abstract representations used by designers to model
the real world, and detailed ones, where every aspect
of a process or a s­ tructure must be described in full to
enable automation.
In the context of network programmability,
the ability to bridge this gap becomes even more
significant. Identifying the capabilities that can
be invoked, and determining how to control them
from outside the network proper, becomes more
challenging as the level of automation rises.
The approach we took to develop the Ericsson
toolset demonstrates how open-source technology
Terms and abbreviations
css—Cascading Style Sheets | dsl—domain-specific language | dsml—domain-specific modeling language |
egit—Git with Eclipse | emf—Eclipse Modeling Framework | Git—open source control model | gmf—Graphical
Modeling Framework | nwa dsl—network architecture dsl | ocl—Object Constraint Language |
PaaS—platform as a service | svg—Scalable Vector Graphics | sysml—Systems Modeling Language | ui—user
interface | uml—Unified Modeling Language | Xtext—framework for developing programming languages
#01, 2015
✱
Ericsson technology review
19
✱ Illustrative architecture
M
OSS/
BSS
S1
RAN
Gi
ISC
IMS
core
EPC
MTAS
Figure 1
Top-level network diagram
HSS
Cx
Function - IMS core
S/ICSCF
P-CSCF
Mb
ISC
Mw
Gm
IMS
client
MTAS
Iq
Mr
Mb
AGw
MRF
Figure 2
Exploring a function
20
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Illustrative architecture✱
enables developments in modeling technology to be
added as they become available. Collaboration —
within the telecom industry, and with other industries
faced with similar system design challenges — has
been crucial factor in developing a toolset that can
serve modern multi-stakeholder environments.
Primary use case:
modeling network architectures
But what is network architecture? One definition
might be: the sum of all the components needed
for operators to produce their services. Such a
definition includes a number of aspects: functional
descriptions, implementation components,
products, topological architecture, as well as
business and responsibility relationships.
Functional descriptions
A system comprises a set of logical functions and
how they interrelate through logical interfaces.
Deconstructing a system into its various elements
facilitates an understanding of how the system
works. Modern models use recursion to simplify
systems into network elements and component
parts to a point where a person with some system
knowledge understands them.
Ideally, architecture design should be decoupled
from implementation. In practice, variants of a
system tend to exist to address the needs of different
deployment contexts. Systems can, for example, be
provided on a dedicated platform, through a cloud
infrastructure, or using PaaS. In a sense, the high
level architecture is the variant that is still valid after
a system has been significantly re-implemented (for
instance, after a change of platform technology).
Implementation components
Logical functions are a great way to explain what
a system does, and to some degree how it does it.
However, to deliver actual products, implementation
components that correspond to logical functions
are needed. Implementation components can be
combined and reused to produce the behavior
described by the logical functions. Sometimes, a
direct correlation exists between logical functions
and implementation components, but this
#01, 2015
✱
Ericsson technology review
relationship is typically
bridging the gap
many-to-many.
A logical function
between the abstract
can be executed by
several implementation representations of the
components, although
real world, and details
reusability goals suggest
to enable automation
that this should only be
the case when certain
constraints, such as choice
of execution environment, create a need for several
implementations. An implementation component
can be responsible for implementing several logical
functions, and again, sound design principles
suggest that this should be the case only when
functions are tightly coupled.
Products
Products are aggregates of hardware and/or
software components. Extending the model
from logical functions through implementation
components links the logical architecture — which
does not change if the functional requirements are
stable — to product life cycle management (including
market adaptations), with its processes and tools. In
a virtualized environment, products will, to a large
degree, be implemented as prepackaged virtual
machines (or increasingly using the container
concept, as exemplified by Docker containers1),
although optimized hardware and software
components used in high-performance elements of a
radio base station, for example, will continue to play
a significant role in designing the best system.
Topological architecture
In telecoms, system topology — the ability to
understand where functionality is best deployed
— is vital for creating the best system. Telecoms is
essentially motivated by the need to connect devices
separated by distance. Mobile networks need to
connect devices as they move about, and so systems
need to be designed to cope with a range of traffic
patterns. As a result, topology becomes highly
relevant, especially when design parameters include
latency, resilience, interconnect points, compute
power or cost.
21
✱ Illustrative architecture
For virtualized scenarios, the location of a
software component is not set at deployment time,
but is instead a dynamic parameter determined
by the operational system. Determining location
is a complex cloud-management process, one that
requires rapid system response and a high degree
of automation. Modeling such system processes is
essential to ensure realistic automation. For example,
to meet low latency requirements, some network
components may need to be deployed close to each
other, while redundancy requirements may dictate
that certain network components be kept apart.
Responsibility relationships
Systems need to be described in terms of the
functionality each business entity (operator, partner,
platform provider, device manufacturer, content
provider or user) is responsible for. Such division
of responsibilities is not necessarily limited to the
relationships between separate legal entities, but
can also be applied to units within the same legal
entity or company. Key resources like access and
core networks, computing infrastructure and
databases must be protected. At the same time, the
pace of business requires that new services can be
developed and launched without having to wait for
traditional system integration to be completed or
for the massive amount of testing to be concluded.
Network architecture modeling plays a key role
in identifying the key interconnection points,
highlighting the interfaces that can be defined and
thus protected as exposable services.
Business relationships
The business relationship includes how workflows
and commercial processes are described, how
they touch, and how they help to define the logical
functions in the system.
All aspects, from functional descriptions to business
relationships, are linked. The complex job of
establishing and maintaining these links is a critical
factor behind the need for formal modeling and
abstraction capabilities.
Perhaps the most important benefit of a formal
model behind the graphical representation of a
22
system is that it allows the architecture to evolve in
a controlled way. The ability to analyze a model for
completeness and consistency, and the capability to
carry out impact analysis on proposed changes, are
key factors in the need for model-based engineering.
Graphical representation
of the system
Figure 1 shows a typical network architecture
illustration. It conveys the main purpose of a system
through a set of interconnected logical functions.
Each function is portrayed as an icon, which conveys
the function’s primary purpose. Color-coding helps
to support the association of functions to network
areas, but color is also used to shift the viewer’s focus
to specific parts of the system. The elements shown
in Figure 1 are examples of network areas — main
groupings of functionality.
Besides functional elements, connections
are a significant feature of n
­ etwork-architecture
diagrams, as they illustrate the direct relationships
between functional elements.
Figure 2 illustrates how a network element/
function can be described in detail. The bounding
box represents the function at a higher level of
abstraction. Even though the elements outside the
box are functions defined by other network areas,
they are included as the information carried over
the interface helps the reader understand the role
of the function, and its relationships with the rest of
the system. By adhering to the principle of need-toknow, context is not lost as the viewer drills down
from one level to the next.
This need-to-know principle is fundamental to
Ericsson’s toolset, which can create a hierarchy of
diagrams that show just what the reader needs to
understand: in other words, a system that renders
illustrations with the main structures and the
correct level of detail without being cluttered with
­unnecessary information.
Details are conveyed through recursive
decomposition of the logical functions into subfunctions — a concept that is illustrated in Figures 1
and 2. To illustrate the principle of recursive
architecture descent, Figure 3 shows how a logical
function can be rendered.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Illustrative architecture ✱
HSS
Function - S/I-CSCF
Cx
MTAS
ISC
Registrar
Mw
P-CSCF
SIP
routing
Media
handling
Mr
MRF
Figure 3 Drilling down into a logical
function
#01, 2015
✱
Ericsson technology review
23
✱ Illustrative architecture
These architecture diagrams are the toolset’s
graphical description of the logical, multilevel
structure of the network area (being described).
However, formal representation is also required.
Figure 4 shows a formal, tree, representation of (a
part of) the same model.
The formal model may contain protocol
definitions, which consist of signals and their
parameters. Functional components can be
associated with such protocols, and detail how they
interact with each other. Sequence diagrams, like
the one shown in Figure 5, are created using the
sets of signals available in the protocols, and aid the
understanding of how a system works by adding
behavior to the architecture.
In line with good design principles —
simplification where possible — recursive descent
is also applied to sequences, so that several
subsequences can be abstracted into a block, which
can then be reused in higher-order sequences.
The goal is to create a toolset that provides
a single, consistent and maintainable system
description that captures the system’s logical
functionality, its hierarchical structure, its internal
and external relations, and ultimately how it relates
to implementation and deployment. In other words,
the aim is to build a toolset that supports both human
understanding and formal stringency.
The fundamental enablers
The open source community Eclipse2 is a good
example of how collaboration across industries
succeeds today. Initially, the aim for Eclipse was to
create a platform for software tool developers. But
the platform has since evolved into a sophisticated
software system with a specialized support
environment for creating a broad range of artifacts.
Eclipse
A basic framework for creating initial workbenches,
Eclipse can be tailored, providing network architects
with the right support to describe a system.
Eclipse Modeling Framework (emf)
This framework includes a set of software tools that
enable logical model structures to be created and
24
managed. In other words, contained elements, their
properties and their relationships can be modeled.
Graphical Modeling Framework (gmf)
This framework includes functionality that renders a
model as a customizable graphic.
Papyrus
A standard-based modeling tool, Papyrus supports
languages like uml and SysML, and is based on a
set of Eclipse components, including uml2, gmf,
emf, ocl and Xtext. Designed from the ground up,
Papyrus is an attractive implementation solution for
the toolset, as it can be extended, specialized, and
adapted to appear to the user as a domain-specific
language (dsl), or more accurately as a domainspecific modeling language (dsml). This capability
enables architects to work using modeling concepts
that are natural to the context at hand.
Generic modeling languages — like uml —
are powerful and flexible, as they can be applied
to a wide range of modeling tasks. However, that
flexibility is also one of their drawbacks, as the
responsibility lies with the user to perform the
mental translation from contextual to generic
modeling concepts. By instead using a dsl, this
responsibility can be shifted to the toolset, allowing
architects to focus on the job at hand: creating the
best architecture.
A key component of any design toolset is the
ability to share modeling information across a large,
and geographically distributed, team. One candidate
open source toolset for managing versions, parallel
development threads and distributed development
is Git. While this toolset is included in the Ericsson
solution, Git was primarily developed to support
code development, and as such was initially text
focused. Fortunately, significant work has been
carried out over the past couple of years to make the
compare-and-merge functionality model-aware,
which is a vital component in the bigger picture.
A domain-specific toolset
The Ericsson toolset for evolving network
architecture — network architecture domain specific
language (nwa dsl) — is based on Papyrus and
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Illustrative architecture ✱
«NWAComponent» S/I-CSCF
«NWAContext» S/I-CSCF
«NWAFunction» Function - S/I-CSCF
«NWAComponent» SIP routing
«NWAComponent» Registrar
«NWAComponent» Media handling
«NWAConnection» <Dependency> Media handling
«NWAConnection» <Dependency> Registrar
«NWAConnection» <Dependency> ISC
«NWAConnection» <Dependency> Cx
«NWAConnection» <Dependency> Mr
Diagram 3 - Next level - inside a CSCF
«NWAComponent» MRF
«NWAConnection» <Dependency> Mb
«NWAConnection» <Dependency> Mr
«NWAConnection» <Dependency> Mw
«NWAConnection» <Dependency> Cx
«NWAConnection» <Dependency> Iq
«NWAConnection» <Dependency> Mw
Figure 4
The formal model
#01, 2015
✱
Ericsson technology review
25
A:IMS Client
:S/I-CSCF
:MTAS
B:IMS Client
INVITE()
INVITE()
INVITE()
〉〉graphics library — customized svg shapes for
visualizing different network functions in diagrams;
〉〉palettes — showing the user what elements are
available for building network architectures; and
〉〉software — to implement the associated logic, including
the additional ui menus needed for the nwa dsl.
INVITE()
200 OK()
200 OK()
200 OK()
200 OK()
ACK()
ACK()
ACK()
ACK()
Figure 5 Simple sequence
diagram
supports key aspects of architecture design, such
as advanced model validation, model and tool
integrations, deployment analysis and validation,
architectural exploration, variation points, and
product line management. Essentially, the toolset
includes the following components:
〉〉uml2 profile — tailored to the network architecture
(nwa) graphical modeling language (originally defined
independently of tool implementation);
〉〉style sheets (css files) — to govern how customized
diagrams are rendered;
References
1) Docker, What is Docker?, available at:
https://www.docker.com/whatisdocker/
2) Ericsson, 2014, Presentation, uml or dsml?,
available at:
https://www.eclipsecon.org/europe2014/sites/default/
files/slides/Ericsson_NWADSL_at_EclipseCon_
Europe2014_0.pdf
26
However, providing the logic and rendering
information is still not enough. To describe the
perfect system, domain-specific properties that
do not break the fundamental assumptions of
Papyrus and uml are needed. This is where the
stereotype mechanism of uml comes into play. By
extending uml Components (defined in the uml
standard) with stereotype designators, the cssbased graphics rendering process picks up the
stereotype and its associated properties to produce
the graphical representation. The resulting diagrams
that architects use to validate their ideas focus on
essential information and use a graphical syntax that
is meaningful, rather than the kind of generic syntax
used by standard models like uml.
The Ericsson toolset could have been developed
from scratch. However, by building directly on the
semantic richness of uml, the resulting toolset
benefits from years of development conducted
by experts in the fields of modeling and tool
implementation. In addition, integration with other
dsls based on uml2 profiles — both existing and
future releases — becomes easier. In other words, the
Ericsson toolset not only benefits from developments
already delivered by the Eclipse modeling community,
but, and perhaps more significantly, will continue to
benefit as enhancements become available.
The open source approach:
how and why?
Large software organizations, like Ericsson, have
used model-based engineering as a key business
differentiator in many different contexts. Today,
modeling is used in a wide range of tasks, including
software design, system design, information
structure, network architecture, and the mapping of
business processes. However, there are a few issues
limiting the wider adoption of this approach by
industry.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
This lack of adoption by industry is mainly tool
related. For example, model-based engineering
has no proper support for dsml development and
customization, and no capabilities to support key
development areas like model-based collaborative
development, testing, deployment on multicore, and
model/tool integrations. These issues, together with
the lack of evolution of commercial tools, lead to the
conclusion that the traditional approach, based on
proprietary technologies, has failed, and that a new
solution based on open source is needed.
In light of this failure, Papyrus — an industrialgrade open-source modeling tool — provides the
necessary basis to establish a new foundation for
model-based engineering; a foundation based
on collaboration among users, suppliers, and the
research community.
Papyrus (and other related open source
technologies such as egit, emf Compare, and
uml2) has evolved to a new level of maturity,
one that has enabled its use at industrial level.
Collaboration is the key factor to ensure its
continued development and more widespread
adoption — not just with suppliers and independent
developers but also with other companies.
Interestingly, the needs and requirements of
many different companies, with different technology
domains, are similar to the telecom domain —
underlining the fact that large system development is
highly generic. For example, the architecture design
characteristics for person-to-person interaction are
more or less the same for a telecoms application as
they are in the control of electricity grids or remote
patient monitoring.
Future development possibilities
Fundamentally, building the best network first
requires the capability to model many different
aspects of network architecture, and secondly, the
ability to capture and maintain relationships among
network elements.
The compelling aspect of building comprehensive
system models is the ability to rapidly create a
functional model of a customer system, with proposals
for evolution and transformation paths. As such,
the benefits of modern architecture modeling not
#01, 2015
✱
Ericsson technology review
only apply to a
the needs and
given technology
requirements of many
domain, but are
a fundamental
different companies, with
enabler of
different technology
collaboration with
customers and
domains, are similar to
partners.
the telecom domain
To ensure
the long-term
evolution of the
open source modeling solution and the development
of a vibrant support community, Ericsson is actively
supporting and developing industrial cooperation
initiatives in this area. Ultimately, the ability to share
ideas and solutions, and contribute to the open
source community, are the key factors for successful
open source modeling.
Conclusion
The model-based engineering strategy illustrated
by the nwa dsl example lays the groundwork to
fulfill the needs of network architecture modeling,
which are:
〉〉flexibility in graphical representation — to achieve the
right level of abstraction;
〉〉integration potential — efficiency across the
development and integration chains;
〉〉a basis in an open source strategy — promoting a
community approach that can not only provide benefit
to the telecoms industry, but also to adjacent industries
experiencing similar architectural challenges;
〉〉ease of use — to lower the threshold for architecturelevel users; and
〉〉efficient collaboration — to support the entire
organization.
Applying a model-based engineering approach to
network architecture design results in increased
productivity and enhances the ability of all parties
to understand the target system. The model-based
approach ensures that the level of consistency,
performance and adaptability needed by Ericsson
and its customers is safeguarded as we progress
deeper into the Networked Society.
27
the authors
✱ Illustrative architecture
Ulf Olsson
◆ Has a background in
software architecture for
large-scale distributed
systems, ranging from
military command and
control to current and
future telecommunications.
He joined Ericsson in
1996, working mainly with
packet-based systems
like Packet pdc, gprs,
umts, cdma2000 and
ims. He then moved on
to systems architecture
in areas like service
exposure and analytics.
He is currently a senior
expert at Group Function
Technology, focusing on
overall system architecture
issues including how to
represent them formally
and informally. He holds
an m.sc. in engineering
physics from the kth Royal
Institute of Technology in
Stockholm, Sweden.
Toni Siljamäki
◆ Has a background in
modeling and software
development for
embedded systems in the
Swedish defense industry.
He joined Ericsson in 1997
28
to work on bridging the gap
between hardware and
software design disciplines,
and held responsibility for
Executable uml modeling
support and model
compiler development —
transforming uml models
into executable code in
Erlang, Java, Plex-C and C
for different platforms.
Since 2013, he has
focused on basic core
capability and usability
improvements of Papyrus,
with a special focus on
dsml development and
customization. He has also
designed and developed
the nwa dsl for Papyrus
described in this article.
Francis Bordeleau
◆ Is product manager in the
eitte software design group
at Ericsson. His primary
focus is model-based
engineering and modeling
tools. In this role, he is
responsible for defining
product specifications
and roadmaps, developing
business cases, managing
budgets, running open
source initiatives, and
collaborating with other
companies, researchers,
and academia. Before
joining Ericsson in 2013,
he was founder and ceo
of Zeligsoft — a provider
of domain-specific modelbased engineering. He
has held the position of
Assistant Professor at
the School of Computer
Science of Carleton
University, Ottawa,
Canada. He holds a b.Sc.
in mathematics from the
Université de Montréal
(1989), a Bachelor of
computer science from the
University of Quebec (1991),
and a Master in computer
science (1993) and Ph.D.
in electrical engineering
(1999) both from Carleton
University.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
xxxx ✱
5
ch
e
Ttrends:
s and
s
le
t
n
le
e
r
,
ology
n
h
c
e
t
o
t
stant
n
s
o
e
c
m
a
o
s
c
in
it
rema
t
When
n
e
ificant
m
n
p
ig
lo
s
e
v
in
e
a
t
d
r
t, ce
x
e
t
n
o
c
continuous
is
h
t
ends
r
in
t
h
y
it
g
W
lo
.
o
n
n
io
h
r tec
o
—
expectat
s
ie
it
n
portu
p
o
d
n
a
ut.
s
o
t
k
ic
shif
t
s
o
t
ency
d
n
e
t
a
e
v
— ha
#01, 2015
✱
Ericsson technology review
29
Here are the five trends that our CTO believes everyone in ict should be
keeping an eye on. They represent the primary driving forces behind new
business opportunities. In some cases, they will cause discontinuities,
and elsewhere they will present challenges. But together, they will set the
direction for technology development.
networking
as a platform
F r o m s i n g l e - s e r v i c e to multi-application platform,
the communication network becomes a massively distributed
compute, storage, and networking infrastructure.
Just how much impact mobile communication, the network
infrastructure that carries it, and the applications that make it
interesting and useful have had on the world is not news. Every
industry on the planet is undergoing a transformation, adopting
digital and virtual processes, products, and ways of working — even
the mobile communication industry itself. And each individual and
organization is adapting to make the most of it. Virtualization and
programmability are at the core of this transformation. The network
resources that make it all possible are becoming virtual, more flexible,
and more usable, to form a versatile and global platform.
tighter
security
and privacy
As d e p e n d e n c y o n networks rises, focus on security and
privacy increases. As networks transform from being closed, protected
environments into open, programmable, and distributed platforms, the
significance of security and privacy is gearing up a notch. The technology
challenge lies in utilizing the openness and global reach of the network
platform, while protecting assets and user privacy, so that society as a
whole can reap the benefits of new network capabilities without being
subject to attack or breaches of security.
30
Ericss o n t e chn o l o gy r e v i e w ✱ # 0 1 , 2 0 1 5
analytics
everywhere
I n c r e a s e d c a p a b i l i t i e s in analytics and machine learning
will unlock new ways of doing business.
Modern networks carry massive amounts of data, and the growth trend
shows no signs of leveling off. This volume of data is a highly valuable
resource, as it provides insight into customers, improves traffic pattern
predictions, highlights potential business opportunities, and can help
identify the services that are being used and those that aren’t. The key to
delivering these benefits is real-time analysis of network metadata.
the iot opportunity
C u s t o m i z e d n e t w o r k s l i c e s to support
upwards of 26 billion devices (beyond 2020) of all shapes and sizes to
suit all needs. In our most recent Mobility Report, Ericsson estimated
that the global number of connected devices is set to top 26 billion
by 2020. Estimates from other ICT players are similar. Some predict
slightly more, some predict slightly fewer, but whatever the exact
figure, that’s a lot of devices to provision and a lot of data to manage.
And so, networks need to gear up, becoming more flexible and
rapidly scalable to cope with widely varying use cases.
more digital and
ever more mobile
As i n d u s t r i e s s h i f t to provide virtual products and services
Two major transformations — digitalization and mobilization — are changing
the way people and society function, and the media industry is leading the
way. Media has undergone several transformation cycles, from broadcasting
and the sale of physical products (like CDs and DVDs) through actual stores,
to selling digital products (downloads, pay-per-view, and on-demand TV)
through user portals, to selling services (like streaming) on a subscription
basis. This transformation has taken place at the same time as the dual shift
in the consumption of content (from the single fixed screen to multiple mobile
devices) and the creation of content (from enterprise to everyone).
Read more about each trend on http://www.ericsson.com/thecompany/our_publications/ericsson_technology_review/archive/technology_trends_2015
#01,
#
0 1 ,2015
2 0 1 5✱ ✱
E rEricss
i c s s o no n
t etcehchn
n o loolgoygy
r ervei v
ew
iew
31
✱ The agile network
t
r
o
p
p
u
s stems
sy
up
g
n
i
r
Gea
defined orks
e
r
a
ftw zed netw
o
s
for rtuali
i
and v
〉〉 Carlos Bravo
Francesco Caruso
Christian Olrog
Malgorzata
Svensson
András Valkó
32
The business environment of operators and service providers is going
through a fundamental transformation. By 2020, more than half1 of
the envisioned 50 billion devices will already be connected. And
while the ever-expanding use of connectivity presents a major growth
opportunity, it also creates new and tougher demands on networks
— and particularly on the processes for managing users
and devices.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
The agile network ✱
Parallel to the connectivity revolution,
the digital economy has triggered a
transformation in the way services are
produced and consumed. Enabled by the
global communication infrastructure, a new
market of digital services is emerging. In this
market, people and organizations can expose
their digital assets, which can be rapidly
combined with partner assets to create new,
more useful, and more interesting services.
c o m m u n i c a t i o n networks have a key
responsibility: to provide the p
­ latform that enables
the digital market to continue to develop. This
­responsibility presents operators and service providers
with a unique opportunity. However, this opportunity
is offset by the challenges of price pressure as well as
the perceived commoditization of networks.
So, to capture the digital market opportunity, both
telecom networks and support systems — oss/bss
— need to gear up.
Gearing up
Business agility is one way to respond to the trends
of digitalization and pressed profit margins. By
being able to apply technologies that increase
the level of flexibility in networks, operators and
service providers can gear up from delivering
network infrastructure to becoming providers of
innovation platforms.
To do this, valuable assets (like network
infrastructure, the subscriber base, user identities,
security credentials, location and mobility
information, service and product catalogs, charging
and billing functions, connected device identities,
and many more capabilities that can be used to
create digital services)
Time-to-market:
need to be leveraged in
how quickly the
new ways.
In the digital
changing needs of
economy, only a few
modern consumers can
players will own all
the assets that are
be detected, and how
needed to create
quickly they can be
attractive services.
Typically, assets from
reacted to
different players will be
combined dynamically
in collaborative
organizations. Operators will blend their capabilities
together with partner assets to expose novel
services. The result: innovation, mashed services,
and highly satisfied users.
The key to success in the digital market is the
ability to adapt, and true business agility (illustrated
in Figure 1) requires flexibility in all three
dimensions: networks, services, and customers.
Network agility
Cloud, sdn and nfv are key elements of network
agility: the capability to efficiently plan and build
networks, adapt them to changing requirements, and
provide superior service quality.
Service agility
The keys to achieving service agility are: the ability
to create new services rapidly, to launch and deliver
superior-­quality services with ease, and to be able to
­monetize them.
Customer agility
The keys to achieving customer agility are: the ability
to interact with consumers in a way that is flexible
Terms and abbreviations
api—application programming interface | etsi—European Telecommunications Standards Institute | nf—network function |
nfv—Network Functions Virtualization | nfvi—Network Function Virtual Infrastructure | oss/bss—operations support systems/business support systems | pnf—physical network function | sdn—software-defined networking | se—service enablement | soa—service-oriented architecture | ttm—time to market | vApp—virtual appliance | vDC—virtual data center |
vim—Virtual Infrastructure Management | vnf—Virtual Network Function
#01, 2015
✱
Ericsson technology review
33
✱ The agile network
Customer/partner management
and interaction
Plan-toprovision
Customer agility
MAKE IT
EASY
Idea-toimplementation
Lead-toservice
Service-tocash
Experience-toresolution
$
Service agility
MAKE IT
WORK
Network agility
Figure 1
MAKE IT
REAL
MAKE IT
HAPPEN
MAKE IT
PAY
MAKE IT
BETTER
Data-to-experience
MAKE IT
ACTIONABLE
Network and cloud management
MAKE IT
ACCESSIBLE
Experience
assurance
Customer
partner
interaction
Order
management
Revenue
management
Resource
management
Service
inventory
Customer
partner
management
M
Enterprise
catalog
Service
enablement
M
NF domain
vApp
management
management
Cloud SI
management
OSS/BSS and SE
Business agility
Transport
domain
management
Network
function
SDN-C
Nonvirtualized
application
Virtualized
application
Figure 2
oss/bss architecture
for sdn/nfv-enabled
networks
34
Equipment
SDN-C
SDN-C
System
infrastructure
Transport
Cloud system
infrastructure
Transport
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
The agile network ✱
and dynamic, the ability to expose new services, and
the means to proactively resolve problems or react to
issues rapidly.
Network agility
Both sdn and nfv play key roles in gearing up
to the level of network agility needed to explore
the opportunities and address the challenges
presented by the Networked Society and the digital
economy.
The concept of network virtualization
— providing physical network resources
as virtualized entities — has already been
successfully applied to telecom networks.
Examples of this type of network partitioning
include vpns and vlans. In 2012, a group of
service providers launched the nfv initiative.
Their aim was to apply best practices from the it
industry — as it virtualized data centers and server
rooms — to the telecom domain. In other words,
how can network elements be virtualized so that
the maximum benefit from commodity-computing
technologies can be achieved, while improving
service agility and service efficiency at the same
time? The short answer is nfv and sdn.
nfv
From a technical point of view, nfv promotes
the decoupling of network functions (nfs) from
hardware. By applying virtualization technologies,
the software of network functions can be broken
apart from hardware appliances. In turn, this
separation unleashes massive flexibility in terms of
how nf can be dynamically deployed, elastically
resized, and offered on an on-demand basis. Some
of the potential benefits of this flexibility are reduced
cost and lower power consumption, but gains can
also be made in terms of increased speed and
efficiency in the deployment of telecom networks.
sdn
sdn provides the ability to programmatically define
and manage networks, which enables the complexity
of underlying implementation to be abstracted
from the applications that run on the network and
consume resources. From a technical point of view,
#01, 2015
✱
Ericsson technology review
sdn enables separation of the data plane from the
control plane.
Service providers typically use sdn to take
a holistic view of their networks, applying sdn
concepts across network layers and domains, which
in turn enables end-to-end programmabilty.
sdn and nfv together
Originally, the aim of combining nfv and sdn was
to decouple services from resources, but when
these two technologies come together, they provide
the additional benefit of detaching life cycle
management from physical constraints. Today,
it is possible to provision an sdn/nfv service
instantaneously without the need to deploy new
physical resources. This flexibility is the foundation
of network agility.
Virtual resource
A virtual resource is an
abstraction of a physical
resource — compute,
storage, or network.
Virtual resources can be
shared among multiple
consumers in such a way
that they appear to be
dedicated.
Service agility
At Ericsson, oss/bss are designed according to a
functional decomposition of network architecture
domains that natively account for sdn and nfv.
Similar to network agility, sdn and nfv play key
roles in gearing up the level of service agility.
Figure 2 shows the oss/bss and service
enablement (se) architecture for sdn/nfvenabled networks. The diagram highlights the
main functional blocks: oss/bss and se, network
functions, equipment (representing the collection of
physical resources), the cloud system infrastructure,
and transport.
Figure 2 oss/bss architecture for sdn/nfvenabled networks.
An nf can be supported by native (nonvirtualized, physical nf) or by virtual (a virtualized
application or a virtualized nf) resources. From a
management point of view, nf are governed across
two orthogonal planes:
〉〉the network function domain management plane
— illustrated as NF domain management in Figure 2;
and
〉〉the supporting resources management plane
— illustrated as vApp management, in Figure 2.
The nf domain-management plane supports
operational needs of nfs, such as fault management,
performance management and specific
35
✱ The agile network
Resource
spec
Charging
logic
spec
Service
spec
Read
service
spec
........
.......
.......
Add
charging
logic
Define
service
spec
........
.......
.......
Read
resource
spec
OSS/BSS
Service
enablement
M
M
Domain
Cloud SI
domain
management
management
Network
function
Access
Assurance
logic
spec
Customer
segment
spec
Add
assurance
logic
Resource
inventory
Cloud system
infrastructure
Product
offering
Add
customer
segment
Service
inventory
Business
logic
creation
environment
Publish
product
offering
Product
catalog
Service
catalog
Transport
Customer
management
IT
Figure 3
Idea to implementation
Handle
customer
request
........
.......
.......
Handle
customer
order
Handle
service
order
Orchestration
creation environment
Activate
resources
Orchestration
execution
Customer
interaction
M
Product
catalog
Access
Figure 4
Customer
order
Product
order
M
Service
catalog
Network
function
Service
order
M
Service
enablement
Resource
order
M
M
Cloud SI
domain
Domain
Domain
management
management
management
Cloud system
infrastructure
Transport
OSS/BSS
IT
Lead to service
36
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
The agile network ✱
configuration for nfs; while vApp management
handles resources required by a network function
throughout its life cycle.
The cloud-system-infrastructure function
aggregates and manages virtual resources across
different instances and technologies, offered by
cloud system infrastructures (in etsi terminology
nfvi + vim).
Cloud deployments often span several different
physical sites joined through a connectivity fabric,
which may have a separate management function.
This fabric, illustrated by transport in Figure 2,
can be orchestrated together with the resource
infrastructure using sdn, effectively implementing
a vdc (or a virtual resource slice) that provides a
network service.
The functions in the oss/bss and se plane are:
〉〉experience and assurance — offering service
assurance;
〉〉customer and partner interaction — enabling both
parties to interact with support systems through
multiple communication channels;
〉〉order management;
〉〉revenue management — providing the capabilities to
charge and invoice for any type of product or service
usage;
〉〉resource management — providing a unified resource
inventory for both virtual and physical resources;
〉〉service inventory;
〉〉customer/partner management;
〉〉enterprise catalog — consisting of products, services
and resources; and
〉〉service enablement — providing service exposure
capabilities to partners for service innovation.
The oss/bss and se plane in sdn/nfv-enabled
networks provides capabilities to introduce new
virtual nfs or vApps progressively. In other words,
new virtual nfs or vApps can be instantiated in
a dedicated slice called trial. At the same time,
an instance of the same nf can be executing in
another slice — called production. The redirection
of users from the old to the new nf/application can
be carried out gradually, with minimum impact,
and managed programmatically in a way that is
transparent to users of the service.
#01, 2015
✱
Ericsson technology review
Rapid business innovation
Support systems — oss/bss — provide the
necessary functions to encapsulate sdn/nfv
services and combine them with other assets into
product offerings. These support systems also
handle product life cycle management, the capability
to charge for products, and the process for exposing
products to users and partners.
However, one of the most significant challenges
for operators and service providers today is time to
market (ttm). One way to shorten the time from
concept to delivery is to have a good understanding
of business processes, so that the level of automation
in processes can be raised. By having welldocumented business processes, preconfigured
solutions and suites can be delivered, which in turn
enables additional business process innovation and
increased speed when introducing new offerings,
all while maintaining flexibility and the ability to
integrate.
As sdn and nfv facilitate new services, these
technologies have greatest impact on the business
processes that lie between the formation of an idea
and its implementation — such as planning, design
and deployment.
Figure 3 illustrates some of the activities included
in the ideas-to-implementation process. It shows
a possible scenario for creating a product offering
from the services and resources managed by several
functional domains.
Within oss/bss, the key logical function of the
idea-to-implementation process is the business
logic creation environment, which is illustrated in
Figure 3. Resource and service specifications as well
as product offerings are created in this environment,
which all result in a product catalog entry.
The idea-to-implementation process can be
broken down into a number of specification
phases: network function, resource, and service
specification.
Virtual data
centers (vDCs),
slices and network
services
A vdc is an instance of
a data center operated
on a per-tenant basis,
with flexible network
topology and basic
services — compute,
network, and storage —
as well as more complex
ones such as firewalling
and load balancing. A
vdc may span multiple
physical data centers
or be constrained
to a subset of the
infrastructure within a
single dc.
A virtual resource slice,
referred to as a slice, is
an isolated view of the
virtual resources — a
vdc in other words.
A network service (ns)
is composed of vnfs,
pnfs, virtual links
and vnf forwarding
graphs that support the
communication service.
Network function specification
Domain management uses the information
provided in the nf specification to build the
resources needed to construct the desired services.
37
✱ The agile network
In some cases, this is a ready-to-use specification
provided by the nf vendor.
Resource specifications
The virtual infrastructure resources needed by
the nfs that the cloud system infrastructure will
expose need to be specified. These resources are
described using vdc and vApp templates, and may
be provided by the vendor.
Service specification
Describes how transport service connectivity
could also be exposed and bundled together with
the target services defined by the market’s needs
into product offerings. These product offerings
may be targeted to any segment, such as media
providers or health care providers. The service
specification includes characteristics that define
specifics of the service in relation to requirements
of the target segment.
The catalog-driven approach facilitates
onboarding of new services, through simple
modeling based on principles like modularity for
defining services and reusability to construct richer
and aggregated services and product offerings. It is
one of the main pillars of the ideas-to-implementation
process, complemented by ease of integration
through standard interfaces and pre-integration and
automation of the end-to-end processes.
Instantly available services
Virtualization of network functions and the
decoupling of software from hardware enable full
automation of the lead-to-service process (shown in
Figure 4) across functional domains. Automating
this process includes instantiation of the entire
software stack of nfs that are encapsulated in
a service, reducing time from order to service
activation, and improving resource utilization — as
resources become allocated shortly before use.
Service-oriented architecture (soa) and
innovative micro-services provide programmable
interfaces designed according to well-established
industry standards and make major contributions
to orchestration and automation. They are some of
the key architecture principles, which together with
38
a common information model expose services using
apis, enabling ease of integration — as described
in a previous Ericsson Review article2. These key
principles allow the instantiation of nfs and the
resources needed. They facilitate the creation of
product offerings from services and resources
defined in different domains — oss/bss, transport,
cloud system infrastructure, and it.
Customer agility
Similar to network and service agility, sdn and
nfv play key roles in gearing up the level of
customer agility.
In the digital economy, the role of partnerships
and ecosystems is more significant than traditional
economies. Digitalized businesses collaborate
more, and combine their assets together with
partner assets to provide customers with the best
services. In this environment, new ways that enable
mashed offerings, service exposure, and blended
services are needed.
Service enablement, as shown in Figure 2,
includes the functions needed to enable operators
and service providers to monetize their assets and
connect to others.
Service exposure, one of the core functions within
se, provides access to network capabilities exposed
by the service development environment through
programmable interfaces. Exposure enables
developers — either at the operator, a partner or a
3pp — to design and compose innovative services.
Support systems — oss/bss — provide the
capabilities to manage partners and developers, to
handle all communication channels, and to organize
the administration of products and services.
Technologies like sdn and OpenStack provide
developers with programmable interfaces, which
can be used together with oss/bss capabilities so
that new services can be deployed and executed in
isolated virtual environments.
In addition to exposing network programmability
through OpenStack and OpenDaylight apis,
developers have access to other services and
capabilities like user identification, charging and
network policies, and configuration information to
program nfs.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
The agile network ✱
Health care
provider
Media
provider
Media
provider
Any industry
verticle
OSS/BSS
Network functions
Instance 4
Instance 3
EPC-4
HSS-4
RAN
Instance 2
Instance 1
EPC-1
EPC-2
HSS-1
EPC-3
IMS-2
IMS-3
HSS-3
HSS-2
Figure 5 Providing new
services with NFV
#01, 2015
✱
Ericsson technology review
39
✱ The agile network
Operator A
Operator B
SDN app
specific
API
M
Settlement
Peer
OSS/BSS
OSS/BSS
SDN app
SDN controller
management i/f
M
Transport
management
i/f
Transport
management i/f
Element
management i/f
Root SDN
controller
Figure 6
BGP
(for example)
OSPF
(for example)
Child SDN
controller
Router
Data plane
Peer
routing
domain
Forwarding
element
Software-defined
networking
40
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
The agile network ✱
New business opportunities
The virtualization of nfs enables operators and
service providers to develop new services for
traditional segments, as well as providing the
possibility to enter new markets. For example,
virtualization enables bundles that include
connectivity services to be mashed with value-add
services and exposed in a one-stop-shop fashion,
which can be created and offered to various
industry verticals.
Traditionally, a connectivity services offering
for industry verticals tends provide network
connectivity optimized for the specific vertical. In a
virtualized environment, optimization is simplified,
as nfs can be instantiated for a particular vertical, as
illustrated in Figure 5.
This illustration shows how nfs and support
systems interact. nfs enable the connectivity to
connect everything in the network together — such
as mobile phones and other handheld devices, as
well as cars, and health care and transportation
equipment. And the support systems — oss/bss —
manage the nfs and translate their capabilities into
tangible services that can be offered to any industry
vertical through operator and service provider
capabilities.
Operational simplicity and efficiency
Software-defined networking usually refers to the
unbundling or separation of the control plane and
the forwarding plane of network elements. It can be
solved in many ways, and OpenFlow is a commonly
used protocol. Traditionally, management
functions have typically interacted with interfaces
exposed by the control plane but with sdn, the
separated forwarding plane becomes a managed
entity in itself.
The separation sdn provides results in fewer
control planes; this in turn makes it easier to align
the different types and versions of control planes
and raises the bar for the least common denominator
of functionality. Taken to the extreme, this concept
results in a single sdn controller being sufficient,
and so provides the benefits associated with reduced
network complexity.
While sdn is not a prerequisite for efficient
#01, 2015
✱
Ericsson technology review
reconfiguration of
to capture the
network resources,
digital market
it does provide a
solid foundation for
opportunity, both
network agility. For
telecom networks and
example, separation
has already led to
support systems — OSS/
improvements and
BSS — need to gear up
new forwarding
service paradigms
like service
chaining3,4 .
Operational efficiency — not just for the single
service but the entire delivery operation — is
greatly enhanced by implementing an sdn fabric
that supports dynamic, automated and modeldriven reconfiguration. Furthermore, when
applications are added to the sdn controller
dynamically, the possibility to perform dynamic
protocol analytics increases, which in turn eases
troubleshooting.
In an nfv context, both sdn controllers and
forwarding elements can be deployed as Virtual
Network Functions (vnfs). Typically, hypervisors
already include a software-defined forwarding
function that is sdn capable, which can work in
conjunction with physical forwarding elements.
Innovation in sdn networks
One of the primary reasons to shift to sdn is the
potential increase in flexibility and agility. However,
it does not necessarily follow that the introduction
of a given technology automatically leads to
improved agility and more streamlined operations.
Typically, the adoption of a new technical model
follows a hype curve — adoption takes place once
business value has been identified, and proper
abstractions are in place to simplify the application
of the technology.
In a previous Ericsson Review article, the concept
of Service Provider sdn 4 was coined. This concept
takes a holistic view of sdn, extending it beyond
the data center to include abstractions that enable
services to be built that leverage all the functions of
the entire network.
41
✱ The agile network
Shifting to sdn/nfv
By nature, sdn and nfv are disruptive technologies,
and as such, tend to foster rapid innovation. They
bring about changes that fundamentally alter the
traditional way networks have been managed and
developed.
As enablers of automation, nfv and sdn make
full use of one of the key architectural oss/bss
principles — a c­ atalog-driven approach based
on a unified model promoting reuse, automation,
speed and correctness.
The concepts of the virtual data center (vdc)
and the virtual resource slice enable services to be
deployed in parallel, and in controlled isolation.
This type of parallel deployment adds flexibility
— because it, for example, enables operators and
service providers to run different versions of multitenant appliances, which can be dimensioned on
demand, and enables services to be personalized.
The ability to improve speed and correctness is
a key ingredient of innovation. By containing risk
and ensuring failures are detected early (failing
fast), operators and service providers can test
more concepts, and do this not just for services
and applications, but also for different market
segments.
The concept of time to market is changing.
Traditionally, ttm was about getting a version
of a service into the hands of paying customers
as quickly as possible. Today, ttm is about how
quickly the changing needs of modern consumers
can be detected, and how quickly they can be
reacted to.
The oss and bss naturally play a key role in
enabling the operation of this new paradigm.
Automating the different flows required, from
the idea of the new service to the implementation
and operation of it, ensures operators and service
providers are in full control of their network and
services, and are empowered to act on insights and
how they are used.
The concepts of sdn, nfv and the virtual
data center, as well as rapid adaption to changing
consumer needs, form the pillars upon which
network, service and customer agility are built.
References
1) Ericsson, June 2015, Mobility Report, available at:
http://www.ericsson.com/mobility-report
2) Ericsson, 2014, Ericsson Review, Architecture evolution for automation and network programmability,
available at:
http://www.ericsson.com/news/141128-er-architecture-evolution_244099435_c
3) etsi, 2014, Group Specification, Network Functions Virtualisation (NFV); Architectural Framework,
available at:
http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/01.02.01_60/gs_NFV002v010201p.pdf
4) Ericsson, 2014, Ericsson Review, Software-defined networking: the service provider perspective, available at:
http://www.ericsson.com/news/130221-software-defined-networking-the-service-provider-perspective_244129229_c
42
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
the authors
The agile network ✱
Christian Olrog
◆ Is an expert in
cloud service delivery
architecture and chief
architect at Business
Unit Support Solutions
at Ericsson. He joined
the department of New
and Special Business
Operations at Ericsson
in 1999 and has been
involved in research and
development in areas
ranging from wireless
lan standardization and
ip security to embedded
devices and enterprise
applications. He holds
an M.Sc. in physics from
kth Royal Institute of
Technology, Stockholm,
Sweden.
systems integration. He
joined Ericsson in 2000
and has worked in all
stages of product life cycle
in Ericsson, from design
to delivery and execution.
He holds an M.Sc. in
telematics engineering
from the Higher Technical
School of Engineering
(etsi), Seville, Spain.
#01, 2015
✱
Ericsson technology review
Malgorzata
Svensson
◆ Is an expert and oss/
bss chief architect at
Business Unit Support
Solutions at Ericsson.
She has over 15 years’
experience with operation
Francesco
Caruso
◆ Is an expert in cloud
architecture and
management at Group
Carlos Bravo
◆ Is portfolio sales support
director and principal
architect in cloud and sdn
at Business Unit Support
Solutions at Ericsson.
He has over 15 years’
experience with operation
and maintenance systems
and processes and
the internal cloud program
to transition oss to the
cloud environment and to
extend oss into the cloudmanagement domain. He
has more than 20 years’
expertise in the telecom
oss domain and holds an
M.Sc. in computer science
from the University of Pisa,
Italy.
Function Technology.
He joined Ericsson in
2012 from Telcordia
Technologies, where
he was director of the
Enterprise Integration
Group. He championed
and business support
systems. She joined
Ericsson in 1996 and has
been involved in research
and development in areas
ranging from revenue
management, ims,
analytics, cloud and sdn.
András Valkó
◆ Is responsible for
architecture and
technology within
Ericsson oss Portolio and
Solutions. He has nearly
20 years’ experience in the
telecom industry, mostly
within the area of network
management and oss,
with a focus on service
assurance, analytics,
performance management,
automation, and selforganizing networks. He
holds a Ph.D. in computer
science and has a technical
research background.
Before his current
assignment, he was head
of Customer Experience
Management and Analytics,
and previously led the
Ericsson Research unit for
network management and
oss/bss.
Acknowledgements
The authors gratefully
acknowledge the
colleagues who have
contributed to
this article: Lars Angelin,
Henrik Basilier, Jan
Friman, Ignacio Más, and
John Quilty.
43
✱ A step toward efficient virtualization
the
benefits
OpenStack as the API
framework for NFV:
and the extensions needed
Service providers are looking to Network Functions Virtualization (nfv) as
a way to deliver and deploy Virtual Network Functions (vnf) services in a
flexible way, using virtualization and cloud computing techniques. As an IaaS
framework constructed as pluggable api components, OpenStack provides
a given level of automation and orchestration to deploy and provision nfv
services. But is it enough, and what improvements are needed?
〉〉 alan kavanagh
44
Both OpenStack and nfv have developed considerably over the past few years from an is/it
and a telecoms perspective.
While these two concepts relate to similar
areas — virtualization, rest-based apis, and
providing fast large-scale services independent of underlying hardware — they address
these areas from different angles.
o n t h e o n e hand, etsi nfv aims to define an
architecture and a set of interfaces so that physical
network functions, like routers, firewalls, cdns
and telco applications, can be transformed: from
software applications designed to run on specific
dedicated hardware into decoupled applications —
called vnfs — deployed on vms or containers, on
generic servers.
OpenStack, on the other hand, addresses service
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A step toward efficient virtualization ✱
provisioning and virtualization by providing an
open-source software service framework that is
api-driven and pluggable, enabling public and
private clouds to be quickly deployed and managed
effectively. A high-level architecture of a telco cloud
service built using OpenStack is shown in Figure 1.
The transformation to vnf services and
deployment scenarios needs an api framework,
and OpenStack is a suitable candidate. However,
to ensure carrier-grade service and support for
provisioning of nfv services, some extensions to the
set of apis are needed, and the concept as a whole
needs to be embraced.
A modular architecture
In 2010, Rackspace and nasa jointly launched
the first release of OpenStack distribution
(Austin). Their aim was to create an open-source
cloud platform that could provision computing,
networking and storage services for private and
public clouds. In other words, a large-scale and
feature-rich api pluggable framework enabling
automated service deployment and provisioning.
The original OpenStack architecture was
modular, built with independent components
(services), called through a rest-based api
frontend. The initial Rackspace/nasa release
included just two services: Nova — for managing
compute resource pools; and Swift — the object
storage system. The architecture is still modular
today, but as Figure 2 shows, it has grown with each
release, through the addition of new components
providing extra services in the IaaS layer.
As an IaaS framework that is flexible and apidriven, OpenStack offers vendors and solution
providers a means to integrate their compute,
network and storage-infrastructure plugins best
suited to their environment. As such, OpenStack
enables end-to-end service deployment,
provisioning and orchestration, reducing
implementation time from weeks to hours. The core
services in OpenStack today include:
Horizon — a web-based service portal that
provides tenants and administrators with a user
interface for provisioning services such as vms and
object storage, and other capabilities like assigning
ip addresses, and configuring access control for
provisioned services.
Nova — which is responsible for compute services,
such as scheduling, and on-demand initiation of
vms, Linux Containers (lxc), or Docker containers,
as well as the removal of these services.
Neutron — which provides networking as a service
to other OpenStack components (such as Nova). It
does this by creating and attaching the virtual switch
port to the vnic of the vm, assigning the ip address,
configuring network overlay for tenant isolation,
and providing network configuration for baremetalprovisioned servers.
Swift — which provides multi-tenant object
storage with inherent replication and automatic
scaling. It manages large volumes of unstructured
data, which is accessed through a restful api.
Cinder — which provides persistent block
storage for instances, such as a vm, running on the
OpenStack platform. It also manages block storage
devices and volume snapshots.
Keystone — which provides authentication and
authorization for OpenStack services, tracking and
authentication of users, as well as authorization
Terms and abbreviations
amqp—Advanced Message Queuing Protocol | api—application programming interface | bios—basic input/output
system | cdn—content delivery network | cee—Cloud Execution Environment | cli—command-line interface |
cpu—central processing unit | hot—Heat Orchestration Template | https—Hypertext Transfer Protocol Secure |
iaas—infrastructure as a service | kvm—kernel-based virtual machine | libvirt—virtualization API | nfv—Network
Functions Virtualization | ovs—open virtual switch | rest—Representational State Transfer | taas—tap as a service
| txt—Trusted Execution Technology | vm—virtual machine | vnf—Virtual Network Functions | vnic—virtual
network interface card
#01, 2015
✱
Ericsson technology review
45
API exposure
OSS/BSS systems
VNF
VNF
Cloud and service
manager
VNF
VNF
VNF
OpenStack
Compute
Networking
Storage
Telemetry
Virtualization layer (KVM/OVS, networking, storage)
Analytics, policy, security infrastructure
✱ A step toward efficient virtualization
Network
Figure 1
Telco cloud service
architecture on
OpenStack
Heat
Orchestrates
cloud
Provides UI
Horizon
Provides network
connectivity for
Neutron
VM
Provides
images
Provides
volumes for
Provisions
Cinder
Nova
Glance
Stores
images
in
Swift
Monitors
Ceilometer
Figure 2
OpenStack conceptual
architecture
46
Keystone
Provides
authentication for
Backs up volumes in
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A step toward efficient virtualization ✱
of the services requested by a user (before the
service request is processed). This is a common
service used by all OpenStack api servers.
Glance — which stores and retrieves vm disk
images and corresponding metadata.
Heat — which provides orchestration of services
using Heat Orchestration Templates (hots), which
describe a given cloud application and how it is
deployed using OpenStack.
Ironic — which provisions baremetal machines
using a pxe boot, for example. By image
provisioning baremetal machines in an automated
and orchestrated way, Ironic can provide high
performing compute clusters, without incurring
the overheads and license fees associated with
hypervisors. This is a significant advantage for
applications and services that perform high packet
processing, and require deterministic performance
as well as low latency.
Functional blocks
The core of each OpenStack service, which is
commonly referred to as the controller, manages
the given service. Services like Nova and Neutron
are built on a pluggable architecture and use an
api web-based services frontend for managing
the controller. The frontend is responsible for
handling authentication and authorization of
api calls via Keystone, as well as command and
control functions like requesting or deleting a vm or
establishing admin/user rights. As Figure 3 shows,
an OpenStack service calls another OpenStack
service through its northbound api. Initial service
requests are sent through a service portal, which
can be the default dashboard (Horizon), or through
a more enriched cloud manager that interfaces with
the northbound api of the OpenStack controllers.
Another method is to access each individual
OpenStack service directly via the cli, though this
is most commonly used for troubleshooting and
advanced administrator tasks.
For example, the Nova compute controller
comprises a set of services including:
〉〉Nova Scheduler — which determines where the
compute service should be instantiated;
〉〉Nova Conductor — which acts as a proxy for requests;
#01, 2015
✱
Ericsson technology review
〉〉Nova Compute Agent — which runs on the compute
blade; and
〉〉Nova database (db) — which stores most build time data
(resource availability, consumption and state) for what
instances are running and which compute blade they
are running on.
The tasks these controller elements carry out to
complete a service request are best described
through the steps in the process to deploy a vm — a
common task carried out by tenants logged on to a
(Horizon) service portal.
vm boot process
The api query for vm deployment is first
authenticated by Keystone. If successful, the request
is passed on to the Nova Scheduler, which allocates
a compute blade for the vm, and then publishes
the request, via the message queue, to the Nova
Compute Agent.
The message queue is used for communication
between all OpenStack daemons and uses amqp —
typically implemented with Rabbitmq.
Depending on the hypervisor or container
solution being managed, the Nova Compute daemon
will call the relevant plugin and the relevant api to
instantiate a vm, for example, via the appropriate
hypervisor. If the deployed solution is a kvm
hypervisor, the Nova Compute Agent calls libvirt to
instantiate a vm, and then updates the Nova db with
the status of the requested vm.
Next, the Nova Compute Agent calls Neutron api
to provision and configure the networking for the
compute service. This may include attaching the vm
to the network as well as allocation of an IP address.
After network provisioning, Nova Compute Agent
calls Cinder api to provision persistent block storage
based on tenant preferences.
Glance api is then called, and returns the url
denoting where the vm image file is stored in the
backend object store, which Nova Compute Agent
uses to download it. Once the image is installed on
the compute blade, the vm will boot.
The steps in this process indicate how vnfs can
be orchestrated, and automatically provisioned
and deployed, using OpenStack services in a vm
47
✱ A step toward efficient virtualization
environment. Provisioning of vnfs via baremetal
would also follow a similar process — which is
supported by Ironic. vnfs that require all available
resources on a given compute blade, such as ram,
cpu cores, disk I/O and/or full nic bandwidth,
are best suited to be provisioned on baremetal —
without a hypervisor. In this case, the Nova Compute
uses a baremetal plugin to call the Ironic api server
that queries the Ironic Conductor to fetch the image
files. Once Neutron has provisioned and configured
the required networking, the baremetal node is
deployed, and pxe boot is initiated to retrieve the
vnf application until the node is rebooted and up
and running with the vnf application.
For vnfs that are cpu heavy, memory intensive,
and have high database transaction frequency, the
Ironic api service is important. This is because it
provides automated deployment and provisioning
of the vnf or any application on baremetal servers,
and removes the need for a hypervisor, which in turn
reduces operating costs and complexity.
Pluggable architecture
The main advantage of OpenStack is the pluggable
nature of its framework architecture. As visualized
in Figure 3, the flexibility offered by such an
architecture allows service providers to choose the
best backend solutions, which can be connected
through the appropriate plugin. Which vendor
plugin is most appropriate depends on the services
the cloud provider wants to offer, the infrastructure
being deployed, and the available vendor solutions.
Taking Neutron and Ericsson as an example,
an Ericsson Layer-2/Layer-3 solution would
use the Ericsson Neutron plugin. The pluggable
architecture offers OpenStack Neutron a way
to extend its functionality with more advanced
networking solutions, such as firewall, vpn, load
balancing and port mirroring, implemented as
standalone service plugins. In this way, networking
modules in Neutron can provide additional and
much needed functionality that can be selected
and included in the overall solution based on the
requirements of the service provider.
The Nova-Docker plugin has been recently
developed to support the deployment of Docker
48
containers via Nova Controller. While some
vnfs take advantage of containers, they are not a
complete replacement solution for vms or baremetal
deployment, but provide another deployment option
that is suitable for some applications. In fact, as more
lightweight container solutions — like Ubuntu’s lxd
— become available, the pluggable architecture of
OpenStack really comes into play. Deployment and
provisioning of the given container solution can be
achieved by simply adding the specific Nova plugin
and calling the OpenStack api to provision the vnf
with a specific deployment option.
The pluggable architecture is ideal for vnfs that
require specific networking configuration, such
as vlan trunking, or advanced network services
like Layer-3 routing, as they require dynamic
routing protocols to be provisioned in addition to
multiple virtual routers. However, support or full
implementation for such advanced services is not yet
included in OpenStack, illustrating some of the gaps
that remain to be fulfilled by Neutron to support all
nfv deployment and configuration scenarios.
What’s needed?
OpenStack provides an IaaS on-demand cloud
resource deployment and configuration service
that enables vnfs to be deployed quickly (within
a matter of minutes) on generic hardware through
automatic deployment and provisioning of vnfs in
a cloud environment. The benefits for nfv vendors
and service providers include:
〉〉faster time to market — reducing the typical lead time
from weeks to minutes;
〉〉elastic scaling of vnf services — which results in
maximum utilization of hardware resources and
reduces capex and opex;
〉〉support for various compute resources and flavors —
offering several deployment options such as baremetal,
containers, and hardware virtualization;
〉〉automated continuous deployment and rolling
upgrades; and
〉〉pluggable backends — allowing vendors and service
providers to provide innovative solutions based on
deployment and service needs.
As an open-source project, OpenStack is licensed
under Apache 2.0 and, as such, provides a basis
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A step toward efficient virtualization ✱
API NFV extensions
Neutron API
Standardized OpenStack northbound APIs
Nova API
Network service
Compute service
OS network
framework
OS compute
framework
Plugin
Plugin
Linux
WMware
ESXi
Swift
API
Cinder
API
Glance
API
OS storage
framework
Plugin
Plugin
Plugin
Keystone API
Heat
API
Ceilometer
API
OS Keystone
framework
Heat
engine
Collector
central
agent
Workflow
service
Events
Plugin
Plugin
KVM
Proprietary interface
Network connectivity
and virtualization
Compute
Storage
IDAM
(RBAC)
OpenStack
infrastructure
services
Physical infrastructure components
Figure 3 OpenStack functional architecture
to develop the necessary plugins to support the
provisioning and deployment of a large number of
vnfs, and to develop extensions to api services,
that are needed to support vendor and service
provider vnfs.
Future challenges
When OpenStack began in 2010, the target market
and predominant scenarios addressed by the
OpenStack community focused on traditional threetier web services and web content hosting. Such
services are typical for public clouds, as they are well
suited for deployment on endpoint ip servers with
a small db using a hypervisor-type solution. Over
time, the focus of OpenStack has evolved to include
support for:
〉〉telemetry services — Ceilometer;
〉〉an orchestration engine for infrastructure life cycle
management — Heat;
〉〉big data — through the Sahara project, which manages
#01, 2015
✱
Ericsson technology review
Hadoop clusters; and
〉〉advanced services in Neutron — such as remote vpn
access support, load balancing and firewall as a service.
In 2013, Ericsson and at&t started to drive
and include support for nfv through several key
contributions, such as vlan aware vms, vlan
trunking, dynamic logging, soft-affinity policy for
server groups in Nova and multi-vnic per vm. In
addition, Ericsson experts are core team members
in the Ceilometer and Barbican projects, as well as a
number of lead contributors in projects such as the
Telco Working Group and Nova in OpenStack.
However, a number of key features are still
needed to enable nfv to embrace OpenStack and
the infrastructure components it manages. This
is where the challenge lies ahead, together with
providing assurance that OpenStack does not
result in service degradation, and that it supports
the necessary configuration options to deploy vnf
49
✱ A step toward efficient virtualization
Additional Information
OpenStack community
and projects:
http://www.openstack.org
services from different vendors. For the moment,
further development of some critical features is
required before nfv services can be fully deployed
and provisioned to run reliably in a predictable and
deterministic manner.
One of the key features currently under
development relates to how Nova determines where
to place an application — specifically, the use case
where a vnf requires a cluster of machines, with
individual applications placed on different compute
blades. Such a setup can be achieved by setting the
ServerGroupAntiAffinityFilter policy. However, the
anti-affinity concept cannot be extended to network
and storage backends to address cases where the
vnf spans several storage pods. Currently, Nova
decides where a given vnf application should be
placed based on simple weights and filters; it does
not take into consideration, for example, that a vnf
should run on a specific blade with a dedicated
storage drive.
A critical feature missing from Neutron, for
example, is support for vlan trunking, which is
needed to deploy and configure vnf services, where
the vnf has selected its own vlan id — a typical
feature for infrastructure services — instead of using
the one assigned by Neutron. Support for vlan
trunking is available in some vendor solutions like
the Ericsson OpenStack cee distribution, making
the most of the flexibility of OpenStack to include
vendor additions.
Work is ongoing to provide Layer-3 services
in Neutron. This work is in the form of providing
support for provisioning and configuring dynamicrouting protocols, such as ospf and bgb — which
are used for load balancing, dynamic route
announcement and route distribution among vnfs
in a cluster — and mpls/bgv vpn — which is used
for inter data center vpn connectivity.
Yet another missing vnf service is the capability
to request provisioning and configuration for virtual
routers in tenant networks. Whileipv6 support has
been added in the last two release cycles — Icehouse
and Juno — feature parity with ipv4 still requires the
addition of a number of features. Similarly, a number
of capabilities are missing, including:
〉〉the ability to set QoS per vnf service per tenant;
50
〉〉fast detection and recovery of network faults at the
overlay layer;
〉〉port mirroring, which is used for purposes such as
troubleshooting; and
〉〉auditing and traceability services at the different layers
in the cloud stack.
Within the OpenStack community, Ericsson is
working on an implementation for port mirroring
under the TaaS project — contributing the source
code for the TaaS service.
Traceability tools are vital for locating service
failures at various points in large systems and for
recovering crashed services — particularly for
virtualization open source service components like
kvm and ovs that are managed and interfaced by
several different OpenStack components. Ericsson
and other industry players have added health checks
and watchdogs to OpenStack components (like
­libvirt) and layers (like kvm) outside the OpenStack
system, some pre-runtime and runtime checks still
need to be covered. For example, vnfs need to have
a no service interruption guarantee to enable carrier
grade services and fast failover detection.
To authenticate api calls, OpenStack uses rulebased access control and role-based access control
for authenticating user and tenant access within
the defined set of configured roles. Yet, a number
of threats remain, both in OpenStack and in the
underlay system — which OpenStack does not
control or manage. In the Juno release, support
for encrypting metadata traffic, via https, was
included. Some services such as boot attestation,
host attestation and firmware validation, tend
to be performed outside the management scope
of OpenStack. These services use, for example,
Intel’s Trusted Execution Technology (txt) to
ensure their trustability by storing hash values
on an attestation server. These values are then
queried, for example, after a baremetal blade has
been returned to the Ironic pool before being made
available to other tenants, to attest and verify that
hardware and software bios and firmware have
not been tampered with. This is an essential feature
for vnfs to ensure they are provisioned and run in
a secure environment. The ability to validate that
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
the authors
A step toward efficient virtualization ✱
VM
App
Bin/libs
Container
Container
App
App
Guest
OS
Alan Kavanagh
App
Bin/libs
Hypervisor
Bin/libs
Bin/libs
Host OS
Host OS
Host OS
Server
Server
Server
VM
Container
Baremetal
Figure 4 vnf deployment options
physical resources continue to operate as expected
is yet another essential feature. OpenStack lacks the
capability to check that resources are still functional
before providing them to a tenant. For example, the
ability to check that ssd drives are still functional on
assigned blades before the Ironic service allocates
them to a tenant is missing.
As an essential component for guaranteeing
service assurance, slas enable vnfs to run in a
predictable environment. As such, slas are an
essential element of assuring that vnfs run in a
deterministic environment, so that a dedicated
number of cpu cores (cpu core pinning) can be
assigned to vnfs, memory allocation is guaranteed,
and sufficient page table sizes are reserved
among other features one would require for
providing carrier-grade functional control for vnf
provisioning.
#01, 2015
✱
Ericsson technology review
Conclusion
OpenStack is still evolving and will take time to mature.
New features and extensions designed to address the
specific requirements of nfv in telco and enterprise
use cases will enable nfv services to be provisioned
and deployed. This will, however, require a number
of future releases. While some development work still
needs to be carried out by the OpenStack community
to support all the necessary features and ensure
that OpenStack is carrier grade, its extendable and
pluggable services framework provides vendors and
service providers with a flexible solution for interfacing
a multitude of plugins and backend solutions.
A large number of solutions may be developed to
suit service provider needs, and so a certification
program is required to ensure which plugins and
infrastructure blocks are connected and nfv
certified.
◆ Is a cloud system
architect expert working in
Development Unit Networks
& Cloud, Systems and
Technology. He has over 15
years’ experience in fixed
and mobile broadband
networks in the areas of
standardization, system
design and r&d. Over the
past number of years he has
been working on designing
and building innovative
solutions related to cloud
computing in the areas of
OpenStack, nfv and PaaS.
He holds a B.A. in computer
and electronic engineering,
and a B.A.I. in mathematics
from Trinity College Dublin
(tcd), Ireland.
51
✱ A blueprint for delivering media
architec
Setting the future
media services
The media industry is in a significant state of change, with new
players entering the market, exponential growth of media content, and
shifting user consumption patterns. A well-designed media architecture
that leverages ict evolution will enable the media industry to meet the
demands of the Networked Society, offering opportunities for all players
in the media value chain.
〉〉 Åke Gerd feldter
Pau l H iggs
Per Lj u n gb erg
Nilo M itr a
Mats Persso n
Like many others, the media industry can benefit from the efficiencies and savings of an
ict transformation — taking advantage of
commercially available it systems, networking equipment, and cloud-based services. As
we move deeper into the Networked Society,
media production and consumption will take on
a more prominent role in shaping requirements
related to network design and performance.
b u t j u s t w h a t is it that requires media
architecture to undergo such a transformation?
To start with, the proliferation of ott solutions
that carry content directly to users has led to
new consumption patterns, as people shift away
52
from watching scheduled programs to viewing
content when it suits them. In addition to changing
consumption behavior, the abundance of content is
causing media traffic carried by ip networks to rise.
The ability to deliver content through a cloud-based
service rather than as part of a vertically integrated
system has led to more efficient and scalable media
delivery solutions, as well as an increase in the
popularity of media-based services, with greater
demands to deliver content customized to the user’s
anytime, anywhere environment.
These are just some of the changes taking place in
the media landscape, causing architects to rethink
their approach to designing solutions for more users,
more content and more efficient delivery.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A blueprint for delivering media ✱
ecture
Media industry trends
Traditional business models in areas from content
creation to distribution and consumption are
changing the face of television, or more broadly,
media entertainment services.
Subscribers are consuming greater quantities of
data, largely fuelled by increased viewing of online
video. Video-centric experiences are becoming
more central to people’s interactions; users have
more devices, a wider range of devices, and view
content for longer. People are personalizing
experiences to match their current environment in
terms of mood, location, time of day, and so on.
New devices with larger and higher-resolution
screens have caused a rise in the number of streams
delivered using both fixed and mobile access, as well
as an increase in the average bitrate per stream.
Today, there is an almost unlimited variety
of content and information available for public
consumption. How media consumers, Millennials
in particular, watch video is changing, moving away
from scheduled tv to consuming content when
it suits them, and from a much wider variety of
sources like YouTube and Twitter, as well as media
embedded in almost any digital stream — such as a
blog or social platform. Traditional broadcast tv is
increasingly being viewed in catch-up mode, forcing
#01, 2015
✱
Ericsson technology review
industry players to rethink traditional business
models based on advertising.
The proliferation of video-capable devices, editing
suites, and platforms that enable instant upload
and dissemination of content have also changed
people’s behavior: from primarily being consumers
of content to also being producers of content.
Portals like YouTube provide a simple means to
share content, with increasing capabilities to create
semiprofessional quality videos, as well as providing
revenue sharing and analytics. The resulting massive
growth in content from both new and previously
existing sources, together with the ubiquitous nature
of search, has created a shift in traditional television
electronic program guides (epgs) from being timeand channel-based to being more interactive. Today’s
epgs, more aptly called interactive program guides
(ipgs) are enhanced with recommendations derived
from personal preferences — moods, social trends,
and viewing habits — making the overall media
experience a richer and more personalized one.
The rise in consumption of content using ott
services places new capacity and performance
demands on the ip infrastructure, and has led to the
creation of technologies such as http-based adaptive
bitrate (abr) and improved encoding techniques
that are converging on a few standards, including
53
✱ A blueprint for delivering media
mpeg-dash and hevc/h.265. The combination
of these techniques, hardware adapted for media
processing, a wide range of new types of devices,
falling storage costs, higher broadband speeds and
other cost/performance gains has resulted in video
distribution and consumption appearing in many
new environments.
Cost-efficient ip-based networking offers a
replacement to the traditional method of connecting
equipment in media production and distribution
centers with sdi-based coaxial cables. Already
today, content producers can provide a broadcaster
with video and other forms of pre-edited material
as standardized files over ip connections, instead
of tape cartridges delivered by truck. Within
a production facility, content, distributed over
an ip network in a well-defined format, can be
edited, transformed and stored using increasingly
standardized equipment, moving away from vendorspecific formats and tools.
The market conditions that these trends —
content growth and viewing patterns, mobility, ict
transformation and new business models — create
has led to the need for an open media architecture
that can accommodate new technology in a flexible
way and enable an all-ip based media ecosystem.
Architecture
An end-to-end media architecture allows multiple
vendors and solution providers to integrate their
offerings in any part of the media value chain,
without disrupting or degrading overall solution
capabilities.
Such an architecture is critical to maintaining
a viable media ecosystem, and while no single
organization can fully define all of its aspects, the
exercise of creating such an architecture has shown
that taking advantage of the ongoing transformation
in ict to manage market evolution results in more
efficient and scalable solutions for all actors in the
media value chain.
The media services architecture Ericsson
has designed uses a component-based model.
The resulting environment is loosely coupled;
deployment- and integration-time-aware with selfcontained functional components that are flexible
(easy to replace or update) and reusable. Control is
carried out through orchestration and workflows
that determine which functions to invoke and when
to invoke them in the content distribution and
delivery process.
The media services architecture is partitioned
into three different planes for separation of concerns,
with each plane hosting one or more functional
components, as shown in Figure 1.
Business support and operations
The top plane of the architecture contains the
functional components that manage business
flow as well as the operation of media services.
Included in this plane are oss/bss functions that
support operation, fulfillment, assurance and
billing of the underlying media functions and
services, as well as functions to provide network
and consumption analytics.
Media control and information
This plane contains the functional components that
orchestrate media flows, holds the metadata and
policy information to describe them, which is in turn
used to guide orchestration. These components
are key functions of the architecture. They enable
much of the network configuration to be automated,
provide abstraction from details, and control
the media flow from creation to consumption.
Orchestration components are data driven, using
Terms and abbreviations
abr— adaptive bitrate | cdn— content delivery network | http— Hypertext Transfer Protocol | hevc— High
Efficiency Video Coding | isp— internet service provider | mpeg-dash— mpeg Dynamic Adaptive Streaming over
http | mpls— multi-protocol label switching | ott— over-the-top | SaaS— software as a service | sdi— Serial
Digital Interface | sdn— software-defined networking | stb— set-top box | VoD— video on demand
54
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A blueprint for delivering media ✱
OSS/BSS
(Operation, fulfillment, assurance, billing)
Analytics
(Network, consumer)
Business support and operations plane
Metadata and policies
(Catalogs, DRM/CA, recommendations...)
Orchestration and workflows
(Content management, multiscreen control...)
Media control bus
Media control and information plane
Media resources
(Capture/playout, transcoding, respository, delivery, mobile broadcast...)
Media infrastructure (high bandwidth, low latency)
Media processing and delivery plane
network data, policies and metadata, which can be
predefined or carried with the content, to manage
the full life cycle of a tv or vod service.
Media processing and delivery
This plane contains functional components that
operate directly on media resources such as
transcoding, storage and streaming — all of which
are connected by a mediaipinfrastructure.
The components of each plane are defined as
virtual functions so that they can be deployed
in a cloud environment. The component-based
architecture, together with well-defined interfaces
between the components, enables the deployment
to be distributed, with some components residing
in a private cloud communicating with others
deployed in a public cloud (or another private cloud).
Legacy non-cloud functional components are also
#01, 2015
✱
Ericsson technology review
Figure 1 The media services
architecture
supported, but are not dynamically scalable, as they
lack the elasticity provided by a cloud infrastructure.
The orchestration and workflow functions, which
are central to the deployment of this architecture,
control which media resources to invoke in the
media flow via the media control bus. This approach
provides a flexible abstraction toolkit for the rapid
creation of services in response to new demands,
such as the automated deployment of a new tv
channel or vod service.
In simple terms, content flows through the media
services architecture by first entering the media
infrastructure as ip packets and then, subject to
orchestration workflows, makes its way from one
media resource function to another for transcoding,
storage, and other media operations before finally
being delivered to the user device for consumption
over ip, or as a traditional broadcast.
55
✱ A blueprint for delivering media
Production
Aggregation
Service provisioning
Delivery
Consumption
Terrestrial
AD
agency
STB
Studios
Satellite
Smart TV
News gathering
IP
network
Aggregator
Event coverage
Content
owner
Cable
Roles
Laptop
Wireline
Media service
provider
Smartphone
Mobile
User generated
content
Content creator
Network operator
Tablet
User/
device
Content provider/broadcaster
TV operator
Content producer
Actors
Consumer
OTT content aggregator (new aggregator)
Figure 2
The end-to-end media
services value chain and
associated roles
Roles and actors
The media architecture supports a media services
value chain from an end-to-end perspective, which
can be divided into a set of roles and actors, as
illustrated in Figure 2.
As shown in Figure 2, the media services
value chain consists of five phases: production,
56
aggregation, service provisioning, delivery, and
consumption. To perform their tasks, actors within
this chain may take on one or more of the defined
roles, with actors in each role performing a specific
set of functions.
The first phase of the media services value
chain is production. During this phase, producers,
such as movie studios or production companies,
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A blueprint for delivering media ✱
create, edit and package content into commercial
offerings. The roles related to this phase are content
creator and content owner. Producers can be both
content creator and owner for their material —
which tends to be the case for movie studios. Or
a producer may contract out the production and
distribution of material while retaining ownership
rights — coverage of a professional sports league,
for example, often falls into this category. On the
basis of a business agreement, a content owner
contracts out distribution to an aggregator or a
media services provider.
Aggregators, typically broadcasters, movie
aggregators and sports networks, purchase content
rights from the content owners, and compile the
acquired content into commercial bundles comprised
of live feeds, such as traditional tv channels or offline content such as films or tv archives. These
bundles can then be made available for purchase and
distributed to media service providers. Advertising
slots, bought by media agencies, can also be
introduced into content by the aggregator.
Media service providers operate in the serviceprovisioning phase, packaging and offering
acquired content as services to consumers — either
as a part of paid subscriptions, as free over-the-air
broadcasts or on a pay-as-you-go basis. Content
is offered to consumers through a multiscreen
portal, which also provides recommendations,
detailed program information, and mechanisms for
purchase and payment, as well as a means to select
the content to be viewed or recorded. Media service
providers offer Pay-tv services to consumers
through subscriptions, while paying carriage fees
to broadcast channel aggregators for their content.
Traditionally, some media service providers have
also played the role of network operator, providing
managed networks — such as cable, fiber, or dsl —
for the delivery of their services.
New entrants to the media-service-provider
arena offer ott services directly to consumers
with no association to a specific access network,
but instead rely on the consumer’s existing isp for
delivery of content, leveraging global cdns. Such
media service providers may pay network operators
for delivery assurance.
#01, 2015
✱
Ericsson technology review
Packaged content is delivered to consumers via
a network operator using cable, satellite, terrestrial,
mobile or wireline access networks, in exchange
for usage and/or subscription fees or as free-toair broadcasts. Network operators may, subject to
agreement with a media service provider, ensure
delivery of content with QoS guarantees by applying
technologies like unicast, multicast, broadcast, abr
and caching networks.
Users — which may be an individual, a household,
a hospitality service (hotels and events), or an
enterprise — consume media services over
connected devices. Consumers can view content
as free over-the-air broadcasts or as Pay-tv
content from media service providers in exchange
for subscription fees and/or fees for on-demand
viewing. Viewing can be multi-platform (Android,
ios, rdk, and so on) and multiscreen on an stb ,
smart tv, smartphone, or tablet.
Applied architecture
When the roles and the media architecture are
brought together, the result — as shown in Figure 3
— is an applied architecture design, with each
role instantiating a portion of the media services
architecture. In addition, some roles share selected
media resources, such as transcoding and storage,
with other roles. In cases where an actor performs
multiple roles, a single instance of such a resource
will suffice. Implementations of the media services
architecture will take full advantage of functions and
infrastructures that are delivered as services rather
than as features of vertically integrated systems.
The network operator provides media delivery
over different network types (such as cable, satellite,
and mobile). The network that the media service
provider selects depends on both business and
technical considerations, such as subscription data,
type and location of device, and network capabilities.
Individual networks are further optimized with
technologies such as caching, multicast and mobile
broadcast. The network operator has no explicit
control plane, as the control information is carried
over the media plane in terms of manifest files
for abr-based delivery and decryption keys for
terrestrial or satellite delivery.
Ad agency: performs
media advertising buys
on behalf of a brand
(advertiser).
Content creator:
performs live event
capture, movie and tv
show creation, and postproduction of video
content.
Content owner: stores
and archives content
as well as generating
metadata to describe it.
Aggregator: performs
functions like translation,
dubbing, encoding,
compression, quality
control, digital rights
application, and
watermarking.
Media service provider:
performs packaging of
content into suitable
delivery formats to
support abr, and applies
content protection to
premium content before
delivery. Advertisements
may also be inserted or
replaced in the media
content as part of the
packaging process.
Network operator:
ensures delivery of
content with QoS
guarantees by applying
technologies such
as unicast, multicast,
broadcast, abr, and
caching networks.
User/device: provides
the media client used for
content consumption.
57
✱ A blueprint for delivering media
Content
owner
Aggregator
Media service provider
Analytics
Analytics
OSS/BSS
OSS/BSS
Business support
and operations plane
Metadata
and policies
Metadata
and policies
Orchestration
and workflows
Orchestration
and workflows
Orchestration
and workflows
Media
control bus
Media
control bus
Media
control bus
Terrestrial
access
Satellite
access
Media control and information plane
Shared network
resources
Media
source
Network
operator
Media
resources
Media
resources
Media
client
Analytics
Cable
access
OSS/BSS
Media
resources
Fixed
access
Media
infrastructure
Media infrastructure
Media infrastructure
Media processing and delivery plane
Radio
access
User/
device
Figure 3
Media services
applied architecture
OSS/BSS
(Operation, fulfillment, assurance, billing)
OSS/BSS
(Operation, fulfillment, assurance, billing)
Analytics
(Network, consumer)
Metadata and policies
(Catalogs, DRM/CA, recommendations...)
Metadata and policies
(Catalogs, DRM/CA, recommendations...)
Orchestration and workflows
(Content management, multiscreen control...)
Orchestration and workflows
(Content management, multiscreen control...)
Media control bus
Media control bus
Media control and information plane
Media control and information plane
Media resources
(Capture/playout, transcoding, respository, delivery, mobile broadcast...)
Media resources
(Capture/playout, transcoding, respository, delivery, mobile broadcast...)
Media infrastructure (high bandwidth, low latency)
Media infrastructure (high bandwidth, low latency)
Media processing and delivery plane
Media processing and delivery plane
Private
cloud
Analytics
(Network, consumer)
Business support and operations plane
Business support and operations plane
Broadcaster
Private
cloud
TV operator
SaaS
Media resources
Media resources
IP media pipe (high bandwidth, low latency)
Media processing and delivery plane
IP media pipe (high bandwidth, low latency)
Media processing and delivery plane
Public
cloud
Figure 4
Example of media services
deployment
58
Media resource
Network/Edge
resources
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
A blueprint for delivering media ✱
Deployment architecture
The deployment architecture — the physical
instantiation of the applied architecture — is based
on a cloud infrastructure.
Actors are likely to have their own private,
public or hybrid cloud instances for hosting
media architecture functions. In the example
deployment architecture illustrated in Figure 4,
the broadcaster operates a private cloud for many
media functions but also uses a SaaS offering in a
public cloud for transient tasks like transcoding
and for static functions such as media storage. tv
operators have a similar setup and can exchange
content more efficiently if their SaaS instances
are deployed within the same data center. In
the example illustrated, the SaaS provider has
no media control and information plane, nor a
business support and operations plane. However,
it is equally feasible in a SaaS model to provide
all layers of the media architecture, in essence
offering the whole media architecture as a
software service.
The ip-based media transport leverages an
sdn-controlled infrastructure1, in which the ip
networking characteristics of layers 2 and 3 are
dynamically configured and reconfigured to suit the
needs of the media transport between resources.
Content is either packaged as files, mainly for
on-demand content, or as streams for live or linear
content. Both cases are managed and individually
Roles and
optimized
for actors
cost and efficiency.
Cloud data center interconnections within and
between different actors create requirements for
secure and efficient connections. The physical
interconnections between clouds are typically
carried by an mpls vpn connection, set up to fulfill,
for example, the necessary requirements in terms of
bandwidth and latency.
Media resource functions often handle large
volumes of media content, which places specific
requirements on the cloud environment for storage
(petabyte capacity and high i/o bandwidth), ip
infrastructure (high bandwidth and low latency),
and potentially hardware-accelerated transcoding
based on graphics processors or dedicated
hardware.
#01, 2015
✱
Ericsson technology review
An all-IP world
the rise in
An all-ip architecture
consumption of content
requires transport
protocols to be
using OTT services places
transformed to
new capacity and
ip. In production
and distribution
performance demands on
environments,
both baseband
the IP infrastructure
(uncompressed raw
video format) and
slightly encoded and
compressed, but still production quality, mezzanine
formats (for example, smpte 2022:6 and jpeg2000based mezzanine formats respectively) will be
encapsulated and carried over ip networks, replacing
existing sdi transport. Baseband formats are
primarily applicable to post-production, while the
mezzanine format is used for further distribution.
Baseband and mezzanine formats carried over ip
transport will need to be transformed for delivery over
traditional non-ip-based broadcast networks. Even for
further ip-based distribution, media in these formats
will need to be transcoded for abr delivery.
Delivering content to consumers over ip is
rapidly becoming standard, as providers of ott
content promote technologies that offer better
user experience and network efficiency. The
media services architecture enables a highly
scalable, robust, secure and efficient environment
for the delivery of live/linear tv and vod content
to consumers connected via fixed or mobile ip
networks. Providing optimized service delivery is
enabled through a unified delivery mechanism that
delivers content to users over all access networks,
including ip unicast and multicast of fixed and
adaptive rate streams, and broadcast over lte and
Wi-Fi networks.
With the owners of 15 billion video-capable
devices eager to consume content over new access
technologies like 5g, a need will arise for a mediacentric ip-based transport protocol to overcome the
limitations of protocols developed for information
exchange purposes (such as: e-mails, instant messages,
and images), which are less suitable for the always
connected, always streaming Networked Society.
59
✱ A blueprint for delivering media
Conclusion
Media production and consumption is a
fundamental aspect of the Networked Society
and will shape requirements related to network
performance, and provide new business
opportunities for all actors in the media services
value chain.
The changing environment created by ott
players, with consumer behavior shifting from
scheduled programming to on-demand viewing,
creates new requirements for tomorrow’s media
architecture.
Meanwhile, the media industry is transforming,
benefiting from the use of commercial it-based
functions and infrastructures that enable media
services to be delivered as cloud-based services
rather than as features of vertically integrated
systems.
Creating media offerings based on the
architecture described in this article brings
advantages for both media service providers and
their peer network operators, allowing new services
to be introduced without changing upstream
processes or disrupting services that are already in
operation. Such offerings include network-based
digital video recording, personalized advertisement
insertion and transparent internet caching, which
can be implemented on the same media processing
and control planes, yielding service differentiation.
Implementations derived from this media
architecture will leverage ict industry
technologies, with products and solutions that
are component-based, cloud-deployable, and allip to provide a scalable and open ecosystem for
multivendor component integration.
References
1) Ericsson Review, February 2013, Software-defined networking: the service provider perspective, available at:
http://www.ericsson.com/news/130221-software-defined-networking-the-service-provider-perspective_244129229_c
OSS/BSS: handles the
operation, fulfillment,
assurance, and billing
of media functions and
services.
Analytics: collects,
processes, analyzes
and visualizes data
available from all the
functional components
for use in network
routing control, content
recommendation, ad
placement decisions,
business management,
and network planning.
60
Metadata and
policies: provide
information services
to other functions,
such as content
catalogs and program
guides; subscriber
and subscription
data, including
entitlements; and content
recommendations.
Orchestration and
workflows: provide
functions to control
content processing and
service control of the
media flow from ingest
to delivery, as well as life
cycle management and
chaining of the functional
components.
Media control bus:
the integration
framework that
provides a lightweight
communication
framework, including
a resource manager
for proper resource
allocation, sla
management, and
security functions.
Media resources:
perform processing
such as encoding,
transforming, storage,
caching and distribution
of the media content.
Media infrastructure: an
IP framework optimized
for transport of large
volumes of content with
high bandwidth and low
latency.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Xxxxxxxxxx:
the authors
A blueprint for delivering media ✱
Åke Gerdfeldter
◆ Is an expert in messaging
and multimedia at
the Media Systems &
Technology unit, Solution
Area Media, Business Unit
Support Solutions. He
joined Ericsson in 1986,
working with messaging
solutions as a developer
and chief architect. He
holds the patent for
Ericsson’s enriched
messaging architecture
described in Ericsson
Review 2007:02. More
recently, he has worked
with system studies for
media products such as
the Multi-service Proxy
and the Media Delivery
Network solution, as
well as coordinating the
definition of the overall
media architecture.
standardization within
various television and
media-related standards
organizations such as the
HbbTV Association, w3c
and rdk Management. He
joined Ericsson in 1992 and
has held several positions
including technical sales,
product engineering and
r&d.
Nilo Mitra
#01, 2015
✱
Ericsson technology review
Per Ljungberg
◆ Is head of the Media
Systems & Technology
unit, Solution Area Media,
Business Unit Support
Solutions. He joined
Ericsson in 1990 and has
worked with software
◆ Is an expert
standardization architect
for media solutions at
the Media Systems &
Technology unit, Solution
Area Media, Business Unit
Paul Higgs
◆ Is a senior specialist
in media technologies
at the Media Systems &
Technology unit, Solution
Area Media, Business Unit
Support Solutions. He
currently works with media
technology innovation and
He serves on the board of
the HbbTV Association,
and was a founder of the
Open IPTV Forum. Mitra
has participated in many
standardization fora
including W3C, oasis,
WS-I.org, OMG, itu-t,
iso and the oma. He
joined Ericsson in 1998,
after 15 years at AT&T Bell
Laboratories, and holds a
Ph.D. in theoretical physics
from Columbia University,
New York.
Support Solutions. In his
current role he coordinates
Ericsson’s participation
in various media-related
standards organizations.
development and systems
architecture for mobile
systems (GSM/UMTS)
in R&D positions in
Stockholm, Sweden and
at Ericsson Eurolab in
Aachen, Germany. In his
current role, Ljungberg
is responsible for system
studies of media delivery
optimization in wireless
systems, Ericsson’s media
systems architecture,
and technology studies
related to all aspects of the
media delivery chain. He
holds a M.Sc. in computer
science from the Linköping
University, Sweden.
Mats Persson
◆ Is a senior specialist in
systems architecture
at the Media Systems &
Technology unit, Solution
Area Media, Business
Unit Support Solutions.
Currently, he is working
with the evolution of
TV and media systems
architecture, focusing on
overall design, analytics
and bss/oss integration.
He joined Ericsson in 1988,
and has previously worked
with system management
in telecommunication
services, mobile systems,
service layer and service
enablement platforms. He
holds an M.Sc. in computer
science from Linköping
University, Sweden.
61
✱ Carrying IMS voice and video calls over Wi-Fi
Wi-Fi
calling
Extending the reach
of VoLTE to Wi-Fi
Using untrusted Wi-Fi to carry voice and video communication is an
open opportunity for operators to extend volte/vilte services in, for
example, indoor locations where cellular coverage may be spotty.
〉〉 Len nart N o rell
An d ers Lu n ds trö m
Håk an Ös terlu n d
H en rik J o hansso n
Daniel Nilsso n
Operators worldwide are currently launching
ims-based voice and video calling over lte
(volte and vilte) services, supported, for the
moment, by about 70 commercially available
mobile devices. Recently, a new technology
was developed to carry voice and video calls
over Wi-Fi. This solution, referred to as Wi-Fi
calling, extends volte by including support
for Wi-Fi as an additional access type for both
voice and video calls.
w i - f i c a l l i n g i s closely aligned with
volte; it uses the same ims telephony client, and
supports mobility between lte and Wi-Fi accesses,
making the resulting user experience a seamless one.
Handover of calls between lte and Wi-Fi is enabled
by routing Wi-Fi calling traffic to the ims through
the Evolved Packet Core (epc), which results in
62
a scalable deployment opportunity for network
operators.
As illustrated in Figure 1, Wi-Fi access can be
used for telephony services for several subscriber
and enterprise scenarios. However, the bulk of
current implementations and the primary use
case for Wi-Fi calling is to complement indoor
environments where cellular network coverage
is limited. This use case may also apply to small
business premises. Operators are also considering
using this technology to provide users, traveling
outside their home network, with access to the
ims telephony services of their home network over
Wi-Fi networks that are commonly found in hotels,
airports, shopping malls and cafés.
Wi-Fi calling offers users a simple solution for
voice and video calls — one that is fully integrated
with modern smartphones and does not require
any additional apps or downloads. As such, the
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Carrying IMS voice and video calls over Wi-Fi ✱
introduction of Wi-Fi calling is expected to have an
impact on the use of ott Voip solutions, as well as
fixed telephony offerings.
The architecture
As illustrated in Figure 2, the Wi-Fi calling solution
follows the same architecture blueprint as volte,
except for the introduction of an epdg node in
the epc. Some modifications to the ims are also
necessary to handle the different nature of Wi-Fi
compared with lte and cs accesses.
The Wi-Fi calling solution is an extension of the
epc architecture and allows any Wi-Fi network to
be used to access the epc, which the 3ggp standard
refers to as untrusted accesses. The epdg node at
the border, which can be found by a device through
a dns lookup, acts as the gateway between the
public internet and the rest of the operator’s epc.
To connect to the epdg over the Wi-Fi/internet
connection, a device uses the ietf protocols ikev2
and ipsec. These protocols provide the connection
with integrity and confidentiality, implying that any
type of internet connection, even an open Wi-Fi
hotspot, can be secured.
The ikev2 protocol uses the credentials stored
on the sim card to automatically set up the ipsec
tunnel between the device and the epdg. As a
result, no additional action is required by the user,
which enhances the seamless experience. The
epdg gateway fetches the security keys/vectors
and subscription information from the hss via an
aaa node.
During the setup of the ipsec tunnel, the epdg
gateway connects to the pgw using the gtpv2
protocol over the s2b interface. To obtain static and
dynamic policies, the pgw uses Diameter signaling
(over the Gx interface) to the pcrf in the same
way as it does for 3gpp accesses. Consequently,
applications like the ims can set up dynamic policies
(over the Rx interface) in the same way as they do for
lte access.
When a handover takes place between lte and
Wi-Fi, the device retains its ip address, and any
policies assigned to the connection will remain intact.
Using this solution, the choice of access technology
(Wi-Fi or lte) used to carry the voice/video call is
transparent to both the user and the ims, except for
some minor differences in the way call termination
and location-based services are handled.
For call termination, the ims network applies
Terminating Access Domain Selection (tads) to
determine whether to terminate a call in ims or to
break out to cs. As devices supporting Wi-Fi calling
have dual radios — one for cellular and one for Wi-Fi
— a device may be simultaneously attached to both
networks, which makes tads more complex. The
ims system needs to keep track of when a device
uses Wi-Fi calling for the ims service, so that a call
remains in ims — even when cellular access for
volte calls is not available.
For location-based services, Wi-Fi is different
from cellular in that it does not use a Cell-id to
assist in positioning. Consequently, location-based
services cannot work in the same way over Wi-Fi
as they do over lte, unless position information is
adopted or provided by some other means.
Terms and abbreviations
aaa: authentication, authorization and accounting | apn: Access Point Name | cs: circuit switched | csfb: cs
fallback | dsl: digital subscriber line | epc—Evolved Packet Core | epdg: Evolved Packet Data Gateway |
fmc—fixed-mobile convergence | gtpv2: gprs Tunneling Protocol version 2 | hss—Home Subscriber Server |
ikev2: Internet Key Exchange version 2 | ipsec: ip Security | ott: over-the-top | pcrf: policy and charging rules
function | pgw: packet data network gateway | pots: plain old telephone system | sip: Session Initiation Protocol
| stb: set-top box | tads :Terminating Access Domain Selection | vilte: video over lte | voip: voice over ip |
volte: voice over lte
#01, 2015
✱
Ericsson technology review
63
✱ Carrying IMS voice and video calls over Wi-Fi
Home Wi-Fi
access point
Wi-Fi access point
Wi-Fi access point
Access to operatorprovided services,
when roaming
3GPP access
Homes with limited
3GPP coverage
Small office/
business with
limited 3GPP
coverage
Seamless handover
of voice and video
calls between LTE
and untrusted Wi-Fi
Outside
home
network
Figure 1
Wi-Fi calling in practice
Signaling
Payload
3GPP
Macro
3GPP
Micro
3GPP
Pico
3GPP
radio
access
S5/S8
Gx
Rx
PCRF
IMS system
SGi
Public/
Internet DNS
PGW
DNS
S2b
IEEE
802.11
Internet
Figure 2
Wi-Fi calling architecture
64
IPsec/
IKE
Wi-Fi
AP
IPsec/IKE
ePDG
AAA/
DNS
HSS
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Carrying IMS voice and video calls over Wi-Fi ✱
Key use cases
Extending coverage
Currently, the main driver for deploying voice and
video calling over Wi-Fi is to extend the reach of
volte services in situations where there are gaps
in cellular coverage. As shown in Figure 3, holes can
occur in indoor environments such as suburban
homes, but they also arise in densely populated
areas where, for example, the use of energy-efficient
building materials makes indoor coverage difficult.
Typically, Wi-Fi calling uses an existing Wi-Fi
router at a customer’s premises. And now, the main
smartphone manufacturers have started to include
native device support for use of unmanaged Wi-Fi to
access the same ims voice service as in lte (volte).
This allows operators to offer Wi-Fi calling as a
complement to volte in locations with coverage
issues. This is a better option than, for example, a
femtocell, which would require the installation of a
dedicated femto base station, incurring significant
installation and maintenance costs.
For vilte, coverage issues are more accentuated,
as video calling demands greater network capacity
than voice. In unfavorable conditions, video calls
may only be possible over Wi-Fi (even if voice calls
can be carried over the cellular lte network).
Subscribers may also want to force a video call over
the Wi-Fi network if the traffic generated is counted
as part of their data bucket.
Wi-Fi calling can thus be used as a complement
to volte, allowing operators to launch ims-based
voice and video calling — even early on in the
process of building out lte coverage — providing
an enhanced user experience compared with cs
fallback (csfb). Operators need to be able to control
when a voice service should be carried by the
cellular network or be provided over Wi-Fi. This is
particularly significant when it comes to supporting
emergency calls over Wi-Fi. Devices can be steered
to use the cellular network in such cases, but if Wi-Fi
is being used to provide a voice service when cellular
coverage is unavailable, then provisions for handling
emergency calls over Wi-Fi are needed.
Beyond the home network
As Wi-Fi calling connections are routed over
#01, 2015
✱
Ericsson technology review
the open internet, provided
connectivity is available,
subscribers can reach their home
whatever
operator network from anywhere.
access technology –
This capability provides operators
with a solution to offer voice
Wi-Fi or LTE — is used
services outside of the home
to carry voice or
network free of roaming charges,
using a device’s native telephony
video calls is
client. In other words, users will
transparent to the
not have to install any additional
applications when traveling
user and the IMS
outside the reach of their operator’s
home network, and using their
mobile device will be no different
than if they were within reach.
Handover between lte and Wi-Fi is not possible
today but specification work is ongoing to enhance
this area with support for Wi-Fi in visited networks
— in a similar way to volte.
Operators can also manage the use of Wi-Fi
calling in certain countries to align with local
regulations. However, emergency calls should never
be carried over the home network, as such calls
must be routed to the local emergency services.
Legal aspects related to the interception of calls by
national authorities may also come into play, as all
traffic between the device and the home operator
will be encrypted.
Fixed mobile convergence
Wi-Fi calling offers fmc operators new opportunities
to create broader and smarter bundles for subscribers.
Today, many households using fixed broadband
services also have a fixed phone extension (home
number) delivered as a fixed broadband Voip service
or as a traditional pots. With the introduction
of Wi-Fi calling, the home number could be
complemented, so that incoming calls to the home
number would forward to a number of mobile
phones (used by the household occupants).
Other types of combined cellular and Wi-Fi
devices such as tablets and set-top boxes (stbs)
could also have the ims client and access the
volte service using epc integration, and could
also be alerted of calls to the home number. Such
65
✱ Carrying IMS voice and video calls over Wi-Fi
Cellular coverage
Video range
EPC
IMS
(VoLTE)
ePDG
eNB
IPSec
Internet
IPSec
Figure 3
Coverage holes in indoor
environments
66
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Carrying IMS voice and video calls over Wi-Fi ✱
Figure 4 Wi-Fi calling
Other devices
Mobile phones
Wireline devices
Small enterprises (10–15 users) can start using
mobile phones instead of fixed phones
Upgrade to a modern phone
experience in the small office
• One phone number
• One address book list
Video calling capabilities
on Android phones
iOS8 and Android
support
Figure 5 Wi-Fi calling for small
business users
#01, 2015
✱
Ericsson technology review
67
✱ Carrying IMS voice and video calls over Wi-Fi
household offerings, in which multiple devices and
subscriptions are bundled to cover the needs of all
household members, will help to increase operator
stickiness and reduce churn.
Small office application
Small enterprises tend to use dsl or fiber through a
single access point to connect the internal network to
voice and managed-data services, using a variety of
sip phones.
Wi-Fi calling enables mobile operators to address
the fixed business by means of a fixed-mobile
substitution. With this solution, users can retain
their well-known fixed extension yet upgrade to
Wi-Fi calling and replace their existing fixed phones
with smartphones that can also be used outside the
business location.
This solution also enables the many advanced
voice and video calling features, such as short
numbers, possible through ims to be directly
applicable to enterprise users, enabling them to
enjoy the experience of a modern smartphone
within the context of enterprise telephony. Special
care, however, needs to be taken, as the unlicensed
nature of Wi-Fi imposes limitations on the number
of devices that can use a single Wi-Fi access point.
Limitations
There are numerous challenges when it comes to
providing quality voice and video calling over Wi-Fi.
The ability to predict or control the performance
of a service over Wi-Fi is limited. Users install the
Wi-Fi access point, and the resulting voice service
quality depends on how well the Wi-Fi network
performs. Wi-Fi calling works well in favorable
Wi-Fi conditions but issues may arise in scenarios
with interference from neighboring access points, if
the Wi-Fi network is already heavily loaded, or if the
access point covers a large building. In such cases, a
better Wi-Fi router may need to be installed.
While recent generations of Wi-Fi technology,
such as 802.11n or 802.11ac, enable higher data
transfer rates, this does not necessarily solve the
issue of voice quality; carrying voice over Wi-Fi
relies less on bandwidth and more on a reliable and
consistent packet delivery between the device and
68
the access point. Techniques that can prioritize
real-time media over ordinary data can make a
difference, but as media and signaling are embedded
in an ipsec connection, it is not obvious that
standard techniques will work.
Seamless handover in Wi-Fi calling is only
supported between Wi-Fi and the cellular lte
network. If multiple access points support a location,
then mobility within the loc ation is restricted by
device and access point capabilities. Typical home
Wi-Fi networks tend to exhibit stickiness: a device
will stay on a weak Wi-Fi connection even when a
better link is availble through another access point.
As Wi-Fi access does not provide for network
location information, the preferred option for
emergency calls is to carry them over cellular access
whenever possible. If Wi-Fi is used where no cellular
coverage is available, emergency calls may be
carried as normal calls. Location can be obtained,
for example, through the registered address for the
home Wi-Fi access point.
Emergency calls for roaming users using Wi-Fi
present a particularly challenging scenario. If the
local emergency number is recognized by the device,
it will itself request an emergency apn that will use
the visited cellular network.
If, however, the number is not recognized by
the terminal, it is the task of the home network ims
to force the device to leave Wi-Fi and establish
the emergency call in the visited network. This
implies that the ims network must be able to detect
emergency numbers for all locations where roaming
using Wi-Fi is enabled.
Conclusion
The Wi-Fi calling solution enables operators to
extend the use of ims-based volte services to
include carrier supported Wi-Fi calling using a
residential Wi-Fi network.
Wi-Fi calling can be used to address indoor
coverage issues — effectively removing the need
for residential femto or app-based solutions.
Furthermore, Wi-Fi calling provides service for
roaming users, as well as offering a means to provide
small enterprises with telephony services.
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
the authors
Carrying IMS voice and video calls over Wi-Fi ✱
Håkan
Österlund
◆ Is a senior specialist
for ims solutions with
focus on access-specific
functions and is a member
of the dunc telephony
evolution team. He has
been working in different
areas at Ericsson since
1984 and with ims based
telephony solutions since
2001. He studied computer
science at the Institute of
Technology at Linköping
University, Sweden.
Anders Lundström
◆ Joined Ericsson in
1999, initially working in
3G packet core system
management. He currently
works in Product Line
Packet Networks as a
#01, 2015
✱
Ericsson technology review
strategic product manager
for epc. In this role, he
is responsible for virtual
epc and convergence
strategies for Wi-Fi
integration as part of
Ericsson’s overall epc
offering. Previously, he
was key lead for Ericsson
in the development of a
3gpp2 migration path
lte/epc, and he has spent
several years working in
the us in various product
management positions.
Daniel
Nilsson
◆ Joined Ericsson in 2000
and is a system manager
at Product Development
Henrik Johansson
◆ Is a product manager in
IMS, responsible for the
volte solution. He has
several years of experience
working with voice and
communication evolution,
stretching from Voice
over atm in the late 1990s,
followed by Softswitch, and
more recently with volte.
Lennart Norell
◆ Joined Ellemtel in 1977 to
work on the development
of Ericsson’s AXE system.
He moved to Ericsson in
Unit Packet Core Systems
& Technology. His area
of expertise is in packet
core integrated Wi-Fi, and
he has worked across the
organization with technical
aspects of the Wi-Fi calling
solution. He holds an
M.Sc. in computer science
from Luleå University of
Technology, Sweden.
and datacom product
areas. He headed the
ims strategic system
management and network
evolution units during the
design of the ims system
and multimedia telephony.
He was a key contributor to
the OneVoice specification
that was adopted by
the gsma as the base
for volte, and he has
continued to contribute
to the gsma InterWorking, Roaming Expert
Group (ireg), where he
is the editor of the IR.94
reference document
for video calls over lte
(vilte). He currently
works as a system expert
at Business Unit Cloud
& ip. He holds an M.Sc in
electrical engineering from
Chalmers University of
Technology, Gothenburg,
Sweden.
1982 and has since held
various management
and technical expert
positions in the telecom
69
✱ xxxxx
issn 0014-0171
284 23-3258 | Uen
Edita Bobergs, Stockholm
72
© Ericsson AB 2015
Ericsson
se-164 83 Stockholm, Sweden
E r i c s s o n t e c h n o l o g y r e v i e w ✱ #01, 2015
Phone: + 46 10 719 0000