Servicedelivery platforms:Building thenext-gennetwork ...media.techtarget.com/Syndication/NETWORKING/... · architecture For next generation services to meet customer and carrier

Service deliveryplatforms: Buildingthe next-gen networkarchitectureFor next generation services to meet customer and carrier needs,network convergence is the technical goal while IP transformation isthe business goal. This E-Guide addresses the challenges of creatinga plan for service providers to achieve both of these goals at thesame time and lays out a service delivery platform (SDP) and SOAroadmap to recreate the network architecture.

Sponsored By:

E-Guide

http://www.alcatel-lucent.com

Table of Contents:

Service delivery platforms facilitate advanced service management

Advanced service creation requires new network model

Telecom operators need vendor help to justify new investment benefits

Resources from Alcatel-Lucent

Service deliveryplatforms: Buildingthe next-gen networkarchitecture

Page 2 of 12Sponsored by:

Service delivery platforms: Building the next-gen network architecture

Table of Contents

E-Guide

Service delivery platforms facilitate advanced servicemanagement

Tom Nolle, president, CIMI Corp.

Editor's Note: In this holistic SearchTelecom.com series, Service delivery platforms: Changing the networking

paradigm, telecom-industry consultant Tom Nolle looks at how SDPs fit into next-generation network architecture

and the business advantages they provide for carriers.

The development of advanced services deployment is based using service feature

components that can be assembled and orchestrated to create a flexible service model

via service delivery platforms (SDPs). The value of what is developed and how easily

it can be differentiated from over-the-top competitive offerings then depends on how

well the advanced services structure can be put into operation.

Operators value reliability and performance consistency -- which add up to Quality of

Service (QoS) -- and these are in part a function of the selection and deployment of

the best technology. They are also critically dependent on the management processes

for "lifecycle" support of the service and its components. Without service

management, there is no QoS, even if the network can support it.

Advanced services components include OSS/BSS

Service management is more than an "in-service" issue. The process of creating a service from components is an

element in service lifecycle management and thus is more a service management process than a part of the logic of

the service.

This view also makes it clear that simply creating a service by assembling pieces isn't enough to make the service

viable. The individual pieces and the structure that is assembled from them must also be managed and billed. How

this happens is a major focus of standards bodies worldwide.

Service components can be visualized either from the software side or the operations and business support systems

(OSS/BSS) side. In terms of software, service-oriented architecture (SOA) techniques and work in standards bodies

like the Object Management Group (OMG) are relevant to creating a model that can be interconnected to form a

cohesive piece of service logic. But this is more an issue of interface harmony and data models than one of actual

service-lifecycle management. For that, ongoing work by the TM Forum is the most relevant.

State-of-the-art service management standards

The current state of the art in service management standards is defined by TM Forum work by the IPsphere Team,

the Service Delivery Framework Team, and the NGOSS Contract. While these three work items are not complete,

they have advanced to the point where their relationship to SDP applications is clear.



Sponsored by: Page 3 of 12

“In a properlyarchitected servicelayer, service logicand service man-agement are twoparallel and tightlycoupled missions.”

Tom Nollepresident, CIMI

Corp.

The primary management question about any given service is whether it is managed in aggregate or by instance.

Generally, this question will be answered by the cost and value of the service. Low-value services like voice calls

would not normally be lifecycle-assured on a per-call basis, but higher-value services like movies or videos over IP

might be.

Where lifecycle processes must recognize each service instance, processes must be orchestrated by some contract

or virtual order representing each customer activation of the service. Where management is in aggregate, the

service resource pool itself is managed, rather than the individual services that might draw on that pool. Thus, the

components of a service may exist at the customer/contract level or only at the infrastructure level.

Using service components

The current management thinking is that a "contract" (for an aggregate or an instance of a service) might organize

the application/feature components of the service. It would act as an orchestration tool between OSS/BSS

processes and users, and the resources and applications that make up the service. By activating the contract, the

individual components of the service are activated in the proper order. So the contract forms a logical bridge

between service logic and service management.

Service components, in the modern vision, are objects -- the TM Forum SDF work calls them SDF Services while the

IPSF work calls them "Elements" -- that carry not only their own descriptions and behaviors but also their

commitments, such as service-level agreements (SLAs), and management requirements. Each component, in effect,

is self-managed, in that its use in a service carries the management objectives and methods associated with it. This

guarantees that when a complex service is assembled, the result can still be fully assured.

Service management must also be syndicated, in the sense that if a component of a service is provided by a

partner, there must be some mechanism to ensure that the component can still be managed by the service provider

