software-controlled networking: cloud, nfv and sdn are

© Analysys Mason Limited 2013

Software-controlled networking: cloud, NFV and SDN are important for next-generation networks

Webinar

Software-controlled networking: cloud, NFV and SDN

are important for next-generation networks

September 2013

Glen Ragoonanan



Uniquely positioned to provide consulting and research to the

TMT industry

2

Our focus is exclusively on telecoms, media and

technology (TMT).

We support multi-billion dollar investments, advise clients

on regulatory matters, provide spectrum valuation and

auction support, and advise on operational performance,

business planning and strategy.

We have developed rigorous methodologies that deliver

tangible results for clients around the world.

We analyse, track and forecast the different services

accessed by consumers and enterprises, as well as the

software, infrastructure and technology delivering those

services.

Research clients benefit from regular and timely

intelligence in addition to direct access to our team of

expert analysts.

Our dedicated Custom Research team undertakes

specialised and bespoke projects for clients.

Research

Consulting

Transaction

support

Strategy

and planning Operational

consulting

Procurement Regulation

and policy

Consumer services

Enterprise services

Telecoms software

Regional markets

Network technologies



Our research portfolio includes 27 programmes covering the

complete depth and breadth of the telecoms sector

3

Deliverables: research programmes include a combination of:

Reports: forecasts, quantitative modelling and survey reports, with in-depth analyses of critical industry challenges and opportunities

Viewpoints: targeted analysis of key trends and topics (technology trends, innovative business models, best-practice strategies and case studies)

Comments: brief informed opinion on industry and competitive developments

Trackers and databases: regularly updated databases of KPIs, services pricing and offers, roll-out initiatives and spectrum auctions.

Research programmes

Network Technologies

Spectrum Fixed Networks Wireless Networks

Consumer Services Fixed Broadband and Media

Mobile Broadband and Devices

Mobile Content and Applications

Voice and Messaging

Practices Programmes

Enterprise Services Enterprise (focus areas: M2M and cloud) SME Strategies

Telecoms Software Markets

Data programmes Application programmes

Telecoms Software Forecasts

Service Assurance Telecoms Software Market Shares

Revenue Management

Infrastructure Solutions Service Fulfilment Service Delivery Platforms

Customer Care

Customer Experience Management

Digital Economy Analytics Operational Transformation

MEA APAC

Regional Markets

Europe

Core Forecasts Telecoms Market Matrix

Country Reports The Middle East and Africa

Asia–Pacific Global Telecoms Forecasts

Telecoms Software Strategies


Software-controlled networking: cloud, NFV and SDN are important for next-generation networks 4

Executive summary and business environment

SDN use cases

Recommendations

Market definitions

Contact details



What is software-controlled networking?

More importantly, what does it mean to me?

The role of software-based solutions has continuously increased as IT and telecoms networks

have converged, and these networks are evolving towards a software-controlled networking (SCN)

environment.

SCN technologies focused on by CSPs and vendors are anchored to virtualisation: cloud

computing, network function virtualisation (NFV) and software-defined networking (SDN).

To identify key technology components of the evolving virtualised next-generation networks

(vNGNs) we developed a layered SCN architecture. The layers identified are:

user, infrastructure, platform, control, service, and development, where management and

security spans all layers.

However, technologies should not be implemented without a business case. The business case for

investing in SCN technologies is unclear to most, with only Tier-1 CSPs exploring it at present.

vNGN transformations will be an evolution, not a revolution, as IP NGN and each CSP will evolve

differently based on its unique business, competitive and technology environment.

CSPs’ telecoms and IT networks will follow different virtualisation paths because they will have to

address different environmental challenges.

5



Software-controlled networking is the path along which CSPs’

networks are evolving – virtualised NGN

Figure 1: Landscape of increasing software control in the network [Source: Analysys Mason, 2013]

6

Legacy IN IMS

architecture

Telecoms

application

servers (TAS,

NG-IN)

Cloud

computing

(IaaS, PaaS

and SaaS)

SON

NFV

SDN

Increasing software control in the network

Prepaid

services,

GSM

IP-NGN, EPC,

OCS

Data services,

SOA, RCS-e

Content (apps, video),

OTT services,

virtualisation

HetNets, FMC, network

virtualisation, cost

Policy

control

Mobile data services,

diameter routing, cost

PSTN is a persistent legacy – particularly in incumbents

Key

drivers

Circuit switching Packet switching



Convergence and innovation drive transformation to reduce

costs and time to market for new technologies The major drivers behind convergence and innovation in

next-generation telecoms networks are:

cost optimisation: to reduce capex and opex

flexibility: to reduce deployment and operational

complexities and further reduce opex

business value: to accelerate time to market for new

technologies in order to deliver new and established digital

(telecoms and OTT) services, which can reduce payback

periods for new technologies and increase revenue

sooner.1

In an advanced SCN environment, CSPs and suppliers will

be able to differentiate themselves on the basis of their

software and applications, not their hardware.

The SCN markets of cloud computing, NFV and SDN have

been very active during the past year, as vendors position

themselves in the evolving SCN value chain. The market has

undergone about USD4 billion in vendor mergers and

acquisitions, and attracted about USD220 million in venture

capital funding for more than ten SDN start-ups worldwide.

7

Figure 2: Overview of the evolving telecoms landscape SCN

technologies target [Source: Analysys Mason, 2013]

1 New digital services are explored in Analysys Mason’s Digital Economy Software Strategies programme, which covers M2M, commerce and billing services, as well as B2C and B2B cloud-based services.

IT

Telecoms

Apps

Cost

optimisation Flexibility

Business

value

Convergence and

innovation

IT

Telecoms

Apps

http://www.analysysmason.com/What-we-offer/Research/

http://www.analysysmason.com/What-we-offer/Research/



The impact of SCN technologies: The effect on each of the

telecoms software market segments in our taxonomy will vary

Network function virtualisation (NFV) is the virtualisation of

the telecoms-specific network functions that currently work

on embedded hardware, so that it can begin working on

high-performance servers.

Software-defined networking (SDN) refers to the architecture

used to make the network control plane (which is presently

embedded or locked firmware) remotely accessible and

modifiable via third-party software clients, such as those

based on the OpenFlow protocol.

Cloud computing is an IT model for providing on-demand

network access to a shared pool of configurable, virtualised

computing resources (for example, processors, servers,

storage, applications and network interfaces (NIC)) that can

be rapidly provisioned and released with minimal

management effort or interaction. Cloud computing is widely

used to virtualise telecoms software (OSS, BSS, SDP) in

communications service providers’ (CSPs’) private clouds.

8

NFV will be dominant in the revenue management and SDP

segments. As a result, systems integration will need to evolve

to more of a ‘NFV integration’ paradigm.

SDN will be prevalent in the segments that are closest to the

network and devices – that is, network management systems,

service assurance and device management. SDN

implementations will also impact custom development because

of the lack of commercial ‘off-the-shelf’ solutions (COTS).

SON is and will continue to be prevalent in engineering

systems, network management systems, and the network

planning and optimisation services in design consulting and

outsourced operations.

Eventually, it will be possible to host all OSS, BSS and SDP

systems in a cloud architecture.

Hosted managed services are delivered from a cloud

architecture using cloud computing technology. An increasingly

software-oriented environment could result in the majority of

product-related services being delivered as cloud services.

Business consulting and PSTN will be unaffected.

Definition of SCN market terms Expected impact on the telecoms software market



The impact of SCN technologies: However, almost all

segments will be influenced

9

Figure 3: Telecoms software market segments impacted by major SCN technologies in the next 5 years [Source: Analysys Mason,

2013]

SCN technology that will have an impact: SDN NFV No impact: SON Cloud computing

Professional services

Business

consulting

Design

consulting

Product-related

services

Systems

integration

Custom

development

Outsourced

operations

Hosted managed

services

Revenue

management

Partner and interconnect

Business optimisation

Mediation

Service delivery

platforms

Content management

Telecoms application

servers

Policy management

Subscriber data

management

Customer care

Customer interaction

Customer relationship

management

Subscriber

management

Service fulfilment

Order management

Inventory

management

Activation

Engineering systems

Service assurance

Service management

Fault and event

management

Performance

monitoring

Workforce

automation

Probe systems

Network management systems

Mobile Residential broadband Business data services PSTN

Device management

Billing

Prepaid

Postpaid

Convergent

and interconnect

optimisation



Virtualisation will continue to blur the hardware and software

boundaries between cloud computing, NFV and SDN Cloud computing and NFV: the same, but different:

