Virtualizing network services – the telecom cloud - CiteSeerX

The communications technology journal since 1924

Virtualizing network services – the telecom cloud March 28, 2014

2014 • 3

The telco cloud 2

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. H E N R I K BA S I L I E R , M A R I A N DA RU L A A N D JOE W I L K E

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 significant innovation challenge for the ICT industry. Traditional telecom product development is deeply rooted in standards,

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 network design has led to the formation of the Network Functions Virtualization (NFV) consortium. Simplified operation of virtualized network platforms and hardware-independent network functionality are just some of this group’s aims2. The benefits offered by next generation 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 virtualization and cloud techniques to manage resources in terms of their storage, computational and networking needs. Virtualization and the technologies related to it, such as cloud orchestration,

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 E R I C S S O N R E V I E W • MARCH 28, 2014

OSS OVF SAF SBG SDN SLA TCO VDC VLAN VM VNF VR VRRP WAN XaaS

operations support systems Open Virtualization Format Service Availability Forum Session Border Gateway software-defined networking Service Level Agreement total cost of ownership virtual data center virtual local area network virtual machine virtual network function virtualized router Virtual Router Redundancy Protocol wide area network anything as a service

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 general aim of SDN and NFV is to deliver functions, networks and infrastructure as services rather than as features of vertically integrated systems. This enables operators to offer communication 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 providers of M2M communication, by supporting 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 contribute to this complexity, including: the need for security zoning; overcoming addressing constraints; the requirement for a high degree of statefulness, which in turn creates needs for load balancing and mechanisms to ensure high availability; as well as the way standards have been defined and legacy implementation choices. Telco applications often require multiple VPNs and virtual local area networks (VLANs), subnets with additional routing, as well as sophisticated load balancers, firewalls, address translators, transparent proxies, and QoS/policybased routing. The process to integrate all of these elements is often both static

3

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 systems 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 services 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 provide all networking capabilities, as well as ensure the interworking and portability of telco applications. To keep costs down, the impact of migration on applications should be kept to a minimum – however, with some application adaptation, it is possible to further take advantage of the automation and elasticity offered by cloud and virtualization technologies. This article describes the requirements 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 organizational 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 virtually, 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 isolation. Operator solutions are deployed in

FIGURE 1  The real-time telecom cloud

Cloud tenants, virtual data centers (VDCs), telco VNFs

Telco solutions and applications

Cloud infrastructure(s)

Transport

VDCs and telco applications and nodes become telco virtual network functions (VNFs) – implemented as portable containers for multiple virtual machines (VMs). As illustrated in Figure 1, the cloud infrastructure fulfills the interconnect capability along with other infrastructure requirements that are provided by site infrastructure and transport networks in non-virtualized environments. Interconnectivity needs to be maintained between virtualized and nonvirtualized networks, and domain managers for telco solutions (OSSs) need to be able to manage dedicated infrastructure as well as virtual resources. Telco systems and applications place tough demands on the networking capabilities of cloud infrastructure. This is because the requirements of telco systems are much more stringent and varied 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 infrastructure 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 discoverability and traceability. In a cloud infrastructure, the concepts 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 separation are required by all functions and API components. For tenants, cloud computing is ultimately about increasing flexibility, reducing complexity and time to market, as well as improving cost-efficiency. Providers of cloud infrastructure services can help tenants to achieve E R I C S S O N R E V I E W • MARCH 28, 2014

The telco cloud 4

FIGURE 2  Multi-tenant cloud architecture

Tenant 2

Tenant 1 Tenant domain manager Domainspecific life cycle management

Tenant domain manager

VDC

Telco VNF

Domainspecific life cycle management

Telco VNF

VDC

Telco VNF

Telco VNF

VDC management Cloud infrastructure domain Cloud orchestrator

External networks

Cloud infrastructure Data center

these goals by providing generic abstractions of services with a high degree of automated life cycle management 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 functionality that is specific to their solution 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 creation/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 E R I C S S O N R E V I E W • MARCH 28, 2014

WAN

Data center

in resources. Descriptors of VDCs and VNFs exchanged with the cloud infrastructure serve as a contract between the two responsibility domains, and may also include SLAs. A virtual data center is a managed collection 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 interconnected 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 networking purposes, each tenant is required to supply descriptions of all

