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
------------------------------
Original Message:
Sent: May 09, 2022 09:54
From: Marc Landry
Subject: Valuation of Measurements from TMF653 (ServiceTestManagement)
Hello Mike,
I have been thinking about the exact same thing. To me the 653 spec does no look like it meets the requirements for "diagnostics". Being able to tell us if the collection (and/or) of atomic test results (pass/fail, up/down) in a brother context are good or bad. Meaning if testMeasure 2, 4 and 8 are out of bounds/bad, how does this affect the overall result of the test. What component is supposed to say: because you have these failures the overall test is a pass or fail. I do not see a way to add AND and OR clauses.
I only see Service Problem being responsible for orchestrating the test and diagnosis but not actually performing it. For me it feels like there is a missing diagnostic API that would include composite atomic tests managed by 653. This Diagnostic API would take the 653 result and apply some rules to detect what is the likely cause of the failed test and this can then be used in Service Problem for further orchestration.
Have you found a way forward? I am battling with the same question. I would be happy to contribute.
------------------------------
Marc Landry
Bell Canada
Original Message:
Sent: Apr 06, 2022 08:28
From: Mike Joost
Subject: Valuation of Measurements from TMF653 (ServiceTestManagement)
Hi everyone,
right now we implemented parts of the STM API regarding executing tests and delivering measurements back.
But now we have a usecase where we need to validate/rate the measurements of a test (like if measurement a is below 50 and measurement b is over 60 the service should be "ok").
Should this be implemented in STM aswell or would it make more sense to place it somewhere else (like ServiceProblemManagement) ?
Right now I think there are 3 options:
- just deliver the raw measurements and let SPM do the validation/rating
- deliver measurements (and adding threashold rules/violations) and SPM does the final summary/validation of the service status taking the violations into account
- add an additional measurement (like summary) and aggregate the "result" there in sth like "serviceStatus=ok" or "serviceStatus=not_ok"
Any ideas what the best solution could be?
------------------------------
Mike Joost
EWE TEL GmbH
------------------------------