Controlling complexity
29 January 2007
Telecoms Vision
Mobile communications is often about exploiting new or so far unexploited opportunities. One such is the service network. Here's a brief description of it: "a horizontal layer above the operator core network, allowing new telecom services and applications to be rapidly developed, tested and deployed independently from the underlying network infrastructure."
The speaker is Michael Crossey, vice president, marketing, of Aepona, provider of application-led products and expert services to telecommunications operators. More to the point, the company provides what it calls a Universal Service Platform that allows service creation and implementation to be carried out within the service network, independent from underlying network resources.
It is, of course, in the company's interest to promote such an approach but, one is bound to ask, if it really is so useful why has it taken this long for the service network's potential to be addressed?
The answer, not too surprisingly, is complexity. In recent years, specifications such as OSA/Parlay have emerged to provide a standardised way of abstracting the complex and arcane interfaces to telecoms networks into a common set of application programming interfaces (APIs). However, says Crossey, "the use of Parlay APIs still requires a degree of specialist telecoms knowledge, with the result that it has been used mainly as a common service framework within network operators, primarily to simplify service rollout across network boundaries such as those between the affiliate operating entities of a pan-national operator. The advent of the Parlay X standards, which define a set of telecom web services, provides a higher level of abstraction than Parlay APIs, opening up the telecoms network to a much broader community of developers."
And that brings us back to a much more comprehensible concept: the developer community. As Crossey points out: "Web services, and more specifically telecom web services, are a key component of the service network. Telecom web services, based on the Parlay X standards, are the means by which third-party application developers and enterprise customers can access the valuable resources of a telecoms network. Telecom web services utilise modern, commonly available IT development tools and techniques that are familiar to millions of developers worldwide. With telecom web services, no specialist telecoms knowledge is required to develop rich applications that utilise telecom network resources such as call control, location, presence and messaging. In addition, telecom web services use the same methods of publishing, discovery and usage that exist for the broader set of web services, meaning that access to them can scale to a global level."
From complexity to (relative) simplicity, then. But where does this leave IMS? In the longer term, will the service network complement or be replaced by IMS?
As the service network is a horizontal layer above the IMS control layer, and is therefore complementary to IMS, suggest Crossey, it gives operators the opportunity to evolve towards IMS at their own pace, without throwing away the investments they have made in current generation IN services; these can be kept in place and accessed from IMS as it is rolled out.
Crossey summarises thus: "Many IMS deployments will be service-driven rather than infrastructure-driven, and the service network allows operators to deploy next generation IMS-type services without upgrading their entire infrastructure to IMS at once."
It remains to be seen how complementary the service network/IMS relationship really will be as the pace of development picks up. Such a use of the service network is, however, a reminder of this industry's continuing ability to find opportunities in apparently highly specialised areas: to control complexity, if you like.
