Embed Size (px)
Citation preview
The evolution of NGNto an open service platform
Regional Workshop on Assistance to the ArabRegion for the implementation ofNext Generation Networks (NGN)
15-16 December 2009, Cairo, Egypt
InternationalTelecommunicationUnion
Marco Carugi
ITU-T SG13 Vice-Chairman
and Q.3/13 [email protected]
Outline
o NGN Capabilities
o Towards an open service platform in NGN
o Service platform standardization developments,
2Yogyakarta, Indonesia, 27-29 July 2009
o Service platform standardization developments,
including ITU-T
NGN Capabilities
3Yogyakarta, Indonesia, 27-29 July 2009
NGN Capabilities
Next Generation Services
o From vertical sylos
• Services require specific infrastructure components for their delivery
o to NGN
• Horizontal Convergence: services no more vertically integrated
• Network functions are componentised• Network functions are componentised
• Standard “capabilities” as service enabling toolkit
o NGN services standardization
• Services specified in terms of required “capabilities”
• Service definitions not anymore a requirement• Public Interest Services are a special case
4
Service Shift as consequence of NGN service vs transport stratum separation
Requirements and Capabilities of NGN
High level requirementso Y.2201 ”High level requirements and capabilities to support
NGN Release 1 service objectives” – approved in April 07• Only network related capabilities
o Y.2201 Rev.1 (formerly NGN Rel.2) ”Requirements and capabilities for ITU-T NGN” – approved in Sept 09• Includes user related and service-specific requirements• Includes user related and service-specific requirements
Detailed requirements o A number of specific Recommendations have been developed
covering the various capabilities (e.g. Security and IdM, QoS, Mobility and FMC, Accounting & Charging, Interconnection etc.)
Each specific NGN realisation may support an arbitraryEach specific NGN realisation may support an arbitraryset of services, thus requiring the implementation of anset of services, thus requiring the implementation of anarbitrary set of capabilitiesarbitrary set of capabilities
5
NGN Capabilities: Rel.1 (Y.2201) and Rel.2 (Y.2201 Rev.1)
o Transport connectivity and network components
o Communication modes
o Multicast
o Media handling (resource management and codecs)
o Access networks and network attachments
o User networks including enterprise networks
o OAM and Survivability
o Accounting and Charging
o Management
o Mobility handling
o Service enablers
o Context awareness
o Open service environment
o Profile management
o Policy managemento User networks including
enterprise networks
o Interconnection, Interoperability and Interworking
o Numbering, naming, addressing
o Identific., authentic., authoriz.
o Identity management
o Security
o Critical infrastructure protection
o Routing
o Quality of Service
o Policy management
o Content management
o IPV6 support
o Non disclosure of info across NNI and ANI
o Inter-provider exchange of user-related information
o Public Interest Services support capabilities
oo Capabilities for service specific Capabilities for service specific requirementsrequirements
6
Towards an open service platform in NGN
7Yogyakarta, Indonesia, 27-29 July 2009
Towards an open service platform in NGN
Application Network Interface
in NGN Reference Functional Architecture
Service stratum
Management Functions
ANI
Application Support Functions & Service Support Functions
Applications
Service Control and Delivery Functions
Content Delivery
FunctionsService User
Profiles
Service Control
Functions
Transport stratum
Control
Media
Management Functions
Management
Transport Control Functions
Resource and Admission
Control Functions
Network AttachmentControl Functions
NNIUNI
Transport Functions
End-User
Functions
Other
Networks
Transport User Profiles
MobilityManagement
Control Functions
IdM*
8Y.2012 Rev.1 (work in progress)
Generic concept of Generic concept of
ANI (Application to ANI (Application to
Network Interface)Network Interface)
Reusable “Capabilities” for
an (open) service environment
Applications
Reusable capabilities
Service environment
End Users3rd Parties
NGN Providers
o Reusable common set of “Capabilities” for reduced service development costso Applying the development approach from IT industry to Telecoms
o (Open) service environment for flexible and agile service creation, execution and management
• Service platform (NGN SDP / Telco SDP)• Rapid changes for satisfying the changing customer needs
• Increasing business opportunities via an environment integrating applications and telecom infrastructure
• Competing with Web companies’ service offerings
NGN resources
9
Reusable common capabilities: BT’s 21CN Service Creation Framework
� Creation of a series of reusable, common capabilities
� First 9 components launched in 2004/5
� 17 new products or enhancements based on these components launched in 2005/6
� Increased automation and acceleration of time to market for new services
� Help to contribute to cost reduction
� Some capabilities have been made available to 3rd parties, invited to develop within the BT ecosystem (3rd party-open environment)
10Source: BT
A (open) service environmentincreases the business opportunities
3rd Party applications
End user created applications
Communities
Personalisation On-Demand
Self-Service
Collaboration
11Yogyakarta, Indonesia, 27-29 July 2009
NGN common building blocks
NGN Provider services
3rd Party applications
3rd Party
Provider
3rd Party
Provider
New business models: « multi-sided model » example scenario
o NGN dynamic features and comprehensive service delivery control
capabilities are made available via MDS through ANI by the NGN Provider to 3rd Party Providers and their customers
o 3rd Party Providers can offer enhanced services to their customers
MDS Business Model
example
ITU-T Y.2212 - Managed Delivery Services (MDS)
Network
Capability+
Service+
Connection
Fee
User/
CustomerNGN
Provider
Service
Charge+
QoS, Routing
others
Cost
Network
Capability
Service
ChargeService
Connection
Fee
User/
CustomerNGN
Provider
<Current Business Model> <MDS Business Model>
A win-win situation for both 3rd Party Provider and NGN Provider
MDS
12
Telco SDP to compete with Web Companies
Enterprise and Web applications
Telco SDP
o Telco world versus Web world (with
its huge offer of Web applications)
o Telcos may become just ‘bit pipe’
providers (services Over The TOP)
o New services become a strategic
differentiator and a way to face with
decreasing voice revenuesExposure (APIs)
Telco SDP (*) as framework for a new service
deployment model
(*) IMS may been seen as separate or
complementary framework
�G� (Telecom �etworks)
Telco SDPdecreasing voice revenues
o But legacy service delivery is inefficient
and expensive
13
�G� (Telco) capabilities
Attributes of an open service environment in NGN
o “Open service environment” key attributes (ITU-T Y.2234)
• Capability exposure via standard appl.-network interfaces (APIs)
• Usable capabilities from different network domains (NGN, but also Internet/Web 2.0, Broadcast Networks, Mobile Networks etc.)
• Portable and re-usable capabilities across network domains (e.g. from Web to NGN, but also from NGN to Web)
• Flexible development of applications and capabilities by NGN
Providers, as well as Application Providers and End UsersProviders, as well as Application Providers and End Users
• Support of all types of service provision
• Support of different business models & service delivery approaches
o Enabled interworking with other service creation environments
• IN-based service creation environment (INAP, CAMEL, WIN, …)
• IMS-based service creation environment
• Open service creation environment (OSA/Parlay, OMA, …)
14
Other service creation environments - example
15Yogyakarta, Indonesia, 27-29 July 2009
Source: 3GPP IMS and OSA/Parlay
o How to open • Adopting a Service Oriented Architectures (SOA)framework from the Information Technology world, and enhance it as appropriate Telecom SOA
• Using Web Services as implementation tool set of the Telecom SOA framework (SOAP vs REST approach) • Most SOA implementations identify Web Services (WS) as
Approaches for an open service environment in NGN
• Most SOA implementations identify Web Services (WS) as the means for realizing a SOA
o What to open (exposing via standard interfaces)• NGN capabilities to Applications
Telecom APIsTo a common basic set of Telecom APIs reusable acrossdifferent service platform implementations
• NGN capabilities to other NGN capabilities
16
Find
Deploy
Service Oriented Architectures (SOA)
o SOA resources are made
available via independent
services, accessed in
standardized way
o SOA systems comprise
loosely joined, highly
interoperable services
17
Bind
interoperable services
Web Services (WS)
o WS are simple XML-based messages
for machine-machine messaging,
acting as XML-based APIs
o WS use standard Internet
technologies to interact each other
dynamically, open standards connect
disparate platforms
ApplicationsApplications
Web ServicesWeb Services
18
disparate platforms
o WS security model is well understood
o WS are loosely coupled, can be
combined to form complex services
o Market success of WS based middleware (e.g. Google, Amazon and many many others) [cloud computing and Web as a platform]
SOA enabled converged SOA enabled converged
telecom network telecom network
(�G� capabilities)(�G� capabilities)
Web ServicesWeb Services
Telecom SOA and enhanced Web Services: new challenges for the development of standards
o Key values of a SOA framework
• Cross-platform and highly reusable
o But new requirements have to supported for a Telecom SOA such as those for carrier grade reliability, performance, security
o But Web Services enhancements are requiredo But Web Services enhancements are required
• Security, policy management, addressing, service traceability
• Current WS standards are incomplete (proprietary implementations, low interoperability)
19
Status of Telco SDPs
Service platforms today
o Platforms using Web Services
with interfaces developed
between proprietary
implementations
Moves to “open” platforms
Why
o Open = Growth of service market
o Closed = Market restricted to those
using your proprietary system
Providers start openingo Controlled platforms (Walled
Garden approach)
• Usage of proprietary control
mechanisms (e.g. for
security, policy mgt)
• SDK (creation and launch)
No openness, no interoperability
o Providers start opening
• Initiatives in terms of SDP
interworking (Verizon, Qwest)
• Joint Labs ( www.jil.org)
• Leadership in standardization
(e.g. APIs in OMA)
• IMS platforms: RCS (Rich
Communication Suite) trials
among 3 French IMS Providers
20
Standardization developments
21Yogyakarta, Indonesia, 27-29 July 2009
Standardization developments
Some key items for Telecom SOA and open Telco SDP emerged in standardization discussions
o SDP architecture and key functions, including service
creation, execution and delivery
o Common basic Telecom APIs
o Capabilities (unified description, security, liability, unified
addressing, manageable register/discover/accessing, tracing)
o Agile service construction (policy-based dynamic service
composition, dynamic adaptation to traffic conditions, SLA composition, dynamic adaptation to traffic conditions, SLA
management, integration with Business Process Mgt etc.)
o Identity Management (unique identity for all user related info)
o Common data models
o Data mining based capabilities
• user’s characteristics analysis, usage information monitoring etc.
o Brokering/interworking with other domains (Service Quality
Mgt and Policy Mgt)
22
Service platforms related standardization activities
o Numerous (closed) market ecosystems (Telco Providers)
• although some moves to openness
o A number of SDOs/Forums/Consortia are involved in this area, including• ITU-T: SG13 (NGN and Future Networks), SG16 (IPTV)
• OMA : OMA Service (Provider) Environment, enablers, APIs
— APIs: Parlay Service Access (22 APIs), Parlay REST, PXPROF (OneAPIprofile of Parlay X SOAP WS (SM, MMS, Payment, Terminal location)), NGSI (Next Gen Service Interfaces)
• GSMA: OneAPI (work now brought into OMA) • GSMA: OneAPI (work now brought into OMA)
• 3GPP (SCIM, brokering)
• TeleManagement Forum: Service Delivery Framework
• OASIS: Telecommunications Services Member Section, others
• IEEE: NGSON (Next Generation Service Overlay Network)
• ATIS: Service Oriented Networks (SON)
• Others, including OMG (service description), Service Broker Forum
o It is required to fill gaps and converge/harmonize existing standards
o ITU-T (SG13) has started collaboration with other organizations
• OMA, OASIS, TMF, IEEE - plan to strengthen these collaborations 23
Initial ITU-T work items in NGN service platform area
ITU-T SG13 is increasing its activities in this area
• Y.2234: Open service environment capabilities for NGN (Sep08)
• Y.OSE-arch “OSE functional architecture for NGN” (launched in Jan09)
• Y.NGN-SIDE-Req: Requirements for NGN SDP (“Service Integration and Delivery Environment”) (launched in May09)
• Y.NGN-Web “Functional requirements and architecture of Web Service
Component in NGN” (just launched - Sept09)Component in NGN” (just launched - Sept09)
• Y.2212: Requirements of Managed Delivery Services (Jan08)
• Y.2232: NGN convergence service model and scenario using WS (Feb08)
• Deliverables based on past OCAF Focus Group activities (Dec06)
— Y.2901/Y.2902 - Carrier grade open environment model/components
Other ITU-T activities in Telecom SOA and WS include
• M.3060: Principles for NGN management (March06) (ex- ITU-T SG4)
• SOA/WS related security aspects (ITU-T SG17)
• Middleware aspects for IPTV and USN (ITU-T SG16) 24
Y.2234 : NGN Open service environment (NGN OSE)
o NGN OSE
• requires the use of standard interfaces
• opens the capabilities of the NGN to third parties
• provides a SOA enabled environment
• may be implemented via Web Services technologies
o NGN OSE high level requirements • to provide standard APIs for application providers and developers,
and potentially end users
25Yogyakarta, Indonesia, 27-29 July 2009
and potentially end users
• to provide service level interoperability underlying different networks, operating systems and programming languages
• to support service independence from NGN providers and manufacturers
• to support NGN OSE capabilities based on NGN providers’ capabilities [OSE capabilities based on application providers’ capabilities not supported in this version of Y.2234]
• to support location, network and protocol transparency• to provide secure access to NGN OSE capabilities satisfying the
general NGN security requirements
Capabilities of NGN OSE
• Registration of capabilities and services(/applications)
• Discovery by users and devices of capabilities and services and other
network information and resources of their interest
• Coordination of services with capabilities
• Composition for flexible composition of services
• Management of services and capabilities
26Yogyakarta, Indonesia, 27-29 July 2009
• Management of services and capabilities
• Development support for efficient service construction, trialing, deployment, removal
• Policy enforcement for resources protection and management, and
service personalization
• Interworking with other service creation environments
Example of “Composition”
(implemented via Web Services)
Choreography Description Language (CDL)
Parlay X
API Call
Application: Locate and Call UserApplication: Locate and Call User
27Yogyakarta, Indonesia, 27-29 July 2009
LocationLocation
CapabilityCapability
WSDL
PresencePresence
CapabilityCapability
WSDL
Session Session
HandlingHandling
CapabilityCapability
WSDL
ChargingCharging
CapabilityCapability
WSDL
Web Service
Description
Language
(WSDL)
NGN OSE positioning within the NGN Architecture
28Yogyakarta, Indonesia, 27-29 July 2009Source : Y.2234
Mapping of
�G� OSE
functional
components into
�G� ASF&SSF
functional
entities [Y.2234]
[ITU-T Y.2012] ASF&SSF FEs
APL-GW-FE APL-SCM-FE AS-FE SS-FE
�ew FE
currently
not
identif
ied
serves as an
interworking
entity between
the applications,
and services and
capabilities of
the NGN
(adapted from
[ITU-T Y.2012])
manages interactions
between
multiple
application
services (or
servers)
[ITU-T Y.2012]
supports generic
application
server
functions
including
hosting and
executing
services
[ITU-T Y.2012]
provides access and
interworking
to a legacy
IN SCP
[ITU-T Y.2012]
Service discovery optional not applicable not applicable not applicable optional
29
O
S
E
Service discovery
Service management optional not applicable not applicable not applicable optional
Service registration optional not applicable not applicable not applicable optional
Service coordination not applicable optional not applicable not applicable optional
Service composition not applicable optional not applicable not applicable optional
Service development
supportoptional not applicable not applicable not applicable optional
Interworking with
service creation
environments
optional not applicable optional optional optional
Policy enforcement optional optional not applicable not applicable optional
NGN SDP requirements - Y.NGN-SIDE-Req draft (Nov09)
Capabilities
Offered
ApplicationsUser generated applications3rd party applications
Service orchestration
NGN-SIDEIn-house applications
application layer
Service registry
3rd party access control
Adaptors
For
IDM&SSO
Policy management.
Content management.
Charging
Online/offline design tolls
Developer potal
NGN SDP functional NGN SDP functional frameworkframework
Capabilities offered by NGN(s)
Offered
by
Non-NGN
Adaptors for capabilities
offered by NGN
integration layer
Service integration
Service registry
Adaptation layer
For
capabilities
Offered
by
Non-NGNservice
creationservice
execcution
Service delivery
support
Charging
User profile
App provisioningTest environment
Service repository
Policy enforcement
30
NGN SDP requirements - Y.NGN-SIDE-Req draft (Nov09)
Table of contentso NGN SDP capabilities
• Generic capability set
• Application-specific capability sets
• Functional positioning (NGN architecture, NGN OSE)
o Requirements of NGN SDP capabilities • General requirements
• Service interface reqts across ANI, NNI and UNI
• Open service interface reqts within NGN SDP• Open service interface reqts within NGN SDP
o Appendixes• Application scenarios
• Survey of API standardisation
• Capabilities and APIs of relevant market SDPs
A number of items for further consideration (Appendix IV.5)• User access to NGN SDP from other domains (Web) and by Internet xSPs
• Role of a Web service platform for NGN SDP, including Web 2.0 APIs
• Role of NGN SDP for a Web service platform (e.g. as NGN capability negotiator)
• others31
Applications
I0+P
Applications
I0+P
Service Provider or Terminal Domain
Other SDOs’ work relevant for NGN service platform: the OMA Service Environment
32Yogyakarta, Indonesia, 27-29 July 2009
Other bindingsOther bindingsWeb service bindingsWeb service bindings 88
Enablerimplementation
Enablerimplementation
Enablerimplementation
88
Enablerimplementation
I0
I1
Policy Enforcer
To Resources inOperators, terminals, Service Providers
I2
Execution Environment (Software Life Cycle Mgmt,
Load balancing, caching, O&M ,
etc.)
Source: Open Mobile Alliance
Parlay-X Web Services specifications provide simple, abstracted telecom Web
Services based on use of network capabilities
o Part 1: "Common"
o Part 2: "Third party call"
o Part 3: "Call Notification"
o Part 4: "Short Messaging"
o Part 5: "Multimedia Messaging"
o Part 6: "Payment"
o Part 7: "Account management"
o Part 8: "Terminal Status"
o Part 12: "Multimedia conference"
o Part 13: "Address list management"
o Part 14: "Presence"
o Part 15: "Message Broadcast"
o Part 16: "Geocoding"
o Part 17: "Application driven QoS"
o Part 18: "Device Capabilities and Config"
o Part 19: "Multimedia streaming control"
Parlay-X Web Services/API specifications
33Yogyakarta, Indonesia, 27-29 July 2009
o Part 8: "Terminal Status"
o Part 9: "Terminal location"
o Part 10: "Call handling"
o Part 11: "Audio call"
o Part 19: "Multimedia streaming control"
o Part 20: "Multimedia multicast session management"
o Part 21: "Content management"
o Part 22: "Policy"
P a r l a y - X A r c h i t e c t u r e
P a r l a y - X A p p l i c a t i o n s
P a r l a y - X W e b S e r v i c e s
P a r l a y G a t e w a y
P a r l a y A p p l i c a t i o n s
P a r l a y A P I
P a r l a y - X A P I
N e t w o r k P r o t o c o l s
N e t w o r k E l e m e n t s
Other SDOs’ work relevant for NGN service platform: the IEEE NGSON framework
Source: IEEE NGSON34
Example of NGSON implementation
Key Aspects:Context awareness, addressing, routing,discovery, registration, composition, self-organization etc.
AD AdvertisementCRM Customer Relationship ManagementIDM Identity ManagementOCS Online Charging SystemSR Service Router
35
Source: IEEE NGSON
Internet / 3rd Parties / Enterprises
OSS/BSS Platform
s
Service
Layer
Control
Layer
SS7 SIP / IMS
Application ServersSCE Application suites
SDPSDF
IMS
Other SDOs’ work relevant for NGN service platform: the TMF Service Delivery Framework
36
Device /
Client Layer
Transport
Layer
Access
Layer
IP / MPLS / PBTSONET / SDH / WDM
Wireless:2G, 3G
WiFi, WIMAX
Wireline:DSL, Cable, FTTx, PSTN
OSS/BSS Platform
s
Control
Layer
Source: TeleManagement Forum
o Towards an open service platform in NGN (Telco SDP)
• Service Oriented Architectures (SOA) as framework
• Web Services (WS) as implementation tool set
o Integrated applications –telco environment enables new business opportunities and a way to “compete” with Web companies and applications (will this be enough ?)(will this be enough ?)
• but bring new challenges to standards development
Conclusion
37Yogyakarta, Indonesia, 27-29 July 2009
• but bring new challenges to standards development
o Numerous SDOs, Forums and Consortia involved
• Required standards convergence and harmonization
• Increasing involvement of ITU-T in this area
• NGN OSE, NGN SDP and other developments
• Collaboration started with other SDOs to integrate relevant specifications within ITU-T NGN standardization framework and enable an open service platform in NGN
Thank you for your attention
38Yogyakarta, Indonesia, 27-29 July 2009
Questions ?
