Aayush: weblog

Archive for the ‘DIAMETER’ Category

Recommended Inclusions in VoLTE IR.92/94 and the IMS standards to achieve GSM-like ubiquity

Posted by Aayush Bhatnagar on December 13, 2014


gsma-volte

The industry has seen and tracked how the VoLTE standards have been evolving over time.

GSMA IR.92 – IMS Profile for Voice and SMS, has undergone several revisions. On the same lines IR.94 has been published for video calling.

However, if we compare mobile telephony available today – with the IMS and VoLTE standards – some key gaps remain in the IR.92 guidelines, which in my opinion should be included in the GSMA standards to maintain backwards compatibility for VoLTE deployments.

All open market VoLTE device networks, and IMS vendors follow IR.92 and IR.94 as the golden standard for their implementation, and hence this alignment is important.

Some of the key features, which are “candidates” for inclusion are mentioned below. Some of these have 3GPP references, while others exist in some form or the other in exiting 2G/3G networks which are live today.

In the absence of “golden” guidelines for these issues, getting a GSM-equivalent ubiquitous and mature standards based implementation for VoLTE becomes a challenge –

1. Support for USSD over IMS should be endorsed by IR.92

The USSD standards for IMS have finally been frozen and are available in 3GPP TS 24.390 since Release-11, which happened in Q3 2012.

In some countries, USSD is a central medium to enable Value added Services – which actually contribute to whatever is left in Voice and SMS revenues for the operator.

USSD is also a good medium to integrate customer self care applications directly with back-end content based application servers – for example, we may want the customer to preview and choose a ring back tone through an android application.

On Android OS, it is trivial to dial out a USSD request from an application by using the following lines of code:

