Anytime, anywhere, any device...

The communications technology journal since 1924 2/2012 Next-generation signaling networks 4 A converged approach to mobile financial services 10 Big-data technologies in network architecture 16 Achieving carrier-grade Wi-Fi in the 3GPP world 24 Deploying telecom-grade products in the cloud 30 Enabling the networkembedded cloud 35

Editorial Anytime, anywhere, any device... Welcome to Ericsson Review a magazine in the process of change. After 88 years of being delivered to you as an ink-and-paper product, this publication is about to undergo one of the most significant transformations in its history. From 2013, it will become a purely digital product that you will be able to access and interact with when, where and however you like. For me, this is an exciting development, and one I hope you ll agree that is in keeping with the cutting-edge technical content Ericsson Review has always brought to its readers. It also places Ericsson among a growing number of companies that are benefiting from a complete shift to the digital sphere. Just a few months ago, in October 2012, the publishers of the celebrated US news magazine Newsweek announced they were taking a similar step after 80 years of print. Given that Ericsson is a world leader in communications technology, it makes sense for us to be among the first to focus on digital distribution. One of the main benefits you will gain from this transition is ease of access to our content. To date, Ericsson Review articles have been published regularly both on ericsson.com and on our tablet application, and then packaged together in the form of this printed journal. With the shift to digital, you ll be able to read Ericsson Review articles whenever you like on your chosen device. Due for release in early 2013, our new mobile app is suitable for both tablets and smartphones, giving you access to Ericsson Review content, Ericsson s White Papers as well as research papers. I think perhaps the biggest advance, though, is in the area of interaction. We ve long encouraged you to interact with us through the Ericsson website and in social media. Soon you ll have more opportunities to do this. You ll be able to comment on Ericsson Review articles, and discuss your opinions in real time with other readers and hopefully the authors as well. This is a way of interrelating that yesterday s readers could only dream of. The Networked Society is truly upon us, as revealed in Ericsson s latest Mobility Report, which predicts an annual growth rate in mobile traffic of 50 percent until 2018. I think digital communication celebrates these developments. And I look forward to increased interaction with you and welcome your engagement in discussing our upcoming Ericsson Review articles. Let s not forget that the printed journal has served us well. It has helped generations of professionals and students keep abreast of the latest technological developments in our industry by communicating in a clear and effective way. Yet the future promises much more. Please join us then, and in the meantime enjoy this last printed edition of Ericsson Review. Regardless of device type, online video is the biggest contributor to traffic volumes (25-40 percent), followed by web browsing (15-20 percent). Ulf Ewaldsson Chief Technology Officer Head of Group Function Technology at Ericsson

CONTENTS 2/2012 Ericsson Review is a technology journal designed to open and encourage discussion. The aim of the journal is to high ight current research in information and communications technology. The journal is distributed to readers in more than 130 countries. Address : Telefonaktiebolaget LM Ericsson SE-164 83 Stockholm, Sweden Phone: +46 8 719 00 00 Fax: +46 8 522 915 99 Internet: www ericsson.com/review Subscriptions: Ericsson Review is distributed through Ericsson s regional offices. If you wish to receive a copy, contact your local Ericsson company. Articles and additional material are pub ished on www ericsson.com/review. Here you can use the RSS feed to keep informed of the latest updates. Ericsson Review app: The articles in this issue are also available on the Ericsson Review app for Android and Apple tablets. The ink for your device is on the Ericsson Review website: www ericsson.com/review. Distribution: Strömberg Distribution AB Publisher: U f Ewaldsson Editorial board: Håkan Andersson, Hans Antvik, Ulrika Bergström, Joakim Cerwall, Deirdre P. Doyle, Dan Fahrman, Anita Frisell, Magnus Frodigh, Dag Helmfrid, Jonas Högberg, U f Jönsson, Magnus Karlson, Cenk Kirbas, Kristin Lindqvist, Per Ljungberg, Arne Norefors, U f Olsson, Patrik Regårdh and Patrik Roséen Editor: Deirdre P. Doyle deirdre.doyle@jgcommunication se Chief subeditor: Birgitte van den Muyzenberg Contributors: Daniel Dasey, Ian Nicholson, Tes in Seale and Michelle Walkden Art director: Carola Pilarz Illustrations: Claes-Göran Andersson Printer: Edita Västra Aros, Västerås ISSN: 0014-0171 Volume: 92, 2012 4 Diameter Signaling Controller in next-generation signaling networks The Diameter protocol is used widely in all-ip networks. Nearly everything that is connected to or is part of a network uses the protocol in some way. The evolved mobile-data nodes use it to communicate with each other and applications use it to get the data they need. The number of signaling messages being sent is rising rapidly, which is putting pressure on all parts of the network and particularly on gateways, charging systems, policy servers and user-data repositories. Deploying a Diameter Signaling Controller (DSC) a key network component can relieve some of this pressure while boosting operational efficiency and increasing the reliability of the internal signaling network. 10 A converged approach to mobile financial services The unique position MNOs hold in providing communication services and the potential revenue opportunities presented by mobile financial services have put m-commerce high on the agenda of most operators. M-commerce is still in its infancy, and the uptake of related services varies greatly from region to region. In Sub-Saharan Africa, for example, 14.5 percent of people over the age of 15 use their mobile phones to receive money, while the figure for Europe and Central Asia is 2.7 percent. The opportunities for operators would be greatly enhanced by the existence of a global ecosystem connecting mobile networks, banks and digital mobile-wallet (m-wallet) platforms, operating across systems, currencies and national borders. 16 Applying big-data technologies to network architecture When does data get big? People, devices and things are constantly generating massive volumes of data. At work people create data, as do children at home, students at school, people and things on the move, as well as objects that are stationary. Devices and sensors attached to millions of things take measurements from their surroundings, providing up-to-date readings over the entire globe data to be stored for later use by countless different applications. 24 Achieving carrier-grade Wi-Fi in the 3GPP world Shortly after the close of the 2012 Mobile World Congress, the GSMA announced a plan to collaborate with the Wireless Broadband Alliance (WBA) to simplify Wi-Fi-hotspot access for smartphones and tablets. Intended to provide subscribers with seamless cellular-to-wi-fi roaming, this joint GSMA/WBA initiative is based on the WBA Next Generation Hotspot (NGH) program and the Wi-Fi Alliance Passpoint certification known in the industry as Hotspot 2.0. 30 Deploying telecom-grade products in the cloud Cloud computing has come a long way from simply being virtual data warehousing the shapeless blob used to illustrate a network owned by another operator or organization, or to represent unknown architecture. Today s cloud solutions manage anything as a service (XaaS). This includes anything that an enterprise, government, organization or individual might need to go about their day. Cloud solutions house applications, databases, services, software, test environments, financial platforms and back-office systems. The cloud approach brings high accessibility through thin clients and apps, resource sharing, scalability and recovery all while providing economies of scale and pay-as-you-go pricing. However, this maturity and readiness to challenge new requirements results in a need for more stringent security demands. 35 Enabling the network-embedded cloud Making better, more dynamic use of cloud resources requires a whole new innovative architecture: the network-embedded cloud. This concept is based on a variety of computational and storage resources being embedded in the network, interconnected via provisioned WAN links, and distributed closer to the network edges to provide the right QoE and more flexible connectivity. Naturally, a change in architecture places new requirements on the way clouds integrate with networks. To implement the network-embedded cloud, some key enablers are required, one of which is elastic networking.

Signaling in IP networks 4 Diameter Signaling Controller in next-generation signaling networks At the heart of the evolved mobile data network almost everything uses the Diameter protocol to communicate. JÖRG EWERT, LENNART NORELL AND SONER YAMEN The Diameter protocol is used widely in all-ip networks. Nearly everything that is connected to or is part of a network uses the protocol in some way. The evolved mobile-data nodes use it to communicate with each other and applications use it to get the data they need. The number of signaling messages being sent is rising rapidly, which is putting pressure on all parts of the network and particularly on gateways, charging systems, policy servers and user-data repositories. Deploying a Diameter Signaling Controller (DSC) a key network component can relieve some of this pressure while boosting operational efficiency and increasing the reliability of the internal signaling network. Introduction The evolution of IMS and mobilebroadband network architectures is closely linked with Diameter. The protocol was first introduced for communication over the interfaces between the IMS core and application servers, charging systems and HSS databases. In the EPC, the protocol is used for policy control in addition to accessing user and charging information. The Diametersignaling architecture for IMS and EPC is illustrated in Figure 1. For mobile-broadband networks, Diameter performs the same functions as SS7 in roaming interfaces and non-call-related signaling. Indeed the issues related to the increase in Diameter signaling have been likened to the problems that arose when SS7 was introduced in the first mobile networks. Diameter is one of the main pillars in the transformation of network signaling to native IP-based protocols, complementing SIP which is used for call-control signaling in IMS. Diameter The specification of this protocol began in 1998. The objective was to create a framework for authentication, authorization and accounting (AAA) that would overcome the limitations of the RADIUS protocol in terms of reliability, security and roaming support. The framework is a base protocol 1 that defines the minimum mandatory set of AAA operations. The base protocol defines the message format, which comprises a header and a set of data elements expressed as attributevalue pairs (AVPs). By expressing data as AVPs, applications using the protocol can be extended in the future with- BOX A Terms and abbreviations 3GPP AAA AVP DA DCCA DEA DRA DSC EIR EPC GSMA GUI hpcrf HPLMN HSS IANA 3rd Generation Partnership Project authentication, authorization and accounting attribute-value pair Diameter Agent Diameter Credit Control Application Diameter Edge Agent Diameter Routing Agent Diameter Signaling Controller Equipment Identity Register Evolved Packet Core GSM Association graphical user interface home PCRF Home Public Land Mobile Network Home Subscriber Server Internet Assigned Numbers Authority IETF IMS IMSI IP IP-CAN IPsec IPX LDAP LTE MAP MME O&M OTT PCC PCRF Internet Engineering Task Force IP Multimedia System International Mobile Subscriber Identity Internet Protocol IP connectivity access network IP Security IP Packet Exchange Lightweight Directory Access Protocol Long-Term Evolution Mobile Application Part Mobility Management Entity operations and maintenance over-the-top policy and charging control policy and charging rules function P-CSCF proxy call session control function PGW packet data network gateway PRD Permanent Reference Document RADIUS Remote Authentication Dial-In User Services SCTP Stream Control Transmission Protocol SGSN Serving GPRS Support Node SIP Session Initiation Protocol SLF Server Locating Function SS7 signaling system 7 TCP Transmission Control Protocol TLS Transport Layer Security TPS transactions per second VoLTE voice over LTE vpcrf visited PCRF VPLMN Visited Public Land Mobile Network

5 out having to modify existing source code or data inputs; new information is simply added as a new AVP. The base protocol defines a set of commands and AVPs that can deliver the minimum set of signaling functions, such as peer discovery, capability exchange, proxying, loop detection and error handling. The base set of operations can be extended by Diameter applications through the addition of new commands and AVPs. As illustrated in Figure 2, Diameter supports both SCTP and TCP transport protocols, and transport security is provided by the TLS or IPsec protocol. Diameter is a peer-to-peer protocol that uses a request-answer transaction format. A Diameter peer can be a client, a server or an agent a Diameter Agent (DA). Agents are positioned between clients and servers, and forward client requests to the appropriate server. There are four kinds of agents: relay, proxy, redirect and translation. A relay agent uses the header information and routing-related AVPs of a message to choose the destination peer. A proxy agent can modify AVPs in the message, it forwards messages, and may use the AVPs to determine the destination or apply a policy for example, to reject a request. Redirect agents return requests to the originating client, providing information on the appropriate next hop that can service the request. Translation agents translate messages from one protocol into another. This type of agent was originally defined to translate messages from AAA protocols, such as RADIUS, to Diameter. However, translation from LDAP and MAP to Diameter is also of interest. The Diameter framework can be developed by extending existing applications or by creating new ones. An existing Diameter application can be extended through the addition of optional AVPs. To implement additional functionality new Diameter applications need to be defined which may imply new command codes and new sets of mandatory AVPs. The 3GPP Ro protocol is an example of how an existing Diameter application the IETFspecified Diameter Credit Control Application (DCCA) has been extended with additional AVPs to support the exchange of charging information. However most of the interfaces in 3GPP FIGURE 1 Diameter-signaling architecture for IMS and EPC Charging IMS LCS OFCS Rf OCS Gy Rf Gy Ro Ro Rf Sy AS CSCF Rx PCRF Gx PGW S9 Gx Cx GGSN Sh S6d SGSN HSS (IMS) (S6a, Cx, Rx, Sh and so on) have their own specific Diameter application. Each application requires a specific ID, which is assigned by IANA; the S6a interface, for example, has the application ID 16777251. Figure 3 shows a typical Diameter message, comprising a Diameter header and a series of AVPs. The example shown is an Update-Location-Request message BOX B Diameter interfaces SLh HSS (EPC) EIR S13 S13 S6a MME Cx, Sh subscription and authentication data IMS Gx QoS/policy EPC Gy online charging EPC Rf postpaid charging EPC/IMS Ro online charging EPC/IMS Rx QoS/policy EPC GMLC S6d S6a SLg EPC Roaming partner sent over the S6a interface from the MME to the HSS. Main use cases The purpose of a DSC is to facilitate the ever-increasing use of Diameter signaling in mobile networks, and Figure 4 shows a reference architecture for the use cases described here. This key network component supports the S6a,S6d subscription and authentication data EPC S9 QoS/policy EPC S13, S13 EIR query EPC SLh, SLg location-based services EPC Sy online charging EPC

Signaling in IP networks 6 FIGURE 2 Structure of the Diameter stack 3GPP-specific Diameter applications EAP RFC 4072 SIP RFC 4740 MIP RFC 4004 Diameter base protocol DB-P (RFC 3588) TLS (optional) NASREQ RFC 4005 DCCA RFC 4006 scaling of Diameter-signaling networks, which will be significantly beneficial when the growth of mobile data and VoLTE traffic requires the deployment of multiple HSS, MME, PCRF, P-CSCF and PGW network elements. It is expected that the growth in signaling traffic (accumulated transactions per second) will reflect the growth in mobile-data traffic a tenfold increase between 2011 and 2016 2. In the near term, this growth will be driven primarily by LTE rollouts. From 2014, growth will be accentuated by the introduction of VoLTE. The amount of signaling traffic will be further increased as the installed base of GSM/WCDMA packetswitching networks starts to transition from SS7 to Diameter. FIGURE 3 Diameter header AVPs Version Flags (RPET) Flags (V, M, P) SCTP (or TCP) IP/IPsec (optional) Diameter message structure and an example message Message length Command code (>255) Application ID Hop-by-hop ID End-to-end ID AVP-attribute value pairs AVP AVP AVP code AVP length Vendor ID Data AVP Example: 316 Update-Location-Request (ULR) Example: 16777251 S6 between MME/SGSN and HSS To correlate the ULR with the reply Update-Location-Answer (ULA) on a Diameter hop To correlate the ULR and ULA end-to-end between MME and HSS Example: 1407 VPLMN ID 10415 3GPP-specified AVP Mobile Country Code (MCC) Mobile Network Code (MNC) Centralized routing As illustrated in Figure 5, positioning a DSC centrally in the core network dramatically reduces the number of connections required. As the number of peer relations to configure in a full mesh is directly proportional to the square of the number of interconnected devices, centralized positioning of a DSC can reduce configuration time considerably, and the time and effort required to add and configure another Diameter signaling peer such as an MME can be controlled. With a well-designed centralized DSC, signaling flow can be monitored, network faults can be isolated, and signaling traffic can be rerouted for maintenance purposes making network expansion a much simpler process. When the DSC routes a request, two or more peers can usually serve it. The DSC uses a load-balancing algorithm to distribute load over the available servers. The complexity of this algorithm can vary, ranging from a simple round robin to a more evolved solution that takes current server loads into consideration, for example. Overload protection A DSC can enhance the robustness of the network by supporting intelligent context-aware throttling of signaling load for servers suffering from unbalanced load, and for clients that misbehave. Overload and signal flooding can be caused, for example, by:

