Telecom Basics and Introduction To BSS

Download as pdf or txt
Download as pdf or txt
You are on page 1of 8

11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS.

Aayush: weblog

Telecommunications for Dummies Telecom


Basics and Introduction to BSS.
Posted by Aayush Bhatnagar on September 5, 2010

50 Votes

Introduction

This post is intended to be a crash course for beginners who wish to understand at a broad level how Business Support
Subsystem components work in a telecom carriers network and more importantly how they connect to the telecom network
elements over standard protocols.

Hence, the text is more conversational in nature rather than completely technical.

Elementary examples of simple call setup procedures have also been included, as they are required for a holistic understanding
of the entire ecosystem beginning from a call setup, to its charging, rating and billing.

Background

Telecom operations from the perspective of a carrier are divided into two broad categories: OSS and BSS.

Operations Support Subsystems (OSS) is an aggregation of functions that enable the operator to provision and manage their
inventory, customers, services and network elements. Provisioning implies making an entry or a record of some resource.
This resource may be a customer, a value added service, inventory such as dongles or even a network element such as a call
control switch. For example if a new customer is acquired, his entire record has to be saved in the network such as his name,
address, phone number allotted etc. This is customer provisioning.

An example of managing an inventory could be as follows.

Dongles procured by the carrier need to be recorded in the inventory management system. Each dongle would undergo a
lifecycle.

Eg: When the dongle is first procured, it is recorded to be in stock. When the dongle is dispatched to a retail store, its status is
changed in the inventory management system to be for sale. When a customer purchases the dongle, its status changes to
sold and it is linked to the customers identity who bought it.

On the other hand, Business Support Subsystems is an aggregation of functions which are used for managing an operators
day-to-day business characteristics and providing an operator with complete clarity on the performance and management of
his diverse lines of businesses.

BSS systems include real-time functions such as charging (post-paid/pre-paid), rating using tariff plans and applying
discounts.

BSS also includes some non-real-time components such as launching new marketing campaigns, analyzing the success of
individual marketing campaigns through business intelligence reports, partner management (for dealing with 3rd party content
providers, other operators, franchisees etc), creating invoices, payment collection, revenue sharing with partners and billing.

This note is more focussed on the BSS components of an operators ecosystem.

Before going to the specifics of BSS, it is useful to review a typical call setup procedure for post paid calls as well as for pre
paid calls, so that some basic grounding is available regarding the call flows in a typical telecom network:

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 1/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog

The above scenario depicts the flow of messages for a pre-paid subscriber. When the subscriber dials out a number, the local
office checks whether the subscriber has enough balance in his/her account. Only if the balance is available, does the call
proceed further.

Case Study:

NOTE-1: There may be one or more transit exchanges between the originating local office and the terminating local office.

NOTE-2: The messages that flow between the local exchange and the pre-paid platform are in INAP protocol. INAP stands for
Intelligent Network Application Part and is the top most layer of the SS7 protocol stack. Both the local office and the service
control point (SCP) understand the INAP messages.

NOTE-3: The other levels of the SS7 stack are: MTP1, MTP2, MTP3, SCCP and TCAP. MTP stands for Message Transfer Part.
SCCP stands for Signalling Connection Control Part. TCAP stands for Transaction Capability Application Part.