String hashString = Uri.encode(“#”);
String shortCode = “*” + hashString + “131” +hashString;
startActivityForResult(new Intent(“android.intent.action.CALL”, Uri.parse(“tel:” + ussd)), 1);

Similarly, incoming USSD responses can be intercepted easily.

However, in order to enable this functionality on a large scale on VoLTE handsets – IR.92 has to endorse the 3GPP specification and provide clear guidelines for implementation at the device side as well as at the network side.

2. Over the Air Function (OTAF) – messages tunneled via SMS and USSD.

OTAF is required for remote provisioning of SIM card information. The secure packet structure of communicating these configurations is defined by 3GPP in TS 31.115.

IR.92 should endorse this specification and include the related call flows in the VoLTE implementation guidelines specification.

The OTAF function has an important role to play in the OSS activation processes, when the customer inserts the SIM card in the handset.

Most OTAF servers connect to the IMS network (IPSMGW) as an ESME function over SMPP. Alternatively, they connect to a USSD gateway if the USSD termination option has to be exercised.

3. Complete SMS over IMS call flows (Ref: 3GPP, IR.92 and GSMA Implementation Guidelines)

The GSMA implementation guidelines as well as the 3GPP specifications do not provide end to end and complete call flows for SMS over IMS, covering all the scenarios.

Only  part call flows are explained where there is no clarity on whether the call flow is depicting IMS to IMS SMS termination or whether one of the SMS legs is from the legacy network (circuit switched).

Moreover, important call flows pertaining to international breakout of SMS messages, SMS initiation/termination when the customer is roaming in UTRAN and GERAN networks are missing.

Clarity on the interconnection of the IPSMGW with ESMEs over SMPP are not mentioned in TS 24.341, and are side-stepped in both IR.92 and the GSMA VoLTE implementation guidelines. As a result, all ESME related services which ride on SMPP are missing in the context of VoLTE.

These details should be clarified and detailed out in subsequent releases of the standards hopefully with clear call flows.

In the interim, vendors are forced to fall back to extrapolating existing 2G architectural details for SMS provided by earlier releases in 3GPP.

4. Support for STAR Code based dialing and detailed guidelines

Star code dialing has been available since GSM. Star codes can be used for activation and de-activation of supplementary services.

The MMTEL standards described in TS 24.173 and its downstream standards for IMS and VoLTE do not standardize or provide any guidelines on the usage of star codes.

This is very important from the perspective of  VoLTE devices vendors as well.

The device vendor has to decide which call flow to invoke based on the user input from the screen (whether to send an INVITE with the star code, or whether to send a standard XCAP request to an Aggregation Proxy server via HTTP)

Star code dialing can also be used for vertical services such as televoting and for other purposes.

This gap needs to be addressed in 3GPP and then ideally endorsed by IR.92. Alternatively, IR.92 can publish guidelines based on the SIP-AS models provided in TS 23.218 and allow device vendors to use star code dialing in VoLTE handsets as a configurable option controlled by OMA-DM.

5. Introducing (IN-like) and Interconnecting with (Existing IN) Toll free services for VoLTE/IMS

The 3GPP IMS architecture defines the IM-SSF (IP Multimedia Service Switching Function), as an entity which interconnects existing 2G/3G IN services with the IMS core network. TS 23.218 defines the IM-SSF formally in the standards.

Some of these services include – Televoting, 1800 toll free calling services, calling card services (for subsidized international calling for example), premium rate services (ITU-T E.155) and others.

For operators with existing 2G and 3G circuit switched core networks, it is possible to use the IM-SSF for bringing these IN services to the IMS architecture and then finally deliver them to VoLTE customers.

However, if there is a greenfield deployment of VoLTE, or a complete migration to LTE is required with no dependency on the IN platform, then this functionality of the IN architecture has to be standardized as part of IMS, and endorsed by IR.92.

3GPP may either directly standardize these applications – like they did for CRS and CAT (Customized alerting tones – also known as CRBT in India) – or 3GPP may work with OMA to define these service enablers formally and then endorse these standards.

In the absence of either of these, IR.92 can directly endorse TS 23.218 IM-SSF architecture for incumbent deployments, and the existing ITU-T recommendations for the benefit of greenfield operators, so that vendors can align to a least common denominator.

At the moment, this service agility is missing from the standards and the SIP Application server models have been defined and the rest is left to vendor innovation (please read this as vendor lock-in).

6. SMS Gateway and peering functionality (think of ESMEs)

Standards define E(SMEs) and their interconnection with SMSCs as part of the SMPP v3.4 and v5 specifications for GSM and UMTS.

However, as we move forward to IMS and VoLTE, the IPSMGW standards do not define any such entity, nor endorse the existing standards of SMPP.

Due to this gap, most of the SMS VAS services, SMS hubbing and SMS gateway services remain un-addressed. Vendors and operators have no choice but to fallback to legacy architectural choices or to support SMPP in the IPSGMW network element.

In markets such as India, SMS VAS services are a major cash cow despite OTTs, and these SMS messages are charged at a premium rate.

The SMPP interface should be included and the ESME functionality should be formally defined in TS 24.341 so that vendor implementations and VoLTE deployments are aligned.

7. Inclusion of MSRP and HTTP(S) for multimedia messaging in VoLTE IR.92/IR.94

It is a well known fact that MSRP and HTTP(S) based file transfer is addressed by GSMA in the RCSe specifications. However, it is required that these are also inlcluded in the scope of VoLTE.

Current MMS messages (even though MMS is dead), rides upon HTTP for file transfer.

With the advent of high speed LTE networks and VoLTE, HTTP and MSRP based file transfer can fuel many applications such as multimedia advertising applications, native support for multimedia messaging in VoLTE handsets (outside RCSe) – to give an integrated multimedia chat and SMS experience on a high speed data network.

Moreover, MSRP can also help in purchasing content from operator-owned content stores or streaming unicast content on-demand.

It is quite surprising that the MMS architecture has been left behind in the IMS standards and IR.92, as it can deliver a lot of value in the current context through innovative content based services.

8. Golden IMS configurations for VoLTE devices

At many occasions, there are configurations required in the VoLTE device which are in addition to the bare minimum list of parameters defined by 3GPP in the IMS Management Object specification.

Some typical examples include the following:

a. RTP keepalive timer values

b. RTCP policies

c. Impact of radio conditions on IMS registration

d. Guidelines for camping priorities between GERAN, UTRAN and E-UTRAN

e. Endorsement of SIP timers given in TS 24.229

f. UE registration re-try behavior endorsement as given in Section-5 of TS 24.229

g. UE star code dialing behavior and resolving conflict of triggering XCAP requests vis-a-vis SIP INVITE requests for dialed star codes by the user

The absence of these details cause implementation and interoperability complexities.

Hence, it is desirable if IR.92 provides an annexure detailing out UE guidelines and golden configuration options which can be followed across VoLTE UE implementations.

Conclusion:

In conclusion, there needs to be a mechanism to include practical implementation pain-points and ensure backwards compatibility in the current IR.92 standards.

All the points listed above are widely deployed in current GERAN and UTRAN implementations with the circuit switched core network.

In the long run as more and more VoLTE devices come in the open market, and IMS deployments expand – these inclusions will help move towards attaining a GSM-like ubiquity for VoLTE.

Please feel free to add to this list or suggest more details/feedback.

Posted in 3gpp, 3GPP TS 24.229, 4G, DIAMETER, DIAMETER charging, IMS, IMS data, IMS procedures, IMS Release 11, IMS UE, ipsmgw, IR.92, IR.94, LTE, MMTEL, MSRP, network elements, RCS, supplementary services, telecom, USSD, USSI, VoLTE | Tagged: , , , , , , , , , , , , , , , , , , , , | 3 Comments »

Policy Control and QoS Awareness for IMS and LTE – An evolving trend.

Posted by Aayush Bhatnagar on February 16, 2011


With the advent of LTE and IMS, policy awareness has become an important trend. Rising data rates in the operator’s network have led to a situation where the network carrier is fast becoming the infamous “dumb pipe”.

To avoid this situation, or to atleast improve upon this condition – it is necessary for the operator to introduce various avenues of network intelligence.

Network intelligence can manifest itself in the form of granular policy control, smart policy enforcement and QoS awareness.

3G HSPA defines 4 levels of QoS, Mobile WiMAX defines 5, while LTE defines 9 QoS levels as part of the standard. This provides ample opportunity to the operator to create a business case around Policy and QoS awareness and present a value add to the customer in the form of innovative plans.

Recent standardization trends have shown that there is greater cohesion between policy awareness and the way we charge the customer. Hence, this points to the fact that policy awareness is fast becoming an avenue of monetization for the operator.

In order for the operator to deliver policy awareness in an end to end manner, the following aspects need to be implemented:

1. The network facet of policy awareness:

The Policy and Charging Rules (PCRF) Function and the Policy and Charging Enforcement Function (PCEF) need to be present in the network. In the LTE infrastructure, the PCRF is a dedicated network element, while the PCEF is embedded in the PDN Gateway of the EPC core network.  These two nodes ensure that policy rules can be defined, controlled and enforced in all sessions. In addition to these nodes, we also have a Subscriber Profile Repository(SPR) which acts as a central database for Policy rule provisioning, management, updation and deletion alike. In addition to these nodes, the 3GPP Policy and Charging Control architecture (PCC) defines the OCS (Online Charging System) as an additional element of this logical grouping.

2. The Business facet of policy awareness:

The business facet of policy awareness is best implemented in the OSS and BSS stack. The operator has granular knowledge of customer behavior, his applications, data consumption practices and take-rate of new applications amongst the customer base. This knowledge can be leveraged upon to provide the customer with new plans and offers based on policy control and QoS. A recent report released in November 2010 and conducted by YouGov states that consumers are willing to pay for better QoS for mobile video services. Continuing with the business facet, it is interesting to note that Policy awareness is also a key enabler for loyalty management programs. With personlalized knowledge about the customer, the operator can launch special offers for high ARPU customers to improve “stickyness”.

3. Personalization of Customer QoE (Quality of Experience):

Policy control also provides a unique opportunity for personalization. Policy rules can be exposed to the customer using a Self care portal or a smartphone application. The customer can himself configure policy rules and personalize their experience. All this would eventually lead to greater customer satisfaction.

Some examples of policy awareness and QoS control with charging are as follows (non-exhaustive) —

— Bandwidth Boost for a specific period of time or a given session on a discounted rate.

— Policy control based on customer location and a special rating plan to be applied for that location (home zone).

— Policy and QoS control based on the time of the day and 10% rating discount for that time slab.

— Policy and QoS control based on the nature of content (video, audio, uploads etc) leading to differentiating LTE QCI levels.

— Policy and QoS control arising from loyalty management schemes (which may be based on ARPU).

— Confluence of parental controls on content consumption and policy/QoS.

The possibilities are infinite and there is no end to the practical use cases around policy control and charging.

However, there needs to be an interface between the PCRF and billing as well, to include post-paid services under the gamut of the policy based monetization story.

Some examples of use cases on the PCRF – Postpaid interface:

— ARPU based policy upgrades

— Unbilled amount thresholds leading to policy governed rewards and promotions

— Customers getting policy “voucher” numbers on their bill as a loyalty scheme which offers a free QoS upgrade

— Bandwidth boost for customers paying their bill on time etc.

— Policy control and QoS for enterprise services (which are predominantly postpaid).

Which are the most common and widespread applications of policy control experienced by you ? Please feel free to share your thoughts.

Posted in 3GPP TS 24.229, billing, BSS, DIAMETER, IMS, IMS data, post-paid, pre-paid, Services, user data | 1 Comment »

Telecommunications for Dummies – Telecom Basics and Introduction to BSS.

Posted by Aayush Bhatnagar on September 5, 2010


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 carrier’s 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 customer’s identity who bought it.

On the other hand, Business Support Subsystems is an aggregation of functions which are used for managing an operator’s 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 operator’s 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:



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:

  • 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 subscriber’s 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:

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

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 operator’s 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.

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:

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 protocol’s Rf interface is used for post-paid charging while the DIAMETER protocol’s 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:

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 missed call, or a failed call setup. However, as the call never got connected successfully, the customer will not be liable for paying for this event.  However, the operator may change his policy and may charge the customer even for missed calls if needed.

Interfaces for Charging:

Charging platforms support multiple interfaces to receive events. Some of the most common charging interfaces are on RADIUS and DIAMETER protocols. Legacy systems used to charge calls on the IN (Intelligent Network) pre-paid platform. There were also Web Service interfaces used for charging in some legacy systems. Web services work on the HTTP protocol and are described by SOAP protocol (Simple Object Access Protocol).

2. Rate Determination and Rating.

The next logical step after receiving charging events is Rate Determination and Rating.

Once the charging system has received an event, rate calculation takes place for the customer depending upon the current tariff plan in use. The charging system needs to decide the amount of units which need to be consumed for the particular charging event. For post-paid subscribers, these units are determined and attached to a Call Detail Record (CDR). Then this
“rated-CDR” is dumped as a file.

For pre-paid subscribers, the units are determined and compared with the subscriber’s account balance. If the account balance is sufficient, the charging system borrows the required amount of units from the subscriber’s account and prepares to deduct them from the available balance.

Units may have different manifestations. For example, we can represent Units as “money”. We may also represent units in the form of the allowable limit for data download in Megabytes (units measured by volume). Another possibility is to measure units in terms of talk time. In some special cases, the operator may also represent units in terms of the number of free calls offered and the number of free SMS messages allowed.

Before the charging system rates a particular charging event and actually deducts units, there is an intermediary step. This step is to apply discounts if applicable. For example, if the charging event cost the subscriber $1 and the tariff plan of the subscriber offered him with a discount of 50% on all calls, then the rate applicable would only be 50 cents.

At this stage, it is important to understand the relationship between a tariff plan, the components of a tariff plan, offers attached with the tariff plan, rate to be applied based on the offers, and the validity semantics of the offer. These are important inputs to the rating engine. The final rate to be applied is calculated based on the tariff plan, offers and discounts applicable on the base plan and the validity of the offers.

The illustration below explains the relationship between these concepts:

The figure above represents a tariff plan. This plan has four components:

  1. Voice
  2. Messaging
  3. Data
  4. Content.

The voice component applies to the usual calls that the subscriber initiates. The messaging component of this example refers to the SMS messages. The Data component refers to the internet browsing and downloads from websites. Finally, the content component refers to the purchase of premium content such as movies, ringtones and ebooks from an operator’s application store for example.

Each component of this tariff plan has an offer attached to it. In this example, the customer has the first 100 voice calls free, the first 50 SMS messages free, first 10 MB of downloads free and 2 ringtones free.

These offers have validity applicable to them. The first 100 voice calls are free and must be consumed within a month. Similarly, the free SMS offer must be consumed within a month. The same is applicable to the data download offer. However, the 2 ringtones are free as a onetime offer to the customer. The customer may download at the most 2 ringtones for free. For the 3rd ringtone download, normal charges shall apply.

The last concept is that of usage counters. At the top of each month, the free voice call quota is re-initialized to a value of 100. With each call made by the customer, this value of 100 is decremented until it reaches zero. Once the free call quota is zero, normal charges apply to all subsequent calls. Similarly, for messaging the usage quota is set to 50 every month.

Validity can be represented in several forms:

The validity semantics of an offer has to be very flexible. This flexibility determines the business agility of an operator. In the figure above, certain validity options are shown. For example:

  • A particular offer may be valid at the top of each month. This is similar to the voice call free usage counters discussed in the example earlier.
  • In some other scenarios, a certain offer may be valid only on certain days of the week (Monday, Wednesday, and Friday). For example all voice calls are discounted 30% on certain days of the week (weekends for example).
  • Another option is for an offer to be applicable within a time band of a day. For example, the operator may offer discounted call rates at night time (between 11 pm and 5 am) to encourage usage during these lean hours.
  • The fourth option shown above is for an offer to be applicable only on some special days such as Diwali, New Year, and Christmas etc.
  • The validity of an offer can also be confined to a closed user group. For example, all calls made between users belonging to a closed user group will be cheaper as compared to the calls made outside the group.
  • Some offers are valid based on the destination of the called party. For example, there may be a special rate applied when calls are made between New York and Chicago.
  • Usage based validity is a very interesting case. For example, when the usage of a particular customer crosses $30 in a given month, all subsequent calls for that month are offered at a discounted rate of 25%. This is a kind of a “reward” given to high ARPU customers.
  • The last option for validity is “unconditional”. This means that the offer in question will be valid at all times and for all calls.

3. Mediation:

The mediation process is the next logical step after rating. Once the rate is determined as explained in the previous section, it is applied to the CDR file. Now, this rated CDR file is pulled by the mediation engine. The mediation engine can handle CDRs from various sources – The MSC, the local office, the SMSC etc. It converts all these CDR files into a common file format. The file format is chosen so that it is understandable by the billing system. This file is then provided to the billing system for post-processing.

4. Billing:

In the billing process, CDRs are provided by the Mediation engine to the billing system. The billing system processes these CDRs and reads them. The output of this process is the generation of an itemized bill in human readable form by the billing system. As the CDRs which reach the billing system are already rated, the billing system can calculate the final bill for a subscriber and the rate applied for each charging event.

The details of the CDR are presented in the form of a bill which can then be e-mailed or dispatched to the subscriber’s billing address.

These days, some advanced billing systems also provide a feature of billing level discounts. For example, if there is a high paying customer who generates a bill of over USD 100 every month for 6 months consecutively, the billing system can provide this customer with a discount of 10% on his next bill. The billing system may even ask the rating engine to provide this high ARPU customer with a quota for free calls from next month onwards.

Wholesale/Interconnect Billing:

Wholesale billing applications include a variety of capabilities. Traditionally, this area included inter-carrier settlements capabilities and this was later extended to interconnect billing applications. In today’s competitive markets and complex value chains, it has expanded further to include among others Roaming, wholesale operators, and resellers, Mobile Virtual Network Operators, Content Providers and E-Commerce.

There is now an array of applications in the area providing charging, billing, and settlement capabilities on a raw data basis, individual transaction basis and bulk basis across a variety of services and platforms. These applications work across a variety of platforms and support a wide range of services, preferably in one single system.

5. Reconciliation:

Reconciliation is an offline process of sorting out the CDRs of the calls made in a certain period to determine the following information:

  1. How many calls were made to another carrier’s network?
  2. How many calls made to another carrier’s network were local/regional/international?
  3. How many calls from other networks terminated in my network?
  4. How many calls made from a 3rd party network used my network as a transit and they actually terminated in some other network?
  5. Similar details for SMS messages and MMS messages are also post processed.

Based on such information, the operator makes a record of the amount of revenue which has to be shared with other network operators. This revenue sharing takes place because all these operators share a point of interconnect (POI) to each other’s networks and they allow calls to be made from one network to another.

Due to this, the operator arrives at an amount which other operators need to pay him, and an amount which he needs to pay to other operators for providing interconnect services to each other.

This process is known as reconciliation.

Business Perspective and an introduction to the non-realtime components of BSS:

Business teams of a carrier are responsible for designing and planning tariff plans which are later launched in the form of marketing campaigns. Each tariff plan needs to be designed carefully, keeping in mind the inputs obtained from competitive analysis of the tariff plans of other carriers.

The BSS component which manages the marketing campaigns for the carrier is called “Campaign Management”. The success or failure of a particular marketing campaign is gauged by another component known as “Business Intelligence” or BI.

The Business Intelligence engine provides the business teams with clarity on the performance of a particular marketing campaign based on various parameters. An example is provided below:

  • Popularity of a particular marketing campaign (tariff plan) based on market segments such as children, young executives etc.
  • Popularity of a campaign based on the region – Florida, California, New Jersey etc.
  • Popularity of a campaign based on age.
  • Popularity of a campaign based on market segment – High ARPU customers, Customers with traditionally low ARPU, mid ARPU customers, enterprise customers etc.

Some of the other major functions of a BSS system which is critical from the viewpoint of a network carrier are:

Revenue Assurance:

The main revenue assurance application areas are:

  • Detection of data discrepancies – Detection of data discrepancies between systems and data repositories that might affect the ability to generate revenues or increase costs, including,
    • Configuration data – e.g. between Customer Relationship Management systems, inventory and network)
    • Events data – e.g., between the call Switch, Mediation, and billing)
    • Interconnect/partners billing
  • Detection of data integrity and correctness problems, e.g., a switch that rounds incorrectly the durations of the call.
  • Rating and Billing Verification – Verification of the correctness of the application of the rating and billing rules – e.g., is the customer billed according to the correct plan, and is he billed correctly according to the correspondent plan.
  • Investigation of revenue leakages, finding and correcting their root cause to prevent the recurrence of similar leakages
  • Grouping and classification of leakages
  • Equipment and system testing – Proactively test equipment and systems and processes to verify that they provide accurate information- e.g., using test call generation
  • Trouble Reports and Alarms – Generation and tracking of Revenue Assurance Trouble Reports and Alarms
  • Automation of revenue assurance controls and data collection
  • Automation of leakages correction
  • Generation of revenue leakage reports and documentation both for internal needs as well as a support to regulatory compliance activities.

