Hex cells, capacity, and the asymmetric-traffic problem

The previous post asked whether altitude could encode direction. This one asks where, exactly, those directions live — what shape the airspace itself has once you have decided to discretise it, and what that shape costs you when traffic refuses to be symmetric.

§The reason airspace needs to be cellular at all

A continuous airspace is mathematically clean and operationally useless. Every coordination decision — who has right of way, who reserves what, where one vehicle's claim ends and another's begins — requires a notion of boundary. In the absence of cells, every boundary has to be negotiated in real time between every pair of vehicles whose claims might overlap. The combinatorics make this intractable above a handful of vehicles per cubic kilometre.

Cells are the discretisation that makes coordination linear instead of combinatorial. A vehicle reserves a cell, or more precisely a cell-time tuple — but I will get to time — and the reservation is opaque to the rest of the network. You do not need to know who is in the cell. You only need to know that the cell is occupied. The cost of a reservation lookup becomes constant, not linear in fleet size.

The question is what shape the cells should be.

§What is wrong with squares

Square cells are the obvious choice. They fail on a property that matters a great deal for traffic: they are not isotropic. A square cell has four neighbours that share an edge and four neighbours that share only a corner. Movement from a cell to an edge-neighbour requires one cell-transition. Movement to a corner-neighbour — geometrically the same Euclidean distance — requires two.

This asymmetry sounds small. In a low-altitude airspace it is fatal. Vehicles travelling diagonally — say, a quadcopter crossing from a launch pad in the southwest of a city to a delivery point in the northeast — must traverse a staircase of cells that is roughly $\sqrt$ times longer than the actual flight path. Every staircase step is a reservation event. Every reservation event has a fixed coordination cost. The protocol overhead for a diagonal traveller is forty percent higher than for an axis-aligned one, despite the vehicle covering the same distance in the same time.

There is also the matter of corners. A square cell shares corners with three other cells. At those corner points, four cells meet, and the coordination question — who has authority over the corner volume? — has no clean answer. Implementations either give the corner to one specific cell (introducing a parity asymmetry) or define a corner-fringe zone (introducing a new class of boundary). Both are technical debt the protocol does not need to carry.

§Why hexagons

A hexagonal cell has six neighbours. All six are edge-neighbours: there are no corner cases, literally. The Euclidean distance from a cell's centre to each of its six neighbours' centres is the same. Movement in any of six directions costs exactly one cell-transition.

When this is combined with the six-way altitude-direction encoding from the previous post, something happens that I find quietly elegant: the protocol's directional alphabet (six directions) maps one-to-one onto the cell topology (six neighbours). A vehicle declaring a direction is also declaring which of its six neighbour cells it intends to enter next. The two layers — the informational layer (altitude says where you are going) and the spatial layer (hex cells say where you can go) — interlock without any glue code.

You can put square cells under any directional encoding, and they will work, after a fashion, with translation tables and special cases. You cannot do better than hexagons under a six-way encoding without breaking either symmetry or efficiency.

There is one place hexagons cost you, and it is worth being honest about it. Hexagonal tiles do not align with latitude-longitude grids. Every existing aviation database, every map, every GIS layer the regulator already has, is square. The protocol must therefore include a coordinate transformation from the world's lat/long substrate to the protocol's hex tiling. The transformation is well-understood — discrete global grids on hex bases have been studied seriously since the 1990s — and the cost is one-time and tooling-amenable, not operational. It is a real cost. It is not a blocking one.

§Cell capacity

A cell is a volume of airspace with a finite capacity. The capacity question — how many vehicles can simultaneously occupy one cell? — is where physics, regulation, and operational pragmatism meet.

The physical answer is "as many as can be safely separated by their own collision-avoidance envelopes." For small quadcopters with one-metre rotor diameters and conservative five-metre safety bubbles, a hex cell of (say) thirty-metre edge length has theoretical room for several vehicles. The physical capacity is rarely the binding constraint.

The regulatory answer is, at present, "one." Most operating jurisdictions for unmanned vehicles still default to single-occupancy assumptions for any given navigable volume, because the regulator does not yet have a model for what multi-occupancy looks like. This will change — it has to, or the entire low-altitude economy stalls — but it will change slowly.

