Fundamentals of EMS, NMS and OSS/BSS

by Jithesh Sathyan
CRC Press. (c) 2010. Copying Prohibited.

  

Reprinted for Mahesh Sadashivappa Ghanti, Accenture

mahesh.ghanti@accenture.com
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/

All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or

other forms without written permission is prohibited.
Fundamentals of EMS, NMS and OSS/BSS

Chapter 19: What Is OSS and BSS?

Overview
This chapter is intended to give the reader a basic overview on OSS and BSS, which will help in building a solid foundation for understanding
the chapters that follow on the process and applications associated with OSS and BSS. The ambiguity in terminologies used and a brief
history on the OSS/BSS evolution is also handled in this chapter.

19.1 Introduction
The communication service and network industry is moving toward a converged world where communication services like data, voice, and
value-added services is available anytime and anywhere. The services are "always on," without the hassle of waiting or moving between
locations to be connected or for continuity in services. The facilities offer easy and effortless communications, based on mobility and
personalized services that increases quality-of-life and leads to more customer satisfaction. Service providers will get much more effective
channels to reach the customer base with new services and applications. With change in services and underlying network, the ease in
managing the operations becomes critically important. The major challenge is the changing business logic and appropriate support systems
for service delivery, assurance, and billing. Even after much maturity of the IMS technology, there was a lag in adoption because of the
absence of a well-defined OSS/BSS stack that could manage the IMS and proper billing system to get business value to service providers
when moving to IMS.
Operations support systems (OSS) as a whole includes the systems used to support the daily operations of the service provider. These
include business support systems (BSS) like billing and customer management, service operations like service provisioning and
management, element management, and network management applications. In the layered management approach, BSS corresponds to
business management and OSS corresponds to service management, while the other management layers include network management and
element management.
Let us start the discussion with the complete picture where OSS corresponds to support systems that will reduce service provider operating
expenses while increasing system performance, productivity and availability. The OSS is both the hardware and software that service
providers use to manage their network infrastructure and services.
There are multiple activities in the service provider space associated with offering a service that requires an underlying OSS to manage. For a
service starting up, the service needs to be provisioned first, the underlying network including connectivity and the elements needs to be
provisioned, then the service and network needs to be configured, the billing system and SLA management system needs to be configured,
the customer records need to be updated and when the service is activated the billing system also needs to start working on records. This is
just a basic line up of activities and there are many supporting operations associated with just getting a service ready for the customer. The
OSS brings in automation and reduces the complexity in managing the services. After activation of service there needs to be a service
assurance operation, customer service operation, service monitoring operations, and many more operations that fall under the service and
business management scope of an OSS.

19.2 Service Providers

The communication service provider that uses the OSS can be:
1. Local exchange carrier (LEC): The LEC is the term used for a service provider company that provides services to a local calling area.
There are two types of LECs, the ILEC (incumbent local exchange carrier) and competitive local exchange carriers (CLECs). Congress
passed the Telecommunications Act of 1996 that forced the ILECs to offer the use of the local loop or last mile in order to facilitate
competition. So CLECs attempted to compete with preexisting LECs or ILEC by using their own switches and networks. The CLECs
either resell ILEC services or use their own facilities to offer value-added services.
2. Internet service provider (ISP): As the name suggests, these service providers offer varying levels of internet connectivity to the end user.
An ISP can either have its own backbone connection to the Internet or it can be a reseller offering services bought from a service
provider that has high bandwidth access to the Internet.

3. Managed service provider (MSP): A managed service provider deals with delivery and management of network-based services,
applications, and equipment. These service providers can be hosting companies or access providers that offer services like IP
telephony, network management, managed firewalls, and messaging service.

4. Long distance reseller: This is a service provider company that purchases long-distance telephone service in bulk at a reduced price
and then resells the long-distance service as blocks to consumers. The long distance reseller benefits from the bulk purchase and the
consumers also can get the service from a long distance reseller at a price lower than what is normally required.