Fraud Management:

Investigating, preventing and responding to activities that indicate fraudulent use of networks or systems.

This is achieved by effective Fraud Management systems coupled with the instrumentation and monitoring that enables potential fraudulent activities to be identified. There are close linkages between fraud identification and anomaly detection.

Eg:

  1. Someone fraudulently tops up the pre paid account from the system backend without using a voucher.
  2. Someone reduces the value of the pos paid bill just before it is processed by the billing system.
  3. Someone deletes the CDRs or reduces the rate on each CDR.

Conclusion:

The domain of BSS is huge and it is not possible to cover all aspects in a single post.

However, this post provided an introduction to some of the important concepts of this area and how the BSS connects to network elements of a telecom system over standard interfaces.

We also discussed some of the most critical concepts of a BSS platform which directly influence the operator’s revenue realization capabilities – such as rating, charging, billing, reconciliation, revenue assurance and fraud management.

If you found this post useful, please feel free to drop comments. If you feel that a certain area was missed out, or if some part of the post was not easily understandable, please let me know.

Posted in 3gpp, billing, BSS, DIAMETER, DIAMETER charging, IMS, mediation, network elements, OSS, post-paid, pre-paid, RADIUS, rating, telecom | Tagged: , , , , , , , , , , , , | 59 Comments »

