Streamlining the telco production line

Service oriented infrastructure (Part 2)   » Log in

Streamlining the telco production line

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

E-mail a friend

E-mail the author

Thank you!

It has long been the desire of telecommunications companies (telcos) to deliver a wealth of products aligned to their customers' evolving needs. In an ideal world, these would be developed quickly and efficiently. In reality, however, the need to use an assortment of back-office processes, some of which are costly, lengthy and error-prone, means it can take 18 months to deliver each product. Such timescales are no longer acceptable. In today's competitive commercial environment, customer demands and expectations are rising. The massive investments telcos are making to introduce next-generation networks will resolve some of these issues but, given the surge of new products such networks are expected to make possible, it is clear that delivery processes must also be transformed if telcos are not just to survive, but to flourish.

Generally, the most costly and time-consuming stages of the telco production line are those associated with the development or configuration of Operational Support Systems (OSSs) and Business Support Systems (BSSs). Little has been automated, so significant levels of expertise and effort are still required to develop the solutions each new product¹ needs and to adapt them as products evolve. The resulting bottleneck impedes the flow of innovations to the market and drives up cost. To help telcos overcome this problem, the TeleManagement Forum (TMF) set up the Product and Service Assembly (PSA) team. Its remit is to identify and define standards that would enable automation and encourage the development of an ecosystem of supporting tools. The approach the PSA team is taking draws on techniques used in the manufacturing industry. Work has progressed rapidly and has attracted widespread support. Working with key telcos, software vendors and equipment manufacturers, the PSA team quickly delivered its first two prototypes. This paper describes the architecture the PSA team has proposed, the interfaces it uses and the prototype that has been developed. The next steps in the project are explained.

---

¹ For brevity, the term 'product' in this paper is used to cover both products and services.

Over the years, telcos have developed a broad range of products to meet their different customers' needs. All too often, however, products were generally developed in isolation from one another. As a result, each was delivered using a separate set of execution and management platforms. Viewed with the benefit of hindsight, it was an approach that clearly would not scale.

But scale it must. In the future, telcos will have to develop and support many more products than before [1]. Some, like basic internet access and voice packages, will be sold in large quantities, but others will attract far fewer customers. Like companies in other industries, telcos will want to exploit the commercial potential of 'the long tail' [2]. As illustrated in figure 1, the revenues generated by a high number of low-demand offerings (shaded light grey) can equal or outweigh those produced by the few high-demand offerings (shaded dark grey).

        Figure 1. The long tail (reproduced from [3])

For the telcos to turn this concept into reality, they need:

- platforms that can support the delivery of large numbers of products;
- production lines that allow new products to be developed and deployed quickly and cost effectively; and
- easy-to-use interfaces that encourage third party and customer innovation.

Together, these components will enable telcos to offer very large numbers of products and make it possible for them to offer products that are more transient than those they have sold in the past – for example, products that respond to fashions and other trends.

The good news is that Next-Generation Network (NGN) technologies, such as the Internet Protocol Multimedia Subsystem (IMS) and the 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 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. Both the service function and service management capabilities are needed before a product can be put on sale. Without one, 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.

        Figure 2. Customer-driven innovation

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. While good progress has been made in this area, relatively little attention has been given to the development of technologies needed to accelerate the assembly and orchestration of service management capabilities, which are the main focus of this paper. While some Service Assembly Environment (SAE) tools are available commercially, the management support they deliver is insufficient to turn 'raw' services into orderable, repairable and billable product offerings.

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 the mass productisation necessary if telcos are to exploit the long tail. The figure depicts the NGN as a cloud and the capabilities it supports or accesses as hexagons. As well as supporting a telco's service function and service management capabilities, the NGN also has access to external web services. The service function and service management manipulation tools that enable the rapid delivery of product offerings are represented in the figure by arrows. At the top of the figure, is the customer whose continuous need for innovation is responsible for the continuous delivery of new products. Only by bringing all these elements together can the best environment be created to promote mass productisation.