7 the mass registration of mobile phones and inter-node signaling directly following network recovery; the handover of huge numbers of sessions following a radio-network failure; or reregistration of smartphone applications following the failure of an OTT server. The DSC can protect itself and other connected server peers from overload by throttling messages. However, any message discarded by the DSC implies a lost processing effort (blind load) in the originating network elements and increases the time until the network settles to a normal state again. Therefore, it is important to perform load regulation as close as possible to the source of the overload. LTE roaming support In the EPC, there are direct Diameter interfaces that connect the network elements of the visited network MME, SGSN and vpcrf to the equivalent elements of the home network: HSS and hpcrf. To simplify the roaming interface, an additional functional entity the Diameter Edge Agent (DEA) has been defined in the LTE Roaming Guidelines (GSMA PRD IR.88). The DEA provides an entry point that hides the topology of the network behind it and advertises itself to roaming partners as a Diameter relay serving all Diameter applications in the network. As such, the DSC should be considered as a signaling firewall that protects the internal network from malformed messages and unauthorized senders. This firewall functionality is implemented by filtering messages through a set of custom izable Diameter message screening rules and message normalization can be done by rebuilding all messages using a specified layout. Session binding 3GPP has defined a new functional element for policy and charging control (PCC) architecture. This element the Diameter Routing Agent (DRA) ensures that all Diameter sessions established over the Gx, Rx and S9 reference points for a specific IP-CAN session use the same PCRF instance when multiple PCRFs have been deployed. For example, sessions created over Gx for LTE users may be routed to a specific FIGURE 4 HSS (EPC) EPC Reference architecture for use cases DEA S6a, S6d S9 S6a, S6d S6a, S6d HSS (EPC) DA S6a, S6d VPLMN IPX HPLMN EIR DA S6a, S6d S6a, S6d, SWx PCRF based on the subscriber identifier IMSI. When another session is created over Rx for a VoLTE voice call, for example this session is identified by the assigned IP address. To ensure that session requests are routed to the correct PCRF, the DRA must maintain the relationship between the subscriber identifier, the assigned IP address and the chosen PCRF instance for the DSC DA S9 DEA (roaming) S9 S13 HSS (IMS) SLF/DA IMS Cx, Sh, Zh Rx Rx DRA EPC Gx Ro, Rf Gx, Rx, S9 Gy Charging Gy DA Sy PCRF whole duration of the IP-CAN session. Like the DEA, the DRA is a functional element of the DSC. Consequently, maintaining all these relationships is a challenge because DSCs are typically deployed as redundant pairs. The stored state for all IP-CAN sessions must be shared between the redundant DSC pair so that a DSC outage does not result in major loss of IP-CAN sessions. FIGURE 5 Centralized versus distributed Diameter-signaling network architecture

Signaling in IP networks 8 FIGURE 6 Roaming and interconnect domain Roaming partners DSC DSC DSC DEA Address resolution of nodes When user data is distributed over multiple instances, the DSC must be able to locate the correct instances for a particular user. 3GPP specifies this in the reference points from EPC and IMS to the HSS that stores the user data. For Diameter applications using reference points Cx, Dx, S6a, S6d, Sh and Dh, the DSC uses FIGURE 7 DSC including logical DA, DEA and DRA elements HSS (EPC) HSS (EPC) HSS (EPC) MME MME MME Core network domain HSS (IMS) Sample DSC topology HSS (IMS) HSS (IMS) PCRF PCRF PCRF PGW PGW PGW PGW the subscriber identity stored in an AVP in the message to select the appropriate server instances (typically two or more), and it then applies load -balancing. To do this, the DSC must be aware of the Diameter application so that the request can be routed to the appropriate server instance. Fast Diameter router/ load balancer Fast Diameter router/ load balancer Fast Diameter router/ load balancer IT domain IMS IMS IMS LCS OCS OCS OFCS OFCS OFCS Ericsson Blade System Deep message inspection Deep message inspection Deep message inspection Deep message inspection Deep message inspection The Diameter interfaces to other nodes that store user data, such as the PCRF or online charging systems, may also need to utilize this feature in the DSC. For centralized user database deployments or when an SLF is used to identify the location of user data, the DSC only needs to identify the set of front ends or SLFs that route the request further. In this case, the DSC does not need the subscriber identity to route the message. Deployment topologies In small to medium-sized networks (up to 10 million subscribers), the Diameter signaling network can be collapsed into a single mated pair of DSCs. However, it may still be beneficial to divide the signaling network across several interconnected DSCs, each serving a separate and independently administered domain. In the example shown in Figure 6, one DSC pair handles the international Diameter traffic as a DEA, a second DSC pair handles the national core Diameter signaling, and a third DSC pair handles the signaling to charging systems. The DSC pairs act as an interface between domains, and consequently each domain can evolve without impacting any other. Very large networks (serving more than 10 million subscribers) are often subdivided into geographical regions. For such networks, DSC pairs may be deployed for each region, where all DSCs are linked to each other providing the signaling interconnect. The Ericsson approach As a central node in the network, the DSC must be carrier-grade complemented with a robust network design which requires both node- and network-level redundancy. At node level, N+1 redundancy is applied for traffic-carrying blades, and other hardware components are 1+1 protected. Network-level redundancy is achieved via mated DSC pairs, which can be situated at different geographical sites. Figure 7 illustrates the DSC, which from a software-architecture perspective is divided into two: a front-end router that handles most message routing through a peer table and an extended diameter-routing table; and a back-end part handling deep message inspection.

9 The front end can handle frequently occurring proxy functions and is also responsible for the load balancing and throttling functions. This part is optimized for high-capacity message processing with minimum delay. The back-end part is invoked when a message requires screening and when based on highly customized business logic modification of the message content is required. The back end supports a comprehensive GUI for easy customization of message handling an essential function for configuring the interfaces with roaming partners. The front- and back-end parts are administrated by a common operations and maintenance (O&M) concept. However, two different O&M roles are defined to fit with the main use cases: basic diameter signaling control and diameter message manipulation. Each blade in the DSC runs both a front-end and a back-end software process. Consequently, all blades are equal in terms of software configuration, which eases expansion and supports a cost- and time-effective configuration process. The load balancer distributes incoming messages to the front end. And requests that require invocation of back-end processes are distributed so that load is balanced. The DSC can be scaled up from minimum configuration of two trafficserving blades to any size simply by adding or removing blades. The configuration of cooperating nodes is unaffected. In one magazine, the DSC can be expanded with up to 10 traffic blades handling up to 300k TPS, and for very high capacity needs, the DSC can contain several magazines. Because individual DSC blades are not visible to neighboring network nodes, they can be added, taken out of service or removed without any impact on the network. In this way, software and hardware upgrades and maintenance can be performed during normal operation without creating disturbances. Conclusion The emergence of the Diameter protocol as a fundamental part of network signaling in the EPC and IMS has created the need for a signalingcontroller network element that facilitates configuration and increases the robustness of the network. This network element, the DSC, is mission-critical and requires telecomgrade software and hardware. A high degree of flexibility will also be necessary to manage the evolution of Diameter signaling. Jörg Ewert joined Ericsson in 1999 as a system manager for mobile softswitch O&M. He later became the leader of the O&M system design team. In 2005, he joined the product management team at Business Unit Networks, where he was responsible for network management and security. He is now responsible for network evolution in product line switching at BU Networks. Ewert studied business administration at the University of Hagen, Germany, and holds an M.Sc. and a Ph.D. in physics from the University of Göttingen, Germany. Lennart Norell joined Ellemtel in 1977 to work on the development of the AXE system. He moved to Ericsson in 1982 and has since held various management and technical expert positions within system and product management in the telecom and datacom product areas. He has been active in the design of IMS, where he previously led the strategic systems management unit. He is currently an expert in IMS and core network architectures at Business Unit Networks, focusing on voice and video over LTE and network signaling. He has an M.Sc. in electrical engineering from Chalmers University of Technology, Sweden. Soner Yamen Acknowledgements Sven Steinacker, Martin Johansson, Volker Kleinfeld and Antonio Alonso References 1. IETF, 2003, RFC 3588, Diameter Base Protocol, Available at: http://www.ietf.org/ rfc/rfc3588.txt 2. Ericsson, 2012, Traffic and market data report, Available at: http://www.ericsson. com/res/docs/2012/traffic_and_market_report_june_2012.pdf joined Ericsson in 1995 as a support engineer. In 1999, after working as a solution and project manager in Turkey, he transferred to system management at Ericsson Eurolab, Germany. In 2000, he joined the product management team, where he is currently responsible for Network Architecture in product line switching at Business Unit Networks. He holds an M.Sc. in electrical engineering from the University of Wisconsin-Madison in the US.

Making money mobile 10 A converged approach to mobile financial services Of the current global population estimated at just over 7 billion people 2.5 billion do not have access to bank services 1, whereas 5 billion have a mobile phone subscription 2. Providing financial services via the mobile phone can bridge this gap, bank the unbanked and the under-banked, and bring all mobile commerce (m-commerce) stakeholders together. MATS RENÉE, FIROOZ BADIEE, ERWIN VAN RIJSSEN AND PATRIK CENTELLINI The unique position MNOs hold in providing communication services and the potential revenue opportunities presented by mobile financial services have put m-commerce high on the agenda of most operators. M-commerce is still in its infancy, and the uptake of related services varies greatly from region to region. In Sub-Saharan Africa, for example, 14.5 percent of people over the age of 15 use their mobile phones to receive money, while the figure for Europe and Central Asia is 2.7 percent 3. The opportunities for operators would be greatly enhanced by the existence of a global ecosystem connecting mobile networks, banks and digital mobile-wallet (m-wallet) platforms, operating across systems, currencies and national borders. BOX A Terms and abbreviations 3PP third-party provider AML anti-money-laundering ATM automated teller machine G2P government-to-person HSM hardware security module KYC know-your-customer MNO mobile network operator MTO money-transfer organization NFC near-field communication NGO non-governmental organization OFAC Office of Foreign Assets Control (US) OSS/BSS operations and business support systems P2P person-to-person In most parts of Africa and other emerging markets, one of the key drivers for the creation of such an ecosystem is the need to bank the unbanked. When it comes to developed markets, the need to make purchasing easier is a key driver for facilitating mass-market uptake. Together, these market drivers are expected to accelerate growth in m-commerce so that the industry will process more than USD 800 billion globally by 2016 (see Figure 1). The innovation is likely to be most readily adopted in emerging markets, where an estimated 1.7 billion people have access to a mobile phone but have no bank account. The m-wallet is a key element in bringing a virtual bank account and all of its related services into a mobile phone securely. In 2011, a total of about USD 350 billion 4 was sent by international money transfer to people in developing countries. The majority of these funds were sent by migrant workers back to their countries PA-DSS Payment Application Data Security Standard PCI DSS Payment Card Industry Data Security Standard PIN Personal Identification Number POS point-of-sale SAT SIM Application Toolkit SIM subscriber identity module SLA Service Level Agreement SME small and medium-sized enterprises SMSC Short Message Service Center TX transaction USSD Unstructured Supplementary Service Data WS web service of origin. Clearly the ability to perform such transactions quickly and securely through a trusted partner is vital to many people and so the window of opportunity for operators to expand their scope in this market is now open. About 140 m-wallet platforms have been deployed globally, with over 100 more being planned 5. Most of the uptake is in Africa, where about 10 percent of operators subscribers are using mobile money services 3. Although the services currently available remain limited and basic (airtime purchase, money transfer and payment of utility bills, for example) consumer interest is growing, and the big question is, who will expand the existing m-wallet services and drive mass-market uptake? Segmentation While the same types of financial services tend to be available in both evolving and developed markets, their accessibility and the extent to which they are used can vary greatly. In emerging markets, the dominant services are basic ones such as domestic and international person-to-person money transfer, merchant payments, bill payments, microloans, insurance payments, and cash-in/ out through agents. In developed markets, the emphasis is on services that simplify payment for small, frequent purchases, such as online ticket payments, downloads of mobile apps, and in-store NFC payments. Figure 1 illustrates the projected market growth by segment for emerging and developed markets combined. Mobile money services The cornerstone of any system

11 delivering mobile money services is a wallet platform. Such a platform, illustrated in Figure 2, enables operators, banks and service providers in a wide variety of markets to provide mobile money services to their users. Along with the traditional services such as SMS, voice and airtime top-up provided to subscribers, with a wallet platform operators will also be able to provide banking services including loans and savings accounts. Stakeholders The m-commerce ecosystem encompasses a large number and wide variety of stakeholders from several industries, each with diverse business goals. These players include agents, operators, banks, MTOs, and different types of service providers, as well as internal actors from the operator side. Agents act as cash-in/out points for the consumer; whereas operators and other service providers deliver the ecosystem s functions, such as settlement, reconciliation, billing and payment; and the internal actors deliver various support functions including compliance, customer service, marketing and product management. Figure 3 shows the main stakeholders and the actions that they typically perform. Network architecture There are a substantial number of integration points between the m-wallet platform and the other actors in the m-commerce ecosystem, which is clearly illustrated in Figure 3. Consider the implementation of just one basic task that users in an m-commerce environment perform regularly: accessing their m-wallet via a mobile device. There are several ways of implementing this function: through a web interface, USSD, a SIM Application Toolkit (SAT), or a mobile app. Typically, an m-wallet platform will integrate with OSS/BSS as well as with partner banks for settlement of funds, and with money-transfer organizations (MTOs) for domestic and international fund transfers. Cash-in/out One of the fundamental functions of any bank or financial service is to give people the ability to deposit and withdraw cash. Users need to be able to put BOX B Drivers in emerging markets: mobile money transfer, bill payments and prepaid top-ups Drivers in developed markets: online payments, download of mobile apps and instore NFC. FIGURE 1 Growth by market segment Global m-commerce market forecast Transaction volume = processed money USD billion 100% = 147 782 P2P transfers M-payments M-banking Domestic International In-store Remote digital Remote physical Prepaid top-up Other* Micro-loans Insurance cash into their m-wallets and get money out of them. One way of implementing cash-in/out is through an agent. An agent could be an existing partner or a retailer selling airtime or mobile subscriptions this kind of actor handles significant amounts of cash and therefore has the necessary procedures in place to handle cash-in/out transactions. When a consumer performs a cash-in transaction through an agent, the cash is handed over to the agent, who then uses their mobile phone to transfer the amount from their wallet to the consumer s. To perform a cash-out transaction, on authorization by the consumer, the agent s mobile device can transfer the amount from the consumer s wallet to the agent s, and the agent can then hand over the cash directly. Naturally, for an m-commerce ecosystem to be successful, there is a need for thousands of agents in close proximity to consumers, providing convenient access. Such a setup will lead to a huge amount of administrative overhead to authorize and monitor many small actors. So, aggregators and super agents acting as intermediaries are an essential layer in the ecosystem hierarchy. Another way of facilitating cash-in/ out is to link the consumer s wallet to a bank account which supports transfers between the wallet and the account. 48 12 3 40 19 10 8 7 2012 130 120 110 172 160 20 38 32 2016 * Ticketing, vending, coupons, bill payment, payroll, G2P/NGO payments, SME payments By integrating wallets with networks of automated teller machines (ATMs), the cost of supporting physical agents for cash-in/out operations can be overcome and people can access their wallets through the nearest cash dispenser. As well as enabling cash-in/out, ATMs can enable subscribers to carry out other activities such as balance inquiries, money transfers, foreign-currency withdrawals and phone-credit purchases. To access their m-wallet from an ATM, a subscriber first needs to have their mobile device authorized by their operator. When they withdraw cash from an ATM, for example, they enter a one-time PIN code sent at the time of transaction to their registered device. The bank network or middleware, which connects the ATM to the operator s wallet platform, carries out the appropriate authorization-request-and-verify function in real time. If authorization is granted, the operation is completed atomically and the subscriber s wallet balance is updated accordingly. Access The primary access technologies used to enable consumers, agents and merchants to carry out mobile money transactions are still USSD and SAT text, menu-based approaches. These approaches are limited. The rise in