Scalability Planning for the IMS Charging architecture

Posted by Aayush Bhatnagar on November 4, 2009


Introduction:

The IP Multimedia subsystem provides a well defined and streamlined architecture for charging multimedia calls and services. The IMS network elements interface to the charging platform over the DIAMETER protocol to enable both pre-paid and post-paid charging.

Architectural Overview of IMS Charging:

The IMS charging platform is sub-divided into two major components:

1. The Charging Data Function (CDF).

2. The Online Charging System (OCS).

The CDF is responsible for receiving triggers for offline (post-paid) charging, while the OCS  is responsible for receiving pre-paid charging triggers. The CDF supports the Rf DIAMETER application, while the OCS supports the Ro DIAMETER application interface.

The Charging Detail Records (CDRs) are collected and co-related at the Charging Gateway Function (CGF). The CGF acts as a gateway to the Billing System, which performs mediation duties.

Scalability Challenges:

In the IMS architecture, the P-CSCF, S-CSCF, SIP-application servers, MRF ,MGCF,BGCF and the I-BCF all need to support the offline charging application interface (Rf interface). This means, that they all act as charging clients (CTF) in case of post-paid scenarios and send triggers to the CDF.

The S-CSCF, the MRF and SIP Application servers support the online charging interface towards the OCS. The IMS Gateway function facilitates the online charging functionality in the IMS architecture by acting as a SIP AS.

