Service delivery platform docking station

A service delivery platform (SDP) docking station (DS) is part of a multiple layer service delivery platform implementation. The SDP DS adds a second SDP layer between the end user and the Core SDP. The Core SDP implements the process flows that enable, provision, and execute telecommunications products and services. The SDP DS provides a customizable front end to the Core SDP to provide local service provider customization, flexible local selection and activation of products and services, and other features.

PRIORITY CLAIM

This application claims the priority benefit of EPO Application No. EP 09 425 064.4, filed Feb. 16, 2009 assigned attorney docket number 10022/1476 and EPO Application No. EP 09 008 688.5, filed Jul. 2, 2009 assigned attorney docket number 10022/1540, both of which are incorporated herein by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Technical Field

This application relates to a multiple layer implementation for a service delivery platform, which may, for example, support selection, activation, and provisioning of telecommunications services.

2. Related Art

The demand for telecommunications products and services continues to be driven by strong market demand for new services, enhanced capabilities for existing services, and increased cost effectiveness for those services. In the past, implementing telecommunications products and services required a significantly complex and expensive monolithic service delivery platform for implementing, provisioning, and executing telecommunications services. The monolithic service delivery platforms were inflexible, took long to implement and debug, and provided little, if any, customization capability.

SUMMARY

A service delivery platform (SDP) docking station (referred to below as an “extension”) is part of a multiple layer service delivery platform implementation. The SDP extension adds, for example, a second SDP layer between the end subscriber and a core SDP. The core SDP implements the logic that enables, provisions, and executes telecommunications products and services. The SDP extension provides a customizable front end to the core SDP, to solve the technical problems of local service provider customization, flexible local selection and activation of products and services, and other technical problems.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1shows a multiple layer service delivery platform100, including service delivery platform (SDP) docking stations (referred to as “extensions” below) that facilitate multi-location deployments of telecommunications products and services. The SDP extensions facilitate locally reselling services that are executed centrally by a full functionality core installation of a SDP. The core SDP is typically located remotely with respect to the SDP extension at a major telecommunications service provider installation (which may be in another city, state, or country). The local resellers may thereby maintain immediate contact and management with their customers and employ local billing and customer management systems, while leveraging the substantial infrastructure of the core SDP to resell services supported by the core SDP. The SDP extensions expose the services implemented at the core SDP, but permit local management and reselling of those services.

FIG. 1shows that subscribers102interact with local service resellers104,106. The local service resellers104,106implement local support for telecommunications products and services, such as the Business Support Systems (BSS)108, operations support systems (OSS)110, and Business Intelligence Systems (BI)112. The subscribers interact with the local service resellers104,106through portlet logic114installed in a user interface116.

The service resellers104,106include service delivery platform extensions, such as the service delivery platform (SDP) extension118. The SDP extension118communicates with the local BSS108, OSS110, and BI112to locally handle billing, support, service integration, reporting, and other telecommunications service provider functions. In addition, the extension118communicates with the core SDP120in place at a site established by a service aggregator122. To that end, the core SDP120may expose web services interfaces toward the service resellers over which the SDP extension118communicates with the core SDP120to execute locally requested services.

The service aggregator122communicates through application enablers124to service providers126. In the service aggregator122, the core SDP120implements service execution and service provisioning to fulfill service requests and service provisioning requests arriving from the SDP extension118. Accordingly, the core SDP120provides the fundamental capabilities to handle telecommunications service orchestration, service management, service catalogues, service subscriptions, identity management, and third party management. The service aggregator122may be an Accenture™ service factory, an aggregator client, or other service aggregator that provides a core SDP.

Thus,FIG. 1shows a multi-layer service delivery platform implementation100. The implementation100implements service delivery in two layers. The first layer128includes the core SDP120. The second layer130includes the localized SDP extensions118, BSS, OSS, and other support systems which collaborate with the core SDP120to deliver services to local subscribers, and which facilitate local management and customization of user experience (e.g., personalized look and feel) for the local subscribers. The resultant multi-location SDP (composed of the two layers128and130) exposes the same services as provided by the core SDP120, but implements its own user interfaces in the SDP extensions118, and routes messages or parts of messages to local systems (e.g., the OSS110or BSS108) for local accounting.