Cloud computing is the virtualisation of commodity IT

hardware and applications/software, which can run at least

99% availability level.

NFV is the virtualisation of telecoms-specific network

functions into applications that will run at least 99.999%

availability on suitable carrier-grade hardware and software.

Cloud computing is acceptable for non-real-time telecoms

software (OSS, BSS and SDP) on x86 servers, but is not

yet proven for telecoms network functions.

Telecoms software systems that provide network functions

can easily reside in a private cloud computing architecture.

The SDN roadmap has to navigate and mature in the data

centre before it can reach the CSPs’ networks (CSP SDN).

There is an overlap of NFV and SDN in the core/aggregation

layer of CSPs’ network.

CSP SDN is still largely in R&D and remains an open

opportunity for telecoms and non-telecoms vendors alike.

Trials to date have clearly separated SDN/OpenFlow from

CSP SDN – but this can change as R&D continues and SDN

vendors provide solutions for both data centres and CSPs as

part of their strategy.

10

Figure 4: ICT convergence in CSPs’ networks from cloud

computing, NFV and SDN technologies [Source: Analysys

Mason, 2013]

Next-generation telecoms Enterprise

OSS

NFV

SDN

Enterprise IT

Cloud management:

Virtual domain, IT

hardware, and

network

IT hardware

Cloud computing

Enterprise IP network

SD

N/O

pen

Flo

w

CS

P S

DN

Revenue management

Charging, Fraud, Interconnect

Control layer

IMS, Diameter, SIP

Network layer

Multi-service IP-based

network

Access layer

Multi-technology fixed and

mobile access networks

Core / aggregation

Distribution

Transport

Customer

care Virtualised

applications (SaaS)

Service layer

Service delivery platforms



Market drivers and inhibitors for NFV and SDN for CSPs

11

Drivers

Cost reduction (capex and opex)

Faster time to market

Reduced network complexities (control and

management)

Competitive pressure

Maturity of virtualisation technologies

Inhibitors

Lack of carrier-grade (99.999%) hardware and

software technologies

CSPs need to acquire the return on investment on

existing network assets

Risk associated with fully open-source solutions:

lack of differentiation or uniqueness

high potential for security threats

Incompatibility with established networks and

OSS/BSS



The OSS layer for NFV and SDN for CSPs will gravitate

towards the NFV standards, not open source solutions

12

Figure 5: The evolution of the CSP OSS layer [Source: Analysys Mason, 2013]

NFV will move away from open-source solutions and towards COTS, and CSP SDN will be different from data

centre SDN. Open source approaches have not been successful in the telecoms sector because it does not

allow CSPs or vendors to differentiate and does not deliver reliable, carrier-grade solutions.

This could lead to control and management (that is, the OSS layer) of CSPs’ virtualised network functions and

SDN gravitating towards the NFV standards.

Data centre SDN will continue to gravitate towards open-source solutions and innovations, unless a strong

COTS network operating system (NOS) is developed.

Open

innovation

SDN

NFV

5–7 years 7 years

Open

innovation

SDN

NFV

Open

innovation

SDN

NFV CSP OSS

CSP OSS




SDN use cases

Recommendations

Market definitions

Contact details



SDN use cases

Roadmapping SDN – from the data centre to CSPs’ networks

The possibilities of SDN for CSPs



The SDN roadmap has to navigate and mature in the data

centre before it can reach the CSPs’ networks

The following SDN deployment scenarios illustrate the maturity of SDN in data centres in

delivering the concept of an SCN environment on commodity IT hardware for a carrier-grade

workload using an SDN control plane for centralised orchestration and management.

The use cases demonstrate that SDN solutions and, ultimately, OpenFlow are not yet mature

enough to support CSP networks. Their usefulness is currently limited to the data centre.

CSP SDN is still in the R&D phase for most vendors. They are collaborating with some CSPs. As a

result, the benefits of CSP SDN remain questionable.

15



Deutsche Telekom’s TeraStream project: a cloud-enabled SDN

architecture Business problem

Cost, complexity, scaling for traffic growth and competitive

pressure have driven Deutsche Telekom to explore a radical,

lower-cost network architecture.

Technical solution

It developed a cloud-enabled, native-IP architecture called

TeraStream, which Hrvatski Telekom is trialling in Croatia.