A quick look at this architectural challenge, presents us with a nearly all connected architecture for the CDF (it interfaces with almost all network elements for postpaid charging). This means, that the CDF acts as a multiplexer of incoming DIAMETER commands.

charging

Even for a simple IMS call, the CDF will receive triggers from the P-CSCF and the S-CSCF. If there is an application server involvement (Eg: Supplementary services) in the call flow, it will receive a trigger from that AS as well. If an I-BCF is present in the network, and the call needs to be terminated in another IMS domain, the I-BCF will also send a trigger to the CDF. This is a very practical scenario, as almost all IMS customers will subscribe to at least one supplementary service and every IMS core network is expected to have border control and peering functions for security (I-BCF acting as an entry and exit point to the network).

This translates into four DIAMETER transactions for the CDF for a single IMS transaction. A single IMS call initiated by an INVITE may have multiple chargeable transactions involved (those for UPDATEs, RE-INVITEs and finally for BYE).

The OCS interfaces with only the S-CSCF, the MRFC and SIP application servers. Hence it is expected to be less loaded as compared to the CDF as shown below:

online

Scalability Requirements Quantified:

Let us take an example of one IMS call for the sake of calculation. A reasonable load of 100 calls per second is assumed in the calculations.

We will only consider “chargeable” transactions i.e. transactions for whom a DIAMETER trigger will be sent to the CDF. A single call can have an INVITE transaction, an UPDATE transaction, a RE-INVITE transaction (assuming there was only 1 re-invite in the call) and finally a BYE transaction. Thus, we have 4 “chargeable” transactions. For each transaction, a DIAMETER ACR/ACA exchange takes place between each network node and the CDF.

