OSS Sandpit – 5G Network Inventory Prototype

5G networks seem to be the big investment trend in telco at the moment. It comes with a lot of tech innovation such as network slicing and an increased use of virtualised network functions (VNFs). This article provides an example of building 5G Network components into the inventory module of our Personal OSS Sandpit Project.

This prototype build includes components such as:

  • Hosting infrastructure
  • NFVI / VIM (NFV Infrastructure and Virtualised Infrastructure Management)
  • A 5GCN (5G Core Network)
  • An IMS (IP Multimedia Subsystem)
  • An RIC (RAN Intelligent Controller)
  • Virtualised Network Functions (AUSF, AMF, NRF, CU, DU, etc – a more extensive list of examples is provided later in this article)
  • Mobile Edge Compute (MEC)
  • MEC Applications like gaming servers, CDN (Content Delivery Networks)
  • Radio Access Network (RAN) and Remote Radio Units (RRU)
  • Outside Plant for fibre fronthaul and backhaul
  • Patching between physical infrastructure
  • End to end circuits between DN (Data Network), IMS, 5GCN, gNodeB, RRU
  • Logical Modelling of 5G Reference Points

Our prototype (a Standalone 5G model) 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
  • Creating Network Slices in the form of services
  • Performing Service Impact Analysis (SIA)

Reference Data

Starting off with the data hierarchy, we had to develop some new building blocks (data classes) to support the virtualisation used in 5G networks. This included some new network slice types, virtualisation concepts and various other things:

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

  • Country
    • Site
      • System (Network Domain)
        • Rack
          • Hosting
            • NFVI / VIM
              • VNF-Groupings (eg CU, DU, MEC, IMS, etc)
                • VNF
                  • Apps (like Gaming Servers)

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 5G network.

5G also required some new templates, especially for core infrastructure that can house dozens of VNFs, 5G reference points and apps (eg games servers, CDN, etc) that you don’t want to recreate each time.

The 5G System architecture includes the following network functions (VNFs) and others.

  • Authentication Server Function (AUSF).
  • Access and Mobility Management Function (AMF).
  • Data Network (DN), e.g. operator services, Internet access or 3rd party services.
  • Unstructured Data Storage Function (UDSF).
  • Network Exposure Function (NEF).
  • Network Repository Function (NRF).
  • Network Slice Specific Authentication and Authorization Function (NSSAAF).
  • Network Slice Selection Function (NSSF).
  • Policy Control Function (PCF).
  • Session Management Function (SMF).
  • Unified Data Management (UDM).
  • Unified Data Repository (UDR).
  • User Plane Function (UPF).
  • UE radio Capability Management Function (UCMF).
  • Application Function (AF).
  • User Equipment (UE).
  • (Radio) Access Network ((R)AN).
  • 5G-Equipment Identity Register (5G-EIR).
  • Network Data Analytics Function (NWDAF).
  • CHarging Function (CHF).

Device Instances

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

  • Hosting infrastructure
  • NFVI / VIM (NFV Infrastructure and Virtualised Infrastructure Management)
  • A 5GCN (5G Core Network)
  • An IMS (IP Multimedia Subsystem)
  • An RIC (RAN Intelligent Controller)
  • Virtualised Network Functions (AUSF, AMF, NRF, CU, DU, etc)
  • Mobile Edge Compute (MEC)
  • MEC Applications like gaming servers, CDN (Content Delivery Networks)
  • Radio Access Network (RAN) and Remote Radio Units (RRU)

This diagram below shows a small snapshot of the 5G Core. The templates we created earlier sure came in handy to avoid re-creating these hierarchies for each device type:

Note that the VirtualPorts are used for 5G reference points to support logical links, which we’ll cover later.

The diagrams below show the rack-layout views of core and edge hosting respectively. You’ll notice the hierarchy of device, NFVI, VNF-group, VNFs and applications are shown:

Physical Connections

To create the physical connectivity between core, edge and RRU, we’ve re-used the fibre cables, splice joints and ODFs that we demonstrated in the introduction to the OSS Sandpit inventory module.

In this case, we’ve just used fibres that were spare from last time and patched onto the 5G network’s physical infrastructure. The diagram below shows the physical path all the way from the Data Network (DN – aka a core router) to the transmitting antenna at site 2040.

This diagram includes router, core hosting, ODFs (optical patch panels), cables, splice joints, edge hosting, Radio Units and antenna, as well as fibre front and backhaul circuits.

