The mission of a new collection of tools called the service layer architecture combines the telecom business model...
with the over-the-top (OTT) innovation model. Here the network's "services" -- which connect users and transport traffic -- are combined with customer identity and presence information and application tools to create a wide range of new experiences, including retail purchasing, finding restaurants, getting directions, delivering custom content and more.
100% [of operators surveyed] said they want a single service-layer architecture strategy that cuts across fixed and mobile services.
President, CIMI Corp.
How did this service layer architecture develop? For years, people have been saying that network operators need to move higher on the OSI stack, get into new services and offer the kind of innovation that OTT players like Google have provided. Telecom operators themselves agree with this, and they have agreed all along.
The issue is that there is a major difference between offering best-effort, ad-sponsored services on the Internet and building stable, profitable network services that customers expect will be supported like all previous carrier services.
What kind of services this service layer architecture will create remains unknown; the market will answer that question over time. How those services will be created within the service layer is unclear, too. Network operators have traditionally turned to equipment vendors to answer that question.
The big four: What operators need from service layer architecture
How to create the service layer may not be clear, but operators already know what they need from it. Their expectations, which have been developing over the last several years, will be the standard for judging service layer architecture offerings that vendors have already started to roll out. Operators' service layer requirements will be announced and revised over the next several years, but at this point, they can be summed up as follows:
- Ecosystem support
- Modular "orchestrated" components
- Differentiation in OTT services
- Vendor support
Requirement 1: Support ecosystem of service layer stakeholders
A recent CIMI Corporation survey of 44 network operators worldwide, including 10 Tier 1 providers, revealed that every single operator expected their service layer technology to host applications supplied by their own development processes, by third-party developers, by equipment and software vendors, and by OTT players like Google and Yahoo. Their vision is not for a one-off set of service layer architecture solutions to current market problems, because that process could never move at market speed. They know they need partners of many types to successfully deliver next-generation services. They want service layer architecture to support an ecosystem of stakeholders of all types, and they expect it to provide for an exchange of technology and revenue among those players.
The practical assumption of the ecosystem requirement is that service layer technology will be a kind of middleware or Platform as a Service (PaaS) that exposes tools and features in the form of well-defined application program interfaces (APIs). Operator personnel and various partner organizations would link their applications, features, content and capabilities to the network through these APIs and build services that would then combine the operator's connectivity and service features with these contributions. The operators expect to control which features are exposed through these interfaces and the nature of the partner relationship to suit their own business and regulatory constraints.
The survey results pointed to a critical point concerning the ecosystem requirement: Among operators with both wireline and wireless service infrastructure, 100% said they want a single service-layer strategy that cuts across fixed and mobile services. While fixed-mobile convergence (FMC) is part of the reason, the largest driver for this requirement is the conviction among operators that service-layer issues like identity, advertising, presence and location are universal and should be addressed only once for all classes of service. Mobile requirements are expected to develop first, though. More than 75% of operators said they believe wireline service-layer technology strategies will develop from early mobile service-layer deployments.
Requirement #2: Orchestrate modular service layer architecture components
More than 90% of operators in the survey indicated that they expect their service layer architecture to be orchestrated -- meaning services would be constructed from a set of modular components that could be assembled in various ways to create different experiences. This modular style of building services contrasts with the monolithic service structure of the past, and operators believe change is mandatory if they are to keep up with the accelerating pace of innovation in the marketplace.
The orchestration of components into services simplifies and speeds development, thus attracting partner support. It also helps guarantee stability by preventing multiple implementations of fundamentally the same capabilities that could collide in the network with serious results.
Just over two-thirds of operators said they believe that network management and service assurance functions in the new services had to be orchestrated into the service logic itself, not added on as an afterthought. It's been industry practice to view "network management" or "service management" as a kind of orthogonal layer -- vertically cutting across all the horizontal functional layers of networking. New services need their management capabilities built in. Only integrated management ensures that the lifecycle processes of network operators can be applied to partner-facilitated or even partner-created services. Network and services management is the key to creating operations economies of scale critical for future mass market services.
Requirement #3: Differentiate from OTT services
The Internet has created a platform for new services that competes with any operator-deployed service layer, and that leads to the next requirement. The service layer must be differentiated from OTT services development to attract partners and create services that can compete effectively against OTT alternatives.
While all operators surveyed agreed on the differentiation requirement, they defined it in several ways, citing service quality and availability as one way of achieving it, integration with traditional telecom services as another, customer support and billing a third, and security and identity integration a fourth.
The need for differentiation collides with traditional provider reliance on formal standards, and operators reported mixed views on how to resolve that conflict. Some believe that "standards provide a way of securing proposals for equipment and tools from multiple vendors" and thus assure good pricing and support. They noted, however, that standards don't help address new opportunities because of how long it takes to set them, which operators say is getting worse over time.
Other operators said they believe it should be possible to quickly identify or set some high-level standards to insure interoperability among service layer elements and between network operators/partners services. Even so, none of the operators reported believing that a service layer architecture solution can wait for full standardization, and most do not think full standards are needed in the service layer. They fear too much standardization will limit differentiation by curbing their ability to customize their own service layer.
Requirement #4: Service layer architecture support requires vendor commitment
The supported requirement is two-dimensional. Operators said they believe an ad-sponsored model of services is not sufficient to sustain the various new services the market will demand. The various for-pay models all have some expectation of Quality of Service, as well as an expectation of customer support. The service layer must meet this support requirement as effectively as past traditional services have done. But operators also want a vendor -- not multiple vendors, but one vendor -- to stand behind their service layer commitments with professional services during the installation/integration phase and into ongoing operations.
As a final point, operators said they were generally unhappy with the way service layer tools are explained. They believe their business goals are clear, and yet the descriptions of vendors' offerings seem disconnected from those needs. Building a favorable consensus on service layer strategy among network operators is possible only through the presence of tools that meet operators' requirements and are described in a way that can be discussed and socialized by operators to support service layer project approval.
About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is the publisher of Netwatcher, a journal addressing advanced telecommunications strategy issues. Check out his SearchTelecom.com networking blog Uncommon Wisdom.