Another random stuff; randomness continued....

[This is a continuation of this entry]

I just finished (quick)reading a book titled "Charging for Mobile All-IP Telecommunications"..., and I think it's a good book. It helps me get a little more into the detail of diameter (protocol). Well, this book does not only explain diameter / charging in IMS network; it also has chapters on charging in GSM and GPRS network. But the part that interests me more of course are the parts on IMS. What I like about the book: it explains the message-exchange for each charging scenario, step-by-step, with some concrete example values to further illustrate the point(s). It helps a lot.



Well, that's all my review :). Ok, I'm not so good at it. Anyway, this charging stuffs is a soup of acronyms (yuck). Here are the acronyms I think I need to know / care about for this moment: CDF, OCS, Ro, Rf, and HSS.

  • CDF (charging data function): the element that receives charging events from various other elements in the (IMS) network, and constructs the complete CDR, before (eventually) handling it over to the billing system.
  • HSS (home subscriber service): the element that stores user's profile (authentication info and subscription profile). The authentication server queries this element (that goes without saying).
  • OCS (online-charging system): the element that calculates service-usage charges. It is primarily used in prepaid-charging scenarios. So, whenenever a service is to be consumed by a subscriber, the SIP proxy / AS sends a request to the OCS, that will trigger a price-calculation on the OCS. Assuming the subscriber still has credits left in her account, the OCS will return a success response, containing the amount of time / volume granted, and the service starts being delivered. In case the service is session-based, the SIP proxy / AS will periodically send other requests, similar to one sent at the beginning, asking for additional credit-usage, to the OCS. All those message-exchanges go through the Ro reference point.
  • Ro: the "reference point" between the CDF and SIP proxies (and the SIP application server) in the (IMS) network. It is used in offline charging. The way I understand "reference point": diameter defines various reference points. I visualize a reference point as a line that connects two elements in the network, and it defines its own set of messages that can be / should be exchanged between those two elements, and in what order. Well, if diameter is a protocol, then I'd say "reference point" is a protocol inside the protocol..., or sub-protocol. So, for each event / session each it manages, those SIP proxies and application server (AS) sends a message to the CDF. Using some correlation mechanism, the CDF builds the complete CDR based on the messages it receives from those proxies and AS.
  • Rf: the "reference point" between the OCS and the SIP proxies and SIP AS.