5. Interexchange carrier (IXC): An interexchange carrier offers long distance services. These carriers complete a long distance call by
routing the call from its originating incumbent local exchange carrier to the destination in a local service provider domain.
6. Application service provider (ASP): An application service provider traditionally offers application as a service over the network. It can
be on-demand software or SaaS (software as a service) based application. Application, systems, and network management can be
combined as a single bundled offering. The application is expected to follow a service level agreement and a complete business
application can be offered by an ASP.
7. Wireless service provider (WSP): As the name suggests, these service providers correspond to carriers who provides cellular,

Page 2 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS

personal, and mobile communication services over a wireless platform to the end user.

8. Content service provider: Content providers were mostly popular in offering Web content on Web sites. In telecom space the content
service provider has a wider scope in providing value-added content in eCommerce and mCommerce environments. Since content
service providers mainly offer value-added service (VAS) over an existing service offering, they work closely with ISPs, ASPs, and
WSPs who provide the basic service on which content can be added.

9. Network service provider (NSP): The NSP offers networking infrastructure as a service. There will be specific network access points
(NAP) through which the equipment and facilities in the network can be accessed. AT&T in the United States and BT in the United
Kingdom are some of the top players in NSP space.

10. Master managed service provider (MMSP): These service providers offer one or more managed services for resale as "point solutions"
generally on a pay-as-you-go model.
In general any organization/company that offers some form of service can be called a service provider. The listings in this section are just
some of the popular terminologies used in association with a service provider in the communication industry.

19.3 Drivers for Support Systems

There are both technology and business drivers influencing the market of support systems. Some of them are:

n Multiplatform environments: The technology focus is now toward multiplat-form-based environments. This increases the complexity on the
infrastructure and business process to be managed. The net result is the requirement for a support system that can manage this
environment.

n Emphasis on system integration: In telecom space there is an increased focus on interoperability and quick integration of products. The
release of the product package in the minimum time (time-to-market) is a key factor for success of the product with multiple competitors
and quick change in technology. Easy integration is possible only when the support systems managing the package are flexible to adopt
the change.

n Mergers and acquisitions: In the current industry there are lot of mergers and acquisitions happening. Merger and acquisition is facilitated
only when the new company and its product can easily be adapted to the business process and products of the master company. For
example, the company being acquired has a product on order management and the master company wants to integrate this project with its
existing OSS solution. If the order management product and the OSS solution are both eTOM compliant and both have a standard set of
interfaces, then very little effort is required in adopting the order management solution.

n Convergence in telecom space: The convergence has a major impact on OSS. With convergence in network, there is a drive to have a
single OSS solution that can manage a variety of networks used in different domains. Most OSS solutions now support both wire-line and
wireless networks. Also when new network and management standards are defined for convergence, the OSS solution has to easily adopt
these standards.

n Off-the-shelf products: COTS (commercial off-the-shelf) products are becoming increasingly popular in telecom and so are standards
around the same. The aTCA (advanced telecommunications computing architecture) is one such standard in telecom space. Most OSS
solutions are expected to have a standard set of interfaces that make it easy to use it, such as a COTS product. The move to comply with
standards is also a driver in changes to OSS space.

n Increasing network complexity: In addition to convergence at domain and technology level, there is also convergence in functionality at
network element level that adds complexity to the network. A typical example of this is an L3-L7 switch in a converged network. In addition
to the basic switching operation, the switch would be performing multiple other functionalities including authentication, encryption, and
application routing. The support systems need to be able to handle the changed network with complex elements having an aggregate of
functionality and a complex information base.

n Emerging standards for service providers: The deregulations and defining of standards for interoperability is a big influence in changing
the OSS industry from legacy modules to interoperating standards compliant modules written by different vendors. Open OSS solutions
are also available for download, changing the competition landscape in OSS space.

n Customer oriented solutions: Customer focused modules are also becoming popular in support systems. Customer management and
assurance of service is becoming an integral part of business support systems. This change in focus can be seen even in management
standardizing forums with work groups specifically for customer centric management.

19.4 What Do Support Systems Offer?

