Loss locus · v3.8
One ticket, two opposite actions

Should you send
a technician?

Every “my internet is bad” ticket ends in one of two decisions, and they are opposites. Roll a van, or talk the customer through their own wiring. Getting it wrong is the most expensive routine mistake a support desk makes — and until now the network could not tell you which it was.

2
directions measured, not one
3
answers: dispatch, advise, or don’t know
0
truck rolls for a Wi-Fi problem
100%
of unmeasured cases labelled as such

A van sent to a fault inside the customer’s house costs you the visit, the engineer’s afternoon, and the customer’s confidence — because they watched somebody arrive and find nothing.

The reason it keeps happening is not carelessness. It is that the evidence genuinely was not there. A subscriber losing packets looks identical whether the fault is on their access line or on their own Wi-Fi, and a support agent has to decide anyway. This is the measurement that separates them.

What the gateway can actually see

The subscriber’s router already sends the BNG a small keepalive on its own schedule. Reading it tells us the state of the line in the upload direction, for free, on encrypted traffic, without touching the customer’s data. But a line broken only in the download direction passes that test perfectly.

So the gateway now sends its own probe and waits for the reply. A missing reply is loss in either direction — and applied where the upload leg is already known clean, a lost round trip means the download direction is at fault.

BNG our gateway Router the CPE The home Wi-Fi, wiring, devices THE ACCESS LINE keepalive — upload only always there, costs nothing, sees one direction our own probe — there and back nothing we send reaches past here so “past the router” is where measurement stops
Two instruments, two reaches. The keepalive is free and always present but reads one direction. The probe reads both, which is what makes the split possible. Neither reaches past the customer’s router — which is exactly why the third verdict below is worded the way it is.

Three answers, and only one of them is a van

Line fault → dispatch

The line is measurably impaired, in the upload direction or the download direction or both. Two independent signals agree. This is the strongest evidence the network can produce, and it is the one the engineer should be sent on.

Past the router → advise

The line carried our probe in both directions and it is still losing packets. The fault is beyond the customer’s router — their wiring, their Wi-Fi, or the router itself. A visit will find a working line.

Not measured → say so

The probe is not running on that gateway, or the subscriber is not on PPPoE, or there are too few samples to call it yet. The verdict is withheld. This is not the same as “no fault found”, and the screen never renders it as one.

What it looks like on the desk

The dispatch-or-investigate panel: per gateway, a count of subscribers losing packets split into line faults marked DISPATCH and downstream cases marked INVESTIGATE FIRST, with the unmeasured categories held separately under a heading reading NOT A CLEAN BILL.
The split, per gateway, never averaged across the fleet. The dispatchable count sits apart from the ones to investigate. Underneath, the subscribers nobody can judge are kept in their own block headed not a clean bill — because a subscriber whose line was never measured is not a subscriber whose line is fine.

The line we will not cross

We do not label anything “the customer’s fault”. “Past the router” establishes two facts and no more: the loss is beyond our gateway, and the line carried our probe both ways. It cannot tell home Wi-Fi from the customer’s own router dropping traffic, and it never claims to. An agent told “this is their Wi-Fi” who is then proved wrong has been made less able to help, not more.

The counters are honest about their own resolution. The probe runs once every ten seconds, so it takes roughly seventeen minutes of a subscriber’s session before it can resolve one percent of loss. It finds a badly broken download direction, not a marginal one — and where it has too few samples, it stays quiet instead of guessing.

Why an operator should care

The visit you did not make

Every ticket correctly routed to “advise” is an engineer’s half-day returned to the schedule, and a customer who got an answer on the first call.

The visit you did make

When the verdict is a line fault, the engineer arrives already knowing the line is measurably impaired and in which direction. Fewer no-fault-founds.

The one you were not sure about

Held as unknown rather than guessed. A monitoring system that admits its limits is the only kind whose confident answers are worth anything.

What it needs

RequirementDetail
Subscriber typePPPoE — the keepalive is a PPP-layer message, so IPoE sessions cannot be split this way
Gateway softwareBNGSOFT XDP BNG v3.8, with the access-leg instrument enabled
The active probeOff by default; enabled per gateway when you want the download-direction split
Subscriber dataNone. The measurement reads the router’s own keepalives and our own probe — never the customer’s traffic

Roll it out where it pays. The split is validated as an instrument and is deliberately marked informational until it has soaked against real subscriber lines on a production gateway. Dispatch decisions stay on the line-fault verdict until then — which is how a measurement earns its way into an operational decision, rather than being trusted because it is new.

BNGSOFT · Loss locus · part of the subscriber-quality stack on the BNGSOFT XDP BNG.
The screen in this document is from a live deployment; gateway names, operator names and subscriber identifiers have been replaced throughout.