-
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.
Evolutionary Innovation and Service Monetisation
Tsahi Levent-Levi posted an article on VoiP Survivor about the AMS and its (lack of) relation with the IMS. Furthermore he talks about the innovative nature of the AMS, expressing his hope that the AMS will not be based on stitching and patching of existing protocols. Finally he comments that: “There are those who believe that IMS is a network designed to make money, while AMS is a network designed to provide services to users”. I hope he doesn’t mean that I form part of the former group, although I’m afraid that …
AMS may possibly bring something new and fresh, I really like the focus on the service/application. Especially the idea of cooperation between end-user devices, the Jini vision comes alive again. As for the comparison between AMS and IMS, since AMS is still in its infancy it is indeed hard to compare the two. But they do overlap! And I think that therefore alone they should be compared, over and over and over. Too much money and time has been invested in SIP, XCAP and such that the overlap can not be ignored.
Also I have my fingers crossed that it stays really free of too much vendor influences. A completely academic standardisation probably wouldn’t be the best of ideas either, since a standard is for a big part meant for industrial use. A balance in this is required, in order for a standard to be successfully adopted.
As for the charging and billing stuff, it is perhaps not the sexiest thing to talk about. But if companies are investing in the development of new technology, and are putting large amounts of money in the day-to-day management and operations of services that are using that technology, someone will need to pay for that. The IP backbone and operator networks don’t run and power themselves. And phones and such still don’t grow of trees.
I’m not saying here that business models might not change, think for instance of sponsorship and such. I also think that a customer is certainly willing to pay for what he perceives as value (instead of distance times duration)!
Furthermore if technologies/networks/services are to be monetized, you should see charging, billing and settlement as an opportunity to further increase the customer experience! For instance: a customer is surely wont mind hearing that he/she received something for free, where he/she normally pays for. So why let him/her know at the end of the month on the bill, instead of immediately after or even during service usage!
To end my ramble on charging/billing: there are too many examples of projects where the order handling, provisioning, billing and other non-service customer-facing processes came last, but hugely impacted on the success of a product! Operators usually get more media attention when they screw up with their bills then when they run a cool new services.
Concluding: I applaud and follow with great anticipation any developments that push the state-of-the-art in new (multimedia) services! Be it research or industry standardisation. I however don’t expect a big-bang of mind-blowing unseen services and a customer value that has yet to be seen before.
Frens Jan Rumph
Ro Remaining-Balance AVP limitation
As I am currently doing a lot of research on IMS charging (online charging specifically), I am going through the 3GPP and IETF standards quite a lot. As critical engineer I usually tend to have some irritations or critiques. You’ll probably see me ‘venting’ this type of thing more often on this blog. Today’s irritation is a small limitation that I found the Ro specification. Well it’s actually just an opinion :). And perhaps I’m being just a bit picky, but why not go for perfection right?
The Remaining-Balance AVP can only occur once in a CCA. Furthermore, the assumption is made that balances can only be monetary. Is that all? Yes that’s all… But it is not consistent with the designs I expect for the counters managed by the Account Balance Management Function. Although the Rc reference point is not yet defined, the Re reference point specifications hints that a subscriber can have multiple balances/counters. This is hinted by the allowed occurrence of AVPs such as Counter, Counter-Price, Counter-Tariff and Impact-On-Counter. And it makes sense to me to have multiple balances! I need a monetary balance for pre-paid subscribers. But why shouldn’t we use the ABMF to manage things such as data quota’s, multimedia message quota’s, frequent caller bonus points, air-miles, and every thing else that can be counted for that matter! Of course this is still possible, only the OCS can never tell the UE about the current value of those balances through the Ro reference point. And all that can be fixed by adding an asterisk to the specifications 
Frens Jan Rumph
The ethics of standardisation and patents
I have recently discovered a European patent, and an US patent from Lucent Technologies, describing the functionality of the IMS Gateway Function (GWF). I have always found the IMS GWF construction a bit odd, and causing extra communication overhead.
The IMS GWF construction (as specified in 3GPP TS 32.260 and 3GPP TS 32.240) is shown in the figure below:
IMS Gateway Function
The ISC was the interface into the OCS for session based charging (connected to the Session Charging Function) in the deprecated 3GPP TS 32.200. This OCS architecture did not include an IMS GWF. The IMS GWF appeared in 3GPP TS 32.240 version 2.0.0. Unfortunately there are no change requests available for that version, so I don’t know who put it in. The funny thing is that the patent descriptions that I found were dated 15 November 2005 for the EU patent and 09 December 2005 for the US patent. But version 2.0.0 of 3GPP TS 32.240 v2.0.0 is dated 20 September 2004. I’m not sure what this means for the patents, my guess would be that it would count as prior art.
But still, the question is: are concepts required for the basic functioning of a standard allowed to be protected by a patent? I have had a number of discussions with colleagues on this topic, and its always a non-conclusive discussion. The good guy in me would immediately say: no. It completely goes into the idea of open standards. But from a financial perspective If any one can provide some arguments to tip me in either direction…
Regarding the IMS GWF: I hope that the existence of 32.240 v2.0.0 allows people to provide an IMS GWF without having to pay royalties to Lucent, and (more important for me) allows ‘free’ and ‘open’ innovation on the IMS GWF.
Frens Jan Rumph
HP and Amdocs claim IMS interoperability with legacy billing
Resulting from their joint efforts at the 4th IMS Forum’s plugfest, HP and Amdocs claim that they prove IMS interoperability with a Legacy Billing System.
The efforts by HP and Amdocs are indeed great steps that need to be taken in order for the IMS architecture to be successfully developed and brought to the industry. HP is even re-using this strategy toward other vendors as well. One of those vendors is Highdeal. They claim a ‘dramatic brakethrough’ in online charging. I do applaud these activities, as they strengthen the commercial viability of the IMS.
I do have some issues however with the claims. First of all, how legacy are the systems from Amdocs or Highdeal? It is claimed that Amdocs for instance communicates with HP through (at least some flavour) of diameter. Both products are top of the notch billing systems, and can hardly be called legacy!
Secondly, and even more important for me, is the question: what does this do to standardisation? I have raised the question earlier already in a previous post. This might make all the efforts put in the development of Online Charging System specifications useless. Is that a bad thing? I’m not sure, but one of the reasons for standardisation is to decrease vendor lock-in possibilities, so I’d say that this work should be continued. However if the industry is not adopting the standards… It would be nice to see HP, Amdocs, Highdeal and others to give back to 3GPP in the form of their protocols for communication towards rating and account balance management systems.
Source: HP and Amdocs claim (pdf)
Source: HP and Highdeal announcement
Frens Jan Rumph
3GPP Re extracted
I finished extracting the diameter specifications for the Re reference point some days ago. I’ve included my semi-proprietary ABNF specifications below.
Not as much work as the Ro reference point, but it took me a bit more time to get my head around it. Ro is pretty straightforward, a lot of it is thoroughly explained in IETF rfc 4006, and from the syntax specified in the 3GPP specs a lot of semantics can be pretty easily deduced.
Re however is a different story, the syntax is specified at an acceptable standard, but a lot of interpretation and even guessing is required to understand it fully. There are still semantics that I don’t feel 100% comfortable about.
An example: the relationship between the Monetary-Tariff AVP and the Counter-Tariff AVP. Does the existence of the Monetary-Tariff AVP mean that there can be only one monetary balance? Hopefully not, the existence of the Counter-Tariff AVP seems to indicate the opposite. However the Monetary-Tariff AVP is mandatory in the Service-Rating AVP, while the Counter-Tariff AVP is not. How should this be interpreted by an OCF?
Another example: I’m not really sure about how to interpret multiple occurrences of the Service-Rating AVP. That is most likely due to the fact that I am working on the concept of the Correlation Function a lot lately. The question is how to include the information from the correlation context … If this not done by include multiple Service-Rating AVP’s, then how? If it is done by including multiple Service-Rating AVP’s, then will all of them be rated? What will happen when using a “B”-class rating function?
Food for thought…
The Re specs (please note that the application and avp ids are To Be Determined):
PRQ ::= < Diameter Header: TBD, REQ, PXY, TBD >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
{ Actual-Time }
{ Subscription-Id }
* { Service-Rating }
PRS ::= < Diameter Header: TBD, PXY, TBD >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
* { Service-Rating }
TRQ ::= < Diameter Header: TBD, REQ, PXY, TBD >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
[ First-Request ]
[ Begin-Time ]
{ Actual-Time }
{ Subscription-Id }
* { Service-Rating }
TRS ::= < Diameter Header: TBD, PXY, TBD >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
* { Service-Rating }
SUQ ::= < Diameter Header: TBD, REQ, PXY, TBD >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
[ Destination-Host ]
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
[ Begin-Time ]
{ Actual-Time }
{ Subscription-Id }
* { Service-Rating }
SUS ::= < Diameter Header: TBD, PXY, TBD >
< Session-Id >
{ Origin-Host }
{ Origin-Realm }
[ Vendor-Specific-Application-Id ]
[ User-Name ]
[ Event-Timestamp ]
* { Service-Rating }
Counter ::= < AVP Header: TBD >
{ Counter-ID }
[ Counter-Value ]
[ Counter-Expiry-Date ]
Counter-Price ::= < AVP Header: TBD >
{ Counter-ID }
[ Counter-Type ]
[ Counter-Change ]
[ Set-Counter-To ]
[ Counter-Expiry-Date ]
Counter-Tariff ::= < AVP Header: TBD >
{ Counter-ID }
[ Counter-Type ]
[ Counter-Change-Per-Session ]
[ Counter-Change-Per-Consumed-Service-Unit ]
[ Counter-Change-For-First-Chargeable-Time-Unit ]
[ Counter-Change-Per-Subsequent-Chargeable-Time-Unit ]
[ Counter-Change-Per-Chargeable-Volume-Unit ]
[ Counter-Change-For-First-Chargeable-Time-Unit-After-Switch ]
[ Counter-Change-Per-Subsequent-Chargeable-Time-Unit-After-Switch ]
[ Counter-Change-Per-Chargeable-Volume-Unit-After-Switch ]
[ Counter-Threshold ]
[ Set-Counter-To ]
[ Counter-Expiry-Date ]
Destination-ID ::= < AVP Header: TBD >
{ Destination-ID-Type }
{ Destination-ID-Data }
Impact-On-Counter ::= < AVP Header: TBD >
{ Counter-ID }
[ Counter-Value-Begin ]
{ Counter-Value-Change }
[ Counter-Value-End ]
Monetary-Tariff ::= < AVP Header: TBD >
{ EParameter-E1 }
{ EParameter-E2 }
{ EParameter-E3 }
{ EParameter-E4 }
{ EParameter-E5 }
{ EParameter-E6 }
{ EParameter-E7 }
Monetary-Tariff-After-Valid-Units ::= < AVP Header: TBD >
{ EParameter-E1 }
{ EParameter-E2 }
{ EParameter-E3 }
{ EParameter-E4 }
{ EParameter-E5 }
{ EParameter-E6 }
{ EParameter-E7 }
Next-Monetary-Tariff ::= < AVP Header: TBD >
{ EParameter-E1 }
{ EParameter-E2 }
{ EParameter-E3 }
{ EParameter-E4 }
{ EParameter-E5 }
{ EParameter-E6 }
{ EParameter-E7 }
Extension ::= < AVP Header: TBD >
* [ AVP ]
Service-Rating ::= < AVP Header: TBD >
{ Service-Identifier }
* [ Destination-ID ]
[ Service-Information ]
[ Extension ]
[ Price ]
[ Billing-Info ]
[ Tariff-Switch-Time ]
{ Monetary-Tariff }
[ Next-Monetary-Tariff ]
[ Expiry-Time ]
[ Valid-Units ]
[ Monetary-Tariff-After-Valid-Units ]
* [ Counter ]
[ Basic-Price-Time-Stamp ]
[ Basic-Price ]
* [ Counter-Price ]
* [ Counter-Tariff ]
* [ Requested-Counter ]
[ Request-Sub-Type ]
[ Impact-On-Counter ]
[ Requested-Units ]
[ Consumed-Units ]
[ Consumed-Units-After-Tariff-Switch ]
[ Monetary-Quota ]
[ Minimal-Requested-Units ]
[ Allowed-Units ]
First-Request ::= < AVP Header: TBD > Enumerated (
SUBSEQUENT_REQUEST 0
FIRST_REQUEST 1
)
Request-Sub-Type ::= < AVP Header: TBD > Enumerated (
REQ_SUBTYPE_AOC 0
REQ_SUBTYPE_RESERVE 1
REQ_SUBTYPE_DEBIT 2
REQ_SUBTYPE_RELEASE 3
)
Destination-ID-Type ::= < AVP Header: TBD > Enumerated (
DESTINATION_NUMBER 0
DESTINATION_APN 1
DESTINATION_URL 2
DESTINATION_EMAILADDRESS 3
DESTINATION_PRIVATEID 4
)
Actual-Time ::= < AVP Header: TBD > Time
Allowed-Units ::= < AVP Header: TBD > Unsigned32
Basic-Price ::= < AVP Header: TBD > Unsigned32
Basic-Price-Time-Stamp ::= < AVP Header: TBD > Time
Begin-Time ::= < AVP Header: TBD > Time
Billing-Info ::= < AVP Header: TBD > UTF8String
Consumed-Units ::= < AVP Header: TBD > Unsigned32
Consumed-Units-After-Tariff-Switch ::= < AVP Header: TBD > Unsigned32
Counter-Change ::= < AVP Header: TBD > Integer32
Counter-Change-For-First-Chargeable-Time-Unit ::= < AVP Header: TBD > Integer32
Counter-Change-For-First-Chargeable-Time-Unit-After-Switch ::= < AVP Header: TBD > Integer32
Counter-Change-Per-Chargeable-Volume-Unit ::= < AVP Header: TBD > Integer32
Counter-Change-Per-Chargeable-Volume-Unit-After-Switch ::= < AVP Header: TBD > Integer32
Counter-Change-Per-Consumed-Service-Unit ::= < AVP Header: TBD > Integer32
Counter-Change-Per-Session ::= < AVP Header: TBD > Integer32
Counter-Change-Per-Subsequent-Chargeable-Time-Unit ::= < AVP Header: TBD > Integer32
Counter-Change-Per-Subsequent-Chargeable-Time-Unit-After-Switch ::= < AVP Header: TBD > Integer32
Counter-Expiry-Date ::= < AVP Header: TBD > Time
Counter-ID ::= < AVP Header: TBD > Unsigned32
Counter-Threshold ::= < AVP Header: TBD > Integer32
Counter-Type ::= < AVP Header: TBD > Unsigned32
Counter-Value ::= < AVP Header: TBD > Integer32
Counter-Value-Begin ::= < AVP Header: TBD > Integer32
Counter-Value-Change ::= < AVP Header: TBD > Integer32
Counter-Value-End ::= < AVP Header: TBD > Integer32
Destination-ID-Data ::= < AVP Header: TBD > UTF8String
EParameter-E1 ::= < AVP Header: TBD > Integer32
EParameter-E2 ::= < AVP Header: TBD > Integer32
EParameter-E3 ::= < AVP Header: TBD > Integer32
EParameter-E4 ::= < AVP Header: TBD > Integer32
EParameter-E5 ::= < AVP Header: TBD > Integer32
EParameter-E6 ::= < AVP Header: TBD > Integer32
EParameter-E7 ::= < AVP Header: TBD > Integer32
Expiry-Time ::= < AVP Header: TBD > Unsigned32
Minimal-Requested-Units ::= < AVP Header: TBD > Unsigned32
Monetary-Quota ::= < AVP Header: TBD > Unsigned32
Price ::= < AVP Header: TBD > Unsigned32
Requested-Counter ::= < AVP Header: TBD > Unsigned32
Requested-Units ::= < AVP Header: TBD > Unsigned32
Set-Counter-To ::= < AVP Header: TBD > Integer32
Tariff-Switch-Time ::= < AVP Header: TBD > Unsigned32
Valid-Units ::= < AVP Header: TBD > Unsigned32
Frens Jan Rumph