Open APIs

 View Only
  • 1.  TMF702/TMF639 and Network Data Quality issues

    TM Forum Member
    Posted Jan 27, 2023 10:50
    Hello,

    I'm working on the implementation of the Assurance processes (data collection, data quality issues detection & correction, etc), and in that scope I'm trying to determine what is the best way to use the APIs to manage misalignment between the Network and the Resource Inventory.

    A typical scenario is when we have some configuration remaining in a equipment, while having nothing documented in the Resource inventory.

    How would you see this situation reflected in terms of calls towards TMF702 & TMF639 APIs ?

    Should TMF702 always return the current state of the Network (that could be obtain via a FIND), and by comparing TMF702 & TMF639 responses we could determine there is a Data Quality issue ?
    And if so, what kind of id should be returned in the response of the TMF702, considering it can't be linked to a TMF639 Resource because of the DQ?

    Thanks for your help.

    ------------------------------
    Jean-Christophe Nicolay
    Proximus SA
    ------------------------------


  • 2.  RE: TMF702/TMF639 and Network Data Quality issues

    TM Forum Member
    Posted Jan 29, 2023 09:44
    Hi Jean-Christophe
    First, your point about the IDs of network resources is a very good one, and I don't think that we have fully considered its implications in the API team. This is so even without data quality problems. When you POST directly to the network (TMF702), what ID is returned? And how does that ID correlate to the corresponding ID in the inventory (TMF639). I plan to open a JIRA issue to highlight this (and similarly for Service - TMF640 vs TMF638).

    Regarding data quality detection, you would need to invest in some reconciliation software, either built in-house or commercially (Amdocs has such software and I'm sure other vendors also have similar offerings). Given that you cannot necessarily rely on ID correlation you would need to use some other criteria, e.g. related party, to compare the actual network with the inventory. All this assumes, by the way, that you can retrieve data from the network. If your network is write-only :) then you may have problems :( .

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



  • 3.  RE: TMF702/TMF639 and Network Data Quality issues

    TM Forum Member
    Posted Feb 01, 2023 05:51
    Edited by Jean-Christophe Nicolay Feb 01, 2023 05:51
    Thanks for your response Jonathan.

    The ID issue is indeed an important point to consider, but from a more general point of view, what do you think would be the best API to expose the Network ?
    Should it be considered as Resources exposed via a TMF702, or a more generic Entity approched with the new (BETA) TMF703 for example ?

    When checking what entities are defined in the SID, we were also considering using the Resource Performance ABE (at least for operational data and performance counters that are not necessarily modelled in our Resource model), but as far as I can tell is not yet existing as an OpenAPI.



    ------------------------------
    Jean-Christophe Nicolay
    Proximus SA
    ------------------------------



  • 4.  RE: TMF702/TMF639 and Network Data Quality issues

    TM Forum Member
    Posted Feb 02, 2023 02:28
    The network would be exposed by Services (TMF638) and Resources (TMF702), which would presumably include logical, physical, and virtual (NFV) resources.
    I'm not sure what would be the scope of an Entity inventory (TMF703), it could conceivably be "anything" of interest to the service provider.
    Be aware that there is also a Topology Discovery API in preparation, @Yuval Stein or @Dave Milham could perhaps give more details.
    Hope it helps​​​

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



  • 5.  RE: TMF702/TMF639 and Network Data Quality issues

    TM Forum Member
    Posted Feb 03, 2023 03:12
    The network resides entirely within the Resource domain and so is managed with TMF634, TMF639, TMF664. TMF702 and TMF652.

    The Service domain contains the customer facing services (CFS) which go into Product Offerings. This is, done properly, an abstraction of the capabilities realized in the many technology specific subdomains of the Resource domain. Resource facing services (RFS) may exist in the Service domain which are technology specific bridges to the Resource domain.  While this is the transitional way of doing things a more functionally pure approach eliminates RFS and instead includes Resource Functions (RF) from the Resource domain in CFS.

    Everyone struggles with the distinction between Service and Network Service (NS).  The former is something which goes into products while the latter is represented by an RF within the Resource domain. For example a 5GC Network Slice is an RF and as such is managed in the Resource domain (i.e. TMF664). If a CSP elects to sell Network-Slice-as-a-Service you may also have a CFS for NSaaS. An simpler example would be DNS (domain name service) which is a common NS provided and consumed within the Resource domain. Again, a CSP could offer DNSaaS with a CFS.

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