Problem solve Get help with specific problems with your technologies, process and projects.

Service delivery platforms facilitate advanced service management

Network operators are dependent on the processes that support lifecycle management of cross-network services and their components. Service delivery platforms (SDPs) facilitate an advanced service management vision by offering APIs and protocols that connect to OSS/BSS, network equipment and other service resources.

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.

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

In a properly architected service layer, service logic and service management are two parallel and tightly coupled missions.

Tom Nolle
President, CIMI Corp

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.

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.

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, TMF and IPsphere Forum, and the publisher of Netwatcher, a journal in advanced telecommunications strategy issues. Check out his SearchTelecom.com networking blog, Uncommon Wisdom.

This was last published in August 2009

Dig Deeper on Telecom Resources

PRO+

Content

Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchNetworking

SearchDataCenter

SearchCloudComputing

SearchCloudProvider

Close