Unfortunately, it just takes one deficiency in this environment to jeopardise the goal of mass productisation. Today, it can take telcos up to 18 months to provision the OSSs and BSSs for a new offering. If they are to reduce this time to weeks – if not days – the various organisational departments and systems required to assemble and orchestrate service management capabilities must cooperate in a seamless and well-understood way. Currently, however, there is generally little or no cooperation across systems. Product knowledge must be duplicated across many different OSSs and BSSs, and few require it to be coded in the same way. Opportunities for the knowledge to be shared among OSSs and BSSs are limited. As a result, development costs and timescales can easily become prohibitive, which makes the 'long tail' difficult, if not impossible, to realise.

The TMF set up its PSA team to tackle this problem [5]. It was initially run as a TMF 'catalyst' project [6] – that is, in a way designed to take new ideas quickly through to the development of practical demonstrators. The PSA catalyst's 'big idea' was to create a new Information Technology (IT) reference architecture that would decouple detailed product knowledge from the OSSs and BSSs that need it, making it possible for a common body of knowledge to be used by all the systems that cooperate to deliver telco products to market. In creating the architecture, the PSA team drew its inspiration from industries that have solved the problem of managing production lines across complex organisational boundaries. Manufacturing industries, for example, have developed a discipline called Product Lifecycle Management (PLM) which is very relevant to the challenge presented to the PSA team.

PLM is now a well-established and well-understood technique. It builds on concepts from Computer Aided Design (CAD), Computer Aided Manufacturing (CAM) and Product Data Management (PDM), assembling pre-existing production line 'building blocks' in ways that allow the automated manufacture of the required product. A similar approach has been taken by the PSA team. The architecture it has developed requires product knowledge of interest to existing OSSs or BSSs to be extracted from that system and held instead in new architectural elements called 'active catalogs'². Collectively, these catalogs provide a place where all of the building blocks from which a product is constructed 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 use of the term 'active' emphasises 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 support this dual use, the definition of an item in an active catalog must include both the rules that govern its connection to other items plus the full instructions for provisioning whatever OSSs and BSSs it requires. For example, an item may reference a combination of activation processes, billing processes and element manager processes that, together, allow activation, billing and assurance processes to be completed automatically.

While the active catalog approach leaves existing OSSs and BSSs in control of their own specialist areas, it makes it easier for such systems to share product knowledge. As a result, it becomes possible for a product manager or even a customer to assemble items without having to worry about the full end-to-end provisioning process. This would be dealt with using the product knowledge held within the items.

To help realise its architecture, the PSA team has undertaken two pivotal activities. The first is the creation of a Web Services Description Language (WSDL) interface for active catalogs. The second is the development of proof of concept demonstrators. The WSDL interface allows active catalogs to publish details of the items they offer, and catalog users to request the provisioning of required OSSs and BSSs. The proof of concept demonstrators were used to evaluate, develop and socialise the PSA architecture and the active catalog interface. Overall, the team's goal is to establish its architecture and active catalog interface as the basis of a new standard for the OSS and BSS aspects of the telco production line.

---

² We use the American spelling of catalog in this paper as this is the spelling preferred by the relevant technical communities.

To provide clarity within the scope of this paper, we will begin by defining the terms we intend to use.
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. The levels are subjective, however. They are 'personal' to the organisation that defines them.

The term 'service creation' is used to define a systematic way to design, code and analyse service function capabilities, and to 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 term 'service assembly'. As a result of the work of the PSA team and accompanying publicity, focus has shifted towards the assembly and orchestration aspects of OSSs and BSSs. The word 'product' is included 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, OSSs and BSSs.

The companies that participated in phase 1 of the PSA catalyst were Atos Origin, Axiom Systems, BT, Cable & Wireless, Celona, Huawei, Oracle and TeliaSonera. Work started in June 2006 and was showcased at the TMF World Conference in Dallas in December 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.

4.1 Learning from other industries
Before the PSA team attempted to develop any potential solutions, the decision was made 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 the PLM technologies used throughout the product lifecycle. In addition to the end-to-end product lifecycle, note that lifecycles also exist for the components that make up the products. Thus, changes to components can affect the behaviour of a product that might already be in-service.

        Figure 3. PLM technologies used within the product lifecycle

