Technical Knowledge · Remote Site Connectivity

Designing Connectivity for Sensors, Monitoring Cameras and Live Video

How telemetry, dashboards, still images, recorded media and continuous live video create different remote connectivity requirements.

Sensor telemetry, monitoring dashboards, still images, recorded video and continuous live video place different demands on a remote connection. A sound architecture separates these traffic types before deciding on bandwidth, resilience or equipment.

Begin with the application flows

Use Remote Site Connectivity: Start With the Operating Requirement to list every source, destination and user. Record whether each flow is periodic, event-driven, requested by a user or continuous.

The design should also state which traffic is operationally critical. An alarm may contain only a small message but be more important than a large routine image upload.

Sensor and telemetry data

Sensors often produce small readings at defined intervals. A local gateway can collect them, apply timestamps and send batches to a platform. Where the application permits it, local buffering or store-and-forward behaviour can protect data during a temporary outage.

Key questions include:

  • How often are readings generated?
  • Must every reading arrive, or is an aggregate acceptable?
  • How quickly must an alarm arrive?
  • How much local storage is available?
  • How does the system detect and report a communications gap?
  • Can remote commands safely be queued or repeated?

Low average data volume does not remove the need for stable power, secure remote management and a defined recovery process.

Remote dashboards and polling

A dashboard may receive pushed data, poll a site gateway or combine both. Frequent polling can create more traffic and connection activity than the payload alone suggests. Multiple users or automated systems may also query the site at the same time.

Prefer an architecture that avoids exposing field devices directly to the public internet. Use supported secure connectivity, authentication and access controls appropriate to the system design.

Still images and periodic camera uploads

Still images are larger than typical telemetry but do not always need a continuous connection. The site may capture an image on a schedule or event, compress it, queue it and upload when the link is available.

Define image size, frequency, retention and how the system handles a growing queue. A design that works during normal operation may fall behind after a long outage unless recovery traffic is controlled.

Recorded video transfer

Recorded clips can be transferred after an event or on a schedule. The network requirement depends on clip length, encoding, resolution, bitrate, retention and the time allowed for delivery. Local recording can preserve evidence when the WAN is interrupted, but storage health and retrieval must be monitored.

Continuous live video

Live video creates a sustained uplink. The stream’s encoded bitrate is a central planning input, but real traffic can vary with scene complexity, codec settings and transport overhead. Latency, packet loss, variation and session continuity can affect the viewing experience even when average capacity appears adequate.

Do not invent a universal bandwidth figure. Obtain the camera/encoder configuration, observe the real stream and test it across representative conditions.

Remote cameras and sensors send data away from the site. Mobile and satellite services may offer different upload and download behaviour, and capacity can vary over time. Test the actual uplink path to the intended platform rather than relying on a download-only result.

Possible designs include:

  • one cellular connection with local buffering for tolerant telemetry;
  • multiple mobile operators with failover for important monitoring;
  • a fixed service where available, with cellular backup;
  • cellular with Starlink or another satellite service;
  • active multi-link or bonding for applications that justify coordinated resilience.

Cellular and Starlink may be combined in the same multi-WAN design, subject to equipment, service and site conditions, but the mode should be explicit. Primary/backup, traffic steering, load balancing and bonding do not provide the same behaviour. See Single SIM, Failover, Load Balancing and Bonding.

Prioritise essential traffic

If sensors and cameras share the connection, define traffic priorities. Essential alarms or control traffic should not be crowded out by a large upload. The implementation may use queues, rate limits, separate networks or application scheduling, subject to the router and system capabilities.

Validate the combined application

Test normal and degraded conditions:

  1. telemetry and alarms alone;
  2. image or video traffic alone;
  3. all expected traffic together;
  4. recovery after a queued-data backlog;
  5. one WAN link removed where redundancy is used;
  6. power interruption and restart;
  7. remote access while other applications are active.

Measure success in application terms: readings arrive with correct timestamps, alarms are visible, images complete, video remains usable under the tested conditions, and recovery does not corrupt or silently discard data.

Turn those application outcomes into a recorded acceptance and failure-recovery test using How to Test and Troubleshoot Remote Site Connectivity Before Deployment.

Frequently asked questions

How can sensor data be sent from a remote site?

A sensor or gateway can send data through cellular, fixed or satellite connectivity to a platform. The design should define message frequency, buffering, security, destination and recovery after interruption.

How much internet does a sensor monitoring site need?

It depends on payload size, frequency, protocol overhead, remote access and other shared applications. Calculate from the actual data model and validate it rather than applying one standard value.

Is CCTV connectivity different from sensor connectivity?

Usually. Cameras may generate sustained or large uplink traffic, while sensors often send smaller periodic messages. Their time sensitivity and tolerance for buffering can also differ.

Why is upload speed important for remote cameras?

The camera sends images or video from the site to viewers or a platform. Sustained uplink capacity and stability therefore affect delivery.

They can be combined using suitable multi-WAN or bonding equipment. The operating mode and benefit depend on service conditions, power, installation, cost, application and tested failure behaviour.

Does live video require bonding?

Not always. A single stable link may meet the requirement. Bonding or another multi-link method may be useful when the application needs additional capacity or resilience, but the decision should follow testing and interruption tolerance.

Technical references