TMF642 - Alarm Management API
🎯 Learning Objective: Understand TMF642 - the industry standard API for managing network faults. Learn how to structure alarm data, manage lifecycle states (Raised to Cleared), and bridge the gap between network errors and customer billing.
What is TMF642?
TMF642 is a standardized "language" (REST-based API) that different systems use to talk about network problems. Instead of every vendor (like Nokia, Ericsson, or Cisco) having their own way of saying "the router is down," TMF642 provides a single template that everyone follows.
The "Doctor's Note" Analogy
Imagine if every doctor wrote prescriptions in a secret code. Pharmacists couldn't read them! TMF642 is like a standardized medical form. It ensures that when a 5G tower "gets sick" (raises an alarm), the NOC engineers, the Billing system, and the Customer Portal all understand exactly what is wrong.
Expose Alarms
Standardize alarms from the NMS (Network Management System) for higher systems.
Query Alarms
Search for specific problems using filters like "show only critical alarms in Mumbai."
Correlation
Expose relationships between root-cause and related alarms so engineers see one "Root Cause" instead of 1,000 separate errors.
BSS Integration
Provide alarm and outage information to SLA, customer care, and billing systems for impact analysis and potential compensation workflows.
It sits "above" the network. While devices use protocols like SNMP or gNMI (Southbound) to report errors, TMF642 exposes normalized, application-friendly alarm information for OSS, BSS, analytics, and customer-facing systems.
TMF642 does not directly communicate with routers, switches, or 5G network devices. Device-level alarms are usually collected through protocols such as SNMP, Syslog, NETCONF, gNMI, or vendor EMS/NMS platforms. OSS fault management systems normalize and expose those alarms through the TMF642 API.
Key Alarm Fields Explained
| Field | Description (Simplified) | Example |
|---|---|---|
| id | The unique "serial number" for this specific problem. | "alm-12345" |
| alarmRaisedTime | When the alarm was first raised (UTC time). | "2025-05-13T20:00:00Z" |
| severity | How bad is it? (critical, major, minor, warning). | "critical" |
| alarmType | What category of error? (Hardware, Software, Signal). | "EquipmentAlarm" |
| probableCause | The "Best Guess" of what broke. | "power-loss" |
| affectedResource | Which network resource or service is affected? | {"id":"router-01"} |
| state | Is it still happening? (raised, updated, cleared). | "cleared" |
In modern TMF API versions (v4+), severity values are typically lowercase
(critical, major, minor).
Legacy systems may use formats such as CRITICAL or Major.
Normalization services standardize these values before exposing them through TMF642.
TMF642 Alarm Object (JSON)
{
"id": "alm-67890",
"alarmRaisedTime": "2025-05-09T10:23:00Z",
"severity": "major",
"alarmType": "CommunicationsAlarm",
"probableCause": "loss-of-signal",
"specificProblem": "Radio Link Failure",
"affectedResource": {
"id": "res-1001",
"name": "mumbai-gnb-001",
"@referredType": "LogicalResource"
},
"state": "raised"
}
Real-World API Scenarios
Scenario 1: The "Flapping" Fiber Link
A fiber cable is loose. It goes down, then up, then down again 5 times in a minute.
- Initial Action: The fault management system uses POST to create the alarm
alm-888with stateraised. - The Change: The link recovers for 2 seconds. The system doesn't delete the alarm; it uses PATCH to update the
alarmChangedTimeand set state toupdated. - The Result: NOC engineers see one alarm with a "Repeat Count" instead of 10 different alarms clogging their screen.
Scenario 2: The 5G Site Power Outage
A lightning strike takes out the power to a 5G base station.
- Raw Events: 500 different "Cell Down" errors flood the system.
- Correlation: The Network Management System identifies that all 500 alarms are related to one site power failure instead of 500 separate problems.
- API Action: One "Parent" alarm is created: "Site Power Failure."
- The Field: The
correlatedAlarmsrelationship links the parent alarm to the related downstream alarms.
Alarm State Lifecycle
Alarms are never truly "Deleted" in telecom. They move to a cleared state but stay in the database for legal and audit reasons.
Standard API Commands
| HTTP Method | Endpoint | What it does |
|---|---|---|
| GET | /alarm | Shows a list of all current problems in the network. |
| POST | /alarm | Creates a new alarm when something breaks. |
| PATCH | /alarm/{id} | Used to "Acknowledge" an alarm or change its severity. |
| DELETE | /alarm/{id} | Rarely used. Alarms stay archived for compliance. |
In cloud-native OSS environments, alarm events are often streamed in real time through Kafka or event-driven pipelines into analytics, AIOps, observability, and customer-impact systems alongside TMF642 APIs.
Bridging to the Business (BSS)
Impact Analysis
The OSS uses the alarm to find which customers are affected (PSR Mapping).
SLA Refunds
The duration of the raised state is used to calculate bill discounts.
Customer Portal
The specificProblem field is what the customer sees on their mobile app: "Outage in your area."
Common Interview Questions
Q1. Why use TMF642 instead of raw SNMP traps?
Raw SNMP traps are low-level and often vendor-specific in structure, while TMF642 provides normalized alarm information in a standard JSON format.
Q2. What is the 'correlatedAlarms' field for?
It links secondary problems to a single Root Cause. For example, if a fiber cut causes 50 routers to fail, the 50 router alarms are correlated to the one fiber cut alarm.
Q3. What happens to an alarm when it is 'Cleared'?
The alarmClearedTime is set, the state becomes cleared, and it moves from the 'Active' dashboard to the 'History' log.
📌 Key Takeaways:
- TMF642 standardizes how we report and manage network faults.
- JSON structure makes it easy to share data with non-network systems (like Billing).
- Alarm Correlation helps reduce noise and improves root-cause visibility in large NOC environments.
- Lifecycle states (Raised -> Cleared) are essential for tracking SLA uptime.