Making money mobile 12 FIGURE 2 M-wallet platform and stakeholders Consumer Agents Activate Transfer TX history Airtime purchase Payment Merchants Bill providers and bill aggregators Register consumer TX history Cash-in Cash-out Voucher redemption TX history Payment Upload bills Settlement TX history Financial controller the uptake of smartphones is likely to shift this front-end interface to a mobile app that can provide a richer user experience. In-store payments Users can buy physical goods in stores through direct wallet-to-wallet transfer using a prepaid or direct-debit card. If both the merchant and the consumer have signed up for an m-wallet service, payment can be made directly by means of a wallet-to-wallet transfer that may be initiated by either party. A second way of using the wallet platform for in-store payment is through a prepaid or direct-debit card that is connected to the user s wallet. The user can make payments in a store by swiping their card through the merchant s point-of-sale (POS) device. The transaction is authorized over a payment network by validating the balance of the wallet linked to the card. For transactions using credit cards issued by major companies such as American Express, VISA or MasterCard, authorization will take place over the payment network of 3rd party financial service provider Wallet platform Settlement and reconciliation Reversal transaction Adjustment Saving accounts Insurance policy Micro loan Compliance officer Organizations and enterprises Salary payment Donations Fee management Commission management Loyalty management Product packaging System configuration Profile management Notification configuration the card issuer. For merchant prepaid cards and other approved prepaid cards, authorization will be granted using the payment network of the operator delivering the platform. NFC a relatively new technology removes the need for a physical card in making payments. The user simply holds their mobile device near the NFCenabled POS to initiate payment, and this way their payment credentials (a virtual card pre-stored in the phone) are transferred over the air. The first commercial deployments of this promising technology have already been completed. Enabling NFC payments on feature phones is implemented through attaching an NFC sticker to the phone and associating the sticker with the mobile subscription identity of the phone. When the wallet platform receives a payment request for a given sticker, a USSD query is sent to the subscriber, asking for approval implemented in the form of a user-entered PIN. In this way, a stolen sticker cannot be used to make a payment. Marketing manager Admin Registration and approval Account management Hierarchy management Compliancy reports AML Customer care agents Security A mobile money platform needs to meet very high security standards to safeguard the financial information stored in it and transferred across it. It needs to provide functionality that ensures the service provider complies with the appropriate regulatory and compliance requirements. Crucial for the trustworthiness of a given platform is the ability to assure the security of the non-repudiation function which assures the identity of a person performing an action. The security-related standards that are usually followed when designing financial systems such as wallet platforms are PCI DSS, PA-DSS and ISO/IEC 27000. Controlling access is a critical part of achieving the overall required level of security. At a given level, access control can be implemented through the definition of role-based permissible operations for the different actors in the ecosystem: consumers, agents, customer service representatives, merchants and internal staff. To support the operator s organizational structure, a wallet platform should provide flexible methods and tools to define roles and associated permissions. Other levels of access can be controlled through the definition of threshold values; for example, the number of unsuccessful logons permitted before an account is blocked, or the maximum amount of money that can be sent or received over a given network. Verification procedures Financial services are key targets for fraud. To prevent money laundering and terrorist activity, national regulations such as know-your-customer (KYC) and anti-money-laundering (AML) laws stipulate the type of verification procedures that need to be performed by a provider of financial services. Typically, checks are performed during customer registration, during transaction processing and at regular intervals. During customer registration, KYC checks are performed to verify the identity of a potential subscriber before access to a service is granted. For the most part, the type of identity verification required is dictated by local regulations, account balance and transaction limits. For example, EU e-money regulations (such as Directive 2000/46/EC)

13 stipulate that no identity verification is required for an m-wallet balance or transaction request for amounts below a few hundred euros although individual national authorities can set lower limits. Above these limits, a subscriber must provide an official identity document before access to the service can be granted. During transaction processing, service providers are required to impose transaction limits and apply screening checks to subscribers carrying out financial operations. A wallet platform is usually equipped to perform this kind of check based on sanction lists, such as those created by OFAC in the US. At regular intervals, historical transaction-pattern data should be analyzed to identify suspicious behavior. Any such findings should then be reported to the relevant authorities. FIGURE 3 M-commerce ecosystem User web USSD SAT GW SMSC Charging system Customer service Front-end I/F OSS CRM Data warehouse Wallet platform HSM TX engine Log server Bill aggregator Bill provider Bill provider Bill provider 3PP service Settlement A wallet platform performs many thousands of transactions every day. These transactions include cash-in/out, money transfers, purchases and returns. While the result of a transaction is reflected immediately in the balance of a wallet, the actual movement of funds (from the operator s trust account at the partner bank where the funds are actually stored to the beneficiary s bank account) is handled as a batch activity, typically performed once or several times during a single business day. To enable the settlement of funds, a wallet platform must maintain a log of all transactions performed during each settlement period. Bill payment One of the most widely used financial services is bill payment. Figure 4 illustrates how a wallet platform could support this process. Converged solution No matter the industry, an effective solution for delivering new services will build on the strengths of current infrastructure and expand the capability of existing tools. Today, most operators provide airtime, messaging and data services as part of their fundamental offering. Products are priced according to a charging system with many subscriber-related parameters, bonuses, special offers and standard Agent web Merchant web WS DBMS Storage Partner bank MTOs External AML charging rates taken into consideration. Leveraging this asset, by reusing the rating engine and tools to cost and configure financial services, will help operators to deliver these in combination with traditional telecom services using the same subscriber database. This converged approach will reduce time to market for new services as well as operational costs. However, providing financial services through the existing telecom infrastructure will require the implementation of some additional functionality: atomic processes to ensure that an operation is completely successful and all accounts involved are charged and updated accordingly; transaction authorization to provide support for explicit user approvals, often granted through the use of PINs; access control to ensure that users can perform only the actions for which they have the associated rights and privileges; sanction screening to perform KYC 3PP service 3PP service 3PP service 3PP service inspections, which in the US and many parts of Europe includes checking identities against published sanctioned lists. AML compliance to adhere to national limits, such as maximum account balance, maximum number of transactions permitted within a given period of time, and maximum amount allowed per transaction; data integrity to ensure the accuracy and consistency of data cannot be compromised; data encryption to protect sensitive information from being accessed by unauthorized users; transport security to protect information flow between the wallet platform and external systems, such as web browsers, third-party service providers, banks and remittance hubs; agent management to support the agent, super agent and aggregator hierarchy; and bank integration to hold custody accounts and provide settlement and reconciliation functions.

Making money mobile 14 FIGURE 4 1. Contract Consumer DB Bill-payment process 2. Provide list of bill companies 5. Validate consumer KYC 7. Upload bills 8. Register bills 9. Provide list of bill companies Bill provider Bill aggregator Ericsson Wallet Platform User Prerequisites: The user is registered, activated and authorized to perform this transaction. The merchant is registered and activated in the system. There are many use cases where traditional telecom and financial services are combined, such as the reuse of the family and friends definition, notifications and sloped charging. Attaining critical mass Payment and mobile-communication systems have one thing in common: they are both network industries. In FIGURE 5 M-commerce interconnect Sending Post network Bank and card network MNO network A neutral network for the last mile in mobile money transfer M-commerce interconnect Real-time payment routing Foreign exchange Clearing and settlement Regulatory compliance 3. Validate and store list Interface 6. Associate consumer with bill provider 10. Save pushed bills 11. Notify user of bill arrival 13. Provide list of associated stored bills 15. Debit user account and credit bill aggregator s account 16. Generate and return payment details other words, the business model for these services is based on senders and receivers. A phone call requires a sender, a receiver and a transfer mechanism the same applies to money transfers. As more people use a network, more services can be developed, and so the network provides greater value to its subscribers. Understandably, one of the recurring questions surrounding new payment Receiving MNO in country A MNO in country B MNO in country C 4. Select Register for bill payment in Client menu Message 12. Select View bill payment in Client menu 14. Select Pay selected bill in Client menu End services is how to reach the critical number of users needed to attract the mass market and protect investment. Enabling interoperability between networks so that users in one network can reach users in another is one of the common ways of attaining critical mass. For payment systems, the interconnect role (Figure 5) is often held by an intermediary, brokering between the different networks. For example, the intermediary in domestic bank transfers and ATM transactions is the automated clearinghouse such as VocaLink in the UK and SIA in Italy. VISA, American Express and MasterCard play a similar role in global card payments. As well as providing technical interoperability, the value provided by the broker lies in their ability to create economies of scale as a payment processor, where the cost per transaction decreases as the number of users increases. Unfortunately, most m-wallet structures lack interoperability, which makes it difficult for operators to reach the mass market. According to GSMA, 140 live mobile money platform deployments currently exist worldwide 5. Most are closed networks, and only a few have more than 1 million users. In many ways, this situation resembles the beginnings of mobile communication networks, which had no interoperability and consequently could only provide users with limited services and value. One possible way to provide interoperability is to create a clearinghouse that acts as a bridge between m-wallet networks and traditional bank and card networks. The case of international remittances (migrant workers transferring money back to their home countries) highlights how users needs can be supported by such a clearinghouse model, where the goal is to make money transfers as simple as sending an SMS. Top of the agenda for the global payment industry and policymakers is international remittance. The reason is simple: in 2011, a worldwide total of approximately USD 350 billion was transferred to developing economies 2, mostly by migrant workers living outside their home countries. Millions of people depend on this influx of cash to meet their daily living expenses and support their investments. According

15 to the World Bank, international remittance is the largest source of external financing in some developing countries, accounting for as much as a third of GDP in some cases including Lesotho and Tajikistan 3. Many people who receive remittances are often unbanked and live in rural areas at a significant distance from the nearest bank. And so accessibility and reach are key success factors for remittance services. Payment infrastructures in mature economies rely heavily on bank-to-bank transfers, whereas many emerging economies lack the financial infrastructures needed to reach people in this way. The first wave of international-remittance providers solved this problem by building on existing retailer networks and post offices, creating a proprietary distribution network and retaining control over both the sender and the recipient channels. This is the model used by Western Union. The primary disadvantage of this model is the cost. It is a cashdriven approach that requires many physical outlets and does not build on the reach advantages of the mobile phone. Another negative aspect of this model is that it doesn t support consumers in mature economies wanting to transfer funds electronically, directly from their bank accounts. The difficulty faced by banks entering the mobile market is that bank-tobank networks alone are insufficient for creating the required reach. Banks still need to build bilateral relationships with partners, such as mobile operators and postal institutions, to reach potential customers. To overcome the challenges presented by the existence of different payment networks, and at the same time take full advantage of mobile ubiquity, the solution should transmit payment messages and provide a global framework for clearing and settlement for the various actors in the ecosystem. The clearinghouse model for mobile money transfer has the potential to bring operators, postal institutions and banks together to offer a superior service that allows each party to build on its core strengths. To create a global, neutral and payment-agnostic network, the key components are: global cooperation among mobile-network operators, postal institutions and banks active in mobile money transfer; a centralized platform for payment routing, processing, clearing and settlement to achieve economies of scale and interoperability among networks; real-time payment routing, clearing and settlement between different payment networks; and a legal framework securing uniform SLAs, compliance and security policies. Conclusion There are many stakeholders with different business models and diverging goals that are part of the m-commerce system banks, operators, agents, aggregators, subscribers and moneytransfer organizations. The aim is to build a sustainable ecosystem, where each party can provide key elements of the wallet platform, making it accessible and widespread. The ecosystem will give the underbanked and unbanked access to a global payment network, where agents and users can work across national borders and currencies, maintain a very high level of security and comply with AML laws. By combining telecom and financial services into a converged wallet, MNOs can make the most of this opportunity to provide mobile financial services to the under-served. The clearinghouse model can bring these stakeholders together and take advantage of the open window of opportunity to provide subscribers with financial services through the expansion of the telecom infrastructure. References 1. The World Bank, April 2012, Three quarters of the world s poor are Unbanked, available at: http://go.worldbank. org/72makhbam0 2. Ericsson, June 2012, Traffic and Market Report, available at: http://www.ericsson.com/res/docs/2012/traffic_ and_market_report_june_2012.pdf 3. The World Bank, 2012, The Little Data Book on Financial Inclusion, available at: http://data.worldbank.org/sites/ default/files/the-little-data-book-on-financial-inclusion-2012.pdf 4. Dilip Ratha and Ani Silwal, 2012, The World Bank, Migration and Remittances Unit, Migration and Development Brief 18, available at: http://siteresources.worldbank.org/ INTPROSPECTS/Resources/334934-1110315015165/ MigrationandDevelopmentBrief18.pdf 5. http://www.gsma.com/mobilefordevelopment/ programmes/mobile-money-for-the-unbanked Mats Renée is marketing manager for M-Commerce within Business Unit Support Systems. He has broad experience of communications and marketing from industry and Ericsson. He has worked with the full marketing mix, including corporate branding and on- and offline marketing. He holds a degree in marketing from IHR University of Stockholm. Firooz Badiee is a strategic product manager working with m-commerce solutions at Ericsson. Since joining the company in 1994, he has worked in a variety of capacities, including as a base-station software developer and as a system architect on the m-commerce platform. He holds a B.Sc. in computer science and engineering from Shiraz University, Iran, and has also studied computer science at Uppsala University, Sweden. Erwin van Rijssen is head of product management within OSS/ BSS and M-Commerce. He joined Ericsson in 1996, and has since worked in different positions spanning software engineering, standardization and product management. He holds an M.Sc. in computer science from the University of Twente in the Netherlands and an MBA from Rotterdam School of Management. Patrik Centellini is a strategic manager in m-commerce. He has worked for almost 15 years in the area of payment innovations catering to banks, mobile operators and payment service providers. Prior to joining Ericsson in 2011, he worked with the Swedish clearinghouse and payment service provider Bankgirot. He holds an M.Sc. in business adminstration from Uppsala University, Sweden and an Executive MBA from Stockholm School of Economics, Sweden.

