Service oriented infrastructure (Part 2)
Streamlining the telco production line
G Bruce, B Naughton, D Trew, M Parsons and P Robson
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 product1 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.
1 For brevity, the term 'product' in this paper is used to cover both products
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 .
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' .
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 )
For the telcos to turn this concept into reality, they need:
- platforms that can support the delivery of large numbers
- production lines that allow new products to be
developed and deployed quickly and cost effectively;
- easy-to-use interfaces that encourage third party and
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 .
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 . It
was initially run as a TMF 'catalyst' project  – 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'2. 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.
2 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
The term 'service delivery platform' is a very loosely
defined and evolving term . 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.
4. Phase 1 of the PSA catalyst
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 . 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)  and enhanced Telecoms
Operations Map (eTOM)  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)  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
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.
|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
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 , 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
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 , Axiom AXIOSS Service
Activation , and Oracle Fusion BPEL Process Manager .
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.
5. Other PSA activities
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 3.
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  and is being continued in the
TMF Interface Program (TIP) catalog management team [20,21] and under SourceForge .
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 , 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.
3 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
The authors would like to thank Dave Milham (formerly of BT
Group) and John Wittgreffe (BT Group) for their invaluable
suggestions and support.
- 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
- Anderson C, 'The long tail', Wired Magazine, October 2004,
- Anon, 'The long tail', Wikipedia, http://en.wikipedia.org/wiki/
- Levy B, 'The common capability approach to new service
development', BT Technology Journal, vol.23, no.1, January 2005,
- TeleManagement Forum, http://www.tmforum.org Top
- TeleManagement Forum Catalyst Program, http://www.tmforum.org/
- 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
- CIMdata, 'Product lifecycle management', http://www.cimdata.com/
- Day M, 'What is PLM?', CAD Digest, http://www.caddigest.com/
- 'Qualitative Change', Mobile Europe, January 2007, http://www.
- TeleManagement Forum, 'Shared information/data framework',
- TeleManagement Forum, 'eTOM business process framework',
- TeleManagement Forum, 'TAM applications framework',
- TeleManagement Forum, 'Product and service assembly catalyst
release 2.0', http://www.tmforum.org/InterfaceImplementation/
- Oracle Siebel CRM, http://www.oracle.com/siebel/index.html Top
- 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/
- Oracle, 'Fusion BPEL process manager', http://www.oracle.com/
- BT, 'Web21C SDK', http://sdk.bt.com/ Top
- TeleManagement Forum, 'TMF211', http://www.tmforum.org/
- TMF Interface Program, http://www.tmforum.org/InterfaceProgram/
- TMF Interface Program catalog management team, http://www.
- The PSA initiative API, http://sourceforge.net/projects/psa-api/ Top
- The PSA initiative, http://www.psainitiative.org/ Top
- McElligott T, 'Being the catalyst', Telephony Online, October 31,
catalyst_ showcase_103106/index.html Top
- W'Product and service assembly: better by design', Vanilla Plus, vol.8,
no.4, December 2006, http://www.psainitiative.org/axiom
- 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
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.