Logical Connections

We also decided to create the various logical connections – in the most part these are interfaces between VNFs – via the standardised 5G Reference Points. 

You can also find a reference to the various logical interfaces / reference-points in the top-right corner of the prototype diagram (first diagram above).

You can also see the full list of reference points from any given VNF, as shown in the example of the AMF below. You’ll notice that these have already been set up as logical links to other components, as shown under “mplsLink” in the bottom pane. (ie the top pane are the “ports” on the AMF, the bottom pane shows the logical links to other VNFs)

The upper pane shows the instance of AMF (on the core) and its various interface points (A-end of the interface as VirtualPorts). The lower pane shows the relationships to Z-end components via logical circuits (note that I had to model them as MPLS links, which is not quite right, but the workaround needed in the tool).

You’ll also notice that the AMF is used by a number of network slices (under “uses” in the bottom pane), but we’ll get to that next.

Network Slices

Whilst not really technically correct, we’ve simulated some network slices in the form of “internal” services. To simplify, for each network slice type we’ve created a separate service terminating at each RRU. So, we’ve associated each RRU, Mobile Edge Infra (RAN), AMF (the Access and Mobility Management Function within the core) and the NSSF (the Network Slice Selection Function within the core) to these network slice “services.”

Some samples are shown below.

BTW 3GPP has defined the following Slice Types:

  • MIoT – Massive Internet of Things – support a huge device counts with enhanced coverage and low power usage
  • URLLC –  Ultra-Reliable Low-Latency Communications – to support low-latency, mission-critical applications
  • eMBB – Enhanced Mobile Broadband – to provide high speed data for application use (eg video conferencing, etc) and
  • V2X – Vehicle to Everything

Service Impact Analysis (SIA)

We can also use the service relationships to determine which Network Slices would be affected if the AMF failed. In the example below, there would be seven slices affected (see under “Uses” in the bottom pane), including all supported via sites 2040 and 2052

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

SigScale RIM

Over the last few weeks, I’ve also been using another open-source inventory management tool from SigScale called RIM (a Resource Inventory Manager designed to support service assurance use cases). It shines a light on mobile networks in particular.

The project creators authored the TM Forum best practice document IG1217 Resource Inventory of 3GPP NRM for Service Assurance which details the rationale for, and process of, mapping 3GPP information models to TM Forum’s TMF634 (Resource Catalog Mgmt) and TMF639 (Resource Inventory Mgmt) standards.

I plan to also use RIM’s REST interface (based on TM Forum’s OpenAPIs) to share data both ways with the Kuwaiba inventory module in the future. 

Summary

I hope you enjoyed this brief introduction into how we’ve modelled a sample 5G 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 the 5G 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.

OSS Sandpit – Resource / Inventory Module

This article provides a description of the inventory baseline, one module of our Personal OSS Sandpit Project.

As outlined in the diagram below, this incorporates the Inventory solution (by Kuwaiba), the graph database that underpins it as well as its APIs and data query tools. The greyed out sections are to be described in separate articles.

OSS Sandpit Inventory Baseline

We’ve tackled inventory first as this provides the base data set about resources in the network that other tools rely upon.

As the baseline introduction to the inventory module, we’ll provide a quick introduction to 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
  • Creating Physical Connections between devices
  • Creating Logical Connections between devices
  • Creating Services and their relationships with resources / inventory
  • Creating Outside Plant Views on geo-maps that include buildings, pits, splice cases, cable management, splicing, towers, antenna, end-to-end L1 circuits
  • Assigning IP Addresses and subnets with an IPAM tool
  • Creating an MPLS network
  • Creating an SDH network
  • Data import / export / updates via APIs including Service Impact Analysis (SIA)
  • Data import / export / updates via a Graph Database Query Language

Reference Data

Kuwaiba has a highly flexible and extensible data model. We’ve added many custom data classes (eg device categories like routers, switches, etc) such as those shown below:

And selectively added custom attributes to each of the classes (such as the Router class below):

Once the classes are created, we then create the Containment model (ie hierarchy of data objects). In our prototype, we’ve developed a custom containment model as follows:

  • Country
    • Site
      • System (Network Domain)
        • Rack
          • Equipment and so on.

We’ve also created a series of data templates to simplify data entry, such as the Cisco ASR 9001 and Generic Router examples below:

