-
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
AMS to the rescue?
I read an article yesterday titled AMS to the rescue, posted on VoiP Survivor. And to be honest, I was a bit shocked and puzzled. It talks about the Advanced Multimedia System which is currently being standardised by the ITU (in study group 16).
I was a bit shocked because the advances made by AMS (as described in the article) sounded like it would have a lot of overlap with the IP Multimedia System, which is being standardised for the last 8 years or so? Continuing to read the article I became a bit puzzled, since the article didn’t even mention the IMS, let alone making a comparision or describing their relationship. Furthermore, do we really need rescuing? Is this a signal from the ITU that we’re heading the wrong way with our current developments (e.g. the IMS)? This called for a little digging 
Some facts on the Advanced Multimedia System:
- It was formerly referred to as H.325.
- The goal of the AMS project is to create a new multimedia terminal and systems architecture that supports distributed and media rich collaboration environments.
- Presently, the project is in the requirements-gathering phase and is starting to look at possible architectures.
- AMS envisions an environment in which a user has many AMS-enabled devices including portable wireless, home entertainment and computer-based devices and is offered many applications and services that are either peer-to-peer or network-provided.
- AMS is viewed as the successor system to the legacy H.323 and SIP systems.
The objectives of the AMS project are:
- Improve the end user experience
- Enable innovative applications
- Enable mobility
- Enable multimedia
- Make it easy to use
- Improve productivity
- Ease application and service development
Some example applications of the AMS:
- Traditional voice and video
- Whiteboard
- File transfer
- Application sharing
- Text messaging
- Video streaming (e.g., IPTV)
- Gaming
- Multi-user data conferencing
- Streaming audio (e.g., “IP radio”)
The AMS project envisions the following components:
- “container” - This is the device that represents the user to the network (e.g., a desk phone, mobile phone, or softphone application)
- Application Protocol Entities (APEs) - These are the applications that register with the container to provide the user with voice, video, and data collaboration capabilities
- Service Nodes (SNs) - These are the network entities that enable the container to establish communication with a remote entity, facilitate NAT/FW traversal, and provide other network-based services
- Application Servers (AS) - These are elements in the network that provide various services, which might include IPTV,
My n cents on AMS:
- The focus of the AMS is more at the edge of the network then one would suspect when reading things such as ’AMS is viewed as the successor system to legacy H.323 and SIP systems.
- A lot of goals of the AMS project are in line with the goals of the IMS, and IMHO seek to build on the efforts put in the standardisation of the IMS by 3GPP. The project description describes that liasons should be made with IETF, ETSI (TISPAN), 3GPP, 3GPP2 and the IMTC, and that it should draw on the work of OASIS, MPEG, IETF, ISO and IEEE. Lets just hope they do! There’s no point in starting all over again!
- A lot of goals and the vision of the AMS project are in line with the Ambient Networks project, an EU FP6 research program, perhaps the ITU can learn from that research.
- The project specifies a lot of Work Items, but NONE on accounting, charging or billing! This would IMHO mean a big gap in the research performed! Unless of course the ITU envisions a world without money or is getting communistic on us
- I wonder how this relates to DLNA? I’m not an expert on that technology, but I have a hunch that there is a relationship here as well!
For further information ake look at this project overview presentation (pdf) from Packetizer, it provides a nice overview of the project. Or check out the AMS project description (pdf).
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
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
SIP on Android
Running SIP on the Android emulator?
Check out:
http://iconverged.wordpress.com/2008/03/10/we-have-sip-working-on-android/
Very good work from those guys, congratulations! They only have the signalling part running, but it’s a start!
This might mean that even though Google is basically an IMS anti-sponsor, that through support of people/companies like these Android phones will support IMS or at least SIP. Fits very well with the architecture of using Intents and Intent Receivers, just set this application to be the Intent Receiver of tel: and sip: uri’s with CALL and DIAL intents and you have a SIP/IMS phone!!! Isn’t that great!
Frens Jan Rumph