TM Forum Community

 View Only

  • 1.  SID - Resource Inventory

    TM Forum Member
    Posted Dec 19, 2023 01:10
    Edited by Sanjay Vyas Dec 19, 2023 01:28

    Hello,

    We are evaluating the CSP OSS Inventory to fit into TMF Resource Inventory Data Model or any relevant TMF .

    Our requirement will be to convert Equipment Hierarchy to Resource standard along with attribute information .

    Please suggest the sample mapping to move forward as per TMF Data Modal (may be 639 only or any other )

    Equipment

    •  Shelf
      • Slot
        • Port

    Attributes:

    • Location
    • name
    • model
    • type
    • logical
    • etc


    #OpenDigitalArchitecture

    ------------------------------
    SV

    ------------------------------



  • 2.  RE: SID - Resource Inventory

    TM Forum Member
    Posted Dec 19, 2023 01:40

    Dear Sanjay,

    To commence the process, initiate the creation of a comprehensive collection of Resource Specifications (TMF634). These specifications will outline the Resources intended for instantiation within your Resource Inventory (TMF639), forming a solid foundation for efficient management and organization.



    ------------------------------
    Ragavi Ramasamy
    Halleyx Inc.
    ------------------------------

    Original Message


  • 3.  RE: SID - Resource Inventory

    TM Forum Member
    Posted Dec 20, 2023 05:54

    Expanding on Ragavi's response

    The resource inventory is catalog-driven (as Ragavi mentioned), and you can in principle model all your network resources dynamically so that your attributes become characteristics that are defined in the Resource Catalog.

    An alternative approach, briefly covered in the TMF634 introductory sections, is to create concrete subclasses for ResourceSpec and Resource, in which case your attributes become properties of the subclasses. So you might define a subclass Slot (and its definition SlotSpec), with the specific properties for a slot.

    Bear in mind that TMF Open APIs define (well) APIs, i.e. exposure contracts between consumer and provider. The APIs say nothing about how to model your catalog and inventory in their persistent layers.

    Good luck!



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------

    Original Message


  • 4.  RE: SID - Resource Inventory

    TM Forum Member
    Posted Dec 20, 2023 07:26

    @Sanjay Vyas asks about mapping equipment inventory to Open APIs.

    You'll want to understand the information model from which the source data model is derived.  For best results the process is to map from one information model to another (i.e. 3GPP NRM -> TM Forum SID) then with that established map the source data model to the target data model (i.e. TMF634, TMF639). The 3GPP Network Resource Model (NRM) example is described in IG1217.

    You specifically ask about equipment with shelves of cards.  This is discussed in GB922 Resource with the EquipmentHolder class.

    Now, as @Ragavi Ramasamy rightly says, you need to create Resource Specifications (TMF634) for the entities you will inventory with TMF639. Following your suggestion you might have matching specifications in your catalog with the associations represented in the resourceSpecRelationship attribute:

    [
       {
          "name": "MyEquipment",
          "@type": "PhysicalResourceSpecification",
          "vendor": "Acme",
          "model": "Alpha",
          "resourceSpecRelationship": [
              {
                  "name": "MyShelf",
                  "@type": "PhysicalResourceSpecification",
                  "relationshipType": "contains",
                  ...
              }
          ],
          ...
       },
       {
          "name": "MyShelf",
          "@type": "PhysicalResourceSpecification",
          "resourceSpecRelationship": [
              {
                  "name": "MySlot",
                  "@type": "PhysicalResourceSpecification",
                  "relationshipType": "contains",
                  ...
              }
          ],
          ...
       },
       {
          "name": "MySlot",
          "@type": "PhysicalResourceSpecification",
          "resourceSpecRelationship": [
              {
                  "name": "MyPort",
                  "@type": "PhysicalResourceSpecification",
                  "relationshipType": "contains",
                  ...
              }
          ],
          ...
       },
       {
          "name": "MyPort",
          "@type": "PhysicalResourceSpecification",
          ...
       }
    ]

    You will then have an item in your inventory for each of these entity types, for example:

     {
       "name": "MyEquipment",
       "@type": "PhysicalResource",
       "serialNumber": "1234567890",
       "place": {...},
       "resourceRelationship": [
          {
             "relationshipType": "contains",
             "resource": {...}
          }
       ],
       ...
    }

    The attributes you require are either mapped to existing attributes, add as polymorphic attributes, or implemented as Characteristics:

    • location: use the place attribute of Resource
    • name:  use the name attribute of Resource
    • model: use the model attribute of PhysicalResourceSpecification
    • type: use category attribute of ResourceSpecification or create a Characteristic
    • logical: create a Characteristic


    ------------------------------
    Vance Shipley
    SigScale
    ------------------------------

    Original Message