Networks and Addressing¶
This page answers three questions that a customer's IT department asks before a robot is allowed into their building, and that our own technicians ask on the first morning of a commissioning: which segments exist, which ports have to be open, and in which direction.
The short answer to the second and third question together is the one worth remembering:
No inbound port at the customer site
Nothing has to be opened towards the robot from the outside. Every connection that leaves the site is established from the inside out — the device pulls, nobody pushes. That holds for telemetry, for software updates and for remote support alike. A customer whose firewall permits outgoing HTTPS already permits everything we need.
1. The three segments¶
| Segment | What lives there | Who may reach it |
|---|---|---|
| Robot segment | The chassis, the Gateway (a Raspberry Pi) and the tablet of one robot. A dedicated WLAN, or a VLAN of the house network. | The Gateway and the tablet. Nothing else, if the house can arrange it. |
| Site segment | The customer's own network: the u-IoT module, door and lift hardware, a site server where one exists. | The Gateway, for the few addresses that are configured. |
| Outside | AWS in the Frankfurt region: IoT Core, S3, the enrolment endpoint. | The Gateway, outbound only. |
The reason for the separation is not elegance. The chassis interface on port 8090 has no authentication of any kind — anyone who can reach it can drive the robot. That is a property of the vendor's device and we cannot change it; we can only decide who is able to reach it. Everything below follows from that one sentence.
2. Every port, one table¶
Direction is given from the point of view of the device that has to be reached.
| From | To | Port | Protocol | Purpose | Evidence |
|---|---|---|---|---|---|
| Gateway, tablet | Chassis | 8090 TCP | HTTP + WebSocket | The only way to read state and to move the robot. GET /device/info, POST /chassis/moves, ws://…/ws/v2/topics. |
MEASURED |
| Tablet, browsers in the robot segment | uGo server on the Gateway | 5173 TCP | HTTP | The operator surface, full scope. Binds to all interfaces. | MEASURED |
| The maintenance proxy on the Gateway itself | uGo server, second socket | 5174 TCP | HTTP | Read-only view for remote support. Binds to 127.0.0.1 and is not configurable — it is unreachable from the site network by construction. See Remote Support. |
MEASURED 27.08.2026 |
| Gateway | Gateway (peer robots) | 45301 UDP | Fleet heartbeat, broadcast 255.255.255.255 |
Two seconds per beat, HMAC-SHA256 with a per-site key. Where broadcast is filtered, a list of unicast addresses is configured instead. | MEASURED |
| Technician laptop | Gateway | 22 TCP | SSH | Commissioning and service. In the robot segment only. | practice |
| Technician laptop | Tablet | 5555 TCP | adb | Only while the kiosk shell is being installed. Switched off afterwards. | practice |
| Gateway | *-ats.iot.eu-central-1.amazonaws.com |
8883 TCP, fallback 443 | MQTT over TLS, client certificate | Telemetry, faults, update jobs, device shadow. On 443 the ALPN identifier x-amzn-mqtt-ca is required. |
MEASURED |
| Gateway | S3 in eu-central-1 |
443 TCP | HTTPS | Update packages and map backups, always through short-lived pre-signed URLs. | MEASURED |
| Gateway | The enrolment endpoint | 443 TCP | HTTPS | POST /anmeldung, once per device, at our premises before delivery. |
MEASURED |
| Gateway | AWS IoT Secure Tunneling | 443 TCP | TLS | Remote support. Outbound, and only while a session is open. | design |
| Gateway | Accessibility services (door, lift, level change) | 3100 TCP · door control 8080 TCP | HTTP | Where those services run on the same Gateway, this is loopback traffic and crosses no network at all. | NOTE read from the services' own configuration, not measured on a site |
| Gateway | Voice service | 3001 TCP | HTTP | The conversational assistant, see Voice and Language Models. | MEASURED 27.08.2026 |
| Gateway | u-IoT module | OPEN | HTTP | The module's interface description is still outstanding; the address is configured per site, the port is taken from that address. | OPEN |
| Gateway | Lift controller | OPEN | vendor-specific | Depends on the installed controller. For the ELFIN gateway it is configured per site. | OPEN |
What is deliberately absent from this table¶
A port for the cloud towards the robot. There is none, and there will be none. The cloud reaches a device only through a topic the device itself has subscribed to, and from that direction the device accepts exactly two messages — a version release and a stop. Everything else is discarded and logged. See URG cloud.
A port for remote support towards the robot. Also none. The tunnel is established from the device, the technician meets it in the middle at AWS, and it closes on its own.
3. Addressing¶
The identity of a device is its chassis serial number, never its address. The serial number is the thing name in the cloud, the client identifier of the MQTT connection and part of every topic path. An IP address is a property of the current network and changes when a customer restructures their WLAN; a robot that identifies itself by address loses its identity the moment that happens.
| Which device | How it gets its address | Why |
|---|---|---|
| Chassis | Fixed reservation on the customer's DHCP server, keyed to its MAC address | The Gateway must find it after every restart, and the vendor's device offers no discovery we could rely on. |
| Gateway | Fixed reservation as well | The tablet points at it. |
| Tablet | DHCP, no reservation needed | It only ever calls outwards to the Gateway. |
| u-IoT module | Fixed, entered once in the settings | It is called, it does not call. |
A robot whose chassis address changes does not fail silently: the operator surface shows not connected, and the technician page names the address it tried. That is deliberate — the failure mode of a wrong address must be visible within seconds, not at the first missed transport.
4. What we ask a customer's IT department for¶
One paragraph, so that it can be forwarded as it stands:
The robot needs a network segment of its own — a separate WLAN or a VLAN — containing the robot, its control computer and its tablet. From that segment, outgoing connections to the internet on port 443 are required (and on 8883 if that is easier to permit); the destination is Amazon Web Services in the Frankfurt region. No incoming connection from the internet is needed at any point. If the robot is to open doors or call lifts, it also needs to reach those specific devices in the house network — each by a single address that is agreed during commissioning.
5. What is still open¶
| Question | Why it is open | How it gets closed |
|---|---|---|
| The u-IoT module's port and its interface | The description is outstanding | It arrives with the description; until then the address is configured as a whole and nothing is interpreted |
| Whether the fleet broadcast survives a hospital WLAN | Measured only across processes on one host so far — all three participants ran on 127.0.0.1 |
Two Gateways in one house, one beat, and a look at both journals. Until then the unicast address list is the fallback that is known to work |
| Whether a site-wide instance is needed at all | Depends on whether the site segment exists | Per building, at commissioning |