A Complete Guide to OSS

A COMPLETE GUIDE TO OSS
A COMPLETE GUIDE TO OSS 1
A Complete Guide to OSS
Rahul Srivastava
2019

Preface
Target readers for this book are all the professionals who are working in Telecom OSS domain
or wish to move to OSS domain. Those who already have worked in OSS projects will find this
book easier to understand.
This book has been divided into two sections. Section I has four chapters and after reading these
chapters’ readers will thoroughly understand the Product design, Sales Order creation, Order
Fulfilment process and Enterprise design concepts. If one thinks froman enterprise perspective,
their business journey starts with conceptualizing a Product offering followed by creating the
product, selling thatproductandfinally delivering itto end customer. Icall it Create-Sell-Deliver
journey. In coming sections, we will see what it means in Telecom Enterprise environment.
Section II has two chapters and I have tried to explain the basic networking concepts in first
chapter and the wireline/wireless access technology, complex network architecture and some
basics of network virtualization and automation concepts in the next chapter. For an
accomplished OSS SME both the sections are important and my recommendation would be to
read through all these chapters and build an understanding.
Happy Learning,
Rahul Srivastava

Contents
Chapter 1............................................................................................................................. 6
Create Process .................................................................................................................. 6
Understanding Product Model ....................................................................................... 6
Modeling Product entities ........................................................................................... 15
Chapter 2........................................................................................................................... 26
Sell Process.................................................................................................................... 26
Chapter 3........................................................................................................................... 35
Deliver Process............................................................................................................... 35
Order Fulfilment journey ............................................................................................ 35
Products in OM Space ................................................................................................ 51
Chapter 4........................................................................................................................... 56
Enterprise Design............................................................................................................ 56
TeleManagement Forum Frameworx ............................................................................ 56
Chapter 5........................................................................................................................... 66
Network Basics............................................................................................................... 66
Networking Components and Devices........................................................................... 68
Key Network Protocols ............................................................................................... 77
Types of Network Connections..................................................................................... 80
LAN.............................................................................................................................. 82
Ethernet..................................................................................................................... 83
Switch ....................................................................................................................... 84
VLAN........................................................................................................................ 86
WAN ............................................................................................................................. 88
Link aggregation............................................................................................................ 90
Router........................................................................................................................... 90
Access, core and distribution ......................................................................................... 91
Routing different networks............................................................................................ 91
Internet connectivity and internal use.............................................................................. 91
MPLS............................................................................................................................ 92
Components of MPLS.................................................................................................. 92
How an MPLS networkworks....................................................................................... 92
Advantages of MPLS ................................................................................................... 93
Is MPLS Layer 2 or Layer 3?......................................................................................... 94
MPLS Pros and Cons ................................................................................................... 94
MPLS VPN ................................................................................................................ 95
Virtual private network (VPN) ........................................................................................ 96

VPN Protocols ............................................................................................................ 96
Remote-access VPN..................................................................................................... 97
Site-to-site VPN.......................................................................................................... 97
Network Topology.......................................................................................................... 98
Chapter 6..........................................................................................................................102
Telecom Networks .........................................................................................................102
Wireless Network.......................................................................................................103
Wireline Network........................................................................................................114
What’s Ahead? ..........................................................................................................139

SECTION- I
A Guide to Order Fulfilment
Create, Sell, Deliver

Chapter 1
Create Process
Introduction
For any Telecom enterprise which invests huge sum of money in setting up infrastructure, employing
human resources has the ultimate goal to earn revenue and make profit out of their investment. They do
so by offering/selling their product and services to end customer and charging them for it. Before these
products and services could be sold, they need to be Conceptualized, Created, given a name and given
certain features and characteristics which customer might be interested in buying and lastly presented
to outside world as a sellable entity. We are going to call it “Create Process”. In Telecom, it is covered
under Product Lifecycle Management (PLM) process and TMFORUM Information Framework (SID –
GB922) provides blueprint for product modeling.
Three pertinent questions which readers might be interested in knowing in “Create Process” is: What
do we create, where do we create and how do we create?
Theshort andsimple answer is:We createProduct Offerings,wecreateitin EnterpriseProduct Catalog
(Assuming Telecom world has moved to catalog driven ecosystem) and We create it by modeling the
products and services and configuring them in Product Catalog.
Of course the above answer is easier said than done and it requires detailed understanding of Product
modeling, Product entities, design principles etc. We are going to discuss all that in this chapter.
Understanding Product Model
A productOffering represents what is externally presented to the market for market’s use. It is a
sellable entity and attributes defining how every sellable entity can be defined by certain characteristics
called productSpecification. A product represents the subscription of a productOffering by a
customer. Association between Product and product spec allows product specs which were not
marketedas product offerings tobeinstantiated as product. Inother words, aproductOffering represents
how ProductSpecification is sold(packagingrules, prices, alterations, commitments) andaproductSpec
specifies what the marketing operator wants to sell at functional level (capacities, usages, QoS,
characteristics) and represents both tangible (Phone, modem etc.) and non-tangible goods (Anti-virus
software etc.). Product specifications represent unique capabilities with commercial value but only sold
through product offerings. A more technical definition is that product specifications are types of
products. ACFSS represents Service Provider’s know-how of non-tangible goods at functional level.
A RFS represents the technical solution that a service provider can implement for the given CFS.
productSpecification is ‘Made Available As’ ProductOffering.

Key Points
Product Offering-
 It is a sellable entity.
 Is identified as ‘What is ordered’
 Gives the marketing view
 Entity Relationship- productSpecification is ‘Made Available As’ ProductOffering
PS-
 Gives the functional view
 Entity Relationship- ProductSpec ‘realizedAs’ CFS
CFSS-
 Services are the functions that customers subscribe to. It is the functional view of a service
that is exposed to customers. It is an abstraction of RFSes
 Is identified as ‘What is configured’
 Gives the functional view
 Entity Relationship- CFS ‘Requires’ RFS
RFSS-
 A resource facing service (RFS) describes how customer facing services are configured.
 Is identified as ‘How it is configured’
 Gives the technical view
 Entity Relationship- RFS ‘Has’ Resource
SID view on Product Offering, CFS, RFS and Resource
A keyelement in SIDis wayit models telecoms products (Product Offerings) andespecially theconcept
of Customer Facing Services (CFS). As discussed earlier, a Product Offering is a sellable entity and it
is externally presented to the outside world. AProduct Offering (Specification) is made up of:
 Customer Facing Services
 Resource Specifications

 A Price Plan
CFS
A Customer Facing Service is defined in SID as: “A Customer Facing Service is an abstraction that
defines the characteristics and behavior of a particular Service as seen by the Customer. This means
that a Customer purchases and/or is directly aware of the type of Service and is in direct contrast to a
Resource Facing Service which support Customer Facing Services but are not seen or purchased
directly by the Customer.”
The key point to this definition is the word seen. The Customer (or more precisely the End User Party
Role) perceives the service “Outbound Voice Call”, for example, as nothing more than that. The End
User does not perceive the switching, encryption, error correction, radio frequency hops, base station
transfers, multiplexing and de-multiplexing that may go on in the background.
A Customer Facing Service Specification as an abstract base class, which specifies the properties
(attributes) common to a particular CustomerFacingService used to realize the associated Product(s).
This entity serves as a common basis to build any set of CustomerFacingServices that the service
provider needs.
CFS can be viewed as the properties of a particular related Service that represents a realization of a
Product within an organization’s infrastructure; This is in direct contrast to ResourceFacingServices,
which support the network/infrastructure facing part of the service. CustomerFacingServices are
directly related to Products as well as to ResourceFacingServices. From a pragmatic perspective a
Customer Facing Service represents a functionality at the boundary of the Service Provider
infrastructure in a protocol-agnostic way, it groups a set of Resource Facing Services that together
provide the necessary technical functionality.
ResourceFacingServicesareindirectly related toProducts throughtherelationship betweenProduct and
CustomerFacingServices. This enforces the relationship to Products while keeping Services that are not
directly realized by Products (i.e., ResourceFacingServices) separated from Products.
The Product Offering is thus defined in terms of the Services that an End User perceives, values, and
may be charged for.
An Example

