Issue 2/2014

Transcription

Issue 2/2014

The communications technology journal since 1924
Communications as a cloud service: a
new take on telecoms 4
Capillary networks – a smart way to get
things connected 12
Trusted computing for infrastructure 20
Wireless backhaul in future
heterogeneous networks 28
Connecting the dots: small cells shape
up for high-performance indoor radio 38
Architecture evolution for automation
and network programmability 46
2/2014
Editorial
Deeper into the
Networked Society
Earlier this year, Ericsson launched
its new vision: a Networked Society
where every person and every industry is empowered to reach their full
potential. Technology leadership is
about realizing this vision. It’s about
developing connectivity technology
to make it an integral part of our daily
lives, whether we’re at work, at school,
at home, outside, on the way somewhere or taking part in some event.
The aims of each individual or enterprise vary widely; they want coverage,
capacity, reliability, availability and
resilience with an appropriate level of
security. The one-size-fits-all network
model no longer applies; network characteristics need to be tailored to users’
specific needs. With cloud technologies, SDN and NFV as a foundation, the
technological developments we are
working on – in the move toward 5G –
are based on providing connectivity to
suit every different use case.
The traditional way of building services and applications by packaging
functionality and data and inherently
assuring security has worked well for
services and applications made and
delivered by just one vendor – some
even benefiting from bundling with
hardware. But this approach doesn’t
lend itself to the creation of innovative
solutions that provide benefit. Nor does
it fit with reusability, fast time to market, and the use of generic hardware.
Instead, applications are being
mashed together from lots of other
internet services. However, the freedom to innovate that this approach
offers leads to security issues, which
is one of our industry’s greatest challenges. And as web services and programmable routing technology are
deployed on platforms that exploit virtualization, assuring security becomes
trickier still.
In the face of such challenges,
trusted computing helps us to meet
the evolving security requirements of
E R I C S S O N R E V I E W • 2/2014
users, businesses, regulators and infrastructure owners.
The developments that I would
like to highlight relate to handling
expected growth in traffic volumes, capacity and machine-type
communication.
Building heterogeneous networks
is an effective way of expanding
networks to handle traffic growth.
However, the additional small cells
included in these networks need to be
provided with flexible and cost-efficient
backhaul. Our research shows that nonline-of-sight backhaul in licensed spectrum is a future-proof technology in
this area.
When it comes to capacity, one of
the significant challenges is providing radio capacity indoors. About 70
percent of all traffic is generated
indoors, and our research has resulted
in a novel small cell solution with a
flexible radio architecture. We wanted
to address the issue of indoor capacity
from an ecosystem point of view, with
an emphasis on cost control at every
phase. From installation to operation,
our aim was to create a special indoor
small cell that works well in large
buildings – a solution that would integrate smoothly with outdoor coverage.
Capillary networks offer a smart
way to connect the Internet of Things,
but they require some additional functionality. The use cases for machinetype communication vary greatly
from one application to the next, and
so rather than building systems with
a one-size-fits-all approach, capillary
networks will be designed to fit the
application.
All of these developments lead to
the establishment of a flexible network
architecture set to satisfy the demands
of every future use case. As always, I
hope you enjoy our insights.
About 50 percent of all
sites will be connected with
microwave in 2019.*
*Ericsson Mobility Report, June 2014
Ulf Ewaldsson
Chief Technology Officer
Head of Group Function
Technology at Ericsson
The communications technology journal since 1924
CONTENTS
2/2014
Communications as a cloud service: a
new take on telecoms 4
Capillary networks – a smart way to get
things connected 12
Trusted computing for infrastructure 20
heterogeneous networks 28
Connecting the dots: small cells shape
up for high-performance indoor radio 38
and network programmability 46
To bring you the best of Ericsson’s
research world, our employees have
been writing articles for Ericsson
Review – our communications
technology journal – since 1924.
Today, Ericsson Review articles have
a two-to-five year perspective and
our objective is to provide you with
up-to-date insights on how things are
shaping up for the Networked Society.
Address :
Ericsson
SE-164 83 Stockholm, Sweden
Phone: +46 8 719 00 00
Communications as a cloud service:
a new take on telecoms
4
Software as a service (SaaS) is a promising solution for overcoming the challenges of
implementing and managing new network technologies and services like voice over LTE (VoLTE).
The SaaS approach can provide substantial savings in terms of cost and lead-time, and create a
new source of revenue for service providers.
This article was originally published on July 22, 2014.
Capillary networks – a smart way to
get things connected
12
A capillary network is a local network that uses short-range radio-access technologies to provide
local connectivity to things and devices. By leveraging the key capabilities of cellular networks
– ubiquity, integrated security, network management and advanced backhaul connectivity –
capillary networks will become a key enabler of the Networked Society..
This article was originally published on September 9, 2014.
20
Publishing:
Ericsson Review articles and
additional material are published
on www.ericsson.com/review. Use
the RSS feed to stay informed of the
latest updates.
Articles are also
available on the Ericsson
Technology Insights app
for Android and Apple
devices. The link for your device is on
the Ericsson Review website:www.
ericsson.com/review. If you are
viewing this digitally, you can:
download from Google Play or
download from the App Store
Publisher: Ulf Ewaldsson
Editorial board:
Håkan Andersson, Hans Antvik,
Ulrika Bergström, Joakim Cerwall,
Stefan Dahlfort, Deirdre P. Doyle,
Dan Fahrman, Anita Frisell,
Jonas Högberg, Patrik Jestin,
Magnus Karlsson, Cenk Kirbas,
Sara Kullman, Börje Lundwall,
Hans Mickelsson,Patrik Regårdh,
Patrik Roséen and Gunnar Thrysin
Editor:
Deirdre P. Doyle
[email protected]
Contributors:
John Ambrose, Paul Eade,
Nathan Hegedus, Ian Nicholson,
Ken Neptune and
Birgitte van den Muyzenberg
Art director and layout:
Carola Pilarz
Illustrations:
Claes-Göran Andersson
Printer: Edita Bobergs, Stockholm
2/20143
Trusted computing for infrastructure
Modern internet services rely on web and cloud technology, and as such they are no longer
independent packages with in-built security, but are constructed through the combination
and reuse of other services distributed across the web. While the ability to build applications
in this way results in highly innovative services, it creates new issues in terms of security.
Trusted computing aims to provide a way to meet the evolving security requirements of users,
businesses, regulators and infrastructure owners.
This article was originally published on October 24, 2014.
28
Wireless backhaul in future heterogeneous networks
Heterogeneous networks are an effective way of expanding networks to handle traffic growth.
However, the additional small cells included in heterogeneous networks need to be provided with
backhaul – in a way that is flexible and cost-efficient. Our research shows that non-line-of-sight
(NLOS) backhaul in licensed spectrum up to 30GHz is a future-proof technology for managing
high volumes of traffic in heterogeneous networks.
This article was originally published on November 14, 2014.
Connecting the dots: small cells shape up for highperformance indoor radio
38
How do you design a small radio to fit the interiors of large spaces, yet powerful enough to meet
future requirements for indoor radio capacity? This was the question we asked ourselves when
we began to develop a solution to provide high-capacity radio for indoor environments.
This article was originally published on December 19, 2014.
and network programmability
46
Automation and network programmability are key concepts in the evolution of telecom networks.
Architecture designed with high degrees of automation and network programmability can rapidly
adapt to emerging requirements, and as such improve operational efficiency and time to market
for new services.
This article was originally published on November 28, 2014.
ISSN: 0014-0171
Volume: 91, 2014
E R I C S S O N R E V I E W • 2/2014
Proof of concept for VoLTE as a service
4
Communications as a cloud
service: a new take on telecoms
Modern mobile networks are complex systems built with an increasingly broad variety of technologies
to serve a wide base of devices that provide an ever-greater range of services. These developments
create interesting business opportunities for operators. But they also bring challenges, as new
technologies and new expectations need to be managed with the same staff and budget.
BA RT J E L L E M A A N D M A RC VORW E R K
Software as a service (SaaS)
is a promising solution for
overcoming the challenges of
implementing and managing new
network technologies. The SaaS
approach can provide substantial
savings in terms of cost and lead
time, and create a new source of
revenue for those adopting the
role of service provider.
This article shares some of the technical
and economical insights and know-how
gained from a proof of concept study
conducted at Ericsson to explore the
implementation of VoLTE as a service.
Why a new take on telecoms?
Today’s networks support several technology generations, from 2G to 4G, and
as research for 5G is well underway,
the next generation is on the commercial horizon. The types of devices connected to networks vary from feature
phones to smartphones and tablets to
the billions of new connected devices
that are emerging to support applications like smart homes and connected
vehicles. In short, this is a complex ecosystem based on constant development,
which can be difficult to predict and
consequently challenging to plan for
and budget.
The introduction of 4G LTE networks, for example, brought with it a
major overhaul of voice services in core
networks – in the move from circuitswitched to IMS. For many, especially
niche operators, this type of technology
upgrade threatens to stretch organizational capabilities to the limit, even to
the point where business profitability
is at stake.
To counter this challenge, many operators have turned to Network Functions
Virtualization (NFV). By placing core
networks in large concentrated data
centers, NFV is a way to rationalize and
simplify operations as well as speeding up innovation cycles1. The addition
BOX A Terms and abbreviations
ARPU
average revenue per user
CRM
customer relationship management
CSCF
Call Session Control Function
HSS
Home Subscriber Server
IMS
IP Multimedia Subystem
LI
Lawful Interception
MRFP
Media Resource Function Processor
MSC
mobile switching center
MTAS
Multimedia Telephony Application
Server
MVNO
mobile virtual network operator
NFV
Network Functions Virtualization
E R I C S S O N R E V I E W • 2/2014
NPV
O&M
OSS
OVF
P-CSCF
SaaS
SBG
SLA
SRVCC
TCO
VLAN
VM
VoLTE
net present value
operations and maintenance
operations support systems
Open Virtualization Format
proxy call session control function
software as a service
Session Border Gateway
Service Level Agreement
single radio voice call continuity
total cost of ownership
virtual local area network
virtual machine
voice over LTE
of multi-tenancy capabilities to NFV
makes this approach particularly interesting for global operators, who have a
presence in several countries and manage a range of networks through various
operating companies.
Apart from addressing the strain on
internal resources, NFV opens up the
opportunity for operators to provide services, like VoLTE, to other communication service providers. By deploying
the necessary IMS network functions
for services in a central virtualized data
center, and by adopting a SaaS model,
operators can unlock the potential of
their infrastructure beyond their own
portfolios. Virtualized services can then
be offered to smaller second and third
tier affiliates or MVNOs at a lower cost,
with reduced risk, and within a shorter
time frame than is normally associated with the introduction of new services using traditional telecom business
models.
The SaaS business model allows
an operator’s partners to circumvent
lengthy hardware procurement cycles.
This way, the burden of costs and complexities associated with owning a
completely new and technologically
advanced communications system can
be removed. Simply by signing up as a
tenant to the existing facilities of a host
operator’s data center, partners will
be able to provide services quickly and
cost-efficiently.
Once in place, NFV provides a flexible
telecom-grade platform on which a variety of communication services can be
offered to people and organizations, in
a low-cost, low-impact fashion. Services
can be quickly and easily trialed,
launched, scaled up or down and decommissioned in line with market demand,
5
presenting an operator-branded and
guaranteed alternative to the many
third-party over-the-top solutions that
operate in both the consumer and enterprise communication space.
Concept – heading for the clouds
Today, the purchasing process for a new
IMS system can take several months
from order placement to an operational system. Once an order is placed,
the network system vendor initiates
the production process for the node.
On completion, the node is then integrated and packaged together with the
necessary software elements, tested,
shipped, installed at the designated central office site, integrated into the network, tested again, accepted and finally
put into operation. Once the system is
functional the operator is responsible
for operations and maintenance (O&M),
often with the support of the vendor.
With a SaaS deployment, operators
can purchase a virtualized IMS network
slice that is custom-initialized for them
in a large data center. Network slices can
be tied into existing radio and packet
core networks over a remote link – as
Figure 1 illustrates.
Working in this way, operators will
no longer need to purchase, install or
own any hardware, or invest in training staff on a new system. The SaaS
approach removes the need to manage
software licenses, and reduces system
integration from a complete IMS solution to just the points of interconnect
with the access network. Ownership
and operational details are instead
taken care of by the service provider and
operators will pay as they go using simple, predictable price models, such as a
flat service fee per subscriber. The benefits: no large upfront investments, limited technical and business risks, and
much shorter time to revenue.
VoLTE as a service
In 2013, Ericsson’s R&D and IT divisions
carried out a joint project to develop a
proof of concept implementation for
VoLTE as a service. The objective was
to gain an understanding of the technical and economic implications of
offering a complex communications
solution like VoLTE as a service. For telecom applications, SaaS is a relatively
new business model that needs to
FIGURE 1 The SaaS concept
IMS
EPC
LTE RAN
Traditional node deployment
Software as a service
EPC
IMS
LTE RAN
FIGURE 2 VoLTE as a service – architecture
Cloud-based
multi-tenant
VoLTE system
Tenant Y
Tenant X
EMA
MM
MSP
HSS
PGM
MTAS
SCC-AS
CSCF
BGCF
MRFP
SBG
P-CSCF
DNS/
ENUM
Tenant X
BSS
MSC-S
MGCF
SMS-C
CRM
MGw
BGF
EPC
LTE
Tenant Y
BSS
MSC-S
MGCF
SMS-C
CRM
MGw
BGF
EPC
LTE
E R I C S S O N R E V I E W • 2/2014
6
FIGURE 3 Network Functions Virtualization – portfolio migration
High
Media distribution network
Control plane elements, CSCF, MSC
Gateways and appliances
Hosted
managed
services
Distributed cloud
Value
OSS, BSS
Home appliances
Edge router
EMS
Real time OSS/BSS
Home networking
Core
router
Radio
access
Low
Fixed
access
High
Low
Risk
(Technology maturity, performance requirements)
FIGURE 4 IP design
Central
storage
Tenant 2
network
E R I C S S O N R E V I E W • 2/2014
CSCF
cluster
HSS
cluster
MTAS
cluster
vRtr
vRtr
vRtr
PGM
IDNS
MFRP
Storage
DC
switch
/FW
O&M
Signaling
Media
Tenant 1
Core
Access
SBG
Access
Tenant 1
network
O&M
Tenant 2
NOC
Tenant 1 IMS network
CSCF
cluster
HSS
cluster
MTAS
cluster
vRtr
vRtr
vRtr
PGM
iDNS
MFRP
O&M
Signaling
Media
Tenant 2 IMS network
take into consideration the tough
requirements of the underlying cloud
infrastructure.
From the start of the project, it was
clear that turning VoLTE as a service
into a viable business proposition, with
competitive price levels and sound margins, would require the onboarding and
serving of new tenants to be simple, efficient and easily repeated.
Through virtualization techniques,
the hosting service provider can deploy
multiple VoLTE systems on the same
shared data center hardware, while
still guaranteeing each tenant their
own dedicated, logically separated virtual network. Such a multi-tenant cloud
infrastructure makes it possible for service providers not only to share hardware among tenants, but also O&M and
engineering staff. The resulting economy of scale is much more significant
than any individual small-scale installation could achieve.
To improve repeatability, a high
degree of business process automation
(auto-deployment and auto-scaling)
reduces the time and effort needed to
operate services, which in turn reduces
costs. And to ensure that customers get
what they pay for, the provision of relevant network statistics is essential for
billing and to provide proof of Service
Level Agreement (SLA) conformance.
A blueprint for the architecture
So how is this done? As shown in
Figure 2, the operator’s radio and
packet core networks as well as their
legacy circuit-switched network are
connected to a remote virtualized IMS
network within a cloud data center over
standardized interfaces for signaling,
O&M and media.
As illustrated in Figure 3, next generation systems will normally be fully
implemented as software without
any strong hardware dependencies.
Consequently, IMS server-type network
functions like CSCF and MTAS are natural candidates for cloud placement.
To optimize use of bandwidth, most
media handling will most likely continue to take place in the tenant network, with the possible exception of the
MRFP. Certain network functions, such
as HSS, can be placed either in the cloud
or in the tenant network, depending on
operator preference or to comply with
7
local regulatory requirements with
respect to user databases.
To integrate with the operator’s various business support, customer care and
other IT systems, the virtualized IMS
network will provide billing and provisioning capabilities.
When another operator becomes a
tenant, a copy of the virtualized IMS
network can be instantiated in the data
center and the whole onboarding process simply repeated.
For commercial deployment, at least
two data center locations are needed to
provide geo-redundancy. Alternatively,
the tenant could operate a single nonredundant system in their own network
and rely on a secondary virtualized system as an overflow and failover mechanism – geo-redundancy as a service.
As an additional offering, service providers can include smaller regional satellite sites that host the IMS media plane
nodes. In such topologies, the satellite
centers can be used to house not just
media gateways but also network functions like Lawful Interception for IMS
(LI-IMS), an anchor MSC for SRVCC and
/or an SBG/P-CSCF. Providing mediaplane nodes in this way reduces the
impact of introducing IMS to an operator’s existing core network to practically
nothing. Taking a coverage area the
size of North America as an example,
approximately 24 regional sites would
be required to provide this service.
A significant change
By the end of December 2015, roaming
fees within the European Union will
no longer exist; rates for voice calls and
data transmission will be the same as
in the subscriber’s home market2. This
drastic change for consumers is likely
to stimulate traffic and motivate operators across Europe to centralize their
core network infrastructures – as physical location will no longer influence
billing rates.
Hardware
From a hardware perspective, data
centers will need to be equipped with
enough servers to host virtualized versions of the number of tenant IMS networks anticipated. In addition, high
capacity physical IP switches and central storage will be needed. As hardware
is completely decoupled from software
FIGURE 5 Operations and maintenance view
Work orders, tickets,
and change requests
DC back office
NOC front office
Tenant
SLA report,
invoicing
Tenant
provisioning
CM
PM
FM
NIM
TM
Network
management
SLA monitoring,
service metering
Subscriber
billing
Dashboard
Mediation
Subscriber
provisioning
Service
activation
CDRs
Node manager
Cloud manager, including:
• SLA resolution
• Auto-deployment
• Auto-scaling
BOX B  
Legend for
Figure 5
CM – configuration
management
DC – data center
FM – fault
management
NIM – network
inventory
management
NOC – network
operations center
PM – performance
management
TM – ticket
management
Subscriber data
vIMS
OS
Hypervisor
Hardware
through virtualization middleware,
service providers have the freedom to
select the x86-based hardware of their
choice, as long as it meets the set target
specifications in terms of performance,
bandwidth and memory of the virtualized network functions – including
some virtualization overhead.
Operations and maintenance
As shown in Figure 4, the IP plan needs
to be designed so that each tenant has
their own set of dedicated VLANs – at
least for O&M, signaling and media –
that are separated from all the other
tenants to avoid interference and maintain security.
For O&M, the service provider’s back
office can perform tasks such as configuration management, performance
management, fault management
and network inventory management
through a managed services portal.
This is similar to the way network management works in the service provider’s own IMS network. The front office
can process work orders and change
requests received from tenants, tickets
from field engineers, and take care of
invoicing and SLA reporting.
As shown in Figure 5, tenants will
be provided with O&M access rights to
their specific network for provisioning subscribers and retrieving detail
records for charging. This access will
connect to the tenant’s back-end IT systems like CRM and billing systems, and
a dashboard function will allow the tenant to view key performance statistics
for their network.
Northbound interfaces from the
different virtualized network functions are generally not affected by
virtualization.
The exact implementation of the IMS
network – its internal structure, what
software and which release is used – is
entirely at the discretion of the service
provider. In other words, the implementation is transparent and of no real
concern to the tenant. Their only concern lies with the behavior of the service, the agreed service level and the
interfaces exposed at the points of
interconnection.
Features – under the hood
Multi-tenancy
Modern server blades house multiple
processor cores on which virtual
E R I C S S O N R E V I E W • 2/2014
8
FIGURE 6 Multi-tenancy
HW
vRouter
VM
VM
VM
VM
(CSCF)
VM (MTAS) VM
VM
VM
VM
(HSS)
VM
vRouter
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
vRouter
VM
VM
VM
VM
VM
VM
VM
VM
VM
vRouter
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Hyp
Hyp
Hyp
#1
#2
#3
VM
VM
VM
VM
VM
VM
VM
VM
VM
(DNS)
(PGM)
(MRFP)
VM
VM
VM
VM
VM
VM
Tenant Z Tenant Y Tenant X
vRouter
vRouter
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
VM
Hyp
Hyp
Hyp
Hyp
Hyp
Hyp
Hyp
Hyp
Hyp
#4
#5
#6
#7
#8
#9
#10
#11
#12
vRouter
VM
VM
VM
vRouter
vRouter
12 blades
machines (VMs) can be placed.
Virtualized IMS network functions
like CSCF or HSS use a number of virtual machines for traffic processing, as
shown in Figure 6, which act much like
a physical node with several blades as
part of a cluster. As illustrated, these
virtual machines should be spread horizontally over multiple blades, so that
the failure of one blade will never bring
down an entire node.
The remaining cores can then be used
for other network functions or even
other tenants.
Auto-deployment
Onboarding a new tenant sets a deployment function into motion. As shown in
Figure 7, this function executes an IMS
network deployment sequence using a
cloud orchestration tool in combination
with scripts that parse the customerspecific environment settings. Any necessary adaptations are executed inside
the deployed VMs.
To save time during the onboarding
process, tenant VLANs can and should
be prepared ahead of time. Software
images for each virtualized network
function are built and uploaded (in
advance) to the cloud manager in, for
example, Open Virtualization Format
(OVF)3, and are kept in storage. From
there, the deployment function can
instantly clone network functions for
new tenants.
FIGURE 7 Auto-deployment
1. Clone from
template
2. Post-config
DNS/
ENUM
Deployment
function
CSCF
Cloud
manager
CSCF
vAPP
E R I C S S O N R E V I E W • 2/2014
CSCF
vRouter
HSS
HSS
HSS
vAPP
vRouter
EMA
MTAS
vRouter
MTAS
To connect them to their pre-assigned
VLANs, the virtual machines are linked
to the appropriate port groups and powered on. The deployment function loads
a data transcript onto the VMs to create an operational virtualized network
function and configures the application
interfaces, so that they form an integrated IMS network. All of this post-configuration work can be scripted; and any
data transcript common to all tenants
can be included in the software image.
Once all the network functions and
connections between them are established, the next step is to connect the virtual IMS network to the tenant’s access
network and IT systems before provisioning the first users. The high degree
of preparation and process automation, together with the use of hardware
capacity available in the data center, and
prestorage of software images, results in
drastically reduced installation times.
The complete software installation for
an IMS network can be fulfilled in just
a few hours, compared with the several
days it would normally take to set up a
traditional central office environment
with physical nodes. Time to revenue
from contract signing to commercial
launch could be reduced to a matter of
weeks, rather than months.
Auto-scaling
The ability to scale networks is a key
business enabler. In the proof of concept project, the Ericsson team developed a controller function that worked
in conjunction with the cloud manager
to determine when and where networks
need to be scaled. As shown in Figure 8,
the controller continuously monitors
the average processor load on each of
the virtualized network functions, by
reading the load figures from the guest
operating system. This approach has
proven to be more accurate than using
the measurements provided by the
hypervisor, as the hypervisor cannot,
for example, determine the priority and
necessity of currently executed tasks
from the outside.
When the load for a particular network function like CSCF exceeds its
set upper limit, which can happen for
example during traffic peaks, the controller requests the cloud manager
to scale out. The cloud manager powers up another CSCF virtual machine,
9
3. Join cluster
1. Measure
load
CSCF
Controller
Cloud
manager
CSCF
2. Power on VM
CSCF
vRouter
FIGURE 9 Example time series
Time: 13:00:44
Finished scaling out
Number of TPs: 5
CSCF-CBA-012 load
Number of traffic processors
PL 4
PL 5
PL 6
PL 7
PL 8
100
PL 3
Service-level monitoring
SLAs are highly varied in nature, covering different aspects of a service such as
customer ticket turn-around times and
other logistical matters. As far as technical content is concerned, SLAs between
service providers and tenants are best
kept simple and transparent. Many network statistics can be made available
for information purposes, which is fine,
but the list of contracted KPIs that carry
financial implications are best kept as
simple as possible (see Table 1).
In its simplest form, billing tenants for the use of VoLTE as a service
can be based on the actual number of
active users during a given time period
– assuming a certain maximum traffic volume. The volume can be defined
in terms of the maximum number of
simultaneous sessions (the current
licensing model) or by average voice
minutes per subscriber. As voice
FIGURE 8 Auto-scaling
51
52
50
49
38
off
80
Processor load (%)
which then joins the existing cluster
and rebalances the traffic. Similarly, a
node can be scaled in during periods of
low traffic.
The user interface for the controller
allows engineering staff in the data center to set upper and lower processor-load
thresholds for scaling in and out of network functions. Additional parameters,
such as the minimum and maximum
number of traffic processors, can also
be set so that a node has a guaranteed
minimum redundancy without monopolizing more than its fair share of available resources.
Figure 9 shows an example time
series taken from a test session carried
out during the proof of concept project.
The scaling mechanism for the CSCF
kicked in just before the 12:58 time
stamp, as the processor load exceeded
the set maximum (indicated by the red
line). Three minutes later, at approximately 13:01, the CSCF was running on
a cluster of five instead of the original
four traffic processors.
Depending on the existing traffic
load, it takes between five and 10 minutes to add capacity automatically (by
scaling a virtualized network function out by one traffic processor) to a
live node in a virtualized data center.
In contrast, adding a physical hardware
board to a live physical node on such a
time scale is unimaginable.
60
40
20
0
12:42
12:44
12:46
12:48
12:50
12:52
12:54
12:56
12:58
13:00
Time
%
Table 1: SLA reporting
Service Metering
Tenant gets billed per number of users +
premium for traffic coverage
Service Level Monitoring
Tenant gets credited in case of failure to meet SLA
Key performance indicators
Key performance indicators
System availability (%)
Number of users
IMS registration time (msec)
Traffic volume
(average session duration and/or
number of concurrent sessions
IMS registration success ratio (%)
VoLTE setup success ratio (%)
E R I C S S O N R E V I E W • 2/2014
10
FIGURE 10 Pricing model
opex
opex
opex
capex
3-year system TCO
(amoritized over 36 months)
Year 1
Year 2
minutes readily translate to the payment plans offered by most operators,
this model is probably preferable for the
majority of tenants. Similar consumption indicators aligned with operator-toconsumer price models can be created
for all other services.
While threshold limits are good for
SLAs and planning, service providers
are not likely to cut off traffic when
an agreed maximum for a tenant is
reached – as long as continued service
does not overload the system or infringe
on other tenants. However, a premium
may be charged.
To keep service level monitoring relatively straightforward, the proof of concept project created example reports for
system availability, registration time,
registration success rate and call establishment success rate. If any of these
Year 3
resources underperformed during a
billing period, the tenant would receive
credit on their next payment.
All of these counters and statistics
are already available in today’s typical
IMS products. By collecting, filtering
and combining them into a customized
business intelligence report, they can be
easily communicated and turned into
actionable data.
In a commercial setup, this data
would be fed from the OSS into a specialized SLA management tool, in which
KPI values are continuously compared
against predefined thresholds to detect
and record SLA violations. A number
of approach warning levels are usually
defined below the critical level, so that
O&M staff can be alerted and take appropriate actions before any impact on business is felt.
Table 2: TCO comparison – an example in USD thousands
system
capex
opex as a service
Hardware
2,400
1,000
Setup fee
Software
3,300
2,500
Service fee*
Systems Integration
1,600
Project
opex
450
24,098
900
Staff
4,300
Facilities
500
Utilities
Lab costs
capex
200
5,000
3 year TCO
21,700 3 year TCO
24,548
NPV
20,791 NPV
20,791
*36 months x 200,000 subscribers x USD 3.35
E R I C S S O N R E V I E W • 2/2014
Financials – where is the money?
In the traditional system-sales model,
total cost of ownership (TCO) is defined
as the initial purchase price including
related project costs, plus recurring running costs such as support agreements,
O&M staff, rent and power. In the SaaS
model, this will be replaced by a single
line item – service fees – under opex.
Unfortunately, estimating a reasonable price level for VoLTE as a service –
one that the tenant can afford and that
keeps the service provider in business –
is not a simple task.
One potential pricing model (shown
in Figure 10) is based on the traditional total cost of ownership for a threeyear period, amortized over 36 equal
monthly payments. Payback times of
less than three years tend to result in a
service that is too expensive for the tenant, and calculating over longer periods
tends to make the model unattractive
for service providers. Parameters like operator size and
running costs – rents, engineer salaries
and electricity – vary greatly from one
part of the world to another, and so the
economy of scale and benefit to operators in different markets will vary. In
conjunction with the proof of concept
project, a study aimed to estimate the
service price for VoLTE for a typical second or third tier operator with between
100,000 and one million subscribers.
The study estimated and adjusted for
net present value (NPV) and the required
initial capex and opex over three years
to own, deploy and run an IMS system
for VoLTE. The resulting estimation set
the fee for VoLTE as a service to be somewhere between USD 1 and USD 5 per
subscriber per month. An example of
the type of calculation used in the study
is given in Table 2 for a mock tenant
with 200,000 subscribers.
To match the price points for a service with the average cost per subscriber
incurred by operators at different ends
of the scale, some sort of tiered price
model is needed – a suggested model is
shown in Figure 11.
If the average revenue for voice services is assumed to be USD 40 per subscriber per month, a fee of USD 1-5 per
subscriber per month for VoLTE as a service is between 2.5 and 12.5 percent of
the corresponding ARPU it generates,
which is a fair business case.
11
Looking at the addressable market,
the number of subscribers connected to
second and third tier operators amounts
to 22 million in North America alone.
Evolution – beyond the horizon
As illustrated in Figure 12, rolling
out VoLTE might be the initial motivation for a second or third tier operator
to switch to the software as a service
model. Doing so would allow such operators to roll out VoLTE in the same time
frame (2014-2015) as their larger competitors – and secure their market share.
Subsequently, operators could
broaden the scope of their offerings to
include customized services for enterprises, the retail industry and many
other verticals. The SaaS platform could
be further utilized by opening it up to
internet-application and web developers to create a whole new range of converged services.
Second and third tier operators are
the most obvious first adopters of this
type of business model for voice – or
rather VoLTE. Once rooted, adoption is
likely to rise up the food chain. Many
operators, both big and small, have
opted for the managed service approach
for their voice networks, gaining efficiency and freeing up resources to focus
on customers and on improving operator brand value.
Operators already include unlimited
voice and unlimited text in their data
plans, rendering these services to the
level of a commodity, or a fundamental
product that cannot really be charged
for, but neither can they be taken out of
the service offering. And so software as
a service – the ultimate form of a managed service – is the most natural evolution path.
Conclusion
By following this route, service providers will be able to offer all managed
networks from the same platform and
housed under the same roof. For operators, the ability to outsource the responsibility for voice shifts price pressure
on to a third party who can provide the
right expertise, efficiency and scale.
FIGURE 11 Tiered price model
Price point in USD
6
5
4
3
2
1
0
1–100
101–200
201–500 501–1000
1000+
Thousands of subscribers
BOX C  
Legend for
Figure 12
FIGURE 12 Service evolution
Capture
aaS – as a service
BusCom –
business
communication
RCS – Rich
Communication
Suite
UC –unified
communication
VisualCom –
visual
communication
WebRTC – Refers
to standardization
for real-time
browser
capabilities.
VoLTE-aaS
RCS-aaS
Mobile
Grow
BusCom-aaS
VisualCom-aaS
UC-aaS
Enterprise
Innovate
WebRTC
Service
enablement
Cable/internet
References
1. Ericsson, February 2014, White Paper, The real-time cloud – combining cloud,
NFV and service provider SDN, available at:
http://www.ericsson.com/news/140220-the-real-time-cloud_244099438_c
2. European Commission, Digital agenda for Europe, Roaming, available at:
https://ec.europa.eu/digital-agenda/en/roaming
3. DMTF, Open Virtualization Format, available at:
http://www.dmtf.org/standards/ovf
Additional reading
ETSI, Network Functions Virtualisation, available at: http://www.etsi.org/
technologies-clusters/technologies/nfv
The author bios for Bart Jellema and
Marc Vorwerk can be found on page 19
E R I C S S O N R E V I E W • 2/2014
Connectivity for billions of things
12
Capillary networks – a smart
way to get things connected
A capillary network is a local network that uses short-range radio-access technologies to provide
groups of devices with connectivity. By leveraging the key capabilities of cellular networks – ubiquity,
integrated security, network management and advanced backhaul connectivity – capillary networks
will become a key enabler of the Networked Society.
JOAC H I M S AC H S , N IC K L A S BE I JA R , P E R E L M DA H L , JA N M E L E N, F R A NC E S CO M I L I TA NO A N D PAT R I K S A L M E L A
People and businesses
everywhere are becoming
increasingly dependent on the
digital platform. Computing and
communication are spreading
into every facet of life with ICT
functionality providing a way
to manage and operate assets,
infrastructure, and commercial
processes more efficiently. The
broad reach of ICT is at the heart
of the Networked Society, in
which everything will become
connected wherever connectivity
provides added value1,2 .
Ubiquitous connectivity and the
Networked Society
Connectivity in the Networked Society
is about increasing efficiency, doing
more with existing resources, providing services to more people, reducing
the need for additional physical infrastructure, and developing new services
that go beyond human interaction. For
example, smart agricultural systems
monitor livestock and crops so that irrigation, fertilization, feeding and water
levels can be automatically controlled,
which ensures that crops and livestock
remain healthy and resources are used
wisely. In smart health care, patients
and the elderly can get assistance
through remote monitoring – again
using resources in an intelligent way
– which improves the reach of health
care services, reduces the need for, say,
physical day clinics and cuts the need for
patients to travel.
As a whole, communication is progressively shifting from being humancentric to catering for things as well as
people. The world is moving toward
machine-type communication (MTC),
where anything from a smart device
to a cereal packet will be connected; a
shift that is to some extent illustrated
by the explosive growth of the Internet
of Things (IoT).
However, the requirements created
by object-to-object communication are
quite different from those of current
systems – which have primarily been
built for people and systems to communicate with each other. In scenarios where objects communicate with
each other, some use cases require battery-operated devices; therefore, low
energy consumption is vital. Barebones device architecture is essential
for mass deployment; typically the data
rate requirements for small devices are
low, and the cost of connectivity needs
to be minimal when billions of devices
are involved. Meeting all of these new
CoAP
EGPRS
eSIM
GBA
IoT
Constrained Application Protocol
enhanced general packet radio service
embedded SIM card
Generic Bootstrapping Architecture
Internet of Things
E R I C S S O N R E V I E W • 2/2014
MTC
machine-type communication
M2Mmachine-to-machine
OSPF
Open Shortest Path First
SLA
TLS
transport layer security
requirements is a prerequisite for the
MTC business case.
Cellular communication technologies are being enhanced to meet these
new service requirements3,4. The powersave mode for example, introduced in
the most recent release (Rel‑12) of LTE,
allows a sensor that sends hourly reports
to run on two AA batteries for more
than 10 years, and simplified signaling
procedures can provide additional battery savings5. Rel-12 also introduces a
new LTE device category, which allows
LTE modems for connected devices to be
significantly less complex and cheaper
than they are today – the LTE features
proposed in 3GPP reach complexity levels below those of a 2G EGPRS modem6.
In addition, 3GPP has identified ways to
increase the coverage of LTE by 15-20dB.
This extension helps to reach devices in
remote or challenging locations, like a
smart meter in a basement 6.
Capillary networks and the shortrange communications technologies
that enable them are another key development in the Networked Society: they
play an important role providing connectivity for billions of devices in many
use cases. Examples of the technologies
include Bluetooth Low Energy, IEEE
802.15.4, and IEEE 802.11ah.
This article gives an overview of the
significant functionality that is needed
to connect capillary networks, including how to automatically configure and
manage them, and how to provide endto-end connectivity in a secure manner.
Capillary networks
The beauty of short-range radio technologies lies in their ability to provide connectivity efficiently to devices within a
13
specific local area. Typically, these local
– or capillary – networks need to be connected to the edge of a communication
infrastructure to, for example, reach
service functions that are hosted somewhere on the internet or in a cloud.
Connecting a capillary network to the
global communication infrastructure
can be achieved through a cellular network, which can be a wide-area network
or an indoor cellular solution. The gateway between the cellular network and
the capillary network acts just like any
other user equipment.
The architecture, illustrated in
Figure 1, comprises three domains: the
capillary connectivity domain, the cellular connectivity domain, and the data
domain. The first two domains span the
nodes that provide connectivity in the
capillary network and in the cellular
network respectively. The data domain
spans the nodes that provide data processing functionality for a desired service. These nodes are primarily the
connected devices themselves, as they
generate and use service data though
an intermediate node, which like a capillary gateway, would also be included in
the data domain if it provides data processing functionality (for example, if it
acts as a CoAP mirror server).
All three domains are independent
from a security perspective, and so
end-to-end security can be provided by
linking security relationships in the different domains to one another.
The ownership roles and business
scenarios for each domain may differ
from one case to the next. For example, to monitor the building sensors of a
real estate company, a cellular operator
might operate a wide-area network and
possibly an indoor cellular network, as
well as owning and managing the capillary network that provides the sensors
with connectivity. The same operator
may also own and manage the services
provided by the data domain and, if so,
would be in control of all three domains.
Alternatively, the real estate company
might own the capillary network, and
partner with an operator for connectivity and provision of the data domain. Or
the real estate company might own and
manage both the capillary network and
the data domain with the operator providing connectivity. In all of these scenarios, different service agreements are
FIGURE 1 System architecture for capillary network connectivity
Cellular access
Capillary network
Mobile
network
Connected
devices
M2M/IoT
cloud
Capillary gateway
Data domain
Capillary connectivity domain
Cellular connectivity domain
needed to cover the interfaces between
the domains, specifying what functionality will be provided.
Like most telecom networks, a capillary network needs a backhaul connection, which is best provided by a cellular
network. Their quasi-ubiquitous coverage allows backhaul connectivity to be
provided practically anywhere; simply
and, more significantly, without installation of additional network equipment.
Factoring in that a capillary network
might be on the move, as is the case for
monitoring goods in transit, leads to the
natural conclusion that cellular is an
excellent choice for backhaul.
In large-scale deployments, some
devices will connect through a capillary gateway, while others will connect to the cellular network directly.
Regardless of how connectivity is provided, the bootstrapping and management mechanisms used should be
homogeneous to reduce implementation complexity and improve usability.
Smart capillary gateway selection
Ideally, any service provider should
be able to deploy a capillary network,
including device and gateway configuration. For this to be possible, deployment
needs to be simple and use basic rules
– circumventing the need for in-depth
network planning. To achieve this, a
way to automatically configure connectivity is needed.
When deploying a capillary network,
a sufficient number of capillary gateways need to be installed to provide a
satisfactory level of local connectivity.
Doing so should result in a certain level
of connectivity redundancy – a device
can get connected through several different gateways. Some systems (such as
electricity meter monitoring) need to be
in operation for years at a time, during
which the surrounding environment
may change; nodes may fail, additional
network elements may be added, and
even the surrounding physical infrastructure can change. But, by allowing
the capillary network configuration to
change, some slack in maintaining constant connectivity is built into the system, which allows it to adapt over time.
The key to maintaining connectivity and building flexibility into connected systems lies in optimal gateway
selection. The decision-making process
– what gateway a device chooses for connectivity – needs to be fully automated
and take into consideration a number
of network and gateway properties.
Network parameters – such as the
E R I C S S O N R E V I E W • 2/2014
14
quality of the cellular radio link and
the load in the cellular cell that a gateway is connected to – fluctuate, and so
a given capillary gateway will provide
different levels of backhaul connectivity at different times. Other considerations, like the amount of power a
battery-operated gateway has left, have
an impact on which gateway is optimal for a given device at a specific point
in time. Consequently, optimal gateway selection should not be designed
to balance load alone, but also to minimize delays, maximize availability
and conserve power. The gateway selection mechanism should support device
reallocation to another gateway when
the properties or the connectivity to a
gateway change. By designing gateway
selection to be smart, flexibility in connectivity is inbuilt, allowing systems
to continue to function as the environments around them evolve.
As illustrated in Figure 2, gateway selection relies on three different
types of information: connectivity, constraints and policy.
Connectivity information describes
the dynamic radio connectivity
between devices and gateways. Devices
typically detect connectivity by listening to the beacon signals that gateways
transmit. Some capillary short-range
radio technologies allow connectivity
to be detected by the gateway.
Constraint information describes the
dynamic and static properties of the network and the gateways that are included
in the selection process. Properties such
as battery level, load level (which can be
described by the number of connected
devices per gateway), support for QoS,
cost of use, and sleep schedule are all
included. The cellular backhaul connectivity of a gateway, such as link quality, can also be included, and future
enhancements might include properties such as cell load – obtained from the
management system of the cellular network. Devices may provide additional
constraint information, such as device
type, battery level, QoS requirements
and capillary network signal strength.
Policy information determines the
goal of gateway selection. A policy might
be a set of weightings or priorities that
determine how the various constraint
parameters affect the best choice of
gateway. Policy information may also
E R I C S S O N R E V I E W • 2/2014
include requirements set by the management system, such as allowing certain types of device to always connect
to given gateways. Policies are static and
are defined by network management.
The process of gateway selection
includes the following phases:
the information regarding connectivity,
constraints, and policy is gathered by
the element making the selection;
the gateway selection algorithm applies
the policies to the constraints while
taking connectivity into consideration
and determines the optimal gateway;
once a gateway has been selected for
each device, the selection is
implemented, which may imply that a
device needs to switch gateway; and
when a device moves to another
gateway, new routes to the device must
be set up in the cellular network so that
the incoming traffic is routed correctly.
The selection process can be controlled
at various locations in the network. The
location of control in turn affects the
need to transport information concerning constraints, policies and connectivity to the control point and to signal the
selection to devices.
If the control point is located in the
connected device, the device performs
the selection autonomously through
local computation based on information
sent by the gateway. As devices have just
a local view of the network, it may not
always be possible to optimize resources
globally and balance load across a group
of gateways.
If the control point is located in the
capillary gateways, the gateways need to
communicate with each other and run
the selection algorithm in a distributed
manner. This implies that gateways are
either connected via the capillary network, via the mobile network or via a
third network such as Wi-Fi, and use a
common protocol, like OSPF, for data
distribution. The main challenge here is
to reach convergence quickly and avoid
unnecessary iteration due to changes
in topology.
Alternatively the control point could
be a single node in the network that collects the entire set of available information. This centralized method enables
resource usage to be optimized globally
across the entire network. However, it
increases communication needs, as it
requires all of the capillary gateways to
communicate with a single point.
Managing QoS across domains
The QoS requirements for machinetype communication are typically different from those used for traditional
multimedia communication in terms
of bandwidth, latency and jitter. For
MTC, the requirement is often for guaranteed network connectivity with a
minimum throughput, and some use
cases may include stricter constraints
for extremely low latency.
For example, a sensor should be able
to reliably transmit an alarm within a
specified period of time after the detection of an anomaly – even if the network
is congested. To achieve this, low latencies are needed for real-time monitoring and control, while the bandwidth
requirements for this type of scenario
tend to be low. That said, QoS requirements for machine-type communication can vary tremendously from one
service to another. In some cases, like
surveillance, the QoS requirements are
comparable to those of personal multimedia communication.
QoS needs to be provided end-to-end.
So for the capillary network case, the
distinct QoS methods of both the shortrange network and the cellular network need to be considered. Each type of
short-range radio technology provides
different methods for QoS, which can
be divided into two main groups: prioritized packet transmission (for example,
in 802.11) and bandwidth reservation
(for example, in 802.15.4 and Bluetooth
Low Energy). As short-range technologies work in unlicensed spectrum, the
level of interference at any given time is
uncertain, which limits the level of QoS
that can be guaranteed. QoS methods
for the cellular networks that provide
connectivity, however, are well established and are based on traffic separation with customized traffic handling.
To provide QoS end-to-end, a bridge
is needed between the QoS domains of
the capillary and cellular networks. This
bridge specifies how traffic from one
domain (through a domain specific QoS
treatment) is mapped to a specific QoS
level in the other. The specifics of the
QoS bridge are determined in a Service
Level Agreement (SLA) established
between the providers of the capillary
15
FIGURE 2 Smart capillary gateway selection
3. Policies
Capillary
gateway
selection
Capillary
gateway
selection
1. Constraints
New communication path
4. (Re-) select gateway and
control communication path
2. Radio connectivity
Mobile
network
Mobile
network
M2M/IoT
cloud
Connected
devices
Capillary
gateways
network domain and the cellular connectivity domain, or between the service owner (in the data domain) and the
connectivity domain providers.
Security for connected devices
The devices deployed in capillary networks are likely to vary significantly in
terms of size, computational resources,
power consumption and energy source.
This variation makes implementing
and deploying security measures challenging. Security in capillary networks,
or within MTC in general, does not follow a one-size-fits-all model because
the constrained devices in the capillary
network are just that: constrained. It is
probably not possible to apply a generic
security solution: even if such a solution
ensures security in the most demanding
of scenarios, highly- constrained devices
will probably not have the resources to
implement it. What is needed is a security solution that fulfills the security
requirements of the use case at hand.
For example, a temperature sensor installed in a home is unlikely to
have the same strict security requirements as, say, a pacemaker or a sensor
in a power plant. A successful attack
on any one of these three use cases is
likely to yield drastically different consequences. So risk needs to be assessed
in the development of security requirements for the specific scenario, which
Old communication path
M2M/IoT
cloud
Connected
devices
Capillary
gateways
in turn determines what security solutions are suitable. The choice of a suitable security solution may then impact
the choice of device hardware, as it
needs to be capable of implementing
the selected security solution.
For end-to-end protection of traffic between authenticated end-points,
widely used security mechanisms such
as TLS would improve interoperability between constrained devices and
services that are already deployed. In
some cases, there might be a need for
more optimized security solutions to
be deployed, such as by using a protocol
that entails fewer round-trips or incurs
less overhead than legacy solutions.
Identification
When a device is installed in a capillary network, in most cases it needs to
possess some credentials – that is to say
an identity and something it can use
to prove it owns the identity, such as a
key. Typical solutions include public key
certificates, raw public keys or a shared
secret. With its stored credentials, the
device needs to be able to authenticate
itself to the services it wants to use –
such as a management portal through
which the device is managed, a data
aggregation service where the device
stores its data, as well as the capillary
gateway, which provides the device with
global connectivity.
One way to implement device identification and credentials is to use the
same method used in 3GPP networks
– basically the 3GPP subscription credentials. The subscription identity and
a shared secret that can be used for
authentication in 3GPP networks are
stored on the SIM card of the device. In
addition to using the credentials to get
network access, they can also be used
for authenticating the device to various services in the network. This can
be done using the 3GPP-standardized
Generic Bootstrapping Architecture
(GBA). For MTC scenarios, GBA is a good
solution, as it provides strong identification and communication security
without requiring any user interaction
or configuration at the device end; the
security is based on the 3GPP credentials stored in a tamper-resistant environment, to which not even the user has
direct access.
To apply GBA, first of all the device
needs to have 3GPP credentials; and
then the 3GPP network, the desired service as well as the device itself all need
to support GBA. Unfortunately, many
capillary network devices do not possess 3GPP credentials, which limits the
use of GBA to capillary gateways. In such
cases, the gateway can provide GBAbased authentication and security for
services on behalf of the entire capillary
network, but device authentication
E R I C S S O N R E V I E W • 2/2014
16
FIGURE 3 Security domains – bootstrapping and management
Capillary gateway security domain
Capillary device security domain
Connectivity security domain
Data security domain
Capillary network
Mobile
network
Connected
devices
M2M/IoT
cloud
Capillary gateway
Trust/business relationship
GBA-based security
Alternative
End-to-end security solution
still needs to be performed between
the device and the service.
Security domains
Capillary networks have two distinct
security domains, as illustrated in
Figure 3: the capillary devices and the
capillary gateway that provides widearea connectivity. The security domain
for devices can further be split into connectivity and data domains. The data
domain incorporates the device and
the services it uses, such as management and data storage, and the connectivity domain handles the interaction
between the device and the capillary
gateway.
The security domain for the capillary
gateway is based on the 3GPP subscription and the security that the subscription credentials can provide for access
services and 3GPP-aware services; for
example, through the use of GBA.
The two security domains intersect
at the capillary gateway; there is a need
for mutual trust and communication
security between the device and the
E R I C S S O N R E V I E W • 2/2014
gateway. At this intersection there is an
opportunity to apply the strong identification and security features of the 3GPP
network for the benefit of the capillary
device. If strong trust exists between
the device and the capillary gateway,
the security domains can be partially
merged to provide the device with 3GPPbased security for the GBA-enabled services it uses.
Bootstrapping
When a device is switched on or wakes
up, it may be able to connect to a number of capillary gateways, possibly provided by different gateway operators.
The device needs to know which gateway it has a valid association with and
which it can trust. Once global connectivity has been established, the device
also needs to know which services to
connect to. Capillary devices will be
deployed in the thousands, and as a consequence of their bare-boned architecture, they do not tend to be designed
with easy-to-use user interfaces. Manual
configuration of massive numbers of
capillary devices has the potential to
be extremely time consuming, which
could cause costs to rise.
Bootstrapping devices to their services using a bootstrap server is one
way of automating configuration and
avoiding the manual overhead. Such a
service, which could be operated by the
device manufacturer, would ensure that
the device is redirected to the selected
management service of the device
owner. During the manufacturing
process, devices can be pre-configured
with information about the bootstrap
server, such as how to reach it and how
to authenticate it. When switched on or
upon waking up, the device will connect
to the bootstrap server, which helps it to
find its current home.
If a device gets corrupted, or for
some reason resets itself, it can – once
rebooted – use the bootstrap server to
reach its current management portal.
From the management portal, either
the device owner or an assigned manager can configure the device with the
services it should use – and possibly even
provide the service specific credentials
to the device. This approach removes
the need to individually configure each
device, and can instead provide a centralized point for managing all devices,
possibly via batch management.
The ability to remotely manage
devices becomes significant when, for
example, 3GPP subscription information needs to be updated in thousands
of deployed devices. Today, 3GPP credentials tend to be stored on a SIM card,
and updating this information typically requires replacing the SIM card
itself. Embedded SIM cards (eSIM) and
SIM-less alternatives are now being
researched. While eSIM is a more MTCfriendly option, as it allows for remote
management of subscription information, SIM-less is of most benefit to constrained devices, to which adding a SIM
is an issue simply because they tend to
be quite small.
Network management
A range of tasks, such as ensuring automatic configuration and connectivity
– for devices connected through a capillary network – are fulfilled by network
management. In addition, network
management needs to establish access
control restrictions and data treatment
17
rules for QoS based on SLAs, subscriptions and security policies. In addition,
a service provider should be able to use
the management function to adapt service policies and add or remove devices.
By nature, connected devices are rudimentary when it comes to manual interaction capabilities. Additionally, the fact
that service providers tend to have no
field personnel for device management
implies that a remote management and
configuration interface is needed to be
able to interact with deployed devices.
Network management of connected
devices in capillary networks poses new
challenges compared with, for example,
the management of cellular networks.
This is partly due to the vast number of
devices, which are orders of magnitude
larger than the number of elements
handled by today’s network management systems. Instead of handling
devices as individual nodes, economy of
scale can be achieved by handling them
in groups that use policies and managed
parameters that are more abstract and
also fewer in number.
Consider the case of a service provider
that wants to reduce costs by replacing sensor batteries less frequently.
To achieve this, the service provider
increases the life length policy of the
node in the management system. The
management system interprets this policy and sets the reporting frequency to
every two hours, instead of every hour,
for a group of sensors in a particular geographical region.
Connected devices will often be battery powered, and so all operations,
including management, need to be
energy optimized to reduce the impact
on battery usage. Additionally, connected devices tend to sleep during
extended periods of time, and so management operations cannot be expected
to provide results instantly, but only
after the device wakes up.
A significant challenge for network
management is the provision of full endto-end scope, an issue that is particularly evident when different domains
in the end-to-end chain are provided
by different business entities – as discussed and indicated in Figure 1. Based
on analysis of the connectivity information provided just by the devices,
the connectivity state can only be estimated at a high level, extracted from
the information available at each end
of the communication path. Estimating
the connectivity in this way can lead
to a significant overhead to obtain and
maintain such information; it is also
limits the configuration possibilities of
the connectivity layer.
The best way to overcome this limitation is to interconnect the network
management systems in the different domains. In this way, connectivity information from the nodes along
the communication path, between the
end points, can also be included. If the
domains are operated by separate entities, this can be achieved through SLAs
specifying the usage and exchange
of information. The resulting crossdomain management provides end-toend management opportunities. For
example, QoS in both the capillary and
the 3GPP domains can be matched, and
alarms from both domains can be correlated to pinpoint faults.
Summary
As the Networked Society starts to take
shape, a vast range of devices, objects
and systems will be connected, creating
the Internet of Things (IoT). Within this
context, cellular networks have a significant role to play as connectivity providers, to which some things will connect
directly, and another significant portion will connect using short-range
radio technologies through a capillary
network.
Cellular networks can provide global
connectivity both outdoors and indoors
by connecting capillary networks
through special gateways. However,
achieving this will require some new
functionality.
Due to the massive numbers of connected things, functionalities – such as
self-configuring connectivity management and automated gateway selection
– are critical for providing everything
in the capillary network with a reliable
connection.
To ensure that communication
remains secure and trustworthy, a security bridge is needed between the capillary and the cellular domains. With this
functionality in place, a future network
can provide optimized connectivity for
all connected things anywhere no matter how they are connected.
References
1. Morgan Stanley, April 2014, Blue Paper, The ‘Internet of Things’ Is Now:
Connecting The Real Economy, available at:
http://www.morganstanley.com/views/perspectives/
2. J. Höller, V. Tsiatsis, C. Mulligan, S Avesand, S. Karnouskos, D. Boyle, 1st edition,
2014, From Machine-to-Machine to the Internet of Things: Introduction to a New
Age of Intelligence, Elsevier, available at:
http://www.ericsson.com/article/from_m2m_to_iot_2026626967_c
3. Alcatel Lucent, Ericsson, Huawei, Neul, NSN, Sony, TU Dresden, u-blox, Verizon
Wireless, White Paper, March 2014, A Choice of Future m2m Access Technologies
for Mobile Network Operators, available at: http://www.cambridgewireless.
co.uk/docs/Cellular%20IoT%20White%20Paper.pdf
4. Ericsson, NSN, April 2014, LTE Evolution for Cellular IoT, available at: http://www.
cambridgewireless.co.uk/docs/LTE%20Evolution%20for%20Cellular%20
IoT%2010.04.14.pdf
5. Emerging Telecommunications Technologies, April 2014, T. Tirronen, A. Larmo, J.
Sachs, B. Lindoff, N. Wiberg, Machine-to-machine communication with long-term
evolution with reduced device energy consumption, available at:
http://onlinelibrary.wiley.com/doi/10.1002/ett.2643/abstract
6. 3GPP, TR 36.888, June 2013, Study on provision of low-cost Machine-Type
Communications (MTC) User Equipments (UEs) based on LTE, available at:
http://www.3gpp.org/DynaReport/36888.htm
E R I C S S O N R E V I E W • 2/2014
18
Joachim Sachs
is a principal researcher at Ericsson Research. He joined Ericsson in
1997 and has worked on a variety of topics in the area of wireless
communication systems. He holds a diploma in electrical engineering
from Aachen University (RWTH), and a doctorate in electrical
engineering from the Technical University of Berlin, Germany. Since 1995 he has been
active in the IEEE and the German VDE Information Technology Society (ITG), where
he is currently co-chair of the technical committee on communication.
Nicklas Beijar
is a guest researcher at Ericsson Research in the Cloud Technologies
research area. He joined Ericsson in 2013 to work with the Internet of
Things and, in particular, he has been working on the capillary network
prototype demonstrated at Mobile Word Congress 2014. His current
focus is on cloud-based solutions supporting the IoT. He holds a D.Sc. in networking
technology from Aalto University and an M.Sc. from the Helsinki University of
Technology, both in Finland.
Per Elmdahl
is a senior researcher at Wireless Access Networks, Ericsson Research.
He holds an M.Sc. in computer science and technology from Linköping
University, Sweden. He joined Ericsson in 1990 researching network
management and network security. He served as an Ericsson 3GPP SA5
delegate for seven years, working on network management. While his interest in the
IoT began privately, he has worked on the subject professionally for the last two years,
specifically on network management and Bluetooth Low Energy.
Jan Melen
is a master researcher at Ericsson Research in the Services Media and
Network Features research area. He joined Ericsson in 1997 and has
worked with several 3GPP and IP related technologies. He studied at the
electrical engineering department at Helsinki University of Technology,
Finland. He has been involved in several EU projects, IETF and 3GPP standardization.
He has been leading the IoT related research project at Ericsson Research since 2011.
Francesco Militano
is an experienced researcher at Ericsson Research in the Wireless
Access Networks department. He joined Ericsson in 2011 to work with
radio architecture and protocols. At present, he is investigating the field
of M2M communications with LTE and capillary networks. He holds an
M.Sc. in telecommunications engineering from University of Siena, Italy, and a postgraduate degree in networks innovation and ICT sector services from the Polytechnic
University of Turin (Politecnico di Torino), Italy.
Patrik Salmela
is a senior researcher at Ericsson Research focusing on security. He
joined Ericsson in 2003 to work for Ericsson Network Security and
moved one year later to Ericsson Research, where he focused for several
years on the Host Identity Protocol. He has since been working on
security topics related to 3GPP, Deep Packet Inspection, and most recently, the
Internet of Things. He holds an M.Sc. in communications engineering from Helsinki
University of Technology, Finland.
E R I C S S O N R E V I E W • 2/2014
19
Authors
Communications as a
cloud service: a new take
on telecoms
Pages 4-11
Marc Vorwerk
joined Ericsson in 2000.
Today, he is a senior
specialist for cloud
computing, and has
previously worked on multi-access, IMS
and media-plane management
research – developing early prototypes
and participating in European research
projects. He began utilizing
virtualization and cloud over six years
ago, and has been an evangelist within
Ericsson to promote the benefits of
these technologies. Today as a senior
specialist he is a team leader, an
innovation event presenter and
provides customer-engagement
support. He holds an M.Sc. in electrical
engineering from RWTH Aachen
University, Germany.
Bart Jellema
joined Ericsson in 1989.
He has held several
system and product
management roles in
Canada, Germany and the Netherlands.
He currently works with the core
networks architecture and technology
team in the area of cloud and NFV, and
is involved in the establishment of
Ericsson’s new global ICT centers. He
has been active in standardization,
holds several patents and is a speaker
for Ericsson at innovation events. He
holds a B.Sc. in electrical engineering
from the University of Applied
Sciences, Eindhoven, the Netherlands.
E R I C S S O N R E V I E W • 2/2014
Can it be trusted?
20
Trusted computing for
infrastructure
The Networked Society is built on a complex and intricate infrastructure that brings distributed
services, data processing and communication together, combining them into an innovative and
more meaningful set of services for people, business and society. But combining services in such an
advanced way creates new requirements in terms of trust. Trusted computing technologies will play
a crucial role in meeting the security expectations of users, regulators and infrastructure owners.
M I K A E L E R I K S S ON, M A K A N P OU R Z A N DI A N D BE N S M E E T S
Today’s industries are in
transformation and ICT is
changing the game. New
applications built from a
combination of services,
communication and virtualization
are being rolled out daily,
indicating that the Networked
Society is becoming reality.
Communication is transitioning from
a person-to-person model to a system
where people, objects and things use
fixed and mobile connections to communicate on an anything-to-anything,
anywhere and anytime basis. But even
though people and businesses are beginning to use and benefit from a wide
range of innovative applications, the
potentially massive benefits that can
be gained by combining modern computing, web services and mobile communication have yet to be realized.
As we progress deeper into the
Networked Society, people, systems
and businesses will become ever more
dependent on an increasingly wider
range of internet and connected services. And so the fabric of the Networked
Society needs to be built on solutions
that are inherently secure, socially
acceptable and reliable from a technical point of view.
Modern internet services rely on
web and cloud technology, and as such
they are no longer independent packages with in-built security, but are constructed through the combination
and reuse of other services distributed
across the web. This creates new issues
BIOS basic input/output system
CBA Component Based Architecture
DoS denial-of-service
DRM Digital Rights Management
DRTM dynamic RTM
HE Homomorphic Encryption
MME Mobility Management Entity
OS operating system
PKI public key infrastructure
ROM read-only memory
RoT Root of Trust
RTM RoT for measurement
RTR RoT for reporting
RTS RoT for storage
SDN
software-defined networking
SGSN Serving GPRS Support Node
SGSN-MME Network node combining SGSN and MME functions
E R I C S S O N R E V I E W • 2/2014
SGX Software Guard Extensions
SICS Swedish Institute of Computer Science
SLA Service Level Agreement
SRTM static RTM
SSLA Security Service Level Agreement
TCB trusted computing base
TCG Trusted Computing Group
TEE Trusted Execution Environment
TLS Transport Layer Security
TPM Trusted Platform Module
TXT Trusted eXecution Technology
UEFI
Unified Extensible Firmware Interface
VM virtual machine
VMM virtual machine manager (hypervisor)
vTPM virtual TPM
in terms of security. One of the most
fundamental of these issues is securing processing in the communication
infrastructure so that it can be trusted.
Solving this issue is a prerequisite for
building trust relationships into a network fabric for data communication
and cloud computation. The red arrows
in Figure 1 illustrate possible trust relationships in such a network fabric that
connects servers, data centers, controllers, sensors, management services, and
user devices.
Trusted computing concepts
Users and owners of processing nodes
use trusted computing to assess the certainty of one or several of the following
aspects:
what the processing nodes do;
how nodes protect themselves against
threats; and
who is controlling the nodes.
This includes determining where data is
stored and processed – which can be significant when legal or business requirements related to data handling need to
be met.
This article presents an overview of
the technical solutions and approaches
for implementing trusted computing in
a telecommunications infrastructure.
Some of the solutions follow the concepts outlined in the Trusted Computing
Group (TCG) specifications. Together the
solutions described here enable what is
often referred to as a Trusted Execution
Environment (TEE), and with the addition of platform identities they provide
a means for secure access control and
management of platforms.
21
In this article, the term platform is
used to refer to the technical system for
computational processing, communication and storage entities; which can be
physical or virtual. The term infrastructure is used to refer to a wider concept,
normally consisting of a collection of
platforms and networks that is designed
to fulfill a certain purpose.
Ensuring that the implementation of
a technical system can be trusted calls
for assurance methodologies. How to
apply a security assurance methodology
to every stage of product development,
so that the implementation of a securityassurance product is in accordance with
agreed guidelines has been discussed in
a previous Ericsson Review article1.
A model for trust
The infrastructure, which is illustrated
in Figure 1, consists of servers, routers,
devices and their computational, communication and storage aspects. This
complex set of relationships can be redesigned using a cloud-based model – as
shown in Figure 2. While the cloud
model also consists of devices, access
nodes, routing units, storage, servers
and their respective management processes, the principles of trusted computing have been applied, and so the
building blocks of each entity include
trusted computing sub-functions.
Management functions govern the
behavior of the platforms through
a number of Security Service Level
Agreements (SSLAs). For example, an
SSLA might impose policies for booting, data protection or data processing.
Through a trustworthy component
known as Root of Trust (RoT), each entity
locally enforces and checks for SSLA
compliance. An RoT may be referred to
as a trusted computing base (TCB) or
trust anchor. It can be implemented
as a hardware component, or exposed
through a trusted virtual entity.
The RoT is one of the fundamental
concepts of trusted computing for providing protection in the cloud model
illustrated in Figure 2. Together with a
set of functions, an RoT is trusted by the
controlling software to behave in a predetermined way. The level of trust may
extend to external entities, like management functions, which interact
remotely with the RoT and contribute
to establishing a trustworthy system.
FIGURE 1 Examples of trust relationships in the Networked Society
Data center
Data center
management
Network
Network
management
Gateway
Routing
HSS
Server
management
Access
Device
management
How the terms trust and trustworthiness are interpreted can be quite complex. They may depend on the results
of an evaluation (such as Common
Criteria methodology for Information
Technology Security Evaluation1), or of a
proof, and may even depend on the reputation of the organization or enterprise
delivering the RoT. An RoT can provide
several functions, such as:
verification of data authenticity and
integrity;
provision and protection of secure
storage for secret keys;
secure reporting of specific machine
states; and
secure activation.
In turn, these functions allow features
such as boot integrity, transparent drive
encryption, identities, DRM protection,
and secure launch and migration of virtual machines (VMs) to be built.
The implementation of an RoT must
be able to guarantee a certain level of
assurance against modification. A good
example of this is the ROM firmware
that loads and verifies a program during a boot process. The TCG approach to
trusted computing relies on the interaction of three RoTs to guarantee protection from modification – each one with
a specific task (see Box C):
storage – the RoT for storage (RTS);
measurement – the RoT for
measurement (RTM); and
reporting – the RoT for reporting (RTR).
How these RoTs are implemented
is highly dependent on the Trusted
Platform Module (TPM) and the cryptographic keys that are used to secure
device hardware.
E R I C S S O N R E V I E W • 2/2014
Can it be trusted?
22
FIGURE 2 A trusted computing cloud model
Compute
(process)
Communicate
Storage
Run-time integrity, protection and privacy
Data integrity: at rest and in motion
Trusted compute initialization: boot integrity
Identity: personalization, provisioning
Measurement
The RoT for measurement – RTM – is
defined in the platform specification
and provides the means to measure the
platform state. It comes in two flavors:
static and dynamic – SRTM and DRTM,
respectively. Intel’s TXT, for example, is a
DRTM; it supports platform authenticity
attestation and assures that a platform
starts in a trusted environment. The
RTM is a crucial component for ensuring that a platform is in a trusted state.
In contrast to the reporting and storage
RoTs, the RTM resides outside the TPM –
see Box C. A DRTM can be used to bring
a platform into a trusted state while it
is up and running. Whereas the static
flavor starts out from a trusted point,
based on a fixed or immutable piece of
trusted code as part of the platform boot
process.
Chipset vendors and platform manufacturers decide what flavor the RTM
should be implemented in – static or
dynamic. The implementation of Intel’s
TXT, for example, includes many adaptations in the chipset, and even uses
Intel propriety code.
E R I C S S O N R E V I E W • 2/2014
A TPM is often implemented as a separate hardware component that acts as
a slave device. However, it can be virtualized, and in this case is often referred
to as a vTPM (see2, for example). To
implement an RoT, there are other solutions than strictly following the TCG
approach, such as those built using the
ARM TrustZone concept. TrustZone can
itself be used to implement an RoT as an
embedded TPM with the functions mentioned in Box C.
Business aspects
In the Networked Society, cloud computing and cloud-based storage will
be widely deployed. These technologies rely on a trustworthy network fabric; however, in a recent survey of the
Open Data Center Alliance, 66 percent
of the members stated that they are concerned about data security3. The upshot
of this has been a delay in the adoption
of cloud computing. Consequently, the
use of trusted computing in existing
and emerging cloud solutions is highly
desirable, as it will help to dispel the
fears associated with data security, lead
Management
SSLA
SSLA
SSLA
PKI
to increased service use and new business models, and create opportunities
for technological leadership.
Other business aspects influencing
trusted computing solutions include
requirements for scalability and elasticity of cloud computing, and the extent to
which processing will be self-governed.
In the cloud
Trusted computing in a cloud environment is a special case. Web services and
programmable routing technology
(SDN based) using infrastructures like
the one illustrated in Figure 1, will be
deployed on platforms that exploit virtualization. To ensure overall security
in the cloud, both the launch and the
operation of virtualized resources need
to be secure.
With respect to Figure 2, three
core features are essential for building trusted computing in a cloud
environment:
boot integrity – so that the hardware
platform can guarantee a trustworthy
RoT for the overall cloud environment;
secure management of VMs – to secure
the launch and migration of VMs in the
cloud environment; and
secure assessment of VMs – to attest
the security and trustworthiness of VMs
throughout their life cycles.
Boot integrity
To boot a platform in a trustworthy way,
a bootstrap process that originates from
an immutable entity – an RoT – must be
used. If the RoT provides proof of the
progress of the bootstrapping process
to the user in some transparent way, it
acts as a measurement RoT.
There are two main approaches to the
bootstrapping process: a verified boot or
a measured boot.
A verified boot actively attests each
component before it is loaded and executed. Using this approach, a platform
will either boot or fail, depending on
the outcome of the verification of each
component’s cryptographic signature.
Measured boot, on the other hand, is
passive. Here, each component is measured and progress reports are saved
into safe storage. The controlling process can then parse the recorded measurements securely and determine
whether to trust the platform or not.
Of the two approaches, only measured
23
boot complies with TCG; measurements
combined with attestation are referred
to as a trusted boot.
Both approaches can be used independently, or combined in a hybrid version
to extend the integrity of the boot to client applications – which is illustrated in
Figure 3. At Ericsson, ongoing work in
Component Based Architecture (CBA)
aims to establish a common approach
to boot solutions and signed software;
coordinating use in products.
Secure launch
Security-sensitive users need assurance
that their applications are running on a
trustworthy platform. Such a platform
provides a TEE and techniques for users
to attest and verify information about
the execution platform.
In some cases, clients may want to
receive an attestation directly from
the platform. To do this, users need to
be provided with a guaranteed level of
trust in hardware or the virtualization
layer during the initial VM launch, as
well as throughout the entire VM life
cycle – migration, cloning, suspension
and resumption.
To launch a VM in a secure way, the
security and trustworthiness of the
hardware platform and virtual layer
first need to be attested. For certain sensitive applications, like financial transactions or handling legal intercept, the
VM or the owner of the VM need to be
advised on the trustworthiness of the
hardware platform each time the hardware platform is changed – for example
following the migration, suspension or
resumption of a VM.
In a cloud environment, some additional security constraints may apply
to a VM launch. For example, due to the
risk of a side channel or a DoS attack,
some customers may require their virtual resources to be separated (not colocated) from any other customer’s
resources.
There are basically two of ways of
attesting a secure VM launch to clients:
the cloud provider can deploy the
trusted cloud and prove its
trustworthiness to the client; or
trustworthiness measurements can be
conveyed to the client – either by the
cloud provider or by an independent
trusted third party.
In the first approach, customers must
trust the cloud provider. The difficulty
with the second approach is the ability of a customer or trusted third party
to collect the trustworthiness evidence
related to the cloud providers – given
the dynamic nature of the cloud and
the diverse set of hardware, operating
systems (OSs) and VM managers (VMMs)
used. This task becomes even more complex because trustworthiness needs to
be reestablished and checked every
time a change occurs in the underlying
layers: hardware, OS, and VMM. It seems
inevitable that for the second approach
to work, cloud providers would have
to expose some, or all of their internal
hardware and software configuration,
including, say, hardware platform specifics, OS, VMM, and even configuration
information and IP addresses. This may
conflict with a cloud provider’s policy to
keep its internal architecture private.
The solution presented in Huebner
on Intel TXT4 is of the first type – based
on trust. Here, attestation is achieved
inside the cloud environment, and the
results are then provided to users.
The BIOS, OS, and hypervisor of the
hardware platform are measured, and
the results are sent to an attestation
server. The server in turn verifies their
trustworthiness by comparing them
against a known database of measurements. Following successful verification, the secure VM launch can then be
carried out.
When attestation is achieved through
the trust model, users cannot remotely
attest the hardware platform and consequently have to trust the cloud provider
and its attestation through SLAs.
To attest a secure VM launch using
the second approach – based on measurement – Ericsson security researchers have created a framework5,6 in
OpenStack to verify the trustworthiness of VM host system software
through remote attestation with a
trusted third party.
FIGURE 3 Hybrid boot process using an RoT for measurement
Platform
management
Proof – through signature
(for example)
Anti-malware software is
started before any third party
software
Login
Attestation
service
Client
Measurements
Third party
software/drivers
RTM
Kernel and
drivers
Anti-malware
software/drivers
Boot manager
firmware
Anti-malware
policy
UEFI boot
Boot policy
Client can fetch TPM
measurements of
client state
TPM
Measurements of components and
anti-malware software are recorded
in the TPM
E R I C S S O N R E V I E W • 2/2014
Can it be trusted?
24
FIGURE 4 Trusted computing attestation process
Open stack
BOX B Cloud
management
Trusted computing pool
4
1
2
3
Server
management
Secure migration
In a cloud environment, VM migration
is often necessary to optimize the use
of resources and ensure optimal power
consumption. This is a highly dynamic
process that depends on many factors,
including application needs, host loads,
traffic congestion, and hardware and
software failures. A secure VM migration ensures the security of the VM both
at rest and during the migration – guaranteeing the same level of trust before
and after. Similarly, cloud federation use
cases require interoperability guarantees among the different cloud service
providers. To achieve this, mechanisms
need to be in place to ensure the same
level of trust when a VM is migrated
from one cloud provider to another.
Migrating a VM can sometimes result
in a change of underlying hardware that
the VM is not aware of. This is significant, as the RoT function can depend
on both hardware and VMM (when it
comes to virtual TPM deployment for
VMs). Migrations are often performed
programmatically by cloud orchestration or management in a manner that is
transparent to the VM. So, cloud orchestration and management need to be
involved to choose the right physical
hosts and VMMs with adequate levels
of trust expressed in SSLAs to run VMs.
For regulation or auditing purposes,
preserving proof of trustworthiness of
E R I C S S O N R E V I E W • 2/2014
Scheduler
the platform needs to be provided for
security-sensitive applications. This use
case can be extended to a remote attestation of HW-VMM-VM to the tenant’s
auditor. There are two aspects related
to preserving trustworthiness:
ensure that the hardware and VMM after
the migration can be trusted to preserve
the same level of trust (trusted
computing base) for VM before and after
the migration; and
provide the same RoT functionality to a
VM before and after migration: for
example, protection and storage of
secret keys in a virtual TPM.
So far, secure VM migration has
received less attention than the secure
launch from both academia and industry. Despite this lack of interest, secure
VM migration is an essential part of the
overall secure life cycle of VMs, if satisfactory levels of security for applications
in the cloud are to be achieved.
Secure assessment
From a management point of view, the
platform needs to provide trustworthiness information and provide assurance
that it responds correctly to management commands. Remote assessment
of the platform state is of particular
importance to ensure that the launch
or migration of a virtual machine is carried out securely.
Trusted
computing
attestation
process
1) the Open
Attestation
Server
determines
a trusted
computing
pool;
2) cloud
management
requests new
workloads from
the scheduler;
3) the
scheduler
requests
the list of
trusted
computing
nodes in
the trusted
computing
pool; and
4) the workload
is initiated on
a computing
node inside
the trusted
computing
pool.
Obtaining assurance for every single functional aspect of the platform
and the services it hosts can be difficult.
Obtaining assurance for just a limited
set of functions can reduce the complexity of this task and be an acceptable
trade-off. Ideally, those aspects that have
security relevance should be expressed
in an agreement between the provider
and the user – typically detailed in an
SSLA, which might demand the support of remote assessment procedures.
For this, a platform should have a set of
mechanisms, like RTM coupled to RTR,
that allow a remote entity to securely
assess certain properties recorded by
monitoring capabilities of the platform’s local trustworthy subsystem. Yet
proper assurance methodologies have
to be applied to ensure that these mechanisms deliver what is needed without
any blind spots, which would result in a
false sense of security.
Implementation aspects
Standards
Although extensive academic work has
been carried out in the field of trusted
computing, only a few implementation standards exist for interoperable
trusted computing solutions. The TCG
has specified a framework and components for implementing trusted computing, which are used by chipset vendors
such as Intel and AMD. However, the
TCG specifications can result in varying
implementations by the different vendors, which is good, as different vendors
can optimize their solutions for different capabilities such as for performance
or for storage. While this flexibility is
advantageous, it also creates interoperability issues7. Flexibility has been
further increased in TPM 2.0 through
implementation and choice of cryptographic primitives. Currently, the TCG
specifications remain the most comprehensive standards for implementing RoTs.
Another important set of specifications has been issued by the
GlobalPlatform organization. Its TEE
specifications include architecture for
secure computation and a set of APIs.
Although these specifications provide
trusted computing for mobile devices,
they can also be used for infrastructure nodes such as base stations. How
the secured environment is actually
25
implemented is left to the discretion of
the hardware vendors and can be system-on-chip or a dedicated separate
component; ARM TrustZone is an example implementation of this technology.
As of mid-2014, the GlobalPlatform specifications do not address how a system
reaches a trustworthy state and how
trust properties can be asserted. With
this in mind, the GlobalPlatform and
TCG specifications complement each
other.
Hardware aspects
As illustrated by the Intel TXT implementation of the TCG DRTM concept,
several components in general purpose
chipsets must be modified to achieve
the needed protection. Similarly, the
protection provided by TrustZone
affects the ARM core as well as its subsystems. This level of invasiveness
results in hardware vendors sticking
to their chosen approach to trusted
computing, and changes to functionality tend to be implemented in a stepwise fashion. Intel and AMD have been
using TCG functionality, and ARM has
pursued its TrustZone concept and
announced cooperation with AMD.
Unfortunately, the TCG specifications
do not really cover the aspects of isolation of execution. To fill this gap, Intel
introduced the SGX concept, which is a
set of new CPU instructions that applications can use to set aside private regions
of code and data.
Isolation during execution is an
important principle, and future hardware will have more functionality to
improve isolation and control of the execution environments. The SGX concept
also supports attestation and integrity
protection, as well as cryptographic
binding operations per private region.
Homomorphic Encryption
In some (cloud) processing cases, it might
be possible to apply what is referred to
as Homomorphic Encryption (HE) as
an alternative to applying stringent
secrecy demands on processing nodes.
Current research in this subject and
similar techniques appear to be promising – leading to reasonably fast cloudbased processing of secret (encrypted)
data for certain operations without
needing to make the data available in
clear text to the processing node.
However, HE is a rather undeveloped technology; it only solves certain aspects of trusted computing, and
involves a level of computational complexity that is, generally speaking, still
too high. It may, however, become a
complementary technique for trusted
computing. If that happens, hardware
support for HE operations will likely
find its way onto server chipsets.
Examples of platform security
In cooperation with the Swedish
Institute of Computer Science (SICS),
Ericsson Research has modified
OpenStack to use a TPM for secure VM
launch and migration. A trusted third
party was used for collecting and sending trustworthy information and control. Part of the solution has been used
in a cloud-based test-bed setup for a
regional health care provider in southern Sweden.
Ericsson security researchers have
also implemented solutions for cloudbased protection of persistent storage8.
Generally speaking, secure VM launch
and migration are finding their way into
OpenStack.
The coming release of the Ericsson
SGSN-MME node is another example of
how trusted computing has been implemented using TPM technology. Beyond
the functionality discussed above, the
TPM is used for secure storage of PKI
credentials. These credentials are used
for TLS connections and for encryption
of sensitive data. Like other telco nodes,
the SGSN-MME has high-availability
requirements, which calls for the use
of hardware redundancy and efficient
maintenance procedures. As the TCG
specifications do not address such use
cases, special care must be taken when
deploying TPMs in such a setting: production, personalization, rollout, and
maintenance support have to be implemented before any of the trusted computing features can be enabled.
Conclusion
Ericsson recognizes that trusted computing is a technical approach that will
enable secure infrastructures and services for the Networked Society. As the
use of virtualization technologies and
the cloud increases, maintaining trust is
essential. In connection with the cloud,
the use of a virtual trusted platform
model as an RoT for different virtual
machines has received some attention from both academia and industry. Despite this, further development
is required to address issues related to
establishment of trust models, trusted
evidence collection, and real-time and
dynamic attestation. Ericsson Research
is active in this field and cooperates with
Ericsson business units to incorporate
such security solutions into products.
BOX C Three main TPM tasks
TPM
The TPM is responsible for protecting secret keys and sensitive functions. The bulk
of the TPM’s data is stored outside the TPM in so-called blobs. The RTS provides
confidentiality and integrity protection for these blobs. The RTR is responsible for:
reporting platform
configurations;
protecting reported
values;
providing a function for
attesting to reported
values; and
establishing platform
identities.
The interaction between the RTR and RTS relates to the responsibility for protecting
measurement digests. The term measurement has a specific meaning in TCG and can
be understood as verification in relation to RTM functions.
RTR
RTS
Protected
capabilities
Shielded
locations
RTM
E R I C S S O N R E V I E W • 2/2014
Can it be trusted?
26
Mikael Eriksson
is a security architect at Business Unit Cloud & IP. He holds an M.Sc. in
data and image communication from the Institute of Technology:
Linköping University, Sweden. He joined Ericsson in 2009 to work with
mobile broadband platforms after an 18-year career as a consultant,
mostly in embedded systems. Since 2012, he has been with the Packet Core Unit,
working on adaptation of security technology in mobile networks infrastructure. He is
currently the study leader of a boot integrity integration project of Ericsson platforms.
Makan Pourzandi
works at Ericsson Security Research in Montreal, Canada. He has more
than 15 years of experience in security for telecom systems, cloud and
distributed security and software security. He holds a Ph.D. in parallel
computing and distributed systems from the Université Claude Bernard,
Lyon, France, and an M.Sc. in parallel processing from École Normale Supérieure
(ENS) de Lyon, France.
Ben Smeets
is an expert in security systems and data compression at Ericsson
Research in Lund, Sweden. He is also a professor at Lund University, from
where he holds a Ph.D. in information theory. In 1998, he joined Ericsson
Mobile Communication, where he worked on security solutions for
mobile phone platforms. His work greatly influenced the security solutions developed
for Ericsson Mobile Platforms. He also made major contributions to Bluetooth
security and platform security related patents. In 2005, he received the Ericsson
Inventors of the Year award and is currently working on trusted computing
technologies and the use of virtualization.
References
1. Ericsson Review, Setting the standard: methodology counters security
threats, January 2014, available at: http://www.ericsson.com/
news/140129-setting-the-standard-methodology-counters-security-threats_244099438_c
2. Stefan Berger, Ramón Cáceres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doorn,
vTPM: Virtualizing the Trusted Platform Module, RC23879 (W0602-126) February 14, 2006, Computer
Science IBM Research Report, available at:
https://www.usenix.org/legacy/event/sec06/tech/full_papers/berger/berger.pdf
3. Tech Times, Cloud computing is the future but not if security problems persist, June 2014, available
at: http://www.techtimes.com/articles/8449/20140615/cloud-computing-is-the-future-but-not-ifsecurity-problems-persist.htm
4. Christian Huebner, Trusted Cloud computing with Intel TXT: The challenge, April 16, 2014, available at:
http://www.mirantis.com/blog/trusted-cloud-intel-txt-security-compliance/
5. Mudassar Aslam, Christian Gehrmann, Mats Bjorkman, Security and Trust Preserving VM Migrations in
Public Clouds, 2012 IEEE 11th International Conference on Trust, Security and Privacy in Computing and
Communications, June 25-27, 2012, available at:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6296062
6. Nicolae Paladi, Christian Gehrmann, Mudassar Aslam, Fredric Morenius, Trusted Launch of Virtual
Machine Instances in Public IaaS Environments, 15th Annual International Conference on Information
Security and Cryptology, 2013, available at:
http://soda.swedish-ict.se/5467/3/protocol.pdf
7. TrouSerS, the open source TCG Software Stack, I’ve taken ownership of my TPM under another OS...,
available at:
http://trousers.sourceforge.net/faq.html#1.7
8. Nicolae Paladi, Christian Gehrmann, Fredric Morenius, Domain-Based Storage Protection (DBSP)
in Public Infrastructure Clouds, 18th Nordic Conference, NordSec, October 18-21, 2013, available at:
http://link.springer.com/chapter/10.1007%2F978-3-642-41488-6_19#page-1
E R I C S S O N R E V I E W • 2/2014
Acknowledgements
The authors gratefully acknowledge the
colleagues who have contributed to
this article: Lal Chandran, Patrik Ekdahl,
András Méhes, Fredric Morenius,
Ari Pietikäinen, Christoph Schuba,
and Jukka Ylitalo
Re:view
27
25 years ago
The front cover of issue 4,
1989 depicted some of the
standardization organizations
of the time.
The associated article
discussed the role of
standardization in terms of
threats and opportunities,
concluding that the need
for it was more obvious
than ever. It noted that
Ericsson’s involvement in
standardization processes
Ericsson Review,
is necessary to be able to
issue 4, 1989.
influence the development of
technology.
50 years ago
Issue 4 in 1964 was dedicated to Ericsson’s new
telephone – the DIALOG. The design characteristics were
said to reflect the general
spirit of rationalization,
mechanization and functional
design permeating the era.
The telephone was starting to
play a central role in domestic
life and so not only its
functionality was addressed,
but also its appearance. Plugand-jack termination was
used to improve the mobility
of the device. Even at this
time, it was recognized that
Ericsson Review,
subscribers paying the same
issue 4, 1964.
amount for a given service
should enjoy the same quality
of transmission. The automatic regulation of transmission
level was an important step to reach this goal.
75 years ago
The fourth issue of 1939
carried an article on the neon
clock advertising department
store NK. Ericsson
constructed the illuminated
timepiece, claiming it to be the
biggest of its kind in Europe,
on Stockholm’s central
telephone tower. Despite a
subsequent fire in the tower,
the clock wasn’t damaged,
but was then moved to the NK Ericsson
Review,
store’s rooftop, where it still
issue 4, 1939.
stands today.
E R I C S S O N R E V I E W • 2/2014
High frequency small cell backhaul
28
heterogeneous networks
Deploying a heterogeneous network by complementing a macro cell layer with a small
cell layer is an effective way to expand networks to handle traffic growth. For rollout to
be successful, however, relies on being able to provide all the additional small cells with
backhaul capability in a flexible and cost-efficient manner.
M I K A E L COL DR E Y, U L R I K A E NG S T RÖM , K E WA NG H E L M E R S S ON, MONA H A S H E M I , L A R S M A N HOL M , P ON T U S WA L L E N T I N
A number of proprietary wireless
small cell backhaul solutions
have been adapted to provide
carrier-grade performance in nonline-of-sight (NLOS) conditions.
These solutions typically operate
in both licensed and unlicensed
spectrum in the crowded sub6GHz frequency range. However,
to cope with predicted traffic load
increases, the need to exploit
additional spectrum at higher
microwave frequencies has been
identified.
This need led to Ericsson researching
how NLOS wireless backhaul could be
used at 28GHz. This research1 showed
how wireless small cell backhaul could
be implemented in an urban scenario
without a direct line-of-sight (LOS) path
between the deployed small cells and
the macro radio base station (RBS) providing backhaul connectivity1, 2. The
Ericsson research showed how pointto-point (PtP) microwave in licensed
spectrum could be used for small cell
NLOS backhaul, and2 showed that
point-to-multipoint (PtMP) could also
be used for the same purpose.
Building on this research, Ericsson
has investigated the impact on user
performance in a heterogeneous network of providing small cell backhaul
over a wireless link – by comparing it
with a system in which small cell backhaul is provided over (ideal) fiber. To do
this, a study was carried out using system simulations that captured the joint
impact of backhaul and access technologies on user performance. Two different
NLOS wireless backhaul technologies
were tested: a commercial high-end PtP
microwave backhaul and an LTE-based
PtMP concept – at 6GHz and 28GHz.
Both technologies were assumed to
operate in licensed microwave bands.
The results of the simulations show
that wireless backhaul technologies can
provide user performance on a comparable level to a fiber-based (ideal) solution. The results demonstrate that NLOS
backhaul deployed in licensed spectrum up to 30GHz is a future-proof technology that can manage high volumes
of traffic in heterogeneous networks.
EIRP
equivalent isotropic radiated power
EPC
Evolved Packet Core
EPS Evolved Packet System
IMT
International Mobile Telecommunications
ISD
inter-site distance
LOSline-of-sight
MIMO
multiple-input multiple-output
MTC
E R I C S S O N R E V I E W • 2/2014
NLOSnon-line-of-sight
O&M
operations and maintenance
PtMPpoint-to-multipoint
PtPpoint-to-point
QAM
quadrature amplitude modulation
RAT
radio-access technology
UE
user equipment
WRC
World Radiocommunication Conference
Challenges created by small cells
Heterogeneous networks built by complementing a macro-cell layer with additional small cells in the RAN impose
new challenges on backhaul. For example, the best physical location for a small
cell often limits the option to use wired
backhaul. In urban areas, small cell
outdoor nodes are likely to be densely
deployed, mounted on lampposts and
building facades about three to six
meters above street level. If fiber exists
at the small cell site, it is the best option
for backhaul. But if fiber is not readily
available, deploying wireless backhaul
is both faster and more cost-effective.
Wireless backhaul is in itself nothing new, but small cell deployments
create new challenges for conventional
wireless backhaul, which was originally designed for LOS communication
from one macro site to another. In urban
environments and town centers, propagation paths between small cells and
macro sites are likely to be obstructed
by buildings, traffic signs and other
objects. Clear line-of-sight is highly
improbable. The number of users connected to each small cell might be just
a few, yet delivering superior and uniform user performance across the RAN
still requires a large number of small
cells. As a result, small cell backhaul
solutions need to be more cost-effective,
scalable, and simpler to install than traditional macro backhaul.
The dominant technology used in
backhaul networks today is based on
microwave – and predictions indicate
that this will continue to be the case. In
2019, microwave is expected to encompass about 50 percent of global backhaul
29
deployments3. The popularity of this
technology can be explained by the fact
that a microwave backhaul network
can be deployed quickly and in a flexible manner – two critical factors for
adoption.
The popularity of microwave has also
led to its extensive development over
the past few decades. For LOS deployments, microwave is capable of providing low cost, compact and easily
deployable backhaul capacity in the
order of several gigabits per second [4].
As mentioned, due to their placement
between street level and rooftop, a substantial portion of deployed small cells
will not have access to wired backhaul,
or have a clear LOS path to a macro site
with backhaul connectivity. These factors create a need for NLOS backhaul.
Solutions to the challenges posed
by NLOS conditions have already
been developed for microwave backhaul. Passive reflectors and repeaters
are sometimes used to propagate signals around obstacles in the communication path. However, this approach
is less desirable for cost-sensitive small
cell backhaul, as it increases the number of sites. Instead, providing singlehop wireless backhaul between a macro
site and a small cell site limits the number of sites needed, and is consequently
better suited to the small cell case. In
urban areas, daisy chaining can be used
to reach sites in difficult locations, and
this solution can also be used to advantage for small cell backhaul.
The propagation properties at lower
frequencies, below 6GHz, are well suited
for radio access. Consequently, modern
radio-access technologies (RATs) tend to
operate in licensed spectrum up to a few
gigahertz. Commercial microwave backhaul for macro sites operate at higher
frequencies – ranging from 6GHz to
70/80GHz. Operating small cell backhaul at these higher frequencies allows
spectrum in the lower frequency bands
to be used by radio access, which leads to
better spectrum utilization overall.
Joint access and backhaul
In 5G networks, it is likely that access
and backhaul will, to a large extent, converge: in some deployments, the same
wireless technology can be used effectively for both. This convergence may
lead to more efficient use of spectrum
FIGURE 1 Example of LTE-based PtMP backhaul system architecture
Macro RBS
and hub
3GPP
core
User
Small RBS
and client
resources, as they can be shared dynamically between access and backhaul5. For
other deployments, a complementary
and more optimized backhaul solution
might be the preferred choice to support 5G features, such as guaranteed
low latency at an extremely high reliability for mission critical MTC, as this
is more backhaul critical.
Another more high-level benefit of
convergence is the ability to use the
same operations and maintenance
(O&M) system for access and backhaul,
which can both improve overall system
performance and simplify system management. For example, a common network management that can combine
KPIs from the entire network can make
optimized decisions and take effective
action to improve overall performance.
Such KPIs include data rates, latencies, and traffic loads experienced by
the various nodes in a heterogeneous
network; including macro cells, small
cells, and backhaul. If not impossible,
such network performance optimization becomes extremely challenging if
the KPIs are inaccessible and the nodes
are uncoordinated. A common network
management system is, therefore, an
enabler for efficient operation of a heterogeneous network.
Irrespective of convergence, the costeffectiveness of backhaul connections
becomes increasingly important in
deployments that include large numbers of small cells. In general, deployments that have less hardware and
simplified installation procedures
are more cost-effective. So, as PtMP
User
backhaul connections simplify deployment, applying this technology is one
way to reduce costs.
In the present study, a system level
approach was used to evaluate the joint
effect of converged access and backhaul.
A complete heterogeneous LTE RAN
deployed in a dense urban scenario was
simulated encompassing macro cells,
small cells, small cell backhaul, users,
traffic models, propagation, interference, and scheduling effects. Using such
an advanced simulation environment
makes it possible to evaluate overall system and user performance for different
small cell backhaul scenarios in a way
that captures the joint impact of access
and backhaul.
Backhaul technologies
for small cells
The various technologies that exist
for wireless backhaul can be classified
into two main solution groups: PtP and
PtMP. A PtP solution uses dedicated
radios and narrow-beam antennas to
provide backhaul between two nodes.
In a PtMP solution, one node provides
backhaul to several other nodes by sharing its antenna and radio resources. As
illustrated in Figure 1, the nodes in a
PtMP scenario are referred to as hub
and client, where the hub is typically
colocated with a macro site (that has
backhaul connectivity) and the client is
colocated with a small cell site.
Spectrum
Irrespective of the technology deployed,
user performance is directly
E R I C S S O N R E V I E W • 2/2014
30
FIGURE 2 NLOS wireless backhaul client/hub – urban deployment
Hub
Hub
Client
Client
related to optimal use of spectrum.
The 2015 World Radiocommunication
Conference (WRC-15) will focus on the
future allocation of additional spectrum below 6.5GHz for radio access.
Looking at current spectrum allocation,
these frequencies are crowded, which
means that the potential for more backhaul bandwidth in licensed spectrum
is greater for frequencies above this.
Backhaul based on Wi-Fi and LTE are
just two of the current technologies
operating below 6GHz. Wi-Fi typically
operates in unlicensed spectrum and is
therefore prone to interference while,
for example, LTE relaying exploits
licensed IMT spectrum for both backhaul and access.
Using unlicensed frequency bands
might be a tempting option to reduce
cost, but this approach can result in
unpredictable interference issues that
make it difficult to guarantee QoS. The
potential risk associated with unlicensed use of the 60GHz band is, however, lower than the risk associated with
the popular 2.4GHz and 5GHz bands.
This is due to very high atmospheric
attenuation caused by the resonance of
oxygen molecules around 60GHz and
the possibility to use compact antennas with narrow beams – which reduce
interference effectively.
The conventional and spectrum-efficient licensing policy for PtP microwave
backhaul works on an individual linkby-link licensing basis6. However, when
it comes to rolling out small cell backhaul, simplicity, multipath interference
E R I C S S O N R E V I E W • 2/2014
issues, and cost are of such importance
that other policies for licensing should
be considered.
Light licensing and block licensing
are two possible alternatives. In the
light licensing case, license application
is a simple and automated process that
involves only a nominal registration
cost. This approach can be used in scenarios where interference is not a major
concern or can be mitigated by technical means6. It has become popular to use
light licensing to encourage the uptake
of PtP E-band links. If properly deployed,
these communication links do not interfere with each other due to high atmospheric absorption and narrow beam
widths.
In block or area licensing, the licensee
has the freedom to deploy a radio emitter within a given frequency block and
geographic area as long as the radio fulfills some basic requirements, such as
respecting the maximum equivalent
isotropic radiated power (EIRP). In this
case, the licensee is responsible for managing co-channel interference between
different transmissions and making it
suitable for managing PtMP backhaul
and radio access systems7.
Being able to exploit the spectrum
potential offered by higher frequency
bands from 10GHz to 100GHz is part
of ongoing research for 5G5,8. The high
propagation losses that are associated with high-frequency millimeter
waves typically limit the applicability
of such high frequency bands to shortrange links. These losses can be partly
compensated for with more advanced
antenna systems using beamforming.
However, this makes mobility at high
speeds (such as in cars and on highspeed trains) more challenging, as
beams would need to be adapted more
or less continuously.
Wireless backhauling of fixed nodes
is less of a challenge, as alignment or
beam pointing is more straightforward
when nodes are situated in predefined
fixed locations than when they are constantly moving – and so the application
of higher frequencies is simpler.
Capacity and availability
Backhaul capacity is often dimensioned to support the peak capacity of
the macro cell9. However, in practice,
the trade-off between cost and the need
for capacity usually results in a more
practical level for backhaul capacity
being set. This level should, at a minimum, support expected busy-hour traffic, with some margin to account for
statistical variation and future growth.
Dimensioning in this way makes sense
when it comes to cost-sensitive small
cell backhaul. However, it is recognized
that different operators – to align with
their business strategy – are likely to use
different approaches for capacity provisioning of small cell backhaul.
Today’s minimum bitrate targets
for backhauling 3GPP LTE small cells
is somewhere in the region of 50Mbps
for radio access using 20MHz of spectrum. To support current peak rate
demands, however, 150Mbps or more is
desirable9. These targets for minimum
and peak bitrates are likely to increase
further over the next few years as traffic volumes continue to rise, and additional spectra and new features for radio
access become available. In addition,
small cell access points may not only be
required to support multiple 3GPP technologies (such as HSPA and LTE) but may
also include Wi-Fi, which will further
increase the need for backhaul capacity.
Availability requirements may differ between small cell and macro cell
backhaul, depending on the deployment scenario. The availability requirement for macro backhaul can be as high
as 99.999 percent (which corresponds to
a maximum of five minutes of outage
per year). For small cell backhaul, such
high availability requirements may not
31
be necessary. If the small cell is deployed
to boost data rates or capacity in an area
with existing macro coverage, the backhaul requirements could be relaxed significantly to, for example, 99-99.9 percent
(which corresponds to anywhere from 12
hours up to several days of outage per
year)8.
From a user perspective, the performance of an individual backhaul link is
less relevant. What matters is the overall performance of the combined backhaul and access links. If the access link
at a given time and place provides a certain level of service, the corresponding backhaul link does not need to be
significantly better. Hence, the access
and backhaul links could be jointly
optimized. To reflect this in the present study, the joint effect of access and
backhaul on user performance was evaluated, using an all LTE-based backhaul
concept operating at higher frequencies that is more integrated with the
LTE access than conventional wireless
backhaul.
Antennas
Maximum antenna gain is given by the
antenna size in relation to the wavelength of the frequency used. As a result,
antennas that are smaller in size than
antennas with the same antenna gain
at lower frequencies can be deployed at
higher frequencies. If aligned correctly,
a compact high-gain antenna can compensate for the increased path loss that
is usually associated with higher frequencies and NLOS conditions.
A PtP system uses high-gain antennas at both ends of a link, while a PtMP
system uses a wide-beam antenna at the
hub site and a directive antenna at the
client site.
More advanced antenna solutions at
the hub site, such as steerable or fixed
narrow multi-beam systems, can be
deployed, but such solutions will probably not be cost-effective for some time.
Carrying out manual antenna alignment with narrow beam widths in
NLOS conditions may sound like a difficult task, but it can be a surprisingly simple procedure, even at 28GHz1. However,
as correct alignment is important, especially at higher frequencies, it may be
a good idea to deploy a client antenna
that has automatic beam-steering capabilities, so that it can simply align itself
to the best signal path. Beam steering
can be implemented using mechanical
methods, antenna arrays or a combination of the two.
LTE-based backhaul concept
To address the issue of providing backhaul in heterogeneous networks, a new
concept is being researched based on
the adaptation of LTE technology for
small cell backhaul at high microwave
frequencies – evaluated at 6GHz and
28GHz.
This concept reuses the LTE physical
layer but applied at a higher frequency
band – up to 30GHz. As LTE physical-layer numerology was originally
designed to operate with a carrier frequency of around 2GHz, operation in
higher bands requires some modification of the original concept. But if top-ofthe-line hardware is in place, the need to
change the numerology (by increasing
the subcarrier spacing, for example) for
frequencies below 30GHz in a backhaul
context is small. However, to reduce
hardware costs, numerology may need
to be adjusted to match higher microwave frequencies. This concept is part
of 5G radio access research5.
With a 3GPP LTE-based PtMP solution, backhaul links can inherit 3GPP
functionality already developed for
LTE access, as well as features that will
be implemented in the future, such as
carrier aggregation, reduced latency,
advanced schemes for beamforming,
MIMO, interference cancellation and
radio resource scheduling. When backhaul and access links are converged,
operational efficiency can be increased,
as the overhead created by managing
different technologies is reduced. For
example, the control and management
architecture as defined by the 3GPP
Evolved Packet System (EPS) can be used
by both systems.
An example system architecture for
LTE-based PtMP backhaul is illustrated
in Figure 1. The basic principles of this
architecture include interfaces, protocols, the reuse of 3GPP logical nodes,
EPS bearer concept, as well as security
solutions.
As Figure 1 illustrates, the small RBS
is connected to a client. The client provides the wireless backhaul IP-based
transport to the core network, which
in turn provides functions like bearer
management, QoS enforcement and
authentication. The client terminates
the LTE radio interface and implements UE functions such as cell search,
measurement reporting, and radio
transmission and reception. The hub
implements the eNodeB side of the LTE
radio interface. In this example, both
the hubs and the clients are controlled
by a 3GPP-based EPC network – which
can be a core network dedicated to backhaul, or a core network shared between
the small RBS and the access links.
While there are similarities between
an all-LTE network (backhaul plus
access) and the LTE relay solution developed in 3GPP (which also provides backhaul based on an LTE radio interface),
there are two main differences between
them. First, LTE backhaul has been modeled as a transport network. As such, it
is access-agnostic and can be used with
any access link technology. LTE relay on
the other hand has been designed to use
LTE link technology for both backhaul
and access. The second difference is that
LTE backhaul links and LTE access links
typically use separate radio resources
(separated in terms of frequency bands),
while the (in-band) LTE relay solution
shares radio resources between the
backhaul and access links.
In summary, an LTE-based PtMP
backhaul provides several benefits compared with other alternatives:
reuse of functionality – inherent
multiple access (PtMP), architecture,
protocol structure, physical layer,
procedures, and security mechanisms
are just some examples of functionality
already developed in 3GPP;
quick launch of new features – by
reusing existing (and future) LTE
developments, new features can also be
rapidly deployed;
use of the same ecosystem – one system
for both backhaul and access links can
simplify O&M for operators and increase
operational efficiency;
support for multi-RAT access links –
compared with LTE relaying solutions,
any RAT can be used on the access link;
joint backhaul-access link optimization
– added value can be achieved through
dynamic optimization and operation of
access and backhaul targeting user
performance. A high level of integration
and potentially shared hardware are
E R I C S S O N R E V I E W • 2/2014
32
FIGURE 3
European deployment scenario
Throughput
Path loss
Mb/s
dB
120.0
110.0
100.0
90.0
80.0
70.0
60.0
50.0
40.0
30.0
20.0
10.0
0.0
130.0
120.0
110.0
100.0
90.0
80.0
70.0
60.0
50.0
40.0
30.0
20.0
Small RBS and client site
US deployment scenario
Throughput
Path loss
Mb/s
dB
120.0
110.0
100.0
90.0
80.0
70.0
60.0
50.0
40.0
30.0
20.0
10.0
0.0
130.0
120.0
110.0
100.0
90.0
80.0
70.0
60.0
50.0
40.0
30.0
20.0
Macro RBS and hub site
Small RBS and client site
other potential benefits of converged
links; and
automated deployment – installation
procedures similar to those used to set
up a small RBS (which today is
automatic) and can also be used to
install the backhaul client.
Evaluation scenarios
In this study, heterogenous networks
were simulated using macro and small
cells for radio access and hubs and clients for wireless backhaul deployed in
E R I C S S O N R E V I E W • 2/2014
building heights are assumed to be
homogenous, ranging from 5m to 40m;
no high-rises;
few open areas;
19 macro/hub sites with an average ISD
of 400m; and
76 small RBS/client sites.
The US city environment is more challenging, assuming that:
a downtown area exists with high-rises
as well as surrounding low buildings,
with open spaces in between;
building heights range from 4m to
288m;
19 macro/hub sites with an average ISD
of 700m; and
114 small RBS/client sites.
Macro RBS and hub site
FIGURE 4
PtMP concept (described in this article). Figure 2 illustrates the simulation
scenario, showing two hubs providing
wireless backhaul to two clients in an
urban environment.
Some assumptions were made about
the nature of the virtual cities. For the
European city:
two virtual cities. These cities aimed to
represent a typical European scenario
with a dense macro deployment and
a typical US scenario with downtown
high rises and a sparse macro deployment with a greater number of small
cells per macro.
The macro RBSs and backhaul hubs
were colocated at the same site, as were
the small RBSs and clients. The clients
were located above street level and backhauled wirelessly to a serving hub using
either PtP microwave or the LTE-based
Figures 3 and 4 illustrate a portion
of the deployments for the virtual
European and US cities. The left side
of each figure shows the results of the
macro-only network, and the right side
shows the results of a combined macro
and small cell deployment that uses
LTE-based PtMP backhaul at 28GHz.
The colors of the cells indicate average
user throughput, according to the scale
on the left. The line between a hub and
a client shows the strongest propagation path, and the color of the line indicates its path loss. The improvement in
throughput, illustrated by the amount
of green in the illustrations, due to
offloading of the macro in the small cell
deployment is considerable. The simulated served traffic levels in the network
are 20GB/month/user in the European
scenario and 6GB/month/user in the US
scenario.
For LTE access, the simulated carrier frequencies were set to 2.1GHz in
the European scenario and 700MHz in
the US scenario. The access bandwidth
was 20MHz in both cases, which corresponds to a peak rate of 108Mbps using
2x2 MIMO. The macro RBS output
power was assumed to be 2x30W and
the small RBS output power to be 2x5W.
High-gain backhaul antennas were
used to compensate for the greater NLOS
33
path loss at higher microwave frequencies. In the PtP evaluations, mechanically steerable high-gain antennas were
used at both the hub and client sites,
while for PtMP evaluations, the hub was
implemented using fixed sector-covering antennas. Antenna parameters and
output power of hub and client for the
different backhaul systems and carrier
frequencies are summarized in Table 1.
For PtMP, 20MHz of bandwidth at two
frequencies were evaluated – 6GHz and
28GHz – while only 28GHz was considered in the PtP case. The LTE-based PtMP
used fixed output power in the downlink, while PtP used adaptive power
control.
Methodology
User performance including wireless
backhaul was evaluated in a static system simulator. In the simulator, LTE
access was based on LTE Rel-8 with 2x2
MIMO and 64QAM in the downlink,
which corresponds to a downlink peak
rate of 108Mbps when using 20MHz of
access bandwidth. The wireless backhaul, including LTE-based PtMP and
commercial PtP microwave, were also
simulated using 20MHz bandwidth. In
one simulated case, 40MHz was also
used for the LTE-based PtMP backhaul
for the more challenging US scenario, to
illustrate the use of the LTE feature carrier aggregation on the backhaul.
User-generated traffic for both simulation scenarios was split on an 80/20
basis – 80 percent generated by indoor
users and 20 percent by people outdoors.
Indoor users were evenly distributed
among the floors of the buildings, and
traffic load was measured in terms of
data traffic consumed by one user in one
month. For each scenario and deployment, as traffic load increased, the traffic served by the system increased until
the system reached its capacity limit.
This limit depends on the scenario and
the deployment, including the number
of macro RBSs and small RBSs deployed.
To put some perspective on the traffic
load, 2014 levels for actual mobile traffic
are in the region of 1.5-2GB /user/month
in Europe and the US. Mobile data traffic is expected to grow globally by 45
percent annually 2013-2019, so by the
end of 2019, mobile traffic will be somewhere around 10GB /user/month3.
User throughput is given by the size
of a data packet and the total transmission time of the packet. The transmission time takes into account any
delay due to resource sharing: multiple users accessing the same radio
resources. Each user is served either by
a macro or by a small RBS. For those
served by a macro, only resource sharing on the access side has an impact on
throughput. For users served by small
RBSs, aside from the resource-sharing
delay on the access side, there is also a
resource-sharing delay associated with
the wireless backhaul. Resource sharing in the backhaul results from either
multiple users connected to the same
small RBS – which means they share its
backhaul connection – or from users
connected to different small RBSs that
share a common backhaul connection
in a PtMP situation. As each PtP backhaul link has an individual (not shared)
backhaul resource, PtP backhaul is only
shared by users connected to the same
small RBS. However, the PtMP backhaul
may be shared by users connected to different small RBSs that are connected to
the same hub sector. Hence for small
RBS users, user performance depends
not only on the access but also on the
type of backhaul that carries the small
RBS traffic.
Wrap up
European city scenario
Figure 5 shows user throughput (in
the downlink) against served traffic
for the European scenario. The curves
represent the macro-only network (blue
curves) as well as heterogeneous networks with three different small cell
backhaul technologies (yellow, red and
purple curves), according to:
yellow – PtP microwave at 28GHz with
20MHz bandwidth;
red – LTE-based PtMP at 28GHz with
20MHz bandwidth; and
purple – LTE-based PtMP at 6GHz with
20MHz bandwidth.
The reference performance levels for
fiber backhaul (green curve) are also
shown. The 10th percentile represents
the 10 percent worst case rates experienced by users, the 50th represents the
median, and the 90th percentile represents the top 10 percent downlink performance rates.
The immediate conclusion from this
is that small cell deployment can radically improve user throughput, especially at high traffic levels where the
macro-only network cannot meet the
demand.
When looking at the served traffic levels, the network has a very good
macro deployment, as it alone can serve
10GB/user/month while maintaining a
10th percentile downlink user throughput of about 10Mbps. By deploying small
cells, the corresponding user throughput is increased to 30Mbps, or the 10th
percentile at 10Mbps is maintained,
while the network serves as much as
23GB/user/month.
Table 1: Antenna parameters and output powers for the different backhaul systems
Node type
Frequency
[GHz]
Antenna
type
Azimuth
HPBW1
[degrees]
Elevation
HPBW1
[degrees]
Max. gain
[dBi]
Aperture
size
Max. power
[dBm]
28
Sector
65°
5°
20
1.5 x 12.5 [cm2]
23
6
Sector
65°
5°
20
6.5 x 54 [cm2]
23
28
Parabolic
reflector
3°
3°
34
Diameter = 20 [cm]
23
6
Patch array
14°
14°
22
20 x 20 [cm2]
23
28
Parabolic
reflector
3°
3°
34
Diameter = 20 [cm]
23
PtMP hub
PtMP client
PtP client
and hub
1
half power beam width
E R I C S S O N R E V I E W • 2/2014
34
As expected, the choice of small
cell backhaul has almost no impact on
the worst case 10th percentile, as these
users are more limited by the access
network than by the backhaul. Small
backhaul limitations only occur for the
median (50th percentile) and best (90th
percentile) users connected via PtMP
backhaul – observed by small penalties
compared with fiber. The PtP backhaul
shows close-to-fiber performance for all
users and served traffic levels. It is also
noticeable that all backhaul options can
cope with the user peak rates (108Mbps)
achieved at lower loads (90th percentile
and below 10GB/month/user).
The variation in performance
between PtP and PtMP wireless backhaul is due to two primary differences
in these systems. Firstly, two different
antenna systems are used, where PtMP
has wide-beam sector antennas at the
hub, while PtP has directive high-gain
antennas at both ends of each link. The
PtMP sector antenna has a much lower
antenna gain than the narrow beam
PtP antenna – 14dB lower, as shown
in Table 1. Secondly, there is less sharing of resources in the PtP backhaul,
where each client has its own dedicated
resource, while the PtMP system may
also share its resources over multiple clients. In the simulated PtMP case, a hub
has three sectors and each sector may
serve one to five clients depending on
the traffic load in that sector.
Finally, the performance levels of the
PtMP backhaul operating at 6GHz and
28GHz are almost identical. Both systems have identical antenna gain and
beamwidth at the hub, while the 6GHz
system has 12dB lower antenna gain
and wider beamwidth at the client. On
the negative side, a lower antenna gain
results in worse system gain and a wider
beamwidth is more prone to interference. However, on the positive side, the
6GHz system experiences less path loss,
which compensates the negative side.
FIGURE 5 European scenario
User throughput (Mbps)
120
Macro
Fiber
PtP microwave; 28GHz, 20MHz
LTE-based PtMP; 28GHz, 20MHz
100
50th percentile
90th percentile
80
60
40
10th percentile
20
0
0
5
10
15
20
25
30
35
40
Served traffic (GB/month/user)
E R I C S S O N R E V I E W • 2/2014
US city scenario
Figure 6 presents the downlink user
throughput against served traffic in the
US city. The network capacity in this
scenario is limited by the macro network since the macro network is much
sparser than the European city. This
is observed in the much lower served
traffic values and the poor macro-only
performance. Deploying small cells
improves the network performance
substantially.
Also in this scenario, worst case user
perfomance (10th percentile) is limited
by access and not by backhaul, so the
choice of backhaul has no impact on
worst case user throughput. But when
looking at best case user performance
(90th percentile), there is a clearer backhaul limitation when using PtMP backhaul with 20MHz bandwidth at higher
served traffic levels. A remedy for
improving PtMP performance for high
performance users is to apply the LTE
feature carrier aggregation in the LTEbased PtMP backhaul. Figure 6 shows
the result when a 40MHz bandwidth
is applied to the backhaul at 28GHz
and the user performance is improved
and PtMP with carrier aggregation is
on a par with PtP microwave and fiber.
Thanks to reduced resource sharing and
high-gain antennas at both ends, the PtP
backhaul also shows close-to-fiber performance for all users and served traffic
levels in this scenario.
When comparing PtMP at 6GHz
to 28GHz, some degradation for high
throughput users is observed in the
90th percentile at high traffic levels
in Figure 6. This is due to the different antenna characteristics, where the
antenna gain at 28GHz is 12dB higher at
the client side than it is at 6GHz and the
wider client antenna beam at 6GHz has
less spatial filtering of interference compared with the 28GHz client antenna.
Summary
Deploying small cells provides a means
for handling future traffic growth and
enables a substantial improvement in
network performance. It is therefore of
great importance to enable small cell
deployments by providing cost-effective backhaul. The study carried out
addresses some of the challenges created by small cell backhaul. By using system simulations that capture the joint
35
effect of access and backhaul, it has
been shown that NLOS microwave backhaul in licensed spectrum up to 30GHz
is a viable solution for dense small cell
deployments in urban environments.
A novel LTE-based NLOS PtMP backhaul concept operating at high microwave frequencies, up to 30GHz, has also
been evaluated. This concept is a potential step toward using LTE at higher frequencies and converging access and
backhaul networks, which is also foreseen in 5G networks.
System simulations for two different
deployment scenarios show that degradation in user performance is minimal
when wireless backhaul is compared
with (ideal) fiber backhaul – for lower
to medium throughput users. For high
throughput users, the performance of
the LTE-based NLOS PtMP backhaul concept is not as good as the PtP microwave
backhaul – which shows close-to-fiber
performance for all users and served
traffic levels due to greater numbers of
radio and antenna resources. The LTEbased NLOS PtMP backhaul was evaluated both at 6GHz and 28GHz, and
28GHz works just as well or even better
than 6GHz.
In the more challenging US deployment scenario, the performance degradation with LTE-based PtMP was
rectified by applying larger bandwidth
in the microwave backhaul by using carrier aggregation, which is inherent in
LTE, bringing it up to par with NLOS PtP
and fiber backhaul.
FIGURE 6 US scenario
User throughput (Mbps)
120
Macro
Fiber
PtP microwave; 28GHz
100
80
60
90th percentile
90th percentile
40
50th percentile
20
10th percentile
50th percentile
10th percentile
0
2
4
6
8
10
12
14
Served traffic (GB/month/user)
E R I C S S O N R E V I E W • 2/2014
36
Mikael Coldrey
Mona Hashemi
holds an M.Sc. in applied physics and electrical
engineering from Linköping University, Sweden, and a Ph.D.
degree in electrical engineering from Chalmers University of
Technology, Gothenburg, Sweden. He joined the Radio
Access Technologies department within Ericsson Research in 2006,
where he is a senior researcher. He has been working with both 4G and
5G research. His main research interests are in the areas of advanced
antenna systems, models, algorithms, and millimeter wave
communications for both radio access and wireless backhaul systems.
Since 2012, he has also been an adjunct associate professor at Chalmers
University of Technology.
joined Ericsson Research in 2010 after completing her
M.Sc. in wireless and photonics engineering at Chalmers
University of Technology, Gothenburg, Sweden the same
year. She holds an experienced researcher position at
Ericsson Research, and has been involved in a variety of projects, such
as the NLOS wireless backhaul, and the EARTH project founded by the
Seventh Framework Programme (FP7) of the European Commission.
Currently, she is working on standardization and concept evaluation
for LTE.
Ulrika Engström
Lars Manholm
received his M.Sc. in electrical engineering, and his
Lic. Eng. in electromagnetics from Chalmers University of
Technology, Gothenburg, Sweden in 1994 and 1998,
respectively. He joined Ericsson as an antenna designer in
1998 and moved to Ericsson Research in 2003. He is currently working
as a senior researcher focusing on antennas for millimeter wave and
higher microwave frequencies.
Ke Wang Helmersson
joined Ericsson Research in 1995 and is currently
working in the Wireless Access Networks department at
Ericsson Research in Linköping, Sweden, where she is a
senior researcher in RRM and system-level simulations, as
well as performance evaluations. She has been involved in research
and development efforts for EDGE, HSPA and LTE and wireless
backhaul technologies. She is currently working on future wireless
industrial applications in the 5G program. She holds a Ph.D. in electrical
engineering from Linköping University, Sweden.
received a Ph.D. in physics from Chalmers University of
Technology, Gothenburg, Sweden, in 1999, and an M.Sc. in
physics and engineering physics, also from Chalmers in
1994. She joined the antenna research group at Ericsson
Research in Gothenburg, Sweden in 1999. Her main research focus is
antenna systems, targeting wireless backhaul challenges for small
cells, LTE and 5G. She has had a variety of roles in, for example,
Ericsson’s testbed development and system evaluations, including
serving as project manager of several successful research projects
within Ericsson Research. She is currently driving studies within the 5G
program at Ericsson.
Pontus Wallentin
is a master researcher at Ericsson Research, wireless
access networks. He joined Ericsson in 1988 working with
GSM and TDMA system design. Since joining Ericsson
Research in 1996, he has focused on concept development
and 3GPP standardization of 3G WCDMA/HSPA and LTE. He holds an
M.Sc. in electrical engineering from Linköping University, Sweden.
References
1. Ericsson Review, 2013, Non-line-of-sight microwave backhaul for small cells, available at:
http://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2013/er-nlos-microwave-backhaul.pdf
2. IEEE Communications Magazine, 2013, Non-line-of-sight small cell backhauling using microwave technology, available at:
http://dx.doi.org/10.1109/MCOM.2013.6588654
3. Ericsson Mobility Report, June 2014, available at: http://www.ericsson.com/res/docs/2014/ericsson-mobility-report-june-2014.pdf
4. Ericsson Review, 2011, Microwave capacity evolution, available at: http://www.ericsson.com/res/docs/review/Microwave-Capacity-Evolution.pdf
5. Ericsson Review, 2014, 5G radio access, available at:
http://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2014/er-5g-radio-access.pdf
6. Electronic Communications Committee (ECC), Report, Light licensing, license exempt and commons, Report 132, 2009, available at:
http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCRep132.pdf
7. Electronic Communications Committee (ECC), Report, Fixed service in Europe – current use and future trends post, Report 173, 2012, available at:
http://www.erodocdb.dk/Docs/doc98/official/pdf/ECCRep173.PDF
8. IEEE Access, vol. 1, May 2013, Millimeter wave mobile communications for 5G cellular: It will work!, available at:
http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6515173
9. NGMN Alliance, White Paper, 2012, Small Cell Backhaul Requirements, available at:
http://www.ngmn.org/uploads/media/NGMN_Whitepaper_Small_Cell_Backhaul_Requirements.pdf
E R I C S S O N R E V I E W • 2/2014
Re:view
37
25 years ago
The cover of issue 3, 1989 shows a batch of wafers
being fed into an LPCVD furnace for coating with silicon
nitride. Semiconductor
technology in general, and
MOS technology in
particular, was
developing so that more and
more circuit elements could
be made on a single chip.
The article describes the
state of MOS technology at
the time and some
development trends. At the
time, Ericsson Components
AB manufactured electronic
Ericsson Review,
components, including
issue 3, 1989.
printed circuit boards and
fiber optics.
50 years ago
The cover of issue 3,
1964 shows part of a rack in
an automatic code switch
exchange. The lead article
stressed the design
elements of exchange
technology and how
Ericsson developed a
selector designed to meet
substantially reduced space
requirements and overall
capital investment. This was
a design move away from
the crossbar system that
had been in use in Ericsson’s
systems since the 1920s.
Ericsson Review,
issue 3, 1964.
75 years ago
The third issue of 1939
carried an article on the leading
telephone cities of the world.
Cities were ranked in terms of
telephone density for the
period 1929-1937. Washington
DC topped the list, with San
Francisco a close second. With
Stockholm in third position it
outranked all other European
cities by a long way with
American cities occupying all
other leading positions. Today, Ericsson Review,
Ericsson’s City Index shows a issue 3, 1939.
much wider and more even
spread across the globe.
E R I C S S O N R E V I E W • 2/2014
Indoor made simple
38
Connecting the dots: small cells
shape up for high-performance
indoor radio
In 2012, the global consumption of mobile data traffic in a month amounted to 1.1 exabytes. This figure
is set to rise to 20 exabytes by 2019, corresponding to a CAGR of 45 percent1. Today, this traffic is split
70/30 with the larger proportion consumed indoors; a level that is not expected to decrease. Adapting
networks to support such a rapid rise in traffic demand will require massive deployments of targeted
indoor small cell solutions, complemented by denser outdoor deployments.
CH E NGUA NG LU, M IGU E L BE RG, E L M A R T ROJ E R , PE R-E R I K E R I K S SON, K I M L A R AQU I , OL L E V. T I DBL A D, A N D H E N R I K A L M E I DA
How do you design a small radio
to fit the interiors of large spaces,
yet powerful enough to meet
future requirements for indoor
radio capacity? This was the
question we asked ourselves
when we began to develop a
solution to provide high-capacity
radio for indoor environments.
radio. This article presents how we overcame the challenges.
Managing mobile data traffic volumes is already a challenge in many
markets, and as traffic trends continue
to rise, the need to efficiently manage
indoor traffic becomes more significant.
Some of the factors contributing to the
challenge of data traffic are:
What we wanted was a solution that
could provide high-performance connectivity, in the increasingly demanding indoor radio environment. We
wanted the installation process to be
simple and to reuse existing building infrastructure. We needed to find
an efficient way to deliver power and
a design that integrates well with outdoor solutions.
The result, the Ericsson Radio Dot
System (RDS), is a novel indoor small cell
solution with a flexible radio architecture for providing high-capacity indoor
Meeting the requirement for more
indoor capacity calls for a combination of macro network extension and
new energy-efficient building standards
– resulting in higher attenuation in outer
walls and windows;
global urbanization development –
today, 54 percent of the world’s
population live and work in dense city
environments, a figure that is forecast to
rise to 66 percent by 20502; and
the gradual consumption shift from
laptops to smartphones3 boosted by
network enablers, application
adaptations, and device evolution.
ACLR
CAGR
CPRI
DAS
DU
FDD
IF
IRU
MIMO
O&M
PCC
adjacent channel leakage ratio
compound annual growth rate
Common Public Radio Interface
distributed antenna system
digital unit
frequency division duplexing
intermediate frequency
indoor radio unit
multiple-input, multiple-output
operations and management
primary component carrier
E R I C S S O N R E V I E W • 2/2014
PoE
RDS
RF
RRU RU
SCC
SDMA
SINR
TCO
TDD
UE
Power over Ethernet
Radio Dot System
radio frequency
remote radio unit
radio unit
secondary component carrier
spatial division multiple access
signal-to-interference-plus-noise ratio
total cost of ownership
time division duplexing
user equipment
densification, together with specific targeted indoor small cell solutions.
To handle peak rates, high capacity
small cells require the same level of
backhauling capabilities and baseband
processing as larger cells. However,
when compared with larger cells, the
cost of backhauling and other resources
(such as baseband processing capability) for small cells typically needs to be
balanced against the fewer numbers
of users served. So, the ability to simplify backhauling and provide a means
to support shared baseband and higher
layer processing across many small cells
becomes critical.
Femtocell-like solutions, with baseband and cell definition at the antenna
point, were thought to be candidates for
indoor capacity needs. Unfortunately,
these types of nodes only work in practice for small deployments, because
radio coordination and cell planning
quickly become unmanageable as the
number of cells increases. For medium
to large buildings, venues and arenas,
macro cell features like coordination,
seamless mobility and interference
management are needed. Supporting
these features points us in the direction
of concepts like main-remote and fronthauling, and solutions that use common baseband processing for remotely
deployed small cell radio heads.
For small cell indoor scenarios, the
preferred transmission medium is
largely dictated by economies of scale.
For example, the ability to use the same
type of cabling and building practices
39
FIGURE 1 Reference architecture – distributed antenna system
RBS with regular
radio units
Attenuator bank
DAS head-end
DAS remote unit
Base station
integration unit
DAS antennas
Radio
distribution units
Coaxial
Fiber
Optical
distribution units
Extended power,
backup and cooling
as those that the IT industry uses for
Ethernet services would be advantageous for any solution. Twisted-pair
copper LAN cables are particularly
attractive, as they tend to be deployed
abundantly within enterprises and are
widely supported by the IT community.
Installing these cables is a relatively simple process, as it does not require specially trained staff or expensive tools.
And in addition, the whole IT ecosystem for LAN cables can be leveraged –
from installation and support staff, to
established installation and maintenance practices, as well as technologies
for fault localization and diagnosis.
Making use of LAN cables is one important characteristic of the Ericsson RDS,
which also benefits from being able
to reuse existing tools developed for
fault localization, diagnosis and copper
cabling. Using copper cables to connect
radio equipment has the additional benefit of remote powering – power is fed
over the same medium as the communications signals. This reduces the complexity and cost of installation, as there
is no longer any need to arrange for local
power, which can be a costly process.
Remote powering from a central location makes it much easier to provide
backup power at the central location,
thereby increasing reliability.
Remote power
Fiber
termination unit
Fiber DAS (parallel)
The major challenge of a traditional fronthauling solution over LAN
cables is meeting the requirements for
latency and its variation, as well as for
high capacity and reach. With the current limitations of the CPRI protocol4, it
would not be possible to apply a mainremote (digital unit (DU)-radio unit
(RU) split) concept over longer distances
using copper cables. As discussed later
in this article, there are additional reasons – like power efficiency and small
cell complexity – for not pursuing CPRI
as it is currently specified.
Our mindset during the conceptualization of the RDS was one of rethinking the ecosystem around how to secure
radio access capacity for indoor environments, taking costs into consideration,
as well as simplicity of installation and
operations, power feeding and the existing indoor infrastructure. We wanted
to create a solution that would fully
unleash the capabilities of existing and
future radio-access solutions and all of
their features5.
Our starting point was to take a view
of the indoor small cell as an extension
to and an enhancement of the macro cellular network. We revisited the RU architecture in such a way that deployed radio
heads would be connected to the rest of
the network via LAN cables, while still
Second coaxial tree
required for 2x2 MIMO
Passive DAS (shared)
fulfilling the goal to have a fully coordinated radio-access network.
Today’s in-building system
Supporting users in indoor environments has been a challenge since the
start of mobile networking. For the last
two decades, this challenge has been
overcome by using a method referred
to as distributed antenna system (DAS).
The many flavors of DAS solutions are
all based on the principle of redistributing macro RBS radio signals across an
indoor antenna grid in the downlink,
and a corresponding collection of the
user traffic in the uplink. As illustrated
in Figure 1, this can be achieved by
using a passive coaxial RF distribution
network, or by using an active fibercoaxial hybrid network.
Distributed antenna solutions have
worked well for many years and are
still considered for multi-operator and
neutral host applications. However, the
technology becomes limited as requirements for higher capacity and capabilities increase and more advanced
services evolve. The DAS model originates from large-cell radio architecture,
and it is good for voice and basic data
coverage, but the radio bandwidth per
user it provides is too low to be a viable
solution as capacity needs rise.
E R I C S S O N R E V I E W • 2/2014
Indoor made simple
40
The uplink near-far problem – a UE connected to an outdoor macro degrades
SINR for the UE served by the indoor system
FIGURE 2
Power
Wanted
carrier
Blocking
carrier
ACLR
SINR
Indoor
antenna
RF frequency
Macro
connection
Blocking UE
Served UE
Indoor domain
The capacity challenge is of particular interest for mobile enterprise scenarios, as application usage shifts from
legacy laptop systems to smartphonebased consumption, which rapidly
increases indoor-radio capacity requirements. In many markets, the shift to
smartphone consumption has already
occurred for basic applications such
as e-mail, and is increasing rapidly as
major enterprise and consumer applications are adapted for smartphone usage.
Indoor radio challenges
Usage in indoor cellular environments
is shifting from traditional voice coverage to smartphone app coverage and
high performance mobile broadband.
For this transformation to succeed
and result in an immersive experience of nearly-instantly available data,
much higher capacity per unit area is
needed compared with existing solutions. However, with the high outdoorto-indoor penetration loss of modern
buildings, an improved indoor system is
E R I C S S O N R E V I E W • 2/2014
Outdoor domain
necessary. For other scenarios, advanced
outdoor macro cells with MIMO, carrier aggregation and beamforming are
suitable.
Pushing down the uplink receiver
noise level to a few decibels above the
thermal noise is a successful approach
to extend the reach of a macro radio,
but is useless for indoor radios. Instead,
dense antenna grids are necessary to
combat the uplink near-far effect –
spectral leakage from user equipment
(UE) near an indoor antenna, but connected to an outdoor macro cell and
transmitting on an adjacent carrier, can
substantially degrade uplink signal-tointerference-plus-noise ratio (SINR) of
the indoor node, possibly to the point
where service outage occurs.
This near-far effect is illustrated in
Figure 2 and cannot be mitigated by
filtering in the base station, as noise
from the blocking UE is inside the carrier bandwidth of the served UE. For
a 20MHz-wide LTE uplink carrier, the
maximum allowed spectral leakage
in the adjacent channel (ACLR) is 30dB
below the carrier power6. For example,
a UE transmitting at 1.7GHz to an outdoor macro cell using maximum transmit power, and assuming a distance
of 1m between the UE and the indoor
antenna, yields an SINR degradation
corresponding to an effective uplink
noise figure as high as 58dB.
The near-far effect does not affect
peak rates since it is not present all the
time. Once it is present, however, it puts
an upper limit on the coverage radius
per antenna due to the risk of service
outage. In the given example, service
outage could occur already with a coverage radius of 20m, depending on UE
capabilities and indoor propagation conditions. For such dense deployments,
fairly high levels of uplink noise can be
tolerated without performance degradation. Instead, focus should be placed on a
design that enables coordination as well
as fast and flexible deployment.
One particularly important requirement for the large building segment is
the need for tight coordination, to handle the dynamic traffic situations that
arise in complex radio environments
like modern atrium buildings with
open offices.
Attempts to apply the femtocell
model in such environments, which
lack natural cell borders, have proven
to be challenging. Instead of increasing capacity, reducing the cell size
often leads to reduced performance
and increased risk of dropped calls due
to inter-cell interference and frequent
handovers. At low loads, peak data rates
may become limited by control channel pollution, as each cell needs a dedicated and robust control channel. Thus,
deployment of femtocells creates a huge
challenge in terms of performance and
TCO. To maintain user satisfaction,
supporting interference management
and seamless mobility are crucial –
between the cells inside the building
and between outdoor and indoor cells.
This level of coordination is simply not
present in femtocell solutions.
The ability to add new features
through software upgrades, avoiding site visits as far as possible, is a key
success factor for indoor radio deployments. To ensure a consistent user
experience with full performance and
service functionality throughout the
41
network, having the same set of radio
features in the indoor segment as in the
outdoor macro RBS is desirable. This
also enables coordination between the
indoor and the outdoor environment
and simplifies network operations and
maintenance (O&M). Coherent QoS,
high-quality voice, and good mobility support, including for instance soft
handover for WCDMA, are examples of
features that will be important for user
satisfaction both indoors and outdoors.
As well as meeting requirements
for increased performance, enabling
large-scale rollouts requires a substantial reduction in complexity of installation. Reusing LAN cables is one key way
of achieving this. In addition, indoor
radio containing active equipment must
support remote powering, like PoE or
PoE+, as the need for local powering in
the event of a power outage could substantially increase deployment costs
and decrease availability.
Key design considerations
Given the challenges, new generations of indoor radio systems need to be
designed smartly, adopting best practices from existing indoor systems –
DAS, Wi-Fi, and Pico – and embracing
new features.
Feature parity
To achieve the desired performance
gain from cell size reduction, combined
cell technology with spatial division
multiple access (SDMA), coordinated
scheduling and other advanced coordination features are needed. Such features are already available in macro
environments, and sharing the same
software base for indoor and outdoor
radios greatly simplifies the implementation of feature parity.
A convenient approach is to use
the same family of DU, which is also
referred to as the baseband unit. DAS is
based on such a design using the same
hardware and software to drive all
antennas in both the indoor and the
outdoor macro network.
Fronthauling with LAN cables
To facilitate deployment of smaller cells
with full coordination and scalability
for high capacity, a fronthaul architecture with a star topology is desired. This
approach enables each radio head to be
FIGURE 3
Radio Dot System – indoor made simple
Radio Dots
Radio Dots
IRU
DU
Structured LAN cabling
Remote powering
Radio base station
with DU and IRU
Power and
backup
fronthauled individually, resulting in
an indoor radio solution that is capable of supporting high capacity while
retaining maximum flexibility. The use
of LAN cables means that several indoor
systems can be deployed within the
same budget and time limitations as is
required for a typical DAS – as the traditional method of fronthauling requires
a fiber deployment. The design challenge in this scenario is how to fronthaul effectively through LAN cables.
Form factors
One concept related to the Internet of
Things is that of miniaturized design
or integration of communication into
everything in a natural way. For our
indoor system design, an ultra-compact
form factor for the radio heads was one
of the most important design considerations. To achieve compactness, low
power design is essential so that the
heat can be dissipated without affecting equipment reliability. The target
is a compact radio head that is smaller
than current DAS antennas, with a
minimalist design suiting any indoor
environment.
Support for high bandwidth
To meet ever-increasing capacity
demands, high bandwidth is essential
for high-performance radio systems,
Radio Dots with
MIMO and diversity
which can be achieved through carrier aggregation in wide FDD and TDD
bands. Additional benefits will come
from the adoption of 4x4 MIMO, which
should occur in the near future, doubling the total bandwidth capacity.
A novel indoor radio solution
As a new generation of indoor radio
systems, the RDS has been developed
with these key design considerations
in mind, based on technology already
developed for RBSs, but with a focus
on reducing architecture complexity, enhancing system scalability and
improving radio system performance.
The design utilizes LAN cabling infrastructure to connect the active antenna
elements – which are called Radio Dots.
The system specifically targets use
cases that are demanding in terms of
performance and dynamic capacity allocation – scenarios that typically require
multi-antenna grids, such as mediumto large-size office buildings. For areas
with less demanding capacity requirements, such as parking garages or outdoor areas in a campus environment,
the RDS can often be complemented
with remote radio unit (RRU)-based
micro DAS.
As Figure 3 shows, the RDS has three
key components: the Radio Dot, the
indoor radio unit (IRU) and the DU.
E R I C S S O N R E V I E W • 2/2014
Indoor made simple
42
Digital unit
The DU provides pooled baseband processing for the system. To manage the
connected radios, the DU uses the CPRI
standard for the DU-IRU interface to
transfer synchronization, radio signals
and O&M signals. When collocated with
the IRU, an electrical CPRI interface is
used, and for remote connection with
the IRU, a CPRI fiber interface is used.
Indoor radio unit
A newly designed RU that incorporates existing macro software features,
extending them with new indoor features. The IRU connects to each Radio
Dot using a proprietary IRU-Radio Dot
interface over a LAN cable (detailed further on).
Radio Dot
The Radio Dot has two integrated antennas in a 10cm form factor and weighs
under 300g. Each Radio Dot is connected to the IRU through a dedicated
LAN cable and remotely powered by
PoE. As in Ethernet networks, the system employs a star topology, as opposed
to the tree topology used in DAS. The
ultra-compact design and use of LAN
cabling simplify installation.
The design of the system is essentially
a centralized baseband architecture
that enables baseband resource pooling
and full coordination. Initial baseband
capacity can be selected to meet nearterm demand, and more capacity can
be gradually added at the DU and IRU
as traffic demand increases –without
rates, as control channel pollution can
be avoided. The combined cell approach
can be taken one step further by introducing SDMA, which allows resources
to be dynamically reused within the
cell. This enables instantaneous scaleup to full capacity, while minimizing the
mobility overhead.
any need to modify the cable infrastructure and the installed Radio Dots. To
illustrate this point, a single cell per
IRU can be upgraded to a multiple cell
per IRU simply by exchanging the IRU
– leaving the Radio Dots untouched. In
addition, a 4x4 MIMO can be supported
without changing the installed cable
infrastructure.
The system is manageable all the way
up to the antenna element. The radio
properties of each individual Radio Dot
can be tuned in terms of coverage and
performance. The approach used in this
solution reduces the need for careful,
tedious and costly site investigations
and network planning for each building, by applying rule-of-thumb-based
network planning to define the deployment requirements such as inter-radio
distance per building type (based on
statistical simulation results for typical
floor plans). This approach simplifies
the planning process and is sufficient
to guarantee high performance for most
buildings. If needed, additional radios
can be installed at a later stage, and this
can be completed quickly due to the simple deployment and LAN-like star topology of the system architecture.
The ability to apply combined-cell
technology to the maximum results in
fully coordinated cells, which in turn
further optimizes capacity, mobility
and robustness of the indoor radio network. Combined cell minimizes the
number of handovers by allowing multiple radios to share the same physical cell identity. It also increases peak
FIGURE 4 Main-remote RBS block diagram
Remote radio unit
Digital unit
RF front-end
RF
IF
TX
DAC
Radio
Processing
RF
Duplexer
E R I C S S O N R E V I E W • 2/2014
RX
IF
ADC
CPRI
BB
processing
The cable interface
Figure 4 illustrates the basic block diagram of a conventional main-remote
RBS solution. Adaptation of this solution for indoor environments was a key
design goal of the RDS, and our idea was
to utilize cost-effective LAN cables to
enable a totally fronthaul-based architecture. The challenge then, was to
identify where the LAN cable interface
should be introduced.
Using existing Ethernet technologies,
such as 1000BASE-T or 10GBASE-T, to
transport CPRI over LAN cables is one
way to answer this question. However,
Ethernet PHYs with IEEE1588v2 support
were not originally designed to support
CPRI with stringent requirements for
bit-error-rate, latency and delay variation. This results in a compromise
between bit rate, reach and latency. To
address this, significant CPRI frame
compression is needed, which increases
complexity but also power consumption. Currently, the combined processing and compression for Ethernet PHYs
and CPRI result in relatively high power
consumption, and so due to the heat dissipation, this approach is not a good fit
for a slim design.
So, what other options are available?
LAN cables are capable of transporting
very high bandwidths; for example, the
effective bandwidth for 100m of Cat 6a
per used twisted pair is between DC and
400MHz. This high bandwidth is feasible, as it operates in the lowest part of the
spectrum and has both a low noise floor
and rather low cable loss. As four twisted
pairs are available for each LAN cable,
the question now becomes: is it possible
to efficiently exploit this bandwidth and
the four pairs for fronthauling?
If we take another look at the RU
design in Figure 4, an interface with a
low intermediate frequency (IF) exists
between the ADC/DAC blocks and the
down-/upconverters. So, is it feasible to
transmit the IF signals directly over the
LAN cables? The answer is yes. As shown
43
FIGURE 5
Radio Dot System block diagram
Radio Dot
Indoor radio unit
Digital unit
RF front-end
RF
TX
DAC
Cable
I/F
RF
Radio Dot interface
Cable
I/F
RX
Radio
Processing
CPRI
BB
processing
ADC
Duplexer
in Figure 5, such an IF-based design,
in effect, extends the RF front-end
over a LAN cable using an IF interface
– which transports the radio signals at
low frequencies with graceful capacity
degradation in the event of unexpected
cable faults.
The elegance and simplicity of this
design requires minimal hardware/software changes regarding radio front end
and processing, and enables the overall
ultra-compact design (see Figure 3). The
IF-based design requires a lot less power
compared with possible Ethernet-based
methods, as the IF cable interface can be
designed in a more power-efficient way.
In addition to the radio signals, the same
twisted pair can carry synchronization
signals and control signaling and power.
This design also supports advanced features for cable equalization, AGC, cable
testing and troubleshooting.
The IF-based design provides high
radio performance and support beyond
the standard LAN-cabling reach of
100m. Given the low noise floor and
rather low cable attenuation at selected
IF frequencies, 3GPP uplink and downlink requirements can be fulfilled, and
4x4 MIMO can be supported by utilizing all four pairs of the cable. Previous
research has shown that the use of four
antennas for indoor environments
has great potential to further increase
capacity7.
Copper is the medium of choice for
indoor broadband infrastructure and
will remain so for many years. LAN
cable technology has evolved significantly over the past four decades – from
Cat 3 to Cat 7 and the upcoming Cat 8
– driven by improvements in Ethernet
speeds from 10Mbps to 10Gbps and set
to reach 40Gbps in the near future. This
has led to substantial improvements in
cable technology, which offer higher
FIGURE 6
bandwidth and lower noise. The RDS
will continue to build on this evolution,
both for performance upgrades and cost
erosion due to economies of scale.
Lab test results
The performance of the system has
been verified in lab tests. Figure 6
System performance
DL throughput (Mbps)
350
Test samples
Fitted
300
250
200
150
100
–5
0
5
10
15
20
25
SINR on SCC (dB)
E R I C S S O N R E V I E W • 2/2014
Indoor made simple
44
FIGURE 7
Illustration of ﬂexible capacity
Evenly configured
More capacity
in hotspots
Hotspot
shows the result of a DL test with
carrier aggregation of two 20MHz LTE
carriers in the 2.1GHz band and using
2x2 MIMO. The IRU and Radio Dot were
connected using 190m of Cat 6a cable.
The SINR on the primary component
carrier (PCC) was fixed at 27dB to show
the full peak rate of carrier aggregation,
while the SINR on the secondary component carrier (SCC) was varied between
-5 and 25dB. During the test, the DL
throughput on the PCC maintained the
expected peak rate of 150Mbps throughout. Figure 6 shows the aggregated DL
throughput versus the SCC SINR, where
the throughput increase above 150Mbps
is due to the SCC. The aggregated peak
rate of 300Mbps was achieved at about
23dB SINR.
Evolution to ﬂexible capacity
Indoor traffic demand tends to vary
over time and space, particularly in
enterprise and public environments.
For example, traffic demand regularly
increases over the course of a day in
areas where many people gather, such
as in conference rooms, cafeterias, and
lobbies. This high traffic demand disappears once people leave. Evenly distributing high capacity in a building for
its peak use is not the best approach, as
this tends to result in overprovisioning
capacity.
E R I C S S O N R E V I E W • 2/2014
Coverage only for
energy efficiency
Hotspot
As the RDS uses centralized baseband
architecture, it can provide capacity in
a more flexible way – by shifting available capacity from one place to another
on demand. This can be implemented
through dynamic cell reconfiguration (such as, traditional cell splitting
and combining) or by using combined
cell SDMA technology. For LTE Rel10/11 UEs, combined cell SDMA is the
desired approach for dynamic SDMA
operations in one cell involving all the
radios. This approach enables efficient
use of the available baseband capacity,
optimizing both network capacity and
mobility, resulting in an improved user
experience. Overlapping radios can be
turned off (dynamically) to save energy.
Figure  7 shows three typical scenarios assuming three-cell baseband capability. Here, for illustration purposes
only, a dynamic cell reconfiguration
approach is used.
In the first scenario, three cells are
distributed evenly to cover the indoor
area, and each cell contains five radios.
The second scenario covers the same
space but includes two traffic hotspots.
Here, the top cell is split into two smaller
cells to provide higher capacity to the
hotspots, while the rest of the area is
covered by a single larger cell using the
remaining baseband resources. In the
third scenario, traffic demand is very
low – a common situation late at night
and early in the morning. To provide
capacity for this low traffic scenario, the
orignal three cells are combined into one
large cell with only the selected radios
active. All other radios (including the
baseband resources involved) are inactive to save energy.
Summary
In this article, we have highlighted the
challenges related to radio capacity and
performance inside buildings, summarizing the main requirements to be
successful in overcoming them. With
a limited technology toolbox available
to operators today, scalable growth for
the platforms of the Networked Society
is restricted, and so innovative design
principles for smart and flexible small
cell radio technology are needed.
Our aim was to provide operators
with the best combination of two worlds:
superior radio technologies and their
continual evolution from the mobile
industry, together with the well-established LAN building practices of the IT
community. This was our inspiration
for the design of the Radio Dot System
– a novel indoor small cell solution.
45
Chenguang Lu
Kim Laraqui
Olle V. Tidblad
is a senior researcher in small
cell transport within Ericsson
Research and is part of the
research team developing the
RDS concept. He joined Ericsson in 2008
and holds a Ph.D. in wireless
communications from Aalborg University,
Aalborg, Denmark. He has actively
contributed to DSL technologies like
Vectorized VDSL2 and G.fast. Since 2010,
he has mainly focused on research in small
cell backhauling and fronthauling.
is a principal researcher and
technical driver of research on
transport solutions for
heterogeneous networks. He is
also part of the research team developing
the RDS concept. He joined Ericsson in
2008 as a regional senior customer solution
manager. Prior to this, he was a senior
consultant on network solutions, design,
deployment and operations for mobile and
fixed operators worldwide. He holds an
M.Sc. in computer science and engineering
from KTH Royal Institute of Technology,
Stockholm, Sweden.
joined Ericsson in 1996 as
field implementation
supervisor of fiber access and
transmission solutions. From
1997 to 2000, he worked with enterprise
communication and IP solutions at the
international carrier Global One. Since
returning to Ericsson, he has held product
management positions within fixed and
radio access infrastructure including
WCDMA, LTE and small cells. He has worked
with Ericsson research and radio product
development to bring the RDS to market. He
holds a B.Sc. in electrical engineering, and
applied telecommunication and switching
from KTH Royal Institute of Technology,
Stockholm, Sweden.
Henrik Almeida
joined Ericsson in 1990 and is
currently head of Small-Cell
Transport at Ericsson
Research, where the RDS
concept was developed. He has a long
history of working with fixed-line access
technologies at Ericsson and is now
focusing on small cell transport solutions for
the Networked Society. He holds a Ph.D.
H.C. from Lund University, Sweden, for his
work in the area of broadband technologies.
Elmar Trojer
joined Ericsson in 2005 and is
currently working as a master
researcher in the Small-Cell
Transport group at Ericsson
Research. He is part of the research team
developing the RDS concept. He has worked
on both fixed and mobile broadband
technologies such as VDSL2 and G.fast,
dynamic line management solutions for
IPTV, and 3G/4G access in the context of
mobile backhaul/fronthaul over copper and
fiber media. He led the design and product
systemization of the RDS with a strong
focus on the physical layer radio
transmission. He holds a Ph.D. in electrical
engineering from the Vienna University of
Technology, and an MBA from the University
of Vienna.
Miguel Berg
joined Ericsson Research in
2007 and is currently a master
researcher in the Small-Cell
Transport group. He is part of
the research team developing the RDS
concept. From 2007 to 2011, he was active
in research regarding copper cable
modelling and line-testing algorithms for
xDSL and G.fast. He holds a Ph.D. in
wireless communication systems from
KTH Royal Institute of Technology in
Stockholm, Sweden. Between 2002 and
2003, he worked at Radio Components,
where he was involved in the design of base
station antennas and tower-mounted
amplifiers.
Per-Erik Eriksson
joined Ericsson in 1989. He is
currently a senior researcher at
the Small-Cell Transport group,
Ericsson Research. He is part of
the research team developing the RDS
concept. He has previously worked with
ADSL, Vectorized VDSL2 and G.fast and has
also been involved in the standardization of
those technologies. He holds an M.Sc. in
electronic engineering from KTH Royal
Institute of Technology, Stockholm,
Sweden.
References
1. Ericsson Mobility Report, June 2014, available at:
http://www.ericsson.com/res/docs/2014/ericsson-mobility-report-june-2014.pdf
2. United Nations, 2014 Revision, World Urbanization Prospects [highlights], available at:
http://esa.un.org/unpd/wup/Highlights/WUP2014-Highlights.pdf
3. Cisco, 2014, Visual Networking Index: Global Mobile Data Traffic Forecast Update, 2013–2018,
available at: http://www.cisco.com/c/en/us/solutions/collateral/service-provider/visualnetworking-index-vni/white_paper_c11-520862.html
4. CPRI Specification V6.0, 2013-08-30, available at:
http://www.cpri.info/downloads/CPRI_v_6_0_2013-08-30.pdf
5. Ericsson Review, June 2014, 5G radio access, available at:
http://www.ericsson.com/news/140618-5g-radio-access_244099437_c
6. 3GPP, Technical Specification 36.101, LTE; E-UTRA; UE Radio Transmission and Reception,
version 11.8.0, available at: http://www.3gpp.org/dynareport/36101.htm
7. IEEE, 2013, LTE-A Field Measurements: 8x8 MIMO and Carrier Aggregation, Vehicular
Technology Conference (VTC Spring), abstract available at:
http://dx.doi.org/10.1109/VTCSpring.2013.6692627
E R I C S S O N R E V I E W • 2/2014
Programmable networks
46
Architecture evolution for
automation and network
programmability
The target architecture of future telecom networks will be designed using sets of aggregated
capabilities. Each domain will have its own set of resources that are abstracted and exposed to other
domains, supporting multi-tenancy and tenant isolation. The result is a fully programmable network,
that has the ability to evolve and adapt to the emerging requirements of the Networked Society.
GÖR A N RU N E , E R I K W E S T E R BE RG, T OR BJÖR N C AGE N I U S ,
IGNAC IO M A S , BA L Á Z S VA RGA , H E N R I K BA S I L I E R , A N D L A R S A NGE L I N
Enabled by emerging
technologies like virtualization,
(SDN) and cloud capabilities,
the architecture of telecom
networks is undergoing a
massive transformation. This is
being driven by several factors,
including the need for less
complex and lower-cost network
operations, shorter time to
customer (TTC) and time to
market (TTM) for new services,
and new business opportunities
built on the anything as a service
(XaaS) model.
The principles of the target architecture
are based on separation of concerns,
multi-tenancy and network programmability. As networks progress toward
the target architecture supporting
as-a-service models with rapid scalability capabilities and greater levels of automation, the need to focus on the basic
principles will become more significant.
Full programmability of a network
and its services needs to take all the
building blocks of a network into consideration: how each piece will evolve;
how they will interface; and how they
support the structure and business processes of an operator.
SDN technologies, for example, are
key enabling tools for network programmability, but to provide value they must
be integrated with the end-to-end process view of the operator. Cloud orchestration technologies are also important
enablers, but without proper interfaces
to business management functions in
place, the result would be a technically
functional but commercially dysfunctional system. Well-defined technical
AAA
authentication, authorization and accounting
API
application programming interface
APN
Access Point Name
BSS
business support systems
COMPA
control, orchestration, management, policy and analytics
DC
data center
EPC
Evolved Packet Core
IGP
Internet Gateway Protocol
IPS
infrastructure and platform services
MPLS
multi-protocol label switching
MTC
MVNO
mobile virtual network operator
E R I C S S O N R E V I E W • 2/2014
NFV
OSS
opex
OVF
PaaS
POD
R&S
SDN
SLA
TTM
TTC
VM
vDC
VIM
network functions virtualization
operations support systems
operational expenditure
Open Virtualization Format
platform as a service
performance-optimized data centers
routing and switching
time to market
time to customer
virtual machine
virtual data center
Virtualized Infrastructure Manager
interfaces and abstractions are critical
to facilitate a split of responsibilities,
support trust relationships and enable
opex efficiency.
This article aims to describe the big
picture of the target ecosystem, presenting an architecture description that
focuses on the inter-domain interfaces,
separation of concerns as well as network programmability.
The ecosystem
The target network architecture will
be built using a set of critical technical interfaces that support business
relations – which we call inter-domain
interfaces. These interfaces mark the
boundaries between the different layers
or domains of a network; they support
the separation of concerns, interoperability, and enable Service Level
Agreements (SLAs). Administrative
domains, as defined by NFV1, are suitable for being managed as one entity
from a competence and administrative
responsibility point of view. As Figure 1
illustrates, there are four typical administrative domains:
transport;
infrastructure and platform services ;
access and network functions; and
business and cross-domain operations.
The target architecture – and in particular the inter-domain interfaces – serve
as enablers for a multitude of domain
combinations. Many other domain
structures are possible, depending on
the strategy and operational structure
of the operator.
Administrative domains are quite
physical in nature. Traditionally, they
47
tend to consist of physical nodes with
pre-integrated hardware and software
functions. This, however, is changing.
Together, NFV and the separation of
software and hardware have brought
about a new administrative domain:
the infrastructure and platform services (IPS) domain. Some administrative
domains – notably transport, access network and the new IPS domain – maintain responsibility for hardware and
platforms, while most other network
function domains – such as the Evolved
Packet Core (EPC) – manage only software functions.
Even though current network architecture already includes several interdomain interfaces, the evolution to the
target architecture aims to improve
multi-tenancy capabilities, as well as
intra-domain and inter-domain programmability. This evolution will happen gradually and to varying degrees
for each domain depending on need –
in terms of value – as well as additional
considerations like legacy equipment
and operational processes.
Key principles of the target
architecture
Developing network architecture so
that it is both highly automated and
programmable requires functionality
to be coordinated across administrative
domains. This can be achieved through
a set of tools to operate each administrative domain, which have operational responsibility for the resources
within the domain, as well as the ability to expose services based on these
resources. In this article we refer to the
combination of these operational tools
as COMPA: control, orchestration, management, policies and analytics. Each
term has a wider meaning than its legacy definition; all are tightly interlinked
within each administrative domain, as
well as having inter-domain relations.
The COMPA functional groupings are
illustrated in the target architecture
shown in Figure 2.
The main principles of the target
architecture are:
separation of concerns;
abstraction and exposure of capabilities;
multi-tenancy;
intra-domain programmability; and
inter-domain programmability.
FIGURE 1 Target architecture with example administrative domains
Access
Core
Services
Business
and cross-domain
operations
Access and network functions
Control
Orchestration
Management
Policies
Analytics
Infrastructure and platform
Transport
Control, orchestration and management
Management and control functions
within each domain will do much the
same job as they do today, but with a
higher degree of automation and realtime capabilities. Orchestration enables
automation across different types of
resources and uses defined workflows
to provide the desired network behavior – all aligned with and enabled by a
policy framework that is supported by
analytics insights. Creating infrastructure services is one example of where
orchestration is heavily used in the IPS
domain, in which processing, storage
and networking resources are assigned
in a coordinated manner.
Services from other domains can also
be viewed as resources orchestrated in a
synchronized manner with a domain’s
own resources to provide services in a
hierarchical way. A strict framework
with a common information model is
required to maintain consistency across
domains – illustrated by the verticalarrow flow in Figure 2.
FIGURE 2 Grouping of COMPA functions in the target architecture
Access and network
functions
Infrastructure
and platform
Transport
Control
Orchestration
Management
Policies
Analytics
Control
Orchestration
Management
Policies
Analytics
Business and
cross-domain
operations
Control
Orchestration
Management
Policies
Analytics
Control
Orchestration
Management
Policies
Analytics
E R I C S S O N R E V I E W • 2/2014
48
FIGURE 3 Policy framework
Operator level
Strategic, tactical and commercial policies:
Business and cross-domain operations
Policy administrative domains
System level policies per
administrative domain
Network functions (NF groups)
Detailed policies:
Network functions level
To offer services that draw
resources from more than one domain,
a cross-domain OSS/BSS function is
needed. This second main flow of
orchestration relates to external business offerings and how to leverage
services from multiple domains. For
example, an enterprise customer may
require a service that combines an infrastructure service from the IPS domain
with a business VPN from the transport
domain – this is shown conceptually by
the horizontal arrows in Figure 2.
To support service exposure, each
domain needs appropriate logging tools.
For example, an IPS domain will need
to create and maintain data records
related to usage for the infrastructure services it provides – regardless of
whether it delivers these services to an
external tenant or to an internal tenant (to other domains within the same
operator). Many of these functions will
be automated and simplified in their
interfaces among staff, OSS/BSS, and
resource control functions.
The policy framework
Policies are sets of rules that govern
the behavior of a system. A policy comprises conditions and actions; events
trigger conditions to be evaluated and
actions are taken if the conditions are
met. Policies are used to define a framework and set the bounds for the controlorchestration-management functions,
derived from the overall business goals
of the operator.
E R I C S S O N R E V I E W • 2/2014
Some policies, like those that control how specific resources are used,
are strictly defined and applied within
an administrative domain. Other policies apply to the inter-domain interfaces, and define for example how one
domain can use services from another.
Such policies can be partly defined by
the administrative domain delivering
the service, but may also be defined by
the administrative domain for business
and cross-domain operations. Figure 3
shows how policies originate from the
overall business objectives of the operator and how they relate to different levels within the operator structure.
The relationship between business
and network operations policies is
defined by a set of meaningful operational KPIs. For example, a business policy governing the parameters of a gold
subscriber service can be interpreted
into specific settings for, say, QoS in the
network. By factoring in the insights
supplied by analytics, these operational
KPIs enable a greater degree of network
automation, and allow policies to govern operational decisions.
Network analytics
Analytics is therefore a key tool for
increasing automation of operations.
To provide insights, predictions, as
well as supporting automation in other
ways, analytics can be applied within an
administrative domain or work in conjunction with the other COMPA functions – both in offline processing of data
and for real-time stream processing.
Domain competence is usually needed
to understand prediction, but insights
exposed from other domains or external sources could also be used as input.
Exposing analytics insights on a
domain basis, and then aggregating multiple domains through a cross-domain
analytics application, enables the entire
network state to be analyzed; which in
turn supports the definition of networkwide KPIs.
A policy engine can use network analytics to check performance-related
KPIs, triggering network state updates
when needed. Such requests could
then be applied to the relevant network
domains by the control-orchestrationmanagement functions – possibly with
some form of manual intervention.
A closed feedback loop from the control-orchestration-management functionality back to the policy engine
would enable policies to learn and adapt
automatically as the network environment changes.
Applying the concepts
Transport
In telco networks, the transport domain
delivers connectivity services between
remote sites and equipment, maintaining topology awareness and services for
multiple customers – multi-tenancy.
In reality, a transport network consists of a set of interworking administrative domains defined by technology,
geography and ownership. The main
technologies powering the delivery of
connectivity services will be based on
IP/MPLS, Ethernet and optical transport;
in the access domain, microwave transport may also play a significant role, and
IPv6 will be the dominant protocol (as
IPv4 becomes more associated with legacy infrastructure). Transport network
topology will become flatter with fewer
packet hops, as the use of converged
IP and optical transport technologies
becomes more widespread2.
Traditional connectivity services like
residential broadband, mobile backhaul, and enterprise VPNs will coexist
with newer services that will provide
connectivity for cloud solutions, such as
DC-to-DC or user-to-DC. These new generation services and the increased number of connections will drive the need
49
for more flexible and dynamic ways to
operate the transport domain.
A number of key components are
needed to support evolved architectural principles and facilitate both
intra-domain and inter-domain programmability. These components
include SDN and network virtualization
technologies3, which allow connectivity
services to be deployed and controlled in
a flexible way.
Programmability in the transport
domain will ensure a suitable level of
resource abstraction, exposure and
control so that other administrative
domains can request transport services according to established SLAs.
Programmability can be achieved by
using northbound SDN-based interfaces, for example, and can be further
increased by leveraging the benefits of
data/control plane separation.
As shown in Figure 4, several scenarios regarding what parts of a transport
node can be SDN controlled. These scenarios lead to multiple possible paths and
intermediate steps to transform a traditional transport network into a network
that is fully SDN-controlled – in which
only a limited set of functions are local
to the transport node. Using SDN controllers will not only result in the introduction of new functions and services
into transport nodes, but existing control functionalities will be moved to the
SDN controller – replacing current localnode implementations.
Migrating an existing transport network to an SDN-based architecture
requires hybrid operational modes
that apply SDN-based control capabilities onto the existing (protocol-driven
local node) transport infrastructure. The
capabilities that are included depend on
the level of centralization versus distribution of functions that the operator
chooses for its transport domain.
The resulting transport domain – in
the context of packet-optical integration – combines increased programmability (enabled by SDN technologies) with
the simpler, more cost-efficient IP and
optical components, and is detailed in
a previous Ericsson Review article2. The
evolved transport domain enables faster
service deployment and reduces operational complexity.
Infrastructure and platform services
As networks evolve, telecom solutions
and systems will increasingly be built
using on-demand elastic infrastructure
and platform services rather than dedicated and managed infrastructure and
software. To leverage the benefits of this
model, a split in responsibility between
the provider of such services and the
users (tenants) is necessary. The provider role is taken by what we refer to in
this article as the IPS domain, which is
a new domain type that provides infrastructure and platform services using
owned or leased resources.
One of the key services offered by the
IPS domain is a structured collection of
virtual computational processing, storage and networking resources, within
what is referred to as virtual data center
(vDC). The vDC interface separates logical telecom nodes from the actual physical infrastructure, using concepts like
virtual machines, virtual network overlays, baremetal, and storage services.
Networking capabilities exposed to
tenants will be rich enough to support
a wide set of telco functions, including
L2 and L3 VPN interworking and SDNcontrolled service chaining4. The IPS
domain can also take the administrative responsibility for common network
functions (such as DNS, firewalling,
DHCP, and load balancing) and offer
these as services, orderable as products
deployable in a vDC.
In addition, the IPS domain can also
supply services to applications, providing an execution framework (PaaS) and
network APIs that expose underlying
network capabilities. For example, common network functions can be exposed
and made programmable by applications. Inter-domain programmability
and abstraction increases application
development productivity and reduces
lead times. In addition, the IPS domain
will support migration by providing
interconnectivity with non-virtualized networks as well as mixed
FIGURE 4 Scenarios for control plane and data plane separation for packet,
and IP/optical transport networks
SDN
controller
SDN
controller
Service
Transport
Service
function
Service
SDN
controller
Optical
SDN
controller
Optical
Service
Transport
Service
Service
function
Service
function
Service
function
Transport
function
Transport
function
Transport
function
Transport
function
Port
Port
Optical
Optical
Hybrid SDN
legacy mode
(packet)
Full SDN mode
(packet)
Hybrid SDN
legacy mode
(IP+optical)
Full SDN mode
(IP+optical)
IGP
IGP
E R I C S S O N R E V I E W • 2/2014
50
FIGURE 5 Infrastructure and platform services domain
Tenant domain
Overall IPS
functions
Infrastructure resource
zone or provider
COMPA
VIM
(v)
switch
Virtualization
POD
App
framework
HW/OS
External
infrastructure
service
provider
POD
DC
interconnect
Data site center 1
deployments of non-virtualized, virtualized and PaaS-based applications.
All the capabilities of the vDC and
application services are orderable by
tenants through policy-controlled
inter-domain interfaces, and all of the
capabilities can be requested, monitored and maintained/scaled through
these interfaces. The interfaces will rely
heavily on modeling of the (sometimes
complex) sets of capabilities, using OVF
descriptors, for example, and forwarding descriptors for service chaining.
Within the IPS domain, overall functions in the COMPA category will act
across a wide set of resources in the
underlying infrastructure.
Using orchestration technologies,
for example, suitable abstractions can
be provided to tenants using a heterogeneous set of resources – which
allows tenants to manage and program resources without requiring any
lower level implementation details.
Policies and analytics may then be
used to ensure that resources are used
E R I C S S O N R E V I E W • 2/2014
Platform
resources
POD
Transport
POD
DC
interconnect
Data site center 2
efficiently, while respecting SLAs and
business requirements.
The physical resources that expose
virtual resources to tenants may be
organized into infrastructure resource
zones, each with their own functions
(VIM in ETSI NFV terminology) acting
within the zone – such as OpenStack
and SDN controllers. Some or all such
zones may be external to the IPS
domain. Another option is to use similar services from another IPS domain
or service provider, where orchestration
capabilities deliver a consolidated service. The transport domain may be used
for inter-connectivity of infrastructure
resource zones at different data center sites or to connect infrastructure
resource zones to external networks.
In both cases, the IPS domain interacts
with the transport domain, based on
frame agreements, to request or dynamically adapt WAN connections.
As shown in Figure 5, the IPS domain
relies on several arbitrarily distributed
DC sites, which contain a number of
PODs – blocks of computational, storage
and networking resources. Typically, a
POD corresponds to an infrastructure
resource zone. To deliver consolidated
and distributed vDCs, the overall orchestrator can request resources across the
PODs through their VIM functions.
The IPS domain offers abstracted
services (the vDCs and application services), multi-tenancy with isolation of
resources, security and SLAs associated
with these services. It allows for intradomain programmability and automation via the VIM (OpenStack), SDN
for the connectivity resources and the
COMPA functions for resource and service orchestration across infrastructure
resource zones and to external providers. It also offers inter-domain programmability where tenants have access to
interfaces for controlling – within
frame agreements – their instances of
the vDC and application services, supporting for example scaling, tenant
SDN control or access to telco network
capabilities. The interface between the
IPS domain and its tenants needs to be
open and, where applicable, standardized to support a full business ecosystem
between IPS-domain service providers and its tenants, with a minimum
amount of system integration between
the two. Indeed, this appears to be one of
the main tasks of the NFV forum.
Network functions
Most network functions of the logical telecom architecture shown in
Figure 6 benefit from using services
from the IPS domain. The separation of
network functions from platforms can
result in significant operational gain –
primarily through automated routines
for backup and restore, capacity planning, hardware handling and a general
reduction in the number of platforms
to be managed. This has a direct impact
on TTM for new services, which can be
reduced from up to a year down to a few
months as the introduction process no
longer depends on platform introduction. Auto scaling of the infrastructure
and platform services and programmability of the network functions removes
much of the manual work associated
with fulfillment, which greatly reduces
the TTC.
The original design of mobile network
architecture in 3GPP supports a certain
51
level of programmability, abstraction
and multi-tenancy. Standardized interfaces between the RAN, EPC and IMS
domains support automation in bearer
service handling and a set of MVNO solutions at various levels. The Rx interface
enables rudimentary inter-domain programming to the PCRF from outside the
EPC domain, while the APN structure
provides a foundation for multi-tenancy.
However this is not sufficient, network
functions architecture is evolving to
increase support for COMPA functions.
Introducing the infrastructure and platform services are a significant step in
this direction, but additional architectural changes and interface improvements are also part of the wider picture.
Separating network functions from
the platforms allows the capacity of a
given network function system – such
as an EPC system – to scale up or down
by simply adjusting the capacity of the
vDC to achieve the wanted capacity of
the EPC system. The multi-tenancy of
the vDC service also means that multiple EPC systems can be instantiated in
parallel in separate vDCs.
Figure 7 illustrates how deploying a
multitude of EPCs in different vDCs provides full isolation of the EPC instances,
inherited from the tenant isolation
built into the vDC service from the IPS
domain. Isolation makes both service
exposure and inter-domain programmability to EPC instances safer – opening up programmability to one instance
does not impact others, and exposure
of data from the EPC system to a customer or partner is limited to that of
the associated EPC system instance.
Implementing isolation in this way minimizes risk and reduces the cost for troubleshooting faulty services.
For operations in multiple markets,
one EPC system can be instantiated per
market, with a central responsibility for
the EPC domain, but with selected programmability suitable for the demands
of the given market. This is a cost-efficient approach with consolidated competence and responsibility, while still
allowing different operational entities
to control selected features of the EPC
system – such as rules for charging or
subscription.
Instantiating a VoLTE system5,
for example, can enable an operator
to offer communication services to
enterprises, emergency services or any
other industry with full isolation and
varying degrees of programmability. To
support this use case, network architecture needs to evolve to the target
architecture. In particular, additional
inter-domain interfaces (to enable programmability and automated orchestration) are needed to instantiate the
relevant subsystems and combine them
into service solutions.
The evolution of the network functions integrates well with 5G radio evolution6. Next generation networks will
support legacy services as well as new
services like enhanced mobile broadband, massive machine-type communication (MTC), as well as mission-critical
MTC. Future networks will need to
support a vast number and a much more
diverse set of use cases. Consequently,
service creation that is platform-independent and flexible, based on programmability and automation is key. A
massive range of industries will depend
on 5G networks – all with different
requirements for characteristics, security, analytics and cost. Meeting all of
these needs is a strong driver for multitenancy, isolation, and instantiation of
services and resources.
Extending instantiation capabilities
to work across multiple domains may
enable novel business offerings to be
created. If, for example, an instance
of an EPC system is integrated with a
VoLTE system instance, the two are then
connected to an IP VPN, and finally
FIGURE 6 Logical telecom architecture
OSS/BSS
User data management
AAA
HSS/
HLR
Domain
mgmt.
OSS
BSS
UDR
Service
enablement
Expose
Packet core
Communication services
PCRF
Mobile
CS
S/PDN
GW
MME/
SGSN
eMBMS
GW
ePDG
GW
TDF
SCCF
IMS
core
IMS
IMS
telephony
message
Media services
Media
delivery
Mobile
broadcast
Other services
Server
Server
E R I C S S O N R E V I E W • 2/2014
52
all three are associated with an isolated and SLA controlled radio-access
service; the result is an isolated, and
SLA-controlled logical instance of the
complete network. Such logical network
instances can be offered to an industry,
to an MVNO or an enterprise. As each
network instance is isolated, it is safe
to open up interfaces to each instance
to enable each customer or partner to
program selected properties of the logical network instance, and to do this in
real time.
To reach the point where a network
can be offered as a programmable service requires a cost-efficient way to connect services – and eventually resources
– from the various domains into logical network instances. As described at
the beginning of this article, to connect services in such a cost-efficient
way requires inter-domain programmability and more generally a networkwide architecture for cross-domain
orchestration and management, while
maintaining per-domain responsibility
and accountability.
many network functions will be managed in similar way as any other virtualized software: following virtualization
management principles in line with
ETSI NFV specifications. Initially virtualized network functions will be operated in parallel with legacy nodes, and
DC operations as well as maintenance
will be automated to a much larger
degree than it is today.
In the longer term, the architecture
should be able to provide the desired
level of automation and network programmability. Full programmability of
the network and its services requires
the inter-domain interfaces as well as
the domains to evolve. To achieve the
full gain of the network architecture
transformation, the related internal
operator processes (like workflow, operation, and maintenance processes) will
need to be adjusted. Technologies like
SDN and cloud orchestration are crucial enablers and tools for automation
Conclusions
Increased levels of automation and
programmability are transforming
network architecture. This transformation is being driven by expected gains
in operational efficiency and reduced
TTM for new services, reduced TTC, and
new business, as well as by the fact that
enabling technologies such as virtualization and SDN are gaining maturity.
The target architecture is built on
interfaces that support the principles of
service and resource abstraction, multitenancy and programmability. Interdomain interfaces also support business
relations, as they include security and
SLAs, as well as separation of responsibility and accountability.
As a first important transformation
step toward the target architecture,
FIGURE 7 Architecture evolution
Business frame agreement
interfaces, non-real time,
not automated
Business and cross-domain
operations
Business agreement
interfaces, rather
static, not automated
BSS
Business management
X-dom
COMPA
Isolated per-tenant
EPC instances
Management
configuration
interface
COMPA
Expose
EPC
Expose
EPC
EPC
COMPA
Current architecture
E R I C S S O N R E V I E W • 2/2014
R&S
Process
Target architecture
Store
APIs within frame
agreement, real-time
and programmable
53
network programmability, but network
operations and services also need to be
controlled through operational policies
linked to business policies.
Due to the impact on operator processes and potentially even the business
ecosystem it is likely that the transformation will take place in a stepwise manner
over a significant period of time – with
different parts of the network evolving
at different rates. In addition, the resulting network architecture will support
5G radio evolution and the associated use
cases and requirements.
BOX B Main principles of the target architecture
Separation of concerns
Each domain has full responsibility over the resources and
operations performed inside the domain.
Exposure and abstraction of capabilities
The abstraction of functions into APIs that are exposed as
services supports domain inter-operability, which enables
automation and programmability.
Multi-tenancy
Each domain offers full isolation of how the different users
(tenants) use domain resources.
Intra-domain programmability
This is achieved by leveraging automation and
programmability within an administrative domain through its
COMPA functions.
Inter-domain programmability
Each domain exposes capabilities and services using welldefined APIs to achieve an end-to-end service offering,
orchestrated by the cross-domain COMPA functionality.
References
1. ETSI, 2014, Draft Group Specification, Security and Trust
Guidance, NFV ISG Spec, available at: http://docbox.
etsi.org/isg/nfv/open/Latest_Drafts/nfv-sec003v111
security and trust guidance.pdf
2. Ericsson Review, May 2014, IP-optical convergence: a
complete solution,available at: http://www.ericsson.com/
news/140528-er-ip-optical-convergence_244099437_c
3. Ericsson Review, February 2013, Software-defined
networking: the service provider perspective,
available at: http://www.ericsson.com/news/130221software-defined-networking-the-service-providerperspective_244129229_c
4. Ericsson Review, March 2014, Virtualizing network
services – the telecom cloud, available at: http://www.
ericsson.com/news/140328-virtualizing-networkservices-the-telecom-cloud_244099438_c
5. Ericsson Review, July 2014, Communications as a cloud
service: a new take on telecoms, available at: http://www.
ericsson.com/news/140722-communications-as-acloud-service-a-new-take-on-telecoms_244099436_c
6. Ericsson Review, June 2014, 5G Radio Access,
available at: http://www.ericsson.com/
news/140618-5g-radio-access_244099437_c
E R I C S S O N R E V I E W • 2/2014
54
Torbjörn Cagenius
Göran Rune
Ignacio Mas
is an expert in distributed
network architecture at
Business Unit Cloud and IP. He
joined Ericsson in 1990 and has
worked in a variety of technology areas such
as FTTH, main-remote RBS, FMC, IPTV,
network architecture evolution, SDN and
NFV. In his current role, he focuses on cloud
impact on network architecture evolution.
He holds an M.Sc. from KTH Royal Institute
of Technology, Stockholm, Sweden.
is a principal researcher at
Ericsson Research. His current
focus is the functional and
deployment architecture of
future networks, primarily 5G. Before joining
Ericsson Research, he held a position as an
expert in mobile systems architecture at
Business Unit Networks focusing on the
end-to-end aspects of LTE/EPC, as well as
various systems and network architecture
topics. He joined Ericsson in 1989 and has
held various systems management
positions, working on most digital cellular
standards, including GSM, PDC, WCDMA,
HSPA, and LTE. From 1996 to 1999, he was a
product manager at Ericsson in Japan, first
for PDC and later for WCDMA. He was a key
member of the ETSI SMG2 UTRAN
Architecture Expert group and later 3GPP
TSG RAN WG3 from 1998 to 2001,
standardizing the WCDMA RAN
architecture. He studied at the Institute of
Technology at Linköping University,
Sweden, where he received an M. Sc. in
applied physics and electrical engineering
and a Lic. Eng. in solid state physics.
is a system architect at Group
Function Technology and an
expert in network architecture.
He holds a Ph.D. in
telecommunications from KTH Royal
Institute of Technology, Stockholm, and an
M.Sc. from both KTH and the Technical
University of Madrid (UPM). He joined
Ericsson in 2005 and has worked in IETF
standardization, IPTV and messaging
architectures, as well as media-related
activities for Ericsson Research. He is a
member of the Ericsson System Architect
Program (ESAP) and has research interests
in QoS, multimedia transport, signaling and
network security, IPTV and, most recently in
cloud computing.
Erik Westerberg
joined Ericsson from MIT,
Massachusetts, the US, in
1996 and currently holds the
senior expert position in
system and network architecture. In his
first 10 years at Ericsson, he worked with
the development of mobile broadband
systems before broadening his scope to
include the full network architecture,
serving as chief network architect until
2014. He holds a Ph.D. in quantum physics
from Stockholm University, Sweden.
Henrik Basilier
Lars Angelin
is an expert at Business Unit
Cloud and IP. He has worked for
Ericsson since 1991 in a wide
range of areas and roles. He is
currently engaged in internal R&D studies
and customer cooperation in the areas of
cloud, virtualization and SDN. He holds an
M.Sc. in computer science and technology
from the Institute of Technology at
Linköping University, Sweden.
is an expert in the multimedia
management technology area
at Business Unit Support
Solutions. He has more than 28
years of experience in the areas of concept
development, architecture and strategies
within telecom and education. He joined
Ericsson in 1996 as a research engineer, and
in 2003 he moved to the position of concept
developer for telco-near applications,
initiating and driving activities mostly
related to M2M and OSS/BSS. He holds an
M.Sc. in engineering physics and a Tech.
Licentiate in tele-traffic theory from Lund
Institute.
E R I C S S O N R E V I E W • 2/2014
Balázs Varga
joined Ericsson in 2010 and
he is an expert in multiservice
networks at Ericsson Research.
His focus is on packet evolution
studies to integrate IP, Ethernet and MPLS
technologies for converged mobile and fixed
network architectures. Prior to Ericsson, he
worked for Magyar Telekom on the
enhancement of broadband services
portfolio and introduction of new broadband
technologies. He has many years of
experience in fixed and mobile
telecommunication and also represents
Ericsson in standardization. He holds a
Ph.D. in telecommunication from the
Budapest University of Technology and
Economics, Hungary.
Acknowledgements
The authors gratefully acknowledge their
colleagues who have contributed to
this article: Jaume Rius i Riu and Ulf Olsson.
Ericsson
SE-164 83 Stockholm, Sweden
Phone: + 46 10 719 0000
ISSN 0014-0171
297 23-3237 | Uen
Edita Bobergs, Stockholm
© Ericsson AB 2014

Issue 2/2014

Transcription

Similar documents

E-HEALTH CROATIA - Ericsson Nikola Tesla

Ciudad de México, a 12 de julio de 2016 PLENO DEL INSTITUTO

RAN and Backhaul network

Prelude 9x12 HS Cover

iPPlus Sales Sheet - IP Plus Consulting, Inc.

Dries Harnie Elisa Gonzalez Boix Lode Hoste Andoni Lombide

Northern Rivers RDA Michael Whereat – Sunshine Coast Council

Hudiksvall Municipality Hudiksvall Municipality, Sweden

January 2015 - ZATIS TECHNOLOGY GROUP