Exploring Telecom Discrepancy Identification and Reconciliation

  • Release version: Yokohama
  • Updated January 30, 2025
  • 8 minutes to read

    • Telecom Discrepancy Identification & Reconciliation solution is designed to confirm the accuracy and consistency of network resource data between network systems and inventory management databases, such as CMDB/TNI.

    Telecom Discrepancy Identification & Reconciliation relies on Telecom Discovery and platform capabilities to perform its functions.

    Telecom Discrepancy Identification & Reconciliation Overview

    telecom discrepancy identification and reconciliation framework.

    TSOM Visibility plugin

    The Telecom Discrepancy Identification & Reconciliation logic is a component of the TSOM Visibility plugin (sn_tsom_core). This plugin encompasses shared logic essential for both Telecom Discovery and Telecom Discrepancy Identification & Reconciliation processes. It includes telecom-specific discrepancy detection and remediation capabilities, along with other foundational logic designed to support current and future telecom application functionalities.

    Identification & Reconciliation Engine (IRE)

    IRE offers a centralized framework for identifying and reconciling data from multiple sources. It confirms the integrity of the CMDB and some non-CMDB tables when various data sources are used to create or update CI records.
    • IRE matches existing CIs based on Identification Rules.
    • IRE creates CIs if no match is found.
    • IRE updates are attributed based on the Reconciliation Rules.

    For more information, see CMDB Identification and Reconciliation (IRE).

    CMDB Compliance and Telecom Discrepancy Identification & Reconciliation

    CMDB Compliance is a toolset that enables administrators to certify CMDB data for accuracy and identify discrepancies detected during compliance audits. It can also automatically generate and assign Follow-on Tasks for failed audit records, which serve as tasks to trigger an appropriate remediation subflow to correct discrepancies. CMDB Compliance Audits form the foundation of our Telecom Discrepancy Identification & Reconciliation.
    • CMDB Compliance runs audits as a post-processing rule, identifying anomalies (discrepancies) in the CMDB.
    • CMDB Compliance creates a Follow-On Task for each Audit Record in a failed state (the failed state is the result of an audit finding an anomaly or discrepancy in the CMDB). A remediation flow can be designed and triggered for each Follow-On Task to address and resolve the discrepancy.

    The logic for Telecom Discrepancy Identification & Reconciliation, as well as the example remediation subflows, are included in the Yokohama release and will be installed automatically with the TSOM Visibility plugin.

    For more information on the general CMDB Compliance toolset, see CMDB Compliance.

    Discrepancy Identification Scenarios (using Certification Audits)

    There are two key discrepancy categories that can be detected between Inventory (CMDB) and Discovery that are described below:
    • Entities that exist in the Inventory but don’t exist in the Network.
    • Entities that exist both in the network and in the inventory but differ in their hierarchy.

    Discrepancy identification in TSOM Visibility relies on using CMDB Compliance (Certification Audits) and has extended it by adding specific logic that uses model relationships and information to identify mismatches.

    Note:
    The current release focuses on the identification and reconciliation of discrepancies at the physical resource layer. In the upcoming release, this functionality is extended to include support for the logical resource layer and attributes as well.

    For more information on the general Certifications Audits feature, see Certification audits.

    Follow-On Task types created for failed Audit Result Records

    The following discrepancy types (Audit Results) can be found for Parent CI and child CIs for each relationship record in the CI Relationship table (cmdb_rel_ci) that matches the conditions, and the following Follow-On Tasks can be created for each of the failed Audit Results:
    1. The most recent discovery date not set- generated in case the Most recent discovery date field in CI is missing.
    2. The most recent discovery date not within configured threshold- generated in case the difference in the Most recent discovery date field value between a Parent CI and child CI is more than 2.5 days.

      By default, it is set to 2.5 days in the sn_tsom_core.discovered_date.diff.threshold.in.days system property and can be changed.

    3. CI model not found–(the ‘Model ID’ field isn’t set or data is invalid). Generated in case a corresponding CI model isn’t found. If a CI model isn’t found, the next validations (4-6) are irrelevant because they rely on CI models. In case a CI model is found, the audit will continue to the next validations (4-6).
    4. Slots occupied discrepancy-Generated in case a Card occupies an incorrect number of Slots.
    5. Model relationships not defined-relevant only if TNI is installed. Generated if the audit is unable to find a relationship between Parent and child CI models in the Network Model Relationships table.
    6. Incorrect number of relationships - relevant only if TNI is installed. Generated if the audit finds that the number of discovered child CI records exceeds the maximum number of its corresponding Parent CI record in the model relationship Count field in the Network Model Relationship table.
    For more information on the general Follow-on Tasks feature, see Building Subflows.

    Discrepancy Remediation Subflows

    Once an audit identifies a discrepancy, it’s logged as a Follow-on Task. The system enables users to define a subflow for specific discrepancy scenarios, enabling them to distinguish between various types of discrepancies and create custom flows to remediate them.

    For more information on how to build a subflow, see Building subflows.

    Usage Example

    The following is an example of a specific scenario on how you can use Telecom Discrepancy Identification & Reconciliation:

    Assume that a piece of equipment was initially discovered with a card (Card40) in its slot (Slot40). Over time, an issue was identified with Card40, and it was replaced by Card41. The inventory (CMDB), however, still contains a Card40 CI, while on the network, it has been replaced by Card41. When the next discovery job is executed, the Card41 CI will be discovered and added to the CMDB in the same slot (Slot40). As a result, we have two CIs (the old one—Card40—and the newly discovered one—Card41) placed in the same Slot40.

    Audit identifies this discrepancy, create a Follow-on task, and enable a user to Remediate. (resolve this discrepancy and decommission Card40).

    When the Service Operation CMDB Compliance Audit runs, it identifies this discrepancy and create an Audit Record in ‘failed’ state (in our example AUDR0001283).
    1. Navigate All > Compliance > Audits > .

    2. Select Service Operation CMDB Compliance Audit.

    3. Select the Run Audits to run the audit.

      A Follow-on Task is automatically created for each failed audit record (in our example, TASK0020215).

      run audit.
    4. Select TASK0020215.follow-on task.

      The Follow-On Task contains a detailed description of the discrepancy. As you can see in the description, the Card40 CI is in discrepancy.

      Note:
      This is an example of the TASK0020215 description created for the "Incorrect number of relationships" scenario. Other scenarios and environments might have different descriptions.

      Card40 was last discovered more than 2.5 days ago.

      Relationships between the following CIs:
      CI Model
      Slot40 (8b2beb4247ceda10f04f83ac416d4398) DEMO 20532Tree (1ba577524c1b3110f8772646dabeb9bb)
      Card40 (0b2beb4247ceda10f04f83ac416d4399) Nokia 7360 FANT-F CARD MODULE (3af9617de5928110f877657a333391e0)
      Card41 (832beb4247ceda10f04f83ac416d439a)

    5. Select the Remediate button to remediate.

    6. Remark: Remediate is a UI action which can be accessed in the following way:
    7. All > System Definition > UI Actions.

    8. Open the Remediate UI action to observe.UI actions.

      For more information on UI actions, see Defining UI actions.

    For this example, the Remediate UI action (triggered by the Remediate) calls the Execute TSOM CI Decommission subflow to address and resolve the discrepancy specified in the Follow-On Task TASK0020215. Additionally, we must decommission an old Card40, which will be executed automatically by calling the subflow ‘TSOM Decommission Card’.

    Once the remediation is successfully completed, work notes are generated with the remediation results in the Follow-On Task window (TASK0020215).

    As you can see in the work notes, we successfully retired Card40 and removed the relationship of Slot40 → Slot40. The discrepancy has been successfully resolved, and the CMDB CI records are now synchronized with the network state.

    example subflow.

    This example subflow is shipped with the solution. Users can define custom remediation subflows using Flow Designer.

    System Properties Affecting Telecom Discrepancy Identification & Reconciliation

    These system properties are part of the TSOM Visibility plugin (sn_tsom_core) and control the Telecom Discrepancy Identification & Reconciliation log (TSOM CMDB Audit). The TSOM Visibility plugin serves as an enabler for the TSOM Visibility applications, containing logic that is shared across the Telecom Discovery and Telecom Discrepancy Identification & Reconciliation solution.

    Table 1. TSOM Visibility System Properties (Impacts CMDB Audit)
    Property Name Recommended / Default Value Description
    sn_tsom_core.audit.interface_card_tables cmdb_ci_interface_card If the value isn’t set (that is, the field is empty), the interface card tables won’t be processed in the TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation).
    sn_tsom_core.audit.discovery_sources SG-Altiplano, ServiceNow The TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation) only processes CI records with discovery source values of SG-Altiplano or ServiceNow (Horizontal Discovery and Patterns). Additional TSOM service graph connectors will be added in future releases.
    sn_tsom_core.audit.relationship_types Contains:Contained by TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation) only processes relationship records with the relationship type Contains::Contained by.
    sn_tsom_core.audit.slot_tables cmdb_ci_container_slot If the value isn’t set (that is, the field is empty), the slot tables won’t be processed by the TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation).
    sn_tsom_core.audit.log.level info

    The TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation) runs with the default log level set to info.

    Note: Changing the log level might impact performance.
    sn_tsom_core.audit.subslot_tables cmdb_ci_container_subslot In case the value isn’t set (that is, the field is empty), the subslot tables won’t be processed by the TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation).
    sn_tsom_core.audit.interface_tables cmdb_ci_ni_interface In case the value isn’t set (that is, the field is empty), the interface tables won’t be processed by the TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation).
    sn_tsom_core.audit.equipment_tables
    • cmdb_ci_ni_telco_equipmen t
    • cmdb_ci_ip_switch
    • cmdb_ci_ip_router
    		 In case the value isn’t set (that is, the field is empty), the equipment tables won’t be processed by the TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation).
    sn_tsom_core.audit.discovered_date.diff.threshold.in.days 2.5 The TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation) only raises discrepancy tasks for CI records with the most recent discovery date values greater than the default threshold value.
    sn_tsom_core.audit.max_number_of_records_to_process 100000

    The TSOM CMDB Audit (Telecom Discrepancy Identification & Reconciliation) is set to process up to 100,000 relationship records.

    Note:
    This value can be increased, but it may impact performance.

    Configure Reconciliation

    See Configure Telecom Discrepancy Identification and Reconciliation.