The benefits of using PLM include reduced time-tomarket, improved product quality, reduced prototyping costs, savings through the re-use of original data and 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 telco OSS/BSS assembly and orchestration. To explain the application of PLM in a typical telco environment, it helps to understand the technique's core functions. Initially, a product idea is developed, using topdown design in conjunction with customer requirements and other external conditions. One or more iterations are completed at this level to define the major building blocks of the product specification. Next, the product specification is detailed. The development stage uses this to take the product from design to prototype, through trial and eventually on to launch. The main tool for enabling the first half of the PLM process is CAD. 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.

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 an anticlockwise direction, these can be described as the portfolio, engineering, OSS and IT departments. For the purposes 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 as modelling tools by portfolio departments to estimate the impact of a new product. In most cases, however, telcos use only simple text descriptions for products. The processes used are, at best, very ad-hoc. The engineering community owns an understanding of its capabilities – for example, of the logical functions that can be supported. The operational support groups understand how to support logical functions. Currently, this understanding is very much in the context of commercialoff- the-shelf or custom OSS applications. Lastly, the customer-facing IT organisation owns the commercial understanding of the product. Understanding here is again very much in the context of commercial-off-the-shelf or custom BSS applications.

An issue in the telco environment is that the way in which all the information is usually brought together to create a coherent PLM process is inherently flawed. There is no detailed modelling component that can bridge all of the domains of expertise. As a result, islands of knowledge must be bridged manually every time a product offering needs to be worked out. There is, however, a reason why these islands of knowledge have evolved. Historically, a comprehensive approach to telco productisation was rarely required. As a result, there was no need to formalise the PLM processes. Today, however, the need for a formalised process is paramount. To create it, the PSA team has proposed a new IT reference architecture that seeks to bridge the various islands of knowledge and establish a formalised PLM process for telcos.

        Figure 4. Applying PLM to the telco

4.2 Catalog-provisioned OSS/BSS
In its simplest form, the PSA IT architecture 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 of 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 catalog. Traditional catalogs are registers of offerings that may be enhanced with information such as pricing, availability and Service Level Agreement (SLA) data. In addition, traditional catalogs 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 catalogs, 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.

The PSA architecture provides an opportunity to create a complete PLM story for the telcos. However, the PSA team is currently only focusing on the portfolio, active catalog, BSS and OSS elements, as these are the areas of most concern. Technology already exists to create and execute services on SEPs. It is the PSA team's intention to supplement SEPs, not replace them. At some future point in time it may be beneficial to provide a totally-integrated PLM solution for telcos.

        Figure 5. Central role of the active catalog

        Figure 6. The PSA federated IT architecture

The second key aspect to this architecture is that the active catalog is not just a single element. A federation of active catalogs is required.

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 to mirror the SID's product, service and resource components. While this is the convention chosen by the PSA team, the flexibility of the architecture should be noted. It can accommodate any number of layers of active catalogs, each representing their own particular degree of abstraction. In addition, each layer of abstraction can contain multiple active catalogs.

To improve clarity and provide focus, the architecture only depicts the active catalog, OSS and BSS elements, and highlights the general PLM flow left-to-right. Starting from the left-hand side of the figure, assembly tools (not shown) will manipulate and populate the product, service and resource catalogs that contain product, service and resource items, respectively. Each item in an active catalog is capable of containing data, rules and process. These elements 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, offering their knowledge upwards and handling downward requests. For example, during the CAD cycle, service items could be offered 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 OSS/BSS applications that are their users appear above the highest layer of active catalogs – typically, the product catalogs. Such applications could include the product introduction, order capture or online self-care aspects of CRM. Towards the end of the CAD cycle, for example, a product introduction application 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.

When a product instance is ordered, 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 and 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, as shown on the right-hand side of the figure, the actions initiated by the active catalogs on the OSSs and BSSs may cause external changes, such as delivery of hardware or the remote configuration of phones.

        Figure 7. PSA Relationship with the eTOM

