As for my experience with the Re reference point and the Rating Function: their specification is not done, at least not to a usable level. I must admit that this statement is based on my findings from a couple of months ago, and I haven’t been tracking the 3GPP charging specs so actively lately. Furthermore: the specification as it is right now is overly complex.

Another note to make: the way HP, Amdocs, Highdeal and others for instance do it (as far as I know), is with proprietary interfaces between OCF (by HP) and RF (by Amdocs/Highdeal). I am not aware of any vendors implementing Re as an interface to their rating product. If you do have this market knowledge, please let me know

Finally to shamelessly plug my company: we have an IMS laboratory in Groningen, within which we can play around with some services and the IMS core. We haven’t jet brought charging/billing into that lab yet, but this is something we would like to do in the future. This in order to experiment with some new concepts we developed, and to really see the opportunities that might arise from using online charging in an IMS environment. If you see any opportunities here, please contact me through e-mail (it’s in the about page).

Best regard,

Frens Jan Rumph

First of all, thank you for your comment! As for the added value: you are correct, a lower TCO and faster ROI is a good thing! I agree with you on that. I am however not sure if that’s going to ‘win the war’ for an operator, so to speak. I doubt if operational excellence will guarantee the viability of an operators business in the long run. So adding value in terms of interesting services to the customer might be a bit more important… As for the service orientation remark: good to hear that @billity is connectable to an ESB. However I’m still not completely convinced whether that would implicate support of the characteristics of service oriented design according to Erl.

Finally, again thanks for your comment! It hits the point a lot better then the article on billingworld.com about which database vendor is under the hood!

I came across your post while surfing. I am employed with Lifetree Convergence Ltd and am familiar with both the products and would like to add my comments to your post.

cent 1: Added Value

As far as our Product J@nus is concerned, speed is not the most important attribute but is incidental (though the product has achieved an enviable level of performance). The unique attribute of J@nus is true convergence across subscriber base (prepaid,post-paid & mixed-mode) and across services (voice,messaging,data, content over GSM/CMDA/Fixed Line/IP).

Having said that, in a Real-Time rating & balance control system the speed of processing provides faster call setup times, higher service levels to the operator, and effective use of available resources. Yes ‘Speed does matter with Size’ of subscriber base. With large subscriber bases, the speed and efficiency of the product does help the operator to keep the TCO low and achive a faster ROI.

Cent 2: Service Orientation

@Billity is a Billing and Customer Care system with a design based on the eTOM model. The business processes as depicted on the eTom framework are available as services on the enterprise service bus.

The SOA architecture of @Billity has provided us agililty in terms of rapid deployment, integration with third party applications and definitely better TCO.

Just to add the last cent … a combination of J@nus and @Billity provides unique levels of sophistication in terms of functionality, performance, innovative
services at a very low TCO covering the entire subscriber base of a telco.

Regards,

Dinabandhu

Indeed it is true that the most commonly used application model is ‘application runs on one physical node’. I could argue that it is not completaly imposible to mimic the caracteristics of AMS that you describe, using for instance J2ME, J2SE and bluetooth communication for instance. But an application environment that is specifically or explicitly geared for this task would be a great advance in ‘mobile’ computing. I’m getting a bit of Jini sensation here

I’m looking forward in the research done and the advances made by your group!

“How would this ‘open and *simple* environment’ differ from existing environments such as J2ME or the Android platform for that matter?”

Because AMS uses a decomposed terminal model. With J2ME or Android you are developing an application that runs on the phone. With AMS your applications don’t run on the phone. Well, some could, but they don’t have to. Applications might run on your PC, your car, your HDTV, your stereo, your home robot, or your home environmental control system. These applications become aware of each other and can interact through the AMS Application Interface.

Thanks for providing some further insight on the AMS. Some comments from my side in return:

1) How would this ‘open and *simple* environment’ differ from existing environments such as J2ME or the Android platform for that matter?
2) I completely agree with you that real service innovation usually does not come from tightly operator controlled environment.
3) Although I’m not a subject expert, I tend to disagree with the remark that SIP is not particularly extensible to next generation applications. Of course SIP is often referred to in combination with the SDP protocol, but as an application developer (using for instance an open Sip Servlet container such as Sailfin) already allows me to develop all sorts of applications. I would however need more then just SIP to create something such as a video game.
4) The decoupling of application and device however is probably more difficult with current standards and environments.

Frens - http://www.telcab.nl