-
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.
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
September 23rd, 2008 at 4:25 pm
You did find work here. I recently started to analyze Re interface and I can see your specification as a nice step to organize data exchanged on Re interface. My work is focused to analyze OCF side, but it makes little sense without RF implementing Re on the other side. Do you have any practical experience with actual implementation of RF?
September 23rd, 2008 at 4:50 pm
Thanks for your comment Tvrtko. I do in fact have some practical experience with Re and the Rating Function, although I must note that I work for a research institute from the Netherlands, and in that setting we perform research and do not produce software for production purposes. So my experience lies within the research and prototyping sphere.
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