Cellular connectivity (LTE / 5G)
Cellular Connectivity (LTE / 5G) – definition
Cellular connectivity is a wireless wide-area networking method in which a mobile robot connects to an operator network through a cellular modem, a SIM or eSIM profile, and radio access technologies such as LTE or 5G New Radio (NR). For an unmanned ground vehicle (UGV), the cellular link typically provides IP connectivity between the robot, remote operator, cloud services, VPN gateway, fleet-management system, or ROS 2 nodes running outside the vehicle.
LTE was standardized by 3GPP beginning with Release 8. 5G NR was introduced in 3GPP Release 15 as the first phase of the 5G system specification. Both technologies can transport standard IPv4 and IPv6 traffic, so they are commonly integrated as Ethernet-like uplinks for robot computers rather than as a dedicated robotics protocol. Source: 3GPP Releases
On Leo Rover or Raph Rover, cellular connectivity is normally an optional communications layer. It does not make the platform autonomous. Local sensing, state estimation, obstacle avoidance, and safety functions should remain available when the mobile network becomes unavailable, congested, or changes IP address.
LTE and 5G in a mobile robotics network
A cellular-connected UGV contains a user equipment (UE) modem. The modem registers with a public or private cellular network and exposes an IP interface to the onboard computer. Depending on the modem and carrier configuration, that interface may be presented through USB, Ethernet, PCIe, or a serial control channel plus a separate network device.
The practical network path is usually more complex than a direct robot-to-operator connection. Carrier-grade NAT (CGNAT), dynamically assigned addresses, firewall rules, and radio handovers can prevent unsolicited inbound traffic to the robot. A VPN with a robot-initiated outbound connection is therefore a common architecture for remote SSH access, telemetry, ROS 2 bridging, and secure access to web interfaces.
| Attribute | Relevance to UGV operation | Reference |
|---|---|---|
| LTE radio technology | Specified by 3GPP from Release 8; commonly used where 4G coverage is available. | 3GPP Release 8 |
| 5G NR radio technology | Introduced in 3GPP Release 15; may use non-standalone or standalone deployment architectures. | 3GPP Release 15 |
| RSRP, RSRQ and SINR | Radio measurements used to assess received signal level, received quality, and signal-to-interference-plus-noise conditions. | 3GPP TS 36.214; 3GPP TS 38.215 |
| IP address allocation | May be public, private, or behind CGNAT. It determines whether inbound connections are feasible. | IETF RFC 6598 |
Cellular connectivity with ROS 2
By default, ROS 2 nodes communicate through a middleware implementation based on DDS. On a local Ethernet or Wi-Fi network, DDS discovery can use multicast. Mobile carrier networks usually do not forward multicast traffic between the robot and a remote workstation. Nodes on opposite sides of an LTE or 5G connection may therefore fail to discover each other automatically.
For remote ROS 2 operation, a VPN or an explicitly configured discovery mechanism is more predictable than exposing DDS ports directly to the public Internet. ROS 2 also provides Quality of Service (QoS) policies for reliability, history, durability, deadline, lifespan, and liveliness. These policies should match the data type and expected link behavior. Source: ROS 2 QoS documentation
Command topics should be handled differently from high-volume sensor streams. A velocity command is small but time-sensitive. A point cloud, depth image, or uncompressed camera topic can saturate an uplink or create queueing delay. It is generally safer to run navigation and emergency-stop logic locally and transmit selected diagnostics, compressed video, mission status, and low-rate map updates.
# Verify the cellular interface and route on the onboard computer
ip addr show
ip route
# Measure reachability through the active cellular path
ping -c 4 1.1.1.1
# Inspect ROS 2 graph after VPN or discovery configuration
ros2 node list
ros2 topic list
Key integration parameters
Cellular performance must be measured at the intended operating site. Nominal modem throughput is not a guaranteed field result. Coverage, antenna placement, carrier spectrum, cell loading, terrain, weather, mobility, and handovers affect usable bandwidth, packet loss, jitter, and round-trip time.
During integration, record the following parameters over representative missions:
- radio measurements reported by the modem, including RSRP, RSRQ and SINR;
- uplink and downlink throughput, measured separately;
- round-trip time, jitter and packet loss to the VPN endpoint or control server;
- reconnection time after coverage loss or modem reset;
- data usage for video, telemetry, software updates and map transfer;
- antenna location, cable loss, grounding and separation from high-current motor wiring.
A useful bandwidth estimate for a camera stream is:
bitrate [bit/s] = image_width × image_height × bits_per_pixel × frame_rate
This formula describes uncompressed payload data only. Transport headers, encoding overhead, retransmissions, and metadata add further traffic. Compression can reduce bandwidth, but it also adds CPU load and may increase end-to-end latency.
Use on Leo Rover and Raph Rover
Leo Rover uses an onboard Raspberry Pi compute unit and can be used with ROS 2. Supported ROS 2 distributions depend on the installed software image and platform documentation. A USB LTE or 5G modem can provide a backhaul link for remote access, telemetry, field experiments, or an RTK correction client. The modem should be evaluated for Linux driver support, power consumption, antenna connectors, and compatibility with the selected carrier bands. Source: Leo Rover technical documentation
Leo Rover has four-wheel differential drive and is rated IP55. Cellular equipment, external antennas, USB enclosures, and cable entries must not compromise the platform enclosure or interfere with payload mounting. Source: Leo Rover technical documentation
Raph Rover can carry larger payloads and may accommodate a higher-power compute unit, industrial router, multi-SIM modem, or additional antenna system. This is useful for long-duration inspection or agricultural deployments, but it does not remove the need for local autonomy and safe degraded behavior.
Limitations and operational considerations
LTE and 5G links are not deterministic control buses. They should not be the only communication path for safety-critical stopping or collision avoidance. A UGV must define behavior for loss of link, high latency, stale commands, VPN failure, SIM expiry, and transitions between radio cells.
For remote operation, use authenticated access, encrypted tunnels, firewall rules, key rotation, and software update procedures. Avoid publishing ROS 2 middleware traffic directly to the Internet. Network segmentation is also recommended when the robot carries cameras, GNSS receivers, LiDAR sensors, or third-party payload computers.