The message that tells your car where to park, and what comes next

Everyone knows the tax of arriving somewhere by car: the slow lap of the block, the same three streets, the space that vanishes as you reach it. It is one of the most ordinary frustrations of driving, and one of the oldest targets for anyone building smarter roads.

In January 2024, ETSI published a standard that removes it in the cleanest way possible: the street tells your car where the free spaces are, directly, over the air. The document is TS 103 916 V2.1.1, the Parking Availability Service. The interesting part is what ETSI built underneath it, and left almost empty on purpose.

What the standard actually does

A roadside unit, or a central station standing in for a whole city, broadcasts live parking information to the vehicles around it. On-street bays, off-street lots, multi-storey car parks, park-and-ride sites: the message carries both the fixed facts of a parking place and its changing availability, and it is sent periodically or the moment a change is worth announcing.

A car approaching a junction receives it and already knows what is free ahead, before the driver has started looking. No app, no account, no circling. The information arrives the same way a hazard warning or a signal phase does, as a standard cooperative-ITS message addressed to everyone in the area.

That alone would be a useful, narrow standard. It is not a narrow standard.

An envelope with one thing in it

The message has a name that gives the game away. Its name is POIM, the Point of Interest Message, and parking is only its first tenant.

Under the hood, POIM is a generic container. It holds up to eight information blocks, and each block is tagged with a type number reserved from 1 to 128. The standard defines exactly one of those numbers:

PoiType ::= INTEGER (1..128, ...)

parkingAvailability  PoiType ::= 1
-- other block imports from separate standards
-- to be added here when needed.

One type filled, a hundred and twenty-seven reserved, and a comment in the schema telling you the rest arrive later. This is not an accident of drafting. ETSI says as much in the introduction: because many kinds of point of interest matter to road users, the document deliberately specifies a generic approach so that future standards can add other types. Parking is the worked example that ships first. The envelope is the actual design.

The room ETSI has already sketched

The best evidence of where this goes is inside the same document. Its informative annex, the part that studies future work without mandating it, lays out the next moves for parking alone:

• Automated valet parking. The car drops you at the door and parks itself, guided by what the facility broadcasts.
• Lorries, trucks and coaches. Heavy and long vehicles have parking needs a passenger-car model does not cover.
• Vehicle-initiated reports. A parked car tells the network the space is now taken, reversing the usual direction.
• Unconnected vehicles. Accounting for the cars that cannot hear the message, so the picture stays honest.

None of that is speculation on my part. It is written into the standard as the roadmap for one point-of-interest type. Multiply it by the hundred-odd type numbers still empty, and the shape of the thing becomes clear.

What the other slots could hold

Here the standard stops and extrapolation begins, so treat this as the reader’s side of the line, with ETSI’s on the other. The reserved numbers are an open invitation to describe, in one shared format over one channel, the points of interest a moving vehicle cares about.

Charging is the obvious next one: ETSI already has older, separate messages for electric-vehicle charging notifications, and folding live charger availability into the same envelope would let a car weigh a free bay and a free charger in one decision. Curbside use is another: the loading bay, the taxi rank, the ride-hail pickup point, the delivery slot that a city increasingly wants to manage by the minute. Then the quieter ones: accessible bays, rest areas, fuel, the services a long-distance driver plans around.

The value lies in none of them alone. It lies in their speaking the same language to the same receiver, sparing the driver a dozen incompatible apps.

Why an envelope beats a message

The design choice is the lesson. ETSI could have written a parking message, shipped it, and started a fresh standard the day charging came up. Instead it wrote a carrier: one frame, one channel, one trust model, and a type number that says what kind of place this block describes. Parking moved in first. The building has room for a hundred more tenants, and none of them need a new building.

That is a slow, unglamorous kind of future-proofing, and it is the kind that tends to outlast the flashier sort. The standard that ships one feature and an empty envelope often beats the one that ships ten features and no room.

Read it yourself

The document is ETSI TS 103 916 V2.1.1 (2024-01). The normative part is the parking service; the future directions live in its informative Annex D, which is worth the read on its own. For where POIM sits among the other C-ITS messages, the five-minute message-set tour covers the nine core messages it arrived alongside, and the layered architecture shows the facilities layer it belongs to. POIM arrives with Release 2, and the Release 1 to Release 2 map tracks what else moved in the same wave.