# How Support Robotics Detects Fibre Line Faults

Source: https://urbanx.co.za/knowledge-hub/support-diagnostics/support-robotics-fibre-faults

**Answer:** 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.

Part of [Gamer-Centric Support & Intelligent Diagnostics](https://urbanx.co.za/knowledge-hub/support-diagnostics) · 9 min read · by UrbanX Support Engineering

## 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](/knowledge-hub/support-diagnostics/article).

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

> **INFO:** 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

> **WARNING:** 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

1. **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.
2. **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.
3. **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.
4. **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.
5. **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?](/knowledge-hub/support-diagnostics/isp-escalate-to-fno)
   - If not confirmed, issue remains ISP-side or customer-side and is resolved without FNO involvement.

## Key Term: ACS Telemetry

- **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.

> **INFO:** 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

> **TIP:** It protects both operational efficiency and user experience.

## What Support Robotics Does NOT Do

It does not:

- Interpret ONT light colours — see [Fibre Troubleshooting](/knowledge-hub/fno-troubleshooting/article)
- Diagnose bufferbloat or jitter — see [Gaming Performance](/knowledge-hub/gaming-performance/article)
- 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.

> **INFO:** Automation shifts support from reactive to structured.

## Frequently Asked Questions

**Does Support Robotics fix fibre line faults automatically?**

No. It detects and validates faults before structured escalation.

**Can it detect problems even if my internet is completely down?**

Yes. Diagnostics can continue via cellular bridge through the support app.

**Does this replace FNO repair?**

No. It ensures only verified access-layer faults are escalated.

**What if the issue is inside my home network?**

The system isolates LAN or router issues before any escalation.

**Why is escalation sometimes delayed?**

Escalation requires confirmation that the issue is access-layer, not user-side. This prevents incorrect FNO tickets.