A moving broadband connection succeeds when the application keeps doing useful work along the route. Plan the trial around completed transactions, interruption length and recovery. A fast result while parked is a baseline; the moving trial answers a different question.
Set the acceptance question first
Write one sentence that names the route, application and acceptable interruption. For example: “On the depot-to-site route, a status message should reach the test server within the agreed deadline, and queued messages should arrive after service returns.” Set the deadline with the application owner before testing. There is no universal acceptable delay for every workload.
Ericsson’s wireless WAN testing explanation distinguishes throughput, latency and jitter. Include those measurements when relevant, but tie the acceptance decision to the application’s result. A ping reply and a successfully saved job record demonstrate different things.
Make runs comparable
- Record the route and direction, date and time window, modem and antenna arrangement, firmware, carrier and plan, application version and test endpoint. Keep these constant when comparing runs.
- Synchronize logger and server clocks. Choose a regular probe interval and record both sends and acknowledgments. Use a test account and non-sensitive payloads.
- Run a parked baseline with the same equipment and endpoint. Confirm the logging system itself records failures and late replies.
- Collect moving results through unattended logging or a passenger. The driver should concentrate on driving and follow ordinary road conditions.
- Repeat the route in each required direction and during relevant operating periods. Record detours and configuration changes rather than combining them silently.
Map position only as precisely as needed for troubleshooting, and limit access to logs that reveal journeys. Confirm permission and data allowances for repeated network tests.
Record failures as well as successes
On a narrow screen, scroll the table sideways. Keyboard users can focus the table and use the arrow keys.
| Field | Record | Why it matters |
|---|---|---|
| Run and location | Run ID, direction, timestamp, segment or authorized position | Makes repeat failures comparable. |
| Task outcome | Transaction ID, send time, acknowledgment time, deadline result | Separates useful completion from radio association. |
| Interruption | First failed attempt, last failure, first successful recovery | Shows the observed failure window at your sampling interval. |
| Recovery | Automatic/manual; backlog delivered; duplicate or lost records | Tests what happens after coverage returns. |
| Context | Cell or link change if available, signal metrics, VPN event, server error | Supports diagnosis without assuming every failure is radio coverage. |
Download the plain-text route-test worksheet and fill in the configuration and acceptance criteria before the first run. Store detailed transactions in your logger’s export; the worksheet is a run summary.
Interpret a gap without overstating precision
Illustrative example: probes are sent once every 5 seconds. A success occurs at 12:00:00, failures occur at :05, :10 and :15, and success returns at :20. The observed success-to-success gap is 20 seconds. The exact failure onset and restoration lie between samples; report the sampling interval with the result. Continuous application logging may give finer timing.
Also report the longest observed gap, failed-deadline count divided by attempts, and whether the application recovered automatically. Separate delayed messages that eventually arrived from messages lost altogether. Avoid labeling a route reliable from an average throughput result that conceals a repeated dead segment.
If the same segment fails across runs, compare client and server logs. If parked baseline tests also fail, investigate the endpoint, account or device first. After a configuration change, repeat the affected route with a new run ID. Record “accepted for this workload,” “needs remediation” or “more evidence required,” together with the test conditions.