The support systems handle the customer, the services that are offered to the customer and the resources that offer the services (see Figure
19.1). Managing the customer is a part of the business support while billing is a business operation of the service management that finally
applies to the customer. So in most scenarios the three entities that influence the support systems are the resource/infrastructure, service, and
customer.

19.4.1 Support Systems to Manage the Customers

The main part of customer management is to manage the customer account. This account has details on the customer contact, information on
the services the customer has prescribed, and the contracts between the service provider and customer. Tracking on customer raised issues

Page 3 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS

and the usage of the service is all mapped to this account. In most cases a unique identification number is associated to each customer as
part of the account and used as reference in all transactions associated to the customer across the different modules in support systems.
Another aspect in customer management that needs to have a defined process is the sales process. First the sales process should ensure
that the customer requirements are satisfied with the specific service offering. The different phases in the sales lifecycle that affect the
customer like the ordering process, the change of service or add-ons to the service, and even termination of service needs to be managed. It
could be a bundled OSS/BSS solution that takes care of customer management or stand alone modules like an order management system.

Figure 19.1: Holistic view of support systems.

Customer billing is also a key aspect of customer management that forms the mainstream activity in business support system. This will include
determining how much the customer owes, preparing the customer invoice and also applying any payments made along with adjustments
based on discounts or breach in service level agreements. Managing the customer expectations is also becoming an important aspect in
customer management. Parameters like quality of end user experience and providing features for customers to manage their service is now
part of most customer management systems. Other aspects of managing the customer expectations include communicating the service
performance to customer, informing about any scheduled outage well in advance, resolution of any failure in shortest time possible, and
obtaining feedback on how much satisfaction the customer has with the resolution, giving offers and discounts, and also having a good
customer support desk.

19.4.2 Support Systems to Manage Service

The support systems play a major role in managing the services that are offered to the customer. Each service is associated with a set of legal
and contractual specifications that needs to be tracked and managed. Automated support systems keep track of the key performance
indicators (KPIs) that are linked to the SLA and take corrective action whenever the possibility of SLA breach is flagged. In addition to the
contracts for the service, the product offerings in the service, the pricing, promotions, and discounts also need to be planned and tracked.
While fulfillment, assurance, and billing of the service are the day-to-day activities, there is also a platform and product planning to be done in
the backend. This includes deciding when the services should be made available, what features should be offered, and decision on the
possible quote for offering the service.
The order management process also needs to be managed by the support system. This solution is closely integrated with the service
provisioning module. So once the order is confirmed, the provisioning is triggered, which includes configuring the network to deliver the
ordered service for the contractual specifications agreed upon. Service management does not end with provisioning and configuring of the
service. This is followed by active monitoring on the service and an infrastructure to determine the quality of service (QoS) actually delivered by
the network. Based on the events generated during monitoring, the network configuration is fine tuned to reconcile the delivered QoS with
customer expectations. These events also help in network planning, so that next time a similar service is configured, better results can be
obtained from initial settings of the network. Service level events are handled by the support systems. The customer, as well as service
providers, also require reports on the service. The customer would be interested in reports like billing, value-added services used, and when a
service outage occurred. The service provider would be working on reports related to resource capacity, utilization, bugs raised, and the SLA
breaches to be compensated. The generation of reports is a functionality of the support systems.

19.4.3 Support Systems to Manage Resources

The infrastructure management is traditionally a part of the support systems. The support system is expected to ensure the proper operation of
the network and elements that make the infrastructure for hosting the services. The installation of software and updates in the elements needs
to be managed. When service configuration is triggered, the network and its elements need to be configured before setting the service level
configuration. Once the elements are configured with necessary hardware and software, the system needs to be tested. This full cycle of

Page 4 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS

network provisioning including configurations needs to be managed by the support systems.

Inventory management is another important module in support systems. Based on requirements, the inventory needs to be supplied for service
fulfillment. Faulty inventory needs to be removed and free resources after use needs to be reallocated. Also included in the management of
resource is monitoring and maintenance of the resources. This includes detecting faults in the resources and resolving the issues. Collecting
usage records from the network and ensuring better utilization of the infrastructure is a part of monitoring. Security of the infrastructure and
fraud detection is also an activity that is performed by the support systems. The services should be offered on a secure and reliable
infrastructure.