Note that, in the figure, the layering of product, service and resource inventories corresponds to that 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. 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 vendor applications across the whole OSS/BSS space. Given the limited number of vendor applications that address this problem and the immaturity of the standards in this problem space, this federated approach is 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 they provide a means to quickly incorporate capabilities from third parties, and also provide a means to quickly expose capabilities further up the value chain.

        Figure 8. Exposing layers of abstraction within and across organisational boundaries

While the PSA architecture depicts only one of each type of active catalog, this is not a restriction. Multiple catalogs of the same type could be used.

Figure 8 highlights 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, both the service catalog and 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, be re-sold to service provider B (a virtual operator) and service provider C (which is offering some value-add). The result is a hierarchy of product catalogs illustrating that one service provider's product can, in effect, be likened to a service by another service provider. Note that, in figure 8, service provider A offers 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.

4.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 reside 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 and BSSs to support it.

Data knowledge might include data required by the item before an order can be made, such as the number of handsets required. It might also include data returned after an item has been allocated, such as the Internet Protocol (IP) address assigned to it.

        Figure 9. Active catalogs, items, data, rules and process

Rules knowledge might include details of how items are to be checked – for example, to verify that an order can be raised. The knowledge might include rules about compatibility – whether an item ordered will be compatible with an item ordered previously, for instance. It 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 and BSSs, such as provisioning a product offering into a billing system.

To manipulate items in a technology-neutral way, the PSA team is defining active catalog interfaces in eXtensible Markup Language (XML) and making them available as web services via WSDL. Two categories of active catalog interface have been identified as candidates for standardisation. These are the 'offer-and-request' and 'action' interfaces 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 that connects the active catalog to the OSSs and 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.

4.3.1 The offer-and-request interface
A key aspect of the offer-and-request interface is that its definition is identical at all levels of abstraction. For example, the offer-and-request interface for a product catalog is the same as that for a service or resource catalog. By making this decision, the PSA team has made its active catalog hierarchy totally flexible. It can contain any number of layers of abstraction, each of which can be categorised as deemed fit. The second key aspect of the offer-and-request interface is that it is agnostic with respect to the product modelling styles used within 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, the company's variant of the SID. 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 only for the details in which it is interested, expressed as name-string pairs. Other operations follow this approach, dealing only with the details of interest and with no concern for peer product models. Table 1 shows the initial operations identified for the offer-andrequest 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.

As a consequence of its discoverable, loosely-coupled nature, the offer-and-request interface can be used to dynamically discover the OSS/BSS provisioning process steps related to each item. The detail 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.

Operation	Description
Discover	This operation is used to get the full details of a particular item.
Validate	This operation is used to check that everything is logically ready before an order can be accepted.
Feasibility	This operation is used to check that everything is physically ready once an order has been accepted.
Reserve	This operation is used to reserve all the necessary 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 provisioning changes on the OSSs/BSSs associated with a previous order. It is the reverse of the 'fulfil' operation.
Release	This operation is used to remove the resources associated with a previous order. It is the reverse of the 'reserve' operation.

Table 1. Initial PSA offer-and-request operations

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 was published in 2007.

4.3.2 The action interface
The action interface conveys communication between the active catalogs and all OSR and FAB systems. When communicating with 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 a mixture of standardsbased and proprietary approaches.

The PSA vision is that the OSS/BSS interfaces will be modelled abstractly and referenced from the item hierarchy. 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. Because their specific operations will not be hard coded into the items, the approach makes it easy to swap in and out different supporting OSS and BSS platforms. 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 and 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 and BSSs. The use of SOA implies that OSS and BSS functionality is presented and employed primarily via reusable services, each performing a clear and limited job of work. Each can then be invoked in a common way – via a shared message format, for example. 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 in way that delivers the benefits of that established environment.

4.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 proof of concept demonstration. By developing such a demonstration, the PSA team was able to refine the architecture and interface, and gain confidence in the approach taken. The demonstration was based around the OSS/BSS assembly and orchestration of two IP Private Branch Exchange (PBX) offerings. The scenario was chosen because it was complex enough to demonstrate the power of the PSA architecture while not having an overly-complex actual feature set.

Figure 10 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. 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 two VoIP product items for small-to-medium-sized enterprises. Note also the SID-equivalent terminology on the right-hand side of the figure.

        Figure 10. CAD view of SME VoIP product items

