OSS Sandpit – Smart City / IoT Network Inventory Prototype

This article provides an example of building Smart City and IoT (Internet of Things) Network components into the inventory module of our Personal OSS Sandpit Project.

This prototype build includes components such as:

  • A Command and Control Centre (CCC)
  • Satellite Earth Stations
  • Smart Buildings including:
    • Compute / Hosting (VxBlocks)
    • Comms (incl Unified Comms and In-Building Coverage)
    • Security (eg CCTV, Access Control)
    • Building Management Systems (BMS)
    • Public Address / Audio-Visual
    • HVAC 
  • An optical fibre ring network and direct fibre backhaul links to radio towers
  • Towers / masts that are affixed with 5G and LoRa antenna and radio heads as well as point to point microwave antenna
  • 5G infrastructure (see this earlier post for more details on 5G setup)
  • LoRaWAN infrastructure (including LoRa antenna / gateway, LoRa network server,  app servers and the join server)
  • IoT Sensors including:
    • Power Management Systems
    • Smart Meters
    • Parking Sensors
    • Traffic Control Systems (TCS)
    • Variable Messaging Systems (VMS)
    • Tollway Systems
    • Rail Control Systems (RCS)
    • Vehicle Detection Systems (VDS)
    • IoT Asset / Logistics Management

This smart-city / IoT prototype can be summarised as follows:

This diagram replicates a smart city I helped to design a few years ago for Ha’il in Saudi Arabia. This smart city was intended to house around 500,000 people and align with an existing university.  Dry Dock, Business Park and an Airport were also a feature of the design that we prepared in conjunction with KEO Architects and Ernst & Young. It was a really interesting exercise in design and commercial modelling.

This smart city hasn’t been built yet, so the network you see modelled in the Inventory tool below is purely hypothetical.

Note that this network was built around a GPON network model, especially for the residential areas, but we’ll be covering that in a later prototype article.

In this post we’ll describe the following use-cases:

  • Building Reference Data like data hierarchies, device types, etc
  • Creating Device Instances including rack views and the virtualised layers within them
  • Creating Physical Connections between devices (eg fibre ring, radio network backhaul)
  • Creating Logical Connections between devices (eg LoRaWAN service mappings and LoRaWAN network layout)

 

Reference Data

Starting off with the data hierarchy, we had to develop some new building blocks (data classes) to support a more granular tower asset model and IoT sensors (as per yellow highlights below):

We’ve developed a custom data hierarchy as follows:

  • Country
    • Site (for key sites – Command & Control Centre, University, Airport, Business Centre and the Dry Dock)
      • Comms Room (Room)
        • Rack
          • Equipment (including VxBlocks, routers, ODFs, etc)
            • NFVI
              • NFVs (including 5G Core, Firewalls, LoRaWAN)
                • Apps (eg LoRa Network Server, Application Servers, etc)
    • Mobile Base Station (BTS) Sites
      • Comms Huts (Building)
        • Rack
          • Equipment
      • Tower
        • Appurtenances (ie attachments to the tower)
          • Mount Groups (ie the frames / mounts that connect attachments to the towers / poles)
            • Equipment (including remote units, LoRa gateways and antenna)
    • City
      • IoT Devices

This required a few new templates, including these BTS / LoRa sites:

More importantly, we needed to include additional classes and attributes to correctly model the towers. First we needed to add Mount Groups. These mounts hold the antenna and remote units that provide 5G coverage across the estate:

You’ll notice on the left-hand pane there are three sector mounts [MNT-01 to 03] (all at 30m elevation above ground level) that to provide 360 degree 5G coverage (ie 3 x 120 degree sector cells). You’ll notice above that MNT-01 has an azimuth of 0 degrees. MNT-02 has an azimuth of 120 degrees and MNT-03 has an azimuth of 240 degrees (not shown). 

MNT-04 holds the LoRA Gateway (which is an omni-cell – providing 360 degree coverage at an elevation of 25m). Meanwhile, MNT-05 holds a point-to-point microwave radio antenna (at an elevation of 29m).

The right-hand pane shows the additional attributes required to model the tower mounts.

This tower configuration is reflected in the diagram below:

Device Instances

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

And a more detailed view of the IoT Management:

You’ll also see these VNFs and Apps reflected in the Rack Layout of the VxBlock below:

Physical and Logical Connections

There is quite a lot of patching and port mirroring required to create the connectivity between the CCC, key sites, Base Stations, Earth Station, Satellite and IoT Sensor Sites, as follows:

Ha’il City Overview

Note that this mirrors the first image above, with the exception of the Airport and Satellite which are off the top of the page.

You’ll also notice that there is a fibre ring (red lines) between key sites as well as point-to-point fibre backhaul to the BTS site. IoT sensors are also shown (LoRa radio connectivity not shown though).

Fibre link between CCC and BTS001

5G antenna and remote unit are at the left, connecting to the 5G Core at right.

One leg of the Fibre Ring

You’ll notice that this is the link between a router in the CCC (Data Centre – Comms Room 1) to the Comms Room at Ha’il University.

LoRaWAN Logical Connectivity

There’s likely to be additional App Servers required, but two have been included for demonstrational purposes.

 

Satellite Modelling

Refer to this earlier post for how to model Satellite networks and services.

 

IoT Service Modelling

It shows the Traffic Light service (MIoT) as well as the infrastructure it uses (ie the IoT Traffic Light device, the nearest LoRa Gateway to these fixed IoT devices and the LoRa network server in the CCC).

We could model connectivity of all the IoT sensors back through the LoRa Gateway with physical links, but instead we’ve simplified, showing only the service utilisation. 

Service Impact Analysis (SIA)

We can also use the service relationships to determine which customer services would be affected if the LoRa Gateway (HA001-LORA-01) failed. In the image above, there would be three traffic light services affected (see under “Uses” in the bottom pane).

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 introduction into how we’ve modelled a sample Smart City and IoT 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 Smart City 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.

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

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.