A remote connection is not validated by one signal reading or one speed test. Commissioning should prove that the actual application works under expected conditions and that the design behaves acceptably when a link or component fails.
Define what “working” means
Start with measurable application acceptance criteria. Examples include successful delivery of telemetry with correct timestamps, visible alarms, completion of image uploads, stable remote access, or a usable live-video session under defined test conditions.
State how much interruption is acceptable, what should recover automatically, what data must be retained and which evidence must be recorded. Do not use “internet available” as the only criterion.
Establish a baseline
Record the installed configuration before introducing failures:
- power supply and measured input where appropriate;
- router, modem, firmware and configuration version;
- SIM, operator, serving cell and band where available;
- antenna model, ports, orientation, cable and connectors;
- RSRP, RSRQ and SINR over time;
- IP addressing, DNS, VPN and application endpoints;
- upload/download, latency and packet loss measurements;
- actual application results and logs.
The baseline provides something to compare when the connection later changes.
Test more than peak speed
Run upload and download tests relevant to the application. Measure latency and packet loss where practical, and observe variation rather than recording only the best result.
The IETF defines packet-loss and delay metrics separately and recommends reporting both for network characterisation (RFC 6703). Round-trip loss measurement guidance also notes that common tools may treat test traffic differently from application traffic (RFC 6673). Use network tests as evidence, then verify the real application.
Observe stability
Operate the system through representative periods and traffic conditions. Look for modem reconnects, changing cells or bands, power events, rising error counts, data queues and application-session resets.
There is no universal commissioning duration. The observation period should be long enough to cover relevant operating cycles and known variation, subject to project risk and practical constraints.
Test the application under load
Run expected combinations of sensors, dashboards, uploads and video. Confirm that high-volume traffic does not block alarms or control messages. If local buffering is used, create a controlled interruption and confirm that queued data is delivered correctly after recovery.
Test failure and recovery
Where the design uses multiple links, deliberately remove one link at a time under controlled conditions. Examples include disconnecting the primary WAN, disabling a cellular modem or using a safe test method to make the primary path unavailable.
Record:
- how failure is detected;
- whether the backup was already active or had to register;
- time and application behaviour during switchover;
- whether sessions restarted or persisted;
- what happened to queued data;
- how and when the system returned to the preferred link;
- logs and alerts generated by the event.
Do not describe a result as seamless unless the specific application remained continuous under the documented test conditions.
Recommended troubleshooting sequence
Troubleshoot one layer at a time so that changes remain traceable.
1. Power
Check supply voltage, connectors, protection devices, backup state and router event logs. Intermittent power can look like a network fault.
2. Router and modem state
Confirm boot state, temperature or alarms, modem detection, firmware and recent restarts. Preserve logs before rebooting where possible.
3. SIM and network
Check SIM status, account/service, registration, selected operator, roaming policy and data allowance. Test the SIM in a known-compatible device only if the procedure is controlled.
4. Radio metrics
Record RSRP, RSRQ and SINR together with cell and band information. Look for variation, not only one reading. Use Understanding RSRP, RSRQ and SINR for interpretation.
5. Antenna and cable
Inspect port selection, connectors, cable damage, water ingress, orientation, mount movement and obstruction. Compare against the installation record.
6. IP and data connectivity
Check address assignment, gateway, DNS, routing, firewall, VPN and reachability to the intended endpoint. Distinguish a DNS failure from loss of the WAN itself.
7. Application
Inspect device, gateway and platform logs. Confirm credentials, protocols, timestamps, queues, storage and endpoint availability.
8. Redundancy behaviour
Check health-detection rules, WAN priorities, SIM switching, failover/bonding state and recovery policy. A backup link that works manually may still fail to activate automatically.
Record evidence and decisions
Use a commissioning record with configuration versions, timestamps, test method, conditions, results, screenshots or logs where useful, observed limitations and accepted exceptions. Tie every acceptance decision to the operating requirement.
Continue from How to Assess Mobile Connectivity at a Remote Site for pre-deployment evidence and Single SIM, Failover, Load Balancing and Bonding for the resilience terms being tested.
Frequently asked questions
Why does a remote 4G connection keep dropping?
Possible causes include power, modem or firmware state, SIM/service, marginal or changing radio conditions, antenna/cable faults, congestion, router policy or the application path. Follow a sequence and preserve evidence.
How should a remote router be tested before deployment?
Test radio conditions, upload/download, latency/loss where practical, stability, the real application, power recovery and any configured failover or bonding behaviour.
Is one speed test enough?
No. It is a short sample to one destination and does not establish stability, application behaviour or recovery.
How can failover be tested?
Create a controlled primary-link failure, observe detection and backup activation, test the application, restore the link and record recovery/failback. Use safe procedures appropriate to the equipment.
How can a remote site avoid depending on one telco?
Test usable services from more than one operator, then select hardware and a switching or multi-link architecture that can use them as required. Different operator names do not prove independent infrastructure, so record shared site, power, backhaul and equipment dependencies where they are known.
Should failover and bonding be tested in the same way?
They share baseline and failure-recovery checks, but the expected behaviour differs. Failover testing should verify detection, backup activation, interruption and failback. Bonding testing should verify the selected implementation’s link use, peer or tunnel dependency where applicable, application-session behaviour, degraded-link handling and recovery.
How do I know whether a problem is caused by signal, router or network?
Compare power and device logs, registration, radio metrics, antenna path, IP tests and application results in order. Testing another operator or known configuration can help isolate the layer when done systematically.
How long should remote connectivity be tested before commissioning?
Long enough to cover the operating cycles and variation relevant to the project. The duration depends on risk, application, network behaviour and acceptance plan; there is no universal period.