Separate, simplify and distribute 16 Applying big-data technologies to network architecture The ability to create data is no longer limited by where people are, or what they are doing. Now anyone with a connected device can create data, store it and share it within a few moments. To monetize big data a new approach to network architecture is needed. MONA MATTI AND TOR KVERNVIK When does data get big? People, devices and things are constantly generating massive volumes of data. At work people create data, as do children at home, students at school, people and things on the move, as well as objects that are stationary. Devices and sensors attached to millions of things take measurements from their surroundings, providing up-to-date readings over the entire globe data to be stored for later use by countless different applications. An IDC study 1 found that, by 2020, the world will generate 50 times the amount of data it did in 2011 and 75 times the number of information containers will be needed to store that data. Much of this information will be carried over mobile-broadband networks, and Ericsson forecasts that by 2017, smartphone data traffic will increase to 1.1GB a month from its current 350MB BOX A Terms and abbreviations ACID API AXE BASE CAP CDR HDFS HLR HSS IDC atomicity, consistency, isolation, durability application programming interface Automatic Cross-Connection Equipment Basically Available, Soft State and Eventually Consistent consistency, availability and partition tolerance Call Detail Record Hadoop Distributed File System home location register Home Subscriber Server International Data Corporation a month which amounts to an annual increase of 30 percent 2. When a new phenomenon comes about, it often takes the related industries a while to agree on a common definition, and big data is no exception. However, the consensus seems to be that data gets big when it starts to stretch the limits of traditional technology 3. Network congestion, reduced application performance and a negative impact on user experience are the consequences of increased data volumes. To mitigate these effects, scalable and costefficient data-management technologies are needed. Technologies such as not only SQL (NoSQL), characterized by its nonadherence to the RDBMS model, and MapReduce, a programming model tailored for processing large-scale distributed data sets, are both used in a wide variety of industry applications including telecom. These technologies have the flexibility to handle big data and support central management of JSON JavaScript Object Notation LDAP lightweight data access protocol M2M machine-to-machine MBB mobile broadband NoSQL not only SQL OLAP online analytical processing OSS/BSS Operations and Business Support Systems RAN radio-access network RDBMS relational database management system RFID Radio Frequency Identification SNA social-network analysis SQL Structured Query Language network resources to reduce opex and enable greater productivity. The highest level of business continuity can be achieved through solutions that support better scalability, performance and availability regardless of the underlying hardware and the rapid growth of data sets. The pace of change will continue to speed up Facilitating the Networked Society 4 presents the telecom industry, as well as many others, with the opportunity to surpass their current levels of innovation, to develop new technologies, and to test new and sustainable business solutions. Today, there are slightly more than 6.2 billion mobile subscriptions worldwide a figure that is set to rise to 9 billion in 2017 2. With so many people using mobile networks, and owing to the increase in smartphone penetration and constant connectivity, the volume of data traffic in these networks is expected to rise 15 times in the same time frame 2. The nature of this data is also set to change the size of single data sets, the variety of data types and the demand for real-time access to data are all on the rise. These factors lead to varying types of data being collected by the network and transmitted through it. Data sets are irregular and may be unstructured, they can contain ambiguities, they are time- and location-dependent, and are constantly being updated by capture equipment such as mobile devices, sensors and RFID readers. In its simplest form, big-data technology encompasses the tools, processes and procedures to consolidate, verify, analyze, manage and visualize

17 very large data sets with mainly nonrelational but also relational repositories. The emergent approach, illustrated in Figure 1, is a cost-effective one that can handle the volume, velocity and variability of big data. Complementing the telecom industry with big-data technologies could generate value and add innovation opportunities for operators and users across all industries, in public services and in private life. Big-data technologies are a new generation of methods and architectures designed to extract value from masses of different data types through high-velocity capture, discovery and analysis. To analyze the large volumes of bytes associated with big data in a cost-efficient manner, a shift in the common approach to computer architecture is needed. By moving from costly hardware to commodity computing, operators will be able to meet the cost requirements for massive amounts of data storage and heavy serverprocessing power. Figure 2 illustrates how value is derived from the correlation between analytics, cloud-based distributed deployment, and data generated by the many devices that are part of the Networked Society. Change agents Some of the core big-data storage and processing technologies are based on NoSQL. As data models become more diverse, complex and dynamic, they do not always work well in legacy relational database models. NoSQL is optimized for applications that can handle rapidly rising data volumes efficiently without creating bottlenecks that require rearchitecting at critical moments. NoSQL also supports non-relational databases such as key-value, document, column and graph databases all of which make it appropriate for use in the bigdata sphere. Some NoSQL functionalities enable developers to consider new patterns such as partial relational data models when designing a service. Relational databases with predefined schemas are typically chosen by many application developers. The most common use-case for web applications today is based on larger data volumes with BOX B The three Vs of big data Volume big data comes in one size: XXL. Enterprises and operators are saturated with data; they amass huge amounts of it daily, and available storage cannot handle these volumes. Velocity data needs to be used quickly to maximize business benefit before the value of the information is lost. Variability data can be structured, unstructured, semi-structured or a mix of all three. It comes in many forms including text, audio, video, click streams and log files. Some of it is new and some is old. FIGURE 1 Big-data dimensions Variability Volume Big data more flexible and diverse data models so, to support the Networked Society traditional technologies need to be complemented with big-data technologies. Such applications need to meet several key requirements: they have to be able to handle heterogeneous data, they need to have high performance levels, and they must be scalable, reliable, metadata-aware and extensible, with low impact on latency. The Semantic Web and social-network analysis (SNA) FIGURE 2 Networked Society Analytics Big data Velocity Efficient extraction of value from data Data Information Knowledge Wisdom are typical examples of today s web applications and would be more efficiently stored and executed in a graph database environment than in a relational one. Cities and big data The knowledge derived through analysis of data from smartphones and other devices connected to telecom networks is a valuable asset for telecom operators 5. The massive amounts of data Cloud computing

Separate, simplify and distribute 18 analyzed by OSS/BSS tools can help operators leverage the value of this knowledge. By further extending these tools to the communication embedded in management systems, requirements for user experience, business innovation and efficiency can be met. The Ericsson Research megacities program focuses on cities with a population of more than 10 million and with a ranking of more than 50 out of a possible 100 on the company s Networked Society City Index 6, which measures the effects of ICT on society, people and business. The huge amounts of data generated by the Networked Society, in which real-time communication is more critical than it was in the past, can be used to a significant advantage in many areas of urban planning, such as efficient use of transportation, smart electricity distribution and water supply. Efficient planning and control of transport and utilities requires analytics support, which will, for example, forecast demand levels and consequently enable utility providers to deliver in a smart way meeting demand with minimal waste. Figures for supply and demand can be constantly refined with real-time consumption rates, creating an ecosystem with reduced waste. Types of data The value that can be derived from using big-data technologies depends on the use case and the data associated with it. Apart from volume and velocity, the value that can be gained from the variability of data tends to be overlooked. Put simply, the less structured the data, the greater the requirement to apply big-data technologies. Variability is typically categorized into three different data types: structured data is well organized, there are several choices for abstract data types, and references such as relations, links and pointers are identifiable; unstructured data may be incomplete and/or heterogeneous, and often originates from multiple sources. It is not organized in an identifiable way, and typically includes bitmap images or objects, text and other data types that are not part of a database; and semi-structured some data is organized, containing tags or other markers to separate semantic elements, but unstructured data may also be present. Inside the technology Big-data technologies are usually engineered from the bottom up with two things in mind: scale and availability. Consequently, most solutions are distributed in nature and introduce new programming models for working with large volumes of data. Because most of the legacy database models cannot be effectively used for big data, the current approach to ensuring availability and partitioning needs to be revised. NoSQL Like key-value storage of semi-structured data, NoSQL systems are designed with specific characteristics in mind, such as relaxed models of consistency. They run applications that tend to be read/write-intensive. To take advantage of scaling capacity as new nodes are added to a network, many NoSQL databases are designed to expand horizontally and run on low-cost commodity hardware. NoSQL databases have far more relaxed or even nonexistent datamodel restrictions. Such databases allow applications to store almost any kind of structure in a data element, and the responsibility for maintaining the logical data structure is transferred to the application. Most NoSQL databases are key- value stores that hold schema-less collections of entities that do not necessarily share the same properties. The data consists of a string containing the key, and the actual data is considered to be the value in the key-value relationship. For example: document stores containing complex data structures that are usually stored in JavaScript Object Notation (JSON); and graph stores, or graph databases an emerging NoSQL category using nodes (stand-alone objects or entities) and edges (lines used to connect nodes and properties) to represent and store information. Another current trend is to combine SQL and NoSQL in a non-conflicting manner that enables the technologies to work well together. BOX C CAP triangle Consistency all nodes see the same data at the same time. Availability every operation results in a response (success or failure). Partition tolerance the system continues to operate when individual components are unavailable, or when messages are lost. FIGURE 3 CAP triangle C Scaling A Trade-off 3 Extra capacity can be obtained by adding more hardware to a specific computer or by moving applications to larger computers a process known as vertical scaling. One limitation of this approach is the risk of outgrowing the capacity of the largest computer; this will eventually affect cost. Vendor lock-in is a potential risk, and vertically scaled solutions can become prohibitively expensive. Adding computers in parallel can also increase capacity. This approach is known as horizontal scaling, and big-data technologies tend to favor it because it supports network expansion. Systems that are built in this way are more flexible, and because commodity computers can be operated together in parallel, the risk associated with singlevendor solutions is reduced. From a developer perspective, vertical scaling is preferable because it is less complex than horizontal scaling, which requires solutions to be implemented to run in parallel creating new challenges in terms of data consistency and availability. Consistency According to the CAP theorem, which is illustrated in Figure 3, horizontal processing leads to a trade-off among three systematic requirements: consistency, availability and partition tolerance (CAP). The theorem states that a distributed environment cannot fully satisfy all three requirements at the same time. Partition tolerance is a must for distributed systems, so designers need to optimize consistency and availability to achieve a trade-off of all three requirements. P

19 Atomicity, consistency, isolation, durability or ACID-compliant database transactions simplify application development, as these platforms guarantee both full consistency support and a given level of availability. Overall availability can be calculated as the product of the availability of each database involved in a transaction. To retain consistency, ACID solutions use a commit procedure involving multiple databases, which leads to a reduced level of availability. Basically Available, Soft State and Eventually Consistent (BASE) 7 technology is an alternative to ACID for scenarios in which availability is the top priority and consistency is deemed less critical than other factors. This approach uses a looser definition of consistency known as eventual consistency in which data consistency is supported but is temporarily reduced under some conditions. Most big-data platforms support BASE, as the level of consistency it provides is acceptable for many applications. As a result, requirements for consistency need more careful analysis during the design of applications that run on top of big-data platforms. Availability Telecom applications have high performance requirements. As telecom networks are often part of safety-critical infrastructures, a telecom-grade database requires five-nines availability, and usually has latency requirements of less than 10ms. With the increased data volumes generated by users and devices in the network and a constant pressure to reduce cost, big-data technologies are gaining a competitive edge as a complementary way of managing data for the appropriate use cases. When the expected massive increase in the number of devices connected to mobile networks is realized, the number of unique profiles needing to be stored in an HLR/HSS will greatly surpass the number of subscribers leading to new and bigger scalability challenges. To address these requirements, various studies have been performed on how to apply big-data technologies in telecom solutions. For example, a study 8 that reviewed the applicability of NoSQL databases in mobile networks showed that it will be possible to use cloud technologies to meet mobile networks FIGURE 4 A parallel data-processing system 1 2 3 4 5 HDFS 2 4 5 2 3 4 1 3 4 1 2 5 1 3 5 HDFS = Hadoop Distributed File System Hadoop = Open source software for parallel data processing future requirements for latency and number of transactions per second. MapReduce Another significant aspect of big-data technologies is MapReduce programming. By splitting a problem into many smaller ones that can be processed simultaneously on a number of nodes, MapReduce offers an extremely efficient solution when the database application needs to aggregate all occurrences of a word or phrase in a very large document database, for example. MapReduce is suitable for solving problems that can be broken down into smaller independent sub-problems with results that can be aggregated to produce a single answer. Google owns the patent for this programming method, which is based on the map and reduces functions commonly used in parallel programming and illustrated in Figure 4. As such, MapReduce is not a generalpurpose solution for data- processing problems. So, Ericsson Research has assessed two typical telecom problems and how these can be processed using MapReduce: first, social-network analysis (SNA) and second, Call Detail Record (CDR) processing. 2 4 5 Map 2 3 4 1 3 4 1 2 5 1 3 5 Reduce MapReduce = Programming model for parallel processing Result Value from users Identifying influential subscribers is a prioritized activity for many telecom operators, as this information can be used to great advantage in targeted marketing campaigns. Influential subscribers can be found by analyzing CDRs. Several metrics and algorithms can be applied to determine the influence level of each subscriber, the drawback of these methods is that they tend to be computationally expensive. Ericsson Research has developed a prototype based on MapReduce on the Hadoop platform to run SNA algorithms efficiently in parallel as map-and-reduce jobs. The algorithms were tested on a cluster of 11 computers and, for most of the tests, the relationship between reduction in computational time and the number of computers was more or less linear. The challenge is to find a method that efficiently combines the results from the different metrics so that the most influential subscribers can be identified. By applying machine-learning techniques to support a weighted combination of the different metrics, operators can use a known set of subscribers and their corresponding levels of influence as a reference set, and

88 years reporting Ericsson Review has been in print since 1924, today it is time to turn a new leaf. Control apparatus for fixed signal timing 1924 The L.M. Ericsson stand at the Gothenburg Exhibition 1923 1968 Tests of telex exchange in Spain 1946 Delivery tests of terminal equipment for 8-channel carrier frequency system Lars Magnus Ericsson 1924: The first edition of the L.M. Ericsson Review is published. The editor states that one of the aims of the journal is to discuss points of design and construction, which have not yet reached a stage of final standardization. The cover story examines Ericsson s presence at the previous year s Gothenburg Exhibition, where a complete Ericsson exchange for 500 lines had been housed in a giant replica of a standard table-set telephone.

innovation The communications technology ournal s nce 1924 1/2012 Validating voice over LTE end to end 4 WebRTC: the web with real time communication 0 Messaging in an all IP world 16 IP transformation strategy for multiscreen video 22 Transport networks in the cloud age 28 The impact of internet based services on OSS and BSS 34 2012 On the brink of the Networked Society 1980 Testing of hybrid circuits 1946: Ericsson Review marks the 100th anniversary of the birth of Lars Magnus Ericsson with a short biography of his life, from poor beginnings to self-made man. He combined his innate imagination and knack for construction with hard work and study to become a success. 1968: The cover shows test engineers verifying a telex exchange in Spain. The related article explains how the flexibility of the Ericsson telex system, within the framework of CCITT (ITU) recommendations, ensures interworking with any other system both on a national and international basis. 1980: An article is published on teletraffic theory and its practical applications. The article covers traffic research and its main aim to dimension networks. Interestingly, it also mentions data traffic and that fact that as early as the 1960s predictions were being made that it would grow to be as large as telephone traffic. This milestone was finally reached at the end of 2009. 2012: An article is published on the validation of voice over LTE from an end-to-end perspective, with the key objective of retaining users. The authors explain how their lab and field trials led them to the conclusion that VoLTE, under normal network conditions, should out perform OTT services. 2013: Articles on various topics such as smart mobile-broadband, software-defined networks and NLOS wireless backhaul, to name but a few will be available digitally. Look out for them and other developments at the journal s home www.ericsson.com/review.

