This week I stumbled across the Advanced Multimedia System (AMS) term and my immediate reaction was to think in a new buzz flavour of the IP Multimedia Subsystem (IMS). After a first look at the available documentation I recalled having seen some ITU H.XYZ activities over a year ago in the very recommendable ITU seminars. Indeed, they are more than related:
The Advanced Multimedia System (AMS) project was formerly referred to as “project H.325” (“H.323, SIP: is H.325 next?” the presentation I had seen a year ago) and aims at driving the development of a third generation multimedia terminal and system architectures able to support emerging, media rich applications that fall outside the bounds of traditional call-based communication platforms (sounds like IMS, doesn´t it?)
I spent some time going through the available material trying to understand what is behind AMS, and the TLDR version of it is something that 1) it may be confused with IMS and 2) it still in its very early infancy. The Advanced Multimedia System (AMS) is a new multimedia system project driven by the ITU in the requirements-gathering phase, see the formal project description. AMS is viewed as the successor system to the 12 year old legacy H.323 and SIP systems.
Googling a little more I came on a post from Radvision that confirmed my impression that there was no real connection between AMS and IMS (besides the unfortunate use of a similar acronym). Even more unfortunate considering the outcome from the Advances to IMS (A-IMS) initiative.
Frens Jan Rumph compared AMS and IMS in terms of charging and billing highlighting that IMS is a network designed to make money and AMS was to be designed for service provision around users. Users are empowered to coordinate its multimedia activities using the modes that best fit their personal/business situation and their needs or desires.
Rather than focusing on enabling multimedia telephony and “the fancy blended/bundled service you like” on top of IMS, AMS promises a user-centric environment with many AMS-enabled devices (portable wireless, home entertainment, computer-based devices) supporting (aka a container) many applications and services in either a peer-to-peer or network-provided fashion.
My understanding, rather than a replacement for IMS, AMS comes to fit something that was deliberately left out of 3GPP IMS specifications, the service and application layer. Of course there must be some new underlying system design that supports the AMS environment, but I guess AMS could be approached as currently done by Service Delivery Platforms (SDP) solutions, bridging “seamlessly” the legacy and the new generation networks based on IMS or whatever NGN control subsystem. Furthermore, given the timing differences and status of the recommendations, AMS is definitely not something to “care about” in the short or mid term.
AMS will define the procedures for application-to-application communication through the AMS-enabled network. The ITU study is expected to cover among others:
- Downloadable codecs
- System decomposition
- Discovery of services
- Support for transcoding functionality (e.g. text to speech)
- Dynamic device discovery
- Application plug in
- Consideration of various business models
- Integrated QoS, security and mobility functionality
The goal of the AMS project is to create a new multimedia terminal and systems architecture that supports distributed and media rich collaboration environments. The targeted applications include highly converged media applications involving multiple personal and public devices, enterprise systems and network services in support of communications, collaboration and entertainment. Specifications arising from this project will enable the development of the terminals and systems, and also inter-communication between systems so applications involving multiple devices and mobile systems can be supported.
How will AMSbe related to ongoing work in the Open Mobile Alliance (OMA), the organization tackling the IMS/NGN service environment standardization? And talking about standardization… there will be again the discussion on to standardize or not standardize (Industry standards vs. proprietary technologies). What does actually hamper or promote innovation? What makes real-world interoperability possible? De-facto standards? ITU-T is not famous because of its standards development agility, and with regard to services, the Web 2.0 lesson is that our days there is no time to stop and sit together to standardize Internet-based services and thereby loose time-to-market. There is just time to keep adopting the programming trends (WS, REST, ruby, …), define and reuse APIs as much as possible to reach scale in the Web mesh.
To conclude with, AMS is definitely something worth to keep an eye on, or may be some thing better, an opportunity to participate and contribute from almost the very first minute.
Comments and discussion very welcome!
Christian.
P.D: Timeline of AMS:
Past Milestones:
- CfR Issued: SG 16 WP2 Rapp. meeting, Biel, Switzerland, 17 – 20 May 2005
- Initial CfR Responses: Contributions into the SG 16 Meeting, Geneva, Switzerland, 26 July – 5 August 2005
- Workshop titled “H.323, SIP: is H.325 next?” (San Diego, 9-11 May 2006)
- Agreement in SG16 to create a new Question to study AMS (July 2007)
- Creation of the AMS project description (September 2007)
- Final approval of new Question 12/16 to develop AMS (June 2008)
Next Steps:
- Collection of requirements continues with architecture inputs expected, input contributions are requested for the next meetings
(Chapel Hill, 25 – 27 June 2008 and Geneva, 25-29 August 2008).
For submitting Contributions, see the instructions at the meeting website - Contributions into the SG 16 Meeting, Geneva, Switzerland, 27 January – 6 February 2009*
(deadline: 16 January 2009 to the TSB at tsbsg16@itu.int) - Completion (depends on input contributions) – 2010*
(*: Tentative dates)
Hi Christian,
Interesting post, but I want to set something straight. You refer to my post and indicate that I claim that the IMS is a control subsystem designed to make money. However this is absolutely not my view: the IMS is a network designed to enable a service provider / operator to deliver services to an end-user. But in it’s design it has not neglected the fact that most business models for providing services includes getting paid by some party (for instance the service consumer or a 3rd party in case of sponsorship). In my post I have indicated that charging and billing are topics that are currently not addressed in the research being and planned to be conducted by the ITU. Which I think they should, unless they come up with a business model that obsoletes the monetization of services.
Best regards,
Frens
Hi Frens!
Thanks for your feedback and clarification. May be a mis referenced you, but to my understanding IMS is a network architecture design to enable the delivery of new services (IP-based, multimedia, …), services which have to be monetized (flexible) to have a business case(s) besides OPEX reduction. So, to this extend, IMS is a control subsystem designed to make money…
I think ITU’s initiative is still in a very early phase to focus on charging and billing, however I agree with you that these topics should be covered in the requirements document.
Kind regards,
Christian.
Christian,
As you rightfully pointed out, AMS is H.325. The intention is to still publish the base architecture and system design specification as H.325. However, since ITU-T document numbers are not officially assigned until the document is ready for approval, we decided to use a working name just in case H.325 is not available later. The official name of the working study area is “Advanced multimedia system for NGN and future packet based networks,” so we used the name “AMS” and it stuck. (BTW, this name does not mean it will not work over the Internet—in fact I think that will be the first environment where it is used.) Personally, I would like to change it to avoid confusion, but perhaps doing that might cause even further confusion.
In any case, the people working on AMS are mixture of new people and some of the people who worked on H.323. Further, we definitely welcome input from even more people who have some great ideas about what a new multimedia system should do. I have been working in multimedia communication space for a very long time and I chair both the H.323 and AMS groups in the ITU. Our group in the ITU tries to make everything available for public review and comment: we did that with H.323, too. I generally publish everything (either directly or indirectly) on Packetizer (www.packetizer.com).
Discussion on AMS started a long time ago, actually. I think it was 2001 or 2002. However, folks did not want to do anything back then, because the telecom market was a mess and there was fear that introducing a new system would just make things worse. The atmosphere has changed now and there is a renewed interest in seeing something new. More importantly, there is an interest to deliver more power and flexibility.
The idea behind AMS is that of “hyperconnectivity”. As we go forward, there will be more and more IP-enabled devices. And, users should be able to use those various devices in order to have a much richer multimedia communication experience.
As an example, suppose you call me on my mobile phone and I want to share an application on my PC so you can see it. I want to be able to do that without taking extra steps to go to a conference server, enter a login and password, etc. You might want to send a file to me and, if it’s an MP3, perhaps I want to store it directly on my home network server so I can play it from my stereo. Perhaps we might want to play a video game over the Internet. We would like a consistent means of initiating all such forms of interaction, whether it is voice, video, app sharing, file transfer, video games, whiteboarding, or whatever.
Most importantly, we are trying to define an architecture that is flexible to the point where anybody can write an application and simply “register” with the “container” and then use it. While I have worked in the VoIP industry for years, I am very quick to tell people that I really do not care about “voice” too much. I got into this business, because I am interested in multimedia communications. I have personally been very disappointed with the results of everything we have done both with SIP and H.323. A telephone is a telephone and if that is all we can deliver, I am not very interested: my old PSTN phone was good enough, as far as a telephone goes.
So, the aim is to not replicate existing services, though of course there will be “voice over IP” and videoconferencing with this system, but we view “voice” as just one of many applications. The “voice” application would register with the “container” just like my electronic whiteboard, my file transfer app, my “Brand X” conferencing app, and everything else.
There is complexity with such a system, as you can imagine. But, by dividing functionality as we have, it actually makes it easier to develop any one part of the system. For example, one team can work on the “container” device completely independently of each of the applications. This also means that it is possible to create a new application and make it available without changing infrastructure in the network, including the “container.” (The “container” is, more or less, the user’s “phone.” But, we try avoid using that word, since there may or may not be a “voice” application on that device. The container could be a residential gateway, a simple data-only communication device, or whatever.) Also, it means that application complexity is kept in check. Essentially, an application is no more complicated than it has to be. Voice applications will advertise a set of codecs and those will be negotiated (much like what we can do with H.323 today), but the voice application only needs to worry about negotiating voice, not negotiating whiteboarding capabilities. Further, the container has the luxury of remaining entirely ignorant about any of the applications and how they work.
We just finished a meeting yesterday. During the meeting, we reached agreement to use XML for this new system. Personally, I think that’s going to be very cool. There is a huge amount of tool support for XML. We also had a person from the W3C attend who shared information on the Efficient XML Interchange (http://www.w3.org/XML/EXI/). In theory, this allows one to create a very compact binary representation of XML without losing the benefits of XML. We have to investigate this one further, but it looks promising.
In any case, if you are interested in knowing what is going on, I welcome you to join the various AMS mailing lists and feel free to send me questions directly.
Cheers!
Paul
[...] while ago, Paul E. Jones, the prophet of AMS, mentioned that AMS would use XML [...]
It seems to me that the focus of AMS is to have applications be able to send and receive data with one another. The communication should be done in a secure and reliable manner. Secure meaning that the communication is secure from point-to-point, and reliable in that message (data) delivery is guaranteed even in the presence of software and network failures. Reliable communication, or assured information delivery is becoming increasingly import especially with wireless connectivity becoming the norm. Additionally, depending on the end use, the communications will need the option of being auditable.
I would argue that AMS, or a project like this, would need to rely on digital agreements or electronic contracts, in which the terms and conditions used to govern the application-to-application communication/interaction is mutually agreed upon, and enforced by an intermediary or broker. The solution should allow the applications to interconnect and interact with one another, regardless of platform, network or location, while at the same time maintaining independence from each others’ internal processes.
At the firm I work at, we have been developing such a solution. Its architecture is based on open standards, but it is a proprietary system. I am a little unclear on your statement of “Industry standards vs. proprietary technologies”. Are you talking about open standards vs. proprietary standards, or open source vs. proprietary systems?
Hi Jason,
agree that a key building block in any new networking approach should involve powerful communication primitives with richer networking semantics in order to overcome the limitations of the point-to-point communication patterns.
Regarding security as you mention, reliability is a must, a point-to-point security approach may be ok. However, I am more attracted to a security approach centered on self-validating data, where integrity and trust derived from the data itself e.g., hash identifiers for data names and some sort of metadata enabling the self-authentication of the data, its fragmentation, and so on.
The future Internet is certainly calling for an enhanced (may be global) type of enterprise service bus (ESB) in the spirit of service oriented architectures (SOA) and infrastructures (SOI), event-driven architectures with the above mentioned characteristics and in line with what you mentioned with application brokers and application interconnection.
With regard to standards/technologies openness, as always, it depends. You are right about the differentiation between standards and systems. I am not an expert on all the legal aspects behind IPR, royalties and buying specifications for implementations and commercialization purposes. Standardization is nice, the process though is painful. On the other side proprietary solutions can get quicker in the market, the caveat is that extensions/optimizations and deployment are more limited.
I would like to see open source everywhere with win-win licensing models, I know it is not easy…
If you go the closed-source code and proprietary way then consider the importance of having rich APIs, rich in the sense of both programmers friendliness and access to a flexible set of functionality. Plus you are closing the door to let the system evolve with third party neat contributions…
I would also like to see the success of Web developers in future telco branded service development environments, but that´s another story.
Thanks for your comments and look forward to take a deeper look on your company’s solutions.
A brand new related essay from ACM computer reviews:
” Open Source: The Dark Horse of Software? ”
http://www.reviews.com/hottopic/hottopic_essay_09.cfm