This is the ninth in a series of questions from SO4IT a Swedish IT consultancy company who are using GigaSpaces technology to build a SID based Order Management system for Communications Service Providers.
In this blog we discuss Buckets and Quotas, extensions need for the SID to support prepay and other complex forms of payment and allowances.
So4It: My CTO has told me about buckets and is proposing to use these to allow us to manage allowances. What does the SID have to say about Buckets?
Andrew: This is an interesting area and I’ve been doing a lot of thinking and work on it over the last 8 or 9 years.
The fact is that most telcos BSS’s are far behind on technology - many are still using billing systems that were developed in-house in the 1990's or earlier and rdbms is everywhere in the BSS side of the business. On the OSS side things are very different. The industry has been fast to adopt new technologies and devices like the IN use very hardware and software to deal with the high volumes.
Below is an excerpt of a document I am working on in my spare time, a “A Rough Guide to SID Implementation for SOA Integration” which together with another document I’ve started writing “A Rough Guide to Using the SID for Application Integration” could, one day, form a sort of “SID for Dummies”.
As you will see from the description and model your CTO is on the right track. The model below (at the moment) doesn’t include Usage classes, but that I believe is fairly straight forward. The Rating and Guiding process first of all examines the UDRs and turns them into CFS Usages with basic pricing information applied and then attaches them to the relevant CustomerAccount(s) and applies the ProductPricing applying the quotas/allowances and product specific rating/discounting to create what the SID calls ProductUsage.
The deduction of the cost of these Usages from the Buckets can either happen in real-time as with IN/PAYG products or monthly as part of the Pay Monthly billing cycle.
----------------------Excerpt begins-----------------------
To handle Prepaid (PAYG) customer (accounts), or even better, Product, you need to consider the kind of “refill”/“reloads”/”top-ups” the customer can make. The simplest reload is just money to be credited to the account; however most CSPs offer a range of reloads or “packs”:
In this blog we discuss Buckets and Quotas, extensions need for the SID to support prepay and other complex forms of payment and allowances.
So4It: My CTO has told me about buckets and is proposing to use these to allow us to manage allowances. What does the SID have to say about Buckets?
Andrew: This is an interesting area and I’ve been doing a lot of thinking and work on it over the last 8 or 9 years.
The fact is that most telcos BSS’s are far behind on technology - many are still using billing systems that were developed in-house in the 1990's or earlier and rdbms is everywhere in the BSS side of the business. On the OSS side things are very different. The industry has been fast to adopt new technologies and devices like the IN use very hardware and software to deal with the high volumes.
Below is an excerpt of a document I am working on in my spare time, a “A Rough Guide to SID Implementation for SOA Integration” which together with another document I’ve started writing “A Rough Guide to Using the SID for Application Integration” could, one day, form a sort of “SID for Dummies”.
As you will see from the description and model your CTO is on the right track. The model below (at the moment) doesn’t include Usage classes, but that I believe is fairly straight forward. The Rating and Guiding process first of all examines the UDRs and turns them into CFS Usages with basic pricing information applied and then attaches them to the relevant CustomerAccount(s) and applies the ProductPricing applying the quotas/allowances and product specific rating/discounting to create what the SID calls ProductUsage.
The deduction of the cost of these Usages from the Buckets can either happen in real-time as with IN/PAYG products or monthly as part of the Pay Monthly billing cycle.
----------------------Excerpt begins-----------------------
Prepay classes
The SID has nothing to help with “Pay as You Go” (PAYG, or Prepay). This is a little shocking considering how long SID has been in use in mobile phone companies. There is a little philosophical issue about whether it is the CustomerAccount that it is prepaid or the Products under the account; I favour the latter as this will support convergent billing in the future, or rather the present as it is perfectly technically possible for a Customer to have a monthly postpaid subscription for say talk time, and have a PAYG subscription for data (though few CSPs offer this). Unfortunately most CSPs cannot get their heads around the idea of having just “Customers” (or rather CustomerAccounts) and having the prepaid/postpaid label associated with the Product rather than with Prepaid Customer and Postpaid Customer.To handle Prepaid (PAYG) customer (accounts), or even better, Product, you need to consider the kind of “refill”/“reloads”/”top-ups” the customer can make. The simplest reload is just money to be credited to the account; however most CSPs offer a range of reloads or “packs”:
- Data packs that offer, say 500Mbytes, 1Gbyte or 2Gbytes
- Message packs that offer, say 500 messages
- iTunes packs that buy a fixed number of downloads from iTunes store
- Combinations of the above
Each of these types of reloads has its own balance associated with it. A customer can be out of money for talking (a balance of 0 in minutes, or money) but still be able to browse the internet or send messages because he/she has a non-zero balance on these services. In fact some CSPs even let their prepaid customer go “into the red” on some services if they for example pay by credit card.
Each refill/reload/top-up is added to a specific “bucket” that holds the balance for a given service or set of services. This balance, be it in Money, Mbytes, or a count of units is then debited by use of the appropriate service. Some buckets can be very specific; for example if a customer has a “Message” bucket then when he/she sends a SMS or MMS its balance is debited until it gets to zero. Once this balance is exhausted another bucket or balance – say the general “Money Bucket” takes over and it too is debited for messages (and calls) until it also reaches zero. So there can be a precedence or preference between using one bucket over the other.
The SID has introduced the idea of Allowances in a complex structure (see SID class AllowanceProductPriceAlteration) which is OK (if a little clumsy) for postpaid but does not work well for Prepaid or real-time billing where topups would credit the AllowanceProductPrice and usage would debited it.
In line with industry thinking on convergent billing I have introduced the concept of CustomerAccountBuckets. These buckets are used to hold the balances which can be associated with either a Product or set of Products or CustomerFacingService or set of CustomerFacingServices.
Here is a class diagram I created for my new ABE, Customer Account Bucket.
Each refill/reload/top-up is added to a specific “bucket” that holds the balance for a given service or set of services. This balance, be it in Money, Mbytes, or a count of units is then debited by use of the appropriate service. Some buckets can be very specific; for example if a customer has a “Message” bucket then when he/she sends a SMS or MMS its balance is debited until it gets to zero. Once this balance is exhausted another bucket or balance – say the general “Money Bucket” takes over and it too is debited for messages (and calls) until it also reaches zero. So there can be a precedence or preference between using one bucket over the other.
The SID has introduced the idea of Allowances in a complex structure (see SID class AllowanceProductPriceAlteration) which is OK (if a little clumsy) for postpaid but does not work well for Prepaid or real-time billing where topups would credit the AllowanceProductPrice and usage would debited it.
In line with industry thinking on convergent billing I have introduced the concept of CustomerAccountBuckets. These buckets are used to hold the balances which can be associated with either a Product or set of Products or CustomerFacingService or set of CustomerFacingServices.
Here is a class diagram I created for my new ABE, Customer Account Bucket.
The other new class is an extension class for CustomerAccount, CustomerAccount_AMCF to hold the prepaidPostpaidIndicator a flag to show the type of account (but I still don’t like it).
Eagle eyed readers may have also noticed that I have added a direct link between CustomerAccount and Product that shows which account owns the “subscription”. There is still of course the more generic method of linking the two classes through the CustomerAccountProductInvolvementRole class which this does not replace, but rather ‘specialises’ for the most common relationship between these classes – “ownership”.
----------------------Excerpt ends-----------------------
Eagle eyed readers may have also noticed that I have added a direct link between CustomerAccount and Product that shows which account owns the “subscription”. There is still of course the more generic method of linking the two classes through the CustomerAccountProductInvolvementRole class which this does not replace, but rather ‘specialises’ for the most common relationship between these classes – “ownership”.
----------------------Excerpt ends-----------------------
No comments:
Post a Comment