What is the C-ITS architecture?

The reference model for cooperative-ITS communications, defined in ETSI EN 302 665 V1.1.1 (2010-09) as the ITS station (ITS-S) architecture. It has four horizontal layers — Access, Networking and Transport, Facilities, and Applications — plus two vertical entities that span all four: Management and Security. Every European C-ITS deployment is shaped by this model, which predates the CAM and DENM message definitions by several years.

What are the layers of the ITS station architecture?

Four horizontal layers: Access (the radio, ITS-G5 or C-V2X), Networking and Transport (GeoNetworking plus the Basic Transport Protocol, addressing messages by geography), Facilities (the messages themselves — CAM, DENM, CPM and the rest), and Applications (the use cases that consume them). Alongside them run two vertical entities, Management and Security, each connected to all four layers, and none of them sitting on top of one.

Why are security and management drawn as vertical entities?

Because neither belongs to a single layer. A message has to be trustworthy at the facilities layer, signed at the security level, and delivered over the access layer, so security has to reach all of them at once. Management is the same: decentralized congestion control needs the access layer's channel load and the facilities layer's message-generation rate together, which no single horizontal layer can see. Drawing them vertically is the model admitting that trust and control are cross-cutting concerns.

Which ETSI standard defines the C-ITS architecture?

ETSI EN 302 665 V1.1.1, 'Intelligent Transport Systems (ITS); Communications Architecture', published 2010-09. It defines the ITS station reference architecture that the later access, networking, facilities and security standards all plug into. The MCO reference architecture in TS 103 696 and TS 103 697 later extended it for cross-layer multi-channel operation.

How does the C-ITS architecture map to the OSI model?

Loosely. The Access layer covers OSI layers 1 and 2, Networking and Transport covers 3 and 4, and Facilities plus Applications sit above as an ITS-specific grouping, with no clean OSI 5-6-7 split. The two vertical entities, Management and Security, have no OSI equivalent as layers — OSI treats them as functions, while the ITS-S model makes them first-class cross-layer entities.

Where do CAM and DENM sit in the architecture?

At the Facilities layer. CAM, DENM, CPM, VAM and the rest are facilities-layer messages: they carry road meaning, are handed down to Networking and Transport for geographic delivery, signed via the Security entity, and put on the air by the Access layer. An application above the Facilities layer is what turns a received DENM into a driver warning.

C-ITS architecture: four layers and two planes

The European C-ITS stack is one diagram everyone redraws. Four horizontal layers, two vertical entities for security and management, and why those two refuse to be layers at all.

The C-ITS architecture is a diagram almost everyone in the field has redrawn at least once: four boxes stacked into a column, two taller boxes standing on either side. Naming the boxes is the easy part, and most explanations stop there. What the shape actually buys you is more interesting, and it starts with a document older than most of the messages that run on it.

ETSI EN 302 665 V1.1.1 set out the ITS station reference architecture in September 2010, years before CAM and DENM were finalised in their current form. The messages changed; the frame they sit in did not. Every European deployment, every roadside unit and every on-board unit, is still shaped by this model.

The ITS station reference architecture of EN 302 665: four horizontal layers, two vertical entities that touch all of them.

Four layers and two cross-cutting planes

The horizontal reading is the familiar one. From the road up: Access is the radio. Networking and Transport moves a message to the right place. Facilities is where the messages live. Applications are the use cases that consume them. A packet travels up this column on receipt and down it on transmission, one layer at a time.

The two boxes standing on their side are Management and Security. They are not layers, and the diagram is deliberate about that: each one connects to all four horizontal layers at once.

Why trust and control refuse to be a layer

Put security in one layer and ask where it goes. Below the facilities layer, so it can sign a message before transmission? Then the application above it cannot know whether what it received was trustworthy. Above the facilities layer, as an application concern? Then every application reimplements certificate checking, and the network layer forwards unsigned packets it should have dropped. Neither placement works, because trust is a property the message needs at every layer it passes through. So security is drawn vertically, reaching each layer where it has something to enforce.

Management has the same problem from the other direction. Decentralized congestion control stops a busy junction from saturating the shared channel. It needs two facts that live in different layers: how loaded the radio channel is right now, which only the access layer knows, and how often the facilities layer wants to generate messages, which only the facilities layer knows. A horizontal layer can see the one below and the one above. Congestion control needs to see the top and the bottom at the same time, so it too becomes a vertical entity.

The vertical boxes are the model telling you which concerns could not be contained. Everything drawn horizontally is separable; everything drawn vertically is not.

What each horizontal layer owns

The separable part is best read from the bottom up, because each layer depends on the one beneath it and nothing above.

Access — the physical link. Two radios coexist in Europe: ITS-G5, a Wi-Fi variant, and C-V2X, built on cellular. Defined for ITS-G5 in EN 302 663.
Networking and Transport — GeoNetworking addresses a message by geography, leaving network addresses aside, and the Basic Transport Protocol routes each message by port number. EN 302 636, with the port registry in TS 103 248.
Facilities — the messages that carry road meaning: CAM, DENM, CPM, IVIM, MAPEM, SPATEM, RTCMEM and the rest, each its own specification.
Applications — the use cases. A red-light violation warning is an application built on the SPATEM and MAPEM below it, with no message of its own.

The clean dependency is what lets the radio change without rewriting the road meaning: swap ITS-G5 for C-V2X at the access layer and the message formats above it survive unchanged. What does change is what the vertical entities read, which is why the radio choice is a deployment question and not only a wiring one.

Where the model leaks

Real deployments blur the boxes, and knowing where is the difference between reading the diagram and having built one.

Decentralized congestion control is specified as a management function, but it acts on the access layer’s transmit decisions, so implementations end up straddling both. The Local Dynamic Map is nominally a facilities-layer store, yet it fuses data the way the management plane thinks, and it is often implemented alongside it. Message signing sits between facilities and networking: the facilities layer asks the security entity to sign, and the networking layer carries the result, so the security entity is doing work in the seam between two layers. The vertical boxes exist precisely because these seams do, and the seams are where implementations spend their time.

Read the sources yourself

The architecture itself is one short standard, EN 302 665 V1.1.1. Read it before the message specifications; it is the frame they all assume. For how the messages at the facilities layer fit together, the five-minute message-set tour walks the set, and the collective perception service takes one of them apart in depth. The stacks and tools used to work with real C-ITS traffic are in resources.