19.5 Defining OSS and BSS

On a broad level, OSS is expected to mean any type of support system related to operations in service provider space. In current management
space, the scope of OSS is more limited. OSS can be divided into three types of management solutions. They are:
1. BSS (business support systems): These are solutions that handle business operations. It is more customer-centric and a key part of
running the business rather than the service or network. Some of the high level functions in BSS include billing, CRM (customer
relationship management), marketing support, partner management, sales support, and so forth. These high level functions encompass
several functions each of which can be a specialized solution. For example, billing will have activities like invoicing, payment processing,
discounts and adjustments, account management, and credit management. Similarly, CRM will have activities like order management,
trouble ticket management, contract management, and SLA breach management.
2. OSS (operation support systems): These are solutions that handle service management. It includes functions like service assurance,
manage services reporting, and so on. In most discussions where OSS is mentioned, it is the service management that is the key focus
and not any type of support systems. So OSS can be used in the context of any type of support system or to specifically mean service
oriented solutions. It is also referred to as "service OSS" to avoid the ambiguity in usage of OSS as the holistic support system.
3. NMS (network management system): These are solutions that handle management of network resources. From support system
perspective the element managers are components of the master network manager and the element management layer is embedded in
NMS functionality. Network OSSs (NMS) manage specific elements in the network deployed by the operator. NMS solutions are
optimized to manage as specific service equipment or a server infrastructure. For example, an NMS for broadband services will be
optimized for broadband infrastructure like ATM, Frame relay, or DSL and an NMS for a specific server infrastructure would be
optimized for servers like Sun Solaris, HP Unix, or Apache Web Server.
The service OSS is the binding glue between the BSS and NMS domains (see Figure 19.2). There needs to be seamless flow of data
between business solutions, service solutions, and network solutions in support systems for a service provider. Together these modules form
the support system in the service provider space. Most service providers do an end-to-end (E2E) between these modules to bring down the
operational expenditure (OPEX).

Figure 19.2: OSS landscape.

19.6 From TMN to eTOM

Page 5 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS

In the early 1980s most of the equipment required by local exchange carriers (LECs) were supplied by one or two suppliers in most parts of
the world. One of the major changes to this approach was the breakup of the Bell System toward the mid-1980s after with LECs were
encouraged to procure equipment from any vendor of choice. As a result the network for offering basic service now had components from
multiple vendors. While there were standard protocols for interaction between network elements from different vendors, there were no popular
and adopted standards for telecom data and interface management in a multivendor environment. This led to an increase in CAPEX for
having new support systems, increase in OPEX with usage of more OSS solutions from different vendors, reduced interoperability between
OSS solutions, and lack of flexibility in bringing in new OSS functionality. The first popular attempt to define the management stack that was
widely accepted was the TMN (telecommunications management network) model.
The TMN model divided the management stack into five layers. The layers are: business management layer (BML), service management layer
(SML), network management layer (NML), element management layer (EML), and the network element (NE) layer. There are management
agents running on the network elements in the network element layer that collect management data. This information from agents is collected
by the element managers in EML. In a network with multiple network elements, there will be multiple element managers. To provide
management data at a network level by aggregating information of multiple network elements in the network, a network manager is used that
sits in NML. Over the network infrastructure, there can be multiple services that will be hosted. The management of the service happens in the
SML. Finally the upper most layer of TMN, the BML is to handle business data in service provider space. The BML takes feed from the SML
and it is the service reports that are used as input in the generation of billing reports and invoicing at BML.
The TMN from ITU-T provided a means to layer the management stack and also helped in defining the basics management blocks using
FCAPS (fault, configuration, accounting, performance, and security). It still was not elaborate enough to map the various telecom processes
into the management layers. So TMF expanded the TMN layers to form a new model called telecommunications operations map (TOM
model). This model brought in more granularities in defining processes in service and the network layer and added modules related to
customer interface and customer care process. TOM was later expanded from just an operations management framework to a complete
service provider business process framework called eTOM (enhanced telecom operations map). Some of the new concepts brought in to
encompass all service provider processes were to introduce supplier/partner management, enterprise management, and also adding lifecycle
management processes. The eTOM is currently the most popular business process reference framework for telecom service providers. A
separate chapter will handle telecom business processes and give a detailed explanation on TOM and eTOM. This section is intended to give
the reader an understanding on how the basic TMN management stack evolved to the current eTOM.