Clearly defining a Product Offering, for example “3G Anytime” solely in terms of the services
perceived by the End User will not help when the Product Offering is sold (as a Product Offering
Subscription) to be provisioned in the network or on the Billing System, but that is precisely the
objective of the SID. By allowing an Offering to be defined independently of how it is implemented as
a step in the direction of Service Oriented Architectures Holy Grail – Loosely Coupled Architecture,
where each domain defines what it wants in the way of services, not how the services are to be
implemented or built.
Clearly a Customer FacingServicesuchas “Outbound Voice Call” has to be provisioned in the network
as a range of low level services managed by dedicated hardware such as the MSC. These services are
defined as Resource Facing Services.
So, we can define a Product Offering as a collection of Customer Facing Services, the Specifications of
the Resources required by the Product Offering (and the CFSs) such as the telephone number
(MSISDN), type of SIM, type of Handset etc and the Prices to be charged for the Product Offering and
theCFSs it offers (Note:An “Outbound Voice Call” or “Send Text Message”canbechargedat different
rates in different Product Offerings).
I hope you will agree that this sounds sensible, but what exactly is a CFS? Is a “Voice Call” a CFS, or
is “Making a Voice Call” a separate CFS from “Receiving a Voice Call”. When one tries to list CFSs
it becomes incredibly difficult to actually decide what is and is not a CFS and why.
We needed an objective way of defining what a CFS was and a set of rules to allow us to determine
whether a candidate service was a CFS, and if it wasn’t a CFS, then what actually it was.
Thetrickis tofocus backonthedefinition of CFS, and it comes backtotheword“seen”in the definition
of CFS, or perhaps more precisely “perceived”. If an End User cannot perceive the difference between
two related services, then probably the two services are components of the same CFS. If on the other
hand the End User can tell the difference then, probably (as there are other pragmatic criteria to be
applied) these two services are separate CFSs.
For example – can an End User tell the difference between making a voice call and receiving one? To
me this is a definite “Yes”. The phone rings when a call is made and when answered there is someone
on the other end of the line to talk to. On the other hand, when making a call the line has to be activated
(bypicking upthe receiver, or pushingabuttononthehandset), thenumber dialed andthen after hearing
the ring tone the phone maybe answered.
On the other hand, can an End User tell the difference between making a voice call to a fixed line
number as opposed to a mobile number? In my opinion, these are the same CFS, handled by different
RFSs (todo theswitching). Onecouldarguethat a knowledgeable End User canbyknowingsomething
about the numbering plan in the country, but the call is perceived (heard) in the same way during the
call. It is also possible that a call to a fixed line number terminates on a mobile phone and vice versa
throughcall forwarding, huntinggroups andthelike. Whenit comes topayingfor the call the difference
between fixed and mobile voice calls may also be perceived as they may be charged for differently, but
that is after the event (for Postpay customers at least). So it comes down to perception during the use
of the service, not prior or after the event knowledge that counts.
However, if oneextends this simple rule toa complexservice like “Voice Mail” things becomecomplex
and uncomfortable. Clearly an End User can perceive the difference between “Listen to a Voice Mail
Message” and “Delete a Voice Mail Message”, but then Voice Mail decomposes into about 10 or more
CFSs that are never ‘unbundled’ – one could never imagine selling a Product Offering that allowed
someone to “Delete a Voice Mail Message” but not to “Listen to a Voice Mail Message”. An additional
rule needs to be defined to allow these type of services that are perceived differently to be bundled
together into a pragmatic CFS.
RFS

A Resource Facing Service is an abstraction that defines the characteristics and behavior of a service
that is used internally as part of the composition of a Customer Facing Service. Resource Facing
Services are services internal to the service provider and may be composed of other Resource Facing
Services and Resources.
A Resource Facing Service is indirectly part of a Product, but is invisible to the Customer – it exists to
support one or more Customer Facing Services.
The TeleManagement Forum Information Framework (SID) defines Resource Facing Service as an
abstract base class for ResourceFacingServices. AResourceFacingService is an abstraction that defines
the characteristics and behavior of a particular Service that is not directly seen or purchased by the
Customer. ResourceFacingServices are “internal” Services that are required to support
a CustomerFacingService. The Customer obtains CustomerFacingServices via Products, and is not
aware of the ResourceFacingServices which support the CustomerFacingService(s) that is being
obtained directly by the Customer via a Product. CustomerFacingServices are directly related to
Products as well as to ResourceFacingServices. ResourceFacingServices are indirectly related to
Products through the relationship between Product and Resource. This enforces the relationship to
Products while keeping Services that are not directly obtainable via Products (i.e.,
ResourceFacingServices) separated from Products.
Users of the Information Framework’s (SID) Customer and ResourceFacingService (CFS/RFS)
typically consider that one or more ResourceFacingService(s) associated with a
CustomerFacingService specify how the later will be configured within an enterprise’s resource
infrastructure. They also tend to assume that the association between
ResourceFacingServiceSpecifications and one or more ResourceSpecification(s) themselves define the
types of Resources that will be used, in some way, to support a CustomerFacingService.
An Example
Here is an example from the definition of a ResourceFacingService: “A[virtual private network] VPN
is an example of a customer-facing service. This particular type of VPN may require border gateway
protocol (BGP) to support it. Customers don’t purchase the BGP, and hopefully aren’t even aware that
BGP is running. Therefore, BGP is an example of a resource-facing service.”
Now the enigma begins to surface: BGP is a Logical Resource, Protocol Service, v Routing Protocols
business entity. At this juncture, users of the Information Framework wonder why BGP in needed in
boththe Serviceand Resourcedomains. Onesolution is torefer tothe ResourceFacingServiceas aBGP
service, but is this enough?
The enigma grows when Information Framework users try to use the simple association from a
ResourceFacingServiceSpecification to one or more ResourceSpecification(s) to define all aspects of
how a ResourceFacingService, in this case the BGP, is configured. For instance, as the BGP is part of
the configuration of the VPN, what is the sequence of configuring it within the overall VPN? Which
properties of BGP can be selected and which are fixed? What other resources must be configured as
part of configuring the BGP?
There have been discussions going on to get rid of ResourceFacingServices at some time in the future.

Notice that the CustomerFacingService and ResourceFacingService have been removed.
ResourceFacingService is represented by ServiceConfiguration. And because CustomerFacingService
is the only subclass of the service, it has been collapsed into Service. Bearing in mind that many
Information Framework users employ CustomerFacingService and ResourceFacingService, here is an
alternative to this rather radical approach.
Notice that it retains the current view shown earlier and enables users to take advantage of the new
Configuration ABEs.
Resource
For physical resources it is pretty obvious because you can see them, hold them in your hand, or put
them in your pocket. The really big resources are usually the Telecom’s Service Provider’s own
equipment, be it a base station, the DP, or the switch, but of course PhysicalResources include things
like the phone, the modem, the mobile, the SIM card, the memory card and the copper pair in the DP
that belong to a Customer’s Product (subscription). Additionally, a physical resource will always be
located somewhere, at an address, a geographic location, or perhaps in a local location (e.g. a room in
a building).

A logical resource is therefore something that cannot be touched. Generally, LogicalResources are
numbers, like the phone number, MSISDN, IMSI, IMEI, PIN, PUKetc. Programs, images, and music
files are all LogicalResources too. This realisation is useful in many ways; not least in understanding
how aLogicalResourcecanhave a location. For example, Firefox. TheResouceSpecifcation for Firefox
belongs toMozilla. I have an instanceinstalled on myp.c. ( a PhysicalResource), soaLogicalResource
can be installed in a PhysicalResource. But consider an MSISDN, it is installed in the HLR (a logical
resource itself) which in turn is installed in the Switch. So a LogicalResource must either be installed
in (locatedin) another LogicalResourceor a PhysicalResourceandthePhysicalResourcehas alocation.
Another thing about Resources is that theyhave lifecycles outside a Product (subscription). Lets assume
a home internet product (specification) that could deliver a free modem, or a modem that is rented to
the Customer or be used by a Customer who already owned a modem (as different ProductOfferings)
Thecomplexvalidation rules about what happenedif a Customer subscribes totheProductOffering that
delivers the free modem and then cancels the subscription only to come back later to take out the
ProductOffering that could use the Customer’s own modem.
Consider it from the modem’s point of view. It was born (manufactured) in a factory in Taiwan and
shipped through a number of warehouses and Suppliers until it ended up in a box on a shelf in a
Supplier’s shop together with a CD-ROM that had its driver software, a cable to connect the modem to
the telephone point, another cable to connect the modem to a p.c., an instruction manual and a piece of
paper with an activation code on it. All of these are Resources, and each will have had its own life to
get to this point. The box all these Resources are in represents (as near as damn it) the ProductOffering.
The ProductOffering also includes a number of Services which are (usually) the reason the Customer
purchases the ProductOffering. These services are not to be found in the box, directly, but ultimately
are delivered by software, either running on the Customer’s computer, in the modem, or in the Service
Provider’s network.
One day someone (a Customer) buys the box and takes it home (the new location for the modem). He
follows the instructions and plugs in the modem correctly to the wall socket and his p.c., loads the
software and activates the service throughentering the activation code and establishing a username and
password (again logical resources) with the Service Provider to set up the Product (subscription). Each
of these Resources have a ResourceRoleProductInvolvement (a type of ProductInvolvementRole)
that link and show the role of the Resource in the Product.
The Customer uses the modem and the Services provided by his Product (subscription) for a year or so
and thencancels theProduct (subscription) for somereason. Hecannolonger usetheServices provided
to him by the Product (internet access, email etc) and he gives up the username and password 2.
However, the modem and cables, CD-ROM and even the software on his p.c. are still all at his house,
but not associated with an active Product. One thought may be that the Modem should be associated
with a bundled Product so that when the Internet Product was cancelled the relationship between the
Customer, the Resource and the Service Provider could be maintained, just in case the Customer ever
came back. You could do that, but if you do that then you should also do that for things like Phone
Numbers, MSISDNs and anything else the Customer can purchase from the Service Provider and carry
away.
One can think that Resource still exists; it hasn’t disappeared just because the Product has been
cancelled. Just like the Person playing the role of Customer still exists even after the Product
(subscription) is cancelled and the Party is no longer playing that role. It is no co-incidence that Parties
play PartyRoles that in turn play PartyRoleProductInvolvement (roles) and Resources play
ResourceRoleProductInvolvement.
And now to the difference between a Service and a Resource. In Telecom at least, a Service is provided
by a Resource, and the Services are nowadays delivered by software, or LogicalResources. Service