FIG. 2shows a block diagram of the extension118. The extension118includes a subscriber user interface component202, an administration user interface component204, a service metering component206, and a batch feed component208. The extension118further includes a local service orchestration component210, in which a core service delivery platform interface component212resides. The local service orchestration component210implements an enterprise service bus214which provides a message transport mechanism for and between the components202,204,206,208, and212. The local service orchestration component210may be implemented with service provisioning logic that is operable to generate a local service provisioning interface on the subscriber user interface component, receive a subscriber service provisioning request for a telecommunication service through the subscriber user interface component202, and communicate the subscriber service provisioning request through the local service orchestration component210(e.g., using the ESB214) to the core service delivery platform interface component212. The service provisioning logic may further communicate telecommunications service provisioning messages, through the core service delivery platform interface component212, to the remote core SDP120which implements service provisioning to fulfill the service provisioning request. The metering component206may locally meter telecommunications service calls flowing through the SDP extension118and arising from the telecommunication service.

The core service delivery platform interface212may implement any desired service proxies toward the core SDP120business services. These proxies natively integrate the extension118with the core SDP120. The interface212may expose the service proxies as APIs, and may include message transformation logic to convert message formats used within the SDP extension118to message formats used within the core SDP120. When each service call is invoked, within the SDP extension118the ESB214may duplicate corresponding support messages. One copy of the messages may route through the core service delivery platform interface212to the core SDP120to execute the core processing needed to support the service. Another copy of the messages, or portion thereof, may be used for local logging and metering, CDR generation, for BSS and OSS functionality and reporting, or other local functions.

The service orchestration component210implements a centrally managed messaging layer (e.g., with an ESB214) as a single point of contact to the subsystems (e.g.,202,204,206,208,218,220,222,212) within the SDP extension118. The service orchestration component210further provides connectors to entities interacting with the service orchestration component210.

The subscriber user interface component202may be implemented with a web application that subscribers access to activate, configure, and execute the services exposed by the extension118. Because the extension118is a localized layer separate from the core SDP120, the extension118may be widely customized to align with the look and feel desired by the local service reseller. In one implementation, the service orchestration component210exposes Simple Object Access Protocol (SOAP)-based Application Programming Interfaces (APIs) for accessing the functions provided by the core SDP120, and the subscriber user interface component202invokes the SOAP-based APIs and in turn exposes a web-based graphical user interface (GUI) to the subscriber.

The administration user interface component204may be implemented as a web application that an administrator accesses to manage the extension118. As examples, the administration user interface component204may configure and monitor service orchestration, configure metering preferences for the metering component206, and access metering and other reports.

The metering component206intercepts service calls, or data extracted from service calls, flowing through the service orchestration component210. The metering component206may then store any desired information related to telecommunications service calls flowing through the service delivery platform extension118into a persistent layer216, such as a metering database. In one implementation, XML Stylesheets (XLSTs) define the fields of each message to be saved by the metering component206, such as user ID, time of request, duration of request, and other fields for building a CDR. The administration user interface component204configures the metering component206to set verbosity and depth of information that will be captured and retained in the persistent layer216. The metering component produces Call Data Records (CDRs) for billing purposes.

The batch feed component208communicates data extracted from the metering component206to external systems on any desired schedule and with regard to any desired information stored in the persistent layer216. In one implementation, the batch feed component208asynchronously extracts data according to an XML filter, transforms the data using XLST, and invokes an external engine, such as a rating or charging engine with the transformed data.

The network gateway adaptor (NGA)218converts requests to and from network elements. For example, the NGA218may be a Short Message Service (SMS) gateway and may convert messages from one datamodel format to another (e.g., consistent with the Short Message Peer to Peer (SMPP) protocol) for integrating, for example, with an SMS-Center. In other implementations, the NGA218may provide one or more network layers for communicating with any external entity.

The business adaptor220may implement a real-time interface toward the business support systems108, such as customer resource management (CRM) and billing systems. For inbound requests the business adaptor220exposes web services APIs for the CRM systems to query extension118data. For outbound requests, the business adaptor220may send real-time CDRs to the billing systems (108) and may also implement message adaptation to convert message from one system format to another.

The operation adaptor222may provide a real-time interface toward the OSS110, including integrated order management (IOM) and service assurance. For IOM, the operation adaptor222may expose APIs for user subscription to services. For service assurance, the operation adaptor222may expose a consolidated set of extension status flags and alarms.

FIG. 3shows an example architecture300of a service delivery platform extension118. The architecture300includes user interfaces302, such as the subscriber user interface202and the administration user interface204. The architecture300further includes a service enablement interface304, which may connect to any service delivery platform or other system that helps to provision, activate, or establish any desired telecommunication product or service. As one example, the service enablement interface304may communicate with the core SDP120using web services calls.

The architecture300also includes a service orchestration layer306, which may implement the functionality noted above with respect to the local service orchestration component210, the core service delivery platform interface212, or other logic, such as the error handler logic308. Inside of the service orchestration layer306, business services310and component services312are defined and executed. The business services310provide provisioning services, such as adding a user, removing a user, clearing user data; authentication services; and service execution services, which invoke the corresponding service through the core SDP120. The component services312may be provided to invoke external web services or other logic.

In one implementation, the service orchestration layer306includes routing and dispatching logic311and listener logic313to facilitate the communication of messages between the service orchestration layer306and the remainder of the architecture300. Messages flow through the SDP extension118between queues controlled by queue managers.FIG. 3shows three examples of queue managers for Java Message Service queues for specific types of messages: the metering queue manager314, the batch feed queue manager316, and the error handler queue manager318.

The metering component206in the architecture300may include message reception and processing logic, such as the listener logic320, and various message processing logic322. The batch feed logic208may include scheduling logic324for controlling when data is communicated in batch form to other systems, as well as message processing logic326.

The data access layer328may include data management logic for different functionality in the SDP extension118. For example, the data access layer328may include a metering data manager330, a routing data manager332, and an error data manager334. Each of the specific data managers may coordinate data flow between the persistence manager336and the SDP extension database338in the data layer340. The persistence manager336may control how long and how much data is retained in the SDP extension database338. The SDP extension database338may include the persistent layer216as part of a unified data model, or as a separate database.

FIG. 4shows a one click on-boarding use case400to initially register a service delivery platform extension118. In one implementation, a license key may be provided by a service provider to the service reseller104upon fulfillment of any defined contractual obligations. The license key may be stored for reference in the core SDP120, along with the service reseller information and status (e.g., initial status=locked). The registration sequence includes: 1) the SDP extension hardware is installed at the service reseller; 2) the SDP extension administration UI is accessed via a web browser; 3) the license key is entered, so that the SDP extension118is registered in the core SDP120(e.g. the service reseller is “onboarded”); and 4) upon registration completion, the SDP extension is unlocked and ready to be used.

FIG. 5shows the user experience500of a one click on-boarding use case for a service delivery platform extension. The retailer administrator accesses the SDP extension User Interface and navigates through the first-access Configuration Wizard502, in which the service reseller administrator inserts the license key to unlock the SDP extension118. In the user interface504, the service reseller information is displayed and the user can optionally modify contact information. In the user interface506, the administrator creates an SDP extension account, for example by providing username and password information.

FIG. 6shows an example of service provisioning600through the service delivery platform extension118. In particular, a product manager602interacts with a service selection user interface603to initiate (e.g., through the SDP extension administration GUI component204), a retrieval process (606) to retrieve a service product catalogue604from the core SDP120. The service catalog604, may, for example, be an XML file defining each product or service available from the core SDP120. The product manager602clicks on a product (for example the Digital File Locker product) and the extension118activates the product by sending corresponding service activation messages to the core SDP120(608). In some implementations, the selected service may be supported in the extension118by separately downloaded and installed applications, such as portlets.FIG. 6shows an example of an application download (610) through which the digital file locker portlet is downloaded from the core SDP120into a specific folder of the SDP extension118, from which the SDP extension118installs the application.

