Small messages answer only part of the question
Factory operators should separate the volume of vehicle commands from evidence that those commands arrive when needed. Embotech describes driving trajectories sent ten times per second in packets of around 150 bytes. That makes the application payload modest. It does not, by itself, specify the complete network load or the conditions for accepting a wireless control system.[2,5]
BMW’s 27 October milestone makes this a current operating question: Oxford has joined Dingolfing, Leipzig and Regensburg as its fourth plant using automated in-plant driving. The group reports one million movements and around 3,500 daily movements across its network. These cumulative and daily counts do not reveal the number of vehicles sharing one radio coverage area at the same moment. The current migrated BMW page displays 30 October; this report retains the original announcement date.[1]
Calculate the payload, then state its boundary
Multiplying the vendor’s approximate 150 bytes by ten messages per second gives about 1,500 bytes per second per vehicle. For hypothetical concurrent fleets of eight, sixteen and thirty-two vehicles, the corresponding downlink payload is about 0.096, 0.192 and 0.384 megabits per second. These are transparent sizing scenarios, not observed BMW traffic. They exclude headers, security, uplink, retransmissions and sensor backhaul.[2]
Embotech’s earlier operating account describes on-premise servers computing trajectories and transmitting them through 4G LTE to a vehicle interface. Outsight separately describes infrastructure LiDAR perception. Sensor processing and command delivery are different workloads: this report does not convert LiDAR point counts into network bytes or infer that raw perception data uses the vehicle command link.[3,4]
A different protocol model has a different denominator
A 2025 open-access engineering paper models thirty-two vehicles under line-of-sight coverage from a central roadside unit with a 160-metre range. Each vehicle sends a 530-byte vehicle message every 100 milliseconds; the infrastructure sends one shared 1,398-byte message at the same interval. The stated sizes include headers. Our accounting gives 169,600 plus 13,980 bytes per second, or approximately 1.469 Mbit/s.[5]
This is not an efficiency contest between the two numbers. They describe different message formats, directions and protocol assumptions. The paper also has automotive-industry coauthors, including BMW; it is not an independent audit of BMW’s current deployment. Its simulation is useful because it exposes inputs that a short product specification leaves unspecified.[2,5]
Reception timing survives the bandwidth calculation
The paper distinguishes the nominal transmission period from the gap between successful packet receptions. Under its stated channel-access assumptions, successfully received packets can have inter-reception intervals of 99–101 milliseconds for ITS-G5, a Wi-Fi-derived vehicle communication technology, and 1–199 milliseconds around resource reselection for LTE-V2X, a cellular vehicle communication technology. Packet losses can create longer gaps. These conditional model bounds are neither field latency measurements nor production reliability guarantees.[5]
The same paper’s dynamic inclusion scheme updates each vehicle’s trajectory every 32/10 = 3.2 seconds in its thirty-two-vehicle example. At an assumed 20 km/h, that covers about 17.8 metres. That is a trajectory horizon calculation, not permission to lose communication for 3.2 seconds, and not a disclosed BMW safety timeout.[5]
What an operator should require
The standards explain why byte volume is only one test. ETSI’s marshalling specification includes an end-to-end protection container with message length, counter, checksum and data identity. AUTOSAR’s cited protocol describes using counters to detect repeated or missing data, and communication loss or timeouts. A checksum checks data corruption. These are mechanisms and configurable conditions, not proof that a particular production installation satisfies its safety case. They reinforce the need to test message validity and freshness alongside capacity.[6,7]
The practical acceptance question is whether a defined workload meets the site’s delivery and recovery requirements. Specify concurrent vehicles per coverage area, both message directions, overhead and competing traffic. Measure reception gaps and loss bursts on actual routes, including coverage boundaries and obstructions. Record stops, recovery actions and lost production time separately. These are proposed tests, not a claim that any cited deployment has failed them.[1,2,5]
The strongest contrary evidence is that the paper finds its modelled communication feasible under planned line-of-sight conditions, while BMW reports an operating rollout. Small payloads may indeed make capacity easier. The remaining gap is the absence here of a matched production dataset joining concurrent load, packet timing and recovery outcomes. Embotech’s above-99.5% availability claim lacks a stated observation denominator on its product page and cannot supply that dataset.[1,2,5]
Scope and tests that could change this conclusion
The deployment panel covers Germany and the United Kingdom; the United States is a planned BMW expansion, not a matched operating comparison. Neither national network performance nor other industries are ranked. A factory line, logistics yard and public parking facility need different route, traffic and recovery assumptions even when they use related marshalling protocols.[1,5]
At the next site acceptance test, reconcile commanded and successfully received messages for the declared peak concurrent fleet, with packet-gap distributions, loss bursts and stop logs over the same period. Evidence that the complete workload consistently meets its declared timing and recovery criteria would narrow this report’s uncertainty. At the next public deployment update, request site-specific concurrent-client counts and intervention records; replace scenario sizing with measurements only when their definitions and observation windows match.[1,2,5]