their telco VNFs, as well as of the solution/VDC level. To automate the allocation of all the requested resources, the cloud infrastructure uses what is commonly referred to as orchestration technologies. 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 capabilities, such as firewalling, load balancing and service chaining can be ordered as resources within a VDC. From the tenant perspective, all network resources are virtual and fully isolated. Although SDN control can be exposed to the tenant (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 infrastructure, the data center needs to be connected to the internet or to a private VPN. The need for external connectivity should be described by the tenant in the form of connection points at the network edges of the VDC. Authorization of the requested connectivity is granted by the cloud orchestrator, which (as part of the orchestration process) also configures the actual routing/switching functions 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

5

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 description formats. To guide the orchestration of resources, these descriptions also include SLA-related parameters, such as affinity/anti-affinity rules and latency requirements. As illustrated in Figure 3, the relationships 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 connection points that the VDC networking description needs to resolve into networks defined within the VDC description. 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

FIGURE 3  Logical connection points in VDC networking

External transport WAN

Telco VNF 1 Internal network

External VPN 2

LBaaS VDC network VM

VM Cloud edge

External VPN 1

Telco VNF 2 VDC network

VM

Cloud edge aaS

VDC execution (tenant view)

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 deployment in different virtualized target environments, applications should be made available and packaged in a hypervisor-neutral virtual-machine file format – preferably the Open

FIGURE 4  An example of telco VNF realized as a cluster of VMs accommodating multiple logical fucntions

CSCF

VM1

I-CSCF

VM2

VM3

VM4

S-CSCF

VM5

BGCF

VM6

S-CSCF/BGCF OAM

I-CSCF Scalable distributed system

VNF internal VLAN

OAM VLAN

Application layer signaling VLANs

E R I C S S O N R E V I E W • MARCH 28, 2014

The telco cloud 6

FIGURE 5  Connectivity and transport solution among telco VNFs

VNF VM

VNF VM

VM

VM

VM

VM

VM

VM

VRRP VR

VR Application signaling VPN OAM VPN

Virtualization Format (OVF) specified by the Distributed Management Task Force (DMTF). When deploying telco solutions, the set of OVF files containing deployment instructions is ingested by the cloud manager orchestration function, and the network solution is deployed accordingly. Similarly, the VDC needs to be described in a format that is suitable for automation. 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 telecom 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 cluster 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 logical functions and are usually designed to be used by large numbers of subscribers and to support heavy traffic loads. Scalable capacity is a fundamental part of telco application design, and implementation typically uses cluster E R I C S S O N R E V I E W • MARCH 28, 2014

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 structure from the surroundings and thus providing a manageable network solution with low opex. Such an architecture allows the telco VNF to be scaled dynamically to fit traffic conditions, where scaling can be achieved by adding or removing cluster members. As such, the virtualized solution provides obvious advantages when scaling can be achieved by simply turning a VM on or off. The entire cloud deployment needs to be optimized from a transport and storage perspective, so that, for example, an increase or decrease in available resources automatically generates a corresponding adaptation of transport layer bandwidth and storage capacity. Proper operation of a telco VNF

cluster requires reliable, secure and high performance intra-cluster communication as well as communication 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 different 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/network operations center (NOC); and one VLAN for application layer communication among the network functions (NFs) in the IMS network architecture. In addition, some telco VNFs, such as Session Border Gateway (SBG), communicate 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 communication 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 centers is to deploy nodes together with virtualized 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 communicate 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 automatic deployment without the need for any manual correction. Quality remains the same Traditional telecom networks are designed to provide uninterrupted service and a superior user experience. The high availability and real-time characteristics of telco applications supported by related infrastructure capabilities are key capabilities that help operators achieve their targeted levels of service and QoE, and these targets are the same for both traditional and virtual

7

environments. However, virtualization poses additional challenges that need to be overcome. Telco VNFs typically include built-in support for resilience, such as availability support in core middleware based on OpenSAF. Consequently, certain rules need to be taken into consideration when deploying telco VNF clusters in a virtualized environment. For example, it’s not a good idea to deploy all VMs on the same hardware, as a hardware failure would cause complete node outage. Such deployment rules can be specified in OVF, so that correct deployment is performed when a cloud manager ingests the OVF file during initial deployment. Telco applications can in turn make the most of features provided by the infrastructure to, for example, maintain 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 telecomspecific requirements. NFV was established as an industry consortium to ensure alignment within the telecom segment, enabling operators to deploy network functions in an automated way on state-of-the art computational and storage entities. Such a move from vertically-integrated purpose-built systems to high-scale generic hardware is an attractive one for operators, as it results in more homogenous systems, reducing the costs associated with complexity and proprietary hardware. This ability to replace static and manual 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 orchestration domain, reference points connect the layers in the non-management

FIGURE 6  NFV reference architecture

NFV management and orchestration Os-Ma

OSS/BSS Service, VNF and infrastructure description

EMS 1 VNF 1

EMS 2

EMS 3

VNF 2

Orchestrator

Se-Ma Or-Vnfm Ve-Vnfm

VNF manager(s)

Or-Vi

VNF 3 Vi-Vnfm

Vn-Nf NFVI Virtual computing

Virtual storage

Virtual network

Virtualized infrastructure manager(s)

Nf-Vi

Virtualization layer Vi-Ha Computing hardware

Hardware resources Network Storage hardware hardware

Execution reference point Other reference point Main NFV reference point

FIGURE 7  IMS core network example

CUDB

L3aaS

MTAS

L3aaS

iCSCF

sCSCF

HSS

L3aaS

L3aaS

VPN aaS

FWaaS

OM

N-SBC

LBaaS

L3aaS

FWaaS

GRX

MRF

BGF

A-SBC

LBaaS

L3aaS

FWaaS

Access

IP works

E R I C S S O N R E V I E W • MARCH 28, 2014

The telco cloud 8

FIGURE 8  Multi-tenant multi-instance IMS network in VDC

Central storage

DC switch FW

Tenant 2 network

domain, which contains: a support systems layer (OSS/BSS), a layer representing the virtualized network functions, and a third layer (NFVI) that represents the infrastructure containing both virtualized and physical resources. In the near future, ETSI NFV requirements will be translated into appropriate standards. Example case – IMS An IMS core network is based on standardized interconnected logical functions whose operation in a virtual data center would be supported by additional infrastructure-related functions such as firewalling and load balancing. Figure 7 illustrates an example IMS core network. Cloud deployment creates the possibility 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 E R I C S S O N R E V I E W • MARCH 28, 2014

HSS cluster

MTAS cluster

VR

VR

VR

PGM

IDNS

MFRP

OAM Signaling Media

Tenant 1

Core

Access

SBG

CSCF cluster

Storage

Access

Tenant 1 network

OAM

Tenant 2

NOC

Tenant 1 IMS network

CSCF cluster

HSS cluster

MTAS cluster

VR

VR

VR

PGM

IDNS

MFRP

OAM Signaling Media

Tenant 2 IMS network

tenant. An example of such deployment is illustrated in Figure 8. Tenants are deployed over a shared cloud infrastructure in which the networking solution guarantees tenant separation – fulfilling security requirements and fair use of resources. As Figure 8 illustrates, the requirements placed on the cloud infrastructure 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 enterprises, and routing and complex interconnect with legacy networks/VPNs – and all of these requirements not only need to be implemented, they also need to be automated. The functionality provided by the virtual data center needs to cover all of these aspects, on top of providing true tenant separation, realtime performance, geographical distribution and telecom-grade availability. Automation and dynamicity are key elements 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 infrastructure 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 vertical – inseparable – towers that become overly complex and are as a result costly to operate. Spearheaded by the IT industry, a shift toward providing everything as a service is taking place. Adopting a similar approach for network functions 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 infrastructure must ensure the robustness, performance, security and interoperability for telco applications, minimizing the costs induced by the transformation itself. This requires a system that provides telco apps with a smooth transition 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 applications and solutions.

References

1. Ericsson, November 2013, Mobility Report, available at: http://www. ericsson.com/res/docs/2013/ ericsson-mobility-reportnovember-2013.pdf 2. ETSI, NFV role and activities, available at: http://www.etsi. org/technologies-clusters/ technologies/nfv

9

Henrik Basilier

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-tofive 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. 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, 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

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.

ISSN: 0014-0171 Volume: 91, 2014

E R I C S S O N R E V I E W • MARCH 28, 2014

Ericsson SE-164 83 Stockholm, Sweden Phone: + 46 10 719 0000

ISSN 0014-0171 284 23-3223 | Uen © Ericsson AB 2014