Even for a reasonable load of 100 calls per second on the IMS core, the DIAMETER transactions for the CDF will need to scale up to 1600 TPS. This provides us with a 1:16 scalability requirement for the Charging Data Function.

For the Online Charging System, only the S-CSCF (through the IMS GWF), SIP application servers (if any in the call path) and the MRFC send charging triggers.

For the sake of calculation, if we have one application server in the path of an IMS call, then a single IMS transaction will result in 2 DIAMETER transactions on the Ro interface. Taking the above assumptions, where a single call has 4 “chargeable” transactions, and a moderate load of 100 cps, the OCS requires to support 800 TPS. This provides us with a 1:8 scalability requirement for the Online Charging System.

The scalability factor requirement for both the CDF and OCS is considerable. In case of the OCS, the response time of the CCR will also affect the call setup latency, as the calls to CCR are synchronous. Unless a CCA is received, the SIP signaling is not put through.

Other considerations to plan for scalability:

In view of the above scalability requirements, we can now plan further on the nature of the deployment architecture of the CDF and the OCS.  Even though the scalability requirements for the OCS may seem to be half (800 TPS) of what is projected for the CDF (1600 TPS) , but the complexity of the OCS is much more as compared to the CDF. The online charging system has many internal modules responsible for real-time rate determination, calculation of the units to be debited and account balance management. Moreover, these modules need to be invoked for each IMS call. The OCS also needs to support time based and content based charging paradigms. This means, that the OCS node is a mission-critical and real-time charging engine. Apart from real-time traffic, non-real time traffic such as pre-paid balance inquiries, pre-paid recharging etc also need to be handled at the OCS (either through an IVR or a SMS based mechanism).

