• 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

    View Frens Jan Rumph's profile on LinkedIn

    Frens Jan Rumph (image)

    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.

  • Meta

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

CDF / CGF: worth your money?

Openet announced on billingworld.com the release of their Charging Gateway based on their Future Works product. It is claimed to be 3GPP standards compliant. To me as a technician this sounds like a 3GPP CGF or a CDF+CGF implementation. My question is: is this worth your money?

Even though their product is probably a great product, but I’m wondering if mediation (because that’s just what it is) is going to exist in the future. Personally I see more in things like the Policy and Charging Control architecture in combination with an Online Charging System. It’s all about the Customer Experience (in which charging and billing play a big role) and Revenue Assurence. To me, old fashioned mediation (based on the CDF/CGF architecture for instance) does not fit in that vision.

Expect the next blog to be on Charging and Billing strategies for the IMS: conservative or progressive :)

BTW: I’ve heard vendors talk about ‘Active Mediation’ when they talk about their implementation of the Online Charging Function, but I wouldn’t see that as being mediation. That’s controlling a users session from a charging/billing/crm point of view. That’s a lot more then ‘just’ mediation.

Frens Jan Rumph

3GPP Release 8 Features

  1. Maintenance of TISPAN documentation
  2. FS on 3G Home NodeB
  3. FS on Multimedia Session Continuity
  4. FS on CS Domain Services over evolved PS access
  5. FS on Transferring of emergency call data – in-band modem solution
  6. FS on Improved network controlled mobility between LTE and 3GPP2/mobile WiMAX radio technologies
  7. FS on IMS Application Server Service Data Descriptions for AS interoperability
  8. FS Restoration Procedures
  9. Registration in Densely-populated area
  10. Lawful Interception in the 3GPP Rel-8
  11. IMS Enhancements for support of Packet Cable access
  12. Study on Non 3GPP access NSP
  13. Support of Service-Level Interworking for Messaging Services
  14. Feasibility Study of Mobility between 3GPP-WLAN Interworking and 3GPP Systems
  15. Study on Requirements for seamless roaming and service continuity between mobile and WLAN networks
  16. Study on Stage 2 aspects of IMS Service Brokering
  17. Study of Requirements of IP-Multimedia Subsystem (IMS) Convergent Multimedia Conferencing
  18. Study on support of a Public Warning System (PWS)
  19. Study of VCC support for Emergency Calls
  20. Study on centralized IMS services
  21. Study on centralised IMS service control
  22. Consumer protection against spam and malware
  23. 3G Long Term Evolution
  24. GERAN support for GERAN - 3G Long Term Evolution interworking
  25. Local Charging Zone Requirements
  26. Enhancements to BS30 Bearer service for Videotelephony
  27. IMS Enhancements Rel-8
  28. NDS Authentication Framework Extension for TLS
  29. Study on Value Added Services for Short Message Service
  30. Value Added Services for Short Message Service
  31. Study on Paging Permission with Access Control (PPAC)
  32. Paging Permission with Access Control
  33. GAN Enhancements
  34. Earthquake and Tsunami Warning System
  35. FS on Extended Support of IMS Emergency Calls
  36. Study on System enhancements for the use of IMS services in local breakout
  37. Study on Services Alignment and Migration
  38. Study on A-interface over IP
  39. Study on Multi-User Reusing-One-Slot
  40. Study on Optimized Transmit Pulse Shape for Downlink EGPRS2-B
  41. Study on InterWorking Function between MAP based and Diameter based interfaces
  42. Study on Evaluation of the inclusion of Path Loss Based Technology in the UTRAN
  43. LCS for 3GPP Interworking WLAN
  44. All-IP Network (AIPN)
  45. 3GPP System Architecture Evolution Specification
  46. CT aspects of System Architecture Evolution
  47. FBI Phase 2
  48. Rel-8 Feasibility Studies
  49. IMS Centralised Service Control
  50. IMS Multimedia Telephony and Supplementary Services
  51. MTSI Video - Dynamic Rate Adaptation/Signalling of Image Size
  52. eCall data transfer Phase 2: Comparison of alternative in-band modem solutions and standardization of one in-band modem solution
  53. Requirements and Test methods for Wideband Terminals
  54. Extending PSS and MBMS User Services for optimized Mobile TV
  55. IMS initiated and controlled PSS and MBMS User Service
  56. Storage and easy access of ICE numbers on USIM
  57. IP Interconnection of Services
  58. Network Selection for non-3GPP Access
  59. Charging for multi-phases services
  60. Home NodeB / eNodeB
  61. 3GPP2 Input to Common IMS
  62. Rel-8 Improvements of the Radio Interface
  63. OAM&P 8
  64. OAM&P Rel-8 Studies
  65. Study of Element Operations Systems Function (EOSF) definition
  66. Study on SA5 MTOSI XML Harmonization
  67. Study of Common Profile Storage (CPS) Framework of User Data for network services and management
  68. Study of Management for LTE and SAE
  69. Study on Charging Aspects of 3GPP System Evolution
  70. Study of System Maintenance by Itf-N
  71. Study of Self-Organizing Networks (SON) related OAM interfaces for Home NodeB
  72. Study on Self-healing of Self-Organizing Networks (SON)
  73. Personal Network Management (PNM)
  74. eCall Data Transfer – Requirements
  75. IMS System enhancements for corporate network access
  76. IMS Service Brokering enhancements
  77. Network Composition
  78. FS on Scope of future HSPA Evolution for 1.28Mcps TDD
  79. FS on Synchronised E-DCH for UTRA FDD
  80. Study on Dual-Cell HSDPA operation
  81. (FS on) Service continuity between mobile and WLAN networks
  82. I-WLAN NSP
  83. Interworking Wireless LAN Mobility
  84. Multimedia Priority Service
  85. Multimedia interworking between IMS and CS networks
  86. Conferencing enhancements for Mp interface
  87. Enhancements for VGCS Applications
  88. Contact Manager for 3GPP UICC applications (formerly “”Enhanced USIM Phonebook”")
  89. Charging Management small Enhancements
  90. Harmonization of Gq’/Rx for Common IMS
  91. IMS Service Continuity
  92. Interworking between User-to-User Signaling (UUS) and SIP
  93. Support of Overlap signalling
  94. OSA Rel-8
  95. Rel-8 RAN improvements
  96. Combination of 64QAM and MIMO for HSDPA (FDD)
  97. Security Enhancements for IMS
  98. Generic Bootstrapping Architecture Push Function
  99. Support of (G)MSC-S – (G)MSC-S Nc Interface based on the SIP-I protocol
  100. IMS Stage-3 IETF Protocol Alignment
  101. New multicarrier BTS class
  102. Support of Customised Alerting Tone Service
  103. Facilitating Machine to Machine Communication in GSM and UMTS (M2M)
  104. SI on AS-MRFC media server control protocol
  105. AS/MRFC stage 2 and 3 work
  106. (Small) Technical Enhancements and Improvements for Rel-8

Frens Jan Rumph