Ok, those are the factoids. How am I going to use them? Well, I was trying to estimate the development effort for the teleconference system, especially the parts related to charging. First, I need to know what needs to be built. Let's go over them again:

  • CDF: I think we need to develop it. But I guess the "correlation function" would be quite tricky to implement; making it conform to a standard / RFC needs bunch of love, I mean, verifications and validations. I was wondering if there's any open source project, that can be used as a reference / example / base / building block. So far I haven't seen any. Anyway, if we have to build it we need a way to communicate with the SIP proxies / AS (to receive diameter requests, process them, and send the responses), and libraries like jdiameter (or openblox) can be very useful (we'll be using the diameter server library, particularly the one that abstracts away the Rf reference point).
  • HSS: is there such thing as "standard of structure of user profile, subscription profile, etc" for HSS? I guess there is none. At the end, it's "just another database application" in my opinion. You have more freedom in the implementation of your HSS, as long as it can be accessed through Sh reference point. Hmm.... On a second thought, implementing HSS should not be our priority. There are two possible situations: (a) the buyer does not have HSS already, or (b) the buyer already has HSS (e.g.: a telco operator that owns an IMS-network).

    In case (b) we'd better spend our effort more on making sure our teleconferencing system will be able to exploit the richness in the structure of the operator's user / subscription profile (which reflects the operator's charging requirements)..., and vice versa: making sure the operator can exploit the exploit the richness of "chargeabilities" (and functionalities) of our teleconferencing system. In short, we'll have to build an adaptor, a two-way adaptor I'd call it. My tactic would be: (1) brainstorm and investigate the possible ways of charging the users of our teleconferencing system, (2) obtain all the information we can have regarding potential buyer's charging requirements / capabilities, (3) prioritize the list we made in step 1, taking into account the information we obtained in step 2.

    Hmm..., allright, what about case (a)? My short answer for this moment: implement our own HSS. I mean, we define our own schema for storing user and subscriptions profile (just a database application, really, in my view), and provide a thin wrapper around it such that it can be queried using diameter protocol (through Sh reference point). The design of that schema would go in lockstep with the design of the functionalities (thus chargeabilities).
  • Back to CDF: I think the situation is quite similar to that of HSS: (a) the buyer does not have CDF, or (b) the buyer already has CDF. Frankly, I have a couple of doubts related to CDF. First: so, this CDF is the one responsible for the construction of the complete CDR out of the events received from various nodes, by executing the correlation function. But who defines the format of the CDR? Is it tied to the billing system that is used? I guess the answer is no, because there's a mediation element (part of the billing solution) that performs the translation / mapping of the CDRs it receives (in any format) to a format suitable for that billing system. So..., who? Some standard body? I tried googling for it, including looking at the Parlay specs., but nada. Is it the operator (that owns the entire system)? So, in that scenario, the service provider will have to deliver CDRs according to the format specified by the operator. Hmm..., I guess the answer is no, for the same reason: that's why they have the mediation element. What is left then: the service provider itself, us (with close collaboration with the operator, supposedly).

    For the sake of discussion let's assume the latter is true. In that case, the CDF will produce CDR in various formats (one for each service). To me that implies: there are several "correlation functions" installed in that CDF. I picture this "correlation function" as a plugable module (one for each service). Who then is responsible for the implementation of the correlation function of a service? I guess the answer is the service provider itself (again, with close collaboration with the operator), because it posses a better knowledge of the events generated by the service (and their correlations).

    Eh, wait a second..., am I wrong to think that CDF overlaps with meditation in several areas / tasks? But, hey, there's another element between the CDF and the billing system; the "charging gateway function" (CDF)..., and to me (again) it overlaps with billing mediation. This starts to confuse me.

    This whole questioning got me thinking: wouldn't it be easier (and better) if we get a copy of a charging platform that has CDF and HSS, evaluate it, see how it works, see how it can / should be customized or extended in order to make it work with our teleconferencing system. That strategy will help us cast our doubts more quickly. After all, we're not in the business of charging platform (eventhough an intimate knowledge of such platform will be very helpful in designing and selling our solution).

    So I googled around, and here are what I found:
  1. http://www.digitalroute.com/product/productsolutions/ims/
  2. http://www.sitronicsts.com/en/products_and_solutions/telecoms_and_media/bss_oss_product_lines/foris_charging_and_billing.html
  3. http://www.intecbilling.com/Intec/Products+Services/Products/Charging+and+Billing/Intec+IMS+Charging+Solution.htm
  4. http://www.openet-telecom.com/
  5. http://advoss.com/IMS_offlinecharging.htmlhttp://www.marben-products.com/diameter/overview.html
  6. http://www.tieto.com/default.asp?path=1%3B93%3B16080%3B124%3B16837%3B17193%3B16242%3B36978%3B37078

    I had to check the whole set of returned links by google queries: +IMS +charging and "charging data function" just to get that list :).

    Allright..., next what? Hmm.... well, I guess I'll just leave it here for now. On to OCS.
  • OCS: Well, like I already stated, if the 3rd-party charging system we use already has it, then fine, not much to say here. But if not, no other choice we'll have to build it in-house. It is a component that resides very close to the billing system (where subscriber's account information is managed), so I think the OCS can be made as an extension to or something that is built on-top of the billing system. I don't have much time right now to do some more research on this, but if you'd like to know some more, here is an interesting, relevant wikipage: http://en.wikipedia.org/wiki/Online_charging_system.
Finally, I'd like to turn our attention to the application server, where the core of our conferencing server, supposedly, will be deployed. The application will be sending events to various charging elements. It is quite likely that it would be something that changes quite often (i.e.: we add / change feature, we change the structure of service and user profile, etc..., and somehow it would impact the chargeability of the application, hence the the events need to be sent). I was thinking: how to design and implement the application such that those changes in charging would not imply direct change in the main code (whose concern is mainly the administration of live conferences and activities within the conference room). Could it be that aspect-oriented programming is the right answer?

Lastly, for those who like to see things explained with lines of code (me too), here's a nice article from Oracle: "Understanding IMS Charging Architecture"..., and the use of diameter API in BEA (oracle) Weblogic SIP server is detailed here:
One last note: I don't mean to suggest that this conference solution will be designed specifically for deployment in IMS network (only) with this whole rambling about charging-related IMS elements. We should take it at the conceptual level. I mean, at least we should know what things we need to be considered as far as charging is concerned: there should be something that stores user and service profile (HSS), there should be something that correlates the charge-inducing / charging-related events sent by the conference server (CDF), and there should be something that calculates the charge, on-line (OCS). That's all. The names don't really matter. However, by following / learning from how those elements are organized in an IMS network, it will be easier for us to deploy our solution in an IMS network (when the need / opportunity arises). Beside that organization is pretty common I believe, and makes a good sense.

Alright, another last note :): (and this is more a reminder to myself): this whole desk-research over charging elements should not distract us from our main objective that is "to make our conferencing solution (more) appealing, also from charging and billing perspective". I think one way to achieve is by making sure (in the design) that our solution allows us / whoever buy this solution to be as creative / innovative as posssible in charging the users :).