Network Configuration

Last validated: 2026-05-05

Oden is designed for real teleoperation networks, not only clean lab networks. A vehicle may have cellular modems, satellite, Wi-Fi, Ethernet, or a site VPN available at different times. Good Oden deployments use those paths deliberately so a weak link does not become the whole system.

The goal is simple: keep video, audio, and control connected through the best available paths, and prove during testing that the paths are actually active.

For the exact Oden link fields, see Network.

Cellular networks fail in local, boring ways: one carrier is congested, one modem roams, one antenna is shadowed, or one area has coverage from a different provider. Satellite and Wi-Fi solve different parts of the map. Oden can combine several links so the vehicle keeps a usable path when any one access network is weak.

Use multiple links when:

  • The vehicle can connect through more than one modem, carrier, satellite terminal, Wi-Fi network, or routed interface.

  • Operators need coverage across a large site or route instead of one fixed test area.

  • A deployment must degrade gracefully rather than drop the session when one link changes.

Do not stop at adding links in the project. During commissioning, verify that each physical link carries traffic when the matching network is available.

On the vehicle, each link should describe one real egress path.

  1. Add one Oden link per modem, adapter, tunnel, relay, or intended route.

  2. Give each link a name that maps to hardware or network ownership, for example cellular-a, cellular-b, satellite, or depot-wifi.

  3. On Linux, use Bind Device or a specific bind address when traffic must leave through one interface.

  4. Use a separate destination port per link unless the network design intentionally shares a port.

  5. Keep links for the same stream in the same bonding group when they should contribute to the same video/control path.

  6. Save the Streamer project after validating the link state.

For service installs, restart the vehicle service after changing the project:

sudo systemctl restart oden-streamer.service
sudo systemctl status oden-streamer.service

On the operator side, the Player or OdenVR project must have matching receiver links.

  1. Create one Remote Streamer link for each vehicle-side link path.

  2. Match the receive ports and relay/P2P/encryption settings to the vehicle-side configuration.

  3. Leave the operator bind address broad unless the workstation has multiple interfaces and routing must be explicit.

  4. When using the portal fleet flow, let Fleet Client create or update the session links unless support has given you a project-specific reason to override them.

  5. Verify Remote Streamer link stats while a real session is running.

For operator layout and visible-camera behavior, see Project Configuration and Bitrate Control and Auto Video Packing.

The most common multiple-link problem is believing that there are multiple active links because they exist in the project. Treat that as unproven until you see traffic on each intended path.

Run these checks during commissioning:

  • Disable or unplug one access network at a time and confirm the session stays connected through the remaining links.

  • Watch Remote Streamer link stats and confirm bytes, packet timing, and loss change on the expected link.

  • Check OS routing from the vehicle computer so each modem/interface has a usable default or policy route.

  • Confirm the configured Bind Device, bind address, destination address, and destination port match the physical path.

  • Check firewall and NAT rules on every path, especially when one link works and another stays idle.

  • Test fallback in the same geography where the vehicle will actually operate.

If one link never carries traffic, simplify the test: run a single-link project through that path, prove routing and firewall behavior, then re-add the link to the bonded setup.

For support evidence, capture portal active state, Oden version, Streamer service logs, Remote Streamer link stats, and the network hardware list. See Diagnostics and Recording for the broader checklist.