IMS is a label that has started springing up all over the telecom industry, whether on individual products, or as vendor systems platforms or interoperability programs. It’s the acronym for IP Multimedia Subsystem, and it is very, very important – a big vision of the future of telecommunications hangs on it. It’s also very, very complicated and pretty abstract.
This tutorial aims to resolve some of that unfortunate conjunction by providing a quick and easy guide to some questions that are frequently asked about IMS. In the report's initial form, answers to a number of basic questions are given, one per page. But the idea is that readers can ask further questions on the message board attached to this article. If you want to send a private message, please email us, and include "IMS Guide" in the subject field. Frequently posed questions will be answered by adding pages to this report.
For a basic understanding of IMS, here are the key starting points:
IMS started as a technology for 3G mobile networks (under the auspices of the 3rd Generation Partnership Project (3GPP)), but it is now spreading to next-generation wireline networks and is going to be a key to fixed/mobile convergence. It builds on the Session Initiation Protocol (SIP), which has emerged as the crucial technology for controlling communications in IP-based next-generation networks (NGNs).
IMS is about services and applications, enabling telcos, mobile operators, and other service providers to offer rich multimedia services across both next-generation packet-switched and (within obvious limits) traditional circuit-switched networks. It is standards-based and uses open interfaces and functional components that can be assembled flexibly into hardware and software systems to support real-time interactive services and applications.
IMS will have a major impact on the telecom industry – including telcos, mobile operators, service providers, vendors, and others – because it will lead to new business models and opportunities, and (hopefully) lower costs through standards-based procurement. It simultaneously lets network owners derive added value from their networks, while opening these networks to third parties (including enterprise customers) to develop and offer enhanced and tailored services and applications of their own. The full exploitation of mass-market broadband will depend on it.
The basic set of standards for IMS implementation were released in 2004, and the first implementations are in hand or planned. Both the International Telecommunication Union (ITU) and the European Telecommunications Standards Institute (ETSI) are heavily involved, and IMS standards are still developing to fill in the inevitable gaps and to add new capabilities. However, IMS is still untested in real-life major carrier networks, and its widescale implementation is some years away.
Support for IMS even at this early stage in its development seems to be fairly hard-nosed, if the results of a poll taken during the Light Reading Webinar on which some of this report is based – IMS: A Blueprint for Fixed-Mobile Convergence – are typical:
Just over 40% of respondents thought that the most important catalyst for IMS deployment was the service providers’ need to create a more flexible environment for the deployment of applications.
18% thought it was service providers’ need to create a converged fixed and mobile network.
17% thought it was service providers’ need to deploy blended or combinational multimedia applications.
In other words, a large majority in favor of pragmatic flexibility, rather than any fancy and/or more futuristic possibilities.
Here's a hyperlinked list of the questions and answers in this report:
What Is IMS? A unified service architecture for all networks
“Most interestingly, the "Profile" schema is designed to hold "transparent" application data also associated with the Public ID used to identify the concerned party fopr any given request/dialog. In this sense, the "Profile" extends beyond the schema and application defined by the 3GPP into areas which overlap with the schema's for enablers like Presence, Group List Management and even other non-standard applications. The fine-grained access to these related Profile parts is not facilitated by any of the 3GPP application usages of DIAMETER, but is made possible through a combination of SIP and XML Configuration Access Protocol.”
Emphasis added above (bolding) is mine…
I remember a few carrier deployments of LDAP a number of years back wherein what the carrier was deciding should be in the schema was not completely able to support the application, in this case a large scale Voice Messaging application supporting the carrier’s residential customers – we are talking millions of users and many hundred’s of calls per second for the large scale deployment we were doing.
Case in point: user password. Should it be in the “directory” maintained by the HSS? Sure it should, customer support (ala OSS) is going to interact with user during a phone call for help when they forget that password and want it reset.
Should the application get the password from the HSS? Sure, but what about encryption of the password, i.e. stored in the “clear”; stored encrypted; and where is the type and logic surrounding the access methods? …
This detail could never get agreed to during the previous implementation discussions surrounding a carrier wide LDAP directory for services and I suspect it will not be agreed to during the “HSS acting as a broker” philosophy discussions in a pure IMS deployment.
End of the day? – a directory (in the past proprietary, today probably LDAP) local to the application to support a complete set of fields necessary to support the application (one such as Voice Messaging) while the subset of this set is maintained on the HSS. And for performance reasons in large deployments, this LDAP directory is probably in RAM with disk recovery features upon server failure. It may even have separate LDAP search mechanisms with cut-down directory sizes so that even “in RAM” searches can perform to the level that proprietary solutions can do today. In the old days, one might have called this index-sequential, but this is only a description at the macro level, since LDAP mechanisms must still be supported, if only to take advantage of the rest of the open-source paradigm.
In this way, hashing of the user password (or any other encryption method) could be implemented locally along with the logic resident in the application itself. There are other examples, of data that no one would want in the HSS, but they would, by definition be information on the user and should almost by definition be in the HSS.
At the end, implementation decisions around performance or usage will perhaps force this to be stored locally, in LDAP, and maintained there under application control, because it has to be accessed very quickly and/or it may not be used anywhere else except that application.
The part about horizontal scaling I don't quite get in IMS is how you scale the database.
The HSS is described by 3GPP as a "repository" for the authentication/authorization, initial Filter Criteria, registration stat ,location, etc. of a given Profile. There is nothing said about the implementation or operation of the HSS: only the schema for the profile and the protocol applications for read/update/subscribe/notify operations facing three logical clients: the CSCFs, IMSSF and OSA GW/SIP AS. It is a model for persistence in the network and may be implemented either as a database or as a "tier" in front of the data-of-record constituting the Profile. Moreover, the subscriber Location function is the "directory" of HSS instances (DIAMETER endpoints for interaction with the Profile). The I-CSCF locates the HSS "instance" (via interaction with the SLF instance it locates - there may be multimpe replicas of this "table" of profile/HSS relationships) which prevides access to the Profile in question and makes that data known to the S-CSCF at registration. Other applications may also locate hte HSS instance needed at any given time through the SLF.
The most important point is that the HSS may not be a database but may insead be though of as a "broker" between the control plane and the OSS systems that hold the data-of-record. The "cache" maintained by the HSS (if there is one; this would generally improve performance) may be thought of as a "unified repository" for the profile.
Most interrestingly, the "Profile" schema is designed to hold "transparent" application data also associated with the Public ID used to identify the concerned party fopr any given request/dialog. In this sense, the "Profile" extends beyond the schema and application defined by the 3GPP into areas which overlap with the schema's for enablers like Presence, Group List Management and even other non-standard applications. The fine-grained access to these related Profile parts is not facilitated by any of the 3GPP application usages of DIAMETER, but is made possible through a combination of SIP and XML Configuration Access Protocol.
This mechanism may be less performant than is required for basic AA functions, but is relaible, scalable, secure and is usable across domain boundaries, unlike the 3GPP Sh/Si/Cx reference points.
The part about horizontal scaling I don't quite get in IMS is how you scale the database. IMS defines a magic box called the HSS. This box holds not only nonvolatile user state but also presense and roaming information akin to the 2G cellular home location register. Whenever I see the picture drawn, I see one instance of an HSS. I don't understand how it scales since it needs to handle a jillion transactions per second. You can horizontally scale everything else in the architecture and dynamically bind to an instance of a box but I don't quite understand how the database scales. I don't think you can use a heirarchical scheme with caching like DNS since the dynamic state part of the data changes fairly frequently.
The term "Service Oriented Architecture" is currently used commonly in reference to a specific set of technologies typified by SOAP and WSDL/UDDI. In principle, however, the term referrs to "horizontalization" of system components on a network scale, and allows the network as a whole to implement "applications". It is another term for the concept of a compoent model for distributed systems, not too unlkie the vision behind CORBA and so forth. In that sense, and at that level of generalization, the IMS is also a service Oriented Architecture. In fact, the fundamental nature of the concept of a "Service Delivery Platform" is also about the persuit of a SOA for communication systems.
It is an odd thing to debate "SOA versus IMS".
In contemporary terms, I would describe the current state of affairs on both the IT and Telecom technology domains as paralell standardization of Service Oriented Architectures with the fundamental difference being that one (the IT side) is developing an "application-centric" vision of an SOA, while the IMS is inherently "user-centric". This diofference is visible at the most fundamental levels and is typified by the simple difference between SIP and HTTP addressing.
Central to the concept of the "user-centric SOA" is the related concept of the "Profile" as a system-wide model for persistence using a standardized set of schema. This allows application component instances to be seperated from the implementation of a given application at the level of the communication system as a whole. This approach moves the discussion of "service creation", for example, into the domain formerly termed "provisioning" and seperates the need for orchestration of system element interaction from the development of system elements as "applications" in isolation.
The blogs and comments are the opinions only of the writers and do not reflect the views of Light Reading. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Digg
Del.icio.us
Reddit
