Editor's Note: This article is the first 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. In the coming weeks, author Tom Nolle will address the role of IMS and SOA, and symbiotic service models for the telecom service transformation.
With telecom service providers' revenue per bit falling at 50% or more per year, network operators are clearly being forced to consider expanding their repertoire of services to something beyond basic voice connectivity. The launching of the Internet as a consumer phenomenon in the 1990s demonstrated that non-voice services could be sold to the mass market, but it also created a framework whereby over-the-top players could exploit access and network infrastructure. Providers need some way to unlock the full value of their investment in the network and also expand into new and profitable applications and services.
Modern network design has morphed the old "Advanced Intelligent Network" voice model of interconnected switches into a three-layer structure:
- The network or data plane, which actually carries user traffic.
- The signaling plane, where service requests (including, but not limited to, connection requests) are made.
- The application plane, where software applications that provide service features and behaviors reside.
This modern structure can be seen in the way a VoIP application would be built today using SIP elements including the underlying IP network, session border controllers and SIP servers. In fact, any telecommunications service can be built on this model, but this is as ...
To continue reading for free, register below or login
To read more you must become a member of SearchTelecom.com
much a risk as a benefit. The value of service resources and the value of the knowledge of user behavior across multiple services, cannot be fully exploited if each service is an independent silo. Siloed services, even using modern architecture, also risk diluting the value of IP convergence by creating multiple independent application layers on top of a single IP infrastructure.
Creating a services ecosystem
Optimizing revenue means optimizing ARPU, and clearly that can't be done effectively without an ecosystemic view of services. A service set targeting a customer population has to be created by not only a single infrastructure but also a single set of application and signaling facilities, allowing service features to be composed from a set of tools available to any service, wireline or wireless, and targeting any customer need.
The industry has responded to this obvious requirement in two ways. First, the set of standards developed first for open mobile communications worldwide by the Third Generation Partnership Program (3GPP) was extended to include the IP Multimedia Subsystem (IMS). IMS has since been adopted by ETSI and the ITU and has also been extended to embrace not only mobile services but also fixed-mobile convergence (FMC) and even pure wireline services. Second, a set of software standards designed to create an open and flexible application structure, called service-oriented architecture (SOA), was developed to guide software development of all types.
IMS and SOA are sometimes viewed as competitive, but in fact, nearly all IMS implementations will use SOA, and many SOA applications for service providers will also include IMS. The two actually serve compatible, related, but not always congruent goals.
IMS defines a service architecture wherein a device set that obeys standard signaling principles can request services from any network, regardless of the identity of the network operator that has supplied the device, and have the proper billing and application security processes assured in fulfilling the request.
Without IMS, users would risk having advanced services not roam from location to location as mobile services do today. They might also have to provide billing information for any service request made out of the home network -- an obvious security risk. IMS also provides a standard way to link service requests to network resource requests so quality of service (QoS) can be assured, even when the service transits several different networks. Finally, IMS provides a standard way of linking signaling to applications to provide enhanced features, including content delivery.
SOA defines a software structure where functional elements ("services") can be invoked in a standardized way and thus can be composed into applications with a great deal of flexibility. New application features can be "discovered" from directories, and new services composed using simple tools and existing components. However, SOA does not ensure that all its "services" can be properly integrated into applications. Developers must still collaborate to use the correct interfaces and request the correct behaviors.
Whether a given service opportunity should be visualized as an SOA ecosystem, an IMS ecosystem, or a combination of the two will depend on a number of factors, including the target market, the service objectives, the existing service set and infrastructure, and the regulatory framework. The first step in service ecosystem planning is to assess these factors to set a broad approach. Remember that SOA will nearly always be used in IMS implementations at the application layer, so the primary question will be whether the ecosystem is built around SOA or around IMS, and then the extent and manner in which the other will be integrated.
IMS is strongly indicated as the core technology for the ecosystem if the service goals include the need to provide the services through multiple provider networks, either because of mobile roaming or FMC goals. IMS may also be very valuable as the core technology for services that will include "open" applications offered by third parties, because it includes facilities to validate these applications and control their behavior relative to both users and the network. IMS also offers direct billing integration for settlement.
SOA may be indicated as the core technology for the ecosystem that is substantially based on best-effort, Web-like delivery of information that does not require settlement with network partners, and where integration with billing and operations systems is not as important.
Remember that in all cases, SOA principles should be required in the development of applications, and in particular in the integration of software components from third parties or with other portions of the OSS/BSS software.
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, Telemanagement 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.
