Orders down, faults up (and the TMN Pyramid)

As mentioned in a post about Service and Resource Availability last week, I do tend to think of OSS workflows around an “orders down, faults up,” flow direction. And that means customers (services) at the top, network (resources) at the bottom of the (TMN) pyramid [see more about the TMN pyramid reference at the end of this article].

OSS/BSS Data Flows

I also think of inventory (yellow) as the point where Assurance / Faults (blue) and Fulfillment / Orders (purple) collide and enhance, as per the diagram below.

These are highly generic examples, but let’s take a closer look:

Assurance flow (blue) – an alarm or event in the network (NEL/NE layer) pushes up through the stack to the OSS as a fault. The inventory (network / service) helps to enrich the fault with additional information (eg device name, location, connectivity, correlation of this and other faults, etc) to help resolve the fault (either manually by operators or automatically by algorithms). It also helps associate the fault in the network/resource with the customer/s using those resources. This allows notifications to be issued to customers. Note that this simple flow doesn’t reflect examples such as an incident (ie when a customer notices a problem first and calls it in before the OSS has been able to issue a notification).

Fulfillment flow (purple) – a customer places an order (BML/BSS layer or above) and it pushes down through the stack, including changes in the network (NEL/NE layer). Once all the appropriate network changes have been made, the order is ready for use by the customer. Once again, inventory plays an important part, associating customer / service identifiers with suitable resources from the available resource pool. Generally the (customer facing) service orders won’t have the technology-specific details required to actually update the network configurations though. That’s where the inventory often helps to fill in the knowledge gaps and send technology-specific commands down into the network. [See Friday’s post for more information about CFS and RFS definitions and mappings]

Inventory flows (yellow) – an inventory is relevant to assurance and fulfillment flows if the BSS and network / resource layers don’t hold enough information to be fully processed. The enriching information stored by inventory must come from somewhere. Some of it comes from Discovery (usually an automated process of collecting from the network or other sources), or via Manual / Scripted Input (eg physical network designs including patch cables and splicing). Some data (eg splices) just can’t be collected automatically as they relate to passive equipment that has no programmatic interface. This data just has to be created manually.
But arguably the more important inventory data is actually recording the mappings made from customers (services) to network (resources). Inventory solutions  are often where these linking keys / relationships are recorded.

These flows also tend to indicate the direction of data mastery. Whilst the network itself is the source of truth, Fulfillment flows will start at the BSS and customer / service / order data will tend to be mastered there before orders are pushed into the network as provisioning commands. For assurance flows, the network will tend to be the master source of data, but with enrichment along it’s path northbound.

Just keep in mind that there are many exceptions to these examples. Data and processes can flow in many different ways. The diagram above is just useful for helping newcomers to understand some conceptual processes and data models / flows.

TMN (Telecommunications Management Network) Pyramid Context

As mentioned above, we thought it best to provide some further context around the TMN Pyramid in case you weren’t already familiar with it. It’s a bit of an old concept, introduced by the ITU-T in its M.3010 recommendations decades ago. However, it still has some important principles to describe today.

As shown in the diagram above, the pyramid consists of five layers (plus an extra one that’s not show – but more on that below), with each representing a different level of abstraction in network management:

1. Business Management Layer (BML) – The topmost layer focuses on business objectives, strategy, and financial considerations. It ensures that network operations align with business goals such as revenue generation, cost reduction, and service quality improvements. This is roughly equivalent to the BSS (Business Support System) layer

2. Service Management Layer (SML) – This layer is responsible for managing telecom services delivered to customers. It includes service provisioning, quality assurance, and customer experience management, ensuring that services meet agreed SLAs (Service Level Agreements). This is roughly equivalent to the OSS (Operations Support System) layer

3. Network Management Layer (NML) – The NML oversees the entire network infrastructure, including fault, performance, and configuration management across different network domains. It serves as the bridge between high-level service objectives and lower-level network resources. This is roughly equivalent to the NMS (Network Management System) layer, where network equipment, usually from multiple vendors and/or domains is stitched together

4. Element Management Layer (EML) – This layer handles the management of individual network elements such as routers, switches, and base stations. Element Management Systems (EMS) are typically vendor-specific and/or single-domain and provide functionalities like device configurations, local connectivity, monitoring, and local troubleshooting. Because they’re often single-domain and single vendor, they can have quite specific proprietary monitoring and management practices / functionality. Terminology is important here as vendors often refer to their proprietary software as NMS, when it’s arguably more correct to call them EMS.

5. Network Element Layer (NEL) – The foundation of the pyramid consists of network elements (NE) (physical or logical) that form the telecom infrastructure (such as routers, switches, and base stations). This includes hardware devices and software-defined components that transmit and process data

6. Not included in the TMN Pyramid, but there’s also the Physical Layer (PL), which incorporates the physical cabling, etc that connects the devices together, as well as buildings, racks, etc that house the network elements
7. As represented in the blue diagram above, each layer up tends to abstract (ie contains less specific data than the lower layer) but connects (ie has greater awareness of its surroundings and broader context)