What is a Phone Number?

Do you know what a Phone Number is? 

Are you sure?  Did you say something like?

“It is a number used on one phone to connect to another phone”.

As far as it goes, that is correct, but that is only one of several correct answers. You could have answered the question by saying any of the following and also be right because phone number pops up all over the CSP’s business, but spotting it can be a bit like playing “Where’s Wally” (or “Where’s Waldo”, if you are American).

What is a phone number?

a)    A phone number is a string of digits and is not, in its truest sense, “a number” because any leading zero is significant.

b)    A phone number is something that can be bought or sold and quite significant amounts of money can be paid for phone numbers.  According to The Register (www.theregister.co.uk) the world's most expensive phone number was auctioned for charity on 22 May 2006 in Qatar.  The number, 666 6666, sold for 10m Qatari riyals or £1.5m.

c)    A phone number is asset allocated to the Communications Service Provider (CSP) by the telecoms regulator that is then allocated, sold, lent or in some other way given for the use of a customer (see (a) above).  The customer can, often, take the phone number with him when he leaves the CSP; he can “port” it out.

d)    A phone number is a way of contacting people and/or organisations (the “simple” answer); so it is a type of address.

e)    A phone number is information on how to connect two phones during a call.

f)     A phone number is a service identifier; a phone service is identified by the phone number used by that service.

g)    A phone number is an account identifier; the customer's account or sub-account is identified by the phone number, after all it appears on the bill.

I’m sure there are other answers too, but the list shows that there are quite a few different definitions a phone number and that it should be found in quite a number of different “pictures” that illustrate the CSPs business.

In the CSP world we have the Frameworx Information Model (aka the SID) that provides definitions of important business concepts and provides lots of “pictures” or data models that show how these concepts interrelate.  So let’s start searching for Phone Number in the SID.  The SID is full of entities and relationships so looking for a particular entity really can be a bit like reading “Where’s Wally/Waldo”; looking for what should be something really easy to spot, but that just doesn’t stand out from the crowd.

SID experts know, even though the SID but doesn’t explicitly show it, that Wally (the phone number) can be found disguised as a Logical Resource and as the Logical Resource can be provided through a Product we can claim to have found him for pictures (a), (b) and (c).

The SID actually has phone number in it as (d), a “Contact Medium”, used to contact Customers, so this time Wally wasn’t even disguised but because it doesn’t relate this phone number with the (Logical Resource) phone number of the Product the Customer is using to make phone calls on the CSPs network it wasn’t particularly easy to find.

So can we find the Phone Number in the SID doing the job defined in (e), providing information on how to connect two phones?  Mr Strowger’s mechanical exchange invented about 125 years ago used a phone number to automatically route the call from one phone to another.  Mr Strowger was an undertaker who became convinced that the telephone operator who was the wife of a competitor undertaker was forwarding calls to her husband when people called for an undertaker, and so he dreamt up a way cutting out the operator in connecting two phones together. CSPs still use this fundamental mechanism in one way or another to route calls using the information imbedded in the phone number to work out how to find the phone that is being called.  This is very important for OSS/network operations but it also has a direct impact on the amount charged to a customer for the call and the profit made by the CSP (on net, off net, roaming, roaming partners, etc, etc). 

So we would expect to find Wally/Waldo (the Phone Number) somewhere around the network picture even if it seems to be bit of an obscure area to find him/it.  But, actually, how obscure is this picture?  Let’s face it, the two of the most important fields on a CDR are the “A Number” and the “B Number” – phone numbers and Billing wouldn’t work if these didn’t identify the product/service being used and ultimately the pricing, discounting and allowances to be applied to the customer’s account for the usage of the network. 

Search as you may, you won’t find Wally/Waldo here in the SID.

