In short: UK container terminals are converting yard cranes from cabbed, manually driven machines into remotely operated and increasingly automated assets, with operators moved off the equipment and into ground-level control rooms. Every one of those moves depends on a wireless link carrying control commands and a wall of camera feeds with deterministic, low latency. That is precisely the workload Wi-Fi handles badly and private 5G handles well — and it is why crane automation has become the clearest private-5G business case in the sector.
Key Takeaways
- Operators are moving from the cab to the control room — remote-controlled rubber-tyred and rail-mounted gantry cranes let one operator run several machines, but only if the camera feeds and controls arrive with predictable latency
- Automation multiplies the data, not just the productivity — each automated crane carries a dozen or more HD and 3D cameras for stack profiling, twistlock alignment and safety, and all of it competes for the same airtime
- Private 5G gives deterministic coverage across the whole yard — licensed spectrum, planned cells and guaranteed quality-of-service replace the dead spots and contention that make Wi-Fi unsafe for moving 40-tonne loads
In a nutshell
The crane is where the port automates first
Container terminals are some of the most heavily instrumented logistics environments in the country, and the place automation lands first is almost always the yard crane. There is a clear reason for it: yard cranes — rubber-tyred gantries (RTGs) stacking containers in the yard, and rail-mounted gantries (RMGs) at the rail interface — do a highly repetitive job in a constrained, well-mapped space, which is exactly the kind of task that automates well. Ship-to-shore (STS) quay cranes are harder, because the ship side is variable and the consequences of error are larger, so the industry has tended to automate the hoist and trolley functions while keeping a human in the loop for the spreader-to-container final move.
The UK's two largest container terminals have both moved in this direction. The Port of Felixstowe, operated by Hutchison Ports, has deployed remote-controlled and automated rubber-tyred gantry cranes, with operators relocated from the crane cab to a remote control room where one person can supervise multiple machines. DP World's London Gateway was designed from the outset around automated stacking cranes at the landside of the yard, with quay cranes operated semi-remotely. In both cases the same pattern holds: take the operator off the machine, put them at a desk with screens and a joystick, and let one person do the work of several.
The productivity logic is compelling. Removing the operator from the cab improves safety, ends the unproductive minutes spent climbing up and down a forty-metre crane at shift change, opens crane work to a wider labour pool, and — because one operator can supervise several semi-automated cranes and intervene only on the moves the automation flags — lifts the number of container moves per operator-hour substantially. But every part of that logic rests on an assumption that is easy to state and hard to deliver: that the link between the crane and the control room is good enough to trust with a moving load.
What "good enough" actually means for a crane
It is worth being concrete about the workload, because the headline figure — bandwidth — is the least interesting part of it.
A remotely operated crane sends two things to the control room and receives one thing back. It sends video: typically a dozen or more camera feeds per crane, covering the gantry travel path, the trolley, the spreader and twistlocks, the container being picked, the truck lane below, and the safety zones around the machine. Several of these are high-definition, and the alignment-critical ones (spreader-to-container, twistlock engagement) need both resolution and a fast frame rate, because the operator is judging a centimetre-scale alignment in real time. It also sends telemetry: load weight, sway, position, fault codes, the constant stream of machine state. And it receives control: the operator's joystick and button inputs, which must reach the crane and take effect predictably.
The hard requirement is not raw throughput, it is determinism. An operator landing a forty-tonne container into a stack is closing a control loop through the network. If the video freezes for half a second, or the latency jumps unpredictably, or a control command is delayed, the operator is flying blind at the worst possible moment. The system can be designed to fail safe — to stop the crane if the link degrades — but a crane that stops every time the network hiccups is a crane that is not earning its keep. The network has to be consistently good, not occasionally excellent.
That requirement — many simultaneous video uplinks plus low-latency, reliable control, across a large outdoor area full of moving steel — is where the choice of wireless technology stops being a detail and becomes the whole project.
Why Wi-Fi runs out of road in the yard
Container yards have historically run on Wi-Fi, and for handheld scanners and tablets it is adequate. For crane automation it runs into three structural problems.
The first is coverage and handover. A yard is hundreds of metres on each side, and cranes travel its full length. Covering that with Wi-Fi means many access points and constant roaming between them; every handover is a moment where a moving crane's link can stutter. Wi-Fi roaming was never designed for a forty-tonne machine that must not lose its control channel mid-lift.
The second is contention and interference. Wi-Fi runs in unlicensed spectrum shared with everything else in range, and a stacked container yard is a brutal RF environment — metal boxes everywhere, reflecting and blocking signals, with the radio environment changing every time a container moves. There is no way to guarantee a slice of airtime for the crane's control channel when it is competing with every other device and every neighbouring network for the same unlicensed band.
The third is quality-of-service. Crane control and a tablet's email sync are not equally important, but Wi-Fi has no robust way to prioritise the one that matters. Under load, the safety-critical traffic and the routine traffic are treated alike.
None of this means Wi-Fi is bad technology; it means it is the wrong tool for moving heavy loads remotely across a large, hostile outdoor site.
What private 5G changes
A private 5G network addresses each of those problems directly, which is why it has become the connectivity of choice for automated terminals worldwide.
It runs in licensed or shared-licensed spectrum — in the UK, Ofcom's Shared Access licensing makes the relevant bands available to a terminal operator for a modest fee — so the crane's traffic is not competing with unmanaged consumer devices for airtime. The operator controls the spectrum and therefore the experience.
It is designed for wide-area coverage with clean handover. A handful of well-sited 5G radios can blanket a yard that would need dozens of Wi-Fi access points, and the cellular handover between cells is engineered for mobility — a moving crane keeps its session as it travels. That alone removes the single most common cause of automation downtime.
It offers real quality-of-service and, increasingly, network slicing — the ability to reserve a guaranteed, low-latency slice for crane control and safety traffic while the camera feeds and the general yard traffic share the rest. The safety-critical loop gets the determinism it needs, by design rather than by luck.
And it provides the uplink capacity that crane automation specifically demands. Most networks are built assuming people mostly download; an automated yard is the opposite — dozens of cameras pushing video up to the control room. Private 5G can be configured with the uplink-heavy profile this workload needs, which the public networks and Wi-Fi are not optimised for.
One network, the whole terminal
The crane case is the one that justifies the investment, but it is not the only thing the network carries — and that is central to the economics. Once a terminal has a private 5G layer planned to cover the yard for crane automation, the same network serves the rest of the operation.
Straddle carriers and terminal tractors moving boxes between the quay and the stack run on it. The optical character recognition and damage-inspection cameras at the gate and the rail head run on it. Reefer monitoring — the refrigerated containers that need their temperature and power state watched continuously — runs on it. The connected-worker devices, the asset trackers, the yard-management handhelds, the CCTV and perimeter security all run on the same managed network rather than on a stack of separate, half-overlapping systems. Each additional use case is incremental cost on infrastructure that is already there.
That consolidation matters in a port, where the alternative is the patchwork that has accreted over decades: one network for the cranes, another for the trucks, Wi-Fi for the office, radio for the people, and a private microwave link for something nobody quite remembers. A single network is cheaper to run, easier to secure, and far simpler to extend.
The direction of travel
UK terminals are not automating because automation is fashionable; they are automating because the economics of container handling reward density, consistency and round-the-clock operation, and because the labour market for crane operators is tight. Felixstowe and London Gateway have shown that remote and automated yard cranes work at scale in British conditions. The smaller and mid-sized terminals watching them are weighing the same move.
Ultimately however, the lesson from the terminals that have done it is that the automation project is, in large part, a connectivity project. The cranes, the control software and the cameras are available off the shelf and broadly proven. What separates a smooth deployment from a troubled one is whether the network underneath is deterministic, well-covered and built for the uplink-heavy, mobility-heavy, safety-critical workload that a remotely operated yard actually generates. Get the network right and the cranes follow. Get it wrong and the most expensive machines on the site spend their time stopped, waiting for a link that was never designed to carry them.