Main steps in charging a pre-paid call in a fixed line network:

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 2/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog
When a pre-paid subscriber makes a call, it arrives at a local exchange (also called local office in the US).
The local exchange looks at the calling number (A-party), and finds that it is a call made by a pre-paid customer. So, it
cannot connect the call straight away as it would have done for a post paid customer.
The local exchange has to now talk to a pre-paid platform.
The local exchange sends a message to the pre-paid platform informing it of the A-party number and the B-party
number.
This message is received by a component of the pre-paid platform called the Service Control Point (SCP). SCP is
nothing but a software module that understands and receives messages sent by the local exchange.
On receiving the message from the local exchange, the SCP communicates with a Rating Engine, which is the second
component of the pre-paid platform. The rating engine is the heart of the pre-paid platform. As tariff plans get more
complex and more services need to be charged, the rating engine must have flexibility and functionality to meet the
business requirements.
It contains in its database, the current balance of all the pre-paid customers. Since there are hundreds and thousands
of customers served by a single pre-paid platform, the rating engine will contain a large number of customer balance
records.
The rating engine looks at the A-party number and then queries its database to find out the current balance of the A-
party. If the A-party has zero or insufficient balance, then it must inform the SCP that the calling customer has
insufficient balance.
The SCP in turn will send a message to the local exchange informing it that the calling party has insufficient balance.
The local exchange rejects the call.
If however, the rating engine finds that the calling party has sufficient balance, then via the SCP, the local exchange is
informed that the call can proceed.
If the balance of the calling party is zero, then no further analysis is required by the rating engine to reject the call.
However it has to check by looking at the B-party number if the balance is sufficient to support the minimum rate of
the call pulse.
For example: If a local call costs 10 cents per minute and the balance of the A-party is currently 5 cents, then this
balance is not sufficient. If it was an international call, then even 50 cents balance may not be sufficient.
Assuming that the balance was sufficient and the pre-paid platform has allowed the call to proceed, then the local
exchange will allow the call to proceed and the call will be eventually connected via one or more exchanges to the
called subscriber whose phone will ring.
If the call is abandoned for any reason like the calling party abandoning the call before it is answered by the B-party, no
answer by B-party etc, then the local exchange must again send a message to the SCP informing it that the call has not
matured.
The rating engine had at the time of allowing the call reserved a certain amount from the subscribers balance. For
example the amount that would have been reserved depends upon the tariff plan of the customer. To avoid frequent
requests for the reservation of amount, the rating engine may be asked to grant a larger chunk of units from the
balance.
As an example, assume that the calling party had a balance of USD 100 when the call was made. When the message
reaches the pre-paid platform, the rating engine on finding that there is enough balance will not only respond to the
local exchange about the sufficiency of the balance as described above, but also reserve an amount, say USD 5.
Therefore, temporarily the balance reduces to USD 95. It is important to understand that reserving an amount is not
equivalent to actually reducing the balance of the calling party. At this time, the reservation only signifies the intent,
and actual deduction would happen only if the call is successful and usage takes place.
When the call is answered, the deduction will happen periodically from the reserved amount of USD 5. How much
amount must be deducted and at what periodicity? This has to ultimately depend upon the tariff plan which the calling
party has subscribed to. Assuming that the call charges are 50 cents per minute, this reserved amount of USD 5 would
be enough for 10 minutes of conversation. This is the validity time.
At the time of informing the local exchange that the calling party has sufficient balance and the call can be connected,
the validity time is also conveyed by the SCP. Thus, the local exchange knows that if this call matures, it can let the call
continue for the first 10 minutes without again contacting the pre-paid platform.
If the conversation ends is less than 10 minutes, for example the call duration is just 3 minutes, the local exchange
sends a message to the charging platform and only USD 1.5 will be deducted by the pre-paid platform at the end of the
call. The remaining USD 3.5 is returned to the account balance of the calling party. His closing balance will now be USD
8.5.
Assuming that the conversation exceeded 10 minutes, the local exchange sends another request to reserve more units.
This has to be done prior to the expiry of the validity time. The pre-paid platform will reserve another chunk of USD 5
and inform the local exchange accordingly.
It may happen that the unit reservation request fails. This will happen when the subscriber has no units left in his
balance. In such a scenario, the pre-paid platform will respond with a message that informs the local exchange that the
credit limit is reached. The local exchange will then immediately terminate the call.

The architecture for charging a pre-paid call in a mobile network (GSM) is shown below. Note that it is very similar. Only the
INAP protocol layer has been replaced by CAMEL:

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 3/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog

NOTE-1: CAMEL stands for Customised Applications for Mobile Enhanced Logic.

NOTE-2: There will be a base station and the base station controller (BSC) before the call reaches the originating MSC.
Likewise, there will be a BSC and a BTS on the terminating side.

NOTE-3: There may be one or more transit exchanges between the originating and terminating MSCs. These are called GMSCs
(Gateway MSCs) in mobile networks.

NOTE-4: The architecture in a CDMA mobile network will be identical except that CAMEL will be replaced by IS-826 protocol
layer.

Details of the SMP and the VMS:

Service Management Point (SMP):

The SMP performs the management functions for the IN platform. For example, all the pre-paid customers must be recorded in
the IN platform along with their initial balance. This is typically called the provisioning of customers. This task is performed by
the SMP. The SMP will typically have local terminals where operators can do this task through a set of commands called the
command line interface (CLI). There may also be a need to periodically delete (de-provision) customers who have left the pre-
paid service provided by the operator. It will also be connected to a voucher management system from where commands will
flow to the SMP for bulk provisioning of customers so that a large number of customers can be simultaneously provisioned in
the pre-paid system.

Voucher Management System:

The Voucher Management System (VMS) allows prepaid subscribers recharge their accounts using pre-paid vouchers, allowing
operators to run widely distributed dealer networks efficiently and easily. VMS allows subscribers to add funds to their accounts
within the home network or in roaming networks regardless of location, time of day or model of phone. VMS cuts down
administrative, bookkeeping and servicing expenses and makes it easy for subscribes to keep track of their account balance
without service centres.

