How to enable a Telephone Company to Innovate like Googlestefan/jak.pdf · ›Digital telephony/POTS ›Internet –Just concerned with user facing actions ›Call control, billing

Slide title

70 pt

CAPITALS

Slide subtitle

minimum 30 pt

How to enable a Telephone Company to Innovate like Google James Kempf Principal Research Engineer Ericsson Research Silicon Valley

Slide title

44 pt

Text and bullet level 1

minimum 24 pt

Bullets level 2-5

minimum 20 pt

Characters for Embedded font: !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~¡¢£¤¥¦§¨©ª«¬®¯°±²³´¶·¸¹º»¼½ÀÁÂÃÄÅÆÇÈËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿĀāĂăąĆćĊċČĎďĐđĒĖėĘęĚěĞğĠġĢģĪīĮįİıĶķĹĺĻļĽľŁłŃńŅņŇňŌŐőŒœŔŕŖŗŘřŚśŞşŠšŢţŤťŪūŮůŰűŲųŴŵŶŷŸŹźŻżŽžƒȘșˆˇ˘˙˚˛˜˝ẀẁẃẄẅỲỳ–—‘’‚“”„†‡•…‰‹›⁄€™ĀĀĂĂĄĄĆĆĊĊČČĎĎĐĐĒĒĖĖĘĘĚĚĞĞĠĠĢĢĪĪĮĮİĶĶĹĹĻĻĽĽŃŃŅŅŇŇŌŌŐŐŔŔŖŖŘŘŚŚŞŞŢŢŤŤŪŪŮŮŰŰŲŲŴŴŶŶŹŹŻŻȘș−≤≥fifl

ΆΈΉΊΌΎΏΐΑΒΓΕΖΗΘΙΚΛΜΝΞΟΠΡΣΤΥΦΧΨΪΫΆΈΉΊΰαβγδεζηθικλνξορςΣΤΥΦΧΨΩΪΫΌΎΏ

ЁЂЃЄЅІЇЈЉЊЋЌЎЏАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯАБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯЁЂЃЄЅІЇЈЉЊЋЌЎЏѢѢѲѲѴѴҐҐәǽẀẁẂẃẄẅỲỳ№

Do not add objects or

text in the footer area Ericsson Confidential | 2013-11-21 | Page 2

› Problem Definition

› Historical Perspective

› Platform

› Process

› Prototypes

› Summary

outline

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Typical platform – Collection of protocols and

systems accumulated over 50 years

› Digital telephony/POTS

› Internet

– Just concerned with user facing actions

› Call control, billing

› Typical process – Group of 30 people

– 1-2 years of effort

› Ensuring the underlying hooks are there

› Programming them if not

› Bottom Line: time consuming and expensive

Problem Definition: How Service Development works today

http://www.planetgeek.ch/wp-content/uploads/2010/06/image2.png

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Problem Definition: AGILE Service Development

Process:

- Flexible, adaptable

to fast evolving

customer tastes

- Low overhead

- Doesn’t require

CS PhD’s to run

- Able to turn around

feature set in weeks

rather than years

Platform:

- Engineered for fast

innovation

- Easily enhanced for

new use cases

- Built on existing

technology when

good enough

- Stable enough for

long term

- Covers cross-domain

(WAN, cloud, mobile)

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Standardization effort by ETSI, 3GPP, and TISPAN – Started in 1998.

› Goal: to produce a set of APIs usable by enterprise IT developers for developing telephony applications independent of the underlying network type (SS7, mobile, etc.)

– Call Control

– Conferencing

– User Interaction (audio, text messaging, SMS, MMS)

– Billing

› Multiple language bindings – CORBA/IDL

– Java

– WDSL (XML Web Services specification)

› In 2003 simplified set of APIs released called Parlay X

– Basic Web services API

› In 2007, the Parlay standardization work was completed

Historical perspective: Parlay

http://www.payphoneoutlet.com/1920s-nostalgic-brushed-chrome-candlestick-telephone-p-16538.html?cPath=111&osCsid=9mfok101bahteqhrfp1epkpfj2

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Standardization effort within