On the other hand, the CDF is responsible for creating and dumping the CDR files. There is no real time rate determination or account balance management involved. The raw CDRs are transported to the billing system (BSS) over FTP, where the itemized billing and mediation takes place.

Deployment planning and possible scenarios:

In view of these architectural discrepancies and varying levels of complexities between the CDF and the OCS, it is clear that there needs to be an architectural separation between the OCS and CDF for deployment. This means, that we have to deploy both nodes independently on dedicated machines and possibly in their own independent clusters.

Let us consider a single IMS domain. A single IMS domain will consist of its own S-CSCF, P-CSCF, SIP application servers (as needed), MRF, I-BCF(or a comparable SBC) and the charging platform (consisting of the OCS and the CDF).

For greater scalability, it is proposed to have a dedicated cluster for each charging entity. The OCS application should have its own cluster and so should the CDF. Both the OCS and CDF may share the same gateway (CGF) to interface to the Billing domain. The clusters should have a DIAMETER load balancer (for the Ro and Rf applications) installed to distribute load amongst the cluster instances.

For hardware configuration, the cluster members may reside on the same machine (for smaller deployments) and on a hardware pair (active-standby) to achieve hardware redundancy. Usually, for carrier grade deployments, hardware redundancy is a necessity.

Discussed below are certain deployment configurations of the OCS and the CDF for varying load requirements. The deployment architectural choices shown below also consider hardware redundancy.

