Frameworx Application: Resource Inventory Management

Category: (1) TAM Application Type

Application Identifier: 7.2

Maturity Level: 4

Overview

Resource Inventory applications manage information of all resources used to implement services and products. This application area is typically linked to various element management systems (i.e. building inventory for actual server, applications,  network and resource assets) and resource inventory database systems which may or may not be combined with Service Inventory Application(s) or database(s). In addition, Resource management applications have a major role to play managing spare parts; passive resources including cable pairs and external plant and passive customer premises equipment.

In addition, Resource Inventory applications are used to discover and manage underutilized or ‘stranded’ resources.

Functionality

Resource Inventory Information Model – the assumption is that this feature implements the standardized information model for the resources to be managed. Typically, the service provider would need to add a lot of detail concerning the resource attributes that are to be managed. The specific details will depend on the particular resources (e.g., particular types of managed elements and equipment) and associated technologies (e.g., SONET/SDH, ATM and Ethernet) to be managed. The suggested approach for the service provider is to start with the TM Forum SID model and then define or make use of an existing model that specializes the SID model for the specific technologies that need to be managed.

Key Functions:

Accurately describes the state of resources (network elements and their components, IT systems and applications, resources defined within systems etc.). A critical aspect of this is the recording of what resources are consumed by service instances at the physical and technology layers.

Track status all resources

Database of all spares (Capacity Management and optionally interface to Asset Tracking)

Barcode/RFID tracking of all resources including spares

Resource Site Information

• Resource History tracking for all problems and returns

• Interacts with Resource Activation and Resource Provisioning

• Manages under-utilized or ‘stranded’ assets

• Resource Inventory Retrieval – this feature allows for client operations support (service assurance and billing systems) to retrieve part or all of the resource inventory known to the target OSS.

This feature may allow the following selection criteria:

• retrieval of a specified set of one or more sub-trees

• exclusion or inclusion of specified object types from the selected sub-tree

• further filtering based on attribute matching

• retrieval of only the object instances that have been modified after a provided date and time

• For the selected objects, this feature may allow the client operations support (service assurance and billing systems) to specify what specific attributes and relationships shall be returned. This (the attributes and relationships to be returned) would be the same for all objects of the same type.

• Resource Inventory Update Notifications – this feature entails the generation of inventory update notifications based on changes to the inventory known to a given OSS. The notifications concerning object creation, object deletion and attribute value changes to other systems.

• Single Entity Notifications – in this variation of the feature, each notification pertains to only one entity, e.g., an equipment instance

• Multi-entity Notifications – in this variation of the feature, a single notification may report on inventory changes for multiple entities.

• Notification Suppression – in this variation of the feature, each notification pertains to only one entity. However, in cases where a container object is created (e.g., a managed element) that has many contained objects, the sending OSS may only report on the container object creation. The expectation is that the receiving OSS will use a retrieval operation to obtain the contained object. This concept is explained further in TM Forum document SD2-1, MTOSI Implementation Statement (see Section 2.5.1, Publisher Notification Suppression).

• Resource Inventory Update – this feature entails an OSS requesting that another OSS (referred to as the target OSS) update its inventory based on a provided collection of updates. The expectation is that the target OS update its inventory as requested, but no other side-effects are expected (e.g., creating an SNC in the network). This is a key point concerning this capability. The inventory update request can involve addition (new object), modification (change to an existing object) or deletion (removal of an object).

• Resource Inventory Reconciliation – this feature entails an OSS reconciling its own inventory with inventory discovered from another source (typically, the network). When new inventory information is discovered, the OSS will try to match the newly discovered information with an entity or entities already known to the OSS

• If no match is found, the OSS will typically assume that a new entity has been discovered and add this to its inventory. Alternately, as decided by the service provider as part of their procedures, the OSS may record this event as an exception. For example, this may happen if the service provider always expects to have the planned inventory in their inventory OSS before actual resources are installed.

• If a match is found and there are no unexpected discrepancies, the OSS will update its inventory as needed.

• If a match is found and there are unexpected discrepancies, the OSS will typically raise an exception so that service provider personnel can correct the problem.

Supported Business Services

(1) TAM Application Type Resource Inventory Management

Appears on these diagrams:

• 7. Resource Management Domain
• Frameworx Application Diagram
• Mapping Index

Frameworx Processes (Automated TAM to eTOM)

• Manage Resource Inventory

Frameworx Domains (Horizontal)

• Resource Domain

---