Communications as a cloud service: a
Communications as a cloud service: a
Communications as a cloud service: a
Communications as a cloud service: a
Communications as a cloud service: a
Communications as a cloud service: a
new take on telecoms
new take on telecoms
new take on telecoms
new take on telecoms
new take on telecoms
new take on telecoms
new take on telecoms
44
Capillary networks – a smart way to get
Capillary networks – a smart way to get
things connected
things connected
12
Trusted computing for infrastructure
20
Wireless backhaul in future
heterogeneous networks
28
Connecting the dots: small cells shape
up for high-performance indoor radio
38
Architecture evolution for automation
Earlier this year, Ericsson launched its new vision: a Networked Society where every person and every indus-try is empowered to reach their full potential. Technology leadership is about realizing this vision. It’s about developing connectivity technology to make it an integral part of our daily lives, whether we’re at work, at school, at home, outside, on the way some-where or taking part in some event.
The aims of each individual or enter-prise vary widely; they want coverage, capacity, reliability, availability and resilience with an appropriate level of security. The one-size-fits-all network model no longer applies; network char-acteristics need to be tailored to users’ specific needs. With cloud technolo-gies, SDN and NFV as a foundation, the technological developments we are working on – in the move toward 5G – are based on providing connectivity to suit every different use case.
The traditional way of building ser-vices and applications by packaging functionality and data and inherently assuring security has worked well for services and applications made and delivered by just one vendor – some even benefiting from bundling with hardware. But this approach doesn’t lend itself to the creation of innovative solutions that provide benefit. Nor does it fit with reusability, fast time to mar-ket, and the use of generic hardware.
Instead, applications are being mashed together from lots of other internet services. However, the free-dom to innovate that this approach offers leads to security issues, which is one of our industry’s greatest chal-lenges. And as web services and pro-grammable routing technology are deployed on platforms that exploit vir-tualization, assuring security becomes trickier still.
In the face of such challenges,
trusted computing helps us to meet the evolving security requirements of
Ulf Ewaldsson
Chief Technology Officer Head of Group Function Technology at Ericsson
Deeper into the
Networked Society
users, businesses, regulators and infra-structure owners.
The developments that I would like to highlight relate to handling expected growth in traffic vol-umes, capacity and machine-type communication.
Building heterogeneous networks is an effective way of expanding networks to handle traffic growth. However, the additional small cells included in these networks need to be provided with flexible and cost-efficient backhaul. Our research shows that non-line-of-sight backhaul in licensed spec-trum is a future-proof technology in this area.
When it comes to capacity, one of the significant challenges is provid-ing radio capacity indoors. About 70 percent of all traffic is generated indoors, and our research has resulted in a novel small cell solution with a flexible radio architecture. We wanted to address the issue of indoor capacity from an ecosystem point of view, with an emphasis on cost control at every phase. From installation to operation, our aim was to create a special indoor small cell that works well in large buildings – a solution that would inte-grate smoothly with outdoor coverage.
Capillary networks offer a smart way to connect the Internet of Things, but they require some additional func-tionality. The use cases for machine-type communication vary greatly from one application to the next, and so rather than building systems with a one-size-fits-all approach, capillary networks will be designed to fit the application.
All of these developments lead to the establishment of a flexible network architecture set to satisfy the demands of every future use case. As always, I hope you enjoy our insights.
About 50 percent of all
sites will be connected with
microwave in 2019.*
4
Communications as a cloud service:
a new take on telecoms
Software as a service (SaaS) is a promising solution for overcoming the challenges of
implementing and managing new network technologies and services like voice over LTE (VoLTE). The SaaS approach can provide substantial savings in terms of cost and lead-time, and create a new source of revenue for service providers.
This article was originally published on July 22, 2014.
12
Capillary networks – a smart way to
get things connected
A capillary network is a local network that uses short-range radio-access technologies to provide local connectivity to things and devices. By leveraging the key capabilities of cellular networks – ubiquity, integrated security, network management and advanced backhaul connectivity – capillary networks will become a key enabler of the Networked Society..
This article was originally published on September 9, 2014.
20
Trusted computing for infrastructure
Modern internet services rely on web and cloud technology, and as such they are no longer independent packages with in-built security, but are constructed through the combination and reuse of other services distributed across the web. While the ability to build applications in this way results in highly innovative services, it creates new issues in terms of security. Trusted computing aims to provide a way to meet the evolving security requirements of users, businesses, regulators and infrastructure owners.
This article was originally published on October 24, 2014.
28
Wireless backhaul in future heterogeneous networks
Heterogeneous networks are an effective way of expanding networks to handle traffi c growth. However, the additional small cells included in heterogeneous networks need to be provided with backhaul – in a way that is fl exible and cost-effi cient. Our research shows that non-line-of-sight (NLOS) backhaul in licensed spectrum up to 30GHz is a future-proof technology for managing high volumes of traffi c in heterogeneous networks.
This article was originally published on November 14, 2014.
38
Connecting the dots: small cells shape up for
high-performance indoor radio
How do you design a small radio to fi t the interiors of large spaces, yet powerful enough to meet future requirements for indoor radio capacity? This was the question we asked ourselves when we began to develop a solution to provide high-capacity radio for indoor environments. This article was originally published on December 19, 2014.
46
Architecture evolution for automation
and network programmability
Automation and network programmability are key concepts in the evolution of telecom networks. Architecture designed with high degrees of automation and network programmability can rapidly adapt to emerging requirements, and as such improve operational effi ciency and time to market for new services.
This article was originally published on November 28, 2014.
To bring you the best of Ericsson’s research world, our employees have been writing articles for Ericsson Review – our communications technology journal – since 1924. Today, Ericsson Review articles have a two-to-fi ve year perspective and our objective is to provide you with up-to-date insights on how things are shaping up for the Networked Society. Address :
Ericsson
SE-164 83 Stockholm, Sweden Phone: +46 8 719 00 00 Publishing:
Ericsson Review articles and additional material are published on www.ericsson.com/review. Use the RSS feed to stay informed of the latest updates.
Articles are also available on the Ericsson Technology Insights app for Android and Apple devices. The link for your device is on the Ericsson Review website:www. ericsson.com/review. If you are viewing this digitally, you can:
download from Google Play or
download from the App Store
Publisher: Ulf Ewaldsson Editorial board:
Håkan Andersson, Hans Antvik, Ulrika Bergström, Joakim Cerwall, Stefan Dahlfort, Deirdre P. Doyle, Dan Fahrman, Anita Frisell, Jonas Högberg, Patrik Jestin, Magnus Karlsson, Cenk Kirbas, Sara Kullman, Börje Lundwall, Hans Mickelsson,Patrik Regårdh, Patrik Roséen and Gunnar Thrysin Editor:
Deirdre P. Doyle
[email protected] Contributors:
John Ambrose, Paul Eade, Nathan Hegedus, Ian Nicholson, Ken Neptune and
Birgitte van den Muyzenberg Art director and layout: Carola Pilarz
Illustrations: Claes-Göran Andersson Printer: Edita Bobergs, Stockholm ISSN: 0014-0171
Volume: 91, 2014 Communications as a cloud service: a Communications as a cloud service: a Communications as a cloud service: a Communications as a cloud service: a Communications as a cloud service: a Communications as a cloud service: a new take on telecoms new take on telecoms new take on telecoms new take on telecoms new take on telecoms new take on telecoms new take on telecoms 44 Capillary networks – a smart way to get Capillary networks – a smart way to get things connected things connected 12 Trusted computing for infrastructure 20 Wireless backhaul in future heterogeneous networks 28 Connecting the dots: small cells shape up for high-performance indoor radio 38 Architecture evolution for automation and network programmability 46
Communications as a cloud
service: a new take on telecoms
Modern mobile networks are complex systems built with an increasingly broad variety of technologies
to serve a wide base of devices that provide an ever-greater range of services. These developments
create interesting business opportunities for operators. But they also bring challenges, as new
technologies and new expectations need to be managed with the same staff and budget.
of multi-tenancy capabilities to NFV makes this approach particularly inter-esting for global operators, who have a presence in several countries and man-age a range of networks through various operating companies.
Apart from addressing the strain on internal resources, NFV opens up the opportunity for operators to provide ser-vices, like VoLTE, to other communi-cation service providers. By deploying the necessary IMS network functions for services in a central virtualized data center, and by adopting a SaaS model, operators can unlock the potential of their infrastructure beyond their own portfolios. Virtualized services can then be offered to smaller second and third tier affiliates or MVNOs at a lower cost, with reduced risk, and within a shorter time frame than is normally associ-ated with the introduction of new ser-vices using traditional telecom business models.
The SaaS business model allows an operator’s partners to circumvent lengthy hardware procurement cycles. This way, the burden of costs and com-plexities associated with owning a completely new and technologically advanced communications system can be removed. Simply by signing up as a tenant to the existing facilities of a host operator’s data center, partners will be able to provide services quickly and cost-efficiently.
Once in place, NFV provides a flexible telecom-grade platform on which a vari-ety of communication services can be offered to people and organizations, in a low-cost, low-impact fashion. Services can be quickly and easily trialed, launched, scaled up or down and decom-missioned in line with market demand, the billions of new connected devices
that are emerging to support applica-tions like smart homes and connected vehicles. In short, this is a complex eco-system based on constant development, which can be difficult to predict and consequently challenging to plan for and budget.
The introduction of 4G LTE net-works, for example, brought with it a major overhaul of voice services in core networks – in the move from circuit-switched to IMS. For many, especially niche operators, this type of technology upgrade threatens to stretch organiza-tional capabilities to the limit, even to the point where business profitability is at stake.
To counter this challenge, many oper-ators have turned to Network Functions Virtualization (NFV). By placing core networks in large concentrated data centers, NFV is a way to rationalize and simplify operations as well as speed-ing up innovation cycles1. The addition
BA RT J EL L EM A A N D M A RC VORW ER K
BOX A Terms and abbreviations ARPU average revenue per user
CRM customer relationship management CSCF Call Session Control Function HSS Home Subscriber Server IMS IP Multimedia Subystem LI Lawful Interception MRFP Media Resource Function Processor
MSC mobile switching center
MTAS Multimedia Telephony Application Server
MVNO mobile virtual network operator NFV Network Functions Virtualization
NPV net present value
O&M operations and maintenance OSS operations support systems OVF Open Virtualization Format P-CSCF proxy call session control function SaaS software as a service
SBG Session Border Gateway SLA Service Level Agreement SRVCC single radio voice call continuity TCO total cost of ownership VLAN virtual local area network VM virtual machine VoLTE voice over LTE Software as a service (SaaS)
is a promising solution for overcoming the challenges of implementing and managing new network technologies. The SaaS approach can provide substantial savings in terms of cost and lead time, and create a new source of revenue for those adopting the role of service provider.
This article shares some of the technical and economical insights and know-how gained from a proof of concept study conducted at Ericsson to explore the implementation of VoLTE as a service.
Why a new take on telecoms?
Today’s networks support several tech-nology generations, from 2G to 4G, and as research for 5G is well underway, the next generation is on the commer-cial horizon. The types of devices con-nected to networks vary from feature phones to smartphones and tablets to
presenting an operator-branded and guaranteed alternative to the many third-party over-the-top solutions that operate in both the consumer and enter-prise communication space.
Concept – heading for the clouds
Today, the purchasing process for a new IMS system can take several months from order placement to an opera-tional system. Once an order is placed, the network system vendor initiates the production process for the node. On completion, the node is then inte-grated and packaged together with the necessary software elements, tested, shipped, installed at the designated cen-tral office site, integrated into the net-work, tested again, accepted and finally put into operation. Once the system is functional the operator is responsible for operations and maintenance (O&M), often with the support of the vendor.
With a SaaS deployment, operators can purchase a virtualized IMS network slice that is custom-initialized for them in a large data center. Network slices can be tied into existing radio and packet core networks over a remote link – as
Figure 1 illustrates.
Working in this way, operators will no longer need to purchase, install or own any hardware, or invest in train-ing staff on a new system. The SaaS approach removes the need to manage software licenses, and reduces system integration from a complete IMS solu-tion to just the points of interconnect with the access network. Ownership and operational details are instead taken care of by the service provider and operators will pay as they go using sim-ple, predictable price models, such as a flat service fee per subscriber. The ben-efits: no large upfront investments, lim-ited technical and business risks, and much shorter time to revenue.
VoLTE as a service
In 2013, Ericsson’s R&D and IT divisions carried out a joint project to develop a proof of concept implementation for VoLTE as a service. The objective was to gain an understanding of the tech-nical and economic implications of offering a complex communications solution like VoLTE as a service. For tele-com applications, SaaS is a relatively new business model that needs to
Traditional node deployment Software as a service EPC IMS LTE RAN EPC IMS LTE RAN
FIGURE 1 The SaaS concept
Cloud-based multi-tenant VoLTE system Tenant X Tenant Y Tenant X Tenant Y HSS MSP PGM MTAS SCC-AS SBG P-CSCF CSCF BGCF ENUMDNS/ MRFP EMA MM BSS MSC-S MGCF SMS-C CRM MGw BGF EPC LTE BSS MSC-S MGCF SMS-C CRM MGw BGF EPC LTE
take into consideration the tough requirements of the underlying cloud infrastructure.
From the start of the project, it was clear that turning VoLTE as a service into a viable business proposition, with competitive price levels and sound mar-gins, would require the onboarding and serving of new tenants to be simple, effi-cient and easily repeated.
Through virtualization techniques, the hosting service provider can deploy multiple VoLTE systems on the same shared data center hardware, while still guaranteeing each tenant their own dedicated, logically separated vir-tual network. Such a multi-tenant cloud infrastructure makes it possible for ser-vice providers not only to share hard-ware among tenants, but also O&M and engineering staff. The resulting econ-omy of scale is much more significant than any individual small-scale instal-lation could achieve.
To improve repeatability, a high degree of business process automation (auto-deployment and auto-scaling) reduces the time and effort needed to operate services, which in turn reduces costs. And to ensure that customers get what they pay for, the provision of rel-evant network statistics is essential for billing and to provide proof of Service Level Agreement (SLA) conformance.
A blueprint for the architecture
So how is this done? As shown in
Figure 2, the operator’s radio and packet core networks as well as their legacy circuit-switched network are connected to a remote virtualized IMS network within a cloud data center over standardized interfaces for signaling, O&M and media.
As illustrated in Figure 3, next gen-eration systems will normally be fully implemented as software without any strong hardware dependencies. Consequently, IMS server-type network functions like CSCF and MTAS are natu-ral candidates for cloud placement.
To optimize use of bandwidth, most media handling will most likely con-tinue to take place in the tenant net-work, with the possible exception of the MRFP. Certain network functions, such as HSS, can be placed either in the cloud or in the tenant network, depending on operator preference or to comply with
Core router Edge router EMS Hosted managed services Control plane elements, CSCF, MSC
Gateways and appliances
Home networking Fixed access Radio access OSS, BSS Distributed cloud
Real time OSS/BSS
Media distribution network
Home appliances Value High Low Low High Risk
(Technology maturity, performance requirements)
FIGURE 3 Network Functions Virtualization – portfolio migration
Tenant 1 network Tenant 1
network Tenant 1 IMS networkTenant 1 IMS network
O&M O&M Signaling Signaling Media Media O&M O&M Signaling Signaling Media Media
Tenant 2 IMS network Tenant 2 IMS network NOC
NOC
O&M
O&M StorageStorage
Central storage AccessAccess AccessAccess CoreCore Tenant 1Tenant 1 Tenant 2Tenant 2 Tenant 2 network Tenant 2 network vRtr vRtr SBG SBG DC switch /FW DC switch /FW vRtr vRtr vRtrvRtr CSCF clusterCSCF
cluster clusterclusterHSSHSS clusterclusterMTASMTAS PGMPGM IDNSIDNS MFRPMFRP
vRtr
vRtr vRtrvRtr vRtrvRtr
CSCF clusterCSCF
cluster clusterclusterHSSHSS clusterclusterMTASMTAS PGMPGM iDNSiDNS MFRPMFRP
local regulatory requirements with respect to user databases.
To integrate with the operator’s vari-ous business support, customer care and other IT systems, the virtualized IMS network will provide billing and provi-sioning capabilities.
When another operator becomes a tenant, a copy of the virtualized IMS network can be instantiated in the data center and the whole onboarding pro-cess simply repeated.
For commercial deployment, at least two data center locations are needed to provide geo-redundancy. Alternatively, the tenant could operate a single non-redundant system in their own network and rely on a secondary virtualized sys-tem as an overflow and failover mech-anism – geo-redundancy as a service.
As an additional offering, service pro-viders can include smaller regional sat-ellite sites that host the IMS media plane nodes. In such topologies, the satellite centers can be used to house not just media gateways but also network func-tions like Lawful Interception for IMS (LI-IMS), an anchor MSC for SRVCC and /or an SBG/P-CSCF. Providing media-plane nodes in this way reduces the impact of introducing IMS to an opera-tor’s existing core network to practically nothing. Taking a coverage area the size of North America as an example, approximately 24 regional sites would be required to provide this service.
A significant change
By the end of December 2015, roaming fees within the European Union will no longer exist; rates for voice calls and data transmission will be the same as in the subscriber’s home market2. This
drastic change for consumers is likely to stimulate traffic and motivate oper-ators across Europe to centralize their core network infrastructures – as phys-ical location will no longer influence billing rates.
Hardware
From a hardware perspective, data centers will need to be equipped with enough servers to host virtualized ver-sions of the number of tenant IMS net-works anticipated. In addition, high capacity physical IP switches and cen-tral storage will be needed. As hardware is completely decoupled from software
through virtualization middleware, service providers have the freedom to select the x86-based hardware of their choice, as long as it meets the set target specifications in terms of performance, bandwidth and memory of the virtu-alized network functions – including some virtualization overhead.
Operations and maintenance
As shown in Figure 4, the IP plan needs to be designed so that each tenant has their own set of dedicated VLANs – at least for O&M, signaling and media – that are separated from all the other tenants to avoid interference and main-tain security.
For O&M, the service provider’s back office can perform tasks such as con-figuration management, performance management, fault management and network inventory management through a managed services portal. This is similar to the way network man-agement works in the service provid-er’s own IMS network. The front office can process work orders and change requests received from tenants, tickets from field engineers, and take care of invoicing and SLA reporting.
As shown in Figure 5, tenants will be provided with O&M access rights to their specific network for provision-ing subscribers and retrievprovision-ing detail records for charging. This access will connect to the tenant’s back-end IT sys-tems like CRM and billing syssys-tems, and a dashboard function will allow the ten-ant to view key performance statistics for their network.
Northbound interfaces from the different virtualized network func-tions are generally not affected by virtualization.
The exact implementation of the IMS network – its internal structure, what software and which release is used – is entirely at the discretion of the service provider. In other words, the imple-mentation is transparent and of no real concern to the tenant. Their only con-cern lies with the behavior of the ser-vice, the agreed service level and the interfaces exposed at the points of interconnection.
Features – under the hood Multi-tenancy
Modern server blades house multiple processor cores on which virtual
Network management Node manager OS Hypervisor Hardware
Dashboard Mediation activationService
DC back office NOC front office Tenant
Tenant provisioning
vIMS Cloud manager, including:
• SLA resolution • Auto-deployment • Auto-scaling
CDRs Work orders, tickets, and change requests
SLA report, invoicing Subscriber data Subscriber provisioning Subscriber billing SLA monitoring, service metering TM CM PM FM NIM
FIGURE 5 Operations and maintenance view
BOX B Legend for Figure 5 CM – configuration management DC – data center FM – fault management NIM – network inventory management NOC – network operations center PM – performance management TM – ticket management
machines (VMs) can be placed. Virtualized IMS network functions like CSCF or HSS use a number of vir-tual machines for traffic processing, as shown in Figure 6, which act much like a physical node with several blades as part of a cluster. As illustrated, these virtual machines should be spread hor-izontally over multiple blades, so that the failure of one blade will never bring down an entire node.
The remaining cores can then be used for other network functions or even other tenants.
Auto-deployment
Onboarding a new tenant sets a deploy-ment function into motion. As shown in
Figure 7, this function executes an IMS network deployment sequence using a cloud orchestration tool in combination with scripts that parse the customer-specific environment settings. Any nec-essary adaptations are executed inside the deployed VMs.
To save time during the onboarding process, tenant VLANs can and should be prepared ahead of time. Software images for each virtualized network function are built and uploaded (in advance) to the cloud manager in, for example, Open Virtualization Format (OVF)3, and are kept in storage. From
there, the deployment function can instantly clone network functions for new tenants.
To connect them to their pre-assigned VLANs, the virtual machines are linked to the appropriate port groups and pow-ered on. The deployment function loads a data transcript onto the VMs to cre-ate an operational virtualized network function and configures the application interfaces, so that they form an inte-grated IMS network. All of this post-con-figuration work can be scripted; and any data transcript common to all tenants can be included in the software image.
Once all the network functions and connections between them are estab-lished, the next step is to connect the vir-tual IMS network to the tenant’s access network and IT systems before provi-sioning the first users. The high degree of preparation and process automa-tion, together with the use of hardware capacity available in the data center, and prestorage of software images, results in drastically reduced installation times. The complete software installation for an IMS network can be fulfilled in just a few hours, compared with the several days it would normally take to set up a traditional central office environment with physical nodes. Time to revenue from contract signing to commercial launch could be reduced to a matter of weeks, rather than months.
Auto-scaling
The ability to scale networks is a key business enabler. In the proof of con-cept project, the Ericsson team devel-oped a controller function that worked in conjunction with the cloud manager to determine when and where networks need to be scaled. As shown in Figure 8, the controller continuously monitors the average processor load on each of the virtualized network functions, by reading the load figures from the guest operating system. This approach has proven to be more accurate than using the measurements provided by the hypervisor, as the hypervisor cannot, for example, determine the priority and necessity of currently executed tasks from the outside.
When the load for a particular net-work function like CSCF exceeds its set upper limit, which can happen for example during traffic peaks, the con-troller requests the cloud manager to scale out. The cloud manager pow-ers up another CSCF virtual machine,
2. Post-config DNS/ ENUM HSS HSS EMA MTAS MTAS CSCF Deployment function Cloud manager CSCF vAPP HSS vAPP CSCF vRouter vRouter vRouter 1. Clone from template FIGURE 7 Auto-deployment VM VM (CSCF) (HSS) (MTAS) vRouter vRouter vRouter vRouter vRouter vRouter vRouter vRouter vRouter VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM (DNS) (PGM) (MRFP) VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM VM Hyp
Hyp Hyp Hyp Hyp Hyp Hyp Hyp Hyp Hyp Hyp Hyp
#2 #1 #3 #4 #5 #6 #7 #8 #9 #10 #11 #12 HW Tenant Z Tenant Y Tenant X 12 blades FIGURE 6 Multi-tenancy
which then joins the existing cluster and rebalances the traffic. Similarly, a node can be scaled in during periods of low traffic.
The user interface for the controller allows engineering staff in the data cen-ter to set upper and lower processor-load thresholds for scaling in and out of net-work functions. Additional parameters, such as the minimum and maximum number of traffic processors, can also be set so that a node has a guaranteed minimum redundancy without monop-olizing more than its fair share of avail-able resources.
Figure 9 shows an example time series taken from a test session carried out during the proof of concept project. The scaling mechanism for the CSCF kicked in just before the 12:58 time stamp, as the processor load exceeded the set maximum (indicated by the red line). Three minutes later, at approxi-mately 13:01, the CSCF was running on a cluster of five instead of the original four traffic processors.
Depending on the existing traffic load, it takes between five and 10 min-utes to add capacity automatically (by scaling a virtualized network func-tion out by one traffic processor) to a live node in a virtualized data center. In contrast, adding a physical hardware board to a live physical node on such a time scale is unimaginable.
Service-level monitoring
SLAs are highly varied in nature, cover-ing different aspects of a service such as customer ticket turn-around times and other logistical matters. As far as techni-cal content is concerned, SLAs between service providers and tenants are best kept simple and transparent. Many net-work statistics can be made available for information purposes, which is fine, but the list of contracted KPIs that carry financial implications are best kept as simple as possible (see Table 1).
In its simplest form, billing ten-ants for the use of VoLTE as a service can be based on the actual number of active users during a given time period – assuming a certain maximum traf-fic volume. The volume can be defined in terms of the maximum number of simultaneous sessions (the current licensing model) or by average voice minutes per subscriber. As voice
100
12:42 12:44 12:46 12:48 12:50 12:52 12:54 12:56 12:58 13:00
Time: 13:00:44 Finished scaling out Number of TPs: 5 51 PL 7 PL 8 PL 6 PL 5 PL 4 PL 3 52 50 49 38 off Processor load (%) % 80 60 40 20 0 CSCF-CBA-012 load Number of traffic processors
Time
FIGURE 9 Example time series
Table 1: SLA reporting
Service Metering
Tenant gets billed per number of users + premium for traffic coverage
Service Level Monitoring
Tenant gets credited in case of failure to meet SLA
Key performance indicators Key performance indicators
Number of users
System availability (%) IMS registration time (msec) Traffic volume
(average session duration and/or number of concurrent sessions
IMS registration success ratio (%) VoLTE setup success ratio (%)
1. Measure load 3. Join cluster 2. Power on VM Controller Cloud manager CSCF CSCF CSCF vRouter FIGURE 8 Auto-scaling
minutes readily translate to the pay-ment plans offered by most operators, this model is probably preferable for the majority of tenants. Similar consump-tion indicators aligned with operator-to-consumer price models can be created for all other services.
While threshold limits are good for SLAs and planning, service providers are not likely to cut off traffic when an agreed maximum for a tenant is reached – as long as continued service does not overload the system or infringe on other tenants. However, a premium may be charged.
To keep service level monitoring rela-tively straightforward, the proof of con-cept project created example reports for system availability, registration time, registration success rate and call estab-lishment success rate. If any of these
resources underperformed during a billing period, the tenant would receive credit on their next payment.
All of these counters and statistics are already available in today’s typical IMS products. By collecting, filtering and combining them into a customized business intelligence report, they can be easily communicated and turned into actionable data.
In a commercial setup, this data would be fed from the OSS into a spe-cialized SLA management tool, in which KPI values are continuously compared against predefined thresholds to detect and record SLA violations. A number of approach warning levels are usually defined below the critical level, so that O&M staff can be alerted and take appro-priate actions before any impact on busi-ness is felt.
Financials – where is the money?
In the traditional system-sales model, total cost of ownership (TCO) is defined as the initial purchase price including related project costs, plus recurring run-ning costs such as support agreements, O&M staff, rent and power. In the SaaS model, this will be replaced by a single line item – service fees – under opex. Unfortunately, estimating a reason-able price level for VoLTE as a service – one that the tenant can afford and that keeps the service provider in business – is not a simple task.
One potential pricing model (shown in Figure 10) is based on the tradi-tional total cost of ownership for a three-year period, amortized over 36 equal monthly payments. Payback times of less than three years tend to result in a service that is too expensive for the ten-ant, and calculating over longer periods tends to make the model unattractive for service providers.
Parameters like operator size and running costs – rents, engineer salaries and electricity – vary greatly from one part of the world to another, and so the economy of scale and benefit to opera-tors in different markets will vary. In conjunction with the proof of concept project, a study aimed to estimate the service price for VoLTE for a typical sec-ond or third tier operator with between 100,000 and one million subscribers.
The study estimated and adjusted for net present value (NPV) and the required initial capex and opex over three years to own, deploy and run an IMS system for VoLTE. The resulting estimation set the fee for VoLTE as a service to be some-where between USD 1 and USD 5 per subscriber per month. An example of the type of calculation used in the study is given in Table 2 for a mock tenant with 200,000 subscribers.
To match the price points for a ser-vice with the average cost per subscriber incurred by operators at different ends of the scale, some sort of tiered price model is needed – a suggested model is shown in Figure 11.
If the average revenue for voice ser-vices is assumed to be USD 40 per sub-scriber per month, a fee of USD 1-5 per subscriber per month for VoLTE as a ser-vice is between 2.5 and 12.5 percent of the corresponding ARPU it generates, which is a fair business case.
opex
opex
opex
capex 3-year system TCO
(amoritized over 36 months)
Year 1 Year 2 Year 3
FIGURE 10 Pricing model
Table 2: TCO comparison – an example in USD thousands
system capex opex as a service capex opex
Hardware 2,400 1,000 Setup fee 450
Software 3,300 2,500 Service fee* 24,098
Systems Integration 1,600 Project 900 Staff 4,300 Facilities 500 Utilities 200 Lab costs 5,000
3 year TCO 21,700 3 year TCO 24,548
NPV 20,791 NPV 20,791
Looking at the addressable market, the number of subscribers connected to second and third tier operators amounts to 22 million in North America alone.
Evolution – beyond the horizon
As illustrated in Figure 12, rolling out VoLTE might be the initial motiva-tion for a second or third tier operator to switch to the software as a service model. Doing so would allow such oper-ators to roll out VoLTE in the same time frame (2014-2015) as their larger com-petitors – and secure their market share.
Subsequently, operators could broaden the scope of their offerings to include customized services for enter-prises, the retail industry and many other verticals. The SaaS platform could be further utilized by opening it up to internet-application and web develop-ers to create a whole new range of con-verged services.
Second and third tier operators are the most obvious first adopters of this type of business model for voice – or rather VoLTE. Once rooted, adoption is likely to rise up the food chain. Many operators, both big and small, have opted for the managed service approach for their voice networks, gaining effi-ciency and freeing up resources to focus on customers and on improving opera-tor brand value.
Operators already include unlimited voice and unlimited text in their data plans, rendering these services to the level of a commodity, or a fundamental product that cannot really be charged for, but neither can they be taken out of the service offering. And so software as a service – the ultimate form of a man-aged service – is the most natural evo-lution path.
Conclusion
By following this route, service provid-ers will be able to offer all managed networks from the same platform and housed under the same roof. For opera-tors, the ability to outsource the respon-sibility for voice shifts price pressure on to a third party who can provide the right expertise, efficiency and scale.
The author bios for Bart Jellema and Marc Vorwerk can be found on page 19
6
Price point in USD
5 4 3 2 1 0 1–100 101–200 201–500 501–1000 1000+ Thousands of subscribers
FIGURE 11 Tiered price model
Mobile Enterprise Cable/internet
Capture VoLTE-aaS RCS-aaS BusCom-aaS VisualCom-aaS UC-aaS WebRTC Service enablement Grow Innovate
FIGURE 12 Service evolution
1. Ericsson, February 2014, White Paper, The real-time cloud – combining cloud, NFV and service provider SDN, available at:
http://www.ericsson.com/news/140220-the-real-time-cloud_244099438_c 2. European Commission, Digital agenda for Europe, Roaming, available at:
https://ec.europa.eu/digital-agenda/en/roaming 3. DMTF, Open Virtualization Format, available at:
http://www.dmtf.org/standards/ovf References
ETSI, Network Functions Virtualisation, available at: http://www.etsi.org/ technologies-clusters/technologies/nfv Additional reading BOX C Legend for Figure 12 aaS – as a service BusCom – business communication RCS – Rich Communication Suite UC –unified communication VisualCom – visual communication WebRTC – Refers to standardization for real-time browser capabilities.
Capillary networks – a smart
way to get things connected
A capillary network is a local network that uses short-range radio-access technologies to provide
groups of devices with connectivity. By leveraging the key capabilities of cellular networks – ubiquity,
integrated security, network management and advanced backhaul connectivity – capillary networks
will become a key enabler of the Networked Society.
requirements is a prerequisite for the MTC business case.
Cellular communication technolo-gies are being enhanced to meet these new service requirements3,4. The
power-save mode for example, introduced in the most recent release (Rel-12) of LTE, allows a sensor that sends hourly reports to run on two AA batteries for more than 10 years, and simplified signaling procedures can provide additional bat-tery savings5. Rel-12 also introduces a
new LTE device category, which allows LTE modems for connected devices to be significantly less complex and cheaper than they are today – the LTE features proposed in 3GPP reach complexity lev-els below those of a 2G EGPRS modem6.
In addition, 3GPP has identified ways to increase the coverage of LTE by 15-20dB. This extension helps to reach devices in remote or challenging locations, like a smart meter in a basement 6.
Capillary networks and the short-range communications technologies that enable them are another key devel-opment in the Networked Society: they play an important role providing con-nectivity for billions of devices in many use cases. Examples of the technologies include Bluetooth Low Energy, IEEE 802.15.4, and IEEE 802.11ah.
This article gives an overview of the significant functionality that is needed to connect capillary networks, includ-ing how to automatically configure and manage them, and how to provide end-to-end connectivity in a secure manner.
Capillary networks
The beauty of short-range radio technol-ogies lies in their ability to provide con-nectivity efficiently to devices within a and the elderly can get assistance
through remote monitoring – again using resources in an intelligent way – which improves the reach of health care services, reduces the need for, say, physical day clinics and cuts the need for patients to travel.
As a whole, communication is pro-gressively shifting from being human-centric to catering for things as well as people. The world is moving toward machine-type communication (MTC), where anything from a smart device to a cereal packet will be connected; a shift that is to some extent illustrated by the explosive growth of the Internet of Things (IoT).
However, the requirements created by object-to-object communication are quite different from those of current systems – which have primarily been built for people and systems to com-municate with each other. In scenar-ios where objects communicate with each other, some use cases require bat-tery-operated devices; therefore, low energy consumption is vital. Bare-bones device architecture is essential for mass deployment; typically the data rate requirements for small devices are low, and the cost of connectivity needs to be minimal when billions of devices are involved. Meeting all of these new
JOACH I M SACH S, N ICK L A S BEI JA R, PER EL M DA H L , JA N M E L EN, FR A NCESCO M I L ITA NO A N D PAT R I K SA L M EL A
BOX A Terms and abbreviations CoAP Constrained Application Protocol EGPRS enhanced general packet radio service eSIM embedded SIM card
GBA Generic Bootstrapping Architecture IoT Internet of Things
MTC machine-type communication M2M machine-to-machine OSPF Open Shortest Path First SLA Service Level Agreement TLS transport layer security People and businesses
everywhere are becoming increasingly dependent on the digital platform. Computing and communication are spreading into every facet of life with ICT functionality providing a way to manage and operate assets, infrastructure, and commercial processes more efficiently. The broad reach of ICT is at the heart of the Networked Society, in which everything will become connected wherever connectivity provides added value1,2.
Ubiquitous connectivity and the Networked Society
Connectivity in the Networked Society is about increasing efficiency, doing more with existing resources, provid-ing services to more people, reducprovid-ing the need for additional physical infra-structure, and developing new services that go beyond human interaction. For example, smart agricultural systems monitor livestock and crops so that irri-gation, fertilization, feeding and water levels can be automatically controlled, which ensures that crops and livestock remain healthy and resources are used wisely. In smart health care, patients
specific local area. Typically, these local – or capillary – networks need to be con-nected to the edge of a communication infrastructure to, for example, reach service functions that are hosted some-where on the internet or in a cloud.
Connecting a capillary network to the global communication infrastructure can be achieved through a cellular net-work, which can be a wide-area network or an indoor cellular solution. The gate-way between the cellular network and the capillary network acts just like any other user equipment.
The architecture, illustrated in
Figure 1, comprises three domains: the capillary connectivity domain, the cel-lular connectivity domain, and the data domain. The first two domains span the nodes that provide connectivity in the capillary network and in the cellular network respectively. The data domain spans the nodes that provide data pro-cessing functionality for a desired ser-vice. These nodes are primarily the connected devices themselves, as they generate and use service data though an intermediate node, which like a cap-illary gateway, would also be included in the data domain if it provides data pro-cessing functionality (for example, if it acts as a CoAP mirror server).
All three domains are independent from a security perspective, and so end-to-end security can be provided by linking security relationships in the dif-ferent domains to one another.
The ownership roles and business scenarios for each domain may differ from one case to the next. For exam-ple, to monitor the building sensors of a real estate company, a cellular operator might operate a wide-area network and possibly an indoor cellular network, as well as owning and managing the cap-illary network that provides the sensors with connectivity. The same operator may also own and manage the services provided by the data domain and, if so, would be in control of all three domains. Alternatively, the real estate company might own the capillary network, and partner with an operator for connectiv-ity and provision of the data domain. Or the real estate company might own and manage both the capillary network and the data domain with the operator pro-viding connectivity. In all of these sce-narios, different service agreements are
needed to cover the interfaces between the domains, specifying what function-ality will be provided.
Like most telecom networks, a capil-lary network needs a backhaul connec-tion, which is best provided by a cellular network. Their quasi-ubiquitous cover-age allows backhaul connectivity to be provided practically anywhere; simply and, more significantly, without instal-lation of additional network equipment. Factoring in that a capillary network might be on the move, as is the case for monitoring goods in transit, leads to the natural conclusion that cellular is an excellent choice for backhaul.
In large-scale deployments, some devices will connect through a capil-lary gateway, while others will con-nect to the cellular network directly. Regardless of how connectivity is pro-vided, the bootstrapping and man-agement mechanisms used should be homogeneous to reduce implementa-tion complexity and improve usability.
Smart capillary gateway selection
Ideally, any service provider should be able to deploy a capillary network, including device and gateway configura-tion. For this to be possible, deployment needs to be simple and use basic rules
– circumventing the need for in-depth network planning. To achieve this, a way to automatically configure connec-tivity is needed.
When deploying a capillary network, a sufficient number of capillary gate-ways need to be installed to provide a satisfactory level of local connectivity. Doing so should result in a certain level of connectivity redundancy – a device can get connected through several dif-ferent gateways. Some systems (such as electricity meter monitoring) need to be in operation for years at a time, during which the surrounding environment may change; nodes may fail, additional network elements may be added, and even the surrounding physical infra-structure can change. But, by allowing the capillary network configuration to change, some slack in maintaining con-stant connectivity is built into the sys-tem, which allows it to adapt over time.
The key to maintaining connectiv-ity and building flexibilconnectiv-ity into con-nected systems lies in optimal gateway selection. The decision-making process – what gateway a device chooses for con-nectivity – needs to be fully automated and take into consideration a number of network and gateway properties. Network parameters – such as the
Cellular access Mobile network M2M/IoT cloud Capillary network Capillary gateway Data domain
Capillary connectivity domain Cellular connectivity domain Connected
devices
requires all of the capillary gateways to communicate with a single point.
Managing QoS across domains
The QoS requirements for machine-type communication are typically dif-ferent from those used for traditional multimedia communication in terms of bandwidth, latency and jitter. For MTC, the requirement is often for guar-anteed network connectivity with a minimum throughput, and some use cases may include stricter constraints for extremely low latency.
For example, a sensor should be able to reliably transmit an alarm within a specified period of time after the detec-tion of an anomaly – even if the network is congested. To achieve this, low laten-cies are needed for real-time monitor-ing and control, while the bandwidth requirements for this type of scenario tend to be low. That said, QoS require-ments for machine-type communica-tion can vary tremendously from one service to another. In some cases, like surveillance, the QoS requirements are comparable to those of personal multi-media communication.
QoS needs to be provided end-to-end. So for the capillary network case, the distinct QoS methods of both the short-range network and the cellular net-work need to be considered. Each type of short-range radio technology provides different methods for QoS, which can be divided into two main groups: prior-itized packet transmission (for example, in 802.11) and bandwidth reservation (for example, in 802.15.4 and Bluetooth Low Energy). As short-range technolo-gies work in unlicensed spectrum, the level of interference at any given time is uncertain, which limits the level of QoS that can be guaranteed. QoS methods for the cellular networks that provide connectivity, however, are well estab-lished and are based on traffic separa-tion with customized traffic handling. To provide QoS end-to-end, a bridge is needed between the QoS domains of the capillary and cellular networks. This bridge specifies how traffic from one domain (through a domain specific QoS treatment) is mapped to a specific QoS level in the other. The specifics of the QoS bridge are determined in a Service Level Agreement (SLA) established between the providers of the capillary quality of the cellular radio link and
the load in the cellular cell that a gate-way is connected to – fluctuate, and so a given capillary gateway will provide different levels of backhaul connec-tivity at different times. Other consid-erations, like the amount of power a battery-operated gateway has left, have an impact on which gateway is opti-mal for a given device at a specific point in time. Consequently, optimal gate-way selection should not be designed to balance load alone, but also to min-imize delays, maxmin-imize availability and conserve power. The gateway selec-tion mechanism should support device reallocation to another gateway when the properties or the connectivity to a gateway change. By designing gateway selection to be smart, flexibility in con-nectivity is inbuilt, allowing systems to continue to function as the environ-ments around them evolve.
As illustrated in Figure 2, gate-way selection relies on three different types of information: connectivity, con-straints and policy.
Connectivity information describes the dynamic radio connectivity between devices and gateways. Devices typically detect connectivity by listen-ing to the beacon signals that gateways transmit. Some capillary short-range radio technologies allow connectivity to be detected by the gateway.
Constraint information describes the dynamic and static properties of the net-work and the gateways that are included in the selection process. Properties such as battery level, load level (which can be described by the number of connected devices per gateway), support for QoS, cost of use, and sleep schedule are all included. The cellular backhaul connec-tivity of a gateway, such as link qual-ity, can also be included, and future enhancements might include proper-ties such as cell load – obtained from the management system of the cellular net-work. Devices may provide additional constraint information, such as device type, battery level, QoS requirements and capillary network signal strength.
Policy information determines the goal of gateway selection. A policy might be a set of weightings or priorities that determine how the various constraint parameters affect the best choice of gateway. Policy information may also
include requirements set by the man-agement system, such as allowing cer-tain types of device to always connect to given gateways. Policies are static and are defined by network management.
The process of gateway selection includes the following phases:
the information regarding connectivity, constraints, and policy is gathered by the element making the selection; the gateway selection algorithm applies the policies to the constraints while taking connectivity into consideration and determines the optimal gateway; once a gateway has been selected for each device, the selection is implemented, which may imply that a device needs to switch gateway; and when a device moves to another gateway, new routes to the device must be set up in the cellular network so that the incoming traffic is routed correctly.
The selection process can be controlled at various locations in the network. The location of control in turn affects the need to transport information concern-ing constraints, policies and connectiv-ity to the control point and to signal the selection to devices.
If the control point is located in the connected device, the device performs the selection autonomously through local computation based on information sent by the gateway. As devices have just a local view of the network, it may not always be possible to optimize resources globally and balance load across a group of gateways.
If the control point is located in the capillary gateways, the gateways need to communicate with each other and run the selection algorithm in a distributed manner. This implies that gateways are either connected via the capillary net-work, via the mobile network or via a third network such as Wi-Fi, and use a common protocol, like OSPF, for data distribution. The main challenge here is to reach convergence quickly and avoid unnecessary iteration due to changes in topology.
Alternatively the control point could be a single node in the network that col-lects the entire set of available informa-tion. This centralized method enables resource usage to be optimized globally across the entire network. However, it increases communication needs, as it
network domain and the cellular con-nectivity domain, or between the ser-vice owner (in the data domain) and the connectivity domain providers.
Security for connected devices
The devices deployed in capillary net-works are likely to vary significantly in terms of size, computational resources, power consumption and energy source. This variation makes implementing and deploying security measures chal-lenging. Security in capillary networks, or within MTC in general, does not fol-low a one-size-fits-all model because the constrained devices in the capillary network are just that: constrained. It is probably not possible to apply a generic security solution: even if such a solution ensures security in the most demanding of scenarios, highly- constrained devices will probably not have the resources to implement it. What is needed is a secu-rity solution that fulfills the secusecu-rity requirements of the use case at hand.
For example, a temperature sen-sor installed in a home is unlikely to have the same strict security require-ments as, say, a pacemaker or a sensor in a power plant. A successful attack on any one of these three use cases is likely to yield drastically different con-sequences. So risk needs to be assessed in the development of security require-ments for the specific scenario, which
in turn determines what security solu-tions are suitable. The choice of a suit-able security solution may then impact the choice of device hardware, as it needs to be capable of implementing the selected security solution.
For end-to-end protection of traf-fic between authenticated end-points, widely used security mechanisms such as TLS would improve interoperabil-ity between constrained devices and services that are already deployed. In some cases, there might be a need for more optimized security solutions to be deployed, such as by using a protocol that entails fewer round-trips or incurs less overhead than legacy solutions.
Identification
When a device is installed in a capil-lary network, in most cases it needs to possess some credentials – that is to say an identity and something it can use to prove it owns the identity, such as a key. Typical solutions include public key certificates, raw public keys or a shared secret. With its stored credentials, the device needs to be able to authenticate itself to the services it wants to use – such as a management portal through which the device is managed, a data aggregation service where the device stores its data, as well as the capillary gateway, which provides the device with global connectivity.
One way to implement device iden-tification and credentials is to use the same method used in 3GPP networks – basically the 3GPP subscription cre-dentials. The subscription identity and a shared secret that can be used for authentication in 3GPP networks are stored on the SIM card of the device. In addition to using the credentials to get network access, they can also be used for authenticating the device to vari-ous services in the network. This can be done using the 3GPP-standardized Generic Bootstrapping Architecture (GBA). For MTC scenarios, GBA is a good solution, as it provides strong identifi-cation and communiidentifi-cation security without requiring any user interaction or configuration at the device end; the security is based on the 3GPP creden-tials stored in a tamper-resistant envi-ronment, to which not even the user has direct access.
To apply GBA, first of all the device needs to have 3GPP credentials; and then the 3GPP network, the desired ser-vice as well as the deser-vice itself all need to support GBA. Unfortunately, many capillary network devices do not pos-sess 3GPP credentials, which limits the use of GBA to capillary gateways. In such cases, the gateway can provide GBA-based authentication and security for services on behalf of the entire capillary network, but device authentication
FIGURE 2 Smart capillary gateway selection
M2M/IoT cloud 3. Policies
1. Constraints 2. Radio connectivity
4. (Re-) select gateway and control communication path
Capillary gateway selection Capillary gateway selection Mobile
network networkMobile
New communication path
Old communication path
Capillary gateways Connected devices M2M/IoT cloud Capillary gateways Connected devices
still needs to be performed between the device and the service.
Security domains
Capillary networks have two distinct security domains, as illustrated in
Figure 3: the capillary devices and the capillary gateway that provides wide-area connectivity. The security domain for devices can further be split into con-nectivity and data domains. The data domain incorporates the device and the services it uses, such as manage-ment and data storage, and the connec-tivity domain handles the interaction between the device and the capillary gateway.
The security domain for the capillary gateway is based on the 3GPP tion and the security that the subscrip-tion credentials can provide for access services and 3GPP-aware services; for example, through the use of GBA.
The two security domains intersect at the capillary gateway; there is a need for mutual trust and communication security between the device and the
gateway. At this intersection there is an opportunity to apply the strong identifi-cation and security features of the 3GPP network for the benefit of the capillary device. If strong trust exists between the device and the capillary gateway, the security domains can be partially merged to provide the device with 3GPP-based security for the GBA-enabled ser-vices it uses.
Bootstrapping
When a device is switched on or wakes up, it may be able to connect to a num-ber of capillary gateways, possibly pro-vided by different gateway operators. The device needs to know which gate-way it has a valid association with and which it can trust. Once global connec-tivity has been established, the device also needs to know which services to connect to. Capillary devices will be deployed in the thousands, and as a con-sequence of their bare-boned architec-ture, they do not tend to be designed with easy-to-use user interfaces. Manual configuration of massive numbers of
capillary devices has the potential to be extremely time consuming, which could cause costs to rise.
Bootstrapping devices to their ser-vices using a bootstrap server is one way of automating configuration and avoiding the manual overhead. Such a service, which could be operated by the device manufacturer, would ensure that the device is redirected to the selected management service of the device owner. During the manufacturing process, devices can be pre-configured with information about the bootstrap server, such as how to reach it and how to authenticate it. When switched on or upon waking up, the device will connect to the bootstrap server, which helps it to find its current home.
If a device gets corrupted, or for some reason resets itself, it can – once rebooted – use the bootstrap server to reach its current management portal. From the management portal, either the device owner or an assigned man-ager can configure the device with the services it should use – and possibly even provide the service specific credentials to the device. This approach removes the need to individually configure each device, and can instead provide a cen-tralized point for managing all devices, possibly via batch management.
The ability to remotely manage devices becomes significant when, for example, 3GPP subscription informa-tion needs to be updated in thousands of deployed devices. Today, 3GPP creden-tials tend to be stored on a SIM card, and updating this information typi-cally requires replacing the SIM card itself. Embedded SIM cards (eSIM) and SIM-less alternatives are now being researched. While eSIM is a more MTC-friendly option, as it allows for remote management of subscription informa-tion, SIM-less is of most benefit to con-strained devices, to which adding a SIM is an issue simply because they tend to be quite small.
Network management
A range of tasks, such as ensuring auto-matic configuration and connectivity – for devices connected through a capil-lary network – are fulfilled by network management. In addition, network management needs to establish access control restrictions and data treatment
Mobile network Alternative M2M/IoT cloud Capillary network Capillary gateway
Capillary gateway security domain Capillary device security domain
Connectivity security domain Data security domain
Connected devices
Trust/business relationship GBA-based security
End-to-end security solution
rules for QoS based on SLAs, subscrip-tions and security policies. In addition, a service provider should be able to use the management function to adapt ser-vice policies and add or remove deser-vices.
By nature, connected devices are rudi-mentary when it comes to manual inter-action capabilities. Additionally, the fact that service providers tend to have no field personnel for device management implies that a remote management and configuration interface is needed to be able to interact with deployed devices.
Network management of connected devices in capillary networks poses new challenges compared with, for example, the management of cellular networks. This is partly due to the vast number of devices, which are orders of magnitude larger than the number of elements handled by today’s network manage-ment systems. Instead of handling devices as individual nodes, economy of scale can be achieved by handling them in groups that use policies and managed parameters that are more abstract and also fewer in number.
Consider the case of a service provider that wants to reduce costs by replac-ing sensor batteries less frequently. To achieve this, the service provider increases the life length policy of the node in the management system. The management system interprets this pol-icy and sets the reporting frequency to every two hours, instead of every hour, for a group of sensors in a particular geo-graphical region.
Connected devices will often be bat-tery powered, and so all operations, including management, need to be energy optimized to reduce the impact on battery usage. Additionally, con-nected devices tend to sleep during extended periods of time, and so man-agement operations cannot be expected to provide results instantly, but only after the device wakes up.
A significant challenge for network management is the provision of full end-to-end scope, an issue that is particu-larly evident when different domains in the end-to-end chain are provided by different business entities – as dis-cussed and indicated in Figure 1. Based on analysis of the connectivity infor-mation provided just by the devices, the connectivity state can only be esti-mated at a high level, extracted from
the information available at each end of the communication path. Estimating the connectivity in this way can lead to a significant overhead to obtain and maintain such information; it is also limits the configuration possibilities of the connectivity layer.
The best way to overcome this limi-tation is to interconnect the network management systems in the differ-ent domains. In this way, connectiv-ity information from the nodes along the communication path, between the end points, can also be included. If the domains are operated by separate enti-ties, this can be achieved through SLAs specifying the usage and exchange of information. The resulting cross-domain management provides end-to-end management opportunities. For example, QoS in both the capillary and the 3GPP domains can be matched, and alarms from both domains can be cor-related to pinpoint faults.
Summary
As the Networked Society starts to take shape, a vast range of devices, objects and systems will be connected, creating
1. Morgan Stanley, April 2014, Blue Paper, The ‘Internet of Things’ Is Now: Connecting The Real Economy, available at:
http://www.morganstanley.com/views/perspectives/
2. J. Höller, V. Tsiatsis, C. Mulligan, S Avesand, S. Karnouskos, D. Boyle, 1st edition, 2014, From Machine-to-Machine to the Internet of Things: Introduction to a New Age of Intelligence, Elsevier, available at:
http://www.ericsson.com/article/from_m2m_to_iot_2026626967_c 3. Alcatel Lucent, Ericsson, Huawei, Neul, NSN, Sony, TU Dresden, u-blox, Verizon
Wireless, White Paper, March 2014, A Choice of Future m2m Access Technologies for Mobile Network Operators, available at: http://www.cambridgewireless. co.uk/docs/Cellular%20IoT%20White%20Paper.pdf
4. Ericsson, NSN, April 2014, LTE Evolution for Cellular IoT, available at: http://www. cambridgewireless.co.uk/docs/LTE%20Evolution%20for%20Cellular%20 IoT%2010.04.14.pdf
5. Emerging Telecommunications Technologies, April 2014, T. Tirronen, A. Larmo, J. Sachs, B. Lindoff, N. Wiberg, Machine-to-machine communication with long-term evolution with reduced device energy consumption, available at:
http://onlinelibrary.wiley.com/doi/10.1002/ett.2643/abstract
6. 3GPP, TR 36.888, June 2013, Study on provision of low-cost Machine-Type Communications (MTC) User Equipments (UEs) based on LTE, available at: http://www.3gpp.org/DynaReport/36888.htm
References
the Internet of Things (IoT). Within this context, cellular networks have a signif-icant role to play as connectivity provid-ers, to which some things will connect directly, and another significant por-tion will connect using short-range radio technologies through a capillary network.
Cellular networks can provide global connectivity both outdoors and indoors by connecting capillary networks through special gateways. However, achieving this will require some new functionality.
Due to the massive numbers of con-nected things, functionalities – such as self-configuring connectivity manage-ment and automated gateway selection – are critical for providing everything in the capillary network with a reliable connection.
To ensure that communication remains secure and trustworthy, a secu-rity bridge is needed between the capil-lary and the cellular domains. With this functionality in place, a future network can provide optimized connectivity for all connected things anywhere no mat-ter how they are connected.
