Open APIs

 View Only

Live Characteristic, Live attributes or Service test?

  • 1.  Live Characteristic, Live attributes or Service test?

    TM Forum Member
    Posted 15 days ago
    Hello,

    I'd like to jump in here, because we are a company that develops Diagnostic workflows, exactly in the way described above, taking a lot of more or less raw data and calculating a consequence by means of rules and/or AI. So far so good. Perhaps @Mike Joost you are perhaps talking about solvatio and mklick?

    A couple of days ago we have started an internal initiative to adopt our data retrieving interface (which is called SBBI) to the TMF Open API standard.
    And of course the very first apporach is, simply to go with the TMF653 Service Test Management API, no doubts about it.

    But, having a lot of experience with several kinds of retrieved data, I would say: Not every value is a "measured" one, not every value which I'd like to read out and to make valuations on is worth to do it with the rather complicate way of a metric definition etc.

    What might be the alternative? Here is a real example: Given a Transmission resource in a PON access network, which is something like Port and timeslot of an OLT, it could give me e.g. a good information about the perception of its partnered ONT on the Customer side of the Access network.
    Let's assume a Dying gasp alert. The data we are longing for is lastDownCause, lastDownTime, lastUpTime and lastDyingGaspTime.

    And here I come with my question: When we make a GET operation with TMF639 Resource inventory API, could we expect to have Characteristic values taken at real time, means calculated at this point in time when the GET operation is sent out? This idea would be similar to the attributes administrativeState and operationalState, of which I would also expect to be fresh-calculated as real-time information and not being static ones, isn't it?

    Such a Characteristic container would look like this BEFORE an ONT Dying gasp event:
    GET /tmf-api/resourceInventoryManagement/v4/resource/1234
    {
    "administrativeState": "locked",
    "operationalState": "enable",
    "resourceCharacteristic": [
    {
    "name": "lastOntDownCause",
    "valueType": "string",
    "value": "Reboot"
    },
    {
    "name": "lastOntDownTime",
    "valueType": "date",
    "value": "2022-07-21T13:45:40:127"
    },
    {
    "name": "lastOntDyingGaspTime",
    "valueType": "date",
    "value": ""
    },
    {
    "name": "lastOntUpTime",
    "valueType": "date",
    "value": "2022-07-22T05:35:40:271"
    }
    ]
    }

    And would look like this AFTER an ONT Dying gasp event:
    GET /tmf-api/resourceInventoryManagement/v4/resource/1234
    {
    "administrativeState": "locked",
    "operationalState": "disable",
    "resourceCharacteristic": [
    {
    "name": "lastOntDownCause",
    "valueType": "string",
    "value": "Dying gasp"
    },
    {
    "name": "lastOntDownTime",
    "valueType": "date",
    "value": "2022-07-23T23:14:20:27"
    },
    {
    "name": "lastOntDyingGaspTime",
    "valueType": "date",
    "value": "2022-07-23T23:14:20:27"
    },
    {
    "name": "lastOntUpTime",
    "valueType": "date",
    "value": "2022-07-22T05:35:40:271"
    }
    ]
    }


    Is this interpretation or use case of Characteristic values intended and reasonable?
    And yes, the third alternative is to have extended attributes with an individual Resource specification. When those are freshly, it might be welcome, too!
    Would look like this:
    GET /tmf-api/resourceInventoryManagement/v4/resource/1234
    {
    "administrativeState": "locked",
    "operationalState": "disable",
    "lastOntDownCause": "Dying gasp",
    "lastOntDownTime": "2022-07-23T23:14:20:27",
    "lastOntDyingGaspTime": "2022-07-23T23:14:20:27",
    "lastOntUpTime": "2022-07-22T05:35:40:271"
    }

    Thanks for sharing your opinions and your knowledge!​

    ------------------------------
    Frank Jörgens
    solvatio AG
    ------------------------------