Network Monitoring, Diagnostics, and Performance Analysis
What this domain tests
Domain 6 asks how you prove a system is healthy and how you localise a fault quickly, from SNMP traps and site alarms to channel-loading statistics and audio-quality scores.
Core rules
- Two monitoring layers: fault management (alarms, SNMP v3 traps, syslog, site power, generator, battery, temperature, door, tower light) and performance management (KPIs trended against a baseline).
- RF KPIs: RSSI, bit error rate, control-channel activity, channel busy percentage, access denials (busy or unauthorized), call setup time, PTT latency, queued and dropped calls, audio quality (DAQ or PESQ).
- Transport KPIs: microwave or fiber latency, jitter, packet loss, QoS/DSCP marking, and NTP plus GPS timing health for simulcast.
- Isolate before you fix: is the fault at one site or system-wide, one talkgroup or all, one subscriber or everyone? Compare against the last known good baseline.
- Confirm with instruments: a service monitor for deviation, sensitivity and power; a spectrum analyzer for interferers and desense; a site sweep for feedline and antenna; BER tests for backhaul.
- Correlate alarms so a single power event does not open fifty tickets.
Worked example
At the 16:00 shift change, officers at one site hear a bonk on PTT but audio is clean after 18:00, and other sites are fine. The pattern indicates channel exhaustion, not RF. Pull busy-hour statistics: if channel busy exceeds the design grade of service and every denial is busy, the site is overloaded. Adding a traffic channel, rebalancing talkgroups or adding a site fixes it. If the denials were unauthorized, you would look at provisioning instead.
Traps
Chasing an RF explanation for a capacity symptom, treating a single drive test as proof of health, ignoring GPS or timing alarms that precede simulcast audio complaints, and rebooting equipment before capturing logs.