And finally, and perhaps most importantly, all the CSPs I’ve worked with all talk about the phone number as being the identifier for the user/the subscriber (a legacy concept that isn’t in the SID) or the product (the subscription or price plan (two more legacy ideas quite rightly excluded from the SID).  But this isn’t just a bit of “legacy thinking” which is how I used to dismiss this definition.  There is an important idea here – not all Products are equal – there are the “subscription products” or the “contract product” that define the overall (basic) services (e.g. voice, messages and data) and their prices and allowances while there are other add-on products that are then associated with or ‘bolted on’ to the main product – and the main product, nine times out of ten, is identified by the Phone Number by both the Customer and the CSP. 

The SID doesn’t draw Wally/Waldo into this picture either, though the ever-flexible SID experts (like me) can claim he is there, you just can’t see him!

I don’t think we should let Phone Number hide in Logical Resource whilst also living secret lives as Contact Medium, Product, Service Identifier and Network Address – these different nuances of the phone number’s role need to be explicitly stated. 

We should be able to see Wally/Waldo wherever he is, then when someone who has never seen the SID before says

“Wow!  That looks complicated… Let’s start with something easy; show me where in these diagrams Phone Number is”,

you can point confidently to the model and say

“There!”

rather than waving your hands around talking about rather complicated things called Logical Resource, Resource Role, Involvement Role etc etc and conducting the “Where’s Wally?” hunt.

You may ask,

“How can I make the SID representation of Phone Number a little closer to the business view of Phone Number?”

or perhaps, if you will,

“How can I put Wally in SID?”

If you make the following enhancements to your own in-house implementation of the SID then it will reflect the business realities and define phone numbers in a way that everyone can recognise and relate to and you will able to point confidently to the SID and say “There’s Wally/Waldo”.

1. Put PhoneNumber and PhoneNumberSpecification into the SID as concrete subclasses of Logical Resource and Logical Resource Specification respectively
2. Create an association from Contact Medium (Phone) to this class.
3. Create concrete subclasses of Product Offering and Product as “Contract Product Offering” and “Contract Product” to identify these key products.
4. Create an association from Contract Product to Phone Number “identified by” to acknowledge that this is important relationship.

I know that the last step is a little controversial for “dyed-in-the-wool” SID practitioners as this is information is already provided by the multipurpose ProductInvolvementRole.  This is a sub type of InvolvementRole that is played by a CustomerAccount, or a PartyRole, or importantly a ResourceRole.  As an alternative to step 4 the creation of a concrete subclass of ResourceRole called “IdentifyingPhoneNumber” would keep the purists, if not the business and “Wally hunters” happy.

So Phone Number is a lot of things to a lot of different people and many of these are already in the SID if hidden from view – but one thing is for certain it isn’t just a string of digits or just a Logical Resource.

So, now, where are Wally’s friends IMSI, IMEI and MSISDN hiding in the SID?

The Problem with RFSs

CFSs are difficult to understand and have caused a huge amount of debate in the TMForum Community and beyond, but RFSs that lurk beneath CFSs are even less well understood.

A recent training and consulting assignment to a telco in Canada revealed a number of issues that they had with RFSs and I suspect many other people have similar problems.

The first issue was the name - Resource Facing Services.  "Resource Facing" makes it sound as if the RFSs provide services to the Resources in the same way as the "Customer Facing" services provide services to the "customer" (or rather User, so perhaps CFS should be renamed UFS, but that's another story). But RFS providing services to Resources doesn't make a lot of sense!  If we have a set of services made up of CFSs on one side and RFSs on the other each servicing its own community and the RFS are supporting the CFSs - what provides the Services themselves?  The problem lies in the name Resource Facing Service and in particular the word "Facing"; it is the wrong word.  A better name would be "Resource Exposed Service" or "Resource Hosted Service" or "Resource Provided Services" or "Resource Fronted Services" (to preserve the acronym) as these types of service don't "Face" the Resources, rather they are exposed or provided by the Resources.

My view is that the RFSs are services that run "in the network" (or perhaps in the end user device, if you are talking about a smart phone or advanced set-top-box).  I think of them (and they used to be defined in SID) as interfaces or Services implemented by software running on hardware.

A second issue, that took me a little while to understand when talking to this group of enthusiastic Canadians, was that they were erroneously assuming that the RFSs (at least, if not CFSs as well) were objects involved with the provisioning of a Product on the network.   This I assured them was not correct.   The Service is the service used when using the Product, not the provisioning process used to create a Product in the network.

A third issue was how to describe the provisioning process for RFSs.  Logically you provision a Product by breaking it down into its components - Resources that the Product delivers (i.e. CPE - so we provision by Logistics delivering (and optionally Workforce management installing the

resource) or by giving the resource to the customer in the shop) and CFSs which we provision decomposing the CFSs into RFSs and provision those on the network... 

But, I hold that you don't usually directly provision RFSs.  With intelligent Network Elements you pass commands (Resource Orders?) to the NE and it internally does some magic in its "black box" to provision the RFS, and therefore from a provisioning perspective we can (usually) ignore RFSs.

Nevertheless when provisioning we need to understand how a CFS decomposes into RFSs and which "boxes" in the network support/provide these RFSs but practically we can jump from CFS Spec (via the RFS Spec) straight to Resources that deliver the RFSs.  Practically we rarely provision a CFS or RFS directly (I guess the exception might be something like a VPN where the service has a number of parameters that can be altered after the VPN has been created, but again I would argue this is done by talking to (a) a supervisor service or application (Logical Resource) that manages the VPN or (b) a VPN "box", or resource that provides the VPN (front end).

So, RFSs are as tricky as CFSs - someone recently asked me why we bother with these Services and I replied that before them things were even trickier.  The SID has really helped Communications Service Providers describe their products in very generic manner using CFSs and RFSs.

Involvement Roles

The class InvolvementRole was introduced in Release 12 of SID and is described in the SID document GB922_1UR_Users_and_Roles_R12-0v_1-3.pdf.  It generalised a structure that had been in place in SID for a long time (since V6 at least) the ProductInvolvementRole.

The diagram above is taken from SID V9. 

In SID V12 things changed ProductInvolvementRole became a sub-class of InvolvementRole and it is InvolvementRole that either a CustomerAccount, PartyRole or ResourceRole can be associated (not more than one of these – no “arc” notation showing exclusivity on associations in UML unfortunately).

The idea is that there are actors that can take roles in the use cases and life-cycles of Products (Subscriptions), Resources and Services, and these actors can be Parties (through PartyRoles) Resources (through ResourceRoles) and CustomerAccounts.
 
Looking at this from the PartyRole point of view; this is an excellent idea as it allows the different people involved in a Product, Service and Resource to be defined; the Users, the Administrators, the Engineers etc etc.
 
A CustomerAccount can have roles, other than direct ownership; the default role, I guess, between a Product and CustomerAccount (note there is no simple association between CustomerAccount and Product).  A Product can be paid for by two or more CustomerAccounts as in Split Billing whereby one account pays for, say the monthly recurring charge while the other account pays for any out of tariff charges. 

It is not so clear how this level of involvement can get down to the Service level so that one CustomerAccount ‘owns’ a Service while the other pays for it as according to classic SID the payment is for Products rather than Services, but, hey, it’s “symmetrical” and logically and generically pleasing, so let’s leave it there...
 
The roles a Resource can play and what involvement these can have is not so immediately obvious; however many CSPs use the phone number or MSISDN to identify a Product (subscription) and this can be modelled as a ResourceInvolvement, but a less obvious InvolvementRole is to do with identities – usernames and email addresses.  These are logical resources and these are relevant to Products, Services and I guess Resources.  For Physical Resources it could be tempting to use this for the BOMP (bill of materials) structure of a Resource, but there are far better ways of doing this within the Resource Domain.  I think again this is useful when talking about security – dongles and other security devices could have InvolvementRoles at all 3 levels (Product, Service and Resource).  I wonder if this could even be extended to include DRM.

I wonder if this approach could, should be extended to the CustomerAccount itself.  There a number of PartyRoles that can be involved in the use cases and life cycle of a CustomerAccount from the SalesRep or AccountManager to the PartyRole that signed the contract, theperson responsible for paying the bill.  Then again there can be multiple CustomerAccounts involved in a CustomerAccount – parent account for an account hierarchy, linked account for other more sophisticated split billing – a linking PAYG and Pay Monthly accounts for example, and finally if ResourceRole can be used to provide security through Usernames etc then this is obviously extended to CustomerAccount.

Therefore I believe that the SID should include a new class CustomerAccountInvolvementRole that is defined as follows:

An extension to SID to better model the different involvement roles played by Actors in a Customer Account - examples include "Contract Signer", "Bill Payer", "Account Manager" etc.

CustomerAccountInvolvementRoles can also be played by other CustomerAccounts - allowing a hierarchy of accounts to be set up for example. 

CustomerAccountInvolvementRoles can also be played by ResourcesRoles where for example a security device is used to identify a CustomerAccount.

 

Finally a thought about PartyRoles:  You might say “surely we’ve got PartyRoles that define the type of roles played by a party in a CustomerAccount, for example?”   And you would be right; we’ve got all these Party Roles defined in SID:

•    Customer
•    Competitor
•    Employee
•    OrganizationPost
•    Partner
•    ProjectPartyRole
•    ServiceProviderEmployee
•    Supplier
•    ThirdPartyPayeeAgency
•    ValueNetworkRole
•    WorkforceEmployeeRole
 

Which of these roles can be in an InvolvementRole?  Well obviously all of them – or perhaps it should be none of them.  The User and Roles document GB922_1UR_Users_and_Roles studiously avoids the issue and talks about “Actors” rather than PartyRoles – and perhaps that is right.
 

First of all the PartyRoles listed above are invariant across Products, Resources, Services and CustomerAccounts – a Supplier is always our Supplier, it doesn’t depend on which Product (subscription) we are talking about.  Even Customer is invariant – it is always the Customer across all CustomerAccounts, Products, Resources etc.
 

What the InvolvementRole allows us to do is to define fine grained roles that are different on different CustomerAccounts, Products, Resources etc.  So we can have a PartyRole playing different roles on different CustomerAccounts, Products, Resources etc.
 

So which PartyRole is playing which InvolvementRole?  It still is a little confusing having these different PartyRoles playing different InvolvementRoles – perhaps the SID needs a new PartyRole concrete sub-class called “Actor” and it is the only(?) PartyRole that can play InvolvementRoles.
 

What do you think?

SID Q&A - Question 10

This is the tenth 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 Q&A we discuss the practicalities of using ProductSpecification to record and manage the configuration of complex Products.

So4It:  I'm trying to grasp the correct way of mapping ProductSpecifications and ResourceSpecifications to each other.  For example, take SIM-card as the resource in question since this is the resource that creates the biggest challenge for me at this point, and for ProductSpecification I choose the MobileTelephony.

Here is the problem background:

A typical ProductOffering for the MobileTelephony-spec will be shown in external interfaces (webshop) as a Product where you can choose the form-factor of the SIM, since you want to make sure you get the correct form-factor that matches the terminal where you will use this SIM.

This means that somewhere in the ProductSpecification structure there will be a Characteristic and a number of CharacteristicValues that will be translated into an option for the webshop-user.

At the same time the ResourceSpecification holds a REQUIRED field called partNo.  And a SIM-card partNo will without any question point out a SIM-card of one specific form-factor.

Actual problem:

For me this means that I can't put a ResourceSpecificationCharacteristic holding a bunch of alternative form-factors on my ResourceSpecification for the SIM since each ResourceSpecification will contain one single partNo, and each partNo corresponds to just one form-factor.

So I can see no other alternative than to put the form-factor Characteristic on my ProductSpecification.  But once I've done that I can't see any use for the reference in the MobileTelephonySpecification to the SIMResourceSpecification, rather it just complicates things.

So how would you model this?  Skip the ResourceSpecification reference and by that completely sever the link between the Resource-Domain and the Product-Domain when it comes to Specifications (at least for SIM), or keep the link but by doing that be forced to create some kind of mock-up duplicate ResourceSpecification for the SIM, that doesn't contain any partNo that actually means anything and add ResourceSpecificationCharacteristics for the form-factor to this mock-up? Both ways seem kinda wrong to me, is there a third alternative?

Andrew: You have raised an interesting point; however it must be remembered that the relationship between Product Specification and Resource Specification is m:m so that there has to be an association class that "resolves" this m:m.  The association class will list for each product specification all the valid Resource Specs part numbers (probably with validity dates).  The association class therefore acts like the Product Spec Characteristics that you envisaged.

I do still see a problem though - if there is more than one "type" of ResourceSpec involved with the ProductSpec then you will see all the part numbers from both ResourceSpecs.

But the "terminal" is a Resource which has a ResourceSpec and that ResourceSpec "requires" a particular SIM type (ResourceSpec) given by the part number.  There is a m:m recursive (self) relationship on ResourceSpec that needs to be resolved by an association class that would have a "type" (Required, Forbidden, Optional).  So the Terminal type needs to be an input on the Product selection process (or part of the Product selection) which would be used to select the correct SIM type part number which would be to display the user.

So4It:  So this is what I have today

• In the ProductSpecification I have a ResourceSpecificationReference that contains the ResourceSpecificationId and the order (if any) it should be presented in.
• In the CompoundResourceSpecification I have a Set of ResourceSpecificationReference's that dictates what ResourceSpecification is included in the CompoundResourceSpecification

Andrew:  OK - so you have in data modelling language "denormalised the structure" - that's OK and sensible for an on-line app.

So4It:  So the association class sound like the ResourceSpecificationReference that I have. There I can put any information I want to be associated with the association between the ProductSpecification and the ResourceSpecification right?

Andrew:  Right.

So4It:  It sound like you are saying that in the ResourceSpecificationReference you should always have information about, what is valid to use in the ResourceSpecification it is pointing to.

Andrew:  Yes, but this is in addition to the Compound Resource you have created.  The new association class on that resolves the "m:m recursive" (self) relationship would say which Resource is compatible with other resources - for example which Terminal devices need Large SIMs and which need Small SIMs.

So4It:  So in the case we are talking about below we will have the following,

We have a compound resources specification for PhysicalSimCard that has 2 ReourceSpecification's, 1 for the SimCard with form LARGE and another for the  SimCard form SMALL. The compound ResourceSpecificationReference will specify that 1 of its ResourceSpecifications has to be selected but only 1.

Andrew:  OK - so you are saying that there are Large and Small SIMs and one must be selected, but the structure I am talking about (that resolves the m:m recursive relationship could be used to say which type of SIM should be used with what kind of Terminal, but of course you may have another way of enforcing this business rule.

So4It:  So what you are saying here is that in the CompundResourceSpecification we should have a class describing what included ResourceSpecifications are compatible with each other. How would we do this case?

CompoundResouceSpecification1
      |
      |-------CompoundResouceSpecification2
      |                    |
      |                    |-------------------AtomicResourceSpecification1
      |                    |-------------------AtomicResourceSpecification2
      |                    |-------------------AtomicResourceSpecification3
      |
      |-------AtomicResourceSpecification4


AtomicResourceSpecification4 can only be select together with AtomicResourceSpecification1so in the CompoundResouceSpecification1 I would have a class (what is a good name of r it?) that says AtomicResourceSpecification4 belongs with AtomicResourceSpecification1 for example?

Andrew:  To associate AtomicResourceSpec1 with AtomicResourceSpec4 you need a new class ResourceSpecCompatibility, it would have the following attributes

resourceSpec1.id
resourceSpec2.id
compatibiltyType (valid values = Required, Forbidden, Optional)
validFromDate
validToDate

So for your example:
resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec1
compatibiltyType = Required
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

and to make sure it can't be combined with others
resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec2
compatibiltyType = Forbidden
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

resourceSpec1.id = AtomicResourceSpec4
resourceSpec2.id = AtomicResourceSpec3
compatibiltyType = Forbidden
validFromDate = 01-Jan-2000
validToDate = 31-Jan-2099

So4It:  Where is this class stored on the CompositeResourceSpecification ?
In the case I explained where would it be stored in the hierarchy?  In CompoundResouceSpecification1 and if not then where?

Andrew: Your structure would remain unchanged - I am proposing an additional structure, but I guess it could be implemented as below
 
CompoundResouceSpecification1
      |
      |----CompoundResouceSpecification2
      |              |-----AtomicResourceSpecification1
      |              |                   |------Required, AtomicResourceSpec4
      |              |
      |              |-----AtomicResourceSpecification2
      |              |-----AtomicResourceSpecification3
      |
      |----AtomicResourceSpecification4
      |                 |------Required, AtomicResourceSpec1

So4It:  I'm sorry I don't understand what you mean ere. I understand the class you are proposing but I just have a hard time understanding where to store it. I guess the class

public class ResourceSpecCompatibility{
        private Integer resourceSpecificationId1;
        private Integer resourceSpecificationId1;
        private CompabilityType compabilityType;
        private Date from;
        private Date to;}

obviously has to exist.   What I am thinking is where to store it. There are a couple of options

1. We store it independent from the ProductSpecification structure and fetch it using the id of the ProductSpecification
2. We could store it on a CompositeProductSpecification  if we assume that compatibility will only exists between ProductSpecification that has a common CompositeProductSpecification parent but can we say that you think?

As I see it 1) is more flexible but makes it less performant when we need to collect  the data.

Andrew:    I'm not an expert on physical design, so I wouldn't like to comment further on how to implement the information.  I just know that the hierarchy you have defined needs to be augmented with a structure that defines how Resources in the hierarchy (or other hierarchies) can be related.

SID Q&A - Question 9

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-----------------------

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

Some CSPs have certainly considered prepay packs for post pay customers for example I think some offer overseas calls that pre-pay for calls while roaming abroad.

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.

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-----------------------