ETSI TR 103 578 V2.1.1 (2024-04)

Intelligent Transport Systems (ITS); Vehicular Communications; Manoeuvre Coordination Service (MCS); Pre-standardization study; Release 2

DTR/ITS-00185

General Information

• Status: Not Published
• Technical Committee: ITS WG1 - Application Requirements and Services
• Current Stage: 12 - Completion
• Due Date: 24-Apr-2024
• Completion Date: 18-Apr-2024

Standards Content (Sample)

TECHNICAL REPORT
Intelligent Transport Systems (ITS);
Vehicular Communications;
Manoeuvre Coordination Service (MCS);
Pre-standardization study;
Release 2
2 ETSI TR 103 578 V2.1.1 (2024-04)

Reference
DTR/ITS-00185
Keywords
ITS, network, protocol
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from:
https://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure Program:
https://www.etsi.org/standards/coordinated-vulnerability-disclosure
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
and/or governmental
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2024.
All rights reserved.
ETSI
3 ETSI TR 103 578 V2.1.1 (2024-04)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Executive summary . 5
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 8
3.3 Abbreviations . 8
4 General description of the manoeuvre coordination service . 9
4.1 Objectives . 9
4.2 Classes of services . 9
4.2.1 Introduction. 9
4.2.2 Status-Sharing . 10
4.2.3 Intent-Sharing . 10
4.2.4 Agreement-seeking . 10
4.2.5 Prescriptive . 12
4.3 Requirements and Considerations . 12
4.3.1 Introduction. 12
4.3.2 Manoeuvre Prediction . 13
4.3.3 ITS Architecture Requirements . 13
4.3.4 Traffic flow heterogeneity . 15
5 Main concepts . 15
5.1 Introduction . 15
5.2 Concept A1, V2V cooperation class "agreement seeking" . 15
5.2.1 Overview . 15
5.2.2 Description . 15
5.2.3 Lane change assistance use case . 18
5.2.4 Lane merging assistance use case . 20
5.2.5 Intersection/Roundabout crossing assist use case . 20
5.2.6 Information flow diagrams . 21
5.2.7 Situation analysis . 22
5.3 Concept A2, V2V cooperation class "Prescriptive" . 23
5.3.1 Overview . 23
5.3.2 Description . 23
5.3.3 Example: Interception situation . 24
5.3.4 Information flow diagram . 25
5.3.5 Situation analysis . 25
5.4 Concept B1, I2V cooperation class "Agreement Seeking" . 25
5.4.1 Overview . 25
5.4.2 Description . 25
5.4.3 Toll Barrier use case . 27
5.4.4 Four-way crossing use case . 27
5.4.5 Highway merge use case . 28
5.4.6 Information flow diagram . 29
5.4.7 Situation analysis . 29
5.5 Concept B2, I2V cooperation class "prescriptive" . 30
5.5.1 Overview . 30
ETSI
4 ETSI TR 103 578 V2.1.1 (2024-04)
5.5.2 Description . 31
5.5.3 Wrong Way Driving use case . 32
5.5.4 Information flow diagram . 33
5.5.5 Situation analysis . 34
5.6 Concept C1, C2V cooperation class "agreement seeking" . 35
5.6.1 Overview . 35
5.6.2 Description . 35
5.6.3 Group Start use case . 36
5.6.4 Information flow diagram . 36
5.6.5 Situation analysis . 37
5.7 Concept C2, C2V cooperation class "prescriptive" . 38
5.7.1 Overview . 38
5.7.2 Description . 39
5.7.3 Fully automated vehicles central supervision use case . 39
5.7.4 Information flow diagram . 40
5.7.5 Situation analysis . 41
6 Conclusions . 42
6.1 Introduction . 42
6.2 Identified impacts on CAM . 42
6.3 Potential requirements . 42
6.3.1 Functional requirements . 42
6.3.2 Functional Safety and Security requirements . 43
6.3.3 Minimum performance requirements. 44
Annex A: Example of MC Messages . 48
A.1 Introduction . 48
A.2 Joint proposal for MCM format . 48
A.3 French PAC V2X project proposal . 52
A.4 German IMAGinE project proposal . 53
A.5 European TransAID project proposal . 54
A.6 SAE J3186 Maneuver Sharing and Coordination Service . 55
Annex B: Examples of an applications pipeline using the MCS . 57
History . 60

