Editor's Note: This article is the second in a three-part series on the future of telecom services, with an emphasis on how service providers can position themselves to get the full value of their network investment, as well as how to roll out new services and applications that will increase their revenue. If you missed it, check out last week's expert advice, Building revenue-increasing telecom services for the future This week author Tom Nolle addresses the role of IMS and SOA in the telecom service provider ecosystem. The last piece in the series will address business models for the service ecosystem.
 |
|
|
|
|
SOA is about integration and reuse; IMS, about application security and control.
Tom Nolle
President, CIMI Corp.
|
|
|
|
|
|
|
|
|
|
If the future of advanced services lies in the flexibility, creativity and optimization of infrastructure and customer relationships, then the next question is how IP Multimedia Subsystem (IMS) and service-oriented architecture (SOA) can each contribute to this future. While the two concepts are compatible and even symbiotic, they are designed to solve somewhat different problems, and planners will need to focus their attention on the proper role of each and the timing of when each might be implemented. SOA is about integration and reuse; IMS about application security and control.
SOA maximizes software reuse
SOA is the broadest of the technology concepts, a sweeping architecture to make software components individually available as services. SOA maximizes software reuse and so is critical in ensuring that software investments are optimized. SOA is also the most reliable way to expose network features to third-party applications and to import information from third-party applications into network services. Finally, SOA is a critical element in the integration of service features with operations components.
The guidepost for planning SOA operations software usage is the TM Forum's enhanced Telecommunications Operations Map (eTOM), also accepted as a standard management architecture by the ITU. This map will illustrate the points where service features need to be linked to planning, provisioning and activation, and ongoing support functions. Most operators will want to plan out this operations dimension early in order to ensure compatibility with their business processes and also to ensure that any other service interactions are compatible with established operations principles.
The IMS service behavior mission
In the context of eTOM, IMS is a platform architecture that supports a service delivery framework. There is active work in TMF on the relationship between SDF elements and eTOM elements, but no final specifications are available at this time. Still, this work offers strong guidance on how to visualize the role of software that creates service features and behaviors (the IMS mission) and software that creates the business framework for service sales and support (the eTOM mission).
Both eTOM and the IMS/SDF framework will use SOA to integrate within their own software elements, and with external software components. The most significant pieces of this integration puzzle are likely to be the relationships among services and between the network operator and third parties that are either obtaining network access and features through a partner program offered by the operator, or supplying their own information or features to the network operator. Each of these interfaces requires special attention.
Where the network operator exposes an API to developers or partners, SOA can provide the necessary security and authentication to ensure that the interface is not hacked. It will still be essential to plan the type of SOA service exposed to the partner to make sure that it meets market needs and is reasonably easy to integrate into the partner's applications. It is also important to ensure that the interface has some form of "cut-out" to prevent the operator's software from being overloaded by an excessive number of partner requests, whether through a software error or an unanticipated load.
The international standards Parlay X and Parlay OSA, based on an SOA interface, are a good starting point for defining these interfaces. It's also essential that requests for features or resources made through the interface be integrated with the OSS processes so they can be assured and billed properly.
Where a network operator obtains external features, similar access journaling will be required for settlement, but here the issue is ensuring the stability of the network operator's service. That means careful editing of parameters that are obtained from the outside.
SOA by itself offers no specific service interface to users; it is customary to build such an interface as part of the application. Similarly, SOA offers no service signaling mediation, so there is no protection or accounting for service requests available in a standard way. IMS provides both of these facilities, as well as a mechanism to control the number of service requests (admission control) and the service quality (resource control). IMS assumes that a call-like process using the SIP protocol will activate a relationship between a consumer/user and an application. That application can then create connection-based services or offer a portal to other experiences and services using Web-like tools, SMS, MMS, and so on.
Where resource control, admission control, or application signaling control is a requirement, IMS should be viewed as the strategy of choice. A carefully planned IMS installation need not provide all of these controls, but the ability to exercise them is available if the service requirements evolve to create the need.
In theory, it is possible to build an IMS application platform that supports nothing more than a SIP request to be linked to a service portal, and then to use SOA tools to develop the remainder of the service along Web 2.0 lines. This approach has the advantage of allowing IMS admission and resource control to be used to gate users and resources in order to prevent congestion and the service outages resulting from it.
IMS can be highly flexible with respect to the relationship between its signaling elements and the SIP protocol, and the applications and services that are offered. It is not necessarily true that every "service" needs an independent session, only that every customer relationship be based on at least one such session. Even that requirement could be avoided for some applications and with some restrictions. Planners should evaluate the way in which prospective IMS suppliers handle non-session behaviors to determine the full range of applications and services that IMS could be used to support.
A final IMS benefit is OSS/BSS integration, and these facilities will also depend on the IMS supplier. Many offer APIs and links to OSS/BSS processes as a part of the IMS deployment. If this is the case, it can greatly simplify the relationship between service applications and OSS/BSS systems. In addition, the HSS/HLR of IMS is a repository for subscriber information that can be linked to any service via the proper application and API, and extensions to the database can support a variety of applications, including ad targeting to mobile users.
SOA and IMS have a highly complementary set of missions, and many network operators will find both essential in future service plans. The primary question may be the priority of deployment and the early service targets, and these relate to the business model that drives the service deployment.
About the Author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM, TM Forum, and the IPsphere Forum, and the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues for both enterprises and service providers and also provides technical consultation to equipment vendors on standards, markets and emerging technologies. Check out his SearchTelecom networking blog Uncommon Wisdom.