Separate, simplify and distribute 22 FIGURE 5 CDR processing with MapReduce the model can then be applied to the entire subscriber base. Pre-loaded local input data Intermediate data from mappers Values exchanged by shuffle process Ouputs generated by the reducing process Outputs stored locally Node 1 Node 2 Node 3 Mapping process Mapping process Mapping process Node 1 Node 2 Node 3 Reducing process Reducing process Reducing process Processing of CDRs Processing CDRs is an essential task for many operators; the results of processing are used for many purposes, such as identifying potential churners. A proof-of-concept collaboration between Ericsson Research and Ericsson s BSS portfolio management team, investigated a MapReduce-based batch-processing method for CDRs. MapReduce was used for fault-tolerance distributed processing of CDRs through horizontal scaleout over a heterogeneous cluster. The time required to process the CDRs with MapReduce was much less extensive than the time required to complete this task using traditional processing techniques the proof-ofconcept system (illustrated in Figure 5) processed 293,877 CDRs per second, while the legacy system processed 3,220 CDRs per second. This is a huge gain for large-scale operators who may need to process up to 200 million CDRs a day. Not only is processing time drastically reduced, but many more statistical reports can also be produced. FIGURE 6 Overview of applications and database integration middle layer Neo4j HBase PostgreSQL NFS HDFS... Application tier Integration middle layer Data stores Plug-and-play data integration The use of NoSQL and MapReduce to manage big data offers many advantages, but big data is also about catering to all of an enterprise s data needs and about providing ubiquitous access to the data tools RDBMS, OLAP or graph stores. Ubiquitous access implies that these tools should be accessible by any service at any time with minimal effort. Ericsson Research is developing the concept of a middle layer that would simplify automatic data integration. The aim is to ease the integration of legacy applications and new services to any available data source through just a few simple steps. This layer will be designed to: require minimal service configuration (plug-and-play); expose multiple database technologies (such as RDBMS and key-value); expose a common application/service API; be suitable for legacy services (such as HLR) as well as new services (such as private data vaults);

23 require minimal schemas for storage of data; integrate with a larger component architecture; handle multiple data stores and any table sizes; perform cross data-store extraction (for analytics); and use mainstream technology to control costs. Figure 6 illustrates the interaction between the integration middle layer and the external environment, where applications such as M2M and private data vaults utilize the integration middle layer. The integration middle layer enables the selection of the best data-storage type according to the application s needs. This type can be determined by monitoring the application s data-access pattern (such as create/read/update/ delete). Conclusion The data available to operators through their networks presents them with an opportunity and a business-intelligence edge over other players. As is often the case, with opportunity comes challenge, and for big data this challenge comprises the volume and diversity of the data and the fact that both are expected to grow substantially in the next few years. The value of the information in the data is significant, but the costs involved in obtaining it using current technology are inhibitive. Consequently, big-data technology is an important part of the puzzle for operators wanting to leverage value from the large volumes of data in their possession in a cost-efficient way. Applying big-data technologies has the side effect of transferring some complexity from the database to the application. Within the big-data sphere, Ericsson holds a unique position by being among the few companies that truly understand networks. Ericsson can provide the glue needed to convert vast volumes of raw data into information and knowledge that can be monetized. At Ericsson Research considerable knowledge has been gained through the development of big-data technology proofs-of-concept, expanding our existing competence to build large distributed systems with high availability to include big-data technologies. Mona Matti is a senior researcher at Ericsson Research in the Services and Software research area in Kista, Sweden. She received her M.Sc. in operational research from London University in the UK in 1981. She has been employed at Ericsson since 1997 and has been part of the machinelearning group in the data program. She has previously worked with knowledge discovery and big-data projects, and now focuses on learningadaptive RAN in the Smart MBB project. Tor Kvernvik is a senior researcher at Ericsson Research in the Services and Software research area in Kista, Sweden. He received his M.Sc. in mechanical engineering from KTH Royal Institute of Technology in Stockholm, Sweden in 1987. He has been employed by Ericsson since 1987, and worked with the development of AXE and the mobile core network until he joined Ericsson Research in 2005. His initial research there involved the core network and policy control. In 2008, he started working with machine learning and data management. He currently focuses on data management and big-data technologies. Acknowledgements References 1. John Gantz and David Reinsel, IDC, June 2011, Extracting Value from Chaos, available at: http:// www.emc.com/collateral/analyst-reports/idcextracting-value-from-chaos-ar.pdf 2. Ericsson, June 2012, Traffic and Market Report, available at: http://www.ericsson.com/ res/docs/2012/traffic_and_market_report_ june_2012.pdf 3. IBM, 2012, What is Big Data? available at: http:// www-01.ibm.com/software/data/bigdata/ 4. Ericsson, The Networked Society site: http://www.ericsson.com/networkedsociety 5. Ulf Olsson and Jaco Fourie, Ericsson Review 1, 2011, Data Analytics the truth is in there, available at: http://www.ericsson.com/ news/110809_data_analytics_244188809_c 6. Ericsson, 2011, The Networked Society City Index, available at: http://www.ericsson.com/ networkedsociety/lab/research/city-index/ 7. Dan Pritchett, Association for Computing Machinery (ACM), 2008, BASE an ACID Alternative, available at: http://queue.acm.org/ detail.cfm?id=1394128 8. Rasmus Päivärinta, Aalto University, Finland, Applicability of NoSQL databases to Mobile Networks, available at: http://www.cse.hut.fi/fi/ opinnot/t-110.5121/2011/lisatty-files/nosql.pdf The authors would like to thank Martin Svensson for his efforts and dedicated contribution to this article.

Shifting control 24 Achieving carrier-grade Wi-Fi in the 3GPP world Users switch between cellular and Wi-Fi networks regularly. The process is not always as seamless as it could be, sometimes requiring several painful steps. Hotspot 2.0 is starting to change all that. STEPHEN RAYMENT AND JOAKIM BERGSTRÖM Shortly after the close of the 2012 Mobile World Congress, the GSMA announced a plan to collaborate with the Wireless Broadband Alliance (WBA) to simplify Wi-Fi-hotspot access for smartphones and tablets 1. Intended to provide subscribers with seamless cellular-to-wi-fi roaming, this joint GSMA/WBA initiative is based on the WBA Next Generation Hotspot (NGH) program 2 and the Wi-Fi Alliance Passpoint certification 3 known in the industry as Hotspot 2.0. The need for such an initiative has risen out of the rapid rise in mobile subscriptions and explosive growth in demand for mobile broadband. Numbering 6 billion at the end of 2011, mobile subscriptions are expected to hit the 9 billion mark by the end of 2017 4. Mobile-data usage is expected to grow 15 times between 2011 and 2017 4. To provide this massive number of users with good service, Hotspot 2.0 will build on the roaming principles that have successfully supported global growth in the mobile industry. Now that the first phase of the initiative Hotspot 2.0 Release 1 has been launched, Ericsson and other telecom vendors are setting their sights on the next step network-directed roaming, which will be developed in Hotspot 2.0 Release 2 and in the ANDSF enhancements in 3GPP Rel 12. The Hotspot 2.0 standard uses operatorprovided information stored in a subscriber s SIM to automate the search for available networks and the associated login procedure removing the need for cumbersome manual steps, and improving user experience. However, the decision to switch is still determined by the device. To implement Wi-Fi that is truly carrier-grade, control needs to be handed back to the network operator. The existing 3GPP ANDSF standard provides operators with a mechanism for handling traffic on public data networks. Operators can list their preferred networks and provide policies for how BOX A Terms and abbreviations AAA authentication, authorization and accounting GTP HESSID GPRS Tunneling Protocol Homogenous Extended Service Set ID PLMN PMIP Public Land Mobile Network Proxy Mobile IP AC access controller HLR home location register PMIPv6 Proxy Mobile IPv6 AES Advanced Encryption Standard hpcrf home PCRF RAT radio-access technology ANDSF access network discovery and selection function ANQP Access Network Query Protocol AP access point BNG Broadband Network Gateway BPCF Broadband Policy Control Function BSS Business Support Systems CAPWAP Control and Provisioning of Wireless Access Points CoA Change of Authorization DPI deep packet inspection DSMIPv6 Dual-stack Mobile IPv6 EAP Extensible Authentication Protocol EAP-AKA EAP-Authentication and Key Agreement EAP-TLS EAP-Transport Layer Security EAP-TTLS EAP-Tunneled TLS EPC Evolved Packet Core EPS Evolved Packet System epdg Evolved Packet Data Gateway GBA Generic Bootstrapping Architecture HSS Home Subscriber Server IKEv2 Internet Key Exchange version 2 IP-CAN IP connectivity access network IPsec IP Security I-WLAN interworking wireless LAN ISMP inter-system mobility policies LBO local breakout LI Lawful Interception MCC Mobile Country Code MNC Mobile Network Code MO management object MSCHAP Microsoft Challenge Handshake Authentication Protocol NAI network address identifier NGH Next Generation Hotspot OCS online charging system OFCS offline charging system OMA-DM Open Mobile Alliance Device Management PCRF policy and charging rules function PDN GW packet data network gateway RF SaMOG SSID TWAN UAM UE USIM vpcrf WAN WAG WBA WFA Wi-Fi WISPr WLAN WPA2 XML radio frequency S2a mobility-based on GTP Service Set Identifier trusted WLAN access network Universal Access Method user equipment Universal Subscriber Identity Module visited PCRF wide area network wireless access gateway Wireless Broadband Alliance Wi-Fi Alliance trademark of the Wi-Fi Alliance Wireless Internet Service Provider roaming wireless local area network Wi-Fi Protected Access v2 Extensible Markup Language

25 to use them. For the moment, this information is relatively static and is prepared without taking real-time network conditions into consideration. The goal is to enable carrier-grade Wi-Fi that provides a secure and seamless experience for users, where roaming to and from 3G/LTE to Wi-Fi networks is operator-controlled and network-directed. To fulfill this vision, Ericsson is working with the industry to align both the Hotspot 2.0 Release 2 and ANDSF specifications. Vision for heterogeneous networks As an integral part of the complete mobile-broadband solution, Wi-Fi is a key element of heterogeneous networks. Just like any other radio-access technology (RAT), Wi-Fi needs to be connected to the core network. Viewed in this way, it can be used to deliver the full suite of services available on the cellular data network, becoming more than just an offloading alternative for capacitychallenged networks. Wi-Fi networks are consistently high performing owing to their inherent small-cell architecture and their use of widely available unlicensed spectrum. Thus, adding Wi-Fi to the set of accessible radios can help to optimize user experience. But integration of Wi-Fi into the cellular network, requires that a number of elements be considered: pico base stations house Wi-Fi and multimode small-cell licensed-band radios; common network nodes perform aggregation of cellular and Wi-Fi networks; unified network management; and many integrated back-end network elements, including HSS/HLR, OCS/OFCS and PCRF/BCRF, enable unified services and features. The enablement of industry standardization and solutions that push performance beyond standards to enable leading-edge services are important aspects of the vision for fully integrated Wi-Fi and cellular networks. Figure 1 shows an architecture for interworking Hotspot 2.0 access networks with a 3GPP-based core network using wellestablished protocols for access and core network interworking. The architecture is based on Wi-Fi Alliance and 3GPP R11 specifications. For completeness, the illustration shows how untrusted Wi-Fi (residential) can interwork with FIGURE 1 Wi-Fi and 3GPP HSS HLR SWx IMS OCS OFCS Gz Gy External IP networks SGi Control Data PDN GW S6b Rx Gx Auth Policy PCRF BPCF S2a the EPC, to, for example, support voice when only Wi-Fi coverage is available, however this is not elaborated further in this article. Use case The following use case is based on a typical dual-mode smartphone scenario where a subscriber is using the cellular data network of their service provider to browse the web while walking around a busy downtown area. The user enters a shopping mall where carrier Wi-Fi coverage is available. As data usage in the area is high, the cellular network signals the smartphone to switch to Wi-Fi. The Wi-Fi radio in the smartphone detects a Hotspot 2.0 access point (AP) which it queries, using the Access Network Query Protocol (ANQP) to find out whether or not the user s home network can be reached through this Wi-Fi network. If it can, the cellular network takes the decision to switch the user s S9 S9a S2a STa AAA BNG L2/L3 L2/L3 Trusted AC Wi-Fi Auth CAPWAP AP AP Wi-Fi RADIUS CoA ANDSF SWd S2b LBO LBO epdg WAG GBA S14 RADIUS DIAMETER SWu Untrusted Wi-Fi internet connection from cellular to Wi-Fi, based on ANDSF-provisioned policy for this location. Using the EAP-AKA mechanism, the smartphone switches and starts authentication with the AAA server of the cellular network using the user s SIM card credentials. On successful authentication, the access controller (AC) sets up a GTP tunnel to the PDN GW to access a carrier-managed connection to the internet, and the user continues to browse, enjoying good service performance. Hotspot 2.0 The WFA, which is responsible for the certification of Wi-Fi products, has created Hotspot 2.0 a technical specification that brings together a number of industry standards. Targeting service providers in the hotspot Wi-Fi market, the specification tries to apply the simplicity of cellular roaming to Wi-Fi. The program run by WFA is called Wi-Fi

Shifting control 26 FIGURE 2 Wi-Fi selected over cellular Data rate [Mbps] Cellular CERTIFIED Passpoint, and Ericsson has been a key contributor to it, providing equipment as part of the certification test bed. Today, connecting to a hotspot can be an awkward and inconsistent experience for subscribers who may need to go through several manual steps to switch network. These steps can include searching for a network, enabling a connection to that network and entering account credentials by launching a web browser. Some mobile-device operating systems, such as ios, have already automated parts of the switching process using a captive portal method WISPr or UAM and some third-party applications called connection managers embed this capability. However, these solutions are only available for certain devices, and are offered by a limited range of carriers; they are far from widespread. The aim of Hotspot 2.0 is to change this supporting widespread automatic switching to Wi-Fi. As an industrywide solution, Hotspot 2.0 will drive network interoperability and standardized network association, authentication, security, sign-up and policy control for mobile devices in a way that is completely transparent to the user. Release 1 completed in June 2012 specified the capabilities for network discovery and selection, and secure authentication. Certified handsets and access Cellular Wi-Fi points supporting theses capabilities are now starting to appear on the market. Release 2, planned for 2013, will include additional capabilities to deliver operator policy to devices and enable immediate account provisioning. Release 1 Network discovery and selection which enables mobile devices to discover and select networks automatically without subscriber intervention is a key element of the initial release. Using ANQP (specified in the IEEE 802.11u-2011 amendment 5 ) mobile devices can query hotspots for a range of parameters that are useful in the process of selecting a network. The complete list of information elements supported by the protocol is provided in Table 1, and includes parameters such as the hotspot operator s domain name, the roaming partners accessible via the hotspot and IP address-type (IPv4 or IPv6) availability. All of these parameters are useful for determining which available network best fits the subscriber. There are several credential types that can be used to grant a device access to the network, including: SIM/USIM-based authentication, which is widely used in cellular networks today; a username-password key; and certificate-based credentials for fixed operators and Wi-Fi-only devices. In all these cases, users will no longer Table 1: ANQP information elements ANQP elements Service-provider identification 3GPP cellular network information NAI realm list Roaming consortium list Hotspot identification Domain name list Venue name Venue information Operator-friendly name Network characteristics IP address-type availability WAN metrics Connection capability Operating class Network authentication type Beacon frame elements HESSID Access network type Internet available BSS load need to enter credential information manually to establish a connection. Ericsson s Virtual AP capability already enables multi-operator roaming where a single hotspot broadcasts multiple beacons (SSIDs) so that several service providers can offer connections to the same AP. The Virtual AP ensures full traffic-segregation and individual operator-defined AAA rules and policy application. However, the multiple-ssid approach limits the maximum number of roaming operators typically to eight and the transmitted beacons occupy excessive amounts of radio airtime. To establish a connection to their preferred provider automatically in Hotspot 2.0, mobile devices can use ANQP to determine which service providers are available via a given hotspot. This protocol identifies providers through their MCC and MNC numbers, realm information or roaming consortium element, enabling a wide range of roaming capabilities without having to broadcast provider information. Naturally, security is of great importance. All Passpoint devices use WPA2- Enterprise security to authenticate and