FIG. 7shows an example of the user experience700of service provisioning through the service delivery platform extension. Initially, the SDP extension118retrieves from the core SDP120the product catalogue604. The service reseller product manager accesses the configuration wizard user interface screen702to select one of the available products to activate, e.g., through a managed services activation link704. The SDP extension118asks the service reseller product manager to choose among different product or service configurations (e.g., DFL configurations Standard, Gold or Platinum) in the service selection user interface704. The service selection user interface704displays sales, marketing, and technical details for each selectable service configuration.

Upon selection of a service configuration, the SDP extension118may ask the product manager to provide additional service technical parameters. The additional parameters may establish, set, or otherwise configure the service for use (e.g., to set domain names, bandwidth, maximum number of users, to enable SMS functionality), and other configuration options. Such parameters may be entered through the services configuration user interface706, for example.

The SDP extension118accepts the information entered through the user interfaces702-706and generates an order fulfillment request708. The SDP extension118sends the order fulfillment request708to the core SDP120. The core SDP120may accept, process, and activate the service, then send back an acknowledgement to the SDP extension118. If the acknowledgement indicates successful activation, then the SPD extension118may insert a link to access the service on a home page access through the SDP extension118. Alternatively, the SDP extension118may insert or install a supporting application or portlet into the subscriber portal accessed by subscribers to facilitate access to the newly activated product or service. The station user interface710may report whether activation has succeeded or failed.

FIG. 8shows an example of service delivery800through the service delivery platform extension118. In particular,FIG. 8shows a service portlet802for facilitating access to the newly activated service that is downloaded from the core SDP120. The SDP extension118inserts the service portlet802into the subscriber portal804accessed by subscribers to facilitate access to the newly activated product or service. The subscriber portal804may be hosted on a local webserver806. Accordingly, the new service is accessed (808) through the SDP extension118via the service portlet802.

FIG. 9shows reporting functionality900for the service delivery platform extension118. In particular, the metering component206stores CDRs and other transaction information within the platform extension118(e.g., in the persistent layer216). Accordingly, the CDRs and transaction information is readily available to the administrator for the SDP extension118. The administrator may access the information stored by the metering component206through one or more administration user interface screens902, which may be designed to report any desired reporting information retrieved or derived from the information retained by the metering component206. More particularly, an administrator may access the SDP extension118administration user interfaces902via a web browser, for example, to access a metering console. The metering component locally meters telecommunications service calls flowing through the service delivery platform extension and arising from telecommunication service use. The information stored in the metering component206may be used for billing, revenue sharing, or other business intelligence purposes.

FIG. 10shows the reporting functionality1000of the service delivery platform extension118in more detail. The administrator accesses a reporting home page1002. In the example shown inFIG. 10, the home page1002provides links to four main reporting categories and the functionality to export any selected data to Excel spreadsheets. In particular,FIG. 10shows a CDR user interface1004, which reports, e.g., information for billing and revenue sharing purposes; a subscriptions user interface1006, which reports, e.g., the number of transactions and subscriptions for each SDP extension managed and hosted service; a user reporting user interface1008, which reports, e.g., the number of subscriber accesses and subscriptions; and a system information user interface1010, which reports, e.g., system technical information such as available disk space.

FIG. 11shows an example of logical flow1100for implementing a multi-layer SDP100. The core SDP120exposes web services (or other interfaces) for the services that the core SDP120implements and makes available (1102). At one or more local reseller locations, a local reseller installs SDP extensions (1104). The SDP extensions are supported by local BSS, OSS, and other support systems (1106) which are connected to the SDP extension (1108). As a result, a two layer SDP implementation is formed, which includes an SDP extension to facilitate local management, control, and customization over the local user experience, while leveraging the complete set of available functionality at the core SDP120. As described above with respect toFIGS. 4 and 5, the local SDP extension118is registered and activated with the SDP core120(1110).

One technical advantage provided by the SDP extension118is its flexibility in terms of local customization (e.g., look and feel) for local customers. In that respect, the local reseller may customize the interfaces through which subscribers interact with the SDP extension118to any extent (1112).

In operation, the SDP extension118implements user interfaces such as the subscriber user interface202and the administration user interface204(1114). The SDP extension118interacts with the subscribers to execute services through the core SDP120, while locally metering the service use using the metering component206(1116).

