Defining BSS & OSS
- BSS
BSS is business support systems. BSS
comprises of software applications that
support customer-facing activities. Billing,
order management, customer relationship
management, call center automation are
all BSS applications. BSS may also
encompass the customer-facing veneer of
OSS applications such as trouble-ticketing
and service assurance – these are
back-office activities but initiated directly
by contact with the customer.
- OSS
OSS is operational support systems. OSS
comprises of software (occasionally
hardware) applications that support
back-office activities which operate a
telco’s network, provision and maintain
customer services. OSS is traditionally used
by network planners, service designers,
operations, architects, support and
engineering teams in the service provider.
Relationship between BSS and OSS
The basic relationship between OSS and BSS
where OSS is passed service orders and
supplies service assurance information to the
BSS layer is often referred to as ‘Orders Down,
Faults Up’.
eTOM (enhanced Telecom Operations Map)
eTOM is a TM forum standard. The TM forum
maintains a number of industry standards for
describing system functionality, processes
and data exchange. eTOM is not an interface,
data or integration standard. eTOM allows
vendors and customers to talk about BSS/OSS
functionality and process with a common
reference point and common language. They
allow vendors to articulate how a product
fulfills a particular role in the telco’s BSS/OSS
environment.
eTOM is basically a map which consists of:-
- ‘Vertical’ business processes such as
Operations, Fulfillment, Billing, Assurance
and Strategy
- ‘Horizontal’ management functions, that
must be considered by some or all of the
vertical business functions, such as
Customer Management and Resource
Management.
For example, Resource Management must be
considered in all business functions:
Resources are allocated during Fulfillment;
Resource usage is tracked for billing; resources
are planned and procured as part of a service
provider’s business strategy.
Following figure depicts the overview of eTOM:
Architecture
In this presentation, we would be looking at
the following modules:
- Operation Support & Readiness
The core of the operations area is the
Fulfillment, Assurance and Billing (FAB)
model. FAB operations are directly related
to customer services whereas Operations
Support and Readiness (OSR) ensure that
the operational environment is in place
for FAB to be successful. Operations
include processes that support customer,
network operations and management.
This also consists of sales management
and supplier/partner relationships
management.
- Fulfillment
Fulfillment functions are a critical set to
activities performed in order to fulfill
customer orders for services in a
Communications Service Provider (CSP)
environment.
Fulfillment can be categorized into
following sub-sections:
Order management
Order management systems are complex
systems which allow customer service
representatives to capture and process new
orders, validate new orders, modify new
orders etc. The order entry process capture
order details such as plan or package, service
address, service details, customer accounts,
relevant contacts etc. Data entered during
order entry is also validated against
predetermined rules. Orders can be validated
as the data is entered and/or validation after
all the data has been entered.
The next step is order decomposition. A
single customer order can be decomposed
into one or more service requests, typically
based on service type, in order to be able to
fulfill an order. For example, if a customer
order contains both a broadband order and a
voice order, two service requests would be
created, one each for broadband and voice,
each of which would be sent to the
appropriate provisioning system.
Service provisioning
Service provisioning systems are systems
used to setup products/services for the
customer after an order for the services has
been created and accepted by the CSP. Service
provisioning activities include specifying the
pieces of equipment and parts of the network
to fulfill the service, configuring the
customer’s routing path, allocation of
bandwidth in the transport network, setting
up of wiring and transmission, etc.
Certain activations can be performed
automatically. For such activations, Service
Activation systems pass the device specific
command and configuration changes to the
network elements, Element Management
Systems (EMS), Network Management
Systems (NMS) or application hosts. EMSs are
designed to receive and execute commands
sent by activation systems on the devices.
EMSs can also feed equipment status data
back to network and trouble management
systems.
- Assurance
Assurance consists of proactive and
reactive maintenance activities, service
monitoring (SLA or QoS).
Communications service providers (CSP)
strive to differentiate themselves from
their competitors by implementing
attractive Service Level Agreements (SLA).
SLAs are formal contracts where the level
of service delivered by the CSP to his
customer is stipulated. An SLA may
specify levels of service availability,
performance, operation, etc. as well as
penalties upon violation of the SLA
Offering SLAs implies that the service
provider has the ability to monitor, act
and report the level of service, in order to
assure the quality of services delivered to
the customers. Service Assurance refers to
all the activities performed for such an
assurance. The goal of Service Assurance
is to provide an optimal customer
experience, that helps retain existing
BRAIN SHARE IWHITE PAPERS Randhir Singh
customers, attract new customers and
prevent penalties arising out of violation
of SLAs.
- Billing
Billing collects usage data records
(accounting), various rating functions, and
billing operations. This includes
production of timely and accurate bills,
providing pre-bill use information and
billing to customers, processing their
payments, and performing payment
collections.
Mediation systems collect network usage
data from the network elements and
convert to billable statistics. The following
figure depicts a simple Billing flow:
CDR includes information on start time of call,
end time of call, duration of call, originating
and termination numbers. CDRs are stored
until a billing cycle runs. For IP Based Services,
a new standard is gaining acceptance called
Internet Protocol Detail Record (IPDR). IPDR
supports both voice and data. Billing systems
use mediation output to determine charges
for the customers. Billing systems use
mediation output to determine charges for
the customers.
Rating
Rating systems calculate the charge for an
individual call, IP usage event, etc. using the
CDRs/IPDRs. Rating systems apply charges
based on pre-configured pricing rules,
applicable discounts and rebates from
promotions. This rating process has grown
increasingly complex in recent years. Modern
rating systems can assign discounts based on
calling circles, provide flexible rating plans
based on size of accounts. These serve as
strategic marketing tools but can be very
complex to administer and operate.
Billing systems combine rated records with
prior balance information, payment records,
recurring charges (such as line rentals),
one-time fees (such as installation and
service charges), promotions and discounts
associated with the customer account, taxes
and credits. Overnight billing batch jobs are
among the largest batch environment at a
CSP’s operating environment. Each customer
is assigned a specific billing cycle.
Interconnection Billing
In the competitive world of communications,
service providers often tie-up with partners,
in order to bundle their own products with
their partners. This helps the service providers
to provide attractive bundles of products and
services. However, in order to successfully
settle interconnect billing settlements an
effective interconnection billing is required.
Interconnection Billing products support
inter-working of a service provider’s billing
systems with the corresponding systems of
another service provider, based on
interconnect agreements and contracts.
Fault Management
Fault Management Systems are designed for
detection, isolation and correction of
malfunctions in a communications network.
They monitor and process network alarms
generated by network elements (routers,
switches, gateways, etc.). An alarm is a
persistent indication of a fault that is cleared
only when the triggering condition is
resolved. Examples of trouble or fault in a
network are damage to an optical fiber line,
switch failure, etc.
The following figure illustrates how fault management works.
Network Elements are designed to provide
various levels of self-diagnosis. Older Network
Elements might simply send an alarm
notifying a problem while newer Network
Elements can provide more precise and
detailed messages. Fault Management
Systems may collect alarms via SNMP traps,
proprietary agents, via EMS. They use complex
filtering systems to assign alarms to specific
severity levels and correlate different alarms to
locate the source and cause of a problem.
After a problem is identified, the FMS then
notifies appropriate network operators as well
as pass the problem information to a Trouble
Management System that in turn logs the
problem and issues a trouble ticket to start the
repair process. The Trouble Management
System then sends commands to appropriate
systems such as Field Service Management to
schedule and dispatch technicians to repair
the equipment and/or to EMS to reroute
network traffic around the problem areas.
Trouble Management systems also handle
automatic escalation, such as progression of a
ticket from minor to major or major to critical,
etc., and support a variety of notification
methods such as emails & SMS.
Fault Management systems usually provide
graphical network displays which are
projected on large screens at the Network
Operations Centres (NOC).
- Network Performance Management
Performance Management components in
NMS and other Alarm Handlers monitor
applications and systems and collect
performance variables of interest at specified
intervals. Performance variables of interest may
be service provider network edge availability,
response times, packet delivery rate, packet
losses, latencies etc., to name a few.
One way to capture performance metrics is
collecting event logs, CDRs and other
performance data such as counters or timers
that the network and system elements
maintain as part of their normal operation.
This is referred to as passive measurement.
Note that active measurement measures a
service, such as application response time,
instead of the internal operation of a network
element.
An example of active network performance
test is injecting “ping” (short, network layer
echo packet) into the network aimed at a
remote IP address. Round-trip time is
measured if the ping packet returns, and an
error counter is incremented if it doesn’t.
Performance statistics captured by “active” or
“passive” performance tests are normalized
and routed to relational databases and/or
data-warehouses. An alternative is to pass the
performance data directly to Performance
Management tools.
Performance statistics are initially analyzed to
determine the normal (baseline) levels.
Appropriate thresholds are determined for
each of the interesting performance variable
so that exceeding the thresholds indicates a
problem.
Performance Management tools then
measure the performance variables against
SLAs defined as thresholds per application or
service, on an on-going basis. In case of
exceptions they report them to alarm
handlers. This form of performance
monitoring is reactive performance
monitoring. Some tools also support
proactive monitoring by way of providing
simulation tools that helps network operators
project how growth in network traffic will
affect performance metrics and plan to take
proactive countermeasures such as increase
capacity.
Performance Management tools may also
support real-time and historical reporting.