the Java Community Process

› Originally started as a way to

control ISDN-based Intelligent

Networks from a Java API

– Moved to higher level call control

later

– Overlap with Parlay

› Between 2001 and 2003,

Parlay and JAIN harmonized

their APIs

– Process issue: JCP requires

implementations, ETSI doesn’t

Historical Perspective: JAIN

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› In 2007, GSMA took over Parlay

Web services APIs for telephony

› Renamed OneAPI

– REST-based APIs

– Standardization effort still ongoing with

GSMA

› Includes call control and billing

Historical Perspective: OneAPI

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Historical Perspective: Analysis Where are the flood of applications expected from Parlay/Jain/OneAPI?

Lack despite more than 10 years of effort suggests need for some reflection and analysis

The APIs must support more that

just application control of

communications

- Automation of configuration and

deployment

- Cross domain orchestration

APIs initially exposed maximal

information rather than simplified

abstractions

- Original Parlay/Jain APIs were too

complicated for enterprise IT folks

The APIs must evolve out of

implementing use cases

- Use case driven APIs will get used at

least for the cases they are designed for

- Supporting more use cases may

require refining the abstractions

The APIs must support

maximal automation

- Anything less will increase OPEX and

deployment complexity, lengthening

innovation cycle

Key to a successful cross-domain service orchestration platform

is simple, usable abstractions and maximally automated

deployment.

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› In 2008, Stanford introduced OpenFlow – Simple, TCAM-based forwarding model

– 1990’s view of the data plane

› In 2012, ONS standardized OpenFlow 1.3 – Same forwarding model

– 2008 view of the data plane

› Problem – Most networking devices don’t have the hardware to support scalable, line

speed TCAM based forwarding

› In 2010, OpenFlow generalized to Software Defined Networking (SDN) – Centralized control plane

– Protocol control of forwarding elements

› What protocol isn’t specified

– Basically real time network management

› SDN opened the discussion to combining control and management planes in a single controller

Platform: sDN

SDN Controller North-bound API is the Platform for transport and

network management control

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Platform: ExamPle OpenDaylight

Hydrogen Release

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› IaaS APIs virtualize/automate server, storage, and network configuration and deployment

– Example: Openstack

– Virtual server deployment and provisioning

– Load balancing

– Virtual network connectivity

– Virtual storage

› PaaS APIs support application developent – Java, Ruby, Python, CloudFoundary

› Orchestration platforms support complex service deployment

– Compose multiple applications into a single service

› Confined to a single data center so far but potentially applicable to the entire network

– Cross domain

– View network, compute and storage resources as one gigantic computational platform

Platform: Cloud Computing

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› In 2012, 24 companies from the operator community issued a white paper for Network Function Virtualization (NFV)

– Emphasis on CAPX savings by using COTS hardware

› Remove function deployment dependence on specific hardware platforms

– Vision was to virtualize all functions involved in running an operator network onto COTS

› Including data plane of routing and forwarding elements

› Subsequent study showed that CAPX savings from white box COTS would not be so great

– Revised white paper now stresses OPEX and speed of innovation

– Virtualizing other network functions like IMS, mobile core, etc.

› Less talk about basic routing and forwarding element virtualization

Platform: NFV

NFV is now about changing the deployment model which could

enable deeper automation of deployment

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Platform: Example Cross-Domain Controller/Telco PaaS

Network

Service

Automated

Deployment

Framework

Automated

Service Assurance

and Management

Service Development Environment/Customer Portal

3G/LTE Transport Router Edge Data

Center

Operational domain

Mobile Access

Operational domain

IP & Optical Transport

Service Edge DataCenter Enterprise and

Consumer

Access

Abstracted

Simplified

Realtime

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Policy configuration and management

› Service and order management – Including end user self-provisioning

› Network management and automation of fault correction

– Root cause analysis

– Service assurance

– Realtime session monitoring

– Topology monitoring

– Cross-layer correlation

