-
Frens Jan Rumph
Profile: I am a researcher, technical consultant and software engineer based in Holland. I have specialized in Charging, Accounting and Billing architectures. From both a technical point of view (IETF, 3GPP, etc) and a business point of view (TM Forum, GBA).
Main interests: Telecom, Charging, Accounting, Billing, Service Orientation, Software Architectures, Software Engineering
Disclaimer: All data and information provided on this site is for informational purposes only.
I do not make any representations as to accuracy, completeness, currentness, suitability, or validity of any information on this site and will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use. All information is provided on an as-is basis.
Furthermore, this is a personal weblog, the opinions expressed here represent my own and not those of my employer.
SIP UA for Android (+stack + RTP) released
Arjun Roychowdhury announced the release of their SIP UA for Android (+stack + RTP), which I just needed to applaud! He a also made a side note that a IMS UA for Android might be expected as well!
Read the announcement at roychowdhury blog
Frens Jan Rumph
Extracting Ro: pfiew, that was a load of work!
Sigh, what the $%^$% are standards for?
Sigh, what the $%^$% are standards for, if your not going to follow it? Sorry I just need to bitch a little about this. Grmbl…
I’m working on an implementation of the Ro reference point, for which I’m using a proprietary tool that converts definitions of Diameter applications (such as Credit Control or Diameter Base) in the ABNF like format defined in IETF RFC 3588 into Java Code. Which worked like a charm for the Diameter Base and Diameter Credit Control applications. I could just take the RFC text, strip off the ‘bla bla’ and make some minor adjustments in order for it to be able to be parsed, and voila: a Java class containing the entire spec… Quite nice 
Now I’m trying to do the same for the 3GPP Ro reference point (as specified in 3GPP TS 32.299), pfff. And all of a sudden I noticed that some AVP names start with ‘3GPP’, which is not much of a problem at first sight, but… IETF has given this definition of a AVP name:
diameter-name = ALPHA *(ALPHA / DIGIT / "-")
Which clearly does not allow a command name or avp name to start with a DIGIT!!! So now I have to modify the converter in order to let it parse AVP’s like 3GPP-Charging-ID…
Sigh…
Update: But of course Java does not allow an identifier to start with a digit either!!! So ill just call them TGPP-* or something like that…
Again: Sigh…
Frens Jan Rumph
Billing and OSS World 2008 - my ideal program
Next week (29th of April to the 1th of May) the Billing and OSS World 2008 will be held in Chicago. Which I will not attend, which is a shame, because it seems really interesting!
Only looking at the topics (I don’t know who the speakers are) my ideal program would be:
Day 1: Tuesday, April 29
9:30 - 11 A.M. Plenary Session: OSS Transformation
11:10 A.M. - Noon Session A: Service Creation & Delivery: Managing the Content Lifecycle — Enabling the Digital Marketplace
1:00 - 1:50 P.M. Session A: Service Creation & Delivery: Case Study: BT 21 Century Network Boosts Web 2.0 Consumer and Enterprise Applications with Voice, Presence and Messaging
2:00 - 2:50 P.M. Session D: Billing/Payment Processing: Charging Ahead with a Real-Time, Advertising- and Policy-Driven Billing Model
3:00 - 3:50 P.M. Session B: Service Assurance & Customer Experience: Beyond CRM: New Technologies for Improving the Customer Experience Session
4:00 - 4:50 P.M. Session D: Billing/Payment Processing: Making Mobile Payments Work: Exploring the Pros and Cons of Leading Methods
5:00 - 6:30 P.M. Session B: Service Assurance & Customer Experience: Harness the Power of Self-Service to Drive Sales, Reduce Costs and Improve Care
Day 2: Wednesday, April 30
8:00 - 8:50 A.M. Session C: Customer Loyalty/Management: Using Billing Data to Promote New Services and Build Customer Loyalty
9:00 - 9:50 A.M. Session C: Customer Loyalty/Management: Examining the Relationship Between Customer Loyalty and Credit and Collections
10:00 - 10:50 A.M. Session A: Service Creation & Delivery: Innovation ≠ Anarchy: Improving Your Service Creation and Delivery Efficiency by Using a Process-Driven Framework
11:00 - 11:50 A.M. Plenary Session: It’s More than Acquisition and Retention. It’s about Experience!
12:00 - 6:15 P.M. Expo Hall Open
6:30 P.M. - 7:30 P.M. B/OSS Excellence Awards Ceremony
Day 3: Thursday, May 1 (actually I would skip this day)
9:00 - 9:50 A.M. Session D: Billing/Payment Processing: Billing and Customer Care Implications of Becoming a Fully Integrated Provider
10:00 - 10:50 A.M. Session A: Vendor Presentation: Extreme Transaction Processing (XTP): Revenue Management on Steroids
11:00 - 11:50 A.M. Session A: Vendor Presentation: Delivering Top Quality of Service and The Best Customer Experience with Next Generation OSS/BSS and SDP
12:00 - 1:00 P.M. Lunch in the Expo Hall
12:00 - 4:00 P.M. Expo Hall Open
As I said, I’m not attending, this was just an exercise to kill time (I’m a bit sniffy and sick at home). Wish there was some way of getting my hands on some presentations! Oh well, just wait for BIMS in Amsterdam, a bit more around the corner!
Something which is also pretty interesting are the Billing & OSS World 2008 Excellence Awards. The categories are:
- Best OSS Transformation
- Best Service Assurance Solution
- Best Service Fulfilment Solution
- Best Customer Loyalty Program
- Best Customer Care Solution
- Best Revenue Management Solution
- Best Billing Solution
- Best New Billing & OSS Product
I couldn’t find out who the nominees are, only that Highdeal was nominated for Best Revenue Management Solution.
Frens Jan Rumph
How far to go with standardisation?
I have been questioning myself about this for some time now, and it also came up at the ETIS Billing Workshop on IMS Billing: how far should standardisation go? To be more specific: how far should 3GPP go in standardising the charging architecture for the IMS?
As an engineer and a researcher I would almost immediately say: design until you drop! Since there is a problem to solve, and I want to solve it. But looking at the bigger picture, it’s arguable to stop at the Ro/Rf interfaces.
Lets take a look at our options:
1) Continue specification as it is done today:
2) Drop current specifications and restrict activities to Ro and Rf specifications:
3) ???
As I said, I have a strong desire to solve things and therefore to design solutions. But when I look at what 3GPP is currently making of the Rr reference point, well… frankly I don’t think it is of the same quality as the IETF Diameter Base and Credit Control specifications. The Rc reference point is currently not specified at all… So I am not sure if the industry will ever accept any of these standards. Which was supported by some comments made by vendors at the ETIS Billing Workshop I was at last week.
So again: how far should 3GPP go? Stop at the Ro and Rf interfaces and the specification of CDR data? Or specify the Rc (towards ABMF) and Rr (towards RF)? Or perhaps even go further into the delivery to cash process?
Something to think about (it will at least keep me from some hours of sleep)…
Frens Jan Rumph