that receives it. This can involve some level of management surveillance into partner infrastructure or simply a

contractual guarantee that the component will meet its SLA.

Enabling cross-network services

In a properly architected service layer, service logic and service management would be two parallel and tightly

coupled missions. Where service relationships are signaled, the signaling-invoked processes perform tasks very

much like service setup and service disconnect management functions.

Whenever resources are committed to a service or experience, resource assurance processes must be able to

sustain quality of experience, or the operator will have an unreasonably high level of complaints and customer care

incidents. The SDP principles that allow operators to build services also allow them to build lifecycle processes into

these services.




Service delivery platforms facilitate this service management vision by offering APIs and protocols that connect

both to management systems (OSS/BSS), network equipment and other service resources. In fact, SDPs can treat

management features and service features in the same way, allowing them to be composed into a service structure

and used as any real feature element of the service would be. This is a demonstration of the power of the software-

object structure that is the basis for nearly all modern SDP applications.




Advanced service creation requires new network modelTom Nolle, president, CIMI Corp.

Editor's Note: This holistic SearchTelecom.com series, Service delivery platforms: Changing the networking

paradigm, telecom-industry consultant Tom Nolle looks at how SDPs fit into next-generation network architecture

and the business advantages they provide for carriers.

Advanced service creation requires speed and agility. And a single difference between the

current networking marketplace and the markets of the past is in the relationship between

services and network infrastructure. This difference is the primary justification for a new model

of service creation and the increased reliance on service delivery platforms (SDPs).

To remain competitive, network operators must foster a new model of layered networks, one

that divides networks into a transport/connection layer, a service control layer, and an

applications and features layer.

In the past, networks were built around a service concept, and demand was typically developed

by deploying capabilities, then socializing their use. This is also known as the "build it and they

will come" approach. Because network services were deployed at their own speed, not in

response to market stimulus, the service delivery paradigms of the time fit well with the long

capital cycles of service providers.

Today, network services are deployed quickly to exploit specific forms of market behavior. Social networking is a

good example of this. If you can't enter a market quickly when the opportunity arises, there is little chance of

carving out a survivable niche. While the notion of service features hosted on networks is inherently more flexible

than the notion of service-specific networks, even hosted features don't go far enough toward providing flexibility,

agility and service velocity. Although hosting decouples services from network equipment, it can still leave silos of

incompatible, non-optimized service implementations.

Advanced service creation requires a different vision of layered networks, one that divides networks into a

transport/connection layer, a service control layer, and an applications and features layer.




“With advancedservice creation,

network resourcesand developers'

applications can becomposed into a

service model from"prefabricated"components”

Tom Nollepresident, CIMI

Corp.

Figure 1: The newvision of advancedservice creation

This structure was first introduced in the PSTN model of Advanced Intelligent Networks (AIN) and has been expand-

ed by work on the IP Multimedia Subsystem (IMS) and Next-Generation Network (NGN) by the 3rd Generation

Partnership Project (3GPP), European Telecommunications Standards Institute (ETSI) and the International

Telecommunication Union (ITU). Because SDPs must support both existing and evolving services, these models,

including AIN, IMS and NGN, must be explicitly supported by SDPs, as well as the emerging Internet-driven models

-- often called Web 2.0.

Advanced service creation must support four key elements

One of the key requirements for advanced service creation is support for the four fundamental elements of

communications services as a standard set of tools so these elements are not implemented multiple times and in

incompatible ways. This reduces the overall service deployment time through standardization and also makes it

easy to create services that share information about users across service boundaries. The fundamental elements

are:

1. Identity: A reliable way of knowing who a user is and linking the logical concept of a user to an entity

that can be authenticated to play a specific role (pick up a message) or receive a bill.

2. Presence: The status of a user across all of the services that user can exercise. This is a critical

element in deciding how to optimize service behavior to user practices. For example, should a given

incoming call be routed to voicemail without ringing, or should a given email result in an IM alert to the

user's cell phone?

3. Location: The place where a given user can be found at a given time. This is a critical element for

services that help users find things that are geographically nearby, but particularly for services that involve

finding the user, including emergency 911.

4. Demographics: Behavioral and characteristic data about users provides a clue to their commercial

behavior. For any services that relate to buying, selling or advertising, demographic information is critical.

Middleware connects service-creation hardware/software

While a service delivery platform should provide all four elements in some way, other essential tools bind together

the advanced service features and applications into services. In the SDP model of agile service creation, application

and transport/connection resources are linked to the SDP via middlewarethat can consist of both software

application program interfaces (APIs) and hardware protocols. The SDP provides the tools to support building