27 secure the air link between the device and the hotspot. WPA2 uses four-way handshaking and AES encryption, offering a level of security that is comparable to cellular networks. The Hotspot 2.0 specification supports four standard protocols commonly deployed in the industry: EAP-SIM for devices with SIM credentials; EAP-AKA for devices with USIM credentials; EAP-TLS for use on both the client and server side, with a trusted root certificate; and EAP-TTLS with MSCHAPv2 for username-password credentials. The specification adds to WPA2- Enterprise security by incorporating features to mitigate common attack threats in public Wi-Fi deployments, including layer-2 traffic inspection, filtering and broadcast/multicast control. Release 2 The second release of the specification is currently being drafted adding operator policy control and immediate account provisioning. The certification program for this release is planned for late 2013. While Release 1 supports automatic network selection based on user preferences, pre-provisioned operator policy, and network availability, it does not support the capability to deliver operatorspecific policies this will be included in Release 2. Immediate account provisioning, also referred to as online sign-up, is a standardized and secure process that enables new user accounts to be created at the time of connection. By supporting this process, a cross-vendor subscription-provisioning methodology can be adopted for non-subscribers providing, easy access to people using Wi-Fionly (non-sim) devices who have no other means of signing up, hence creating value for the operator. Shifting control To ensure the best user experience, subscribers should be connected to the most appropriate network given the time of day, their current location and account preferences. To prioritize the list of networks correctly for a given user, the ability to apply operator BOX B Wi-Fi handover behavior Today All handsets switch to Wi-Fi when it is available. Wanted Possibility for access selection in operator public hotspots, depending on: radio characteristics and load situation; subscription parameters; services; other policies. FIGURE 3 Interface architecture Wi-Fi SWu (IPsec) S2c S2c Trusted WLAN access Untrusted WLAN access policies is essential. Operators need to be able to control whether a device uses cellular or Wi-Fi, and in the case of Wi-Fi, which network would ensure the best user experience. Users still have control over when they connect to a residential or enterprise network by manually selecting the local Wi-Fi network. Operator policy has been included for some time in the 3GPP interworking wireless local area network (I-WLAN) specification 6. The ANDSF 7 mechanism provides devices with additional information to expedite discovery and selection. Mobile WLAN devices use PLMN selection based on operator-defined priorities that are preprogrammed into the SIM to choose the appropriate operator network 6. Such priorities can be further modified according to management objects (MOs), as specified in 3GPP TS24.235 8. The ANDSF mechanism augments PLMN selection, providing improved control over the network-access decisions made by devices. Through a set of operator-defined rules, ANDSF guides devices through the decision-making process of where, when and how to choose a non-3gpp network. Interaction between a device and the ANDSF server uses the S14 IP interface, and data MOs in OMA-DM compatible XML can be transported over any available network. Typically, operator policies are pre-stored in devices before they are shipped. However, the controlling ANDSF server can push policies to devices and devices can use the pull mechanism to access policies at any time. When roaming, the ANDSF server of the visited network takes precedence. S2a S2c S2c SWu (IPsec) S2c PDN GW epdg S2b When a device sends location information which may include geographical, cellular area and WLAN SSID descriptors to the ANDSF server, discovery information is sent back to the device providing it with a list of alternative access networks, such as a list of Wi-Fi network SSIDs within the current cell ID. At the same time, intersystem mobility policies (ISMPs) are sent to the mobile device, providing prioritized rules that control which network should be chosen. Each rule specifies a location and/or time for example, a certain Wi-Fi network can be valid when a device is in a particular cell at a certain time of day. The device will choose the network with the highest priority. Ericsson s role in the standardization work currently being carried out by the WFA is to ensure that ANQP network parameters, specified in Release 1, are included in Release-2 policies in such a way that operators maintain control over devices when they choose a network. Ericsson is also responsible for ensuring that operator policies defined in Hotspot 2.0 are fully integrated into 3GPP Rel 12 policy. Choosing the right RAT The policy tools described so far are valuable to the operator as they support control over user experience and take static or slowly changing network parameters into account. However, they do not cater for the rapidly fluctuating RF environment experienced by a mobile device. To illustrate the point, when a mobile device moves into an area covered by both Wi-Fi and 3G, it may decide to switch to Wi-Fi, even

Shifting control 28 FIGURE 4 UE S2a session mobility TWAN 1. Non-3GPP specific procedures 2. EAP authentication 7. L3 attach 8. L3 attach completion S-GW 0. GTP/ PMIPv6 tunnel 3. Create session request 5. Create session response 6. GTP tunnel though the coverage offered by the 3G network is better. Policies defined by ANDSF and Hotspot 2.0 will help to overcome some of the problems associated with automatic handover to Wi-Fi networks. However, tracking of rapid changes in the RF environment requires much tighter integration of the Wi-Fi and cellular networks, and is not part of the scope defined for Hotspot 2.0. To help overcome this issue and include realtime RF-environment information to improve the cellular/wi-fi decisionmaking process, Ericsson s concept for heterogeneous-network solutions makes use of information from both the cellular and Wi-Fi networks. The concept supports integration for legacy devices as well as performance-enhancing features identified for future device types. By using network load data from the cellular and Wi-Fi network in the decision-making PDN GW Roaming scenarios AAA vpcrf proxy 2. Authentication and authorization 4. PCEF initiated IP-CAN session modification procedure 9. 3GPP EPS bearer release 9. 3GPP EPS bearer release hpcrf process, for example, integrated Wi-Fi solutions can make informed real-time RAT-selection decisions. The concept, for example, enables the network to control Wi-Fi acceptance thresholds for legacy devices. In the example illustrated in Figure 2 both Wi-Fi and 3G coverage are available. In such situations, devices will not be allowed to connect to the Wi-Fi network if signal strength is below a given level a parameter that can be updated by the network in real time. To improve performance and consequently user experience even further, the long-term goal is to improve devices so they can receive instructions from any access network to switch to a different network, and to spread information across networks about signal condition and location. Session mobility Referring back to the use case, imagine HSS/ AAA that our user is watching a streaming video over the cellular network while walking into the mall. When the device switches from one network to another, the video should continue to play without any user intervention. To implement this successfully, full IP-session continuity and IP-address preservation between the cellular and the Wi-Fi network are required. I-WLAN, which determines how IP-interworking between cellular and non-cellular networks takes place, has been part of 3GPP specifications since Release 6 7. This type of interworking allows operators to integrate noncellular access into the cellular packet core network, providing harmonized traffic handling for cellular and Wi-Fi access. With packet core network integration, operators gain improved visibility and control over non-cellular traffic and consequently over the user experience. Subscribers will be able to use their favorite services independent of the access network and without interruption. As such, WLAN is an integral part of mobile-broadband access and the interworking enables subscribers to use WLAN access and still be linked to operator functions including charging, policy control, deep packet inspection (DPI), QoS and Lawful Interception (LI). Session mobility between 3GPP (such as UMTS and LTE) and non-3gpp (such as WLAN) access networks was first introduced to 3GPP specifications in Release 8, with continuous enhancements to this capability included in subsequent releases. There are two ways to distinguish mobility in non-3gpp networks depending on whether the target network is trusted or not and whether the mobility mechanisms used are network based or client based. Trusted or untrusted Determining whether or not a Wi-Fi network is trusted in terms of 3GPP standards depends largely on whether the subscriber s home operator trusts the security of the WLAN deployment. The business relationship between the WLAN provider and the home operator is often a factor in this equation. For example, when a subscriber connects to a WLAN provided by an operator other than their home operator, this WLAN

29 might be considered untrusted particularly if the provider uses the public internet to connect to the home operator. In such a case, the specifications allow the device to establish a secure tunnel to an epdg before the traffic is routed to the core network of the operator. In contrast, when subscribers connect to their operator s own Wi-Fi, it is considered to be trusted and a secure tunnel is not required. Network- or client-based Both network-based and client-based mobility between 3GPP and WLAN (non- 3GPP) networks are supported by 3GPP specifications. The 3GPP to WLAN interfaces are S2a, S2b and S2c. The architecture showing the three interfaces is illustrated in Figure 3. In all cases, session mobility is provided between the 3GPP network and the WLAN network with the PDN GW acting as the userplane anchor between the two. S2a: The mobile device connects to the Wi-Fi network using standard WLAN authentication procedures without any need for mobility or tunneling support in the mobile device. PMIPv6 or (as of Release 11) GTP protocols can be used for the S2a interface between the WLAN and the PDN GW, but GTP is already widely deployed in mobile networks and offers a range of performance advantages over PMIP. Either IPv4 or IPv6 may be used in the transport layer. S2b: The wireless network is considered an untrusted non-3gpp access network. The mobile device must establish a secure IPsec/IKEv2 tunnel to an additional network element, the epdg, through which the PDN GW is then accessed. Either PMIPv6 or (as of Release 10) GTP protocols can be used for the interface between the epdg and the PDN GW, and either IPv4 or IPv6 transport may be used. S2c: This option can be used over both trusted and untrusted non-3gpp access networks. The mobile device must connect to the PDN GW using DSMIPv6. In Release 10, the S2c option added support for IP mobility per flow in addition to IP session mobility. The drawback of this solution is that new clients would be needed, whereas S2a can operate in clientless mode compatible with today s devices. For operator-deployed and fully References integrated Wi-Fi networks, the trusted WLAN model is most appropriate. In this case, the S2a interface is the most cost-effective solution, allowing unmodified mobile devices to access the PDN GW via S2a. Ericsson has held a leading role in the Release 12 SaMOG project, which aims to add full mobility across the S2a interface, including support from appropriately enabled dual-mode devices. A typical message sequence for session mobility is shown in Figure 4. Conclusion For most operators, Wi-Fi has become an integral part of their mobile-broadband strategy. Ericsson s concept for heterogeneous networks incorporates Wi-Fi, fully integrating it into mobile-access and core networks. The evolution of Wi-Fi technology through Hotspot 2.0, application of operator policy, intelligent RAT selection and GTP session mobility will bring about a world where people no longer know or care whether they are connected using a cellular or Wi-Fi data network, and operators will be able to control the choice of connectivity to optimize the user experience. Ericsson has a leading role in standardization efforts to ensure that the key elements of Wi-Fi are implemented in 3GPP. 1. WBA and GSMA, March 2012, Press Release, GSMA and WBA collaborate to simplify Wi-Fi hotspot access for smartphones and tablets, available at: http://www.wballiance. com/2012/03/20/gsma-and-wbacollaborate-to-simplify-wi-fi-hotspot-access-forsmartphones-and-tablets/ 2. Wireless Broadband Alliance, Next Generation Hotspot Program, available at: http:// www.wballiance.com/wba-initiatives/ next-generation-hotspot/ 3. Wi-Fi organization, 2012, White Paper, Wi-Fi CERTIFIED Passpoint: A new program from the Wi-Fi Alliance to enable seamless Wi-Fi access in hotspots, available at: http://www.wi-fi.org/ register.php?file=wp_20120619 _Wi-Fi_CERTIFIED_Passpoint.pdf 4. Ericsson, June 2012, Traffic and Market Report, available at: http://www.ericsson.com/res/ docs/2012/traffic_and_market _report_june_2012.pdf Stephen Rayment is chief technology officer for Wi-Fi products at Ericsson. Previously, as CTO of BelAir Networks, he led the definition and delivery of the industry s first carrier Wi-Fi solutions. He has over 30 years of product experience in the telecommunications industry and has been active in industry standardization as an officer in IEEE 802.11 and in the Wi-Fi Alliance. Stephen is author of over 25 patents. He holds a B.Sc. and an M.Sc. in electrical engineering, from Queen s University in Kingston, Canada and a diploma in administration, from the University of Ottawa, Canada. Joakim Bergström is an expert in new radioaccess networks at Design Unit Radio. He has more than 10 years of experience in standardization within the 3GPP RAN area working with HSPA, LTE and their evolution. He holds an M.Sc. in electrical engineering from the Royal Institute of Technology (KTH), Stockholm. Within the radio area, he has coordinated all of Ericsson s standardization activities and projects since 2011. 5. IEEE, 802.11u-2011 - IEEE Standard for Information Technology-Telecommunications and information exchange between systems-local and Metropolitan networksspecific requirements-part II, available at: http://standards.ieee.org/findstds/ standard/802.11u-2011.html 6. 3GPP, Technical Specification 24.234, 3GPP system to Wireless Local Area Network (WLAN) interworking, available at: http://www.3gpp.org/ ftp/specs/html-info/24234.htm 7. 3GPP, Technical Specification 24.312, 3GPP Access Network Discovery and Selection Function (ANDSF) Management Object (MO) available at: http://www.3gpp.org/ftp/specs/ html-info/24312.htm 8. 3GPP, Technical Specification 24.235, 3GPP System to Wireless Local Area Network (WLAN) interworking Management Object (MO), available at: http://www.3gpp.org/ftp/specs/htmlinfo/24235.htm

