Chapter 19
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.
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.
The communication service provider that uses the OSS can be:
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.
There are both technology and business drivers influencing the market of support systems. Some of them are:
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.
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 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.
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.
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.
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 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.
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:
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).
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.
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.
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 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.
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.
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.
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.
1. Kornel Terplan. OSS Essentials: Support System Solutions for Service Providers. New York: John Wiley & Sons, 2001.
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.