applications and features, then connects these components into functioning services. Similarly, the SDP provides

tools to exercise the standard interfaces being developed between transport/connection resources and services. An

example of this is the Resource Access Control Facility (RACF) defined in ITU NGN.

In advanced service creation, a service-control framework, normally based on some form of service signaling,

allows the user to commit network resources (or in voice terms, for example, to make a call) and activate special

service features (again using a voice example, invoke call forwarding). Signaling "events" (hitting a key combina-

tion) result in the activation of a software-hosted feature through a standard interface. In the call-forwarding

example, this might be the CAP/CAMEL protocol.




With advanced service creation, SDPs would be able to expose their applications/features via middleware in

response to a wide variety of signal stimuli, not just a combination of phone keys. Similarly, both applications/

features and service signaling could invoke transport/connection functions in a way that is both technology- and

vendor-independent. This flexibility means that the network's connection resources and developers' applications and

features can be composed into a service model at the service control layer to create a service from "prefabricated"

components.

Fitting applications into service control logic

Put into this context, applications like IPTV and IMS are examples of structured service control logic, a model that

is completely consistent with the way the ITU's NGN works interprets these applications. Because the IMS model

supports the same basic calling services as PSTN/AIN and provides a way to quickly expand the carrier voice

service features, it demonstrates the value of advanced service creation with legacy services.

The so-called "Web 2.0 applications" can also be created in a service control model. Service-oriented architecture

(SOA) principles can be based on a variety of technical models, including Web services and the Internet model of

Representational State Transfer (REST) that frames service and application components as URLs. Clicking on a URL

can generate a signaling event just like pressing a telephone key. In fact, both types of events can activate the

same features and behaviors in an advanced SDP implementation. This demonstrates that service-control

applications can coexist in parallel (something the ITU standards also affirm) and that tools to create service-layer

structures quickly can then be used to build services quickly as well.




Telecom operators need vendor help to justify new investmentbenefits

Tom Nolle, president, CIMI Corp.

For decades, the strength of the world's technology industry has come in large part from its ability to satisfy

people's natural yearning for order, logic and organization. Even though the average user of a network service or a

personal computer has no hope of understanding how it all works, they are comfortable with the value proposition

that led to the purchase. After all, you don't have to be an automotive

engineer to drive a car.

The telecom industry now faces a challenge that is part of a larger technology challenge: The

basic value proposition of networking is not as well understood as it has been in the past, which

means that those buying technology in general, and network equipment in particular, are having

more of a problem proving the benefits. Network operators call this a "monetization problem,"

and the macro-problem of network benefits for all and the micro-problem of benefits to

equipment buyers that justify the investment will be key to the recovery of telecom.

We all depend on voice communications, but despite all the hype to the contrary, building the

same level of dependence on something beyond voice has proved difficult. Dependence on the

Internet is the best that has been achieved, but so far that has been possible only through

precipitous drops in price-per-bit, which have contaminated the usual access/transport network

business case.

At the service level, where profits have always been strongest, nothing has replaced voice, and voice is in decline.

What you don't "need," you have to be "sold," and the need to merchandize communications has created the

current network operator fixation on third-party access and over-the-top partnerships. It's a good response, but it

doesn't provide a concrete roadmap to link whatever opportunity these relationships create with investment in the

network.

Vendor efforts to explain network investment value

Three vendors are apparently trying to take on the challenge. Alcatel-Lucent announced in early December that it

would refocus its strategy on dynamic service partnerships between the Web and telecom worlds. Cisco's chairman

and CEO John Chambers alluded to much the same thing with his Cscape™ event speech around the same time,

and Juniper now has Web 2.0 and monetization featured prominently on its homepage. The question now is

whether recognition of the need will translate into solutions to the problem.

Creating services that can be merchandized more than needed is an exercise in dynamism at all levels, starting of

course with the "storefront" that over-the-top partnerships and Web 2.0 can create. But to create flexible services,

you need composable service architectures that can mix and match feature components as needed to meet current

market needs and opportunities. Efforts to create that sort of architecture go back four years and have borne little

fruit so far.




“At the servicelevel, whereprofits havealways been

strongest, nothinghas replaced voice,

and voice is indecline.

”Tom Nolle

president, CIMICorp.

You also need a whole new vision of network operations. OSS/BSS processes have historically been focused on

fairly long-cycle activities. The way to make them work for something like voice calls was to manage the stuff in

aggregate. Will that work for thousands of unique services created through possibly tens of thousands of partner-

ships involving billions of customers? Nobody seems to think so, but again, efforts to bring some order to