ETSI
5 ETSI TR 103 578 V2.1.1 (2024-04)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI Web server (https://ipr.etsi.org/).
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and of the 3GPP
Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of the ®
oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Intelligent Transport Systems (ITS).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document provides an overview of the Manoeuvre Coordination Service (MCS) (clause 4) which enables
collective actions to be coordinated between a group of cooperative partners.
A set of main concepts studied for the support of collective actions with associated examples of ITS applications and
use cases are provided in clause 5.
Identified impacts on CAM and functional requirements, Functional Safety and Security requirements, as well as
minimum performance requirements are provided in clause 6.
Annex A provides examples of Manoeuvre Coordination Messages (MCMs) which were tested in several National and
European research projects. An attempt is achieved to derive a common message structure, syntax and semantic.
Annex B provides an example of an applications pipeline using the Manoeuvre Coordination Service based on the
results of a collision risk analysis taking profit of Artificial Intelligence.
ETSI
6 ETSI TR 103 578 V2.1.1 (2024-04)
Introduction
The present document intends to provide some baselines for the standardization of the Manoeuvre Coordination Service
(MCS) which will support different applications related to the CCAM (Connected Cooperative Automated Mobility)
situation.
The main concepts which are proposed cover the CDA (Cooperative Driving Automation) services "Intent Sharing",
"Agreement seeking "and "prescriptive" (see SAE J3216 [i.1]).
An agreement seeking CDA service may take several forms according to the local situation of cooperative partners and
their intents.
A prescriptive CDA service requires a special permission which needs to be provided by a relevant authority to the ITS-
S using it. In this case, the intent is indeed a mission which is executed by an authorized stakeholder (police
intervention, emergency rescue, road maintenance operation (for example during winter), urgent transport of critical
goods and materials, etc.).
When manoeuvre coordination has been agreed between subject and target vehicles, these manoeuvres can be seen in
CAMs which are disseminated by these vehicles. Consequently, CAMs can be considered as implicit acknowledgement
messages of the MCMs.
ETSI
7 ETSI TR 103 578 V2.1.1 (2024-04)
1 Scope
The present document gives an overview of the Manoeuvre Coordination Service (MCS), describes the class of
cooperation, and introduces relevant use cases. Potential requirements (functional, functional safety, security, and
performance requirements) are also introduced as well as for the MCM format.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] SAE J3216: "Taxonomy and definition for terms related to Cooperative Driving Automation
(CDA) for on-road motor vehicles".
[i.2] https://www.pacv2x.fr/.
[i.3] Imagine: "Virtual Final Presentation".
[i.4] ETSI TR 103 299: "Intelligent Transport System (ITS); Cooperative Adaptive Cruise Control
(CACC); Pre-standardization study".
[i.5] SAE J3186: "Application Protocol and Requirements for Maneuver Sharing and Coordinating".
[i.6] ISO 26262: "Road vehicles -- Functional safety -- Part 1: Vocabulary".
[i.7] IEC 61508 (all parts): "Functional safety of electrical/electronic/programmable electronic safety-
related systems".
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
alternative trajectory: trajectory proposed by a manœuvre coordination partner as an alternative possibility
Connected Cooperative Automated Vehicle (CCAV): vehicle which has connectivity capabilities including V2X
communication
NOTE: In the present document "V2X" refers to 3GPP cellular V2X (PC5), DSRC ITS G5 or other standard
DSRC technologies meeting ITS application requirements (e.g. performance requirement).
manoeuvre advice: list of manoeuvres which need to be executed by receiving relevant vehicles (subject and target
vehicles) to obtain a specific result/outcome
ETSI
8 ETSI TR 103 578 V2.1.1 (2024-04)
MCS triggering vehicle: release 2 cooperative vehicle (most often probably the subject vehicle) which initiates an
MCS either with a request or an offer
NOTE: When an MCS triggering vehicle issues a request, if this one is accepted, this MCS triggering vehicle
becomes a subject vehicle. When an MCS triggering vehicle issues an offer, if this one is accepted, this
MCS triggering vehicle becomes a target vehicle.
reference trajectory: trajectory being currently driven by the vehicle
release 2 cooperative vehicle: connected cooperative automated vehicle which is equipped with a release 2 conforming
set of services which is necessary to contribute to manoeuvre coordination actions
relevant vehicle: cooperative vehicle which can be impacted by the manoeuvre coordination service because of its
proximity to other vehicles actively participating in manoeuvre coordination
NOTE 1: A relevant cooperative vehicle may also provide relevant data from its CAMs, CPMs disseminations to
active manoeuvre coordination participants. Then, it could affect initiated manoeuvre by aiding or
blocking it.
NOTE 2: In SAE J3186 [i.5], "Relevant Vehicle" term is equivalent to "Affected Vehicle".
requested trajectory: trajectory requested to be achieved from a manœuvre coordination partner
subject vehicle: cooperative vehicle, which needs a manoeuvre coordination, to satisfy its intent or to respond to
received messages
NOTE 1: Several subject vehicles may be synchronized to execute a manoeuvre.
NOTE 2: In SAE J3186 [i.5], "Host Vehicle" term is equivalent to "Subject Vehicle".
Target Road Resource (TRR): type and description of the road resource which is intended to be occupied by the
Executant
target vehicle: cooperative vehicle which actively participates in the accommodation of one accepted subject vehicle
manoeuvre
NOTE: In SAE J3186 [i.5], "Remote Vehicle" term is equivalent to "Target Vehicle".
trajectory: planned path with dynamic information (e.g. heading, time, speed, speed variation, etc.) between an origin
waypoint and a destination waypoint
NOTE: Clearly indicating a predicted path that can be identified as such by other cooperative ITS-S.
unconnected vehicle: vehicle which has not the required connectivity capabilities necessary to support the Manoeuvre
Coordination Service
NOTE: SAE J3186 definition [i.5]: Vehicle which is not capable of V2X communication.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ABS Anti-lock Braking System
ACC Adaptive Cruise Control
ADAS Advanced Driving Assistance Systems
AEBS Automated Emergency Brake System
ALK Active Lane Keeping
AVP Automated Valet Parking
C-ACC Cooperative Adaptive Cruise Control
CAS Cooperative Awareness Service
ETSI
9 ETSI TR 103 578 V2.1.1 (2024-04)
CCAM Connected Cooperative Automated Mobility
CCAV Connected Cooperative Automated Vehicle
CDA Cooperative Driving Automation
CPS Collective Perception Service
ESP Electronic Stability Program
FSR Functional Safety/Security Requirement
ISA International Society of Automation
ITS Intelligent Transport System
ITS-S ITS Station
MCM Manoeuvre Coordination Message
MCS Manoeuvre Coordination Service
ODD Operational Design Domain
PDU Protocol Data Unit
RSE Roadside Equipment
SAE Society of Automotive Engineers
SSP Service Special Permission
SV Subject Vehicle
TG Target vehicle "G", "G1".
TR Technical Report
TRR Traget Road Resource
TTC Time To Collision
TV Target Vehicle
VBS Vulnerable Basic Service
VRU Vulnerable Road User
4 General description of the manoeuvre coordination
service
4.1 Objectives
The objective of the Manoeuvre Coordination Service (MCS) is to exchange information and develop cooperation
between ITS-S in proximity or remotely for the support of the driving automation functions of Connected Cooperative
Automated Vehicles (CCAV). Therefore, this service is in support of ITS applications that in turn contribute to
automated driving functions.
4.2 Classes of services
4.2.1 Introduction
Several cooperative driving automation services can be identified. SAE J3216 [i.1] distinguishes the four following
classes of cooperation to increase cooperation among vehicles:
• Status-Sharing.
• Intent-Sharing.
• Agreement-Seeking.
• Prescriptive.
The clauses below provide more information on the 4 above mentioned classes.
ETSI
10 ETSI TR 103 578 V2.1.1 (2024-04)
4.2.2 Status-Sharing
Status-sharing corresponds to the communication of data relatively to a present situation under the form of information
about an object in its current state or about the result of an event which changed an object state. For example:
• CAMs provide the status of vehicular objects. This is an "Evidence" data set reflecting the current state
(present) of the considered vehicular object.
• DENMs provide event notifications indicating a rapid modification of a vehicle object or a road infrastructure
state.
EXAMPLE: A closed lane consecutively to a stationary vehicle, road work or accident.
• VAMs are providing the status of Vulnerable Road Users (VRUs).
• CPMs are providing the status of perceived unconnected objects (i.e. vehicles, VRUs, etc.).
It is however considered that status sharing (day 1 functionality) will still be necessary as the layer of information to
provide the basic data for ITS application with intent of manoeuvre coordination functionality based on MCS.
4.2.3 Intent-Sharing
Intent-sharing corresponds to the communication of an intent which may impact the manoeuvring of other mobile
objects.
A road user of any category, be it automated, human-driven or a vulnerable road user, manoeuvres according to an
intent. In most circumstances, this intent is guided by a set of rules, mostly prescribed in the form of traffic rules. When
a driver navigates to the right-turning lane, it is only in special circumstances that the driver will not follow the path
prescribed by that lane. Additionally, specific tools like turn signals and hand signals are used to indicate an intent in
the short term by the indicating road user.
Three types of behaviours could be taking place when considering intent in its current form if present:
• The road user does not indicate any thing, therefore pursuing its current intent. This could be continuing
straight on the road.
• The road user indicates a manoeuvre requiring a change, such as switching lanes, turning, crossing the road.
This is commonly indicated with intent signals (a pedestrian looking at driver before crossing, turn signals).
• A mistake in setting, (or forgetting) the right intent signal occurred (learner driver, sudden intent changes, or
adjustments to road status: avoiding potholes in the lane, lane change without signalling).
Intent sharing is therefore an inherent behaviour road user already utilize. To enable this capability in the long term for
CCAVs, the communication of this intent to other road users via an ITS service would enable a wider range of
manoeuvre coordination that it is currently possible. By comparison, VBS uses a dedicated container to convey
manoeuvre information. This should also be considered here.
The planned manoeuvre can be simply indicated using for example the turning signals of a vehicle or could be more
precisely indicated by communicating the planned trajectory of the vehicle and transmitting it in a V2X message.
4.2.4 Agreement-seeking
Agreement-seeking results in manoeuvre which is achieved by a set of cooperative objects (at least two) in a
coordinated manner. By seeking and agreeing to coordinate their actions, at least one of them can reach an identified
objective.
In the present document, agreement-seeking takes place through the sharing of information, seeking a cooperation
agreement. Such agreement needs to be sought and accepted by the cooperative parties. Three different situations can be
considered and initiated by cooperative objects. When cooperative objects can receive and communicate intent,
agreement-seeking constitutes the next constructive step.
ETSI
11 ETSI TR 103 578 V2.1.1 (2024-04)
Agreement-seeking results through the sharing of information and the seeking of a cooperation agreement. Such
agreement needs to be sought and accepted by cooperative parties. These different situations can be considered and
initiated by cooperative objects:
A) V2V cooperation agreement seeking
In this class of service, a MCS triggering can be initiated via the two following triggering conditions:
• A subject vehicle which is seeking a cooperation with one or several target vehicles for the coordination of one
or multiple manoeuvres. This is achieved by the subject vehicle via the dissemination of an intent and
cooperation request which may involve several sequential exchanges for the accomplishment of the subject
vehicle projected manoeuvre.
• One target vehicle which offers its support to one or several subject vehicles for the coordination of their
manoeuvres. This is achieved via the dissemination of an intent and a cooperative offer which may involve
several sequential exchanges for the accomplishment of subject(s) vehicles(s) projected manoeuvres with the
eventual support of other target vehicles.
B) I2V Manoeuvres coordination with roadside infrastructure
In this case, the MCS triggering initiative is taken by a roadside station which has generally a better perception of the
local situation due to added precise data sources, such as information from road operators or sensors such as cameras.
The Roadside Station (RSU) identifies maoeuvres target vehicles and suggests them to coordinate their manoeuvres for
various mobility purposes which would be identified. This is an offer which is broadcasted via MCMs when the MCS is
triggered by the RSU.
The objective of this coordination suggestion needs to be provided to relevant vehicles (subject(s) and target(s)) to be
able for them to take a decision to accept it or not.
The intention of relevant vehicles to execute or not the suggested manoeuvre coordination could be given in response
by vehicles by for example, supplying their path predictions (or targeted trajectories) which can be reflecting or not
their intent (evolution or not of the vehicle reference trajectory provided by CAM) or by an explicit response. However,
the suggested manoeuvre coordination needs to be accepted by all relevant subject(s) and target(s) vehicles for starting a
collective action. If this is not the case, the initiating vehicle may propose another strategy.
A typical example is the guiding of cooperative vehicles at a tolling station level for them to access the best gate
according to specific vehicles' features and rights and considering the current waiting queues at gates' level.
C) C2V Manoeuvres coordination with a central system
A central system may seek agreements with cooperative objects for various purposes such as road safety, traffic
management improvement, mobility applications (e.g. Automated Valet Parking (AVP)).
In such case, the central system proposes manoeuvre coordination actions to a selected set of subject vehicles which
keep the possibility to accept or refuse the centre proposals.
Additionally, it is critical to consider that there can be different levels of agreement reached which is demonstrated in
the following:
• Reception and Acknowledgement/Non-Acknowledgement (ACK/NACK). In this instance the agreement-
seeking object (regardless of ITS-S type) communicates intent and manoeuvre and seeks a confirmation or
rejection of the proposed manoeuvre.
• Reception and indirect Acknowledgement/Non-Acknowledgement (ACK/NACK). Here the functionality is
identical from above, except, the vehicles communicate their decisions by adapting their broadcasted data of
other services than MCS, such as path prediction (or reference trajectory) adaptation in the CAM.
• Reception and negotiation phase with consecutive Acknowledgement/Non-Acknowledgement (ACK/NACK)
with only one other road user. In this instance the cooperating vehicle is given the option by the agreement-
seeking party to choose or counter proposed alternatives.
ETSI
12 ETSI TR 103 578 V2.1.1 (2024-04)
• Reception and negotiation phase with consecutive Acknowledgement/Non-Acknowledgement (ACK/NACK)
with more than one other road user. The added complexity requires multiple rounds of choice and counter
proposals between involved objects. This option can potentially lead to the most effective trajectory choice for
all involved participants.
Since all of these different options constitute agreement-seeking, it is important to differentiate between them for an
implementation and to set a frame for their appropriate level of use. Potentially, the degree of agreement-seeking cannot
be decoupled from the use case, the amount of involved road users or the topology, and road use limitation.
4.2.5 Prescriptive
The prescriptive concept is an attempt to extend the manoeuvre coordination service to critical situations which cannot
be covered by previously considered concepts.
The main principle remains the same with three important phases:
• Intent sharing phase, but in this concept, the intent is considering mainly fully automated vehicles without a
driver in them which can be viewed as being in a critical situation relatively to road users' safety (dangerous
driving), to vehicle owner asset protection (e.g. recovery of stolen vehicles), to respect of local or European
regulations (e.g. drug or dangerous goods transportation), to terrorist attacks, creating a corridor for emergency
intervention or road capacity recovery, etc.
• Prescriptive acceptation phase, which provides more precise information on the origin of this concept use to
convince the manoeuvre coordination application of receiving vehicles to accept the provided
recommendations.
• Collective action, consisting of executing decided manoeuvre coordination after a complete acceptation of
required vehicles partners.
However, The MCS is only providing information to receiving vehicles. This information is deeply checked by the
facilities layer of the receiving vehicles before being communicated to the local manoeuvre coordination application of
the vehicle if judged correct and relevant.
NOTE: This type of service is already covered by standards for example for vertical signs such as traffic light
(status RED) and speed limits which can be considered as "prescriptive messages" leading vehicles to
stop at a red-light phase or limit their speed according to the indicated speed limit.
Two main issues need to be considered:
• What will be the roles and responsibilities of OEMs once fully automated vehicles are sold, during all their life
cycle (which stakeholders will have to ensure a safe and proper use of these vehicles?). And then, what will be
the National and European regulations which will be developed to cover the critical situations identified here
above?
• What will be the necessary extensions of security means to make sure that fully automated vehicles be
efficiently protected against cyberattacks (collect WG5 viewpoint) and physical vehicles modifications (likely
remaining the responsibility of OEMs vehicles functional safety).
4.3 Requirements and Considerations
4.3.1 Introduction
Clause 4.2 focused on the manoeuvre coordination service which can be decomposed into three distinguishable phases:
• The intent sharing phase which initiates the manoeuvres coordination service providing data elements
explaining an ITS-S intent (goal) and associated reference trajectory evolution need of one or several subject
vehicles.
• The agreement-seeking phase which objective is to obtain the complete agreement of local cooperative
vehicles which need to be involved in a collective action to successfully achieve the initial goal being
proposed.
ETSI
13 ETSI TR 103 578 V2.1.1 (2024-04)
• The achievement of the collective action which results of the obtained agreement. However, if this collective
action is not completed, local traffic evolutions may impact it leading to some form of collective
reconfiguration of the action.
Manoeuvre coordination is based on the prediction capabilities of involved ITS and real-time interactions existing
between the functions which are active in the ITS architecture.
4.3.2 Manoeuvre Prediction
A critical precondition for planning safe manoeuvre in road traffic is a precise and correct manoeuvre prediction of road
users. These predictions are based on the observation of the road users. Currently, the manoeuvre of road users also
depends on unobservable parameters, such as their selected routes, the objects' physical capabilities, or individual
comfort, and behaviours parameters. Therefore, predictions of other objects by an ego vehicle are uncertain since this
information is missing. To address this uncertainty, road users act more cautiously to increase safety, that also means
that they drive slower, wait longer until they found larger gaps to merge in and so on, thereby reducing the overall road
traffic efficiency.
Consequently, the prediction improvement is one requirement which needs to be considered for the achievement of
manoeuvre coordination. The prediction improvement can be achieved via local context and objects (static and mobiles)
perception and the sharing of this perception for example using the CPS.
By adding further data sources such as CAS, VBS and CPS, the pool of available information to the ego vehicle is
increased. However, even with these services, the exact planned manoeuvre by all road users can never be determined
by the ego vehicle to a high degree of certainty. This is where the explicit communication of a road user intent of any
sort to another over a dedicated service like MCS can cover the information gap and provide the receiving vehicle with
tools to better estimate other road users' behaviours.
Navigation systems generally plan the itinerary that a mobile object follows to reach an identified destination from a
known origin and this, accordingly to criteria provided by the services' user. This itinerary can then be decomposed into
a set of relevant trajectories which can be used for the object mobility prediction. The prediction uncertainty level
depends on the type of mobile object which is considered:
• A vehicle moving in an automated mode respects the navigation plan, excepted in exceptional situations
disturbed by an unexpected event (for example, an accident).
• A vehicle moving in a human driven mode may not respect the proposed navigation plan accordingly to
human decisions or driving errors. This is added to unexpected exceptional situations.
• A vulnerable road user may not respect a proposed navigation plan which is more difficult to provide due to
less topographic constraints, the low inertia of VRUs and random behaviours related to VRUs risk level
profiles.
However, one critical limitation is the capability of a road user to accurately determine its own trajectory. Only when
the ego estimation is highly accurate can the road user receiving the information do effective estimation. The position
accuracy can already prove to be a limitation if the received manoeuvre information is placing the sender vehicle on a
different lane than where it plans the manoeuvre.
More information is provided in annex A.
4.3.3 ITS Architecture Requirements
Four functional categories can be identified in an Intelligent Transport System, as shown in Figure 1.
ETSI
14 ETSI TR 103 578 V2.1.1 (2024-04)

Figure 1: Four functional categories of an ITS
Main applications (e.g. navigation, traffic management, safety, etc.) are supported by functions which are present in the
four ITS categories which are represented in Figure 1.
The navigation and collision avoidance functions are key applications of automated vehicles which have to move
dynamically on existing road infrastructures according to planned itineraries and th
...