Core Network & Enterprise Nexus 1 Jack E. Brown 9/29/2009 SOA Reference Architecture
9/29/2009 Jack E. Brown 2 Cable Architecture Overview Headend Hub Internet gateway Core Router Xport HFC GR303 gateway Xconnect Xport Hybrid Ckt/ VoIP D A T A Router GigE switch C O M B I N E R / S P L I T T E r Data, VoIP, Multimedia CMTS Servers Firewalls Analog satellite Native data, Analog video, Digital video Synchronous TDM CMTS rcvr analog mod Downstream Fiber Analog off-air ASI demod analog mod Coax QAM Fiber Node GigE Xport Local pgms analog mod Digital HDTV satellite Upstream Fiber V I D E O Local VOD Servers B R O A D C A S T Internet rcvr MPEG mux 2-way Amps DWDM SONET/SDH ATM GigE RPR DVB-ASI DVT demod Digital HDTV off-air Tap WEB cache servers Local pgms Drop Broadcast Video Appliances
NIU (Ckt Telephony)
Cable Modem (high speed data)
O N D E M A N D V I D E O GigE switch HDT Xconnect VOD Servers PacketCable Ckt voice Xport Xport Router V o I P Signal gateway & V O I C E Broadband Multimedia CMS Media Gateway Xport OSSs* Application Servers Xconnect OSSs*
IP address mgmt
Ckt Switch PSTN Circuit
9/29/2009 Jack E. Brown 3 PacketCable 1.5 Architecture Framework
9/29/2009 Jack E. Brown 4 PacketCable 2.0 Reference Architecture
9/29/2009 Jack E. Brown 5 Core PacketCable 2.0 Architecture
9/29/2009 Jack E. Brown 6 Cellular Integration
9/29/2009 Jack E. Brown 7 PacketCable MultiMedia and Converged Services 3RD PARTY SERVICES PCP Web Portal SCP PARLAY Telephony Application Manager Supplemental Telephony Servers Non-Telephony Application Servers APPLICATION LAYER APPLICATION LAYER OSA-GW IM-SSF HSS (USER PROFILE) SIP Managed IP Network Service Broker ENUM CSCF SESSION CONTROL LAYER COPS or DAIMETER SIP Session / Border Controller BGCF PCMM Policy Server MGCF MRFC SG SIP SIP COPS CMTS DOCSIS Protocols (NCS/SIP) Media Server MG HFC Access Network Mobile Gateway ENDPOINT AND MEDIA GW LAYER MSO Relationship: Wireless Provider sMTA or eMTA Legacy Fixed and Mobile Networks Mobile Access Network 802.11 AP
9/29/2009 Jack E. Brown 8 OpenCable The OpenCableproject is a concerted effort by cable operators to:
Create a common platform for interactive services, programming, and advertising on retail and cable devices;
Support home networking for cable content and services;
Encourage supplier competition and innovation.
The OpenCable specifications describe an interactive digital cable platform comprising: Baseline core functional requirements for digital cable ready “host” devices;
A “middleware” comprising a set of common application programming interfaces (APIs);
The hardware interface between the host device and a removable security module (the “CableCARD™”);
Copy protection and security requirements; and
Optional extensions for host devices, including Home Networking, and DVR.
9/29/2009 Jack E. Brown 9 OpenCable Services and ApplicationsOpenCable Platform services may include:
Electronic program guides (EPGs);
Interactive personal video recorders (DVR);
Interactive sports and game shows;
Impulse pay-per-view (IPPV);
Communications utilities such as e-mail, chat, and instant messaging;
Caller ID presented on the TV;
Interactive games; and
Interactive services such as voting and polling within a television show, shopping (television commerce, or “T-Commerce”), and home banking.
9/29/2009 Jack E. Brown 10 OpenCable Target Market
Content Developers: TV writers, directors and producers; ITV application developers; production houses; graphic designers.
Copyright holders: Studios; producers; programmers sports leagues; music labels; video game companies.
TV Networks: Cable services and broadcast networks.
Advertisers: Advertisers, agencies and marketers.
Cable Operators: MSOs and local cable systems.
Device makers & retailers: Digital TVs; HDTVs; DVRs; set-top boxes; portable TV players; mobile phones.
9/29/2009 Jack E. Brown 11
Traffic Provisioning Billing Policy Broker BPM Service Registry Security Data VNO B2B - Enterprise Aggregator Billing Data Provisioning Orchestrated Applications Traffic Traffic Traffic Traffic Traffic Traffic Traffic Data Provisioning Data Provisioning Data Provisioning Data Provisioning Data Provisioning Data Provisioning Data Provisioning Billing Billing Billing Billing Billing Billing Billing Example High LevelSOA Reference Architecture Liberty Alliance Federation Service Bus WS IMS – Pkt Cable & Enablers 3rd Party Apps Legacy Apps IMS-Pkt Cable Apps IN Apps Legacy Network Elements Wireline Wireless Jack E. Brown 9/29/2009 12
9/29/2009 Jack E. Brown 13 Definition of a “SOA Service” Service Definition Policy Engine SLA O/L Control Access Rights ResourceSharing Content Filtering
The service contract specifies the “rules of engagement”, i.e. the purpose, functionality, constraints and usage of a service
A Service interface provides an explicit means for the consumers of a service to access its functionality according to the contract it offers
The implementation is the actual functionality produced by the service
14 Jack E. Brown 9/29/2009 Application Infrastructure
Composite Application Framework
Business Service Orchestration
Governance and control
Service discovery, publishing and security
Message routing and transformation
Application Infrastructure vs. Service Infrastructure Sharing Across Multiple Organizations
15 Jack E. Brown 9/29/2009 App2 App 1 Legacy App 1 CSCF MMSC SMSC CDF Blended Services Approach
IMS – Pkt Cable/ VoIP/Circuit-Switched
IMS & Pkt Cable 2.0 is an access-agnostic standardized layered infrastructure which enables rapid deployment of new IP-based services across all networks, while maintaining a common policy management for service access
Service Oriented Architecture (SOA)
SOA is a technology strategy that organizes the discrete functions contained in internal or third-party applications into interoperable, standards-based services that can be combined and reused quickly to meet business needs.
A federated services framework that leverages SOA across new and existing networks to dynamically deliver composite services across a heterogeneous IT and core network service application ecosystem
Layered SOA Reference Architecture Logical View 16 Jack E. Brown 9/29/2009 SOA reference architecture should account for processes, capabilities, services, data access, and network access
9/29/2009 Jack E. Brown 17 Layered SOA Reference Architecture Logical View Composite business services are typically created using high-level programming interfaces like workflow, business process management tools, and portal technology. These high-level programming techniques consist principally of configuration, and they are metadata driven. Presentation Services provide separation between the way content is transported and the way it is formatted for delivery to the user. In a SOA environment, content will generally be transported as XML. The content may be delivered in many different formats, depending on the device being used end user. These formats may include HTML, WML, cHTML, and others, with the capabilities of specific devices further complicating the ways that the content should be formatted. Presentation services may also entail personalization of content for specific users as well as for their devices. Architecturally, the shared business services layer begins the representation of two key paradigms, consolidation and rationalization. Consolidation refers to the ability to reduce or eliminate business functionality that is duplicated partly or wholly in different parts of an enterprise. Rationalization refers to the standardization of business functionality.
9/29/2009 Jack E. Brown 18 Layered SOA Reference Architecture Logical View The Data and Access Services layer will provide means to expose data from a diversity of software suites, custom applications, and data sources deployed throughout. In general most Service Providers, have embraced a long list of retrieval strategies such as Extract, Transform, and Load (ETL), message-oriented middleware (MOM), Object brokers, data integration, .NET, SOAP, etc. The intent of Data and Access services layer is to integrate these different access strategies into a single access technology The Network Access Services Layer offers features that guarantee the security, stability, and performance required by network carriers and demanded by subscribers. In other words it provides an abstracted network service development platform that hosts network based services that can be connected to the SOA, via the service bus, while providing connectivity into network related systems for telephony applications
9/29/2009 Jack E. Brown 19 DATA AND ACCESS SERVICES LAYER
9/29/2009 Jack E. Brown 20 Network Access Services Layer connecting the telecommunications network architectures to the SOA environment
9/29/2009 Jack E. Brown 21 HSS Packet CSCF Rating Engine Legacy SSP SMSC MMSC Policy Broker BPM Service Registry Security Content Mgmt OTAA/P Device Mgmt Client Mgmt ISC / SIP ISC / SIP LDAP/SQL TL1 / MML TL1 / MML CAP CAP AIN AIN LDAP XML XML Billing Billing External Gateway And other XoIP functions Reference Architecture – A Bit More Detailed xxxx Wlireline IN APPs Enterprise APPS IMS –OCAP Pkt Cable APPs Orchestrated Apps Billing ANSI-41 LDAP/SQL Web Services Prepaid (CAP) Diameter Rf/Ro BAF AMATPS Web Services Web Services Web Services Sh Data Federation BILLING SCIM / IMSSF PROVISIONING WS WS Traffic Data ANSI-41 Prepaid (CAP) Billing Diameter Rf/Ro BAF AMATPS LDAP Provisioning Sh HLR MPC Network 1 Network 2 Network 3
22 Jack E. Brown 9/29/2009 Federated ESB Deployment
9/29/2009 Jack E. Brown 23 Service Provider Perspective -- What is SDP? At the highest level, the Service Delivery Platform (SDP) is a set of enabling capabilities that allow new services to be rapidly and efficiently plugged into the carrier infrastructure.
SDP sits between the carrier’s network / IT infrastructure and the end user applications.
SDP exposes the capabilities of the IT and Network infrastructure to applications in a standard way.
SDP is not: a network element, an individual platform, an OSS/BSS solution, an access technology, or a competitor to IMS
While some industry SDP implementations are IMS specific, SDP is broader than IMS. SDP allows applications to utilize capabilities of IMS (e.g. session setup), non IMS (e.g. get location), and IT (e.g. send a billing event) infrastructure.
9/29/2009 Jack E. Brown 24 Service Provider Perspective -- The SDP Concept The Service Delivery Platform Concept Is A Fundamental And Far-reaching One An SDP mediates between the network and the converged applications and services that leverage it
It is an exposure, integration, and execution framework
facilitates the connection of high-level services with core network functions in a reusable way
Consistently manages the execution of these services
Maximizes the access investment by provides an access-agnostic integration substrate for IP and non-IP services
An SDP enables developers and content providers
It includes service creation tools to easily and efficiently create new services
It includes orchestration, brokering, and composition services to allow efficient recombination of existing Network and application capabilities into new, more flexible services
An SDP puts additional structure on the service layer itself
It breaks the service layer into logical tiers
It partitions key capabilities, such as user identity, into these tiers and puts defined interfaces on them
It interfaces to OSS/BSS
It supports flexible workflow engines for new service development, and potentially also for provisioning, ordering, billing, and care
It can offer a tighter mapping onto device capabilities
Publicly-exposed APIs Partner applications Third-party Web Services VoD Switched Video Music Downloads Applications & Services tier Well-defined, flexible, and reusable enabling infrastructure Service composition, orchestration, policy, routing, user profiling, identity, common data models, content management, and well-defined services interactions OSS/BSS Enabling function tier Subscriber Data Location Messaging Presence Core Network (IP, non-IP) Core network & enterprise capabilities Enterprise Network (IT) SMSC MMSC MSC EAI UBP Amdocs
9/29/2009 Jack E. Brown 25 An Example SDP Logical Framework View SDP Logical Framework composed of 3 key planes: Services Layer, Exposure Layer, Service Life Cycle
Exposure layerprovides a secure and managed access to the services by managing and enforcing 3rd party SLAs; it packages the underlying services for external consumption.
Service layerprovides an abstraction of network and IT capabilities using SOA principles in order to facilitate re-use and composition; it also provides a flexible execution environment to support multiple service delivery models.
Service Life Cycle Mgmtprovides an overarching end-to-end management of the various phases of the service. It refers to the governance and the business processes that drive the work flow management within the services layers
Network & IT Layer provides the actual underlying physical infrastructure.
SDP Framework SOA dictates peering across services not layers 25 Restricted – Proprietary – Internal Use Only
9/29/2009 Jack E. Brown 26 Logical Framework – a more detailed view in 2D
A service is defined as an autonomous, self-contained logic that exposes a well defined interface that facilitates re-use and composition AND common communication infrastructure
This is different from end-user service; End User’s generally think about Caller ID, Conferencing, Voicemail, Family Tracking etc
Rationale for decomposition Decomposed services
Helps in definition of service contracts
Helps in understanding impacts of business logic on service definitions for short-term and long-term
Allows evaluation of platforms and integration points
Allows evaluation of scalability, reliability requirements
Facilitates in distributing services across platforms to deliver optimal performance
Forms basis for composing coarse grained services
Allows a focused demarcation of the services with the organizational boundaries
Helps in focusing on the latency requirements of services. From Low latency (Network) to increasing response times (Business)
Network Services are network capabilities abstracted in form of repeatable logic, reusable by a wide spectrum of internal & external applications. For e.g. call control, sendSMS, etc.
Application Services are application logic abstracted in form of services, reusable by a wide spectrum of internal and external applications, in order to compose integrated applications. For example, conferencing, presence, group mgmt, etc.
Common Services provide service control and leverages capabilities across both IT and network domains. For example, policy mgmt, pre-paid charging, data access, etc.
Business Services implement the business processes (and functions) to enable a rapid service creation, deployment and monitoring environment.
Segment Specific Apps Content Services includes specific services that facilitate life cycle management of content. Composite Services & Apps Composite & Segment specific servicesare composed using foundational network, application, common and business services (For e.g. – Messaging service that abstracts different messaging types to the 3rd parties, SMS, MMS, etc.) Business Services Content Services App Services Network Services Common Services Jack E. Brown 9/29/2009 27 27
9/29/2009 Jack E. Brown 28 Service Creation is one of the key enabler for addressing time to market drivers and developer ecosystem
In order for 3rd party developers to create applications, three main artifacts are required:
Service Specification (Exposure)
Provide service API’s
Web Services, etc.
Make available IDE’s, Simulation tools, device emulators
Service Catalogs (SLA based exposure of services)
Service Specifications and Documentation
Exposure mechanisms should be independent of any specific toolsets
Service Creation Tools (Environment):
Software development tools that use Graphical User Interfaces for creating, developing and testing telecommunication service applications, minimizing time to market for new services.
Support open source tool sets that developers can use to create services e.g. Eclipse, NetBeans, .NET, Ruby On Rails, IBM’s Websphere Rational® (BMF), etc
Provides an environment for Application Testing
Simulation tools, device emulators
Incubation Environment for product trials & testing.
Not all applications would require incubation testing or simulation tools
Service Specification (Exposure) Service Creation Environment Service Testing (Execution / Simulation) Service Certification & Deployment Legend 3P Environment Service Provider
9/29/2009 Jack E. Brown 29 SLA Mgmt. Location Movies Charging Performance Presence/Avail. Music BI Fault Monitoring Messaging Images Usage Mgmt. Other Other Other Other Services Mash-ups Services Testing & Certification End-User Services Consumer Services Business Services Access Management Policy Management Service Catalogue Service & Application Management Service Reporting Partner Management SOA Management Design-Time Governance Run-Time Governance Lifecycle Governance SOA Governance SOA Repository & Business Service Registry, Governance Interoperability Framework (GIF) Service Orchestration Service Adaptors Content Adaptors BSS Adaptors OSS Adaptors SOA Enablement Network Gateways Network & IT Service Elements
30 Service Delivery Platform (SDP) Services Mash-ups Services Testing & Certification Consumer Services Business Services A standards based architectural blueprint for development, deployment, integration and management of converged services User Equipment Plane Application Plane Service Delivery Plane Content Management & Delivery User Interaction & Presentation SDP Governance SDP Management Platform Support Functions Service Orchestration Subscriber Data Brokering Content IT Service Enablers Network Service Enablers Business Support Systems (BSS) Operation Support Systems (OSS) SIP OSA-Parlay SS7 Web Services Access Gateway Other Service Control Plane IMS Network Cable Network Legacy Network Network Backbone Circuit Backbone IP Backbone Real-Time IP Backbone Jack E. Brown 9/29/2009 1 October 2009 30
9/29/2009 Jack E. Brown 31 TM Forum NGOSS Framework 31
9/29/2009 Jack E. Brown 32 Operations Level 2 Processes The above figure is shown with Level 2 processes visible. Note, in general, a Level 2 process is part of a vertical, and also a horizontal, Level 1 process. Hence level 2 processes can be reached in the process hierarchy by either path. However, whichever path is uses, a Level 2 process is “stretched” across several vertical levels. This is because the process concerned is need in several vertical levels 32
9/29/2009 Jack E. Brown 33 ITU-IETF Business Architecture
9/29/2009 Jack E. Brown 34 Integration Framework When it comes to integration of a set of OSS products, where almost every component has to interact in several ways with most of the others, the number of point-to-point integration modules will become too many. And when including the often significant number of legacy applications in operation at a Network Operator the situation gets even worse. In the figure below a common type of OSS system map is visualized: A typical set of point-to-point integrations 34
9/29/2009 Jack E. Brown 35 Integration Framework Due to the “mess” introduced by the large number of point-to-point integrations the concept of a message bus supporting the exchange of messages between components attaching to the bus was introduced. This significantly reduces the number of integrations, since the component only integrates with the bus itself (figure below): The message bus concept 35
9/29/2009 Jack E. Brown 36 Integration Framework NGOSS and OSS/J NGOSS and OSS/J lay the foundation for OSS middleware components market by defining industry architecture and interfaces. TeleManagement Forum’s eTOM® model provides the processes outline for OSS/BSS systems. The model is widely deployed in the industry. J2EE, XML and Web Services are the main technologies suggested for use with OSS/J. Technology Choices.
9/29/2009 Jack E. Brown 37 OSS/J Architecture and APIs Functional API status in different verticals The above figure provides an overview of the OSS/J roadmap of APIs as defined through their corresponding JSRs and within a Fulfillment, Assurance and Billing context. It describes the current scope of work as well as the future one according to the color legend. The APIs highlighted in green have either had their corresponding JSR approved with final release, or are in maintenance mode. The APIs highlighted in yellow have their corresponding JSR approved by the Java Community and their specification as well as reference implementation and TCK are being developed through the Java Community Processes. 37
9/29/2009 Jack E. Brown 38 OSS through Java™ list of core APIs
9/29/2009 Jack E. Brown 39 JSR-264, the Order Management API.
9/29/2009 Jack E. Brown 40 Integration Framework Example of a WEB Services Infrastructure Illustrating Service Provisioning Using A Business Process Engine 40
An SOA Reference Architecture Should
Define the framework for the architecture and design efforts of all projects on the SOA roadmap.
Provide traceability from business objectives through architecture to
Provide a common vocabulary to communicate overarching SOA
architecture principles and direction across multiple communities including Enterprise and Network Architecture teams, Domain teams, management, and business groups.
Provide the means against which to measure architectural compliance of the work product.
41 Jack E. Brown 9/29/2009
An SOA Reference Architecture 42 A Reference Architecture may be related to and support the following Business Drivers And Objectives:
Seamless experience across sales and service touch-points.
Take cost out through process simplification.
Deliver IT solutions/services to meet business needs.
Manage business risk and government compliance.
Deliver a simplified and rationalized product portfolio on time.
Strategic Objectives may be addressed through the implementation of a common set of Business Services that are exposed within the Enterprise and Network domains. In this way, 3rd party application developers and services providers, Affiliates/Partners, sales, and service may all access the same data, network, and business functions through these common Services. Jack E. Brown 9/29/2009
An SOA Reference Architecture 43
As a result, a consistent view of the customer and a consistent set of operations that may be performed on or for the customer will be presented to all parties.
Synergies are achieved through the reduction of redundancy and through increased re-use. With this reduction in redundancy comes agility to move more rapidly in changing environments, since the logic within the services only needs to be changed and tested in one place.
Business Service interfaces may also be used to hide the complexity of the back-end systems, workflows, and network capabilities from the 3rd party ecosystem and end user communities.
Jack E. Brown 9/29/2009
An SOA Reference Architecture 44
When Services are created as coarse-grained interfaces that represent business level transactions, complexity is also reduced for the client applications, since one call to a service may replace many lower level API calls.
The complexity of workflows may be addressed through the use of Business Process Modeling and Execution tools that represent tasks at a level that is higher than that of raw code.
One of the goals of the Reference Architecture should be to define a flexible, agile SOA that will integrate the network and IT domains and will support rapid development of applications to meet business and customer needs.
Jack E. Brown 9/29/2009
45 An SOA Reference Architecture
A rich set of Business Services that are accessible throughout the Enterprise and Network domains using platform-independent technologies and standards will support the rapid assembly of applications with a reduction in the development of custom and redundant code required to do so.
By using existing Services, new applications and services will be able to eliminate the testing effort that would otherwise be needed if they had re-implemented those Services within the application.
Most applications currently contain some aspects of Security, Auditing, and Compliance internally. As a result, similar functionality is duplicated across many applications, and changes in rules or procedures for this functionality must be cascaded across all this custom code in each application.
Jack E. Brown 9/29/2009
46 An SOA Reference Architecture
SOA could introduce centralized Security, Auditing, and Compliance Services that would be implemented and maintained in one place.
In some cases, these Services may be called directly by applications. In other cases, these Services may be invoked implicitly as a request passes through an Enterprise Service Bus (ESB). The ESB approach provides ways to integrate these critical functions without introducing code into the applications.
A SOA based Reference Architecture can assist with application rationalization efforts. Rather than implementing the rationalization effort in large steps, a Services layer can introduce a level of abstraction to isolate the front end clients from the back end systems where rationalization and refactoring are taking place.
Jack E. Brown 9/29/2009
47 An SOA Reference Architecture A Reference Architecture may be related to and support the following IT Drivers And Objectives:
Keep systems up and running.
Deliver timely and accurate bills.
Meet business requirements, schedule, and cost.
Simplify and improve processes.
Mitigate security and compliance risks.
Deliver Strategic Business Capability Roadmaps.
Jack E. Brown 9/29/2009
48 An SOA Reference Architecture A Reference Architecture may be related to and support the following Product Development Drivers And Objectives:
Usable and Reliable Products and Services.
Deliver Products to Meet Channel Needs on Time.
Deliver a Simplified, Rationalized Product Portfolio on Time.
Grow Application and Content Usage.
By exposing existing capabilities as Services, new products may be created by orchestrating the invocation of these existing capabilities to create new functionality. Exposure of core capabilities in a way that will facilitate and simplify reuse will greatly simplify the leveraging of existing capabilities. The ability to combine these existing capabilities through the use of orchestration tools without the need to write low-level code to accomplish the sequencing and integration of the capabilities will significantly reduce development time for new services Jack E. Brown 9/29/2009
49 An SOA Reference Architecture A Reference Architecture may be related to and support the following Network Drivers And Objectives: