BT Innovation Journal - Current Volume


Streamlining the Telco Production Line

G.Bruce, B.Naughton, D.Trew, M.Parsons, P.Robson


It has long been the desire of Telecommunications companies (Telcos) to deliver a wealth of tailored products, quickly and efficiently, to meet their customers' ongoing needs. In reality, however, it has taken up to 18 months to deliver just one single product using an assortment of back-office processes; some of which are costly, lengthy and error-prone. This may have been acceptable in years gone by, but it's definitely no longer the case given today's competitive commercial environment and ever increasing customer demands and expectations. The massive investment that Telcos are already making in transforming to Next Generation Networks (NGNs) will resolve some of these issues. However, given the surge of products expected of these NGNs, it is vital that the necessary delivery processes are also geared up if Telcos are not only to survive this transformation, but to flourish.

Generally, the biggest delays and costs in the Telco production line are incurred in provisioning the management support for the intended product offerings. The reason for this is that the processes used to provision the necessary Operational Support Systems (OSSs) and Business Support Systems (BSSs) are typically not automated, or have automation that is not straightforward to change. This limited level of automation has created a bottleneck that has proved difficult to overcome. In this environment, for each new product that is to be offered, a considerable amount of effort and resource is required to develop a workable solution. In addition, for each new offering, the OSS and BSS provisioning has typically been done in a very specific way, making even small incremental changes complex and costly.

Telcos are considering new approaches to overcome this bottleneck. One significant approach to tackling these challenges is being developed by the Product and Service Assembly (PSA) team. This new approach is based on adapting relevant and successful techniques used within the manufacturing industry. To help with the adoption of such an approach within the Telecommunications industry, the PSA founder companies have worked in collaboration with key Telcos, software vendors and equipment manufacturers. The PSA team was initiated within the TeleManagement Forum (TMF) partly to define the necessary standards, and partly to encourage the development of an ecosystem of tool support. The PSA team has grown rapidly from an initial idea into a broad collaboration that has already delivered its first prototype. This paper addresses the work of the PSA team covering the PSA architecture, interfaces and prototype, and outlines the next steps planned by the PSA team.


1. Introduction


The "killer application" was supposed to be the one application that would replace voice and help keep the Telcos in business for the next few decades. This application never appeared, and so the Telcos were forced to rely upon delivering a divergent range of products that kept the revenues coming in. While this plan worked to some extent, efficient implementation was a problem. All too often, products were built as vertical silos, or stove-pipes. Each product required its own execution and management platforms, producing a situation which clearly cannot scale. And scale it must, for while the search for the killer application has become a distant memory, the most likely outcome is that Telcos must be able to offer a large number of products [1]. A low number of these products will be high-demand offerings, such as basic Internet access and voice packages. However, a large number of these products will also be low-demand offerings, such as network-based call wake-up. The relationship between product demand and number of products is illustrated in Figure 1. Known as "the long tail" [2]* the concept is that the benefits gained from a high number of low-demand offerings (shown in yellow) can equal or outweigh those benefits gained from a low number of high-demand offerings (shown in green).

The long tail Fig 1; [3]

For the Telcos to turn this concept into practice, just as Amazon and Netflix have done, three ingredients are required. First, an environment which can support the execution of a large number of offerings is needed. Second, a Telco production line is needed to build a large number of offerings quickly and cost effectively. And thirdly, the environment must promote continuous product innovation by making it easy to use by 3rd parties and customers. By achieving this, not only can a very large number of products be obtained, but the ever-increasing transient nature of certain "trend-related" products can be accommodated. The good news is that NGN technologies, such as Internet Protocol Multimedia Subsystem (IMS) and Service Delivery Platform (SDP), claim to be able to sweep aside stove-pipe solutions by providing single platforms capable of supporting and enabling large numbers of offerings. By promoting other technologies, such as Service Oriented Architecture (SOA) which can enable a more flexible use of available functionality, NGNs have also made it easier to address the Telco production line problem. In essence, the Telco production line needs to deliver product offerings that must comprise both "Service Function" and "Service Management" capabilities. Service Function capabilities* such as broadband access or location service, are features that are used directly by a receiving party [4]. Service Management capabilities, such as order handling or billing, are features supporting the product offering that are used only indirectly by the receiving party. To offer a product, both the Service Function and Service Management capabilities are needed. One without the other would make little sense. For example, broadband is of little use if it cannot be ordered, while billing for nothing is an equally bizarre business proposition.

The development of Service Creation Environment (SCE) tools has helped streamline the processes required to create and orchestrate the Service Function capabilities associated with a potential product offering. Such tools, and their underlying technology, are not the subject of this paper as good progress has already been made in this area. Conversely, the technology required to accelerate the assembly and orchestration of the Service Management capabilities associated with a potential product offering has been left largely unexplored by the industry and, as such, is the subject of this paper. Note that, while some Service Assembly Environment (SAE) tools are commercially available, they fail to adequately deliver the management support required to turn "raw" services into orderable* fixable, and billable product offerings. Such tools are not covered within this paper.

As captured in Figure 2, a combination of NGNs, tools that manipulate Service Function and Service Management capabilities, and, most importantly, customer-driven innovation are necessary to promote mass productisation, so enabling the long tail. The figure depicts the NGN as a cloud and the capabilities it supports or accesses as hexagons below the cloud. Here, in addition to supporting Telco Service

Customer-Driven Innovation Fig 2

Function and Service Management capabilities, the NGN also has access to external Web Services. The Service Function and Service Management manipulation tools are represented by the three red arrows, which enable the rapid delivery of product offerings. At the top of the figure, is the customer whose continuous innovation is responsible for the continuous delivery of new products. Only by bringing all these elements together is the best environment created to promote mass productisation.

Unfortunately, it just takes one deficiency in this environment to jeopardise the goal of mass productisation. Today, Telcos can take up to 18 months to provision the OSSs and BSSs for a new offering. If the Telcos are to reduce this provisioning time down to weeks, if not days, then all of the various organisational departments and systems, which are required to assemble and orchestrate the Service Management capabilities, must cooperate in a seamless, well understood way. Currently, there is generally little or no cooperation across systems. Product knowledge is duplicated across many monolithic OSSs and BSSs. This knowledge is rendered in proprietary ways, making it difficult to be shared amongst the OSSs and BSSs. Without the technology to address these issues, costs and timescales are becoming prohibitive for new offerings. Or, to put it another way, the "long tail" is in danger of being cut short* and all associated benefits, lost.
Just under a year ago, the PSA team was established within the TMF standards organisation [5] to address the OSS and BSS aspects of the Telco production line. It was decided that the project should be run as a TMF "Catalyst" [6] as these projects were designed to provide a way to quickly pioneer new ideas through the development of practical demonstrators. The PSA Catalyst's "big idea" was to create a new Information Technology (IT) reference architecture which decoupled the detailed product knowledge from the monolithic OSSs and BSSs, and made that knowledge common to all the cooperating systems.

In creating the architecture, the PSA team drew its inspiration from other industries where the problem of managing production lines across complex organisational boundaries has long been solved. Industries, such as manufacturing, are disciplined in Product Lifecycle Management (PLM) which is a very relevant solution to the problem that was faced by the PSA team. PLM is now well established and understood, being based on earlier concepts such as Computer Aided Design (CAD), Computer Aided Manufacturing (CAM) and Product Data Management (PDM). These concepts take a bottom-up engineering-oriented approach of assembling production line "building blocks" into products in an automated fashion. It is this product assembly approach that has been taken by the PSA Catalyst.

The PSA architecture proposes that shareable product knowledge should be removed from existing OSSs and BSSs, and federalised within new architectural elements, called "Active Catalogs". Collectively* Active Catalogs provide a place where all of the product building blocks are modelled. For example, network equipment, client devices, Short Message Service (SMS) servers and Customer Relationship Management (CRM) platforms could be viewed as building blocks. These building blocks would be modelled as PSA "Items" within the Active Catalogs and would be assembled into product offerings that make sense to both the customer and the product manager.

The term "Active" in Active Catalog refers to the fact that Active Catalogs can be used not only in an offline CAD-like way but also in an online CAM-like way. To this end, an Active Catalog Item definition includes assembly rules on how it can be combined with other Items, plus full instructions on how to orchestrate the provisioning of its supporting OSSs/BSSs. Looking at an orchestration example, an Item may reference a combination of activation processes, billing processes and element manager processes to activate, bill and assure that Item automatically. Each existing OSS and BSS will still remain in control of its own specialist area, however, the change in scope from the traditional approach, is to make these systems more capable of sharing product knowledge. In this way, a product manager or even a customer could assemble a number of Items without needing to worry about the end-to-end provisioning processes. This worry would simply be dealt with using the product knowledge held within the Items.

To help realise the PSA architecture, the PSA Catalyst is undertaking two pivotal activities. The first is the creation of a Web Services Description Language (WSDL) interface for the Active Catalogs. The second is the development of Proof of Concepts (PoCs). The WSDL interface is used by Active Catalogs, to publish details of the Items they offer, and by Active Catalog users, to request Active Catalogs to provision the necessary OSSs and BSSs. The PoCs are used to evaluate, develop and socialise the PSA architecture and the Active Catalog interface. The aspiration of the PSA team is to make the PSA architecture and the Active Catalog interface form the basis of a new standard for the OSS and BSS aspect of the Telco production line.

2. Terminology


The Telco industry is peppered with terms, many of which are overloaded or have vague meanings. Official definitions are hard to find, so, to provide clarity within the scope of this paper some of the commonly used terms are defined below.

The terms "Products"* "Services" and "Resources" are used to define different levels of abstraction of a unit of Telco capability. Resources define the lowest level of abstraction, relating to units of capability that have little use in isolation. Examples might include a phone or a home router. Services define the next level of abstraction, relating to units of capability that have use in isolation but no commercial support. Examples might include "raw" voice mail or presence capability. Products define the highest level of abstraction, relating to units of capability that have use in isolation and that also have commercial support. Examples might include a voice or broadband "package" These three general levels of abstraction originate from the TMF, however, the levels are subjective in that they are personal to the particular organisation defining the levels.

The term "Service Creation" is used to define a systematic way to design, code and analyse Service Function capabilities, and design, code, analyse and deploy Services. The term probably pre-dates the Intelligent Network (IN) era, and is still in wide-spread use today in areas such as Session Initiation Protocol (SIP) environments. In the opinion of the authors, Service Creation does not cover the creation of Products or Service Management capabilities.
The term "Service Assembly" is used to define a systematic way to pull together and provision pre-existing Services, Service Function and Service Management capabilities to deliver a Product. Having said this, it is the opinion of the authors that presently available Service Assembly environments inadequately support the provisioning of Service Management capabilities, which would turn Services into Products.

The term "Product and Service Assembly" has been created by the PSA team to add weight to the Service Assembly term. Through the work and publicity of the PSA team, focus has shifted towards the assembly and orchestration aspects of OSS and BSS. The "Product" in Product and Service Assembly has been added to emphasise that the Product, and not the Service, is the end goal.

The term "Service Execution" is used to describe a systematic way to run Telco Services on Service Execution Platforms (SEPs).

The term "Service Delivery Platform" is a very loosely defined and evolving term [7]. In the opinion of the authors, Service Delivery Platforms should, amongst other things, contain Service Creation environments, Product and Service Assembly environments, Service Execution environments, OSS and BSS.

3. Phase 1 of the PSA Catalyst


Participants in phase 1 of the PSA Catalyst were Atos Origin, Axiom Systems, BT, C&W, Celona, Huawei, Oracle and TeliaSonera. The project started in June 2006 and culminated by being showcased at the TMF World Conference in Dallas, USA on December of that year. The following sections describe the reuse of practices from other industries and the three major milestones reached by the Catalyst, namely, the introduction of a new IT reference architecture, the specification of a new architectural element, and the construction of the first PSA prototype.

3.1 Learning from other Industries

Before the PSA team attempted to develop any potential solutions, the decision was taken to look at how other industries addressed similar problems. The most pertinent industries were the automotive and aerospace industries, where PLM was identified as an obvious relevant discipline. In a nutshell, the goal of PLM is to seamlessly take products from concept to design, manufacture, in-service operation and, eventually, to end-of-life [8]. PLM, itself, leverages and builds upon CAD, CAM and PDM technologies. CAD tools provide a way to model products from smaller component models, while CAM tools consume these component models and, using the knowledge within these models, communicate with other systems to realise the product. Unlike CAD and CAM, PDM spans the entire product lifecycle, and is used as a tool to facilitate the creation, storage and sharing of product data. Figure 3 shows the relationships between associated PLM technologies used through-out the product lifecycle. In addition to the end-to-end product lifecycle, note that component lifecycles also exist for the components that make up the products. Thus, changes to components can affect the behaviour of a product that might, say, be in-service.

PLM Technologies used within the Product Lifecycle Fig 3

Some of the benefits of using the PLM approach are reduced time-to-market, improved product quality, reduced prototyping costs, savings through the re-use of original data, savings through the complete integration of engineering workflows and increased product quantity [9], [10]. Given that these benefits were exactly what the PSA team were looking for, it was appropriate for the team to attempt to transfer the PLM approach to the Telco OSS/BSS assembly and orchestration problem.

To establish how PLM would be applied to a typical Telco environment* it's worth mapping out some of the core PLM functions. Initially the product idea is developed, using top-down design, in conjunction with customer requirements and other external conditions. A number of iterations at this level are made in order to define the major building blocks of the product specification. Next, the product specification is detailed before the product is ready to be developed. The development stage uses the detailed product specification to take the product from design to prototype, through trial, and eventually to launch. The main tool for enabling the first half of this PLM process is CAD. The CAD tools provide engineering descriptions of the resources that are available to be used in the assembled product, allowing a bottom-up construction of the product to meet the top-down product requirements. The main tool for enabling the second half of this PLM process is CAM. Once the product design is assembled it can be verified using CAM tools. For example, are there enough resources to manufacture it? Assuming the method of manufacturing the product's building blocks is defined and operational, the product can be automatically built and configured as appropriate.

Applying PLM to the Telco Fig 4

Figure 4 maps out these core PLM functions and overlays them with what's happening within Telco environments today. As shown by the ellipses, there are four main domains of expertise involved in the Telco production line; starting with the leftmost ellipse and moving in and anti-clockwise direction, these can be described as the portfolio, engineering, OSS and IT departments. For the purpose of this paper, the portfolio department can be viewed as responsible for product and service assembly; the engineering department responsible for the SEP; and the IT department responsible for BSS.

PLM tools exist in some Telco environments today, and are used by the portfolio department as modelling tools to estimate the impact of a new product. However, for most cases, Telcos only use simple text descriptions for products and, in all cases, the processes used are, at best, very ad-hoc. The engineering community owns an understanding of its capabilities, for example, what logical functions can be supported. The operational support groups have a full understanding of how to support logical functions. Currently, this understanding is very much in the context of Commercial-of-the-Shelf Systems (COTS) or custom OSS applications. Lastly, the customer facing IT organisation owns the commercial understanding of product. In a similar fashion to the OSS department, understanding here is very much in the context of COTS or custom BSS applications.

One of the main issues with Telco environments from this perspective is that the usual method of tying all of this information together into a coherent PLM process falls down because there is no detailed modelling component that can bridge all of these domains of expertise. As a result, we have islands of knowledge that need to be bridged manually every time a product offering needs to be worked out. There is a reason, however, why these islands of knowledge have evolved. Historically, such a comprehensive approach to Telco productisation has never really been needed and, as a result* the PLM processes didn't need to be formalised. Today, the need for a formalised process is paramount and, to this effect, the PSA team has proposed a new IT reference architecture that seeks to bridge these islands of knowledge and establish a formalised PLM process for Telcos.

3.2 Catalog-Provisioned OSS/BSS

The PSA IT architecture, in its simplest form, can be viewed as a facilitator between the portfolio, BSS, OSS and SEP islands of knowledge, as shown in figure 5. The first key aspect to this architecture is the introduction of an automated facilitator, or mediation function, known as the Active Catalog. The Active Catalog is more than a traditional catalogue. Traditional catalogues are registers of offerings that may be enhanced with information such as pricing, availability and Service Level Agreement (SLA) data. In addition, traditional catalogues may contain product relationship and product composition rules as well as pointers on how products may be consumed. The Active Catalog builds on the role of traditional catalogues, providing a modelling facilitator and the necessary intelligence to allow it to interwork and interact with the OSS/BSS and SEP provisioning elements of the architecture. It, thus, plays the role of a bridge between these islands of knowledge, linking CAD to CAM, and facilitating a common point of shared knowledge between all domains.

Central Role of the Active Catalog Fig 5

The PSA architecture provides an opportunity for a complete PLM story for the Telcos. However, the PSA team is currently only focusing on the portfolio, Active Catalog, BSS and OSS parts of this story, as these are the areas of most concern. Technology already exists to create and execute services on SEPs, and it is not the intention of the PSA team to replace these technologies, but to supplement them. However, at some future point in time it may be beneficial to provide a totally integrated PLM Telco solution.

The second key aspect to this architecture is that the Active Catalog is not just a single element, but a federation of  Active Catalogs. Figure 6 shows Active Catalogs that provide a federation of knowledge at different layers of abstraction. This federated approach is consistent with the TMF's Shared Information/Data model (SID) [11] and enhanced Telecoms Operations Map (eTOM) [12] industry standards, which model comparable product, service and resource layers.

Within the PSA architecture, the Product Catalog, Service Catalog and Resource Catalog make up the federation of Active Catalogs. This particular federation was chosen in order to enable close alignment with the SID's product* service and resource components. While this is the convention chosen by the PSA team, it should be noted that the flexibility of the architecture can accommodate any number of layers of Active Catalogs, each representing their own particular degree of abstraction. In addition, each layer of abstraction can also contain multiple peer Active Catalogs.

To help with clarity and provide focus, the architecture only depicts the Active Catalog, OSS and BSS elements, and highlights the general left-to-right PLM flow. Starting from the left-hand-side of the figure, the assembly tools (not shown) will manipulate and populate the Product, Service and Resource Catalogs which will contain Product, Service and Resource Items, respectively. Each Item within an Active Catalog is capable of containing data, rules and process, which are fundamental to the assembly and orchestration process - and are covered in more detail within the next section of this paper. The federated Active Catalogs cooperate with each other by offering their knowledge upwards and by handling downward requests. For example, during the CAD cycle, Service Items could be offered up for use by a Product Catalog; while during the CAM cycle, Resource Items could be requested to provision relevant parts of the OSSs/BSSs.

The PSA Federated IT Architecture Fig 6

Above the highest layer of Active Catalogs (typically, the Product Catalogs) are the OSS/BSS applications that are Active Catalog users. Such types of applications could be the product introduction, order capture or Web self-care aspects of CRM. Towards the end of the CAD cycle, a product introduction application, for example, might be made aware of new Product Items. Conversely, during the start of the CAM cycle, such Active Catalog user applications might be used to initiate the introduction of a new product offering or the ordering of a product instance.

In the case of initiating the ordering of a product instance, a request would be directed at the relevant Item within the Product Catalog. The Product Item would then generate subsequent requests which would ripple down to the Items within Service and Resource Catalogs. For a particular product, a coordinated series of actions would be initiated by the Active Catalogs onto the relevant OSSs/BSSs. For example, ordering a new Voice over Internet Protocol (VoIP) product may cause changes to Product, Service and Resource Inventory, as well as changes in Fulfilment, Assurance and Billing systems. Another example could be that during order capture for a Broadband product, the selection of certain Product and Service options may initiate changes to restrict further orderable Resource options, such as the type of router that can be selected. Finally, and on the right-hand-side of the figure, the actions initiated by the Active Catalogs on the OSSs/BSSs may cause external changes, such as delivery of hardware or remote configuration of phones.

Note in the figure that the layering of Product, Service and Resource Inventories correspond to those of the Product, Service and Resource Catalogs. However, the Operational Support and Readiness (OSR), and Fulfilment, Assurance and Billing (FAB) systems are shown as potential monoliths since they may or may not have presence at each of the three layers. Figure 7 shows how the PSA architecture and the PSA Catalyst's initial coverage within this architecture maps onto the TMF's eTOM. While the PSA architecture includes all aspects of PLM and orchestration aspects of OSR and FAB, the Catalyst's initial coverage is much more modest. At present, the Catalyst covers only the assembly aspects of PLM and the orchestration of Fulfilment systems during order capture.

PSA Relationship with the eTOM Fig 7

The federated Active Catalog approach is not consistent with the way that some vendors currently address parts of the OSS/BSS bottleneck, instead choosing to encapsulate all Product, Service and Resource data within a single element. The TMF's Telecoms Applications Map (TAM) [13] maps out vendor applications across the whole OSS/BSS space. Given the limited vendor applications addressing this problem and the immaturity of the standards in this problem space, this federated approach is also not shown within the current version of the TAM. The merits of such a federated approach are that it can enable organisations to more conveniently expose and manage appropriate layers of abstraction. Figure 8 provides some example arrangements, showing how layers of abstraction can be exposed both within and across organisational boundaries. This is the final key aspect of the PSA architecture. Telcos will be able to benefit from the different layers of abstraction since it provides a means to quickly incorporate capabilities from 3rd parties, and also provides a means to quickly expose capabilities further up the value chain.

While the PSA architecture depicts only one of each type of Active Catalog, this is not a restriction, and multiple Active Catalogs of the same type could be used. Figure 8 goes some way to highlighting the possible Active Catalog configurations both within and across organisational boundaries. In the figure* "P" indicates a Product Catalog* "S" a Service Catalog and "R" a Resource Catalog. Solid lines indicate relationships between Active Catalogs, and dotted rings indicate organisational boundaries, either surrounding a company or a business unit within a company.
In the case of Service Provider "F"* one business unit simply supplies Resources via the two Resource Catalogs, while another supplies Services. Note that in the second case, the Service Catalog plus two Resource Catalogs are used by a "parent" Service Catalog* resulting in a hierarchy of Service Catalogs. The Products supported by Service Provider "F" can be offered commercially to end-customers or, as in this case, re-sold to Service Provider "B"* who appears to be a Virtual Operator* and Service Provider "C"* who appears to be offering some value-add. The result is a hierarchy of Product Catalogs* illustrating the one Service Provider's Product can, in effect, be likened to a Service by another Service Provider. Keeping with Service Providers "F"* "B" and "C" and hypothetically mapping them to the real world; Service Provider "F" might be BT Wholesale* Service Providers "B" might be Virgin* and Service Provider "C" might be BT Retail.

Note that Service Provider "A" contains a Service Catalog that has no relationship with an underlying Resource Catalog. This could be because it contains Services, such as "Terms and Conditions"* that do not require underlying Resources. In addition* Service Provider "A" contains another Service Catalog that uses the Product Catalog from Service Provider "E". In this case* Products from Service Provider "E" are likened to a "child" Service or even to a Resource.

3.3 Anatomy of an Active Catalog

Studying the Active Catalog in more detail and still relating it to CAD/CAM, the Active Catalog itself can contain one or more hierarchies of Items. For example, if the Active Catalog is a Service Catalog, it can contain multiple Service Item hierarchies, with the potential to offer one hierarchy for each Service . Figure 9 shows a single hierarchy of Items that can be assumed to have been constructed during the CAD cycle. Within each of the Items resides data, rules and process knowledge required not only for the CAD cycle assembly phase, but also for the CAM cycle OSS/BSS orchestration phase. As a result, each Item contains assembly rules to aid the construction of the Item hierarchy, and process fragments to provision the OSSs/BSSs to support it.

Exposing Layers of Abstraction Within and Across Organisational Boundaries Fig 8 Active Catalogs, Items and Data/Rules/Process Fig 9

Data knowledge might include data required by the Item before an order can be made, such as the number of handsets required. Data knowledge might also include data returned after an Item has been allocated, such as the Internet Protocol (IP) address assigned to it. Rules knowledge might include rules on validation, such as, is the Item valid for an order to be made. Rules knowledge might include rules on compatibility, such as, if this Item is ordered will it be compatible with an Item previously ordered. Rules knowledge might also include rules on composition, such as, this Item requires broadband access. Lastly, process knowledge might include pointers to process fragments, reusable functions and any orchestration code. This process knowledge can then be invoked to provision the necessary OSSs/BSSs, such as provisioning a Product offering into a Billing system.

Operation

Description

List

This operation is used to get a list of the available Items in an Active Catalog.

Discover

This operation is used to get the full details of a particular Item.

Validate

This operation is used to check that every-thing is logically ready before an order can be accepted.

Feasibility

This operation is used to check that every-thing is physically ready once an order has been accepted.

Reserve

This operation is used to reserve all the nec-essary resources required for an order.

Fulfil

This operation is used to complete all the necessary provisioning changes on the OSSs/BSSs for an order.

Cease

This operation is used to remove the provi-sioning changes on the OSSs/BSSs associ-ated with a previous order. It is the reverse of the "Fulfil" operation.

Release

This operation is used to remove the re-sources associated with a previous order. It is the reverse of the "Reserve" operation.

Fig 10: Initial PSA Offer-and-Request Operations

In order to manipulate Items in a technology-neutral way, Active Catalogs interfaces are being defined by the PSA team in Extensible Markup Language (XML) and made available as Web Services via WSDL. Two categories of Active Catalog interfaces have been identified as candidates for standardisation. These are the Active Catalog "Offer-and-Request" interface and the Active Catalog "Action" interface* as illustrated by the block arrows in figure 6. The Offer-and-Request interface is the "north-south" interface* while the "Action" interface is the "east-west" interface between Active Catalog and OSSs/BSSs. Because of project priorities and timescales, the PSA team decided to focus efforts on standardising the Offer-and-Request interface first as this was seen as the driver for subsequent efforts on standardising, or at least addressing, the Action interfaces.

The Offer-and-Request Interface: A key aspect of the Offer-and-Request interface is that the definition of the interface is identical for whatever abstraction of Active Catalog it is implemented on. For example, the Offer-and-Request interface for a Product Catalog is the same as that for the Service Catalog and the Resource Catalog. By making this decision, this has enabled the Active Catalog hierarchy to be totally flexible, allowing it to contain any number of layers of abstraction, with each layer of abstraction capable of being categorised as deemed fit.

The second key aspect of the Offer-and-Request interface is that it is agnostic with respect to product modelling styles used within the Active Catalogs. For example, an Active Catalog using the SID model would be able to freely interact with an Active Catalog using BT's Common Capability Model (CCM). This model-agnostic capability is achieved by providing operations on the interface that only pass relevant Item data as "name-string" pairs. For example* the "Discover" operation allows the Web Service "Requester" to ask the Web Service "Provider" for only the details* expressed as "name-string" pairs* it is interested in. Other operations follow this approach, dealing with only the details of interest, and not being concerned with peer product models. Figure 10 shows the initial operations identified for the Offer-and-Request interface. Note that the focus of the PSA team has been on fulfilment, hence the initial direction that the interface has taken. It is expected that on taking into full consideration OSR and FAB that the interface will go through a number of natural evolution cycles.

Following on from the discoverable, loosely-coupled, nature of the Offer-and-Request interface, the third and final key aspect of the interface is that it can be used to dynamically discover the OSS/BSS provisioning process steps related to each Item. The details of how these process steps are realised, however, is the domain of the Active Catalogs. Hence, process steps can be coordinated between layers and across multiple systems at the same layer. The following section explains this further.

The latest public version of the interface is contained within the PSA Interface Implementation Specification (IIS) document [14], from which greater detail can be obtained. An approved PSA interface specification is expected around May 2007.

The Action Interface: The Action interface conveys communication between the Active Catalogs and all OSR/FAB systems. When communicating with the OSR systems, there is an exchange of information relating to Product launch, however, when communicating with FAB systems, information exchange relates to Product operations, such as ordering and billing. From a standards viewpoint, this is a very immature and complex area. In addition, there is also a host of different proprietary approaches. As a result, most Telcos are using different local standards or mixture of standards-based and proprietary approaches.

The PSA vision is that the OSS/BSS interfaces will be modelled in an abstract way and then referred to from the Item hierarchy. This way, process knowledge, such as knowing the correct OSS/BSS provisioning operations to invoke, and knowing when to invoke them, can be based on configuration that is obtained at discovery time. Using this approach makes it easy to swap in and out different supporting OSS and BSS platforms because their specific operations will not be hard coded into the Items.

The PSA architecture recognises a small number of alternative approaches for Active Catalog to OSS/BSS integration. The choice between these will depend on a Telco's situation and aspirations.

One approach would see Active Catalogs interfacing directly with each of their associated OSSs/BSSs, and executing most or all of the process steps fairly directly, perhaps via a closely associated activation system. This is most likely to be appropriate at the lower Resource layer and, possibly, at the Service layer.

A second approach, which would be expected to bring rather more benefit, applies where a Telco has implemented an SOA, even if only between the Active Catalogs and the OSSs/BSSs. The use of SOA implies that OSS/BSS functionality is presented and employed primarily via reusable services, each performing a clear and limited job of work, that can be invoked in a common way such as via a shared message format. In this case, the Active Catalogs would again control most of the process, but would simply need to be able to send and receive messages in the local shared message format. The Active Catalogs could then use the available SOA services in a more dynamic manner.

The third approach might apply where, in addition to implementing an SOA, a Telco has a well developed strategy for Business Process Management (BPM) and Business Activity Monitoring (BAM). In this case, the Active Catalogs could generate processes, such as fulfil processes, in standard representations, such as Business Process Execution Language (BPEL). These processes could then be imported into the Telco's BPM engine and executed with the benefits of that established environment.

3.4 A Worked Example

Although a significant amount of work was carried out by the PSA team in developing an architecture and interface specification, the end goal was the development of a working PoC. By developing and demonstrating a PSA PoC to a wide audience, the PSA team was able to refine the architecture and interface, and gain confidence in the approach taken.

The PoC was based around the OSS/BSS assembly and orchestration of two variations of IP Private Branch Exchange (PBX) offerings. The scenario was chosen because it was complex enough to demonstrate the power of the PSA architecture, whilst, at the same time, not having an overly-complex actual feature set. Figure 11 shows how the two offerings were modelled at the Product, Service and Resource Catalog layers. The figure could be viewed as a complete picture, at the end of a CAD cycle, showing how the two Product offerings are modelled. The Resource Catalog models components such as hardware, application server software and core applications.

CAD View of SME VoIP Product Items Fig 11 CAM View Indicating OSS/BSS Provisioning Fig 12

The Service Catalog is shown"importing" the necessary Resource Items* and combining or repurposing them to create Service Items. In turn, the Product Catalog is shown importing the necessary Service Items and combining them to create the two Small-to-Medium Enterprise (SME) VoIP Product Items. Note also the SID equivalent terminology on the right-hand-side of the figure.

Proof of Concept System Solution Fig 13

For the demonstration, once the Product Items to be offered were modelled, they were offered to the order capture application for subsequent customer ordering. Figure 12 provides a visual indication of the OSS/BSS processes that are invoked once an order is accepted. In essence, the figure represents the CAM cycle generated as a result of ordering the "SME VoIP Silver" product. Starting at the top of the figure, an order for the SME VoIP Silver product initiates the "decomposition" of the SME VoIP Silver Product Item into the "Base PBX" and "PBX Line" Product Items. This decomposition process continues down the Item hierarchy until the bottom of the hierarchy is reached, with each Item in the hierarchy playing its part in provisioning the necessary OSSs/BSSs.

It should be noted, however, that the traversal of the hierarchy is not a single top-to-bottom pass but may take the form of one or more passes down and back up the hierarchy, depending on whether checks and reservations, and so on, are made. Traversal of the Item hierarchy will action the necessary OSS/BSS provisioning processes, such as PBX activation and phone ordering. Only once all the necessary OSS/BSS processes are complete, can the CAM
cycle also be considered complete. It should also be noted that for the purpose of the PoC, only a subset of the OSS/BSS processes shown in figure 12 were delivered. The PoC demonstrated the ordering and subsequent OSS/BSS orchestration of SME VoIP Silver product, followed by the assembly, ordering and subsequent OSS/BSS orchestration of SME VoIP Gold product. The demonstration was carried out in real-time, showing almost immediate OSS/BSS assembly and provisioning, and the validity and power of the approach taken.

Figure 13 shows the complete system solution that was built by the PSA vendors for the PoC. The green shaded area shows the main OSSs/BSSs; the red shaded area shows the Service Creation and Product and Service Assembly tools; and the yellow shaded area shows the main Service Function capabilities. The OSSs/BSSs consisted of the Active Catalogs, Oracle Siebel CRM [15], Axiom AXIOSS Service Activation [16], and Oracle Fusion BPEL Process Manager [17].

With the exception of the Active Catalogs and Assembly tools, the system solution was built with enterprise-grade products that are either commercially or freely available. The Active Catalogs provided the mediation between all systems, while all of the main Service Function capabilities were modelled as Items as shown earlier.

4. PSA Next Steps


Two public next steps are currently underway to build on the results of the phase 1 Catalyst. Firstly, phase 2 of the PSA Catalyst is expanding the team and the scope of the work. The phase 2 team consists of Atos Origin, Axiom Systems, BT, C&W, Convergys, Huawei, Microsoft, Oracle, QinetiQ, TeliaSonera and Tibco. Figure 14 shows the increased scope of the work, with the use of multiple Resource Catalogs and the inclusion of billing aspects into the PoC. The enhanced scope now rolls-in a more complex Triple-Play "product journey"* incorporating VoIP* Video on Demand (VoD) and Broadband. It is expected that Microsoft will provide a Resource Catalog supporting VoD; Oracle will provide Resource Catalog supporting VoIP; and Huawei will provide a Resource Catalog supporting network and client devices. In addition, it is expected that the Oracle Resource Catalog will contain one of the BT Web21CTM Software Development Kit (SDK) [18] capabilities, namely Short Message Service (SMS). While a small aspect of billing and rating is to be addressed by the demonstration, it is expected that this work will be supplemented by a paper-based exercise looking at the implications of not only rating, billing and charging, but also assurance TMF OpenOSS group has been identified because it provides a rally point for OSS/BSS and open source software. Because each of these bodies has unique qualities, it is likely that one or more of these bodies will be approached to act as host to the PSA specification work have been identified. These are the Organization for the Advancement of Structured Information Standards (OASIS) group [19], the TMF New Generation Operations Systems and Software (NGOSS) Contract group [20], and the TMF OpenOSS group [21]. OASIS has been identified for its industry-strength in XML related standards. The TMF NGOSS Contract group has been identified for the unique position it holds in being at the brink of developing a raft of much-needed standards for the Telco OSS/BSS industry. Finally, the TMF OpenOSS group has been identified because it provides a rally point for OSS/BSS and open source software. Because each of these bodies has unique qualities, it is likely that one or more of these bodies will be approached to act as host to the PSA specification work.

PSA Phase 2 OSS/BSS System Solution Fig 14

It is intended that he results of the phase 2 Catalyst will be made available at the TMF World Conference event in May 2007 at Nice, France. In addition to this short-term Catalyst activity, a longer-term activity, called the PSA Initiative [22], is underway which will initially provide an additional marketing channel for the work. The potential to use this initiative as a means to host other activities, such as developing open source implementations to stimulate a PSA ecosystem, are also being considered.

5. Conclusion


This paper has highlighted the process of provisioning the OSS and BSS as the biggest bottleneck in the Telco production line. This bottleneck must be addressed if Telcos are to be able to successfully offer a plethora of Product and Service offerings on their NGNs. The paper describes an approach taken by the PSA Catalyst to overcome this problem. Such an approach is grounded in similar approaches taken within the automotive and aerospace industries. The PSA approach has resulted in the creation of the Active Catalog concept, which provides a bridge across all the cooperating Telco domains of expertise. The paper sets out the PSA approach, architecture, interface and PoC in detail. Finally, we have highlighted some of the next steps that the PSA team is taking or planning on taking.

Much has already been achieved by the PSA team in such a short time, and there is an industry-wide buzz about this activity [23], [24],[25]. However, expectations should be managed as there is definitely no shortage of work that still needs to be carried out. Solutions to the outstanding general issues need to be addressed by either specification or implementation work before full deployments can be discussed. Nevertheless, it is expected that a combination of work carried out by the PSA Initiative and TMF PSA Catalysts will pave the way for Telcos to take PSA further. Outside of the public eye, Telcos and vendors are already working on testbeds and leads to accelerate PSA solutions and to determine whether PSA can truly help streamline the Telco OSS/BSS production line.