But we can also create templates for other objects, such as cables. The following sample shows a 24 fibre cable with two loose-tubes, each containing 12 fibre strands. (Note that colour-coding on tubes and strands is important for splicing technicians and designers)

Site and Device Instances

Next, we created some sites and devices within the sites, as shown below:

You’ll notice that some devices are placed inside a rack whilst others aren’t. You’ll also notice the naming convention for all devices (eg site – system – type – index, where site = 2052, system = DIS (distribution), type = CD (CD player for messaging) and index = 01 (the first instance of CD player at this site)).

It even allows us to show rack layouts (of equipment positions inside a rack)

And even patching-level details inside the rack (pink and blue lines represent patch-leads connecting to ports on the Cisco ASR 9001 router in rack position 2):

Physical Connections

Physical connections can take the form of patch-leads or via strands / conductors inside cables.

The diagram below represents a stylised optical fibre connection that we’ve created between a CODEC at site 2000 and another CODEC at site 2052. As you’ll also notice, it traverses two patch panels (ODFs – optical distribution frames), two splice joints and three optical fibre cables.

In our inventory tool, the stylised connection above presents as follows, where A and B have been added to indicate the patch-leads from the CODECs to patch-panels (ODFs):

Logical Connections

We can also represent logical and virtual connections. In the case below, we show a logical connection from the Waveguide of an antenna, to the broadcast of that signal to a neighbouring site, which then picks up the signal at the UAST (receiver).

Outside Plant Views

Outside plant (OSP) are the cables, joints, manholes, etc that help connect sites and equipment together. In the example below, we see the OSP view of the fibre circuits we described above in “Physical Connections.” If you look closely on the GIS (map overlay) below, you’ll spot sites 2000 and 2052, as well as the cables and splice joints. The lines show the physical route that the cables follow. 

You may also have noticed that the green line is showing a radio broadcast link, which is point-to-point radio and therefore follows a straight line path from antenna to antenna.

Cable Management

Cable management and splicing / connections is supported, with tubes/strands being selected and then terminated at each end of the cable (in this case CABLE1 and its strands connect the splice case on the left pane, with the ODF on the right pane). These can be managed on a strand-by-strand basis via the central pane. From the diagram, we can see that fibre 001 in CABLE 1 is connected to F1-001 in the splice case and 001-back on the ODF from the A-end and B-end details in the bottom left corner.

From the naming convention, you’ll notice that there are two sets of cable “ports” in the splice case, as indicated by fibre numbers starting with F1 and F2 respectively.

Topology Views

The diagram below shows a topological view of the devices within a site, helping operators to visualise connectivity relationships.

Services

One of the most important roles that inventory solutions play is as a repository of equipment and capacity. They also assist in allocating available resources to customer services. In the example below, service number “2052-ABC_LR_97.3FM-BSO” has a dependency on a tower, antenna, antenna switch frame and many more devices. If any of these devices fails, it will impact this customer service, as we’ll describe in more detail below.

 

IP Address Management (IPAM) and IP Assignment

We can manage IP address ranges / subnets, such as the examples below:

And then allocate individual IP addresses to devices, such as assigning IP address 222.22.22.1 to the CODEC, as shown on the “Physical Connection” diagram above.

MPLS Network

The following provides a simple MPLS network cloud for a customer:

APIs (including Service Impact Analysis Query)

The solution has hundreds of in-built APIs that facilitate queries, adds, modifies and deletes of data. 

The example shown below is getAffectedServices, which performs a service impact analysis. In this case, if we know that the device TEST-CD-02 fails, it will affect service number “2052-ABC_LR_97.3FM-BSO.” We can also look up the attributes of that service, which could include customer and customer contact details so that we can inform them their service is degraded and that repair processes have been initiated.

Note that the left-side pane is the Request and the right-side pane is the Response across the getAffectedServices API.

Data management via queries of the Graph Database

This inventory tool uses a Neo4j graph database. Using Neo4j browser, we can connect to the database and issue cypher queries (which are analogous to SQL, a structured query language that allows you to read/write data from/to the database). 

The screenshot below shows the constellation of linked data returned after issuing the cypher query (MATCH (n:InventoryObjects…. etc)). The data can also be exported in other formats, not just the graphical form shown here. 

I hope you enjoyed the brief introduction to 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.

Building a Personal OSS Sandpit

Being Passionate About OSS, I’ve used this blog / site to share this passion with the OSS community. The aim is to evangelise and make operational support tools even more impactful than they already are.

