Page 459 - Handbook of Modern Telecommunications

3-250 CRC Handbook of Modern Telecommunications, Second Edition

Service activation coordinates and executes the steps that need to be taken to enable, change, or dis-
able a service for a particular customer. The focus is on interfacing, communicating, and changing the
state of resources. Service activation needs to ensure atomicity of its actions—in the end, either the ser-
vice is fully activated or the activation fails and all resources are returned to their pre-activation state.
For complex services, the design of the service instance is done by a provisioning function; for ser-
vices that do not require significant planning for each instance, service activation is fully responsible for
providing the service.

3.10.4.4.2 Resource Lifecycle Support
When we look at the resource lifecycle aspects of fulfillment, we need to consider the functionality
required to support the resources independently of any specific service instance.
Resource change and configuration management deals with the required changes to maintain the
resources. The first responsibility is to configure the resources for preproduction testing and then for
production. However, change and configuration management needs to also deal with changes after the
resource is in production. These changes may come about because of engineering changes (e.g., upgrade
to a new version of the OS), they may be proactive measures (e.g., change the password on all routers), or
reactive measures (e.g., install a patch to resolve an incident or a problem). In all cases, change and config-
uration management needs to verify dependencies and conflicts on the change with the other resources.
While strictly speaking traffic and capacity engineering is part of change and configuration manage-
ment, it has very specific goals and operational processes to warrant considering it separately. Traffic and
capacity engineering has a goal of rebalancing how the resources are being used, without affecting the
services, to optimize the utilization of the resources. For example, it may reroute an Label Switched Path
(LSP) across a different route or change the weights in routing calculations to better balance throughput
or it may move applications to different/additional servers to improve response times.

3.10.4.4.3 Service Offer Lifecycle Support
Finally, looking at fulfillment from the perspective of the service offer lifecycle, we get to the functional-
ities required to deploy a new product into production. The clean and efficient handoff of a new service
from the service development team to the operations team becomes more critical as the product lifespan
shortens. Two functionalities are especially important.
Before a new product or service goes into production, it needs to be tested to ensure that it works
properly in a production environment. This production testing may involve friendly trails, establishing
performance baselines for the product, and generally validating that all operational and billing systems
can handle the new service.
The second aspect is actually rolling out the new service into production. If the new service is an
enhancement to or replacement for an existing service, production rollout will include making any nec-
essary changes to customers of the old service. Fortunately, some of the convergence aspects between
SDP, OSS, and BSS can facilitate the processes. By properly integrating the OSS with the SDP platform,
it becomes possible for the OSS to automatically discover new services that have been introduced into
the SDP and load that information into the OSS systems. This is why it is important to look at the service
offer lifecycle across all systems that are affected by it, and not just at the systems individually.

3.10.4.5 Assurance Functions
As with the fulfillment area, we can look to see how assurance supports the three lifecycles. We consider
these in a bottom–up manner, starting closest to the infrastructure. Figure 3.10.5 provides an overview
of assurance functions.
3.10.4.5.1 Resource Lifecycle Support
The resource lifecycle is addressed through what is traditionally known as domain management or,
using the TMN model, network and element management. Domain management focuses on ensuring