Virtualizing network services
– the telecom cloud
Virtualizing network services
– the telecom cloud
Inspired by a transformation in neighboring industry sectors toward providing information,
products and functions as services – XaaS – the telecommunication industry is evolving the
architecture of its systems and networks. This new generation of architecture is characterized
by a very high degree of abstraction and virtualization.
carry the transformational power that is needed to reap the benefits offered by higher levels of abstraction.
Modern virtualization technologies, such as software-defined networking (SDN), in combination with existing tools for storage and computing, ensure virtualization and abstraction for the entire set of critical resources. The gen-eral aim of SDN and NFV is to deliver functions, networks and infrastruc-ture as services rather than as feainfrastruc-tures of vertically integrated systems. This enables operators to offer communica-tion services at the right price points for subscribers, by serving the next generations of terminals like high-end smartphones, tablets, and 3D glasses. In addition, this enables operators to offer low-price connectivity to service pro-viders of M2M communication, by sup-porting devices like utility meters and health care equipment.
The nature of telecoms today
The network setup for telco applications tends to be quite sophisticated, and there are a number of factors that con-tribute to this complexity, including: the need for security zoning; overcom-ing addressovercom-ing constraints; the require-ment for a high degree of statefulness, which in turn creates needs for load bal-ancing and mechanisms to ensure high availability; as well as the way standards have been defined and legacy imple-mentation choices.
Telco applications often require mul-tiple VPNs and virtual local area net-works (VLANs), subnets with additional routing, as well as sophisticated load bal-ancers, firewalls, address translators, transparent proxies, and QoS/policy-based routing. The process to integrate all of these elements is often both static protocols and service quality – a model
that has served the industry well, until recently. But the situation has changed. Increased competition, the perceived high cost of proprietary hardware and the need for reduced complexity in net-work design has led to the formation of the Network Functions Virtualization (NFV) consortium. Simplified operation of virtualized network platforms and hardware-independent network func-tionality are just some of this group’s aims2.
The benefits offered by next genera-tion systems include rapid deployment of new services, ease of scalability and reduced duplication. These systems are primarily being built with mass-market technologies that capitalize on virtual-ization and cloud techniques to man-age resources in terms of their storman-age, computational and networking needs. Virtualization and the technologies related to it, such as cloud orchestration,
H EN R I K BA SI L I ER, M A R I A N DA RU L A A N D JOE W I L K E
BOX A Terms and abbreviations
ADC application delivery controller
API application programming interface
ARPU average revenue per user
BFD Bidirectional Forwarding Detection
DMTF Distributed Management Task Force
EPC Evolved Packet Core
M2M machine-to-machine
NF network function
NFV Network Functions Virtualization
NIC network interface card
NOC network operations center
OAM operations, administration and
maintenance
ONF Open Networking Foundation
OSPF Open Shortest Path First
OSS operations support systems
OVF Open Virtualization Format
SAF Service Availability Forum
SBG Session Border Gateway
SDN software-defined networking
SLA Service Level Agreement
TCO total cost of ownership
VDC virtual data center
VLAN virtual local area network
VM virtual machine
VNF virtual network function
VR virtualized router
VRRP Virtual Router Redundancy Protocol
WAN wide area network
XaaS anything as a service The demand for bandwidth
created by subscribers and devices has been rising steadily for a number of years. The amount of data carried by mobile networks is doubling roughly every year1, and the number of
connected machine-to-machine (M2M) devices – sensors and actuators – is expected to reach 50 billion by 2020. However, average revenue per user (ARPU) is declining in most markets, and the price point for connectivity for many M2M devices is low.
The subsequent catch-22 situation – where infrastructure growth is needed to meet increased demand in the face of hard-pressed revenue margins – is a sig-nificant innovation challenge for the ICT industry.
Traditional telecom product devel-opment is deeply rooted in standards,
and manual, which is time consuming and leads to inaccuracies. Being able to integrate elements automatically, through say automatic orchestration with SDN technologies, is a vital step in the creation of new generation sys-tems that will reduce time to market for the deployment of new services and increase operational flexibility. Benefits and cost
For operators, the return on investment associated with migrating network ser-vices to the cloud comes in the form of reduced TCO, improved TTM and a very high degree of automation in network operation – all of which improve the bottom line.
To guarantee continued service, a migrated environment needs to pro-vide all networking capabilities, as well as ensure the interworking and por-tability of telco applications. To keep costs down, the impact of migration on applications should be kept to a mini-mum – however, with some application adaptation, it is possible to further take advantage of the automation and elas-ticity offered by cloud and virtualiza-tion technologies.
This article describes the require-ments placed on telco applications as a result of increased abstraction, as well as the challenges a telecom cloud must overcome (including migration), and how these challenges differ from the general IT cloud. The article also gives some insight into the implementation aspects of the telecom cloud, what kind of services, APIs and capabilities are expected, and what technologies will be used.
The telecom cloud
An operator network can be described as a set of solutions, such as EPC or IMS/ VoLTE, split over multiple organiza-tional domains. In turn, these domains consist of sets of telco applications that interconnect using site infrastructure, such as switches, routers, firewalls and transport networks.
When a network is deployed virtu-ally, organizational domains within the operator becomes a tenant of the shared cloud infrastructure, which provides virtual data centers (VDCs) that serve as resource containers and zones of isola-tion. Operator solutions are deployed in
VDCs and telco applications and nodes become telco virtual network functions (VNFs) – implemented as portable con-tainers for multiple virtual machines (VMs). As illustrated in Figure 1, the cloud infrastructure fulfills the inter-connect capability along with other infrastructure requirements that are provided by site infrastructure and transport networks in non-virtualized environments.
Interconnectivity needs to be main-tained between virtualized and non-virtualized networks, and domain managers for telco solutions (OSSs) need to be able to manage dedicated infra-structure as well as virtual resources.
Telco systems and applications place tough demands on the networking capa-bilities of cloud infrastructure. This is because the requirements of telco sys-tems are much more stringent and var-ied than generic IT applications. Typical telco systems need support for:
multiple routing contexts and routing protocols;
multiple VPN connections to external networks;
packet-load-balancing capabilities for heavy payload applications – including additional capabilities than are typically included in application delivery controllers (ADCs);
support for virtual network interface cards (NICs) – to trunk large numbers of VLANs and interconnect to external
networks; path diversity;
service chaining – for bump-in-the-wire applications;
security zoning;
heavy-duty routing between tenant networks;
geo-redundancy mechanisms; and latency/QoS control.
In traditional networks, these features are provided by the site infrastructure. In the telecom cloud, these features need to be replicated by the cloud infra-structure in such a way that they can be orchestrated, as orchestrated features can be exposed through appropriate abstractions, as well as being coupled with advanced support for discoverabil-ity and traceabildiscoverabil-ity.
In a cloud infrastructure, the con-cepts of multi-tenancy and separation of concerns are crucial, as they enable organizations (tenants) to securely share the same space and manage their own virtual resources – implemented as isolated slices of the physical resources (VDCs in other words). Isolation and sep-aration are required by all functions and API components.
For tenants, cloud computing is ulti-mately about increasing flexibility, reducing complexity and time to mar-ket, as well as improving cost-efficiency. Providers of cloud infrastructure ser-vices can help tenants to achieve FIGURE 1 The real-time telecom cloud
Cloud tenants, virtual data centers (VDCs),
telco VNFs Cloud tenants, virtual data centers (VDCs),
telco VNFs Telco solutions and applications Telco solutions and applications Transport Transport Cloud infrastructure(s)Cloud infrastructure(s)
their telco VNFs, as well as of the solu-tion/VDC level. To automate the alloca-tion of all the requested resources, the cloud infrastructure uses what is com-monly referred to as orchestration tech-nologies. If WAN connectivity is needed for orchestration, it is provided by an underlying transport domain.
The basic networking capabilities provided to a tenant through the VDC construct can range in complexity from very basic L2 links to multiple networks with intra-routing. Advanced capabili-ties, such as firewalling, load balancing and service chaining can be ordered as resources within a VDC. From the ten-ant perspective, all network resources are virtual and fully isolated. Although SDN control can be exposed to the ten-ant (for service chaining purposes, for example), such control is restricted to isolated slices of the network under the management of the tenant SDN controller.
To connect to other VDCs or another network outside the cloud infrastruc-ture, the data center needs to be con-nected to the internet or to a private VPN. The need for external connectiv-ity should be described by the tenant in the form of connection points at the net-work edges of the VDC. Authorization of the requested connectivity is granted by the cloud orchestrator, which (as part of the orchestration process) also config-ures the actual routing/switching func-tions that connect networks within the data center to the outside. One of the aims of the telecom cloud is to automate this part of the process.
Service establishment
Setting up a telco service or solution inside the cloud involves a number of steps, which can be summarized as:
onboard instantiable descriptions/ templates of the telco VNFs; onboard instantiable descriptions/ templates of the VDCs;
instantiate the virtual data center – in which the cloud orchestrator allocates resources for shared use within a VDC; instantiate the desired telco VNFs within the VDC – the cloud orchestrator allocates the resources needed for the VNF and binds them to the VDC; and configure the application-specific elements of the telco VNFs.
Once a service is established, it enters these goals by providing generic
abstractions of services with a high degree of automated life cycle manage-ment for resources.
To manage the complete life cycle of application-layer functions contained in VDCs and VNFs, each tenant needs to provide the domain-manager func-tionality that is specific to their solu-tion domain. This manager interacts with the cloud infrastructure domain that manages the life cycle for virtual resources, it maintains descriptions of VDCs and VNFs, interacts with the cloud orchestrator for resource cre-ation/assignment/deletion, as well as integrating with application-specific management.
To take advantage of the elasticity that cloud computing provides, to, for example, scale out operations or direct network control, the application layer needs to adapt to real-time changes
in resources. Descriptors of VDCs and VNFs exchanged with the cloud infra-structure serve as a contract between the two responsibility domains, and may also include SLAs.
A virtual data center is a managed col-lection of computational, storage and networking slices provided to a tenant by the cloud infrastructure from its pool of resources – which may be distributed across a set of data centers. Resources assigned to a given tenant are isolated from other tenants, but can be intercon-nected through external networks and other VDCs. The tenant determines how this interconnection takes place on the basis of their security policies.
As illustrated in Figure 2, tenants can deploy network solutions within a VDC as a set of interconnected telco VNFs. For internal and external net-working purposes, each tenant is required to supply descriptions of all Data
center centerData
External networks External networks VDC management VDC management WAN WAN Cloud infrastructure domain
Cloud infrastructure domain
Cloud infrastructure Cloud infrastructure Cloud orchestrator Cloud orchestrator Tenant 1 Tenant 1 Tenant domain manager Tenant domain manager Tenant domain manager Tenant domain manager Tenant 2 Tenant 2 Telco VNF Telco VNF Telco VNF Telco VNF VDC VDC Domain-specific life cycle management Domain-specific life cycle management Domain-specific life cycle management Domain-specific life cycle management Telco VNF Telco VNF Telco VNF Telco VNF VDC VDC
service assurance mode, where the ability to both observe and trace the requested VDC and VNFs is key. Automating orchestration
To be able to automate processes through orchestration, a number of service establishment descriptions are needed, including:
descriptions of the telco VNF, specifying its needs, such as computational, storage and networking resources along with VM start order instructions; descriptions of other services and resources required by the cloud system, such as firewalling and load balancing; descriptions of the networking requirement for the VDC as a whole, including internal connectivity among VNFs as well as external connectivity, which includes definitions of service chains.
For automated orchestration to work, essentially everything that in the past was configured manually must now be made into machine-readable descrip-tion formats. To guide the orchestra-tion of resources, these descriporchestra-tions also include SLA-related parameters, such as affinity/anti-affinity rules and latency requirements.
As illustrated in Figure 3, the rela-tionships between the different types of descriptions need to be managed. A telco VNF (and its constituent parts) needs to connect with networks inside and outside the virtual data center. As such, they define the logical connec-tion points that the VDC networking description needs to resolve into net-works defined within the VDC descrip-tion. Likewise, the VDC descriptor needs to refer to logical connection points to (VDC or) external networks, which the cloud domain manager resolves into real network connections.
To support elastic operations such as scale out, with flexible and automated deployment of VNFs and VDCs, their descriptors (the VDCs and VNFs) should be viewed as templates for all resource assignments. As such, the containing VDC defines the network context for a VNF instance and scale out VMs use the VNF descriptor as a template.
The cloud infrastructure uses the descriptions provided by the tenant to orchestrate virtual networks as well as all other resources. Virtualized
Infrastructure Managers (such as OpenStack) orchestrate resource requests across multiple sites and layers of functionality, using SDN controllers to create virtual network connections derived from the provided descriptions. Automating deployment
To automate deployment of telco VNFs in virtual data centers and to reduce the effort required to support deploy-ment in different virtualized target environments, applications should be made available and packaged in a hypervisor-neutral virtual-machine file format – preferably the Open
Cloud edge Cloud edge Cloud edge aaS Cloud edge aaS External VPN 2 External VPN 2 External transport WAN External transport WAN External VPN 1 External VPN 1 VM VM VMVM LBaaS LBaaS VM VM
VDC execution (tenant view) VDC execution (tenant view)
Telco VNF 1 Telco VNF 1 Telco VNF 2 Telco VNF 2 VDC networkVDC network VDC networkVDC network Internal networkInternal network
FIGURE 3 Logical connection points in VDC networking
VM1 VM1 VM2VM2 VM3VM3 VM4VM4 OAM OAM S-CSCF/BGCF S-CSCF/BGCF I-CSCF I-CSCF VM5 VM5 VM6VM6 CSCF CSCF I-CSCFI-CSCF S-CSCFS-CSCF BGCFBGCF
Scalable distributed system Scalable distributed system
VNF internal VLAN VNF internal VLAN OAM VLAN OAM VLAN Application layer signaling VLANs Application layer signaling VLANs
FIGURE 4 An example of telco VNF realized as a cluster of VMs accommodating multiple logical fucntions
cluster requires reliable, secure and high performance intra-cluster com-munication as well as communica-tion with neighboring networks. This is implemented by adopting L2, VLAN and IP-VPN technologies in the VDC.
To separate the communication for different trust domains, VMs use dif-ferent VLANs. To start with, there is one VLAN for communication among the VMs within the telco VNF; one VLAN for operations, administration and maintenance (OAM) communication between the telco VNF and the OSS/net-work operations center (NOC); and one VLAN for application layer communica-tion among the network funccommunica-tions (NFs) in the IMS network architecture.
In addition, some telco VNFs, such as Session Border Gateway (SBG), commu-nicate with users and other operators; such VNFs require an additional VLAN per access domain and per interconnect network.
For security and L3 load balancing reasons, IP routers are used for commu-nication among telco VNFs – there is no direct VLAN connectivity between telco VNFs. This concept is illustrated in Figure 5.
The best solution for virtual data cen-ters is to deploy nodes together with vir-tualized routers (VRs). VRs host router functions and serve different traffic types, such as application signaling or OAM. VRs – one per security domain – are used by telco VNFs to communi-cate with each other and externally. VRs support Open Shortest Path First (OSPF), Bidirectional Forwarding Detection (BFD) and link load balancing for the telco VNF as well as forwarding filters. The complete solution, including VNFs, can be described by, for example, an evolved OVF description, enabling auto-matic deployment without the need for any manual correction.
Quality remains the same
Traditional telecom networks are designed to provide uninterrupted ser-vice and a superior user experience. The high availability and real-time charac-teristics of telco applications supported by related infrastructure capabilities are key capabilities that help opera-tors achieve their targeted levels of ser-vice and QoE, and these targets are the same for both traditional and virtual VM VM VMVM VMVM VMVM VR VR VRVR VRRP VRRP VNF VNF VM VM VMVM VMVM VMVM VNF VNF Application signaling VPN OAM VPN Application signaling VPN OAM VPN
FIGURE 5 Connectivity and transport solution among telco VNFs
Virtualization Format (OVF) spec-ified by the Distributed Management Task Force (DMTF). When deploying telco solutions, the set of OVF files con-taining deployment instructions is ingested by the cloud manager orches-tration function, and the network solu-tion is deployed accordingly. Similarly, the VDC needs to be described in a for-mat that is suitable for autofor-mation. Both descriptor levels need to encompass all applicable networking.
Telco applications in the cloud
A cloud-based networking solution needs to support QoS to guarantee tele-com quality and real-time behavior, and at the same time it needs to be flexible to automate deployment and connectivity within the VNF – implemented as a clus-ter for scaling.
An application implements a logical function, and its interfaces are defined by standards like 3GPP and IETF. Telco VNFs accommodate one or more logi-cal functions and are usually designed to be used by large numbers of sub-scribers and to support heavy traffic loads. Scalable capacity is a fundamen-tal part of telco application design, and implementation typically uses cluster
architecture. This applies to traditional (non-cloud) deployment as well as deployment in a virtual data center. In the virtual environment, the software of a telco VNF cluster runs on a set of (OS-inclusive) virtual machines (VMs).
A telco VNF built on a clustered architecture can be dimensioned to fit expected capacity by deploying the right number of VMs. The application, however, is exposed as a single entity on a network level, hiding internal struc-ture from the surroundings and thus providing a manageable network solu-tion with low opex.
Such an architecture allows the telco VNF to be scaled dynamically to fit traf-fic conditions, where scaling can be achieved by adding or removing cluster members. As such, the virtualized solu-tion provides obvious advantages when scaling can be achieved by simply turn-ing a VM on or off.
The entire cloud deployment needs to be optimized from a transport and storage perspective, so that, for exam-ple, an increase or decrease in available resources automatically generates a corresponding adaptation of transport layer bandwidth and storage capacity.
OSS/BSS OSS/BSS
EMS 1
EMS 1 EMS 2EMS 2 EMS 3EMS 3 VNF 1 VNF 1 Virtual computingVirtual computing Computing hardware Computing
hardware hardwarehardwareNetworkNetwork
Execution reference point Other reference point Main NFV reference point Execution reference point Other reference point Main NFV reference point Hardware resources Hardware resources Storage hardwareStorage hardware Virtual storageVirtual storage Virtualization layer Virtualization layer Vn-Nf Vn-Nf Os-Ma Os-Ma Or-Vnfm Or-Vnfm Or-Vi Or-Vi Vi-Vnfm Vi-Vnfm Se-Ma Se-Ma Ve-Vnfm Ve-Vnfm Nf-Vi Nf-Vi Vi-Ha Vi-Ha NFVI NFVI Virtual networkVirtual network VNF 2 VNF 2 VNF 3VNF 3 Service, VNF and infrastructure
description Service, VNF and infrastructure
description
Orchestrator Orchestrator
NFV management and orchestration NFV management and orchestration
VNF manager(s)VNF manager(s) Virtualized infrastructure manager(s) Virtualized infrastructure manager(s)
FIGURE 6 NFV reference architecture environments. However, virtualization
poses additional challenges that need to be overcome.
Telco VNFs typically include built-in support for resilience, such as availabil-ity support in core middleware based on OpenSAF. Consequently, certain rules need to be taken into consider-ation when deploying telco VNF clus-ters in a virtualized environment. For example, it’s not a good idea to deploy all VMs on the same hardware, as a hard-ware failure would cause complete node outage. Such deployment rules can be specified in OVF, so that correct deploy-ment is performed when a cloud man-ager ingests the OVF file during initial deployment.
Telco applications can in turn make the most of features provided by the infrastructure to, for example, main-tain availability. For example, VMs can be automatically restarted on different hardware in the event of a failure. Industry movements
A wide variety of organizations, such as ETSI NFV, OpenStack, OpenDaylight, DMTF, ONF and IETF, are involved in the industry shift to cloud-deployed solutions. For operators, ETSI NFV has a more prominent role as a result of its development of overall frameworks and architectures and attention to telecom-specific requirements.
NFV was established as an industry consortium to ensure alignment within the telecom segment, enabling opera-tors to deploy network functions in an automated way on state-of-the art com-putational and storage entities. Such a move from vertically-integrated pur-pose-built systems to high-scale generic hardware is an attractive one for opera-tors, as it results in more homogenous systems, reducing the costs associ-ated with complexity and proprietary hardware.
This ability to replace static and man-ual configuration, including operations such as cabling, will be an important capability of efficient future systems. This is reflected in the NFV reference architecture, which is illustrated in
Figure 6 as the NFV management and orchestration domain.
From the management and orchestra-tion domain, reference points connect the layers in the non-management
MTAS
MTAS L3aaSL3aaS N-SBCN-SBC LBaaSLBaaS
iCSCF
iCSCF sCSCFsCSCF MRFMRF BGFBGF
L3aaS
L3aaS FWaaSFWaaS
HSS HSS L3aaS
L3aaS CUDB
CUDB L3aaSL3aaS
IP
worksIP
works
A-SBC
A-SBC LBaaSLBaaS L3aaSL3aaS FWaaSFWaaS
L3aaS
L3aaS VPNVPNaaSaaS FWaaSFWaaS
GRX GRX OM OM Access Access
1. Ericsson, November 2013, Mobility Report, available at: http://www. ericsson.com/res/docs/2013/ ericsson-mobility-report-november-2013.pdf
2. ETSI, NFV role and activities, available at: http://www.etsi. org/technologies-clusters/ technologies/nfv
References domain, which contains: a support
systems layer (OSS/BSS), a layer repre-senting the virtualized network func-tions, and a third layer (NFVI) that represents the infrastructure con-taining both virtualized and physical resources.
In the near future, ETSI NFV require-ments will be translated into appropri-ate standards.
Example case – IMS
An IMS core network is based on stan-dardized interconnected logical func-tions whose operation in a virtual data center would be supported by addi-tional infrastructure-related functions such as firewalling and load balancing.
Figure 7 illustrates an example IMS core network.
Cloud deployment creates the possi-bility to implement multiple instances of IMS core networks to serve different tenants by utilizing the multi-tenant capability of the cloud infrastructure. The set of telco VNFs that implements a given tenant’s IMS core network is deployed in the VDC dedicated to the
tenant. An example of such deployment is illustrated in Figure 8. Tenants are deployed over a shared cloud infrastruc-ture in which the networking solution guarantees tenant separation – fulfill-ing security requirements and fair use of resources.
As Figure 8 illustrates, the require-ments placed on the cloud infrastruc-ture are complex. Advanced VLAN handling for telco VNFs is required – as is path redundancy, the ability to cope with large numbers of VLANs for SBG access, interconnect for multiple enter-prises, and routing and complex inter-connect with legacy networks/VPNs – and all of these requirements not only need to be implemented, they also need to be automated. The functionality pro-vided by the virtual data center needs to cover all of these aspects, on top of providing true tenant separation, real-time performance, geographical distri-bution and telecom-grade availability. Automation and dynamicity are key ele-ments to providing a cloud offering as a service based on an IMS core. A VDC can be instantiated from a description on
demand, resulting in tenant networks being created or modified. Interconnect is established automatically by the infra-structure using orchestration and SDN technologies. The domain manager for the IMS application is responsible for these steps, as well as all other life cycle management, including, for example, runtime scale out operations.
Conclusion
Traditional network architecture is often built on proprietary hardware. Telecom systems are by nature verti-cal – inseparable – towers that become overly complex and are as a result costly to operate. Spearheaded by the IT indus-try, a shift toward providing everything as a service is taking place. Adopting a similar approach for network func-tions is one way for operators to expand infrastructure.
Some of the benefits of this type of network transformation are:
reduced complexity – which lowers running costs;
simplified in and out scalability – which makes efficient use of network resources and supports dynamic ability to respond to changes in capacity demand; and
reduced time to market for new services.
In addition to enabling new benefits and opportunities, the cloud infrastruc-ture must ensure the robustness, per-formance, security and interoperability for telco applications, minimizing the costs induced by the transformation itself. This requires a system that pro-vides telco apps with a smooth transi-tion and real-time fully telecom-adapted network support, while providing new sets of enablers that act as a bridge to a new era of cloud-empowered telco appli-cations and solutions.
Tenant 1 network Tenant 1
network Tenant 1 IMS networkTenant 1 IMS network
OAM OAM Signaling Signaling Media Media OAM OAM Signaling Signaling Media Media Tenant 2 IMS network
Tenant 2 IMS network NOC
NOC
OAM
OAM StorageStorage Central storage AccessAccess AccessAccess CoreCore Tenant 1Tenant 1 Tenant 2Tenant 2 Tenant 2 network Tenant 2 network VR VR DC switch FW DC switch FW VR VR VRVR CSCF clusterCSCF
cluster clusterclusterHSSHSS clusterclusterMTASMTAS PGMPGM IDNSIDNS MFRPMFRP
VR
VR VRVR VRVR CSCF
clusterCSCF
cluster clusterclusterHSSHSS clusterclusterMTASMTAS PGMPGM IDNSIDNS MFRPMFRP
SBG SBG
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
Publishing:
Ericsson Review articles and additional material are pub ished on: www ericsson.com/review. Use the RSS feed to stay informed of the latest updates.
Ericsson Technology Insights
All Ericsson Review articles are available on the Ericsson Technology Insights app available for
Android and iOS devices. Thelink 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, Deirdre P. Doyle, Dan Fahrman, Anita Frisell, Jonas Högberg, Patrik Jestin,Magnus Karlsson, Cenk Kirbas, Sara Kullman, Börje Lundwall, Hans Mickelsson, Ulf Olsson, Patrik Regårdh, Patrik Roséen and Gunnar Thrysin
Editor:
Deirdre P. Doyle
deirdre.doyle@jgcommunication se
Contributors:
Paul Eade, Nathan Hegedus and Ian Nicholson
Art director and layout:
Carola Pilarz Illustrations: Claes-Göran Andersson ISSN: 0014-0171 Volume: 91, 2014 Henrik Basilier is an expert at Business Unit Networks. He has worked for Ericsson since 1991 in a wide area of subjects 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.
Marian Darula
is head of Network Transformation at Development Unit Core Networks, Architectures and Technology. He is currently leading the technology project for telecom networks transformation adopting cloud technologies and NFV. He holds a Ph.D. in theoretical electronics from the Institute of Electrical Engineering, Slovak Academy of Sciences, Bratislava, Slovakia and a degree in applied mathematics and software engineering from Czech Technical University, Prague, Czech Republic.
Joe Wilke
is head of Development Unit IP & Broadband Technology Aachen and currently manages the technology leadership program for network virtualization and cloud. He holds a degree in electrical engineering from the University of Aachen, Germany and a degree in engineering and business from the University of Hagen, Germany.