Automating the cloud 30 Deploying telecom-grade products in the cloud Gone are the days when the cloud was simply considered to be extra and unreliable computing capacity. Today it has developed to become the center of an established business model in which global applications are hosted, resources are efficiently managed and economies-of-scale created. The cloud as a platform is now ready for the next level, being remodeled to host critical services. FRANCESCO CARUSO, CALIN CURESCU, CHRISTIAN OLROG, JAN SÖLVHAMMAR AND ANDRÁS VAJDA Cloud computing has come a long way from simply being virtual data warehousing the shapeless blob used to illustrate a network owned by another operator or organization, or to represent unknown architecture. Today s cloud solutions manage anything as a service (XaaS). This includes anything that an enterprise, government, organization or individual might need to go about their day. Cloud solutions house applications, databases, services, software, test environments, financial platforms and backoffice systems. The cloud approach brings high accessibility through thin clients and apps, resource sharing, scalability and recovery all while providing economies of scale and pay-as-you-go pricing. However, this maturity and readiness to challenge new requirements results in a need for more stringent security demands. As the cloud matures, the one-sizefits-all model of telecom products is BOX A Terms and abbreviations also in the process of evolving, moving toward product diversification to match individual subscriber requirements and tastes. To achieve individualized product offerings, a much higher degree of automation is needed to define products in such a way that they do not conflict with each other, can ensure a short time to market, and can be assigned with appropriate Service Level Agreements (SLAs) that can be upheld without requiring manual intervention from an operational center. Cloud management Cloud solutions have matured to the point of becoming an attractive option for hosting complex and mission -critical systems. The OSS and BSS functions required to define, allocate, supervise and monetize cloud resources, as well as implement some of the key aspects of the cloud (automation, self-service, and on-demand resource management) are collectively referred to as cloud management. This is one of the essential components of the maturing cloud model. However, the level of automation in mainstream cloud-management solutions tends to be limited, supporting just the basic building blocks of a deployed service: virtual machine (VM) management, software installation and configuration of some aspects of storage and networking. Tasks such as securing optimal placement of workloads, fulfillment of SLAs and resource reallocation are, for the most part, still performed manually, with limited support from the underlying management system. The lack of automation is a significant barrier to developing and delivering complex services ones that require multiple resource types and need to meet stringent QoS requirements. To overcome this barrier, cloud management needs to be enhanced with innovative technologies that automate tasks such as reallocation of resources and load balancing. Ericsson s concept of model-based service definition and automatic resolution of SLA constraints is a step toward increased automation. Functional architecture The functional architecture of a cloudmanagement solution is illustrated in Figure 1. The typical OSS/BSS components can be reused in the cloud model as follows: API ASM BSS CMDB CPE EMS HW IaaS OSS PaaS application programming interface abstract service map Business Support Systems configuration management database cloud processing equipment Extended Messaging Service hardware infrastructure as a service Operations Support Systems platform as a service SaaS SDP SLA SMS SW URL VDC VM VoIP XaaS software as a service Service Delivery Platform Service Level Agreement Short Message Service software uniform resource locator virtual data center virtual machine voice over IP anything as a service Planning This component defines cloud services, including dimensions for price, campaigns, and SLA characteristics. Fulfillment This component creates, sets up and deploys applications and services hosted by the cloud. It uses a PaaS/ IaaS approach to employing platform

31 resources (such as life-cycle management and embedded cloud functionality) and infrastructure resources, such as virtualized computing, networking and storage. Assurance This component supervises and, if possible, automatically adjusts allocated resources. Typical aspects of service assurance are monitoring, SLA enforcement and fault management. Security Due in part to the multi-tenant nature of cloud solutions, security functions in the cloud context are more important than they are in traditional data warehousing. They play a vital support role in SLA management, and mandatory security aspects of any cloud-management solution include identity control, access management, logging and monitoring, auditing and compliance. Charging This component implements the payas-you-go model of cloud computing, by generating the corresponding charging records for external billing systems. FIGURE 1 Functional architecture of cloud management Cloud-provider planning and management Cloud-service management Backup management Analytics IaaS management Cloud provider portal Service bus and cloud management API Service-catalog and service-order management Activation SW provisioning and management Cloud orchestration CMDB SLA management Fault management Performance management IaaS APIs ID and access management Key management service Logging service Automated auditing Virtual and physical resource management Virtualization layer Cloud tenant portal Planning Fulfillment Assurance Security Computing Storage DC networking Charging and billing Analytics Deploying complex services Over the past decade cloud-based offerings have evolved constantly, becoming more complex and highly integrated. Today, the dependency hierarchy of most cloud applications and services is non-trivial. A cloud service may, for example, use another mash-up, rely on a networking feature or be dependent on a web service provisioned by another vendor. Failures or delays that occur in one service can impact multiple dependent services, creating situations that can become difficult to manage or recover from manually. To reduce the knock-on effect of failures in highly dependent systems, current research and development is moving towards building platforms that manage this complexity through automated creation, composition, publishing, marketing, bidding, contracting and revenue-sharing functions. The next step in the evolution of the cloud model will support portable selfdescribed cloud applications and services that use model-driven configuration, interaction and management. Telecom-grade and other regulated services place strong requirements on end-to-end performance and nonfunctional parameters, such as latency, throughput, localization, security, availability and reliability. For SaaS deployments, such requirements need to be translated into cloud-platform SLAs that guarantee sustained and verifiable endto-end performance. Models Service Delivery Platforms (SDPs) have been used to great advantage in communication services for life-cycle management. These platforms generally include a framework for creating services, an order/fulfillment subsystem, and an execution platform to host communication services. An SDP enables products to be created from groups of resources, value-added services, multiple configurations and billing plans. By picking and mixing in this way, communication service providers can use an SDP to define and offer services with a short time to market. High availability, elastic scalability and provision for disaster recovery are among the key benefits of a cloud deployment. To maximize these benefits, complex and QoS-sensitive applications need to be specified within the service creation environment and SLAs need to be handled automatically at the fulfillment stage. In other words, by extending the space where services are created, complex applications can also be made scalable, available and suitable for cloud deployment. The Ericsson model To create value-added services, Ericsson s concept of an extended creation environment for cloud services is based on modeling the characteristics of a virtual data center (VDC) and virtual zones. The concept models applications and services in terms of logical components that are available in a palette, where embedded integrity and validation rules are used to guide the composition of cloud services and avoid any invalid combinations.

Automating the cloud 32 FIGURE 2 Model-based service definition Resource inventory Access selection Internet service Resource dispatch CPE Resource EMS Activate INET Activate Wi-Fi Internal process component identifiers One of the challenges of this approach is to identify the right level of abstraction in the service-creation environment somewhere between a business abstraction and a technical specification so that the service can be monetized and meaningful SLAs can be defined from a user perspective. For example, if a service includes FIGURE 3 Input from PC CPE equipment Access type Control Invoice Cancel VDC service Resource IaaS provider Cloud model Order for triple play VoIP with VM feature IPTV with sports package Internet gold package Activation date dd-mm-yyyy SLA management Activate internet over Wi-Fi PC Base station antenna tuning Availability Elastic scalability Security Start flow Cancel/ rollback Product triple play VoIP service Resource VoIP provider Provision VoIP Activate VoIP External process component identifiers Activate service over Wi-Fi Base station EMS Fixed subscriber EMS Externally discovered catalog specifications IPTV service Resource IPTV provider Provision IPTV Activate IPTV Outputs Success Fail Order data disaster recovery, this may be implemented through geographic replication. However, the service users only need to know that several levels of backup are available with sliding payment packages; they need not be concerned with how recovery from disaster is achieved. The typical service model of a triple -play product enhanced with a VDC cloud offering is shown in Figure 2. The basic building blocks are specification components for resources, services and products, which allow capabilities to be described in a modular way: resources network, storage and computational resources are the basic functions of the platform, they support the execution of services and need to be allocated quantitatively; services represent an identified piece of basic functionality (such as SMS) or value-added services such as internet access or voice; and IPTV product VoIP product catalog VDC service Resource IaaS provider Cloud model products provide a complex end-toend service with defined business and billing characteristics, such as a package including free voice calls in the home network, free SMS, and mobile data provided at a flat rate. As shown in Figure 3, an SLA can be applied as an additional constraint at any level. When a service component is deployed in the cloud, a description for it is created, which includes: basic properties an informal description; offering the functions that are included, used to construct the dependency tree; characteristics fixed properties, such as memory or processing consumption needs, and variable, deploymentdependent properties such as price or location; configuration information needed for service instantiation, such as installation scripts and download URLs; dependencies other service components that the service being described depends on; and constraints that describe nonfunctional requirements the SLA core. In the Ericsson concept, SLAs can specify both traditional networking aspects, such as bandwidth and delay, as well as non-functional aspects, such as processor speed, available memory, placement of VMs at specific locations in the network topology, and the cost associated with a certain component. For traditional networking aspects, SLAs are defined in terms of specific dependencies, such as the geographic location of a given service component or the throughput that a particular network component should provide. The Ericsson concept extends the SLA definition mechanism to include aggregated constraints. For example, a service provider is more likely to be interested in the total price of a service including its dependencies, or the total (aggregated) reliability of a service from an end-toend perspective, than the cost or reliability of its individual components. The freedom to mix and match potential dependencies without restraint, as long as the aggregated SLA is fulfilled, optimizes the service-selection process. The aggregation mathematical function also needs to be specified, which in the

33 case of delay and pricing is addition, and for availability is multiplication. Each service component has an associated process component, which governs its life cycle from activation through assurance and decommissioning. For example, the Extended Messaging Service (EMS) resource is associated with the procedure for activating internet access over Wi-Fi. At order time, all process components are collected to form a service-composition plan macro flow which includes a dependency structure that specifies: when various process components should be invoked; what data is defined as input to the component; and the possible set of logical operations that can occur between components. The SLA resolver ensures the SLAs are upheld. At order time, the creation environment sends the order description the top-level service dependencies and SLA aspects chosen by the consumer to the SLA resolver. Based on the available service components and their characteristics, the resolver automatically creates the entire service tree and deployment plan for use by the fulfillment component. SLA management To fulfill end-to-end SLAs, they must be translated into resource-related requirements on the cloud infrastructure. This is more challenging in a cloud context than in traditional data centers as service component characteristics vary. They may be allocated in different locations, accessible over different network links or share infrastructure with other applications dynamically. Manually constructing a clouddeployment graph that defines which services to use and how and where to create the necessary VMs and network links is a complex and maintenanceintensive process. An automatic process that builds the dependency tree based on the service model and resolves SLAs into resource parameters suitable for instantiation would be very beneficial. Such an automated process the SLA resolver in the concept uses a resolution engine to settle constraints and build the dependency tree. Starting with the top-level service description, and including the SLAs agreed with the consumers of the service, the engine FIGURE 4 Service description repository DevIdDB Zencoder Software decoder X Container NW (1Gb) Example of service model with SLAs Refinement by adding components Zencoder Offers: Transcoding 1.8s delay Requires: Device DB, decoding DevIdDB Offers: Device DB Requires: Linux HW dec C Offers: Decoding Requires: Linux, dual core 3GHz Topology: HW dec Container Offers: Linux, dual core 3GHz Node 1 chooses the services that match the dependencies and fulfill the constraints. The resolver algorithm is applied iteratively to each of the dependencies and employs backtracking when a constraint is not fulfilled. With a fully built resolution tree, it is possible to identify the components needed to support a service and then group them into a virtual node. The resources needed by the virtual node to host the allocated software stack can also be computed automatically. To prepare for infrastructure allocation, the resolved service-description tree is packed into an abstract service map (ASM) consisting of nodes, each with its own software stack and network links. The ASM is handed off to the fulfillment function, which determines the available physical infrastructure, based on information stored in the configuration MyCinema Offers: IPTV 3s delay sum aggregated 99.5% availability multiply aggregated Location: <country> Requires: Transcoding Relational DB Link (transcoding Ext) 2Gb Link (transcoding DB) 1Gb MySQL Offers: Relational DB 0.5s delay Requires: Linux Container Offers: Linux, dual core 2GHz Node 2 Link 1 NW Link Offers: Network link 1Gb capacity 0.2s delay Configuration: Node 1 Node 2 Link 2 NW Link Offers: Network link 2Gb capacity 0.2s delay Configuration: Node 1 External management database (CMDB). Once the necessary VMs are instantiated, the provisioning mechanism uses the VM s service description sub-tree to deploy the software stack in the right order and according to the configuration scripts specified in the service description. Figure 4 illustrates the SLA resolver. The engine starts with the MyCinema abstract service definition, which specifies the service as an IPTV type with specific SLAs for location, delay and availability. Dependencies include a transcoder, a database and two provisioned links with specific connectivity and bandwidth constraints. The SLA resolver extracts specific components and refines the definition by adding components, such as Zencoder for the transcoding service and MySQL for the database. The aggregation constraint of the delay is satisfied MyCinema

Automating the cloud 34 FIGURE 5 Mapping of service model to the infrastructure Resolved requirements Link 2 (2Gb) External Node 1 3GHz dual core Link 1 (1Gb) Search on the live data center for a working deployment and configure network Node 2 2GHz dual core András Vadja is an expert in cloud computing and cloud management within Group Function Technology and Portfolio Management. He joined Ericsson in 2001 working within Ericsson Research and Business Unit Networks. At Ericsson Research he was one of the initiators of Ericsson s cloud-research efforts, driving the strategy and architecture work. He holds a B.Sc. in mathematics and computer science and a master s in distributed computing from Babes-Bolyai University, Cluj-Napoca, Romania Jan Sölvhammar Mapping to live data center GW requires a three-second delay and the sum of the delays of the dependencies is less (1.8 + 0.5 + 0.2 + 0.2 = 2.7). The corresponding ASM and mapping to the infrastructure is shown in Figure 5. Conclusion Innovative mechanisms for automatically managing complex cloud services and associated QoS and other SLA requirements are needed to take the cloud model to the next level, and bring increased automation into the underlying architecture. Two Ericssondeveloped technologies, model-based service definition and automatic resolution of SLAs, will help bring about automation in the cloud by extending the service-creation environment and supporting service providers to create nonconflicting, differentiated offerings with short times to market and automatic SLA fulfillment. Francesco Caruso is a principal cloud architect within the Cloud Infrastructure System Management group at Ericsson s Business Unit Networks. He joined Ericsson in 2012 from Telcordia Technologies, where he was director of the Enterprise Integration Group. He championed the internal cloud program to transition OSS to the cloud environment and to extend the OSS into the cloud-management domain. He holds a B.Sc. in computer science from the University of Pisa, Italy, and has more than 15 years of expertise in the telecom OSS domain. Calin Curescu is a senior researcher with the Services and Software department of Ericsson Research. He initiated the research on SLA-driven management of cloud services, and has worked with cloud computing, service composition and network exposure. He holds a Ph.D. in computer science from Linköping University, Sweden. is product manager for OSS products at Ericsson s Business Unit Support Solutions, where he has been working with various software products for multimedia applications and OSS. He joined Ericsson in 1990 and has over 20 years of product-management experience in different areas. He has worked with radio-network products for many years and holds an M.Sc. in industrial engineering and management from Linköping University, Sweden. Christian Olrog is a systems manager and chief architect at Business Unit Support Solutions. He holds an M.Sc. in physics from KTH Royal Institute of Technology, Stockholm, Sweden. He joined the department of New and Special Business Operations at Ericsson in 1999 and has been involved in research and development in areas ranging from wireless LAN standardization and IP security to embedded devices and enterprise applications.