delivered by the telco that may involve Human Resources, like an installation service, but this is not
directly modelled in SID but is considered something covered by the likes of a WorkOrder or
ServiceOrder.
Resource Classification dimension
 Location
 Device
 Hardware
 Firmware and Software
 Device Interface
 Protocol
 Transmission Descriptor
 Address Entity
 Transmission Entity
 vendor
 role
 technology
 layer
Types of Association between PSR
 Inheritance
 Association
 Containment
Product/Service/Resource Domain Relationships
Decomposition example

Diagram- Decomposition example for a wireless Product Offering
Diagram- Decomposition example for a wireline Product Offering

Modeling Product entities
Having understoodthebasic conceptsof Product,CFS, RFS andResource,wewill movetoPLM design
process. Let us now understand the modeling principles of Product entities also called as Aggregate
Business Entities (ABEs). We will try to understand the entity relation, characteristics and cardinality
in detail. This product realization journey begins withcommercialconceptualization of a Sellable entity
called product by the business team. Then the requirement comes to PLM product modeling experts
who do the functional and technical modeling of that product. While doing so they are supposed to
follow some modeling guidelines and this is what we are going to discuss.
Following are the PLM ABEs -
1. Product/ProductOffering
2. Product/ProductSpecification
3. Product/Product
4. Product/ProductOffering/Product Offering Price
5. Product/ProductOffering/Product Offering Price Rule
6. Product/ProductOffering/Pricing Logic Algorithm
7. Product/Product/Product Price
8. Product/Product Usage
Note: I strongly recommend that all readers after reading this book should also read “GB922- SID
Model” for more detailed understanding on SID modeling. Same can be downloaded from internet.
Entity Group Entity Type
Product offer Bundle
Package
Promotion
Component Component
Component group
Pricing Charge
Chargegroup
Discount
Discount group
Cost
Cost BasedCharge
ChargeBased Discounts
Let us discuss each of these ABEs in detail.
A. Product/ProductSpecification
Products are tangible or non-tangible items which enterprises sell or lease to a customer. AProduct
Spec may be simple (atomic) or composite (Fowler Specification).

Key Points to remember
 CFS can’t be seen by the customer. Only product/Product Spec is visible to them.
 A ProductSpecification can’t contain itself but it can reference other
 Atleast one action is allowed for a ProductSpecification (Ex- Create, Update, Delete)
 ProductSpecificationRelationship may be exclusivity, migration, dependency, substitution
etc.
Product Specification entities and relationship
 ProductSpecificationType- Grouping a product specification based on common characteristic
or how specs are marketed. It can be of two types- ProductLine and ProductCategory.
 ProductSpecification- It can be of 2 types- AtomicProductSpecificaton which can’t be broken
further and CompositeProductSpecificaton which consists of multiple atomic PS.
 ProductSpecificationRelationship- Required for bundling or composite specification.
Relationship can be Dependency, Exclusivity, substitution etc.
 AllowedProductAction- AllowedProductAction described by ProductActionType Create,
Update, Delete etc.
 ProductSpecificationCost
Diagram- ProductSpecification Relationship
Product Specification Example

Product Characteristics
ProductSpecificationCharacteristic and ProductSpecificationCharacteristicValue represent the
properties of ProductSpecification. It can be grouped into 3 types- Discrete, parameter range, derived.
Characteristics where customer has the option to choose/interchange is modeled as
ConfiguratbleProductSpecificationCharacteristic. Characteristics can be bundled together into
packages by using ProductSpecCharRelationship (Mutually exclusive, inclusive etc). For example,
a number of electrical characteristic can be grouped together using “Electrical properties” characteristic
that represents a composite of the detailed properties such as, power requirement, plug requirement etc.
Product Specification characteristic entities and relationship
 ProdSpecCharUse
 ProdSpecCharValueUse- E.g.-ProductOffering “Silver plan” only allows BW 2 MBPS and 5
MBPS out of values 1,2,5 and 8 MBPS. This can be achieved using ProdSpecCharValueUse.
 ConfigurableProductSpecCharacteristic

Diagram- ProductSpecCharacteristic Relationship
Diagram- ProductSpecCharValueUse Relationship
Diagram- ProductSpecification modelingexample
B. Product/ProductOffering
 Product Offering set out in ProductCatalog are ProductSpecifications with additional detail that
enable a contract to be struck for their sale. E.g.- SLA, Shipping Details etc
 ProductOfferingTerm- It defines the condition under which the ProductOffering is made available
to the customers. E.g.- Shipment Term, Service Term, Payment Methods, Bulk Buying, loyalty,
commitment periods.
 ProductOffering which are part of BundledProductOffering should not be individually procurable.
If need be, a separate SimpleProductOffering can be created.
 A BundledProductOffering does not necessarily need to have an association with
ProductSpecification
 ProductOfferingTerm- It is the condition under which a ProductOffering is made available to the
customer.

Product Offering entities and relationship
Following are the Product offering entities and their relationships are as shown in the diagram-
 ProductOfferingType – Ex- Simple or Bundled
 ProductOfferingPrice
 MarketSegment
 Place
 MarketStrategy
 SalesChannel
Diagram- ProductOffering entities
C. Product/Product
 SimpleProductOffering instantiated as ProductComponent and BundledProductOffering
instantiated as Product Bundle
 The information which BundledProductOffering/ SimpleProductOffering was used for purchase
is kept in ProductBundle/ProductComponent entity respectively. E.g.- Special Price,
Commitments, discounts and other business information etc.
 Features of a product to which customer subscribes are represented by
ProductCharacteristicValues. E.g.- colour, size, storage etc.
Product entities and relationship

Diagram- Product entities
D. Product/ProductOffering/Product Offering Price
 ProductOfferingPrice Depends on ProductSpecCharValueUse
 Pricing component is always applied at ProductSpec level
 Between ProductOffering andProductOfferingPrice,thereexists PolicySet whichgoverns theprice
of a ProductOffering. We use the ‘ProductOfferingPriceGoverenedBy’ relationship.
Types of product offering price
• Recurring charge
• Non- recurring charge
• Event rate
• Standalone recurring rate
• Standalone non‐recurring rate
• Non‐recurring, cost‐based rate
• Recurring, cost‐based rate
Rate Types
• Simple:Rates that inherit from this type detail a specific amount in a decimal field called Rate.
This represents the amount to be charged.
• Threshold: Rates that inherit from this type detail a type of unit‐based pricing whereby the
amount charged varies according to a quantity. The Rate element details how the rate varies as
the quantity changes.
• Tiered: Rates that inherit from this type detail a type of unit‐based pricing whereby the amount
charged varies according to a quantity. The Rate element details how the rate varies as the
quantity changes.
Discount Types

• Product event discount rate
• Product non‐event discount rate
• Standalone event discount rate
• Standalone non‐event discount rate
• Promotional discount
• Corporate discount
Product Offering Price entities and relationship
• ProdSpecCharValueUse
• PriceEvent
• GeographicalArea
Diagram- ProductOffering price

Diagram- ProductOffering price
E. Product/ProductOffering/Product Offering Price Rule
We need PriceRule model to define price policy for simple product or cross-product. The price of
product offering is governed by policy set. Price of a product offering depends on the following generic
structure. These components trigger evaluation of PolicyRule.
1. Policy event- Time of purchase
2. Policy condition- Type of purchase
3. Policy Action- Action to be taken if condition is found True.
Policy Rule
 Policy rule aggregates atleast one or more PolicyConditions and one or more PolicyActions.
So PolicyConditions and PolicyActions can both use composite pattern.
 How PolicyRule is executed- Rule priority, combine policy conditions
 PolicyGroup construct can aggregate multiple PolicyRule

Diagram- ProductOffering PolicyRule
Diagram- ProductOffering priceRule
Diagram- ProductOffering PolicyCondition and PolicyStatement

 PolicyValue- Quantity
 PolicyVariable- Entity Placeholder
 PolicyOperator- Equals, GreaterThan etc.
Diagram- ProductOffering PolicyAction and PolicyStatement
PolicyGroup
 The PolicyGroup subclass of PolicySet brings together multiple PolicyRules and applies them
as atomic set of rule.
 To support the action associated with the complex PolicyRules PolicySet Model is extended
further. Figure below-

Diagram- ProductOffering PolicyGroup Example
F. Product/ProductOffering/Pricing Logic Algorithm
G. Product/Product/Product Price
H. Product/Product Usage

Chapter 2
Sell Process
Introduction
We discussed in the previous chapter about “Create Process”. Now that Telecom enterprise has a
sellable entity called “ProductOffering” on offer for end customers, they would want to sell it.
How a best fit product is offered, how it is selected, how the selected product offering is captured and
what role does contextual awareness plays in selling process, dynamic pricing etc. will be discussed in
this chapter and we are going to call it “Sell Process”.
Again, the three pertinent questions which readers might be interested in knowing in “Sell Process” is:
What do we Sell, where do we Sell and how do we Sell?
The short and simple answer is: We Sell Product Offerings, we sell it on a sales platform (Traditionally
a CRM) and how we sell it is something we will discuss as we progress through this chapter.
Understanding Lead to Cash Flow
Lead to Cash flow typically starts with a marketing plan and ends with revenue. Following is the Lead
to cash flow:
 Organizations launch marketing campaigns in different format to get hold of the leads that can
