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)
The TIC! Blog 