NGN service revenues

Download Report

Transcript NGN service revenues

IPsphere Forum Backgrounder
Kevin Dillon
Chair - IPsphere Forum
1
Agenda
• Our collective NGN “mission”
• IPsphere Forum role in the NGN mission
• IPsphere framework & relationship to other NGN activities
• Overview of IPsphere work program structure, priorities
• Energetic discussion 
2
Mission of the NGN…
NGN service
revenues
Current service
portfolio
revenues
3
Quest is $$$; NGN technology is
means to this end
Types of
Services
Only new service revenue is justifying any
significant amount of new network infrastructure
Processing
Growth opportunity via per-service
transactional charging models (a la SMS)
Content
Transport
Current telecom
service portfolio
Operator X
Access
Current telecom
service portfolio
Operator Y
Current telecom
service portfolio
Operator Z
Need for pan-operator
co-operation to provide
a consistent platform
for network-effect to
drive uptake of higher
level service offers
Conventional
Telecom revenues;
Currently ~ $240
B* in US but low
growth & under
increasing
pressure
* CIMI Corporation
4
Business challenges of the classic
Internet model
Types of
Services
Processing
Content
Significant service revenues accrue to retailers,
advertisers, search engines etc. – but not to network
service providers
Exploitative
“overlays” suppress
network operator
revenue
opportunities
Challenge #3: Facilities investments
tend to benefit all users, hard to
justify premium service charges
Transport
Challenge #1: Fixed
access rather than
per-service charging
Access
Challenge #4: Poor trust
model to screen
participating endpoints
Internet service
provider A
Internet
service
provider B
Internet
service
provider C
Network offers very
little beyond
ubiquitous connectivity
- estimated best case
US revenues ~ $80 B*
Challenge #2: No commercial
approach to inter-ISP service
collaboration beyond “best effort”’
* CIMI Corporation
5
Possible Business Models
Types of
Services
Telecom can, must, will carve out a role in markets
consuming “Content” & “Processing” offers
Processing
Content
NGN Content,
Processing “direct”
service revenues
Model B: provide pan-operator fulfillment platform
for other’s Content/Processing service offers
NGN Content, Processing “indirect” service revenues
Transport
Access
Model A: integrate own Content/Processing
offers directly with Access, Transport
service portfolio
NGN Access,
Current
telecom
Transport
service
service portfolio
revenues
NGN Access,
Current
telecom
Transport
service
service portfolio
revenues
NGN service
revenues
NGN Access,
Current
Transporttelecom
service
service
portfolio
revenues
6
Potential Impact…
Comparative US Market Data Revenue
600.00
500.00
$Billions
400.00
IPsphere
Status Quo
300.00
Internet subsume
200.00
100.00
0.00
2004
2005
2006
2007
2008
2009
2010
Year
CIMI Corporation
7
Where the IPsphere Forum fits in
•
The IPsphere Forum is architecting a framework for worldwide,
pan-operator IP services
– Network operators & other service providers free to create multiple
service, business relationships using the same infrastructure
– Interconnect with users and with each other in a way suitable for each
such relationship model supported
•
The goal of the IPsphere work is to frame a business-level
exchange among network operators & service providers, and with
users
– Complements (but not replace) protocol signaling at the network control
level
– Business-level exchanges provide a reference for properly slaving service
creation to business relationships
•
The IPsphere Forum seeks to accomplish this by adding a new
layer to a traditional network architecture, a business (or “service
structuring”) layer
8
IPsphere Forum Membership
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Alcatel
America Online
Bezeq
Brasil Telecom
Brighthaul
BT
Cellcom
China Unicom
CIMI Corporation
Cisco Systems
Colubris Networks
Datapower
Ericsson
fmc.service
France Telecom
GeoTrust
Huawei
Hewlett Packard
IBM
Internet 2
Juniper Networks
Korea Telecom
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Level 3
Lucent Technologies
Marconi
Masergy
Nexagent
NexTone
Nortel
Oracle
Packeteer
Polycom
Qwest
Red Zinc
SBC
Siemens
T-Com
Time Warner Telecom
T-Systems
Telenor
Tellabs
Telstra
Ulticom
Verizon
9
IPsphere Forum Board
•
•
•
•
•
•
•
•
•
•
•
•
•
Omar Elloumi, Alcatel, Secretary
Keith Dickerson, BT, Board Member
Monique Morrow, Cisco, Vice Chair
Christian Jacquenet, FT, Board Member
Yi Zhao, Huawei, Board Member
Kevin Dillon, Juniper, Chairman
Tom Walsh, Lucent, Treasurer
Donal Morris, Red Zinc, Board Member
Cornelis Hoogendorn, Siemens, Board Member
Roger Wenner, T-Com, Board Member
Sten Nordell, Telenor, Board Member
Andy Malis, Tellabs, Board Member
Douglas O’Leary, Verizon, Board Member
10
IPsphere is a Business Layer
above Network
1) Each Individual Provider registers service “element” offers
2) Retail Providers discovers service “elements” required of others
3) Negotiate & establish contracts for collaboration in the overall services
4) Individual Providers provision their own networks per their ‘offers’ entered in
contracts
IPsphere Service Structuring Stratum
IPsphere
Business
Layer
SOA - Web Services Framework
CNI
N
M
S
Provider A
ICI
N
M
S
Provider B
ICI
N
M
S
ICI
Provider C
N
M
S
CNI
Provider D
11
IPsphere Pan-provider
Cross-network Service
Structuring based on SOA
Service
Structuring
Endpoint X
IPsphere
A
Cross-network Traffic
Handling based
Policyon&standard
protocols
Control
Traffic
Handling
IPsphere
C
Endpoint Y
IPsphere
B
IPsphere framework is made up of a federation of providers who share a Service Structuring Stratum
connection for business coordination. The interconnected networks use standard packet protocols for
signaling for services, but at key points in & between network jurisdictions there are ‘IPsphere interface
points’ where business relationship management must be structured.
A provider makes an explicit business decision to participate in a pan-provider service, and that decision
is communicated by publishing a list of “Elements” representing service offers the provider is willing to
make & the commercial conditions under which the offer is valid . These are combined with Elements
from other providers to create services.
12
IPsphere Service Decomposition
Application
Endpoint
Content /
Processing
Endpoint
Producing Resource
Consuming Resource
Access /
Projection
Transport /
Connection
Access /
Projection
IT oriented
services
NW oriented
services
A typical application or retail service is made up of a series of “Elements” from one or more of the
classes shown above. Endpoint Elements represent either service users/access points or
content/processing capabilities (storage, grid, ASP, etc.). Access/Projection is the Element that
represents the “last mile” connection to the user; it could be DSL, cable, wireless, etc.
Transport/Connection represents the core network connecting ingress & egress Access/Projections.
Each Element used to create a service is contributed by a provider by publishing it via the Service
Structuring Stratum. The process of service creation in the IPsphere model is the process of
assembling published Elements into services/applications.
An Element is also a software link between the IPsphere’s business-layer functions and an operator’s
mechanisms for controlling the behavior of its network.
13
Elements, Components, Messages
Service
Transport/
Transport/
Transport/
Connection
Connection
Connection
Access/
Access/
Access/
Projection
Projection
Projection
Endpoint
Endpoint
Endpoint
A service is made up of a series of “Elements”, “Access/Projection”, “Transport/Connection”, and
“Endpoint”. For each element, there are a series of “Components” representing the phases of
service setup. These are “Setup” for initial business negotiation, “Execute” for actual service
creation on the network, and “Assure” for the ongoing operational phase of the service.
Each Component phase consists of four message steps: “Start,” which initiates the Component,
“Negotiate,” which exchanges parameter values until a set is agreed upon, “Complete”, which
signals the end of a Component activity, and “Alert,” which is an out-of-sequence indicator of a
problem that has arisen
14
The IPsphere SOA
Translate order to template
Identify partner carriers/Elements
Setup Start A/P
Setup Complete A/P
Setup Start T/C
Setup Complete T/C
Setup Start C/P Element
Setup Complete C/P Element
Execute Start C/P Element
Execute Complete C/P Element
Execute Start A/P
Execute Complete A/P
Execute Start T/C
Execute Complete T/C
Assure Start A/P
Assure Start T/C
Assure Start C/P
Service
Structuring
Stratum
Service
Directory
(eg.UDDI)
Endpoint
(C/P)
Element
T/C
Element
A/P
Element
Administrative Owner
Service ‘Decomposition’
15
Summary of Principles
•
The IPsphere framework divides a service into Elements; Access/Projection,
Transport/Connection, and Content/Processing.
•
A given service may have any number of elements of any of these types as needed, and services
are created by combining Elements contributed by providers
•
A provider participating in the IPsphere framework will contribute at least one Element for at
least one service, but will likely contribute many elements for many services
•
The contribution will be made by publishing a set of web services into directory – or registry structure within the SSS VPN, supporting all of the components associated with each
element/service combination the carrier wishes to offer
•
The creation of a pan-provider service involves a web-service-based exchange of messages
between the administrative owner who coordinates the service on behalf of the customer, and
the providers who contribute elements to the service
•
Each Element is a software “method” or module that is published as a web service and which links
to underlying network management or policy management capabilities to actually control the
service
•
This takes place at the Service Structuring stratum of the IPsphere reference architecture.
Other Standards Organizations & Industry Fora are responsible for processes in the Network
Control, and Traffic Handling strata
16
IPsphere SOA federations &
Trust/Security
IT application
SS
ENI
TH
SS
ENI
ENI
NP&C
NP&C
TH
ICI
SS
ICI
NP&C
TH
1. All clients start behind a “Trust Barrier”: akin to being “in the lobby”
ENI
2. To get inside clients present credentials, and receive authorizing “token”: akin to a “badge”
3. “Federate” other clients participating in the activity: akin to populating the “meeting room”
4. Provide network environment for the exchange – akin to projector, whiteboard, audio…
17
What IPsphere Forum Is…and Isn’t
Doing
•
IPsphere Forum deliverable: An agreed framework by which
network services are framed into a business context by linking
service creation with service ordering and fulfillment
•
IPsphere framework is based on SOA/WS principles for the
exchange of business information
– Makes it easy for it to manage the elements of higher-layer services that
require identity management and reliable communications, including grid
computing and ASP services
•
IPsphere Forum is NOT developing strategies to create the actual
services within the network, provide for QoS, or manage
resources at the physical level
– IPSF is compatible with and leverages current & emerging standards in
these domains, and will work to ensure it stays that way
– We may uncover gaps, augmentations to these standards, and will liaise to
pursue these as required
IPsphere Forum is NOT developing an alternative to the Internet – it is developing an alternative
to the classical “Internet” business framework being applied to non-Internet services
18
IPsphere & related NGN programs
IPsphere Forum
focus
Outcome is an IT
framework; not a set of
network specifications
Service
Structuring
Stratum
Business framework via which NGN
capabilities can be monetized to the
optimal extent – leverages SOA work
(W3C, OASIS, LAP etc.) into Telecom
NGN context
NW Policy &
Control
Stratum
Network control & intra-operator
policy mechanisms; IMS, TISPAN,
TMF etc.
Traffic
Handling
Stratum
“Bearer” mechanisms from
responsible bodies such as
IETF, ITU, MFA, DSL Forum
etc.
19
IMS & IPsphere relationship
Administrative
Owner
IPsphere pan-provider service
composition & federation
SERVICE
PLANE
SOA/WS ‘loose coupling’
SCIM
SCIM: Service Capability Interaction Manager
MRFC: Multimedia Resource Function Controller
CSCF: Call Session Control Function
MRFC
HSS: Home Subscriber Server
HSS
I-CSCF
PDF: Policy Decision Function
BGCF: Breakout Gateway Control Function
MGCF: Media Gateway Control Function
HLR
P-CSCF
BGCF
PDF
MGCF
MGW: Media Gateway
GGSN: Gateway P\GPRS Support Node
CONTROL
PLANE
HLR: Home Location Register
S-CSCF
SGSN: Serving GPRS Support Node
Node B
BTS
RAN
WLAN
RNC
BSC
MRFP
MG
W
MG
W
SGSN
GGSN
PSTN
PLMN
Intranet/
Internet
TRANSPORT PLANE
20
IPsphere Forum structure
IPsphere Forum Board
Work Program committee
7 use cases validated
Generic use case template drafted
Several use case contribs in progress
Business Dimensions WG
Marketing committee
Chair*: Ariana Nikitas (Tellabs)
Vice chair*: Todd Shimizu (Juniper)
Chair: Kevin Dillon (Juniper)
Vice chair: Donal Morris (Red Zinc)
Reference Architecture WG
Chair: Ian Stanley (Telstra)
Vice chair: David Weinberg (Juniper)
Execution framework agreed
Early implementation in testing
Public showcase in planning
Reference Arch complete
Service decomposition model agreed
Data model, endpoint model, & various
SDO liaisons in progress
Reference Implementation WG
Co-Chairs*: Matt Ford (BT), Ron Jacob (Brighthaul)
Co-Vice chairs*: Phil Jacobs (Cisco), David Page (Nexagent)
* Indicates interim arrangement
21
Work Group roles
•
BDWG charter: primacy of business aspects in the IPsphere
Forum through development & tuning of overall “business
framework” reconciling the perspectives of both service users and
service providers, and the parsing of member contributed (& board
sanctioned) use cases through the “business framework”
•
RAWG charter: the technical framework of the IPsphere Forum
through development & tuning of overall reference architecture &
associated specifications. Technical framework is tuned via
ongoing validation against IPsphere BDWG “use cases”, IPsphere
RIWG “execution framework”
•
RIWG Charter: Prove and tune technical framework via actual
implementation, also showcase to promote & evangelize IPsphere
functionality
•
Leverage & liaisons with related SDO’s handled via BDWG for
commercially oriented topics, & via RAWG for technically oriented
topics
22
Conclusions
•
NGN business model can’t follow the classical Internet framework
•
Substantial, and urgent, need for a business framework for IP
NGNs that enables both providers & users to meet their economic
and technical needs optimally
– And for the broadest possible set of network, content & application
services as facilitated by NGN technologies
•
IPsphere Forum work on ‘Business of IP’ complements & leverages
telecom industry NGN standardization activities already underway
•
IPsphere Forum promotes the application of Service-Oriented
Architecture (SOA) approaches to network service federation,
publication and consumption
•
The IPsphere Forum is working to expand its international
presence and participation, especially in North America, Asia and
Africa
23
www.ipsphereforum.org
24