result in revenues
 Leads can turn into business opportunities.
 Opportunities which successfully result in revenues for the organization become ‘Customer’ or
‘Accounts’ for the organization.
How it works?
• Identify the opportunity.
• Offer the right products.
• Specify the features and pricing that are feasible for the organization.
• Place the order.
• Close the deal.
Understanding CustomerRelationshipManagement (CRM)

CRM is short for Customer Relationship Management. It’s a software solution that brings a host of
capabilities together. You can store all your prospects and customers, make calls, send emails, create
reports, schedule appointments, add notes, manage your pipeline etc.
A customer who is for example buying any product or service is touched upon by:
 Marketing- Marketing teams canuseCRM tomeasuretheReturn onInvestment(ROI) ontheir
activities and campaigns. It also gives them insight about whether they are targeting their Ideal
Customer Profiles (ICPs), and the right geography and industry.
 Sales- Sales teams canuseCRMto geta deeper understandingof their prospectsandcustomers,
and manage their sales pipeline better. The CRM also helps automate day-to-day tasks, track
and improve sales productivity, identify industry trends, and enhance sales strategy.
 Services- Customer support teams can use CRM to help improve customer relations and
retention. It gives them insight into the customer’s issues and their past interactions, and
provides the necessary tools to manage activities around customer engagement.
A CRM Software therefore touches these three areas of business and it aims to sustain the revenue
stream and retain the customer.
Customer Order Capture Flow
1. Check/create customer account in CRM. Customer Account willhave the customer details also
called as customer profile or customer context.
2. Based on the customer context fetch the eligible product offerings fromEPC.
3. Selected Product Offering validation.
4. Fill in the product specification details
5. Get the quote with price details
6. Check the availability of physicalresource
7. Resource reservation in logical inventory
8. Technicalservice qualification to ensure the serviceability of the product and services
9. Schedule Appointment (WFM) with the field engineer.
10. Submit Order

CRM Lifecycle
Customer Acquisition Customer Extension
Customer Retention
Selling Process (Configure,Price, Quote)
CPQ solutions pick up where CRM leaves off, making allof the complex product, pricing, and business
rules centralized, automatic and available in real-time. Sales has everything it needs at its fingertips
when trying to configure and quote a deal. The CPQ process starts with identifying and presenting
products to customers, proceeding to proposaland quotation creation, followed by the generation and
submission of quotes for valid orders.

High Level O2F Flow
What is CPQ
Configure, Price, and Quote (CPQ) is a process in the sales life cycle. Every business that sells complex
products has a CPQprocess in one way or another. When a customer is interested in a product, the sales
rep must configure the product to meet the customer’s request. When the product has been finalized,
the sales rep has to price the product and get approvalfor that price. Finally, the sales rep must prepare
a quote or proposal document to present or send to the customer. If a business sells simple products
with set prices, the CPQ process is already done. But enterprise businesses often have thousands of
complex products, ever-changing pricing calculations, large proposal document templates and sales
reps that don’t have the time to worry aboutit all. If a product or pricing expert forgets to respond to an
email, getting a quote to an interested customer can take weeks. Even when the proposalis complete,
what ensures that the configured product is valid and that the pricing calculations are exact? Today’s
enterprise business can’t rely on tribalknowledge and manual data entry to drive the CPQ process; the
digital age requires a fast, automated CPQ process that produces 100% accurate quotes, every time.
CPQ in today’s ecosystem can guide you through the following, catalog-driven, selling process:
• Browse and select best‐fit offers from your portfolio.
• Create accurate offer configurations and pricing in real‐time.
• Produce quotes across your sales channels that are valid and deliverable based on customer
preferences, your business models and your technicalcapabilities and constraints.
• Generate accurate digital orders for submission directly to your automated order-management
platform.
CPQ Process
New customer quotes and orders:

• Purchase of products and services
Existing customer:
• Upgrade or downgrade the product and services
• Purchase of additionalproduct and services
• Product and service changes
• Product and service disconnections
The key stages of the CPQ process are following:
 Customer and product portfolio identification to surf, browse, identify and enforce the eligibility
of product offers based on the customer context. Offers can be sourced directly from product
catalog, ensuring that CPQ acts on the latest product specification.
 Product offer selection identifying and including desirable products for eligible customers in the
quotation process.
 Full product offer configuration, pricing and validation of consumer and enterprise offers using
the extensive configuration capability of CPQ. This ensures that by modeling a product
specification in product catalog, associated products are configurable through the CPQ solution.
Users can select and specify the configurable values of products.
 Quote/proposalcreation.
 Quote validation and finalization through a configurable client framework, enabling flexible,
catalog‐driven quote and order processes.
 Customer acceptance using the customer profile and context awareness to ensure the validity of
the quotation.
 Bill of materials (BOM) creation from the decomposed PSR, required by the configured
quotation.
 Order validation and generation to create fully validated digital orders, ready for submission to
order‐management solutions.
 Order submission to an order‐management system for processing.

CPQ Solution Design considerations
 Catalog‐Driven CPQ
 Quote Configuration
The quote‐capture framework of CPQ should allow users to configure valid products while enforcing
following Validations:
• Mandatory field enforcement, ensuring the valid collection of key data
• Complex data‐format verification, enabling the custom verification of both free‐form and
option‐based data using REGEX and complex rules to ensure the entry and selection of valid
data.
• Choice‐ and cardinality‐based selection control, ensuring the selection of bestowed and
optional product elements based on structural product specification rules.
• Proactive compatibility rendering, actively responding to user selections to identify
incompatible items and choices to minimize the configuration effort for the user.
• External data consumption (reservation/availability) ability toconsumereal‐timecallouts to
external systems directly within the configuration process. This is key to providing accurate
data entry and capture for products that rely on unique customer items and where a reservation
request may be required.
• Reactive portfolio rules enforcement for portfolio‐based validation, ensuring the selections
made across products are compatible both with one other and any pre‐existing products in the
customer portfolio.
 Dynamic Pricing
CPQ prices the configuration of customer products in real‐time, using all the information gathered in
the quoteand order capturealongwith contextualinformation toderive a customer‐ specific pricewhile
the baseline pricing may be defined in the product catalog
 Quote Validation
Throughout the quoting process, CPQ validates the quotation based on the product configuration,
ensuring that the outcome of the quotation along with the customer product portfolio meets the rules
specified in the product catalog. CPQ operates on several levels of rule specification and validation,
driven by the rule entities specified in Catalog. CPQ identifies relevant options and filters out
incompatibilities based on user selections and displays the product data based on the results.
• The Product Classification and Selection functions include:
• Presenting product data in the UI layer.
• Guiding customers to the types of products available.
• Allowing customers to browse and choose products.
• The Product Configuration service provides a set of server resources that expose and enable the
resolution of the ambiguity in a product specification based on customer responses and selections.
The product configuration capability interrogates the product specification and returns optimized
representations that can manipulate and navigate the configuration of a product to derive a product
candidate from the catalog. Once a product specification is selected, the product configuration
capability supports the selection of available customer choices. The selection of choices helps to
define the product candidate from a product specification. This service also provides import
capabilities

• The Cross‐Sell, Up‐Sell and Promotion services provide web service resources that query the
definitions of complex relationships between product specifications based on relationship‐type
meta‐information, such as cross‐sell and up‐sell details.
• Cross‐sell shows other products relevant to the products or options the customer has already
chosen.
• Up‐sell shows additional products in which the customer may be interested that are available at
a higher price, recommending that they swap their choice for another product. These
capabilities enable a CPQfront endtoanalyze andretrieve relevant products for agivenproduct
and relationship type, for example, to evaluate the up‐sell rules and return appropriate products
from the product catalog, also providing input to calculate the product price.
CPQ Rules
A CPQ product should have Rule-based truth-maintenance capability in order to select right product, do
product validation, apply correct pricing and discounts etc.
Following are the types of enforcement rules:
• Cardinality
• Compatibility
• Dependency
• Eligibility
• Availability
• Serviceability
• Pricing
CPQ Integration
Contextual awareness is a key factor in CPQ that enables the formulation of a vital picture of contextually
relevant information impacting a quote and order at any given time. For Example, CPQ may interact with
CMS, CIB DB for customer and installbase information. Through context‐aware integration points, CPQ
can provide the ability to call out in real‐time to operation data services to build a picture of the customer,
including theproducts andservices theymayalreadyhaveandtheability of the networktoprovideservices
to the customer. With this information CPQ can accurately validate and enforce business rules during the
quoteand order captureprocess.Thefollowingfigureshows someof thevariables in contextualawareness.
The context affects the products and services that the customer can purchase. Contextual data impacts
eligibility, helps resolve customer‐specific pricing and controls the resources that a customer can select.
CPQ can query externalsources for key, contextually relevant information, such as:
• Customer account and productdetails.
• Network availability and serviceability details.
• Inventory and reservations availability.

