OSS Sandpit – Satellite Network Inventory Prototype

This article provides an example of building Satellite Network components into the inventory module of our Personal OSS Sandpit Project.

This prototype build includes components such as:

  • A Satellite
  • Earth Stations
  • Satellite Aggregation Site
  • Beams (including Beam to Earth Station mappings)
  • Customer services
  • Satellite Dishes
  • Satellite Receivers (ODU / IDU)
  • Satellite Modems
  • Leased Lines (backhaul)

Our prototype is summarised in the diagram below:

We describe this via the following use-cases:

  • Building Reference Data like data hierarchies, device types, connectivity types, containment, device layouts, templates, flexible data models, etc
  • Creating Device Instances including rack views and the virtualised layers within them
  • Creating Physical Connections between devices
  • Creating Logical Connections between devices

Reference Data

Starting off with the data hierarchy, we had to develop some new building blocks (data classes) to support the devices and multiplexing used in satellite networks (including those highlighted in yellow below):

In our prototype, we’ve developed a custom containment model as follows:

  • Country
    • Site (for head-end equipment)
      • System
        • Rack
          • Equipment
    • City (for customer sites)
      • CustomerSites
        • Equipment
    • Satellite_Infra
      • Satellite Earth Stations
        • Rack
          • Equipment
      • Aggregation Site
        • Transmission System
          • Rack
            • Equipment
      • Satellite
        • Beam (downlinks)
        • Uplinks (as VirtualPorts)

In a real situation, you probably wouldn’t bother to model to this level of detail as it just makes more data to maintain. We’ve just included this detail to show some of the attributes of our sample satellite network.

The satellite network also required some new templates, especially for the Earth Stations and Customer sites that have many devices and ports that you wouldn’t want to re-create each time.

Device Instances

We then create the devices to build the prototype network model shown in the first diagram above. This includes:

  • Satellite
  • Earth Stations
  • Satellite Aggregation Site
  • Satellite Dishes
  • Satellite Receivers (ODU / IDU)
  • Satellite Modems
  • Switches
  • Routers

This diagram below shows a small snapshot of the Geraldton Earth Station. The templates we created earlier helped to avoid re-creating these hierarchies for each Earth Station and Customer Site:

Earth Stations (including Infrastructure within Geraldton):

SkyMuster II Satellite (showing beams and transceivers / uplinks):

SkyMuster II Satellite Attributes:

Satellite Customer Sites:

Customer Site Details:

Physical and Logical Connections

There is quite a lot of patching and port mirroring required to create the connectivity between the customer sites, Aggregation Site, Earth Station, Satellite and Customer Sites, as follows:

Head-end (Customer core site, Aggregation Site, Earth Station):

Earth Station to Satellite:

Satellite to Customer Sites (modelled as MPLS Links to handle many:one links to the satellite):

Customer Site (including identification of which beam is mapped to):

Note: Whilst there would be significant outside plant (OSP) such as cables, joints and splices, especially between the Earth Station (in Geraldton, in Western Australia) and the Aggregation Site (in Eastern Creek, in New South Wales), we’ve only shown a point-to-point leased fibre link. To see how fibre cables, splice joints and ODFs are modelled, refer to the introduction to the OSS Sandpit inventory module.

Service Impact Analysis (SIA)

We can also use the service relationships to determine which customer services would be affected if the Geraldton router (GER-RTR-01) failed. In the example below, there would be two services affected (see under “Uses” in the bottom pane).

The upper pane shows all of the devices and links that Customer Service C-42-00001 relies upon for service.

Similar analysis could be done using the getAffectedServices API that we demonstrated in the OSS Sandpit Inventory Intro post.

Summary

I hope you enjoyed this brief introduction into how we’ve modelled a sample Satellite network into the Inventory module of our Personal OSS Sandpit Project. Click on the link to step back to the parent page and see what other modules and/or use-cases are available for review.

If you think there are better ways of modelling this Satellite network, if I’ve missed some of the nuances or practicalities, I’d love to hear your feedback. Leave us a note in the contact form below.

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.