The operational answer is somewhere in between, and is the part the protocol concerns itself with. The protocol declares a per-cell capacity that varies with three inputs:

Each input is observable. Each is auditable. None of them require a central scheduler — only a shared definition of the cell's policy, which the protocol distributes as part of the airspace state.

§The asymmetric-traffic problem

Here is the problem the model has to solve.

In any real low-altitude airspace, traffic is asymmetric. A delivery hub in the morning sends out twenty vehicles for every one that comes back. A hospital corridor during a mass-casualty event carries inbound medical drones at five times the outbound rate. A festival site at sunset has a strong inbound rush followed three hours later by a strong outbound rush. A tourist zone at dawn carries photography drones outbound and almost nothing inbound.

A protocol that gives every direction the same fixed capacity wastes itself the moment any of these conditions arises. The cell allocated to the rare direction sits empty while the cell allocated to the common direction overflows.

The protocol's answer is a dynamic capacity assignment within the directional structure. Of the six direction bands available per cell, a single hex cell can be configured to allocate three to the dominant flow and three to the inverse — or four to one and two to the other, or any other split that preserves the protocol's separation guarantees. The split is itself a reservable property: vehicles entering the cell read its current capacity profile and conform.

This is not free. The cost is configuration complexity: every cell now has a policy state in addition to its occupancy state. The benefit is that asymmetric traffic patterns, which would saturate a symmetric system at half their theoretical maximum, can be handled at close to full theoretical throughput.

The protocol's design choice — and this is a deliberate one, made early — is that the cost is worth it. Low-altitude airspace will be asymmetric far more often than it is symmetric. Cities are radial. Hospitals are point sources. Delivery hubs are unbalanced by design. Building a protocol that assumes symmetry is building a protocol that fails on its first day in operation.

§What a reservation actually is

A reservation in this protocol is a tuple. The four-dimensional nature is the entire point: a reservation occupies (cell, direction band, time window) with a known start, duration, and exit transition. When a vehicle requests a reservation, it commits to entering the cell, travelling within the declared band, and exiting through a specific neighbouring cell at a specific time.

The protocol does not require — and deliberately does not include — any prediction about what the vehicle does outside the reservation window. A vehicle can hover, land, change mission, or terminate before the reservation expires. The reservation is a contract about cell occupancy, not a forecast of the vehicle's full trajectory.

This matters because predictions are the part of any traffic system that gets brittle when conditions change. Wind shifts. Batteries deplete faster than expected. Missions reroute. A protocol that depends on accurate trajectory prediction across long horizons is a protocol whose failure modes are mysterious. A protocol whose primitive is a short, scoped cell reservation has failure modes that are local and inspectable: a vehicle either honoured its reservation or it did not, and if it did not, the reservation expired and the cell freed itself for the next claimant.

I will go into the time dimension at more length in a future post — the choice of reservation duration, the handling of overruns, what happens when reservation requests conflict, the role of priority classes for emergency vehicles. For now, the load-bearing claim is that a hex cell, equipped with a directional capacity profile and a 4D reservation primitive, gives you a substrate on which the rest of the protocol can stand.

§What this gives you, and what it does not

You get, by construction:

• Isotropic movement (any direction costs the same)
• Clean topological neighbourhood (six edges, no corner ambiguities)
• Capacity that scales with directional load
• A coordination primitive whose computational cost is constant per request, not linear in fleet size

You do not get:

• Continuous trajectory optimisation
• Sub-cell precision routing
• Native lat/long operation
• Any guarantee about what happens between cells

The protocol assumes vehicles can navigate within a cell using their own systems. The protocol's job is to make sure two vehicles do not both believe they own the cell at the same moment.

That is a smaller job than people sometimes expect a "traffic management system" to do. It is also, I would argue, the right job — the one that scales, the one that can be implemented without a central authority, the one that survives the next generation of vehicle hardware without re-architecture.

A protocol is most useful when it does only what it must. The next post looks at what the AI layer negotiates on top of this substrate — and, more importantly, what it deliberately refuses to negotiate.