Quote-To-Cash
Quote-to-Cash is the vital business process that connects a customer’s interest in a purchase to the
realization of revenue. It includes creating a quote, responding to RFXs, submitting a proposal,
negotiating and managing a contract, fulfilling orders, recognizing revenue, ensuring compliance and
tracking payments – all within visible and controlled workflow. Quote-to-Cash solutions include
Configure-Price-Quote (CPQ), Contract Lifecycle Management (CLM), and Revenue Management
applications.
Quote-to-Cash automates three core applications: Configure Price Quote, Contract Management,
and Revenue Management. Each application flows naturally into the next, creating a seamless QTC
process.
Configure Price Quote (CPQ) empowers salespeople by providing up-to date product and pricing
information. The CPQ application ensures sales people provide prospects with valid and complete
proposals, no matter the complexity of bundling rules or size of product catalog. The application also
enforces the company’s pricing rules to prevent inappropriate discounting. With CPQ, salespeople get
accurate proposals out more quickly and accurately, enabling them to close more deals.
Contract Management enables sales and legal teams to generate, negotiate, store, and comply with
all sales contracts, along with related legal documents such as NDAs. The Contract Management
application ensures that dealterms can be created quickly, following all company policies, and that the
company has totalvisibility to every step of the negotiation process. Once dealdocuments are signed,
Contract Management tools ensure that all the company’s new obligations are tracked correctly.
Revenue Management ensures correct, timely control of all revenue related processes, including
order management, billing, and revenue recognition. With the Revenue Management application, these
criticalback-office functions work in sync with each other and in accordance with the terms of the deal.
Revenue Management reduces the risk of errors in the ongoing customer relationship and makes sure
that the business captures the revenue opportunities, suchas renewals, that otherwise may slip through
the cracks. Revenue Management handles the diversity of business models a growing enterprise may
offer clients:physical goods, professionalservices, subscriptions, usage-base fees, and one-time fees.

Chapter 3
Deliver Process
Introduction
We discussed in detail about “Create Process” and “SellProcess” in previous chapter. Let us move on
now and understand what happens after the ProductOffering is purchased by the customer and sales
order is submitted through CPQ application.
A general understanding would be that customer should start using the services which he paid for. In
other words, allthe services which he requested for should be fulfilled. Realization of requested service
is covered under “Deliver Process”.
In this chapter we will try to understand the different steps in order fulfilment journey including
provisioning, O2F integration touchpoints etc. in detail.
Order Fulfilment journey
Order fulfilment journey post the sales order is captured and submitted to Order management system
can be broken into 3 layers, COM, SOM and TOM. Each layer is designated with a defined role to play
and I amgoing to explain themin detail. Almost all the Servicefulfilment products whichI haveworked
on follow this product architecture and fulfillment designers while designing the fulfillment journey
should follow this design principle and divide the Processing flow into 3 layers. It can be noted here
that COTS products available in the market have the capability to work in all three roles (COM, SOM
& TOM) as well as individual role.
Let us discuss the details of COM, SOM and TOM layer and try to fit-in the fulfillment journey tasks
in these three layer-
COM
Fulfillment COTS in COM role typically accepts the customer Order, validates it, decomposes PO/PS
into CFS and interacts with a billing system to perform such tasks as synchronizing customer accounts
between the order source system and the billing system, and initiating billing activities in billing
systems. OM in COM role also typically identifies the services that are associated with the products,
bundles, and offers, and sends that data to OM in the SOM role in a service order.
SOM
OM in the SOM role works with service and resource management systems to design services, assign
the resources required to fulfill the services and define how those resources need to be configured to
fulfill the services. This process is called design and assign.
To design and assign services, OM in the SOM role uses the data received in the service order. It sends
that data to a Service Resource Inventory (SRI)/ Physical Network Inventory system to design the
service and assign resources. As part of the service fulfillment you model predefined service
configurations in your SRI/PNI system.
OM in the SOM role processes the service order. In this case, OM uses orchestration again, and OM
decomposes order items into:

 An order component that interacts with a service and resource inventory system to design the
service and assign resources. For example, the service might need a localloop, telephone
number, and so on.
 An order component that sends a technicalorder to OM in the TOM role to manage service
activation and shipping.
In the SOM role, orchestration is used to ensure that the service design occurs first. The inventory
system needs to send data about the network resources and the actions required on those resources
back to OM, so OM can include that data when processing activation, shipping, and interactions with
a partner gateway.
TOM
After receiving the required data from the inventory system, the fulfillment SOM instance sends a
technical order to OM in the TOM role. In the TOM role, OM processes the technical order and
orchestrates the activation, shipping, and installation tasks. The systems typically involved in these
activities are WFM, SCM, and network activation systems. Partner gateway (PGW) systems for third
party service providers or trading partners can also be involved at the TOM level.
After completing the tasks in the technical order, OM in the TOM role communicates the order status
to OM in the SOM role, which in turn communicates its order status to OM in the COM role. OM in
the COM role can then complete the original customer order.
By using COM, SOM, and TOM, OM is able to take as input the products, bundles, and offers that the
customer purchases, and resolve those into customer-facing services and ultimately the resource-facing
services that need to be implemented on the network.
OM in the TOM role processes the technical order and decomposes order items into:
 An order component that sends activation requests to the network.
 An order component that sends requests to a shipping system.
An example
A sales order has been created to fulfil a product offering “BroadbandServiceOffer”. OM receives this
Order, does some order level validation and transforms it into customer order. Next, customer order
(PO/PS) is decomposed into service order (CFS) and an orchestration plan is selected. Based on the
orchestration plan, execution of fulfilment process starts and Service order is sent to SOM layer. Figure
below shows, layer wise Order decomposition

Let’s come down to SOM layer now. In SOM Layer Service order (CFS) is further decomposed into
Resource Facing services (RFS) and resource Design and Assign service corresponding to each RFS
is executed. Once the Design and Assign is complete, Order moves to TOM layer.
In TOM layer RFSes are decomposed into Technical services which are nothing but network
activation tasks.
Let’s see how fulfilment process manages the fulfillment of a request for an ADSL service in
SOM/TOM layer:
1. We start with the first task, Verify ADSL Service, which verifies that the ADSL service exists.
For example, the task might run a web service operation that reads a PNI database to determine
if the service is available at the specified address.
2. After verifying that the service is available, the process branches to two tasks that are
independent and can run in parallel:
a. The Ship Modem Self-Install Pkg task sends a shipping order to the hardware provider.
b. The Assign Port task looks up a port in the inventory system and assigns it.
If the port is available, the next taskis Activate DSLAM. However, if the port is not available,
the process transitions to the Add Capacity task, and then back to the Assign Port task.
3. After the Assign Port task is finished, the Activate DSLAM task can run. This task contains an
OM integration with a third-party activation system to activate the DSLAM.

The Assign Port task is dependent on the completion of both the Ship Modem Self-Install Pkg
task and the Activate DSLAM task. Therefore, even if the Ship Modem Self-Install Pkg task
completes, the Activate DSLAM task cannot start until the Assign Port task is finished.
4. When the activation is complete, the next two tasks send the customer survey and require that
an OM user verifies the order to make sure it is complete. After these two tasks are completed,
the order is complete.
Any of the tasks in this process can be configured as automated tasks. For example, the Assign Port
task can be an automated task if there is an integration with the inventory system, and the inventory
system is able to respond to an automation plug-in sender requesting a port number with a response that
assigns the port number for the service.
Order Template
We have progressed wellso far. Now let us understand the Order template i.e. what allinformation
are required to be there in a Customer order.
The metadata that you model in the order template defines the data that the order can include at
runtime. For example, a runtime order can include the following data:
 Information about the order. For example:

 The type of order, such as a requestfor a new service or a change to an existing
service.
 Order creation date.
 Expected completion date.
 Sales Order Id
 Product Offering Id
 Information about the customer; for example, name and address.
 Order Line Items and information about the services being requested; for example, upload
speed, download speed, and quality of service.
The data in customer orders, service orders, and technical orders is typically different for each type
of order:
 Customer orders include information about the customer, such as their location, the product
offerings that the customer purchased, and the product requirements, such as download speed.
 Service orders include information about the customer-facing services that need to be
provisioned, including the technicalrequirements suchas bandwidth andquality of service, and
the customer's location.
 Technicalorders includeinformation about theresources andresource-facingservices that need
tobe activated, andthe equipment that needs tothe shippedor installed. Resources andresource
facing services are identified by the physical inventory system from customer-facing services
that OM SOM sends to the physical inventory.
Order Operations
Order Orchestration concepts
We have progressed well so far. Having understood the COM, SOM and TOM process, lets us
understand the Customer Order capture process in CRM/CPQ as wellas order orchestration process in
OM in detail. Here I am going to explain you the new order acquisition flow

Diagram- NewAcquisition Order
Generic OM Flow
1. Customer Order Capture
1. Check/create customer account in CRM. Customer Account willhave the customer details
also called as customer profile or customer context.
2. Based on the customer context fetch the eligible product offerings fromEPC.
3. Selected Product Offering validation.
4. Fill in the product specification details
5. Get the quote with price details
6. Check the availability of physicalresource
7. Resource reservation in logical inventory