But there’s a big stumbling block – the barrier to entry into the OSS industry is huge. The barrier manifests in the following ways:

  • Opportunities – due to the breadth of knowledge required to be proficient, there aren’t many entry-level, OSS-related roles
  • Knowledge / Information – such is the diversity of knowledge, no single person has expertise across all facets of OSS – facets such as software, large-scale networks, IT infrastructure, business processes, project implementation, etc, etc. Even within OSS, there’s too huge a range of functional capability for anyone to know it all. Similarly, there’s no single repository of information, although organisations like TM Forum do a great job at sharing knowledge. On top of all that, the tech-centric worlds that OSS operate within are constantly evolving and proliferating
  • Access to ToolsOSS / BSS tools tend to be highly flexible, covering all aspects of a telco’s business operations (from sales to design to operations to build). OSS tend to cost a lot and take a long time to build / configure. That means that unless you already work for a telco or an OSS product vendor, you may struggle to get hands-on experience using the tools

It’s long been an ambition to help reduce the third barrier to entry by making personal OSS sandpit environments accessible to anyone with the time and interest.

The plan is to build a step-by-step guide that allows anyone to build their own small-scale OSS sandpit and try out realistic use-cases. The aim is to keep costs to almost nothing to ensure nobody is limited from tackling the project/s.

The building blocks of the sandpit are to be open-source and ideally reflect cutting-edge technologies / architectures. The main building blocks are:

  1. Network – a simulated, multi-domain network that can be configured and tested
  2. Fulfilment / BSS – the ability to create product offerings, take customer orders for those products, then implement as services into a network
  3. Assurance / Real-time – to perform (near) real-time monitoring of the network and services using alarms / performance / telemetry / logging
  4.  Resource / Inventory – to design and store records of multi-domain networks that spans PNI (Physical Network Inventory), LNI (Logical Network Inventory), OSP (Outside Plant), ISP (Inside Plant) and more
  5. Data Visualisation & Management – being able to interact with data generated via the abovementioned building blocks. Interact via search / queries, reports, dashboards, analytics, APIs and other forms of data import / export

OSS Sandpit Concept Diagram

Until recently, this sandpit has only been an ambition. But I’m pleased to say that some of these building blocks are starting to take shape. I’ll share more details in coming days and update this page.

This includes:

  • Introduction to The Resource / Inventory Module with the following use-cases:
    • Building Reference Data like location hierarchies, device types, connectivity types, containment, device layouts, templates, flexible data models, etc
    • Creating Device Instances including rack views
    • Creating Physical Connections between devices
    • Creating Logical Connections between devices
    • Creating Services and their relationships with resources / inventory
    • Creating Outside Plant Views on geo-maps that include buildings, pits, splice cases, cable management, splicing, towers, antenna, end-to-end L1 circuits
    • Assigning IP Addresses and subnets with an IPAM tool
    • Creating an MPLS network
    • Creating an SDH network
    • Data import / export / updates via APIs including Service Impact Analysis (SIA)
    • Data import / export / updates via a Graph Database Query Language
  • Designing the Inventory / Resources of a 5G Network including:
    • Hosting infrastructure
    • NFVI / VIM
    • A 5GCN (5G Core Network)
    • An IMS (IP Multimedia Subsystem)
    • An RIC (RAN Intelligent Controller)
    • Virtualised Network Functions (AUSF, AMF, NRF, CU, DU, etc)
    • Mobile Edge Compute (MEC)
    • MEC Applications like gaming servers, CDN (Content Delivery Networks)
    • Radio Access Network (RAN) and Remote Radio Units (RRU)
    • Outside Plant for fibre fronthaul and backhaul
    • Patching between physical infrastructure
    • End to end circuits between DN (Data Network), IMS, 5GCN, gNodeB, RRU
    • Logical Modelling of 5G Reference Points

More details and use-cases to come, including:

  1. Inventory modelling of:
    1. Satellite services
    2. Fixed wireless and Rural ISP network models
    3. Internet of Things (IoT)
    4. GPON / FTTH
    5. HFC / CableCo
    6. Data Centre (DC)
    7. MPLS
    8. SDH Transmission
    9. More network virtualisation (SDN), in addition to the virtualisation scenarios covered in the 5G prototype (see above)
    10. Are there any other scenarios you’d like to see???

 

If you’d like to know more about our Personal OSS Sandpit Project, fill in the contact form below.