Augmented outside plant

When you think of any aspect of life or work, augmented reality is completely going to change how we do it.”
Ori Inbar
.

Here in Australia, we have a program called Dial Before You Dig, which provides information, usually in the form of plans, about underground assets for a given address. It is used by technicians and individuals wanting to know the locations of underground utility assets (ie electricity lines, water mains, gas lines, telecommunications cables) before commencing on a project that requires excavations at a site.

It’s not too hard to envisage a day when the dial before you dig information from existing utility plans becomes spatially mapped into GIS (Geographical Information Systems) formats and becomes available within augmented reality (AR) visualisation tools like Google Glass. It would enable you to put on your AR glasses and see an overlay of all the underground assets as you walk around the site before starting excavations.

As discussed in an earlier post, AR is likely to impact a number of different functional groups within CSPs. AR could be really helpful for CSP technicians to quickly find cable pits, when they are often covered with dirt and the associated work package only provides approximate coordinates of the pit that they’re due to work at.

Enabling this type of AR is likely to be a joint initiative between:

  • GIS manufacturers
  • AR visualisation tools
  • Custom tools that allows spatial data / content creation, storage and playback / visualisation

The two most exciting aspects of this concept for OSS are:

  1. Many CSPs already use GIS to model their outside plant data
  2. Modern GIS are spatial engines that allow organisations to easily overlay visual information of almost any sort

The ramification of these two points is that many CSPs already have the tools and when combined with any other OSS objects that are geo-coded (ie have GPS coordinates assigned to them) they just need AR visualisation tools and a bit of development work to create powerful AR experiences for their field technicians.

Examples might include:

  1. Logical, not just physical views of the network (eg logical configurations of head-end equipment that ties back to the network termination devices in a customer premises)
  2. Cable joint layouts showing current state and proposed state after jointing works have been completed
  3. Using OSS cable trace toolsets (eg Remote Fibre Test Systems – RFTS) to indicate estimated cable cut locations (although you don’t really need AR to show where a cable has been cut when you spot a massive yellow digger and a sheepish looking operator in the proximity of the fault)
  4. Visualisation of the names of cables and perhaps even the impacted customers or other service data on each cable strand when opening a cable joint
  5. Allow techs to relay field work conditions to the design team so that they can make on-the-spot modifications to designs and/or OSS data that reflects the real site conditions. An example could be a tree that prevents an aerially strung cable being installed in the location the designers had originally specified
  6. Allows techs to see the actual designs that are recorded in OSS tools, as opposed to the slightly earlier design that was printed out with the work package (ie before some other designer made unrelated changes in the area where the tech is working).
  7. Visualisation of communications assets in three dimensions when working on riser cable and network devices on multiple levels of a data centre, high-rise building or segregation of assets in a multi-tenant building

In fact, I shouldn’t even limit the perspective to outside plant. Areas that have a high density of physical infrastructure, such as the many racks and cable looms that exist inside exchanges / data centres, are also prime locations for AR.

For example:

  1. Tracing a cable route through the complex cabling looms in a DC
  2. Showing an overlay of key information above each rack (and then each device inside the rack):
    1. Highest alarm severity within the rack (eg a flashing red beacon above each rack that has a critical alarm on any device within it, then a red beacon on any device inside the rack that has critical alarms)
    2. Operational state of each device / card / port within the rack
    3. Active alarms on each device
    4. Current port-state of each port
    5. Performance metrics relating to each device / port (either in current metric value or as a graph/s)
    6. Configuration parameters relating to each device / port (eg associated customer, service, service type or circuit name)
  3. Showing design / topology configurations for a piece of equipment
  4. Showing routing or far-end connectivity coming from a physical port (ie where the cable ultimately terminates, which could be in the same DC or in another state / country)

I’m sure you can come up with a lot more!

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.