Northbound vs Southbound Interfaces
Learning Objective: Understand northbound and southbound interfaces – the two directions OSS communicates. Southbound = talking to network devices. Northbound = exposing data to BSS, analytics, and other higher-level systems.
The Big Picture: OSS Communication Directions
OSS sits in the middle – talking down to devices and up to higher-level systems.
Southbound Interfaces – OSS to Network
Southbound interfaces allow OSS/NMS to communicate with network devices (routers, gNBs, switches, OLTs) and EMS systems. Key characteristics:
- Direction: OSS → Network (downward)
- Purpose: Collect telemetry, retrieve configurations, push configuration changes, receive alarms, manage software
- Protocols: SNMP, Netconf, gNMI, RESTCONF, CLI, CORBA, TL1
- Data flow: Device → OSS (polling or streaming), OSS/EMS → Device (configuration, provisioning, software management)
- Operational behavior: Southbound communication is often asynchronous because network devices may respond slowly, lose connectivity, or stream telemetry continuously.
| Protocol | Use Case | Modern Relevance |
|---|---|---|
| SNMP | Alarm traps, polling counters | Still widely used, being supplemented by gNMI |
| Netconf | Configuration management | Common in IP/MPLS networks |
| gNMI | Streaming telemetry, configuration | Modern cloud-native networks, 5G |
| RESTCONF | REST-based configuration | Modern IP networks |
| CLI (SSH) | Legacy automation, ad-hoc commands | Still common, but not scalable |
Northbound Interfaces – OSS to Higher-Level Systems
Northbound interfaces expose OSS data and capabilities to higher-level systems like BSS, dashboards, analytics platforms, AIOps, and orchestration engines. Key characteristics:
- Direction: OSS → Higher-Level Systems (upward)
- Purpose: Service activation, alarm notifications, performance data, inventory queries, usage reporting, orchestration commands
- Protocols: REST APIs, TMF Open APIs, Kafka, gRPC, SOAP, AMQP, MQTT
- Data flow: OSS → Consumers (push or pull)
Traditional OSS integrations relied heavily on synchronous APIs and polling. Modern OSS increasingly uses event-driven architectures with Kafka, Pulsar, and streaming telemetry for near real-time operations.
| Protocol/Standard | Use Case | Example |
|---|---|---|
| TMF Open APIs | Standardized OSS-BSS integration | TMF642 (alarms), TMF639 (resource), TMF638 (service) |
| REST APIs | Custom OSS integrations | Inventory queries, service activation |
| Kafka / Event Bus | Real-time event streaming | Alarm notifications, telemetry streams |
| gRPC | Real-time microservice communication | Telemetry, real-time analytics, microservice integration |
Real-World Example: End-to-End Flow
A router interface fails in a multi-vendor network:
- Southbound: gNMI/SNMP from router → EMS → Mediation → NMS
- Processing: NMS correlates alarm, identifies impacted services, updates inventory
- Northbound (TMF642): NMS pushes alarm to assurance dashboard via Kafka
- Northbound (service notification): NMS notifies affected customer via integration with CRM
- Northbound (usage): NMS provides usage data to BSS for SLA credits
Why This Matters in Real Operations
- Southbound integration complexity – Every device vendor has different protocols, MIBs, YANG models. Mediation layers are essential.
- Northbound standardization – TMF Open APIs reduce integration cost between OSS and BSS.
- Customer experience expectations – Delays in OSS activation workflows can directly impact customer onboarding and SLA commitments.
- Protocol migration – Legacy SNMP to modern gNMI requires phased approaches.
- Multi-vendor OSS – Different OSS modules may use different northbound protocols (REST for inventory, Kafka for alarms).
Connection to BSS
Northbound interfaces are where OSS and BSS integrate:
- Order to activation: BSS sends service order request → OSS provisions service → OSS returns activation confirmation
- Usage to billing: OSS collects usage → sends to BSS via mediation → BSS rates and invoices
- Alarm to notification: OSS detects fault → northbound notification to CRM → customer support notified
- Inventory to product catalog: OSS exposes resource availability → product catalog validates order feasibility
A typical telecom operator manages devices from Nokia, Ericsson, Huawei, Cisco, Juniper, and others. Each vendor uses different southbound protocols, MIBs, YANG models, and alarm formats. Northbound interfaces must normalize these differences to present a consistent view to BSS and analytics platforms.
Common Interview Questions
Q1. What is the difference between northbound and southbound interfaces?
Southbound connects OSS to network devices (collecting data, pushing configs). Northbound exposes OSS data to BSS, analytics, and higher-level systems.
Q2. Why are southbound interfaces more complex than northbound?
Southbound must handle multiple device vendors, protocols (SNMP, Netconf, gNMI), data models (MIBs, YANG), and legacy equipment. Northbound can be standardized using TMF Open APIs or common REST patterns.
Q3. What northbound protocols are used for real-time alarm notifications?
Kafka, gRPC streams, WebSockets, or TMF642 webhook callbacks.
Q4. Can the same OSS platform have multiple northbound interfaces?
Yes. For example, REST API for inventory queries, Kafka for alarm streams, and TMF APIs for BSS integration.
Q5. What role does mediation play in southbound integration?
Mediation normalizes vendor-specific protocols and data formats, enriches data with inventory context, and routes to appropriate OSS applications.
Key Terms
Takeaways for You
- Southbound (downward): OSS → Network devices. Protocols: SNMP, Netconf, gNMI, CLI. Purpose: collect data, push configs, receive alarms.
- Northbound (upward): OSS → Higher-level systems (BSS, analytics, AIOps, portals). Protocols: REST, TMF APIs, Kafka, gRPC.
- Mediation layers are critical for normalizing multi-vendor southbound differences.
- TMF Open APIs (642, 639, 638) are the industry standard for northbound OSS-BSS integration.
- Event-driven architectures (Kafka, Pulsar) are increasingly replacing traditional polling and synchronous APIs.
- East-West interfaces enable peer-to-peer communication between OSS domains (covered in Topic 6).
Recommended Next Learning Path