Acknowledgements


The authors would like to thank Dave Milham (BT Group CTO office and TMF Distinguished Fellow) and John Wittgreffe (BT Group CTO office) for their invaluable suggestions and support.

References


  1. Beyond Triple Play: forecasts for broadband value-added services, Margaret Hopkins, Analysys Research Limited, 2006, http://research.analysys.com/default.asp?Mode=article& iLeftArticle=2265&m=&n= Top
  2. The Long Tail, Chris Anderson, Wired Magazine, October 2004, http://web.archive.org/ web/20041127085645/ http:/www.wired.com/wired/archive/12.10/tail.html Top
  3. Wikipedia,http://en.wikipedia.org/wiki/The_Long_Tail Top
  4. The Common Capability Approach to New Service Development'* Brian Levy, January 2005, BT Technology Journal, http://www.springerlink.com/content/q477u4k34lrx5218/?p= adf5664766244729925c20a83d2d6405&pi=5 Top
  5. TeleManagement Forum, http://www.tmforum.org Top
  6. TeleManagement Forum Catalyst Program, http://www.tmforum.org/browse.aspx?catID=786 Top
  7. Service Delivery Platform Taxonomy: The Who, What and How of SDPs, Sharon Ballard, Yankee Group, September 2006, http://www.yankeegroup.com/ResearchDocument.do?id= 14548 Top
  8. CIMdata, Product Lifecycle Management, http://www.cimdata.com/PLM/plm.html Top
  9. Martin Day, CAD Digest, What is PLM, http://www.caddigest.com/subjects/PLM/select/ day_plm.htm Top
  10. The Value Proposition of Product Lifecycle Management Software Solutions, Qualitative Change, October 2006, http://www.mobileeurope.co.uk/white_papers/white_paper.ehtml?o= 2682 Top
  11. TMF SID, http://www.tmforum.org/browse.aspx?catID=1684 Top
  12. TMF eTOM, http://www.tmforum.org/browse.aspx?catID=1647 Top
  13. TMF TAM, http://www.tmforum.org/browse.aspx?catID=2322 Top
  14. PSA IIS, to be published at http://www.tmforum.org/browse.aspx?catID=880 Top
  15. Oracle Siebel CRM, http://www.oracle.com/siebel/index.html Top
  16. Axiom AXIOSS Service Activation, http://www.axiomsystems.com/products/service-activation.aspx Top
  17. Oracle Fusion BPEL Process Manager, http://www.oracle.com/appserver/bpel_home.html Top
  18. BT Web21CTM SDK, http://sdk.bt.com/ Top
  19. OASIS, http://www.oasis-open.org/home/index.php Top
  20. TMF NGOSS Contract, http://www.tmforum.org/browse.aspx?catID=3951&linkID=32150 Top
  21. TMF OpenOSS, http://www.tmforum.org/browse.aspx?catID=2602 Top
  22. PSA Initiative, http://www.psainitiative.org/index.html Top
  23. index.html Top
  24. Telephony Online, http://telephonyonline.com/software/technology/tmw_catalyst_showcase_1 Top
  25. Vanilla Plus, http://www.psainitiative.org/axiom4pageraw.pdf Top
  26. Light Reading, http://www.lightreading.com/document.asp?doc_id=120419

Authors


Photo 1 Gary Bruce is a Principal Researcher within BT's Group CTO office. He leads research and exploitation activities for both PSA and open source OSS software. Gary has worked on network signalling systems and open network Application Programming Interfaces (APIs), here at BT and, previously, at Sun Microsystems. His work on open network APIs led to his involvement in various international projects, adopting key roles within the Parlay Group and related initiatives.
Photo 2 Brian Naughton is the VP Strategy and Architecture at Axiom Systems. He joined the company in May 2006 from global telecommunications provider, Cable & Wireless where he reported to the Group CIO. He was responsible for a global fulfillment architecture and instrumental in creating their next generation OSS blueprint that underpins C&W transformation to NGN. Prior to C&W, he worked for BT, Sun Microsystems, BEA Systems and Intel.
Photo 3 Dave Trew is the technical lead for the PSA Catalyst. He is an Enterprise Architect in Atos Origin's Telco group, providing leadership for Enterprise Application Integration (EAI) projects and end-to-end OSS/BSS solutions. In recent projects he led a major brown-field EAI programme for a European Tier One Telco and a full zero-touch provisioning solution for a European Digital Subscriber Line (DSL) provider. Recently, he has contributed to scoping and IT architecture for a major NGN/All-IP programme.
Photo 4
Martine Parsons is the Marketing Director at Axiom Systems. Responsible for effective marketing techniques to communicate the Axiom Systems value proposition, brand and mission globally, she joined the company in April 2001 following an initial round of VC funding and an aggressive expansion plan for global solutions. Prior to Axiom Systems, Martine worked for BEA Systems, Broadbase Software, Avaya and Microgen.
Photo 5 Paul Robson is a Senior Researcher working on PSA, Information and Communication Technology (ICT) Audit and Total ICT Virtualisation within the BT Group CTO office. Paul began his career in BT, developing Java Web applications on various portal systems for BT's corporate customers. He moved into research in 2004 where he has worked extensively with open source OSS systems both at BT and, externally, with the TMF.

« Previous | home | Next »