In addition, as noted above with respect toFIGS. 6 and 7, the SDP extension118may obtain a service catalog604of available services from the core SDP120(1118). The SDP extension118generates and displays a service selection interface603. The service selection interface603may display the services available from the core SDP120, as listed in the service catalog. The SDP extension118may also accept service selections from the service selection interface listing (1122), and coordinate activation of the selected service with the core SDP120(1124).

The service delivery platform extension118may include a subscriber user interface component, a service metering component, a core service delivery platform interface component, and a local service orchestration component. The local service orchestration component may implement an enterprise service bus in communication with the subscriber user interface component, the administration user interface component, and the core service delivery platform interface component. In addition, the local service orchestration component may include service provisioning logic operable to generate a local service provisioning interface on the subscriber user interface component, receive a subscriber service provisioning request for a telecommunication service through the subscriber user interface component, communicate the subscriber service provisioning request through the local service orchestration component to the core service delivery platform interface component, communicate telecommunications service provisioning messages, through the core service delivery platform interface component, to a remote core service delivery platform which implements service provisioning to fulfill the service provisioning request, and locally meter, using the metering component, telecommunications service calls flowing through the service delivery platform extension and arising from the telecommunication service.

The service provisioning logic may be further programmed to download from the remote core service delivery platform a plugin extension for implementing the telecommunication service, and locally install the plugin extension in the service delivery platform extension. In addition, the service provisioning logic may be further operable to download a service catalog of available telecommunications services from the remote core service delivery platform, display a telecommunications service selection menu on the local service provisioning interface, the service selection menu comprising telecommunication service entries derived from the service catalog, as well as receive a subscriber service provisioning request for a telecommunication service selected from the telecommunications service selection menu.

The systems, components, and logic described above may be implemented in many different ways, including a combination of hardware and software, or as software for installation on any desired operating system including Linux, Unix, or Windows. The functionality may be implemented in a single system or functionally partitioned across multiple systems. As another example, the components, systems, and logic may be implemented as computer-executable instructions or as data structures in memory and may be stored on, distributed across, or read from many different types of machine-readable media. The machine-readable media may include RAM, ROM, hard disks, floppy disks, CD-ROMs, flash memory or other machine-readable medium. The components, systems and logic may also be encoded in a signal, such as a signal received from a network or partitioned into sections and received in multiple packets communicated across a network. The systems may be implemented in software, hardware, or a combination of software and hardware.

Furthermore, the systems may be implemented with additional, different, or fewer components. As one example, a processor or any other logic or component may be implemented with a microprocessor, a microcontroller, a DSP, an application specific integrated circuit (ASIC), program instructions, discrete analog or digital logic, or a combination of other types of circuits or logic. As another example, memories may be DRAM, SRAM, Flash or any other type of memory. The systems may be distributed among multiple components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Logic, such as programs or circuitry, may be combined or split among multiple programs, distributed across several memories and processors, and may be implemented in or as a function library, such as a dynamic link library (DLL) or other shared library.

The transport layer between components and systems such as the core SDP and the SDP extension118or user devices and the core SDP120may include Transport Control Protocol (TCP), Real Time Transport Protocol (RTP) or other transport logic. The network layer may route information based on Internet Protocol v4, v6 (i.e., IPv4 or IPv6) or other network layer protocols. The data link layer may include wired or wireless links, such as IEEE 802.11, WiFi, WiMAX, Asynchronous Transfer Mode (ATM), Fiber Distributed Data Interface (FDDI), Ethernet, or other data link layers over optical fiber, coaxial cable, twisted pair or other physical layers.

Interfaces between the systems and the logic and modules within systems may be implemented in numerous ways. For example, interfaces between systems may be Web Services, Simple Object Access Protocol, or Enterprise Service Bus interfaces. Other examples of interfaces include message passing, such as publish/subscribe messaging, shared memory, and remote procedure calls.

The hardware and software platforms that run in the SDP DS may vary widely. As examples, the endpoints may run the Windows CE™ operating system, JAVA ME™ system, Symbian™ operating system, Palm™ operating system. The hardware platforms may be implemented with a general purpose processing platform, such as those available from Sun Microsystems, Hewlett Packard, or International Business Machines and running Unix, Windows™, Linux or other operating systems.