Features of a VMS are as follows:

Account recharging via voice services

The Voucher Management System allows subscribers to recharge their accounts from their own telephone as well as from any
tone-dial phone.

Account recharging via non-voice services

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 4/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog

Subscribers can top up their own accounts, as well as the account of any other subscriber of the same network, by sending an
SMS request with a PIN code to a service number. Accounts can also be recharged from a special websites of the carrier.

Account recharging via operator

Subscribers can recharge their accounts via call centre operators.

Distributed system

The prepaid card system allows distributed systems with card roaming to be built, giving your subscribers the ability to
recharge their accounts while in roaming.

Blocking

The Voucher Management System can bar a specific telephone number from accessing the service after several consecutive
unsuccessful attempts to enter a PIN code from that number, protecting you from fraud.

Advertising

Additional profit can be generated from placing adverts on cards, and can also be a useful marketing tool for the operator, for
example to advertise new services.

Card Status

Information about card usage (transactions made) is recorded automatically in the operators billing system.

Revisiting Post paid Charging:

Charging for Post-paid subscribers:

For post-paid subscribers, there is no need to check for the balance. The calls are allowed to proceed further, without any
messaging to a pre-paid platform, and the call details are captured in the form of a Call Detail Record (CDR) at the end of the
call.

These CDRs are used later for billing purposes.

A typical CDR file captures the following information:

Calling party number

Called party number

Call start time

Call end time

Call duration (End Time Start Time)

Call Identifier

This information is saved in the form of a file in the local exchange or the MSC and is pushed to the Charging System for post
processing.

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 5/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog

The charging system has a rating engine and a mediation engine. The rating engine analyzes the CDR files and determines the
rate to be applied for each CDR file. Once this rating is completed, the CDR is known as a rated-CDR. This rated CDR is
pushed to the mediation engine. The mediation engine is required because it may receive CDRs from more than one source
and the format of the CDRs may be different from each source.

The mediation engine post-processes the rated CDRs from multiple sources and reformats them into a common file. This
common file is then pushed to the billing system which generates the itemized bills for each customer based on the CDRs.

A simple procedure for a post-paid subscriber is given below in terms of CDR creation and storage:

We have so far described charging of voice calls. The figure below shows the post-paid charging of a data call in CDMA:

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 6/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog

The data call path bifurcates from the PCF Packet Control Function, which is a logical function of the Base Station Controller
as shown above.

The Rating, Mediation engine and billing system are common for data calls as well as voice calls.

The figure below shows the corresponding architecture for charging a Mobile WiMAX data call. The only difference here is, that
we have an ASN gateway as the controller for data calls. The AAA is sending charging events on RADIUS protocol.

The AAA (Authorization, Authentication and Accounting) server receives the messages on RADIUS protocol. There may be a
dedicated RADIUS to DIAMETER converter in the AAA server, which converts these messages to the DIAMETER protocol and
sends them to the charging platform. DIAMETER protocols Rf interface is used for post-paid charging while the DIAMETER
protocols Ro interface is used for pre-paid charging.

Introduction to the Realtime Components of BSS:

We can now discuss the BSS system in more detail. There may be some overlap of information with what is described above.

The figure below shows a modern BSS system which works on DIAMETER interfaces and integrates with IMS, Mobile WiMAX
and LTE on DIAMETER protocols:

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 7/8
11/1/2017 Telecommunications for Dummies Telecom Basics and Introduction to BSS. Aayush: weblog

LEGEND:

This is only an architectural representation meant to show some of the major components of a BSS system and to provide a
glimpse in to the complexity of a modern BSS platform.

However, we will be discussing conceptually some of the basic components of the BSS system without going into the technical
details.

Some of the most important real-time network facing components of a BSS system are:

1. Charging
2. Rating
3. Mediation
4. Billing, and
5. Reconciliation

1. Charging

Charging of customers can be done in two ways: pre-paid (online) charging and post-paid (offline) charging. The first step of
revenue generation starts with the charging process, where the network elements identify the events which need to be
charged. Some examples include sending a SMS, MMS, dialling a number, downloading content etc. Network elements such
as the local exchange (office), SMSC (Short Message Service Centre) etc generate these chargeable events towards the
charging platform.

Chargeable events can be conceptualized as intents to charge the customer based on his/her actions. At this stage, it is not
guaranteed that these events will actually lead to revenue realization. For example, a chargeable event will be generated for a

https://whitelassiblog.wordpress.com/2010/09/05/telecommunications-for-dummies-telecom-basics-and-introduction-to-bss/ 8/8

You might also like