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.