19.7 Few OSS/BSS Processes

Some of the OSS/BSS processes are discussed on a high level in this chapter. Most processes are performed using a solution, which means
that in most scenarios there is a management application mapped to the service provider process. The intent is to familiarize the reader with
some solid examples to get a better understanding of the concepts that will be discussed in the chapters that follow.
n Provisioning: This process involves service and network management functions. The provisioning activity requires setting up the
infrastructure to offer the service. So the provisioning module has to interact with an inventory module to check on what resources—
switches, routers, connections—need to be utilized in setting up the infrastructure. Once the resources are allocated, next the resources
need to be configured. This includes configuration of service parameters for the various customer instances and the configuration of
elements making up the network. Next the service is activated. The element managers send activation commands to the configured
resources. The agents feed the equipment status and other management data to the element managers. Service providers look for flow-
through provisioning and activation solutions that require minimal or no manual intervention. These solutions will interact with inventory and
monitoring modules, so that a single mouse click can result in selection, assignment, and provisioning of resources.
n Order management: The solution for order management will have a Web user interface (UI) or graphical user interface (GUI) that guides
the user through the ordering process. The range of services that can be offered has increased, so has the value-added services offered
with the basic service. There are also bundled services offered where a single order would have multiple services like phone, broadband
internet, TV subscription, and so on. The order management is the main input feed for offering a service and there would be multiple inputs
required in order management that may not be relevant for all customers. So the order management system needs to provide default
values to ensure that order is completed in the minimum time possible and also be robust to avoid any errors in the order. Once the order
is taken, the order management solution also has to trigger modules like service provisioning to complete the order.
n Trouble ticket management: Centralized management of defects including ensuring defect closure and providing consolidated reports is
required for infrastructure and product planning. The trouble ticket manager interfaces with fault management modules in the network and
provides a centralized repository of troubles that needs to be fixed. This helps to improve the service quality and the response time in
fixing a trouble condition. There will be different kinds of reports that can be generated by trouble ticket manager, which will give
information on network equipments that get faulty most of the time, wrong configurations that degrade performance, efficiency of bug fixing
team in fixing problems, map faults to modules or release products from specific vendors, customer quality of service, and issues reported
by customer including outage of service. A trouble ticket can be raised by the customer, the service provider, or some predefined fault logs
will automatically register as a trouble ticket. These tickets are then assigned to the resolution team. Based on how critical the trouble
condition, different levels of supports will be offered and there is usually a dedicated team to handle each level of support. Support level
can map to the services offered like level zero support might involve calling up the person who raised the ticket within an hour and
providing support or it could mean that the trouble needs to be closed within a day. These items are explicitly slated in the SLA.
When a trouble ticket is raised and needs to be assigned to a support person, the work force management module provides necessary
inputs on the best person to solve the trouble condition. The work force management module has details on the skill sets and location of
the technicians. It also maps technicians to specific trouble tickets, like whether the technician is free or working on a ticket, was there a
change in the ticket status, or was the ticket reallocated to some other technician, and so on. Consider the trouble ticket deals with a faulty
switch in Dallas, Texas. So the trouble ticket manager assigns the ticket to a technician in Dallas based on input from the work force
module. After fixing the switch, the technician can change the status of a ticket, for reconfiguration of switch by an operations team in

Page 6 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS

London. Now again the trouble ticket manager can use the work force management module to assign the ticket to a professional from an
operations team in London. This way the trouble ticket manager can track the ticket from creation to closure.
n Inventory management: Cost saving in telecom space can only be achieved when the available inventory is properly utilized. The inventory
needs to be properly allocated and deallocated for offering the service. Inventory data if not managed is really complex. For example,
inventory will include a wide variety of network elements like switches, hubs, servers, trunks, cards, racks, shelves with different capacity,
address range, access points, and so on. The inventory would be placed at different locations and the quantity of each of these elements
may be different at each of the locations. Again some of these elements may be faulty and some of the working elements might be already
in use, booked for a specific provisioning, being fixed, and under maintenance leading to a different status at a given point of time.
When the provisioning module needs resources based on parameters like status, location, capacity, and so on, a decision is made on the
most appropriate resources to be used. This information is provided by an inventory management module. The inventory data can also
include details on serial number, warranty dates, item cost, date the element was assigned, and even the maintenance cost. All inventory
information is logically grouped in the inventory management module. This makes it easy to view and generate reports on the inventory.
Capacity planning can be performed based on inventory data and new inventory can be procured as per need before an outage occurs.
Inventory affects the CAPEX and OPEX directly and hence inventory reports are of much importance to senior management. Procuring
inventory from a new vendor usually goes through a rigorous vendor analysis followed by legal agreements for license including
maintenance and support.
n Billing: Records are generated by the elements in the network that can be used for billing. In switches where calls are handled, call details
records (CDR) are generated that have billing information. CDRs can have multiple call records. The CDR is parsed to for parameters like
calling party number, destination number, duration of call, and so on, and the customer is billed. A mediation module performs the activity
of parsing and converting the information in CDR to a format that can be used by the billing system. Billing modules have a rating engine
that applies the tariff, discounts and adjustments agreed upon in the SLA as applicable, and create a rated record on how the bill was
calculated. This record is stored in a database and aggregated over the billing cycle. At the end of a cycle (like a month for monthly billing
of calls), the aggregated records are used by modules like an invoicing system to prepare an invoice for the customer. There can be
different billing models that can be applied based on the SLA with the customer. It can be flat bill where a fixed amount is billed for usage
of service, or a usage-based bill where the bill reflects the customer's utilization. Another example along the same lines is real-time billing
where the debit from a prepaid account or amount to be paid for on a postpaid account can be viewed as soon as a service is used.
Now let us see an E2E flow of how the modules discussed in this section (see Figure 19.3) interact to offer a service like telephony. Every
activity starts with a business requirement. So first the customer contacts the sales desk and uses a Web interface to request the service.
Once the credit check is performed and the customer can place an order, the required customer details and service information is feed to the
order management system. The order management system creates a work order and sends the details to the provisioning system. The
provisioning system sends data to the inventory system for allocation of appropriate resource. If some manual setup is required before starting
the automated provisioning, then a work request or a trouble ticket is created. Using the workforce module, the request is assigned to a
technician for resolution. Once the setup is ready, the provisioning module initiates provisioning of service and the network. Once provisioned,
the service is activated and the billing module is triggered to collect and work on the billing records.

Figure 19.3: Mapping of the support system process.

19.8 Conclusion
The overview presented in this chapter is just the foundation for the chapters that follow. The difference between OSS and BSS was discussed
in the context of support systems. The ambiguity associated with OSS as a complete support system including network management, against
a support system for service management alone was also handled in this chapter. The shift from the popular TMN to eTOM was also handled.
Support systems are a vast subject and once the reader gets the fundamentals from this book there are many support processes where the
reader can specialize as a professional.

Additional Reading

1. Kornel Terplan. OSS Essentials: Support System Solutions for Service Providers. New York: John Wiley & Sons, 2001.

Page 7 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited
Fundamentals of EMS, NMS and OSS/BSS

2. Hu Hanrahan. Network Convergence: Services, Applications, Transport, and Operations Support. New York: John Wiley & Sons, 2007.

3. Kornel Terplan. Telecom Operations Management Solutions with NetExpert. Boca Raton, FL: CRC Press, 1998.

Page 8 / 8
Reprinted for OET7P/1248301, Accenture CRC Press, Taylor and Francis Group, LLC (c) 2010, Copying Prohibited