8. Technicalservice qualification to ensure the serviceability of the product and services
9. Schedule Appointment (WFM) with the field engineer.
10. Submit Order
Order Orchestration Flow
2. Assess, Decompose, format, Enrich the Order
The very step once the Sales order is captured and submitted to OM is to assess, validate, format and/or
enrich the order in COM layer. Different order management products have their own way of assessing
and validating the order. I am trying to explain here the productagnostic approach. Also, OM designers
should prefer to keep synchronous communication between Sales platform and OM till assessment
process is completed and Order moves ahead for further execution.
• Commercial validation: Validates the products and services contained on the order for
compatibility. Attribute, Template etc.
• Decomposition:Enriches the order withtheadditional products, services,resources anddataneeded
to fulfill the order using catalog decomposition, inference and mapping rules. customer order
(PO/PS) is decomposed into service order (CFS)
• Formatting and enrichment:Do Metadata level enrichment
• Impact analysis: Determines the products, services and resources currently associated with a
customer portfoliobyaccessingtheserviceprovider's repositoryanduses this informationtoderive
appropriate fulfillment actions.

• Fulfillment process selection:Derives the fulfillment process specification for each order, which is
further dynamically optimized during fulfillment.
3. Select the Orchestration plan
Now that customer order has been decomposed into service Order, next big task is to identify the
fulfilment process which should be invoked. Fulfilment process are modeled during design time and
there may be multiple fulfilment processes for different order types and operation. A fulfilment
process is a sequence of tasks and subprocesses that run consecutively or concurrently to fulfill all or
part of an order. It enables you to break down the work required to execute and fulfill an order into
functionaltasks, which can be distributed to various systems and order managers to be completed in a
controlled manner.
In processes, you can control how the tasks are run. For example, you could create a rule that evaluates
data and branches the process appropriately. Any number of processes can be defined in an order
process, consisting of any number or combination of manual and automated tasks. You can also run
subprocesses from a process. Subprocesses are processes that are launched from another process, as
opposed to being launched from an order.
An orchestration plan is based on two main factors: decomposition, which organizes sequence of
execution of the order items, and dependencies, which dictate when the executable order items are
allowed to run. Some services might require that some fulfillment tasks are completed before others.
For example, you need to complete provisioning order items before you can process activation order
items.
Dependencies are relationships in which a condition related to one order item must be satisfied before
another item can be processed successfully. For example, a piece of equipment must be shipped to a
location before the action to install it at that location can be taken. Dependencies can be between order
items in the same order (intra-order dependencies) or between order items in different orders (inter-
order dependencies). Inter-order dependencies are particularly common in situations that involve
amendments or follow-on orders. For example, the order items in a follow-on order for VoIP
provisioning might depend on the execution of the order items in the original order for DSL
provisioning.
A fulfilment process may be selected on the basis of order attributes which come in the order candidate.
1. Basis Order candidate and business rules, select the fulfilment flow
2. Trigger the selected fulfilment flow
4. Execute the Orchestration plan, listen to updates and response
We discussed earlier, every order orchestration plan may have one or more fulfilment processes and
each fulfilment process is a sequence of tasks and subprocesses that run consecutively or concurrently
to fulfill all or part of an order. Now let us understand the fulfilment tasks which are part of an
orchestration plan in detail. Here I am just trying to give you a conceptualview and the fulfilment tasks
which are explained below does not need to be designed in the same order. Also, not all the fulfilment
tasks are needed to be there in every orchestration plan.
 SYNC customer and Initiate Billing (Optional)
 Service Feasibility assessment
In Service feasibility assessment we want to achieve following-
 Whether the given customer location is serviceable for the ordered product.
 If the serviceability is found True, identify the network connectivity shortfall

 Depending on the number and type of shortfall, create multiple work orders or ticket of work to
complete network reachability till customer premise and complete the CPE installation.
 Customer Order qualification- Design & Assign Service
If you may recall what we discussed earlier, customer order gets decomposed into Service Order in
COM layer and Service order (CFS) is further decomposed into Resource Facing services (RFS) in
SOM layer. A CFS is a representation of the service that the customer purchased. An RFS is how the
service is implemented on the network. It is important to allocate resources to each RFS before
triggering network activation tasks on network. Design and Assign service ensures this resource
allocation.
By using the design and assign process in a service order, the incoming sales order does not need to
include any information about the existing installed network resources, such as localloops, ports, and
so on. The incoming order needs to describe only the type of service, the desired attributes such as
bandwidth, and any information that affects the choice of resources, such as the customer's location.
The design and assign process completes the transformation from a customer-facing service (CFS) to
a resource-facingservice (RFS).
For example, a customer might purchase a product offering named “Gold Broadband Service”. The
CFS is Broadband Internet Service. How that service is implemented on the network is the RFS, in this
case DSL Service. Therefore, the CFS Broadband Internet Service is resolved to RFS DSL Service.
However, the customer's requirements might be such that DSL is not possible, but a cable broadband
access is possible. In that case, the CFS Broadband Internet Service is resolved to the RFS Cable
Internet Service.
Because the resource-facing services are pre-configured in the PNI/SRI, the PNI/SRI can design the
resource-facing service and assign resources based only on the requirements of the customer-facing
service.
The design and assign process works as follows:
 OM sends the PNI/SRI system a request to design a service and assign resources. The request
specifies thetype of service, for example, broadbandInternet, therequestedservicesattributes,such
as upload and download speed, and relevant data, such as the location of the customer.
 Given the customer requirements, the PNI/SRI system determines which predefined service
configuration is appropriate, and based on that, finds the network resources that are available. For
example, if Broadband Internet Service maps to DSL service, the SRI system knows that the DSL
service design requires a port and a localloop. The PNI/SRI system finds an available local loop at
the customer's location and assigns it to the customer's service.
 The PNI/SRI system returns the resources, resource-facing services, and their associated actions to
OM. The PNI system also changes the status of the resources in the inventory.
 SLA & Milestone
SLA is operator’s commitmenttoits customer over thefulfilmenttimeline. Milestone canbe understood
as an indicator of the Order progress against SLA. An SLA framework calculates the fulfilment
timeline depending on various criteria. We will try and understand them.
SLA calculation framework Design Considerations
 Order priority

 Customer location (Rural, Urban etc.)
 WFM appointment
 Appointment and work force management- WFM
We briefly discussed earlier that appointment is scheduled during Order capture. If we look from
enterprise design perspective, ordering system in general do communicate with Work Force
Management system for Appointment management. When a Sales order is captured, an appointment is
taken at the same time if the Order fulfilment requires any physicalinstallation at the customer premise
by the field engineer. Using that appointment, a work order can be created by OM in WFM and it can
also be tracked there. As the work order progresses, its status can be updated in WFM and notified to
OM by creating a notification channelbetween OM and WFM. Also every customer location may not
have the last mile connectivity through operator network infrastructure and the level of connectivity
shortfallmay be different at different customer location and it needs to be evaluated while creating the
Work Order.
Keeping these things in our mind, we need to create a Work Order model. It is used to support the
interaction between the OM and the WFM.
Understanding Work Order Model
A Work Order Model should have following capabilities-
1. Appointment Handling
A Work order modelshould have the capabilities to recreate, reschedule or update the appointment
or appointment details depending on the requirement.
For example- A customer missed the appointment and equipment installation could not be
completed. In such a case work ticket should be closed as completed, however a new appointment
should be recreated and a work ticket would be required to be created to complete the installation.
2. Connectivity shortfall assessment
Every customer order has customer location as one of the request attribute. Based on this location,
OM can query physical network inventory to assess the level of connectivity shortfall and
accordingly a work order or work ticket can be raised in WFM followed by field engineer site visit
and network equipment installation.
3. Work Order Handling
A work order modelshould be able to create, Update or cancela new or existing work ticket in
WFM. Giving an example for each-
Create-
 New order with shortfalls identified and valid appointment is
 Amend Order is received with new appointment ID during Manage Shortfall.
Cancel-
 Cancel work ticket during Inflight Order Cancellation
 During Order rollback
Update-
 Update the work ticket status post ticket completion
4. Work order status notification

Once a work order is created in WFM, OM would wait for notifications whenever an event has
occurred on a Work Ticket in WFM. WorkOrder modelwould have a mechanism to listen to Work
ticket notifications sent by WFM.
Types of Notifications are as listed below:
 Work Order Created, Assigned, Started, Pending, Rescheduled, Cancelled, Completed
etc.
Based on the notification received, following actions may be taken by work order model
 Changing of order Sub-status
 Sending notifications to calling system, CRM for example
 Updating of the Appointment Date and time in SRI
 Re-calculation of SLA
 Logistics and Supply chain management- Shipping, delivery, delivery reschedule
