A graphene analogy to help fix OSS data

By now I’m sure you’ve heard about graph databases. You may’ve even read my earlier article about the benefits graph databases offer when modelling network inventory when compared with relational databases. But have you heard the Graphene Database Analogy? It can help conceptualise the migrating, cross-linking and fixing of data sets.

I equate OSS data migration and data quality improvement with graphene, which is made up of single layers of carbon atoms in hexagonal lattices (planes).

The graphene data model

There are five concepts of interest with the graphene model:

  1. Data Planes – Preparing and ingesting data from siloes (eg devices, cards, ports) is relatively easy. ie building planes of data (black carbon atoms and bonds above), where each data set might come from a different source (eg different EMS, spreadsheets, APIs, etc)
  2. Bonds between planes – It’s the interconnections between siloes (eg cross-domain circuits, network links, patch-leads, joints in pits, etc) that is usually trickier. So I envisage alignment of nodes (on the data plane or graph, not necessarily network nodes) as equivalent to bonds between carbon atoms on separate planes (red/blue/aqua lines above).
    But we can often find points of commonality  between data sets. Alignment comes in many forms:

    1. Through spatial alignment (eg a joint and pit have the same geospatial position, so the joint is probably inside the pit)
    2. Through naming conventions (eg same circuit name associated with two equipment ports)
    3. Various other linking-key strategies
    4. Nodes on each data plane can potentially be snapped together (either by an operator or an algorithm) if you find consistent ways of aligning nodes that are adjacent across planes
  3. Confidence – I like to think about data quality in terms of confidence-levels. Some data is highly reliable, other data sets less so. For example if you have two equipment ports with a circuit name identifier, then your confidence level might be 4 out of 4* because you know the exact termination points of that circuit. Conversely, let’s say you just have a circuit with a name that follows a convention of “LocA-LocB-speed-index-type” but there is no associated port data. In that case you only know that the circuit terminates at LocationA and LocationB, but not which building / rack / device / card / port so your confidence level might only be 2 out of 4.
  4. Visualisation – Having these connected planes of data allows you to visualise heat-map confidence levels (and potentially gaps in the graph) on your OSS data, thus identifying where data-fix (eg physical audits) is required
  5. Connection Hierarchies – The interconnections between planes and the relative hierarchy of the planes can provide great insights for root-cause and/or service-impact analyses. For example, let’s say your PNI provides the physical network data plane. The second plane might be an optical transport layer. If you get a Loss of Signal alarm on adjacent devices in the optical plane, you could imply a cable cut as the root-cause and therefore suppress all child alarms from plane 2 and above in your graphene hierarchy.

* the example of a circuit with two related ports above might not always achieve 4 out of 4 if other checks are applied (eg if there are actually 3 ports with that associated circuit name in the data but we know it should represent a two-ended patch-lead).

Notice how closely the graphene diagram above resembles the following network layer diagram below from ITU-T Rec. G.805

I also see the graphene mindset as a potential mechanism for visualising data across layers such as:

  • Physical infrastructure
  • Logical / virtual infrastructure
  • Services and
  • Other overlays such as real-time data

I feel that this graphene concept is important for us to build the network inventory visualisation tools fo the future.

Or also for data proximities for root-cause (refer to this earlier post) such as:

  1. Proximity in topology (ie nearest neighbours)
  2. Proximity by geography
  3. Proximity in time
  4. Proximity by object hierarchy (think OSI stack)

Note: The diagram above (from graphene-info.com) shows red/blue/aqua links between graphene layers as capturing hydrogen, but is useful for approximating the concept of aligning nodes between planes

If this article was helpful, subscribe to the Passionate About OSS Blog to get each new post sent directly to your inbox. 100% free of charge and free of spam.

Our Solutions

Share:

Most Recent Articles

No telco wants to buy an OSS/BSS

When you’re a senior exec in a telco and you’ve been made responsible for allocating resources, it’s unlikely that you ever think, “gee, we really

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.