TeraStream is a redundant architecture to allow live testing

as well as low-latency disaster recovery. The Cloud Service

Centre will host virtualised instances of cloud computing,

content and network functions, using NFV technologies.

Cisco’s CloudStack, using OpenFlow, is in the data centre.

Tail-f’s NCS is controlling the metro network, but with a non-

OpenFlow solution. Alcatel-Lucent’s CloudBand is the cloud

computing solution in the data centre.

Analysis

The need to reduce network costs and complexity are the

primary drivers for TeraStream. Deutsche Telekom aims to

roll this model out to its other operations if it is successful.

SDN has so far been more successful in the data centre.

The operator does not expect to develop COTS solutions and

is partnering with vendors such as Alcatel-Lucent, Cisco and

Tail-f on TeraStream.

16

Figure 6: Deutsche Telekom’s Cloud Service Center concept

[Source: Deutsche Telekom, 2013]

Figure 7: Deutsche Telekom’s current use of non-OpenFlow

SDN in the metro network [Source: Deutsche Telekom, 2013]



Google’s G-Scale uses OpenFlow-enabled SDN to reduce the

scaling cost of its private inter-data-centre WAN Business problem

The cost per bit of scaling traditional WAN network architecture

to meet growing demands on bandwidth was increasing.

Google needed to scale the network to deliver high availability

(data replicated across sites) and low-latency access to its

services for users.

Technical solution

Google built G-Scale, its internal WAN backbone for about

13 data centre sites, using custom hardware running Linux,

OpenFlow software controllers and adapters, centralised

traffic engineering capabilities, open source routing stacks for

BGP and IS-IS contributing to Quagga (a network routing

software suite). G-Scale was completed in about 18 months.

It used multiple Google hardware chassis in each site to

provide fault tolerance and scale.

Analysis

G-Scale provides scalability and centralised control and

management of Google’s WAN with uniform hardware.

Google can scale its WAN infrastructure on demand and

deliver higher bandwidth at a lower cost per bit.

G-Scale will not be commercialised. Google is an open

source advocate, like the ONF, and contributed to Quagga.

17

Figure 8: Google’s WAN [Source: Google, 2013]

Figure 9: Google’s G-Scale [Source: Google, 2013]



NTT Communications embarks on an SDN-enabled global

cloud platform for enterprise customers Business problem

NTT Communications wanted to scale its global cloud service

platform at a lower cost. The long time-to-market cycle, as

well as the complexity of controlling and managing cloud

computing services for enterprise customers is reducing profit.

Technical solution

NTT used its established relationship with NEC to implement

a fully virtualised (compute, storage and network) enterprise

cloud platform for nine data centre locations in eight

countries as of March 2013.

The OpenFlow-enabled SDN uses NEC’s ProgrammableFlow

solution to provide flexible on-demand, intra- and inter-data-

centre network resources and capacity.

Analysis

NTT’s SDN reduces network cost, complexity (control and

management) and provides on-demand scalability.

This solution is not a completely open source SDN/OpenFlow

solution, which demonstrates the need for carrier-grade

solutions for the CSP market.

In-house development will drive SDN R&D and deployment in

its network, in the absence of COTS. Internal development is

the company’s traditional business and operations model.

18

Figure 10: NTT’s virtualised cloud service platform [Source:

NEC, 2013]

Figure 11: The benefits of a fully virtualised data centre [Source:

NEC, 2013]



SDN use cases

Roadmapping SDN – from the data centre to CSPs’ networks

The possibilities of SDN for CSPs



SDN and NFV has achieved some success, but an end-to-end

SDN solution that meets CSPs’ business objectives is needed

A robust and interoperable OSS layer that will co-

exist with established OSS and traditional network

infrastructure, with the roadmap to provide a unified

abstracted SDN control and management layer for

the hardware and network functions.

An SDN transformation roadmap that provides

technology and operational transition plans that

meet the CSPs’ business objectives in phases.

Examples of clear, quantifiable benefits of using

NFV/SDN in specific target areas (such as policy,

IMS and optical) so that CSPs can justify the

investment.

New target areas and use cases, such as:

dynamic app-aware traffic engineering with SDN

dynamic service chaining of Gi network functions

at the Gi interface for both NFV and SDN

SDN for IPv6 networks with IPv4 service

compatibility.