› Automated traffic engineering to reduce the need for overprovisioning

– Gscale-like utilization in operator network

› WebRTC support and streaming media protocols/APIs

› Realtime gateway deployment and IoT?

› Security APIs?

› Other?

Platform: What’s Missing?

Additional Platform APIs should derive from specific use cases

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Agile principles of software development help make service development quicker

› Good software engineering practices are necessary

– Object-oriented design

– Unit testing

– Automated acceptance testing

– …

› Devops or Continuous Deployment can reduce the time until new features

– Integrate development and operations

– Decrease feature set in any one release

– Release on a monthly basis

› Proactive, destructive fault testing can ensure that services will stand up to any load or any fault condition

– Netflix Chaos Monkey kills streaming video VMs randomly to ensure their video feeds will survive a VM crash

Process: Agile Service Development

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






PrototypeS: Cloud Atlas › Elastic WAN Networking with

SLAs for OpenStack

› Tight integration with OpenStack Neutron data center networking with WAN

› End to End, Data Center to WAN to X, virtual networking

› Simple, customer usable API – Based on simple abstractions for

bandwidth and connectivity

– Reduces operator management overhead

› Connectivity and bandwidth on demand

– Cloud – Cloud

– Cloud – Enterprise

› Independent of underlying WAN VPN hw/sw technology

– OTT, L3VPN, L2VPN, etc.

– SmartEdge, SPO 1400, etc.

Applications

Abstractions

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Prototypes: Cloud Atlas Architecture

Cloud OS

A

GW A

Orchestration Layer

or Cloud OS Tenant

Cloud OS

B

GW B

Site A Site B

Network

Virtualization

A

WAN

EN Agent

A

EN Plug-in

EN Agent

B

EN Plug-in

Network

Virtualization

B

EN Manager

EN Plug-in

Management

API Management

API

Cloud Atlas

Public API

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Bandwidth calendaring:

– Limited duration scheduled period of increased bandwidth

– Between two data centers or a data center and enterprise network

› Operator can make use of spare capacity during off-peak hours

› Example application:

– Checkpoint (not live migrate) VM into another data center

– Periodically update

– Start checkpointed image if original goes down

Prototypes: BANDWITH Calendaring Use Case

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› On-demand, policy driven QoS for mobile enterprise cloud services

– Demonstrates cross-domain orchestration between cloud and mobile network

› Portal for enterprises to configure enhanced QoS for specific cloud-based services

– Both by deployment location choice and LTE enhanced bearer

› No mobile operator administrative involvement after enterprise tenant account is set up

– Demonstrates customer service configuration portal

Prototypes: Network Slices

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Prototypes: Network Slices Demo Video

Network slices video here

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






Prototypes: Network Slices Architecture

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Despite minimal success historically, a Telco PaaS for controlling cross domain functions in operator networks show some promise due to new developments

– SDN NFV as building block technologies

– OpenStack as deployment platform

– “as a Service” movement

› Agile service development requires more than just new APIs, it requires a different approach to service development

– Agile Software Development

– Automated acceptance testing

– Devops/Continuous Deployment

› Prototypes illustrate the utility of Telco PaaS for quick service development

summary

Slide title

44 pt


minimum 24 pt

Bullets level 2-5

minimum 20 pt






› Picture on slide 3 is from

http://www.planetgeek.ch/2010/06/17/code-quality-building-

code-you-wont-curse-tomorrow/#more-1646

› Cloud Atlas prototype was developed by Stephan Baucke

and Racha Ben Ali

› Network Slices prototype was developed by Stephan

Baucke, Olof Bäckman, Vladimir Katardjiev, and Martin

Körling

› Victa McClellan kicked off and led the architecture work on

cross-domain control

Credits

http://www.planetgeek.ch/2010/06/17/code-quality-building-code-you-wont-curse-tomorrow/


















Documents

How to enable a Telephone Company to Innovate like Googlestefan/jak.pdf · ›Digital telephony/POTS ›Internet –Just concerned with user facing actions ›Call control, billing