Support Robotics detects fibre line faults by continuously monitoring router WAN state, ACS telemetry, and disconnect patterns. It validates the issue through automated diagnostics and user confirmation before triggering structured FNO escalation.
What Support Robotics Means in an FTTH Environment
Support Robotics is not a chatbot and not a marketing feature. It is an automated diagnostic ecosystem operating at the last metre — between the Optical Network Terminal (ONT), the router, and the user’s devices.
In a South African open-access environment where ISPs depend on Fibre Network Operators (FNOs), accurate fault isolation is critical. False escalation wastes repair time and increases downtime.
For the full context on how this fits into the broader support framework, see the Support & Diagnostics overview.
Support Robotics exists to:
- Detect abnormal signal behaviour
- Validate whether the issue is LAN, router, or access-layer
- Gate FNO escalation through structured diagnostic flow
This reduces unnecessary truck rolls and improves repair accuracy.
What Triggers Automated Detection
Support Robotics continuously observes device-level telemetry via ACS (Auto Configuration Server) integration. Detection triggers typically include:
- WAN disconnect events
- Repeated PPP session drops
- Device unreachable state
- Sudden loss of sync
- Reboot loops
These are not user-reported symptoms. They are system-detected anomalies. When an automated trigger fires, the Diagnostic Flow begins.
Step-by-Step Detection Workflow
Automated Trigger Detection
- System detects WAN down state, repeated reconnect attempts, or unusual disconnect frequency.
- Event is logged into the Ticket Lifecycle system.
- No escalation occurs yet.
Remote Validation via ACS Telemetry
- Support Robotics queries router WAN status, device reachability, session logs, sync behaviour, and historical disconnect patterns.
- If router is online but user reports no internet — issue is likely internal.
- If router is unreachable and WAN state shows failure — access-layer fault becomes possible.
App-Based User Validation
- If ambiguity exists, the system prompts: guided reboot sequence, cable verification, speed test distinction (WAN vs WiFi), and in-app diagnostic checks.
- This eliminates loose Ethernet cables, router placement issues, and internal network congestion.
- Automation confirms the fault category before human escalation.
Broadband-Down Fallback (Cellular Bridge)
- If fibre is completely offline, the support session continues via smartphone mobile data.
- Agent accesses router console remotely. Configuration and log inspection continues.
- This removes “offline blindness.” Diagnostics continue even when broadband is down.
Escalation Gating Decision
- Escalation to an FNO occurs only if: WAN state confirms no sync, router hardware is validated, user-side causes are eliminated, and repeated signal loss is confirmed.
- If confirmed, escalation proceeds through structured handoff — see When Does an ISP Escalate to an FNO?
- If not confirmed, issue remains ISP-side or customer-side and is resolved without FNO involvement.
Key Term: ACS Telemetry
Device-level performance and status data collected through Auto Configuration Server protocols (e.g., TR-069 / TR-369). This allows remote visibility into router state, WAN connectivity, logs, and configuration without requiring physical access.
How This Reduces Downtime
Without Support Robotics: the user calls support, manual questioning begins, a technician is dispatched prematurely, and the FNO ticket is opened incorrectly.
With automated detection: the fault is pre-classified, user-side issues are eliminated early, the FNO receives validated fault reports, and repair timelines shorten.
In South Africa’s multi-FNO environment, accurate escalation prevents repair delays caused by misclassified tickets.
Multi-FNO Context (South Africa)
UrbanX operates across infrastructure owned by:
- Vumatel
- Openserve
- Frogfoot
- MetroFibre
- Other regional FNOs
Because the ISP does not own the access layer, escalation must be precise. Support Robotics ensures:
- Clear responsibility boundary
- Accurate fault classification
- Reduced repeat calls
- Lower truck roll rates
It protects both operational efficiency and user experience.
What Support Robotics Does NOT Do
It does not:
- Interpret ONT light colours — see Fibre Troubleshooting
- Diagnose bufferbloat or jitter — see Gaming Performance
- Replace FNO repair processes
- Guarantee zero downtime
It validates fault origin before escalation.
When the User Notices Nothing
In some cases, disconnects are detected before users report them, repeated short drops are logged, and instability patterns are identified. This allows proactive contact or guided resolution before full outage occurs.
Automation shifts support from reactive to structured.