20

NFV is available for:

policy control (PCRF, AF, OCS, OFCS, recently

PCEF)

ISP (caching, load balancing, DNS/DHCP, traffic

management, BRAS, AAA)

IMS components (CSCF, MGCF, MRFC, MGW,

TAS, NG-IN, RCS-e)

routing (Diameter, OSPF, RIP, BGP, IS-IS)

mobile (MME, HSS, PGW, SON, ANDSF).

SDN/OpenFlow is prevalent in CSPs’ data centres.

Some SDN success has been noted in CSPs’

transport networks:

Tail-f’s NCS multi-vendor SDN controller in

Deutsche Telekom’s TeraStream metro network

NTT’s inter-data-centre WAN connectivity using its

own technology and NEC’s.

What is needed to evolve to SDN for CSPs? NFV and SDN successes for CSPs to date



We have identified four use cases that should form the

building blocks of CSPs’ end-to-end SDN strategy

21

Figure 12: Potential SDN use cases for CSPs [Source: Analysys Mason, 2013]

New or replacement hardware introduced in the network could be automatically discovered and sent configuration information from an SDN control plane, based on the network configuration policy.

New network functions could be pre-configured in the SDN architecture at the controller layer and be automatically configured when connected to the network.

Auto-network configuration

After network changes (such as node addition, configuration change or failure), the time it takes for these changes to propagate throughout an SDN could be considerably shorter.

The SDN controller could manage this convergence more efficiently than traditional network techniques, such as broadcast and replication.

Faster network convergence

SDN could enable centralised and uniform control and management of network configuration, policies, changes, rollbacks and upgrades.

Centralised control and management

SDN could facilitate interactions between (or integration of) multiple policy management systems across the network and service layer to:

manage the network

auto-provision subscriber-requested services, based on service policies.

Policy-driven and simplified operations



Policy-based management is becoming pervasive, which is

important for SDN1 – centralised or distributed?

22

Figure 13: Hierarchy of major policy and network management

systems in CSPs’ operations [Source: Analysys Mason, 2013]

1 For further details, see Mark H. Mortensen’s Mobile operators with multiple policy management systems need new monitoring and control architecture. Available at www.analysysmason.com/Research/Content/Comments/Interacting-policy-mgmt-Jan2013-RMA02-RMA04.

Figure 14: Potential evolution to a master policy management

system in a CSP’s SDN operations [Source: Analysys Mason,

2013]

SON

Low-level

Signalling

Service control

Differentiated services

Network

Master

policy

control

SON

High-level

SON

Network

Service

SON

Low-level

Signalling

Service control

Differentiated services

Network

Service

policy

control

SON

High-level

SON

Network

Service

Network

policy

control

SON policy

control




SDN use cases

Recommendations

Market definitions

Contact details



Recommendations for CSPs

CSPs should:

understand that virtualisation is the next evolution for networks, but it adds performance and cost layers.

ETSI NFV claims that the performance level of virtualisation is approaching carrier-grade performance in terms of reliability,

availability and processing throughput. Performance benchmarks on live networks have yet to confirm this claim.

Virtualisation adds a higher software cost layer onto the hardware compared with embedded software because of its ability to

provide elasticity and flexibility. The benefits of this cost for cloud computing and NFV are tangible in terms of power, cooling and

floor space cost savings.

be stakeholders in the development of NFV and CSP SDN solutions and collaborate with vendors. BT, Deutsche Telekom, NTT

Communications, Portugal Telecom, Telefónica and Verizon are leading by example in this respect.

use NFV as the first step to realising the benefits of virtualisation and eventually evolve to CSP SDN by identifying specific

network functions that can be virtualised – particularly those in the core and on x86 hardware, such as PCRF, caching, and some

TAS and IMS components.

measure the benefits of virtualisation accurately in order to develop cost key performance indicators by benchmarking costs

prior to the deployment.

expect CSP SDN transformation programmes to be long (more than 10 years) and complex, and recognise that traditional

networking and infrastructure will continue to coexist with SDN environments because PSTN, as well as new and different OSS, will

be required for both environments. Early adopter CSPs will have to use in-house skills initially because COTS and vendor

capabilities and skills will increase over time.

embrace the advantages of an IT culture because SCN will increase the convergence between IT and telecoms. For example,

