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
Northbound Consumers
BSS / Orchestrators / Analytics / AIOps / CRM
REST, TMF APIs, Kafka, Event Bus
SNMP, NETCONF, gNMI, CLI, RESTCONF
Network Devices
Routers, gNBs, Switches, OLTs
Southbound Interfaces - OSS to Network
Southbound interfaces allow OSS/NMS to communicate with EMS platforms, domain controllers, and network devices (routers, gNBs, switches, OLTs).
Key Characteristics
- Direction: OSS → Network (downward)
- Purpose: Collect telemetry, retrieve/push configurations, receive alarms, manage software
- Data flow: Device → OSS (polling/streaming), OSS → Device (config, provisioning)
- Operational behavior: Often asynchronous - devices may respond slowly or stream telemetry continuously
Common Protocols
- SNMP - Traditional polling and traps
- NETCONF - Configuration management
- gNMI - Streaming telemetry, modern 5G
- RESTCONF - REST-based configuration
- CLI (SSH) - Legacy automation
Protocols Used at Each Network Layer
Different parts of the telecom network use different management protocols. This is because optical infrastructure, IP routing, switching, and service layers all have different operational needs.
| Network Layer | What It Does | Management Protocols | Simple Example |
|---|---|---|---|
| Physical Layer | Fiber, cables, transceivers, signal transmission | TL1, SNMP, vendor-specific EMS APIs | Optical power monitoring, LOS detection |
| Data Link Layer (Switches) | MAC addresses, VLANs, switching, Ethernet | SNMP, NETCONF, CLI | Port status, VLAN configuration, MAC table query |
| Network Layer (Routers - IP) | IP routing, forwarding, BGP/OSPF | SNMP, NETCONF, gNMI, CLI | Route table query, BGP session monitoring |
| Transport Network / Service Transport | Connectivity carrying services across IP/MPLS, optical, and carrier transport domains | SNMP, NETCONF, gNMI, TL1, vendor/domain controller APIs | Bandwidth utilization, tunnel status, transport path health |
| Application Layer (Services) | Customer-facing services like VoLTE, VPN, and 5G slices | REST APIs, gRPC, TMF Open APIs | Service activation, SLA monitoring, customer portal |
Routing protocols (BGP, OSPF, IS-IS) run inside the network to help packets find their path. They are not management protocols. Management protocols (SNMP, NETCONF, gNMI) are used by OSS to monitor and configure devices.
Southbound Protocol Details
| Protocol | Use Case | Modern Relevance |
|---|---|---|
| SNMP | Alarm traps, polling counters | Still widely used, often supplemented by gNMI |
| NETCONF | Configuration management | Common in IP/MPLS networks |
| gNMI | Streaming telemetry, configuration | Modern cloud-native networks and 5G |
| RESTCONF | REST-based configuration | Modern IP networks |
| CLI (SSH) | Legacy automation, ad-hoc commands | Still common, but not scalable |
| TL1 | Optical transport management | Legacy optical networks |
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
- Data flow: OSS → Consumers (push or pull)
Common Protocols
- TMF Open APIs - Standardized OSS-BSS integration
- REST APIs - Custom integrations
- Kafka / Event Bus - Real-time event streaming
- gRPC - Microservice communication
Northbound Protocol Details
| Protocol/Standard | Use Case | Example API |
|---|---|---|
| TMF Open APIs | Standardized OSS-BSS integration | TMF642 (Alarm Management), TMF639 (Resource Inventory), TMF638 (Service Inventory) |
| REST APIs | Custom OSS integrations | Inventory queries, service activation |
| Kafka / Event Bus | Real-time event streaming | Alarm notifications, telemetry streams |
| gRPC | Microservice communication | Real-time analytics, telemetry |
Traditional OSS integrations relied heavily on synchronous APIs and polling. Modern OSS increasingly uses event-driven architectures with Kafka, Pulsar, and streaming approaches that complement traditional APIs for near real-time operations.
End-to-End Flow: Interface in Action
Scenario: A router interface fails in a multi-vendor network
1. Southbound
gNMI/SNMP from router → EMS → Mediation → NMS
2. Processing
NMS correlates alarm, identifies impacted services
3. Northbound
TMF642 alarm to dashboard, Kafka to CRM, usage to BSS for SLA credits
The Mediation Layer - Southbound Enabler
Many operators use mediation layers between OSS and network devices to normalize protocols, enrich data, and manage device heterogeneity. OSS rarely talks directly to every device type.
Nokia EMS
Vendor-specific alarms and telemetry
Ericsson EMS
Proprietary event and KPI formats
Huawei EMS
Vendor-native device management
Normalize • Enrich • Deduplicate • Route
Without mediation, NMS sees incompatible vendor formats. Mediation creates a unified operational view, enabling multi-vendor OSS without custom adapters.
Why This Matters in Real Operations
Southbound Complexity
Every device vendor has different protocols, MIBs, YANG models. Mediation layers are essential for multi-vendor integration.
Northbound Standardization
TMF Open APIs reduce integration cost between OSS and BSS. Standardized interfaces accelerate time-to-market.
Customer Experience
Delays in OSS activation workflows directly impact customer onboarding and SLA commitments.
Protocol Migration
Legacy SNMP to modern gNMI usually requires phased migration. Operators often run hybrid environments for years.
Connection to BSS - Where Northbound Meets Business
Northbound interfaces are where OSS and BSS integrate. This is the critical business-engineering bridge.
Order to Activation
BSS sends order → OSS provisions → OSS returns confirmation
Usage to Billing
OSS collects usage → Mediation → BSS rates and invoices
Alarm to Notification
OSS detects fault → Northbound → CRM notifies customer
OSS → BSS
- Activation confirmations
- Usage records for billing
- Alarm notifications for CRM
- SLA breach events for credits
BSS → OSS
- Service orders (TMF641)
- Customer tier for prioritization
- SLA commitments for monitoring
- Product catalog for feasibility
Real Telecom Challenge: Multi-Vendor Integration
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.
• Nokia: "CPRI link down" (vendor-specific format)
• Ericsson: "eCPRI interface failure" (different format)
• Mediation: Normalizes both to "Transport Link Down"
• NMS: Single actionable alarm
Key Terms You Must Know
OSS to network devices (downward)
OSS to higher-level systems (upward)
BGP, OSPF, IS-IS - help packets find path (not management)
SNMP, NETCONF, gNMI - used by OSS to monitor/configure devices
Simple Network Management Protocol - legacy polling/traps
Network Configuration Protocol - modern config management
gRPC Network Management Interface - streaming telemetry
Transaction Language 1 - optical transport management
Standardized northbound APIs such as TMF642, TMF639, and TMF638
Normalizes vendor-specific data for NMS
Data modeling language for NETCONF/gNMI
Management Information Base - SNMP data structure
Common Questions
Q1. What is the difference between northbound and southbound interfaces?
Southbound connects OSS to network devices for telemetry, alarms, and configuration. Northbound exposes OSS data and capabilities to BSS, analytics, and higher-level systems.
Q2. What protocols are used at each network layer?
Physical: TL1/SNMP. Data Link: SNMP/NETCONF. Network: SNMP/NETCONF/gNMI. Application: REST/gRPC/TMF APIs. Routing protocols like BGP and OSPF are for forwarding, not management.
Q3. Why are southbound interfaces more complex than northbound?
Southbound must handle multiple device vendors, protocols such as SNMP, NETCONF, and gNMI, different data models, and legacy equipment. Northbound is easier to standardize with APIs such as TMF Open APIs.
Q4. What northbound protocols are used for real-time alarm notifications?
Kafka, gRPC streams, WebSockets, and TMF642-based alarm integrations are commonly used for near real-time alarm delivery.
Q5. Can the same OSS platform have multiple northbound interfaces?
Yes. For example, one OSS can expose REST APIs for inventory queries, Kafka for event streams, and TMF APIs for BSS integration.
Q6. What role does mediation play in southbound integration?
Mediation normalizes vendor-specific protocols and formats, enriches data, and routes it to the right OSS applications.
Q7. Which TMF API is used for alarm notifications?
TMF642 is the Alarm Management API and is commonly used in northbound alarm integration scenarios.
📌 Key Takeaways:
- Southbound (downward): OSS → Network devices. Protocols include SNMP, NETCONF, gNMI, CLI, and TL1. Purpose: collect data, push configs, and receive alarms.
- Northbound (upward): OSS → Higher-level systems such as BSS, analytics, and AIOps. Protocols include REST, TMF APIs, Kafka, and gRPC.
- Protocols per layer: Physical (TL1/SNMP), Data Link (SNMP/NETCONF), Network (SNMP/NETCONF/gNMI), Application (REST/gRPC/TMF APIs).
- Routing protocols such as BGP and OSPF are not management protocols.
- Mediation layers are critical for normalizing multi-vendor southbound differences.
- TMF Open APIs such as TMF642 (Alarm Management), TMF639 (Resource Inventory), and TMF638 (Service Inventory) are widely used for northbound OSS-BSS integration.
- Event-driven architectures such as Kafka and Pulsar complement traditional APIs for near real-time operations.
- East-West interfaces enable peer-to-peer communication between OSS domains.