Open APIs

Expand all | Collapse all

TMF656 Parent/Underlying Problem explanation

  • 1.  TMF656 Parent/Underlying Problem explanation

    Posted Apr 12, 2021 15:49
    Hi, can someone explain what constitutes a Parent or Underlying Service problem, preferably with an example.


    Wayne Sampson
    CGI Info Systems Management Consulting Inc.

  • 2.  RE: TMF656 Parent/Underlying Problem explanation

    TM Forum Member
    Posted Apr 13, 2021 02:09
    Hi Wayne
    I hope this example is accurate, but I am not an OSS expert.
    Let's suppose that telco partners start experiencing connectivity issues with (say) a 1GB fiber connection. They'll each open a service problem. But the root of the problems is the same for all, the equipment in the telco's exchange that handles all the fiber connections. So the telco could open a problem to get that equipment fixed, and make the problem a parent problem for all the partners' problems.
    Similar concept to customer trouble ticket, there could be 1000s of retail trouble tickets opened all due to the same underlying problem.
    Happy for OSS ops experts to weigh in with more (better?) examples.
    Anyway 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.

  • 3.  RE: TMF656 Parent/Underlying Problem explanation

    Posted Apr 14, 2021 01:15
    Parent - Root cause of a problem in the network

    Children/ Child - Due to the root cause other network elements gets affected and hence propagates the affect to TT. This results in 100 or more alarms unnecessary. Therefore it is critical to know the root cause within 3 minutes for all L0 to L4 domains and the exact location of the issue.
    These are on the network

    Service - Circuit or customer - these are the customers affected due to the root cause. This is a relation built in the Inventory of the OSS, called the service inventory which is mapped from CRM to Circuit.

    NMSWorks Software Pvt. Ltd.

  • 4.  RE: TMF656 Parent/Underlying Problem explanation

    Posted Apr 15, 2021 09:30
    Thank you all for your insights into this subject.

    After reading the feed and the documentation again, these are my observations.

    In reference to the API documentation examples, what constitutes an underlying problem seems to be a judgement call from the SPM Administrator. In the example, it's the fact that the Administrator considers that two declared problems affecting the same location results in a Problem, Underlying Problem relationship.  It would be nice if the rules governing when a problem becomes an underlying problem were more explicit. For example, an underlying relationship is established when:
    • They have the same underlying cause.
    • They affect the same location.
    • An affected service in one problem is dependent on an affected service in another problem. 
    I am assuming as well that in a Problem-Underlying-Problem that both problems are handled individually whereas in a Parent-Child association, only the Parent problem is handled and when closed, closes all children as well. Is this a correct assumption?

    From what I understand from the Parent-Child(ren) example, The Parent relationship is simply a way of grouping Service Problems based on some criteria. In the example, the criteria is that Problem 1 and 2 are deemed to be the same problem. Again, it would be nice if the rules for grouping were more explicit, or maybe they are too CSP/telco. specific.

    Thanks again

    Wayne Sampson
    CGI Info Systems Management Consulting Inc.

  • 5.  RE: TMF656 Parent/Underlying Problem explanation

    TM Forum Member
    Posted Apr 13, 2021 08:36
    Edited by Brian Keeley Apr 14, 2021 04:40
    HI Wayne ,

    there are some examples from the API Guide as well.  The underlying problem is simply the root cause that can be driven from the Network Provider.   I see that in the example: a trouble ticket notification triggers the creation of a service problem that is the underlying problem ( that makes sense to me).   A series of customer tickets could generate service problems that can all be associated into a common fault / root cause and one can use a parent problem to relate them.

    A simple example: a splitter cabinet / DSLAM that fails due to power/electronics in the cabinet , environmental (flood) or even a traffic accident (it happens).  Each customer could generate a customer trouble ticket .  In this scenario all services for all customers served by that remote would/could be impacted.  One can imagine generating multiple service problems, including a service problem originating from the monitoring systems of the network.  It would detect and report the loss of connectivity from the remote most likely.  SPM can associate / correlate all the problems to a parent problem and can correlate to the underlying network problem.   That correlation can occur in many ways.

    Brian Keeley
    CGI Info Systems Management Consulting Inc.