At the customer premise, before a network equipment or resource could be shipped and delivered, it is
important to identify what that resource is going to be?
One scenario may be, where a physical device or resource is part of the product offering and selected
during order captureitself. For example, aproductoffering“MobileGoldOffer”maybea bundled offer
with mobile phone as part of the offering and customer may have a choice to choose between multiple
brands, color and configuration.
In another scenario, where order capture process is limited to selecting a Product offering which does
not have any physical device as part of the offering but may require a physicalresource to be installed
at customer premise. In such a case, Identification and allocation of resources is done in SOM layer.
We discussed earlier about Design and Assign process in OM in SOM role where we design RFS and
allocate resources correspondingtothoseRFS. For example, a productoffering“BroadbandGoldOffer”
may have a RFS “DSL Service” which requires DSL modem to be installed at customer premise.
Having understood the resource allocation concepts, let us now understand where to place the shipping
and deliver task in the OM orchestration flow. My recommendation is to have this task in TOM layer.
Reason being, resource allocation is done in SOM layer so, shipping should be done post allocation of
resources i.e. in TOM layer.
In TOM layer a “Ship Modem” task can be created which will send shipping order to the hardware
provider followed by a user task which will wait for a delivery notification till the shipped device is
delivered successfully. User task can be closed manually or through automated notification framework.
Note: OM in the COM role can also interact with workforce management (WFM) and supply chain
management (SCM) systems to ship products to customers. However, shipping tasks may require
knowledge of the services and resources being activated and shipped; for example, the service design
process might determine which type of modem to ship. Therefore, such shipping tasks should typically
be delegated to OM instances running in the SOM or TOM role.
 Provision Order- Deliver Service
As discussed earlier, OM in TOM role processes the technical order and orchestrates the activation,
shipping, and installation tasks. The systems typically involved in these activities are WFM, SCM, and
network activation systems. Technicalorders include information about the resources and resource-
facing services that need to be activated, and the equipment that needs to the shipped or installed.

In TOM layer RFSes are decomposed into Technical services which are nothing but network
provisioning tasks and these are executed on the network targets like AAA, HLRs, ELMS, NMS etc.
Provisioning in itself is a big subject but we will have limited discussion here on provisioning. For
correct provisioning design, following design approach should be followed
Design and solution approach-
1. Identify network target – Identify the network elements, ELMS or NMS on which network
services are to be provisioned. Example of Wireless NEs are – HLR, EIR, AUC etc. Wireline
NE examples are- Multiplexers, Layer 2and Layer 3 switches, CMTS,OLT, Aggregation switch
etc.
2. Create the circuit diagram-
Always create circuit diagram before starting the provisioning design for better understanding.
For example- Let’s assume we have to do the service provisioning on a DSL network. Our
approach as Provisioning designer should be to create the circuit diagram first. X-axis, we will
be divided betweenAccess, Aggregation andCore network. Y-axis will be divided betweenOSI
layers. All the network devices and network functions which are to be configured will be placed
in this 2D model.
3. Build the Provisioning commands- Provisioning commands are generally provided by the NE
vendors. As provisioning designer, you need to understand that command i.e. what exactly is
that command doing on network.
4. Define Execution sequence- Once you understand the network command, it is easier to chalk
out the execution sequence. For example- AHLR subscriber profile should be created on HLR
post his SIMauthentication only. So execution Sequence will be “Create AUC profile” followed
by “Create HLR profile”
5. Evaluate Dependency, Exclusions etc. – Evaluate Network Service and attribute level
dependency. For example- Before 3G or 4G service could be provisioned on HLR/HSS, it is
important to provision GPRS bearer service. So 3G Service provisioning is dependent on GPRS
bearer service.
 Error Handling

During execution of a fulfilment process, it is quite likely that a fulfilment task fails. What do we do in
suchascenario?OMdesigners needtothink aboutit duringdesign time. Therearetwopossible solution
approach i.e. handle the failure or rollback the order if the failure is irreparable. Let’s discuss both in
detail-
 Fallout Management
If we want to handle the failure; we do it through a fallout management framework. How it works is,
when a task fails in an orchestration flow, a fallout page opens which requires a manual intervention.
Now who should be accessing that fallout page or what should be the options available on the fallout
page or the expiry time of that fallout page should be thought out during design time. In summary
following design consideration need to be taken into account
1. Fallout options- Retry, Cancel, Skip and Rollback may be the standard optionsavailable against
the failed task and order.
2. Fallout work queue- Work Queue stands forthe work group which is going to work on a
particular failure.
3. Fallout expiry time- Time configured for the expiry of a fallout page once opened.
4. Fallout manual input- Option may be given to manually enterany input attribute if need be.
5. Fallout Status- Fallout status may be Pending, InProgress,Closed etc.
 Rollback
There are certain failures for which it is not possible to take forward the order processing. In such cases,
we need to UNDO all the changes which have been done during course of fulfilment process execution
and send a failure response back to the calling system. This process of UNDO changes and sending
failure response is called rollback.
Rollback again may be auto invoked or manually invoked. Let’s take an example. When OM receives
an order, it first validates it. Now, if validation task itself fails there is no point taking the order for
further processing. In such a case, an auto rollback may be invoked.
But, if a provisioning task fails while interacting with network say in TOM layer, we may want to
analyze the failure and then decide whether to rollback the order or not. In such cases, a fallout page
should be opened with an option to rollback.
 Work Group Management and User tasks-
As we know a fulfilment process is a sequence of tasks and subprocesses that run consecutively or
concurrently to fulfill all or part of an order. Most of the fulfilment tasks are automated tasks and do
not require any manual intervention. But there are cases when we want a user action. In such cases, a
user or manualtask is created. It Represents the need for human intervention in the fulfillment process.
Manual tasks are assigned to personnelwho complete the workfor these tasks in OM monitoring client.
Personnel can manage tasks by adding comments to the order, attaching documents, displaying the
history of the order, and manually entering and saving order data required to complete the task.
Manual or User tasks key design considerations
 A user task should be associated with a workgroup. Awork group is the specialized team
authorized to work on a particular type of user tasks.
 User Task Status- Pending,InProgress,Closed
 User Roles and permissions
 Task assignment options- Do, Redo, Undo, Fix
 Configurable attributes- SLA, PONR, Custom States, Reason Codes and validations
 Assign tasks to users based on taskassignment strategy
 Task Hierarchy
 User Group owner
 Escalation in case of SLAviolation

 Notification- Milestone, Error, Installation etc.
Notification framework is the main control plane of an order flow and entire order progress and its
successfulcompletion relies on how robust notification framework is. It plays a very criticalrole in the
inter-component communication between OM and external BSS/OSS systems where order progress
depends on responses to/from externalsystems.
There may also be cases like fulfilment task failure or milestone achievement etc where BSS/ OSS
systems are required to be notified for corrective or progressive action. In all such cases notification
framework plays an important role.
Notification canbe sentatOrder level, Order item level, Order milestone level, or fulfilment task failure
level etc.
External systems may be
 WFM
 CRM or order-source system
 SCM (Supply Chain management)
 Billing and other BSS systems
Notification Type may be
 Milestone Notification
 Error Notification (In case of a fulfilment task failure)
 Order completion notification
 Logistics flow notification to/from SCM
 Work Order flow notification to/from WFM
 SLA notification
 Order Status Update
As the order progresses, OM communicates with the originating CRM or order-source system to
provide information about the status of the order. You can track the status of tasks, order items, order
components, and the order itself.
When all order items for an order are complete, OM closes the order and informs the originating system
that all of the fulfillment tasks are complete.
 Billing Event activation
Billing account instantiation and activation through a single task or through 2 tasks is an OM
designer’s prerogative. My recommendation is to take the 2nd design approach. If you may recall,
in the COM layer we had instantiated the billing account. Once the network activation is complete,
it is important to get the billing going. Its time now to activate the account.
Network provisioning happens in TOM layer. Once it is done, controlshould be given back to COM
layer where Billing account is activated.
5. Manage OLM events
During course of an order journey following are the likely possibilities-
 In-flight revision requests
 In-flight cancellation

 Error Handling
During design time, OM designers need to modelthe workflow and manage OLM events. For
canceland revision requests, OM generates and executes compensation plans to match a change.
OLM manages order data and status updates and order fallout.
6. Order status update events
After completing the tasks in the technicalorder, OM in the TOM role communicates the order
status to OM in the SOM role, which in turn communicates its order status to OM in the COM
role. OM in the COM role can then complete the original customer order.

Diagram- Order Flow example- Acquisition
Modify and Query Operation workflows
An example
Diagram- Order Flow example- Balance check

Diagram- Order Flow example- Billing Address change
Diagram- Order Flow example- MSISDN Change
Products in OM Space
Amdocs Order Fulfilment

Amdocs Order Management Process
Oracle OSM

An Example
We have understood the Order fulfilment process wellenough to design an orchestration flow for a
real life use case.
We will first model the PSR and create COM/SOM/TOM layer orchestration flow. Next we willsee
in detail how these are implemented.
Quad Play Scenario
 Allocate and activate resources to support new customer services e.g. Quad play offering for
$100 per month
 Broadband – e.g. 10 MB/sec per weekday and 20 MB/sec on weekend
 Voice – 1000 domestic minutes plus international calls at 10c per minute
 Wireless – 1000 SMS, 500 domestic voice minutes, and1GBof data. If exceeded, costs are 1c
per SMS or voice minute or MB
 TV – 50 basic channels s and 4 sports channels
Order Capture entities
 Offer customer differentcombination of services
 Voice
 Data
 TV
 Wireless
 With various price plans

 Voice minutes
 Data speed
 Data volume
 TV Channels
 Number of SMSs
Order Orchestration
O2F Model (OrderToFulfil)

