The following diagram shows a typical architecture of a Billing System. This chapter will give a brief introduction of all the interfacing systems starting from top to bottom.
This is the first system from where a customer order is captured and customer is created into the system. CRM stand for Customer Relationship Management and OMOF stands for Order Management and Order Fulfilment.
There are systems like Siebel, which provides modules for CRM as well as OMOF. The CRM system keeps customer-related information along with product and services. The OMOF module is responsible to track order starting from its creation till its completion.
Here, we have two possibilities −
CRM (Customer Relationship Management)/OMOF (Order Management and Order Fulfilment) system contacts with the billing system and billing system contacts with provisioning system to provision the services and network inventory system as well to assign phone numbers or IP addresses, etc.
Second possibility could be that CRM/OMOF system itself contacts with provisioning system to provision the services and network inventory system as well to assign phone numbers or IP addresses, etc.
This system takes commands either from the Billing System or CRM/OMOF System to activate, deactivate and suspend the services. Both the architectures are valid and depend on how architect designs the whole setup.
After taking provisioning commands, this system contacts with core network system to activate, deactivate or suspend the services. After a successful provisioning, this system sends a response back to either the Billing System or the CRM system depending on who sent it the last command.
This system maintains all the network identifiers like phone numbers, MSISDN, IP addresses, e-mail addresses, etc., and technically it is called Network Inventory System.
Depending on the system architecture, either CRM/OMOF or Billing System contacts NIS to obtain a required network identifier and assigns it to the customer at the time of order creation.
This system is responsible to maintain the life cycle of network identifiers, which starts with available and then flows through different stages like activation, suspend, terminate, quarantine, and again available.
Generally, Billing System does not interact with network switches. Network switches are responsible to provide all the services to the end customers based on what services have been provisioned for the customer. These systems are responsible for controlling calls, data download, SMS transfer, etc., and finally generating Call Detail Records.
Network Switches include MSC, SMSC, GGSN and MMSC. For more information on GSM, MSC, SMS, SMSC, GGSN, MMS, MMSC, please refer to our GSM tutorials.
The Mediation System collects CDRs from different network elements in different formats. Various network elements generate CDRs in ASN.1 format and some network elements have their own proprietary format of CDRs.
The Mediation System processes all the CDRs and converts them into a format compatible to the downstream system, which is usually a Billing System. The Mediation System applies various rules on CDRs to process them; for example, mediation system marks the international calls based on the dialed number (B-Number), same way mediation system marks the on-net calls based on A-Number and B-Number.
There may be a requirement to filter out all the calls, which are having call duration less than 5 seconds, the best place to filter out such type of calls will be at Mediation System level. Same way, if some extra information is required in the CDRs, which is critical to billing, then Mediation System will help in providing such information based on some other attributes available within the CDRs.
Once the collected CDRs are processed, Mediation System pushes all the CDRs to the Billing System using FTP because usually Mediation and Billing systems run on different machines.
This is a downstream system for the Billing System and usually keeps tons of historical data related to the customers. Billing System dumps various customer information into the DWH system. This information includes service usage, invoices, payments, discounts and adjustments, etc.
All this information is used to generate various types of management reports and for business intelligence and forecast.
DWH system is always meant to work on bulk and huge data, and if there is a need for any small report, then it is always worth to generate it from the billing system directly instead of abusing DWH for a small task.
An Enterprise Resource Planning (ERP) system provides modules to handle Financials, Human Resources and Supply Chain Management, etc.
Billing System interface with this system is used to post all the financial transactions like invoices, payments, and adjustments.
This system works like a general ledger for the finance department and gives complete revenue information at any point in time it is required.
As such, this is not necessarily a complete system, but it could be a kind of custom component, which sits in between the Billing System and different payment channels like banks, credit card gateway, shops, and retailers, etc.
All the payment channels use payment gateway to post payments to the billing system to settle down customer invoices.
Usually, Payment gateway exposes a kind of API (Application Programming Interface) to the outside world to post the payments to the Billing System. The API can be used by any external resource to post the payment.