Once the product items to be offered had been modelled, they were offered to the order capture application for subsequent customer ordering. Figure 11 provides a visual indication of the OSS and 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 demonstration, only a subset of the OSS/BSS processes shown in figure 11 were delivered. The demonstration showed the ordering and subsequent OSS/BSS orchestration of the SME VoIP Silver product, followed by the assembly, ordering and subsequent OSS/BSS orchestration of the SME VoIP Gold product. It was carried out in real-time, showing almost immediate OSS/BSS assembly and provisioning and the validity and power of the approach taken. Figure 12 shows the complete system solution that was built by the PSA vendors for the proof of concept demonstrator. The top left block shows the main OSSs/BSSs, that at the bottom the service creation and product and service assembly tools and the that top right 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.

Two public next steps followed the phase 1 catalyst. First, phase 2 of the catalyst expanded the team and the scope of the work. The phase 2 team consisted of Atos Origin, Axiom Systems, BT, Cable & Wireless, Convergys, Huawei, Microsoft, Oracle, QinetiQ, TeliaSonera and Tibco. Figure 13 shows the increased scope of the work, with the use of multiple resource catalogs and the inclusion of billing aspects into the proof of concept demonstration. A more complex triple-play 'product journey', incorporating VoIP, Video on Demand (VoD) and broadband was also included. Microsoft provided a resource catalog supporting VoD, Oracle a resource catalog supporting VoIP and Huawei a resource catalog supporting network and client devices. In addition, the Oracle resource catalog contained the Short Message Service from BT's Web21C Software Development Kit [18]³.

        Figure 11. CAM view indicating OSS/BSS provisioning

        Figure 12. Proof of concept system solution

        Figure 13. PSA phase 2 OSS/BSS system solution

Second, phase 2 of the catalyst developed and made public the first version of the PSA specification. The work has resulted in a TMF standard [19] and is being continued in the TMF Interface Program (TIP) catalog management team [20,21] and under SourceForge [22].

The TMF NGOSS contract group has been chosen 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, while SourceForge has been chosen because it provides a convenient way to expose the work to a wider community under the open source banner.

The results of the phase 2 catalyst were made available at the TMF's May 2007 World Conference in Nice, France, where they received the 'Best Catalyst 2007' award. In addition to the short-term catalyst activities, a longer-term activity, called the PSA initiative [23], is underway and provides 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.

---

³ The Web21C SDK has since become part of BT's Ribbit platform.

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 team 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 the initial proof of concept demonstration in detail.

Finally, this paper has highlighted some of the other activities the PSA team has undertaken. Much has already been achieved by the PSA team, and there is an industry-wide buzz about this activity [24, 25 and 26]. However, expectations must be managed. There is no shortage of work remaining to be carried out. In particular, outstanding issues must be addressed by either specification or implementation work before full deployments can be discussed. Nevertheless, it is expected that the combination of work carried out by the PSA initiative and TMF PSA catalysts has paved the way for telcos to take PSA further. Outside of the public eye, telcos and vendors are already working on prototype PSA solutions to determine whether PSA can truly help them streamline their OSS and BSS production lines.

The authors would like to thank Dave Milham (formerly of BT Group) and John Wittgreffe (BT Group) for their invaluable suggestions and support.