Chapter 4
Enterprise Design
Introduction
In this chapter we will try to understand the enterprise design concepts and explain the design
frameworks in detail. Any telecom enterprise IT setup focusses on 3 key things and they are:
• Plan the Business - Strategy
• Manage the Business - Operation
• Run the Business - Supplier/Partner and Enterprise Management
After reading this chapter readers willunderstandtheapplications whicharepartof Strategy, Operation
and Enterprise Management and integration approach of these applications.
TeleManagement Forum Frameworx
TMForumFrameworx is asuite of bestpractices andstandards thatprovides theblueprint for effective,
efficientbusiness operations. Itenables youto assess andoptimize performanceusingaproven, service-
oriented approach to operations and integration. The practical tools available in Frameworx help
improve end-to-end management of services across complex, multi-partner environments. There are 3
types of frameworks- SID, TAM and TOM. We will discuss each one in detail.
What Frameworx can do
 Innovate and reduce time-to-market with streamlined end-to-end service management
 Create, deliver and manage enterprise-grade services across a multi-partner value-chain
 Improve customer experience and retention using proven processes, metrics and maturity
models
 Optimize business processes to deliver highly efficient, automated operations
 Reduce integration costs and risk through standardized interfaces and a common information
model
 Reduce transformation risk by delivering a proven blueprint for agile, efficient business
operations
 Gain independence and confidence in your procurement choices through conformance
certification and procurement guides
 Gain clarity by providing a common, industry-standard language
Information Framework (SID)
 The Information Framework (SID) is a component of Frameworx, the TM Forum’s blueprint
for enabling successful business transformation. It provides standard definitions for all the
information that flows through the enterprise and between service providers and their business
partners. All of Frameworx, including the Information Framework, is created and evolved by
industry leaders and practitioners in TM Forum’s Collaboration project.
 The Information Framework (SID) provides a reference modeland common vocabulary for all
the information required to implement Business Process Framework (eTOM) processes. It
reduces complexity in service and system integration, development and design by providing an
off the shelf information model that can be quickly adopted by all parties.
5 things you can do with the Information Framework

1. Reduce integration costs by adopting standards-based information models and using them in
applications and interfaces
2. Savehundreds of designhours bystartingwithamatureframeworkand 1500entities developed
and vetted by subject matter experts
3. Speed time to market by using well-understood integration interfaces based on the Information
Framework, eliminating the need for data translation between systems
4. Avoid wasting precious development time on debates with your team, partners, or vendors by
adopting a widely proven, industry accepted, rich and extensible information model
5. Mandate conformance to the Information Framework and save time and money during vendor
evaluation and procurement
Diagram- SID Framework
Application Framework (TAM)
The Application Framework (TAM) is a sub-component of Frameworx, the TM Forum’s blueprint for
enabling successful business transformation. It provides a common language and means of
identification for buyers and suppliers across allsoftware application areas.
All of Frameworx, including the Application Framework, is created and evolved by industry leaders
and practitioners in TM Forum’s Collaboration project.
What is the Application Framework?
The Application Framework (TAM) provides a systems map which captures how business capabilities
are implemented in deployable, recognizable applications.

The Application Framework provides a common language for communities who specify, procure,
design, and sell systems, so that they can understand each other’s viewpoints. It provides logical
groupings of applications, then describes each application’s functionality.
As a result, it is a practical, everyday working guide to define and navigate the elements of the complex
management systems landscape.
5 things you can do with the Application Framework
1. Streamline procurement by using common definitions and language to specify and evaluate
solutions
2. Document and then rationalize your application inventory during transformation projects or
mergers and acquisitions
3. Integrate faster and with lower costs by defining and clearly communicating the functions
provided within each application
4. Reduce custom development costs with modular, standardapplication requirements
5. Increase automation and efficiency with standard, deployable components
Diagram- TAM Framework Level 1 View
Business Process Framework (eTOM)
The Business Process Framework (eTOM) is a criticalcomponent of Frameworx, the TM Forum’s
blueprint for enabling successfulbusiness transformation.
It is a comprehensive, industry-agreed, multi-layered view of the key business processes required to
run an efficient, effective and agile digital enterprise.
All of Frameworx, including the Business Process Framework, is created and evolved by industry
leaders and practitioners in TM Forum’s member driven collaboration community.
What is the Business Process Framework?

It is a hierarchicalcatalog of the key business processes required to run a service-focused business. At
the conceptuallevel, the framework has three major areas, reflecting major focuses within typical
enterprises:
 Strategy, Infrastructure and Product
 Operations
 Enterprise Management
6 things you can do with the Business Process Framework
1. Create a common language for use across departments, systems, external partners and
suppliers, reducing cost and risk of system implementation, integration and procurement.
2. Adopt a standard structure, terminology and classification scheme for business processes to
simplify internal operations and maximize opportunities to partner within and across
industries.
3. Apply disciplined and consistentbusiness process developmententerprise-wide, allowingfor
cross-organizationalreuse.
4. Understand, design, develop and manage IT applications in terms of business process
requirements so applications will better meet business needs.
5. Create consistent and high-quality end-to-end process flows, eliminating gaps and
duplications in process flows.
6. Identify opportunities for cost and performance improvement through re-use of existing
processes and systems.

Diagram- eTOM Framework Level 1 View

Enterprise Architecture
Few Examples
Diagram- Layered Enterprise Architecture with digital experience snapshot

Diagram- SOA Enterprise Architecture
Diagram- Enterprise Integration

SECTION- II
A Guide to Telecom Networks
Basics and Advanced

Chapter 5
Network Basics
Introduction
This chapter talks about basic networking concepts which are foundation for understanding complex
telecom network architecture. Switches, Routers, LANs, Ethernets, SONETs, OSI protocols,
multiplexing techniques etc. are the building blocks of any telecom network. Unless we understand the
network functions of these devices and protocols, readers will find it difficult to understand the
increasingly complex network design.
After reading this chapter, readers willthoroughly understand allthe networking devices, protocols and
their functionin detail andin thenext chapter wewillsee their role in a connectednetworkenvironment.
Basic Networking Concepts
OSI Model
The Open Systems Interconnection (OSI) Modelis a conceptualand logicallayout that defines network
communicationbetweentelecommunicationor computingsystems. OSI referencemodelis divided into
7 layers and each layer offers a set of protocols and these protocols are used by two communicating
devices for uninterrupted communication.
OSI Reference Model

OSI Model Layers and Protocols
Following are some of the important OSI protocols-
 Application layer:DNS, DHCP, FTP, HTTP, IMAP, LDAP, NTP, POP3, RTSP, SMTP, Telnet,
TFTP
 Presentation Layer: JPEG, MIDI, MPEG, TIFF

 Session Layer: NetBIOS, NFD, PAP, SCP, SQL, ZIP
 Transport Layer: TCP and UDP
 Network Layer: ICMP, IGMP, IPSEC, IPV6, IPX
 Data-Link layer:ARP, ATM, CDP, FDDI, Frame-Relay, HDLC, PPP, STP, Token-Ring
 Physical Layer: Ethernet, DSL, ISDN, Wi-Fi, Bluetooth, Sonet/SDH
Networking Components and Devices
Introduction
All but the most basic of networks require devices to provide connectivity and functionality.
understanding how these networking devices operate and identifying the functions they perform are
essential skills for any network administrator and are requirements for a Network+ candidate. This
chapter introduces commonly used networking devices. Although it is true that you are not likely to
encounter all the devices mentioned in this chapter on the exam, you can be assured of working with at
least some of them.
Network Devices Summary
Device Description Key Points
Hub Connects devices on an Ethernet
twisted-pair network.
 A hub does not perform any tasks besides signal
regeneration.
 Are used to create network
Switch Connects devices on a twisted-pair
network.
A switch forwards data to its destination by using the
MAC address embedded in each packet.
Hub/Switches are used for local area network and not
used to connect to internet
Repeater Regenerates data signals. The function a repeater provides typically is built in to
other devices such as switches.
Bridge Connects LANs to reduce overall
network traffic.
 A bridge allows data to pass through it or prevents data
from passing through it by reading the MAC address.
 Transfers data only to the intendeddestination. Bridge
uses MAC address.
Router Connects networks.  A router uses the software configured network address
to make forwarding decisions.
 It Is used to connect networks. Router uses IP address.
Gateway Translates from one data format
into another.
Gateways can be hardware or software based. Any device
that translates data formats is called a gateway.
Are used to establish communication between two
devices which do not use the same protocol for
communication
CSU/DSU Translates digital signals used on a
LAN into those used on a WAN
CSU/DSU functionality is sometimes incorporated into
other devices, such as a router with a WAN connection.
Modem Provides serial communication
capabilities across phone lines.
Modems modulate the digital signal into analogat the
sending end and perform the reverse function at the
receiving end.
Network card
Enables systems to connect to the
network.
Network interfaces can be add-in expansion cards,
PCMCIA cards, or built-in interfaces.
Media converter Interconnects older technology
with new.
A media converter is a hardware device that connects
newer Gigabit Ethernet technologies with older
100BaseT networks or older copper standards with fiber.
Firewall Provides controlleddata access
between networks.
Firewalls can be hardware- or software based. They are
an essential part of a network’s security strategy

A Complete Guide to OSS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to A Complete Guide to OSS

Similar to A Complete Guide to OSS (20)

Recently uploaded

Recently uploaded (20)

A Complete Guide to OSS