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).
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.