1. Hopkins M, 'Beyond triple play: forecasts for broadband value-added services', Analysys Research Limited, 2006, http://research. analysys.com/default.asp?Mode=article& iLeftArticle=2265&m=&n= Top
2. Anderson C, 'The long tail', Wired Magazine, October 2004, http:/www.wired.com/wired/archive/12.10/tail.html Top  
3. Anon, 'The long tail', Wikipedia, http://en.wikipedia.org/wiki/ The_Long_Tail Top  
4. Levy B, 'The common capability approach to new service development', BT Technology Journal, vol.23, no.1, January 2005, pp.48-54 Top
5. TeleManagement Forum, http://www.tmforum.org Top
6. TeleManagement Forum Catalyst Program, http://www.tmforum.org/ browse.aspx?catID=786 Top
7. Ballard S, 'Service delivery platform taxonomy: the who, what and how of SDPs', Yankee Group, September 2006, http://www.yankeegroup .com/ResearchDocument.do?id= 14548 Top
8. CIMdata, 'Product lifecycle management', http://www.cimdata.com/ plm/definition.html Top
9. Day M, 'What is PLM?', CAD Digest, http://www.caddigest.com/ subjects/PLM/select/day_plm.htm Top
10. 'Qualitative Change', Mobile Europe, January 2007, http://www. mobileeurope.co.uk/white_papers/1127/Qualitative_Change.html Top
11. TeleManagement Forum, 'Shared information/data framework', http://www.tmforum.org/browse.aspx?catID=1684 Top
12. TeleManagement Forum, 'eTOM business process framework', http://www.tmforum.org/browse.aspx?catID=1647 Top
13. TeleManagement Forum, 'TAM applications framework', http://www.tmforum.org/browse.aspx?catID=2322 Top
14. TeleManagement Forum, 'Product and service assembly catalyst release 2.0', http://www.tmforum.org/InterfaceImplementation/ TMF867ProductandService/33019/article.html Top
15. Oracle Siebel CRM, http://www.oracle.com/siebel/index.html Top
16. Axiom AXIOSS service activation, Following the acquisition of Axiom by Comptel, this is now know as the Comptel Provisioning and Activation Solution. For details, see http://www.comptel.com/ ProvisioningActivation/ Top
17. Oracle, 'Fusion BPEL process manager', http://www.oracle.com/ appserver/bpel_home.html Top
18. BT, 'Web21C SDK', http://sdk.bt.com/ Top
19. TeleManagement Forum, 'TMF211', http://www.tmforum.org/ Contracts/TMF211ActiveCatalog/34048/article.html Top
20. TMF Interface Program, http://www.tmforum.org/InterfaceProgram/ 5733/home.html, Top
21. TMF Interface Program catalog management team, http://www. tmforum.org/cws/view_folder.aspx?SelectedIndex=4&team_ID=222 Top
22. The PSA initiative API, http://sourceforge.net/projects/psa-api/ Top
23. The PSA initiative, http://www.psainitiative.org/ Top
24. McElligott T, 'Being the catalyst', Telephony Online, October 31, 2006, http://telephonyonline.com/software/technology/tmw_ catalyst_ showcase_103106/index.html Top
25. W'Product and service assembly: better by design', Vanilla Plus, vol.8, no.4, December 2006, http://www.psainitiative.org/axiom 4pageraw.pdf Top
26. The PSA Initiative, 'OSS firms team up', Light Reading, March 27, 2007, http://www.lightreading.com/document.asp?doc_id=120419 Top

Gary Bruce is a principal researcher at BT. Currently, he leads the company's research and exploitation activities for both PSA and open-source OSS software. Previously, he worked on network signalling systems and open network Application Programming Interfaces (APIs), both at BT and in an earlier employment at Sun Microsystems. His work on open network APIs led to his involvement in international projects including those of the Parlay Group.

Brian Naughton is 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. There, he was responsible for a global fulfilment architecture and was instrumental in the creation of the next-generation OSS blueprint that underpinned the company's next-generation network. Prior to joining Cable & Wireless, he worked for BT, Sun Microsystems, BEA Systems and Intel.

Dave Trew is the technical lead for the PSA catalyst project. 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. Recent projects have included a major brown-field EAI programme for a European tier-one telco and a full zerotouch provisioning solution for a European digital subscriber line provider. He has also contributed to scoping and IT architecture for a major all-IP next-generation networking programme.

Martine Parsons is the marketing director at Axiom Systems. Responsible for effective marketing techniques to communicate the company's 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 joining Axiom Systems, Martine worked for BEA Systems, Broadbase Software, Avaya and Microgen.

Paul Robson is a senior researcher working on PSA, Information and Communication Technology (ICT) audit and total ICT virtualisation at BT. He began his career in BT, developing Java web applications for portal systems used by BT's corporate customers. He moved into research in 2004 and has since worked extensively with open source OSS systems, both at BT and with the TMF.

« Previous

|

|

Next »