operations chaos have fallen short.

The year of network operators' discontent

Network operators in 2009 want to make money building networks, and since building networks is the provenance

of network equipment, operators naturally look to equipment vendors. Service providers aren't liking what they

find. Every major operator we at CIMI Corp. surveyed put equipment vendor support for their monetization

paradigms in the "unsatisfactory" or "very unsatisfactory" categories. All this was before the current wave of vendor

interest, to be sure, but that wave has still not produced a tangible result.

Cisco's Chambers had the vision in his speech, and Cisco's Active Network Abstraction (ANA) is the most developed

of all the frameworks that could reasonably promise to link the pieces together. But the company seems to view

ANA as a "network management" offering, and as such, nothing but a tick on an RFP. There's no indication that

anyone at Cisco sees ANA as a path to meeting Chambers' challenge of mashing up services in the future, which

would make a connection a hard sell to buyers.

Juniper has the longest history with the problem set, perhaps; its "Infranet Initiative" posed the right questions four

years ago and (as the IPsphere Forum, now part of TMF) has made progress toward defining some of the pieces of

the solution. But no standards process in the world has ever been able to keep up with the market, and certainly

this one isn't doing that. There is no hope that a useful result can be achieved in 2009, when it will be needed the

most. Operators tell me that they don't expect standards to solve their problem anyway.

That would seem to leave things up to Alcatel-Lucent. But while it has the broadest product portfolio and the most

direct linkage to service-layer technology of any vendor (with IMS and IPTV), the company hasn't said anything yet

to indicate what it will do with those assets to meet its stated new strategic goals. Unlike the other two players,

Alcatel-Lucent doesn't seem to have a specific product foundation on which it could build, but it does have the

largest number of total pieces should it be able to create such a foundation. But Alcatel-Lucent, like the other

traditional telecom equipment vendors, is facing a broad set of market challenges. Can it meet this strategic one

with so many tactical issues creating diversions?

All the while, network operators are grappling with questions about what to invest in to secure revenue and profit

growth for themselves when, or even if, world economic conditions improve. Whether they get that from their

network vendors will probably depend on whether one or more of this group of three are prepared to step beyond

the standards, move faster than the market and take some risks. If that doesn't happen, I believe that the whole of

public networking will be transformed by a shift to metro-centric spending and bandwidth-commoditizing equipment

choices.




If that happens, ad spend couldn't supply more than a quarter of the capital budget of networks today. We have to

provide services that people will pay for if we want to fund the future of networking.

About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firmspecializing in telecommunications and data communications since 1982. He is a member of theIEEE, ACM and the IPsphere Forum, and the publisher of Netwatcher, a journal in advancedtelecommunications strategy issues. Tom is actively involved in LAN, MAN and WAN issues forboth enterprises and service providers and also provides technical consultation to equipmentvendors on standards, markets and emerging technologies. Check out his complete networkingblog.





• Services Access and Onboarding: The New Game for Network Providers

• Accelerated Process Development and Execution in Large IP Service and NetworkMigration Programs

• The Business Value of the Network Integrator

• Finding Value in Services: A Navigational Guide

• Alcatel-Lucent Services

About Alcatel-Lucent

Alcatel-Lucent (Euronext Paris and NYSE:ALU) provides solutions that enable service providers, enterprises and

governments worldwide, to deliver voice, data and video communications services to end-users. As a leader in

fixed, mobile and converged broadband access, carrier and enterprise IP technologies, applications, and services,

Alcatel-Lucent offers the end-to-end solutions that enable compelling communications services for people at home,

at work and on the move. With operations in more than 130 countries, Alcatel-Lucent is a local partner with global

reach. The company has the most experienced global services team in the industry, and one of the largest

research, technology and innovation organizations in the telecommunications industry with a portfolio of over

25,000 active patents spanning virtually every technology area.

www.alcatel-lucent.com




www.alcatel-lucent.com

http://www.alcatel-lucent.com

http://www.alcatel-lucent.com/wps/portal/Services

http://www.bitpipe.com/detail/RES/1247079978_831.html

http://www.bitpipe.com/detail/RES/1226742637_11.html

http://www.bitpipe.com/detail/RES/1238000393_812.html?psrc=RORG

http://www.bitpipe.com/detail/RES/1238000393_812.html?psrc=RORG

http://www.bitpipe.com/detail/RES/1238080155_539.html?psrc=SRS

Documents

Servicedelivery platforms:Building thenext-gennetwork ...media.techtarget.com/Syndication/NETWORKING/... · architecture For next generation services to meet customer and carrier