Reshaping the cloud 35 Enabling the networkembedded cloud Growth in the number of smartphone and tablet applications deployed in public data-centers, and the rising use of cloud services by enterprises can lead to stretched resources, suboptimized networks and, ultimately, an inferior user-experience. Maybe it s time to reshape the cloud. DAVID ALLAN, JAMES KEMPF AND TORBJÖRN CAGENIUS Making better, more dynamic use of cloud resources requires a whole new innovative architecture: the network-embedded cloud. This concept is based on a variety of computational and storage resources being embedded in the network, interconnected via provisioned WAN links, and distributed closer to the network edges to provide the right QoE and more flexible connectivity. Naturally, a change in architecture places new requirements on the way clouds integrate with networks. To implement the network-embedded cloud, some key enablers are required, one of which is elastic networking. Elastic networking is a technique for dynamically managing network connectivity between data centers, in a way that is complementary to their computational and storage resources. This technique can reduce provisioning BOX A Terms and abbreviations AAA authentication, authorization and accounting API application programming interface CDC central data center CDN content distribution network CIR committed information rate DC data center DDC distributed data center EIR excess information rate E-LAN Ethernet LAN service E-LINE Ethernet line service GW gateway IPsec IP security IPT-NMS IP Transport Network Management System connectivity time from days to minutes. However, for it to work, a direct relationship must exist between the data-center architecture and network connectivity to maintain tenant isolation, ensure provisioned bandwidth and uphold prioritization within the distributed cloud. Market situation Cloud computing combines the collective benefits of rapid fulfillment and multiple business models with the elasticity of computational and storage resources. It is the next phase in the automation evolution that began with batch processing, continued with early time- sharing and virtualization, and has resulted in the massive expansion of warehouse-scale computing. Until now, the networking component of cloud infrastructure has been confined primarily to intra-data-center communication. However, there are a number of factors that are driving the development of inter-data-center networking, including: MEF E-LINE Metro Ethernet Forum Ethernet Line Service MPLS Multiprotocol Label Switching NaaS Networking as a Service NMS network management system OS operating system OTN optical transport network RNC radio network controller SLA Service Level Agreement VLAN virtual local area network VM virtual machine VPLS Virtual Private LAN Service WAN wide area network WDM wavelength division multiplexing increased deployment of applications over private and public clouds, which is known as the hybrid-cloud model; storage-capacity issues at existing facilities, requiring seamless interconnect between multiple data centers, which is known as cloud bursting; geo-redundancy, to minimize the impact of a major disruption to normal operations; and the ability to personalize the location of computational and storage resources in the network to conserve overall bandwidth, or minimize latency between critical components. The requirements imposed by the seamless interconnect and the networkembedded cloud need to be analyzed to understand: the differences in the resource environments of intra- and inter-data-center communication; and the characteristics of data-center traffic patterns throughout the life cycle of a given workload. The trend in architecture design is shifting towards the provision of nonblocking connectivity within the fabric of the data center. Statistically speaking, connectivity is non-blocking assuming perfect load balancing across the bisection bandwidth. However, the scaling capability of such designs or clusters is limited; once the maximum has been reached, inter-cluster connectivity becomes blocking. Current operational practice to minimize inter-cluster bandwidth requirements is to place workloads that need to interact with each other within the same cluster. Similar operational practices could be applied to the sets of clusters, irrespective of physical location, if requirements for geo-redundancy and data-mirroring could be ignored allowing the network to continue to function without further intervention. But even

Reshaping the cloud 36 FIGURE 1 Vision of a network-embedded cloud Tenant 1 AAA Security Policy SLA WAN network management Network virtualization WAN E-LINE E-LAN L3VPN L2VPN IPSec VPN within a non-blocking cluster, additional computational support is needed to manage collisions of exceptionally large data flows. Adopting an intracluster or intra-data-center approach requires enhanced resource management. Grouping computing resources geographically to manage overall network bandwidth or customer latency will place even greater demands on the integration of cloud data-centers and the WAN. Ericsson vision Management of computational and storage resources has, until recently, been the primary focus of building and operating clouds. Unfortunately, this focus tends to result in suboptimal designs as factors such as network latency, the cost of high bandwidth over long distances and the lack of service guarantees are ignored, leading to poor application and Tenant 2 Tenant 3 Cloud orchestration DC1 Elastic networking Cloud OS2 Network virtualization Cloud OS1 Network virtualization Elastic networking Elastic networking network performance or high costs for certain applications. Ericsson s key insight into the networkembedded cloud has been finding the proper balance between computational, network and storage resources to create optimal cloud-infrastructure designs. Ericsson s vision covers the full range of deployment scenarios, from mega datacenters, smaller regional micro datacenters, clusters of individual servers, and embedded-service blades on routers sometimes referred to as pico data-centers. Network virtualization provides tenants with secure, isolated, elastic network-slices with associated SLA guarantees in essence, Networking as a Service (NaaS). Cloud orchestration and elastic networking act as the glue that binds computational, storage and networking resources together into a single entity that can be dispatched as Charging Host virtualization platform Micro DC Mobile network shown in Figure 1. The resulting service provided to tenants is a seamless, secure and isolated elastic slice of the networking, computational and storage resources a slice that has outward connectivity to the internet. Elastic networking provides tenants with an abstraction called a flash network-slice a logically isolated virtual network that may span several data centers and network domains, with service-level guarantees defined in timescales of less than a second and up to a few minutes. This is a considerable improvement on, say, the time it takes to bring up a VPN connection in the WAN today a process that can take from a couple of hours up to several days to complete. Tenant traffic within the flash network-slice is logically isolated from other traffic and can be further isolated with the addition of a firewall or through encryption. Each slice will have associated bandwidth guarantees, which can be met on a flexible basis so the tenant can save on unused bandwidth for times of greater need. The flash network-slice brings to networking the same model of on-demand, elastic resource-allocation that data centers and virtualization bring to computation and storage. Cloud network-orchestration aggregates computational, storage and network resources, providing the tenant with a single logical view for the deployment and provisioning of applications. Tenant applications are constructed by: selecting various components from a catalog; specifying the service-level guarantees for network connectivity between applications; and adding location constraints on the deployment of each chosen component. Storage resources are allocated to the application to provide access to critical data, and the properties of the connection from the application to clients are specified. The developer describes the application at a high level, and it is the job of network orchestration to refine this description into a physically deployable system a process that involves filling in the details of where to deploy virtual machines, how to provision them, the exact network links and their bandwidth, and what type of

37 load balancing, if any, is necessary for client access. This orchestration model involves a multi-tiered approach, which enables developers to create applications with a wider scope than that allowed by the currently popular three-tiered approach. Use cases When considering cloud operations, and in particular inter-cloud transactions that could benefit from networkresource management, a number of use cases emerge. All are various forms of the larger problem of mapping workload to computing resources while taking network connectivity into account. The architecture of the network-embedded cloud distributes computational and storage resources geographically and integrates these resources operationally throughout the operator network. As shown in Figure 2, resources vary in size and are placed at different locations in the network, which in turn imposes different requirements for elasticity on each resource. The typical central data center (CDCs) has a high capacity to process requests, host many applications and support a large number of tenants. As this type of data center tends to be served by dedicated high-capacity links, the requirements for fully elastic transport connectivity are often trivial. On the other hand, a typical distributed data center (DDC) has fewer tenants, fewer statistical multiplexing gains, and shares connectivity over access and aggregation links. Consequently, DDCs will have a proportionately greater need for additional elasticity at the transportlayer level. FIGURE 2 per-tenant basis and managed dynamically. In this way, the bandwidth per tenant can be managed enforced, policed and monitored dynamically at the DC border gateway, as long as the total bandwidth required is within the established shared-transport capacity. The migration of an application from one center to another exemplifies the CDC-to-CDC use case. Consider an application that resides in CDC A. For reasons related to redundancy, the user wants to move the application to CDC B. To do this, the user orders additional VMs in CDC B and an inter-dc bandwidth, which may contain QoS properties, for a certain period of time. The connectivity between the application in CDC A and the copy in CDC B is established by configuring a new virtual connection on top of the existing inter-dc transport connection. This request can be enforced by the border gateway of each data center. Distributed data-centers in the operator network Primary site CDC DC GW Local switching site Operator A IP backbone DDC Local switching site Distributed to enterprise For the DDC to enterprise-site use case, the need for dynamic-bandwidth connectivity at the transport level is assumed to be greater as significant fixed-facility capacity may not be available 100 percent of the time. Even though access and aggregation links may support up to 1Gbps or 10Gbps, they may be shared by other services. So the need to access or move applications dynamically between the enterprise network and the DDC creates a need for elastic networking-connectivity. Bandwidth must be managed dynamically throughout the access and aggregation network as well as in the DC border gateway. To use cloud services provided by an operator, enterprises first need to establish initial connectivity from their site to the operator DC. This step is performed automatically through the operator s customer portal. An existing or new VPN service ordered CDC DC GW DDC Central data centers across dozens of sites on a national and global scale Distributed data centers across hundreds of sites on a central office/metro scale Central to central For the CDC-to-CDC use case, the bandwidth for transport between the two centers is assumed to be high. This type of link could be implemented through a dedicated lambda on a WDM network, OTN, MPLS or an MEF E-LINE service. This level of bandwidth allows the DC operator to provide high-availability or geo-redundancy services to its cloud users as well as for application mobility, such as follow-the-sun scenarios where workflows are available to teams collaborating across time zones. Elasticity for these slices is provided on a Enterprise LAN/DC Aggregation Last mile Enterprise LAN/DC Aggregation Last mile Thousands of enterprise sites on a LAN scale Connectivity type Transport elasticity Per tenant elasticity Central DC to central DC Central DC to distributed DC DC to enterprise site/dc No Limited Limited/full Full Full Full

Reshaping the cloud 38 FIGURE 3 Properties of an elastic network-connection Modified VPN with additional 100Mbps CIR or EIR bandwidth added Initial VPN with CIR 100Mbps 200Mbps 100Mbps in this way could include a basic connectivity service, with say 100Mbps CIR bandwidth. Once operational, an enterprise may need to modify connectivity dynamically. This can occur, for example, FIGURE 4 Elastic networking with IPT-NMS Site A Quantum A Cloud network controller Physical network Hypervisor Binding Tenant 1 Elastic network Physical site GW EIR added between t 1 to t 2 - volume based (Gbph) or - throughput based (x Mbps) t 1 t 2 when an application running at the enterprise requires additional computational resources from the cloud service. Flexible connectivity is achieved through the cloud network orchestration and, in this case, connectivity Cloud orchestration Flash network-slice IPT-NMS Physical WAN instance (such as VPLS) Binding Physical site GW Without elasticity the bandwidth will be capped at 100Mbps Time Quantum B Cloud network controller Physical network Hypervisor Site B bandwidth might be increased from the existing 100Mbps to say 200Mbps for a specific time period. The requested connectivity is provided by modifying the existing VPN, and is enforced in the border gateway and intermediate network. As highlighted in Figure 3, the additional bandwidth may be offered with properties that are different from those included in the basic VPN service. It may, for example, be offered as an EIR or as a measured service where the user is charged per megabyte. In this particular use case, the elastic connectivity impacts the allocated resources inside the DC as well as in the network, which requires coordination between the two. Missing technology To enable the network-embedded cloud at the infrastructure level, a number of key technologies need to be added to today s cloud deployments, one of which is support for network virtualization. To achieve this, the cloud operating system must support virtualized networks as first-class objects in the API, exactly as for virtual machines and storage blocks. OpenStack, an open-source cloud operating system currently under development, contains support for virtualized networking in the form of a virtual Layer 2 network management API called Quantum 1, which supports the following objects: network a virtual isolated Layer 2 domain in the data center for the exclusive access of a tenant; port a logical Layer 2 port on a virtual switch; and attachment a Layer 2 interface providing network services to a virtual machine. The Quantum API allows a tenant to create and delete these objects, plug attachments into ports, unplug them as well as perform other operations. It is the job of the data-center network manager to implement a Quantum Layer 2 network on top of the physical data-center network. T o export this API as a plug-in there are a variety of technologies available to the network manager, such as VLANs and IP tunnels. While this API supports virtual networks inside the data center, implementing NaaS in the network-embedded

39 cloud requires additional support to link virtual network resources inside the data center with those outside the data center (in the WAN). Ericsson s elasticnetworking extension to Quantum provides this support. Elastic networking supports the creation of a VPN over the WAN by adding virtual links and connecting the VPN to Quantum networks in multiple sites. The resulting VPN is an implementation of the flash network-slice abstraction in the OpenStack Quantum cloud operating system 1. As with Quantum, an elasticnetworking agent is required to tie the API into the physical network. For that purpose, Ericsson s implementation supports an internal API that binds the external API implementation to a specific network management system. The concept behind Ericsson s IPT-NMS 2 supports managing wide area network connectivity, so a system design using this component as part of cloud orchestration can leverage this. The resulting architecture is illustrated in Figure 4. The cloud orchestration system deploys tenant applications in the different data centers depending on their requirements for computational, storage and networking resources. The system handles internal resources, including networking via the Quantum API, and calls the IPT-NMS via the elastic networking API to handle the details of WAN network-establishment between data centers relieving tenants of the need to be concerned with such details. Being able to make the most of the integration between cloud orchestration and NMS gives network operators with their own data centers a clear advantage. However, in the case where the data center and the network are managed by different administrative entities, coordination between cloud orchestration and the NMS will be required to establish a flash networkslice, stitching each part of the slice over the domain boundaries and over the multiple domains involved. The final piece of missing technology in the network-embedded cloud is support for diversely deployed computational resources that are often present in networks, such as unclustered servers, RNCs and routers with service blades embedded into the network. Ericsson s prototype cloud orchestration system allows operators to manage these resources in the same way as they do large homogenous data centers. Routers running a hypervisor on blades also run an instance of the cloud orchestration agent on those blades. The agent insures that the VM instances are running the latest software by managing upgrades when new versions are released. Cloud orchestration can also manage content-distribution software from multiple vendors, as content from certain sites can require a particular type of content distribution network (CDN). Attempting to manually manage the complexity created by different vendors software, patch releases and upgrades is a challenging task, with a high probability of errors and resulting in misconfigurations. Conclusion Enterprises have started to move applications to the cloud. However, to fully adopt the cloud as a central technology, additional network considerations such as bandwidth, latency and privacy need to be addressed. Current VPN technology takes these parameters into consideration in the WAN but comprehensive integration into the cloud technology base is lacking. The same level of flexibility in allocating and managing flash network-slices needs to be provided by WAN networks as the cloud provides for allocating and managing computational and storage resources. To cope with the increased traffic generated by smartphones and tablets, the cloud will have to get closer to users deploying computational and storage resources in small, micro or pico data centers embedded in the network. As they have control over resources in both the network and the data center, network operators managing data centers have a clear advantage when it comes to supporting enterprises in establishing connectivity. To combine NaaS with data center computational and storage services, closer cooperation is needed between cloud orchestration and the NMS. Extensions to Quantum and OpenStack to connect data-center virtual networks over the WAN can fulfill that need while pico data-centers can be incorporated into the architecture in a seamless manner. David Allan is a distinguished engineer at DUIB Systems and Technology, Business Unit Networks at Ericsson Silicon Valley in San Jose, California. He joined Ericsson in 2009 and his current role focuses on carrier and cloud infrastructure based on MPLS and Ethernet. He holds a B.Eng. from Carleton University, Ottawa, Canada. James Kempf has worked at Ericsson Research in Silicon Valley on software defined networking (SDN) OpenFlow and cloud computing since 2008. He graduated in 1984 from the University of Arizona in the US with a Ph.D. in systems engineering, after which he worked with various blue chips in Silicon Valley, primarily in research. He has also worked with the IETF for 10 years. Torbjörn Cagenius is an expert at BNET System Management, Business Unit Networks. He joined Ericsson in 1990 and has worked in a variety of positions and with different technology areas. His current role is system area driver for distributed cloud architecture. He holds an M.Sc. in electrical engineering from the Royal Institute of Technology (KTH), Sweden. References 1. OpenStack, 2012, Quantum API Guide v1.0, available at: http://docs. openstack.org/api/openstacknetwork/1.0/content/index.html 2. IP Broadband Network Management, available at: http://www.ericsson. com/ourportfolio/products/ ip-broadband-network-management

Telefonaktiebolaget LM Ericsson SE-164 83 Stockholm, Sweden Phone: + 46 10 719 0000 Fax: +46 8 522 915 99 ISSN 0014-0171 Edita Västra Aros, Västerås