CSPs need to be open to using new vendors, focusing on flexibility and cost reduction as the core requirements in architectural

design, and be more open to using software solutions that accelerate delivery time and ease operations.

24



Recommendations for vendors: Hardware, software and

services are the three main market opportunities Hardware

It is not clear whether NFV and SDN will drastically increase

the depreciation of telecoms hardware. However, it is clear

that NFV and SDN will require new and different carrier-

grade hardware that is analogous to high-performance server

chassis. Ultimately, hardware can become the bottleneck in

SDN architecture and increase the value of this opportunity.

Software

Software will represent the highest revenue opportunities for

functions such as virtualisation (network OS, hypervisors),

OSS (SDN controllers, orchestrators and managers), NFV

components (such as PCRF), high availability, integration

adapters and security, among others.

Services

The three main professional service opportunities associated

with NFV and SDN are:

transformation or migration to a NFV and SDN environment

management of a complex combination of SDN and

traditional networks (including legacy), which will co-exist

integration of different multi-vendor technologies for OSS,

BSS, SDP, NFV, SDN and other competitive technologies

that emerge during the next 10 years.

25

Figure 15: SCN market opportunity segments in cloud, NFV and

SDN Analysys Mason will explore [Source: Analysys Mason,

2013]

Sub-segments Market

opportunities SCN markets

Cloud computing

NFV

SDN

Hardware

Software

Services

Core

Distribution

Access

Hypervisors

NFV components

OSS

Transformation

Co-existence

Integration




SDN use cases

Recommendations

Market definitions

Contact details



Pro

fess

ion

al s

erv

ices

: C

o-e

xis

tence

, in

teg

ration

, tr

ansfo

rma

tio

n

Telecoms

Access

Distribution / Transport

Core / Aggregation

IT

End users and

end devices

Software-controlled networking architectural categories

27

Figure 16: Software-controlled networking architectural categories [Source: Analysys Mason, 2013]

Enterprise Virtualised next-generation networks (vNGN) Legacy

User layer

Infrastructure

layer

Platform layer

Control layer

Service layer

Development

layer

Mobile Fixed Hetnets

BYOD CPEs

Mobile smart devices

IP-enabled devices

Robustness, resilience

Network operating system

(NOS)

Multi-service

IP core network

Multi-service

IP-enabled, optical

transport network

IP

network

Hypervisors (hardware

virtualisation)

Intelligent

networks

and SS7

IMS, diameter and SIP OSS Policy control

Telco

SDP BSS

IMS

applications

Cloud, OTT,

e-commerce

services

Home gateway

services

M2M

services

Elastic

connectivity

services

Service

accessibility (over

FMC, hetnets)

ICT applications development (by CSPs, DCPs, vendors and third-party developers)

IT development Telecoms development

Man

ag

em

en

t

Secu

rity

Op

en

so

urc

e

High availability (HA)

Multi-technology controllers

Multi-tenant SaaS

Session boarder controllers

IT manager of

managers (MoMs)

AP

Is

AP

Is

AP

Is

Inte

gra

te

Access

Wi-Fi smart devices

Performance acceleration

Scalability, elasticity

IP NGN



Definitions of SCN market and revenue types

Figure 17: SCN market definitions [Source: Analysys Mason, 2013]

Market Definition

Cloud computing Covers cloud infrastructure (hardware, software/applications and services) and management of CSPs’ internal private cloud infrastructure

and cloud management for enterprise customers. Cloud management covers the software systems that enable customers to order,

activate, assure, bill and secure cloud services. This definition excludes network virtualisation, which we include in SDN.

Network function

virtualisation (NFV)

This market is defined by the parameters identified by the ETSI Industry Specification Group (ISG). It covers network functions such as

routing, switching, IMS functions, caching, PCRF, PCEF, MME, SMSC, HSS and media processing.

Software-defined

networking (SDN)

Specifically covers SDN work that is currently confined to the data centre. Most is currently related to the OpenFlow protocol and led by the

Open Networking Foundation (ONF), but some non-OpenFlow solutions are included. We expect SDN in CSPs networks (CSP SDN) will

take on a different form, beyond OpenFlow. We will focus on and include the CSP SDN market as it evolves.

Figure 18: SCN market revenue type definitions [Source: Analysys Mason, 2013]

Revenue type Definition

