About Service Models

A service model is a combination of service actions and atomic actions that may or may not be specific to vendor, technology, and software load.

When working with service models, see the following topics:

About Vendor, Technology, and Software Load-Specific Service Models
About Common Service Models
About Mixed Service Models

About Vendor, Technology, and Software Load-Specific Service Models

Vendor, technology, and software load-specific service models are provided out-of-the-box with delivered cartridges. Entities in the service model contain the vendor, technology, and software load tokens and there is a one-to-one relationship (or limited one-to-many relationship) between service actions and atomic actions.

Service models designed in this way enable upstream systems to directly access device-specific operations. Using out-of-the-box service model design preserves simplicity in the Oracle Communications ASAP service model and requires less service modeling work in ASAP. However, it also forces upstream systems, which are required to make selections of service actions based on the vendor, technology, and software loads being activated, to collate service actions together into meaningful work orders. Additionally, vendor equipment changes may create future maintenance.

Note:

When utilizing an out-of-the-box cartridge service model, consider consolidating service actions into meaningful building blocks to avoid pushing additional logic to upstream systems.

Consider the use of cartridge (vendor, technology, and software load-specific) service models when:

Services are implemented very differently across vendors (for example, use of preconfigured profiles vs. passing of raw parameters to a network element) or next generation services whose standards are evolving (multiple vendors at different phases of support for new technologies, for example, and who have different interface specifications).
One single type of vendor equipment is present in the network (for example, a specific vendor for HLRs, a specific vendor for voice mail) without future plans to introduce additional vendors into the network.
Atomic actions are technology oriented (for example, nail up a relay point) rather than service oriented (for example, add a subscriber).
Significant knowledge of the network infrastructure exists in upstream systems, such as Inventory.
Highly complex domains (IP-VPN, ATM) with homogeneous networks (for example, Cisco) are used.
Different activation steps (API calls) are required in order to activate the same services across different vendor equipment.

Lastly, if you have customer-specific parameter values that you want to expose to upstream systems, you can create new atomic actions with customer-specified atomic action parameters defined as defaults. This approach exposes only a subset of the cartridge atomic actions via the service actions. However, to use this variant you must create duplicate service actions and atomic actions with minor differences, which may create maintenance challenges.

About Common Service Models

Common service actions are most often associated with common atomic actions to create a consistently abstract service model (both service actions and atomic actions are common). In common service models one or more of the vendor, technology, and software load attributes are left out of the names of both service actions and atomic actions to indicate that they may be used to activate services on equipment from multiple vendors. ASAP has a built-in mechanism to map common atomic actions to a specific vendor, technology, and software load implementation based on the vendor, technology, and software load of the network element on which the service is being activated (see tbl_nep_asdl_prog for mapping details in the ASAP Cartridge Development Guide). For example, a common service action can add a subscriber regardless of whether it is a Nortel DMS 100 (POTS) or a Nortel CS2K (VoIP).

Common service actions map to one or more common atomic actions. The atomic actions map to multiple vendor, technology, and software load-specific implementations allowing for multiple technologies to be activated. The common atomic actions may simply be a renaming of the cartridge atomic actions to exclude one or more of the vendor, technology, software load attributes. In some cases, when a common service model is implemented in which many similar atomic actions across various network elements are required, the technology token must be maintained in the atomic actions to distinguish between the types technologies being activated.

Consider use of common service actions with common atomic actions when:

There exists a subscriber and service oriented domain where services are implemented uniformly across vendor equipment. Similar activation steps are used to activate similar services uniformly across different vendor equipment.
Changes may occur to the types of vendor equipment in the network or there is significant churn in the software loads. Limited change to the service model is desired despite changes to the network equipment.
Inventory systems containing information about the equipment in the network are not available, or little information about the network is stored in upstream systems.

Common Service Model Example

The following wireless example demonstrates how a GSM subscriber is activated on the authentication center (AUC), flexible number routing network element (FNR), voice mail server (VMS) and home location register (HLR). This service model can be implemented to support technologies from many different vendors (for example, Nokia AUC, Ericsson AUC, and so on):

C_ADD_GSM-SUBSCRIBER -->
A_AUC_ADD_SUB 
A_FNR_ADD_SUB 
A_VMS_ADD_SUB 
A_HLR_ADD_SUB

Common Service Model Challenges

Consider the following challenges when implementing a common service model:

Different activation steps are required even when implementing simple subscriber oriented features.
Significant parameter deltas can exist for similar services. For example, one service may require that you configure a subscriber by assigning a preconfigured profile to a subscriber on one network element (which is identified by its profile name); another may require that you configure a subscriber on a network element by passing all the details of the subscriber and services. In this case the atomic action parameters sets are dissimilar.

The following diagram shows an example of the some of the complications that can be involved in using a common service model even when the activating simple services. This example illustrates how to add a feature to a subscriber on an Ericsson HLR by first adding and then activating the feature (these are implemented as separate atomic actions); meanwhile, adding a feature on the Nortel HLR is a single atomic action. In order for a common service model to work in this case, you must configure spawning logic on the activate atomic action so that it does not execute when activating services on the Nortel HLR. The diagram also shows that PARM C is needed only when activating a service on the Nortel HLR. Therefore, it must be made optional so that a failure of the atomic action does not result when activating services on the Ericsson HLR (in which case PARM C will not be present on the work order).

Diagram is described in surrounding text.

Note:

While it is ideal to use a common service model, multiple service activation differences on different vendor equipment often result in increased maintenance, complicated spawning logic, and numerous atomic actions per service action if using this method. In such cases, consider implementing logic upstream to select the correct vendor, technology, and software load-specific service actions.

About Mixed Service Models

Mixed service models combine common service actions and vendor, technology, and software load-specific atomic actions, and should be used with discretion when implementing solutions. Common service actions map to multiple vendor, technology, and software load-specific atomic actions.

Consider the use of common service actions with vendor, technology, and software load-specific atomic actions when the same services are implemented differently across different vendor equipment (resulting in many optional atomic action parameters using a common model) and service actions must be agnostic to avoid exposing network specific details to upstream systems. This model requires that spawning logic spawn the correct atomic action.

Note:

When implementing solutions, discard from the cartridges those service actions and atomic actions that are not used. Include in your production environment only those service modeling entities that you intend to use. Unused actions are exposed through the OCA client during fallout management, and may create confusion and unnecessary overhead when starting and stopping the ASAP system.