NOTE: “Servers” may vary from case to case. You may go for a T-1000, T-2000 or a higher end SUN server. You may also go for a “cheaper” option by using HP servers (8 cores and 16 GB RAM). For large-scale carrier grade deployments, an ATCA is a must (12 blades and above).

Deployment for up to 1 million BHCA (approx 270 CPS):

270 CPS is assumed to be the call rate of SIP signaling during peak load. This is the most common deployment scenario considered in telecom and usually serves as a benchmark.

For IMS deployments for up to 270 CPS, we can have multiple options. We may go for a HP server pair configured as follows:

a) Server-1 has CDF active and OCS as stand-by.

b) Server-2 has CDF stand-by and OCS as active.

This simple deployment will provide us with software and hardware redundancy, while also providing dedicated 8 core servers for each charging application (OCS and CDF).

Software redundancy can be performed by providing 2 independent processes of the CDF and OCS on each server (active) and 2 more processes of the CDF and OCS (for stand-by). A software load balancer may be used for distributing this load amongst the OCS and CDF processes.

This is called a 1+1 active-standby configuration. Each active instance of the CDF is expected to handle up to 4320 TPS at peak load. Each active instance of the OCS is expected to handle up to 2160 TPS at peak load.

This deployment scenario is shown below. The red-arrows depict change-over in case of hardware failure. Software fault tolerance is taken care of by switching between the software instances of the OCS and the CDF by using a software load balancer.

server-pair

Each server may host multiple software processes for the CDF and the OCS. Each process can be a full CDF/OCS application in its own right. The load balancer may also be deployed in an active-standby configuration similar to the CDF and the OCS. The CDF and OCS active processes may be more in number, based on the scalability requirements. Each new process of the OCS or the CDF may be instantiated using a CLI or over SNMP, when the element management systems get an alarm of possible overload or traffic peaks.

This  kind of a deployment architecture is shown below:

failover

Other interfaces for this deployment can be a command line interface (CLI) for polling the system and performing administrative tasks. Other interfaces will be over SNMP to the northbound management systems for monitoring the system health and servicing alarms.

Other possibilities:

In case of higher loads, the system can switch to a 1+1 Active-Active configuration, where all software processes of the CDF and the OCS are accepting DIAMETER requests. The load balancer will handle the distribution of the requests amongst the processes. In case the capacity is still not sufficient, new application processes of the CDF and the OCS can be started by firing the appropriate CLI command to scale horizontally.

For deployments for over 1 million BHCA, as shown earlier, the load on the charging platform will be even higher. For catering to such traffic, a time will come when the system needs to scale out. We may require a server pair for the CDF and the OCS dedicatedly.

Another interim option is to have all active CDF processes on one machine and all active OCS process on another machine and horizontally scale by increasing the number of processes.

Conclusion:

This post was an attempt to quantify the challenges at hand for scaling the Charging platform in the conetxt of IMS. As seen, the requirements for scalability for the charging platform is more challenging than the other core network nodes. The scalability factors increase almost exponentially as the load on the IMS core increases. Hence, a robust scalability architecture needs to be devised for catering to the same.

Posted in 3gpp, DIAMETER, DIAMETER charging, I-CSCF, post-paid, pre-paid, S-CSCF | Tagged: , , , , , , | 12 Comments »