Hardware Includes the hardware and maintenance associated with each SCN market.

Software Includes product (licence software and maintenance) and product-related services (installation and configuration of product software

supplied), in each SCN market. Also includes hardware control and management software, such as virtualisation, high availability, security,

management, application optimisers, middleware and certified APIs.

Professional

services

Services that suppliers provide and are associated with their hardware and software services, such as implementation, systems

integration, support and maintenance. This includes design, deployment, systems integration, product and solution support, and managed

services in each SCN market. Excludes CSPs’ in-house development.



Sub-segments Definition1

Infrastructure layer Covers mainly infrastructure/hardware, and lesser software and services, security and management that provide storage, computing and

networking resources in CSPs’ core/aggregation, distribution/transport and access IT and telecoms network layers to reach end users.

Platform layer Includes mainly software and services above the hardware infrastructure, security and management for virtualisation (NOS, hypervisors),

high availability, scalability/elasticity, performance, and resilience. Platform software maybe implemented on bare-metal hardware.

Control layer Includes hardware, software and services above the platform layer, security and management for control of the underlying platform and

infrastructure with functions such as OSS (multi-technology (NFV, SDN, IT) controllers, orchestrators and managers), multi-service IP

network control (IMS, Diameter, SIP), and NFV components (for example, policy control).

Service layer Includes hardware, software and services above the control layer, security and management for creating, enabling, delivering and

managing services with functions such as BSS, SDP, API exposure, applications, and service accessibility (handover, etc.)

Development layer Includes hardware, software and services above the service layer, security and management for application development from network

and service API exposure from the service layer. This will be available to third-party developers.

User layer This market is not sized but noted as part of the ecosystem. Analysys Mason’s Mobile content and applications programme follows the

device and consumer segment in more detail.

Multiple layers Management and security spans all layers and is covered in each. Open-source software will assist R&D to COTS across all above layers,

but will not contribute to revenue. As such only COTS revenue contributes to the sizing of SCN markets.

Definitions of SCN market layered sub-segments [1]

Figure 19: SCN market sub-segments by architectural layers definitions [Source: Analysys Mason, 2013]

1 Bold text indicates the largest source of revenue in each layer and will be the focus in market sizing.



Definitions of SCN market layered sub-segments [2]

Figure 20: SCN market sub-segments by architectural layers by cloud/virtual layers definitions [Source: Analysys Mason, 2013]

Virtual layers Definition

IaaS Includes the infrastructure layer only, to deliver storage, computing and networking.

PaaS Includes the platform and control layers to increase availability, robustness, performance, elasticity and control/manageability to the

underlying infrastructure layer.

SaaS Includes the service and development layers to develop, deliver and manage service on a robust underlying PaaS.




SDN use cases

Recommendations

Market definitions

Contact details



Contact details

32

Boston

Tel: +1 202 331 3080

Fax: +1 202 331 3083

[email protected]

Cambridge

Tel: +44 (0)1223 460 600

Fax: +44 (0)1223 460 866

[email protected]

Dubai

Tel: +971 (0)4 446 7473

Fax: +971 (0)4 446 9827

[email protected]

Dublin

Tel: +353 (0)1 602 4755

Fax: +353 (0)1 602 4777

[email protected]

Edinburgh

Tel: +44 (0)131 443 9933

Fax: +44 (0)131 443 9944

[email protected]

Johannesburg

Tel: +27 11 666 4786

Fax: +27 11 666 4788

[email protected]

Manchester

Tel: +44 (0)161 877 7808

Fax: +44 (0)161 877 7810

[email protected]

Milan

Tel: +39 02 76 31 88 34

Fax: +39 02 36 50 45 50

[email protected]

New Delhi

Tel: +91 11 4700 3100

Fax: +91 11 4700 3102

[email protected]

Paris

Tel: +33 (0)1 72 71 96 96

Fax: +33 (0)1 72 71 96 97

[email protected]

Singapore

Tel: +65 6493 6038

Fax: +65 6720 6038

[email protected]

Madrid

Tel: +34 91 399 5016

Fax: +34 91 451 8071

[email protected]

Glen Ragoonanan

Senior Analyst

[email protected]

London

Tel: +44 (0)20 7395 9000

Fax: +44 (0)20 7395 9001

[email protected]

software-controlled networking: cloud, nfv and sdn are

Documents