ISO 23239-1:2021

Road vehicles - Vehicle domain service (VDS) - Part 1: General information and use case definitions

This document, as the first document in the ISO 23239 series, provides a basic definition of vehicle domain service and supplementary information on detailed concepts, as well as definitions of the typical and supplementary use cases being used to define the specification of applications. Detailed specifications of communications and applications are provided in other documents in the ISO 23239 series, and they are not provided in this document. NOTE The remote processes by the tools connected to the on-board diagnosis (OBD) connector in a vehicle, such as repair and maintenance, prognostics, monitoring, configuration and reprogramming of vehicle are out of the scope of this document.

Véhicules routiers — Service du domaine du véhicule (SDV) — Partie 1: Information générale et définitions des cas d'utilisation

General Information

• Status: Published
• Publication Date: 08-Jun-2021
• ICS: 43.040.15 - Car informatics. On board computer systems
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31 - Data communication
• Current Stage: 6060 - International Standard published
• Start Date: 09-Jun-2021
• Due Date: 23-Jan-2021
• Completion Date: 09-Jun-2021

Overview

ISO 23239-1:2021 - "Road vehicles - Vehicle domain service (VDS) - Part 1: General information and use case definitions" defines the foundational concepts, terminology and typical use cases for Vehicle Domain Service (VDS). This first part of the ISO 23239 series establishes a common vocabulary and functional overview (for example VDS, VDDM - vehicle domain dynamic map, VDSA - vehicle-domain service account, VDS master time) and describes business and system use cases, system sequences, architecture variations, and information security considerations. Detailed communication and protocol specifications are intentionally not included here and appear in other parts of the ISO 23239 series. Remote OBD tool functions (repair, reprogramming, prognostics) are out of scope.

Key topics and requirements

• Core definitions and actors: master vehicle, domain actor, vehicle domain, VDS account and master time.
• Vehicle Domain Dynamic Map (VDDM): role of dynamic and static map components shared inside a vehicle domain.
• Primary VDS functions & variations: basic VDS functions, registration, traffic explorer, traffic reporter, manoeuvre coordinator and scenario variations.
• System architecture: reference and typical architectures, including VDS hosted on vehicle multimedia systems and interactions with network operators.
• Time synchronization: requirements for VDS master time to support coordinated decision-making.
• Security & privacy: high-level information security guidance for secure and reliable VDS operation.
• Use case coverage: business use cases, system use cases (start/stop, setup, selection, data collection, manoeuvre queries) and sequence diagrams.
• Informative annexes: detailed scenario variations, smart traffic architecture examples and multimedia reference models.

Applications

ISO 23239-1 is used where vehicles need to share, receive or coordinate actionable driving information in short-range networks without depending on heavy roadside infrastructure. Practical applications include:

• Coordinated driving manoeuvres and negotiation between neighboring vehicles.
• Localized dynamic maps for enhanced perception beyond on-board sensors.
• Short-range traffic reporting and exploration to improve traffic flow and safety.
• Integration points between VDS and vehicle multimedia or telematics systems.
• Inputs to smart traffic architecture planning and V2X feature design.

Who should use this standard

• Automotive OEMs and system architects designing in-vehicle communications and cooperative driving features.
• Tier-1 suppliers building VDS-capable telematics, multimedia or domain controllers.
• Connected vehicle platform and software providers.
• Policy makers, test labs and researchers defining conformance, security and interoperability for cooperative vehicle applications.

Related standards

• Other parts of the ISO 23239 series (for detailed communications and application specifications).
• Complementary V2X and automotive cybersecurity standards (refer to ISO catalogue and national bodies for cross-references).

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 23239-1
First edition
2021-06
Road vehicles — Vehicle domain
service (VDS) —
Part 1:
General information and use case
definitions
Véhicules routiers — Service du domaine du véhicule (SDV) —
Partie 1: Information générale et définitions des cas d'utilisation
Reference number
©
ISO 2021
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii © ISO 2021 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
3.1 Basis of vehicle domain . 1
3.2 Primary actors . 2
3.3 Secondary actors . 3
4 Abbreviated terms . 3
5 Conventions . 4
5.1 Documents overview on OSI based services. . 4
5.2 General policy structure . 5
6 General information for vehicle domain service . 6
6.1 General . 6
6.2 Vehicle domain service . 6
6.3 Vehicle domain dynamic map service . 7
6.4 Variations of vehicle domain services . 8
6.4.1 Basic functions of vehicle domain service . 8
6.4.2 Vehicle domain registration service . 9
6.4.3 Traffic explorer service .10
6.4.4 Traffic reporter service .11
6.4.5 Manoeuvre coordinator service .12
6.4.6 Scenario variations of vehicle domain service .13
6.5 Time synchronization in VDDMS .16
6.6 Other variations of vehicle domain services .16
6.6.1 Vehicle domain digital key service .16
6.7 System architecture of vehicle domain services .17
6.7.1 General.17
6.7.2 Basic system architecture of vehicle domain service .18
6.7.3 Typical system architecture variation of vehicle domain service .18
6.7.4 Vehicle domain service on vehicle multimedia service .19
6.8 Network operators related to VDS .20
6.9 VDS in smart traffic architecture model proposal .21
6.10 Information security in VDS .24
7 Business use cases for VDS .24
7.1 General .24
7.2 Business use case of vehicle domain registration .24
7.3 Business use case of traffic explorer .25
7.4 Business use case of traffic reporter .26
7.5 Business use case of manoeuvre coordinator .27
8 System sequences for VDS .27
8.1 General .27
8.2 Basic elements of general BUC .28
9 System use cases for VDS .29
9.1 General .29
9.2 System use case of VDS start .29
9.3 System use case of communication set up .29
9.4 System use case of security set up .30
9.5 System use case of VDS selection .31
9.6 System use case of VD data collection.31
9.7 System use case of VD status report .32
9.8 System use case of driving manoeuvre query .32
9.9 System use case of VDS stop .33
Annex A (informative) Scenario variations of vehicle domain dynamic map service .35
Annex B (informative) Typical examples of smart traffic architecture model.43
Annex C (informative) Reference model of vehicle domain service on vehicle multimedia
system .51
Bibliography .54
iv © ISO 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www .iso .org/
iso/ foreword .html.
This document was prepared jointly by Technical Committee ISO/TC 22, Road vehicles, Subcommittee
SC 31, Data communication, in collaboration with ITU-T (as H.VDS-UC).
A list of all parts in the ISO 23239 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
Introduction
The connected vehicles are expected to expand and become even more popular in the markets of
different countries. A variety of technologies are being developed and discussed for many applications.
Everyone who drives a car collects traffic information to determine the correct driving behaviour and
accurately recognize the relevant traffic information and driving conditions without delay. Although
the autonomous driving function takes over the driver’s operation, there is the same value in a judgment
of correct driving behaviour. While many independent autonomous driving cars and intelligent
driver assistance functions provide information collected by various sensors, LIDAR and radar, their
performance is limited and the inaccuracies increase with ambient conditions such as weather and
blind spots.
In addition, the blinkers normally equipped with all vehicles only provide one-way fragmentary
information, though. If the vehicle communicates with other neighbouring vehicles or traffic
participants and exchanges various information, it will be able to go beyond the limits of its sensor
capabilities and blind spots to provide a more accurate assessment of the traffic situation. It will also
be possible to negotiate planned driving manoeuvres with neighbouring vehicles and to coordinate the
sequence and timing of driving manoeuvres.
This ability to share information between vehicles defined in this document is provided only on a
direct communication network between the vehicle and neighbouring traffic participants. It will
be accomplished with on-board functionality without investing in a significant communication
infrastructure on the road. This will enable vehicles to make more accurate and appropriate driving
choices, which will provide a number of benefits such as reducing traffic accidents and congestion with
improving traffic efficiency.
An important aspect of this documentation development is focusing on implementation points
throughout the vehicle. Typical use cases are collected, from which distinctive aspects of the
implementation specification are derived. And beyond simple information exchange, the resulting
information is reviewed, evaluated, and then used to generate reliable information that can be applied
to critical vehicle controls.
The ISO 23239 series is developed within a unique standard number, so that it will eliminate
inconsistencies and redundancies within the documentation. As a result of these tasks, compatibility
and interoperability will be confirmed, being added the economy and efficiency of implementation
with global consistency. Furthermore, by providing a concrete path from existing simple and partial
communication interface to trusted vehicle implementation, it is expected to support a smooth launch
of brand-new vehicle application and accelerate the introduction of next generation communication
technologies into the future vehicle market.
vi © ISO 2021 – All rights reserved

INTERNATIONAL STANDARD ISO 23239-1:2021(E)
Road vehicles — Vehicle domain service (VDS) —
Part 1:
General information and use case definitions
1 Scope
This document, as the first document in the ISO 23239 series, provides a basic definition of vehicle
domain service and supplementary information on detailed concepts, as well as definitions of the
typical and supplementary use cases being used to define the specification of applications.
Detailed specifications of communications and applications are provided in other documents in the
ISO 23239 series, and they are not provided in this document.
NOTE The remote processes by the tools connected to the on-board diagnosis (OBD) connector in a vehicle,
such as repair and maintenance, prognostics, monitoring, configuration and reprogramming of vehicle are out of
the scope of this document.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1 Basis of vehicle domain
3.1.1
vehicle domain
VD
limited group of secure and reliable connections, provided by the master vehicle (3.2.2) and established
on an existing network service by registering the domain actor (3.2.3)
Note 1 to entry: Vehicle domain is only related to network connection between master vehicle and domain actor.
Physical or geometrical conditions are not included.
3.1.2
vehicle domain dynamic map
VDDM
dynamic map in the vehicle domain (3.1.1) generated by a master vehicle (3.2.2)
Note 1 to entry: VDDM consists of static high definition features, dynamic actors and other characteristics.
3.1.3
vehicle-domain service
VDS
group of functions provided by the master vehicle (3.2.2) to the domain actor (3.2.3) in the vehicle
domain (3.1.1)
Note 1 to entry: It includes vehicle domain dynamic map (3.1.2).
3.1.4
vehicle-domain service account
VDSA
unique identifier of the domain actor (3.2.3), certified and issued by the vehicle domain service operator
(3.3.7)
3.1.5
vehicle-domain service master time
VDS master time
basic time steps for synchronization between the master vehicle (3.2.2) and the domain actor (3.2.3)
generated by the master vehicle
Note 1 to entry: It generates both past and future time steps.
3.1.6
vehicle-domain service system
VDSS
physical structure that consists of the master vehicle (3.2.2) (server), neighbouring vehicles (client),
other traffic participants (clients), and a wireless network between the server and its clients that
provides vehicle domain service
Note 1 to entry: An element in the VDSS is named primary actor (3.2.1). Elements outside the VDS (3.1.3) are
named secondary actors (3.3.1).
3.2 Primary actors
3.2.1
primary actor
PA
master vehicle (3.2.2) or one of its clients in the vehicle domain (3.1.1)
3.2.2
master vehicle
MV
server of vehicle domain (3.1.1)
Note 1 to entry: This means the vehicle in which the server function is implemented.
3.2.3
domain actor
DA
client of a master vehicle (3.2.2) in a vehicle domain (3.1.1)
Note 1 to entry: They are in general traffic participants, such as vehicles, bikes and walkers around the master
vehicle.
3.2.4
domain vehicle
DV
vehicle client of a master vehicle (3.2.2) in a vehicle domain (3.1.1)
2 © ISO 2021 – All rights reserved

3.2.5
domain participant
DP
client of a master vehicle (3.2.2) except for a vehicle in a vehicle domain (3.1.1)
EXAMPLE Walker, bike and other traffic participants with network function.
3.2.6
domain sensor
DS
client of a master vehicle (3.2.2) in a vehicle domain (3.1.1) with sensing function
Note 1 to entry: It is the network entity and typically, a vehicle with network and sensing function is often both a
domain vehicle (3.2.4) and domain sensor at the same time.
Note 2 to entry: The general definition of a domain sensor never excludes the domain actor (3.2.3) except vehicle.
3.3 Secondary actors
3.3.1
secondary actor
SA
logical or functional network entity outside the vehicle domain (3.1.1)
3.3.2
smart-city traffic manager
SCTM
central management server of traffic information in a smart city
3.3.3
smart traffic
optimized traffic controlled by the smart city traffic manager (3.3.2) in a smart city
3.3.4
smart traffic architecture model proposal
STAMP
model proposal of the multi-layer-like control structure of smart traffic (3.3.3)
3.3.5
traffic operator
TO
lower functional server of the smart city traffic manager (3.3.2) that manages traffic control information
3.3.6
traffic monitor
TM
lower functional server of the smart city traffic manager (3.3.2) that monitors traffic status
3.3.7
vehicle domain service operator
VDSO
service operator who issues the vehicle-domain service account (3.1.4)
4 Abbreviated terms
For the purpose of this document, the following abbreviated terms apply:
BUC business use case
DSRC dedicated short range communication
IP internet protocol
LDM local dynamic map
NTP network time protocol
STAMP smart traffic architecture model proposal
SUC system use case
TCP transmission control protocol
TLS transport layer security
UTC universal time
5 Conventions
5.1 Documents overview on OSI based services.
Figure 1 shows the organization and coverage of each of the documents in the ISO 23239 series on the
OSI layered architecture.
The definition of OSI layer model is defined in ISO/IEC 7498-1.
As indicated by the bold framed shapes, this document defines general information and use case
definitions. This is the base document, as the other documents in the ISO 23239 series are detailed and
separated specific documents according to the OSI layered architecture.
4 © ISO 2021 – All rights reserved

Key
Coverages
description coverage of this document
description coverages of other parts of ISO 23239 series
Figure 1 — Documents overview of vehicle domain service
The upper layers are not fit for proper TCP/IP communication.
5.2 General policy structure
This document provides the policies for specifications as general information. The list of the policies
consists of recommendation, permission, possibility and capability. Additional statements are attached
in order to provide better understandings. All policies are expressed in a unified format.
This document applies a policy structure, i.e. a unique number identifies each individual policy included
in this document. It will improve the readability with easier policy tracking. The following modified
recommended format will be applied:
'VDS'’Y’ - ‘xxx’ — policy name
[
policy text
]
where
— 'VDS' represents the ISO 23239 series,
— 'Y' represents the specific part of the ISO 23239 series,
— 'xxx' represents the individual policy number,
— 'policy name' represents the name of policy,
— 'policy text' defines the provisions of policy and
— '[' and ']' defines the starting and ending points of policy.
EXAMPLE
VDS1 - 000 — The form of general policy
[
This sentence should give the example form of the general policy defined in this document.
]
6 General information for vehicle domain service
6.1 General
The vehicle domain is the area that consists of road vehicles in which the applications are implemented.
The applications provide integrated information services used in the vehicle. The provided information
is generated from various source information, acquired by the communication, concerned with the area
around the vehicle such as traffic condition and so on. The source information is acquired directly or
indirectly by communication with neighbouring vehicles and other traffic participants (bikes, bicycles
and walkers) without any support by the road sided infrastructure.
This clause gives the basic definitions of vehicle domain services.
6.2 Vehicle domain service
The master vehicle generates a vehicle-domain network. Surrounding participants, such as vehicles,
bikes and walkers, join that network as domain actors. Various types of sensors equipped with
participants could also join it as additional actors. The master vehicle provides vehicle domain services
to the actors participating in its domain service network.
VDS1 - 001 — Vehicle domain service
[
If a vehicle is the master vehicle of the vehicle domain, it should provide vehicle domain services to the
domain actors.
]
Figure 2 shows a basic vehicle domain service. The master vehicle communicates with domain actors,
such as domain vehicles, sensors and participants. The master vehicle provides vehicle domain services
and domain actors respond to them.
6 © ISO 2021 – All rights reserved

Key
1 vehicle domain
2 master vehicle
3 domain vehicle
4 domain sensor
5 domain participant
Figure 2 — Basic vehicle domain service
The minimum structure of the vehicle domain service consists of one master vehicle and one domain
actor. The field in which the vehicle domain is located includes everywhere the vehicle goes, such as
traffic roads, public parking areas and private garages.
VDS implementation depends on the original equipment manufacturer's (OEM) decision. Activation of
implemented VDS function depends on user’s or owner’s decision, local regulation or other rules before
driving.
6.3 Vehicle domain dynamic map service
The most typical service of VDS is the vehicle domain dynamic map service. The VDDM is the beginning,
original and most important service of VDS. It is applied to the vehicle driving with no restriction of
location, i.e. on the road, street, freeway, public parking area and private road.
The master vehicle collects relevant information from all of domain actors. The domain sensors report
acquired information about silent traffic participants and conditions instead of them. The master
vehicle generates dynamic map information within the vehicle domain. The master vehicle provides
VDDM-based services to the domain actors.
VDS1 - 002 — Vehicle domain dynamic map service
[
The master vehicle should provide vehicle domain dynamic map services to the domain actors.
]
Figure 3 shows a typical vehicle domain dynamic map service. The master vehicle communicates with
the domain actors, such as domain vehicles, sensors and participants. The master vehicle provides
vehicle domain dynamic map services and the domain actors respond to them.
Key
1 vehicle domain
2 master vehicle
3 domain vehicle 1
4 domain vehicle 2
5 domain vehicle 3
6 domain sensor 1
7 domain sensor 2
8 domain participant 1
9 domain participant 2
10 domain participant 3
Figure 3 — Typical vehicle domain dynamic map service
6.4 Variations of vehicle domain services
6.4.1 Basic functions of vehicle domain service
The basic functions of VDS are collecting and processing traffic and driving information. Generated
information services are used to get better recognition of traffic situations and improve decision of
driving behaviour.
These kinds of generated information provided in a virtual map format consist of information about
dynamic actors, such as vehicles and participants, and static high definition road features. This is
defined as a vehicle domain dynamic map.
To perform various functions, VDS has multiple services.
Below are the typical services of VDS.
— Vehicle domain registration: the master vehicle calls the domain actors to participate in its domain.
A domain actor will respond to the master vehicle and exchange credentials. If mutual identification
processes are successfully completed, a secure connection shared by the master vehicle and the
domain actor is generated.
— Traffic explorer: the master vehicle collects traffic information by communicating with the domain
actors. The traffic information collected is the synchronized position and other information of the
8 © ISO 2021 – All rights reserved

domain actors around the master vehicle or information potentially related to the driving behaviour
of the master vehicle.
— Traffic reporter: the master vehicle reports the collected local traffic information, obtained by
the traffic explorer service, to the other traffic servers, such as central dynamic map operator or
another vehicle domain server. It will be shared to update the latest status and it can be reused in a
similar use case of another master vehicle.
— Manoeuvre coordinator: the master vehicle generates its driving manoeuvre plan, it consists of a
series of position information with synchronization time. The master vehicle sends it to the relevant
domain vehicle and asks the corresponding plan of the domain vehicle. The master vehicle and
domain vehicle share their driving manoeuvre plan to get an agreement or negotiate the coexistence
of their plans. If it is successfully done, planned driving manoeuvre will be performed safely under
the shared understandings of them.
6.4.2 Vehicle domain registration service
The master vehicle provides the following vehicle domain services.
VDS1 - 003 — Vehicle domain registration service
[
The master vehicle should support the vehicle domain registration service.
]
Figure 4 shows a typical vehicle domain registration service. The master vehicle calls neighbouring
vehicles and traffic participants to join the vehicle domain. For example, the vehicle in the rear position
is able to join the invited vehicle domain by performing the registration. If the registration is performed
successfully, the vehicle in the rear position will join the vehicle domain as a domain vehicle. Details of
procedures will be provided in the subsequent parts of the ISO 23239 series.
In case that the entity of sensor is also registered, it will join the vehicle domain as a domain sensor.
Key
1 vehicle domain
2 master vehicle
3 domain vehicle
4 domain sensor
Figure 4 — Typical vehicle domain registration service
The vehicle domain has the driving plan of the master vehicle. The driving plan is a kind of driving
schedule with a longer period than a driving manoeuvre, such as ‘turn right at the intersection 1 km
away’. If the driving plan of a domain vehicle is different from that of the vehicle domain, the domain
vehicle will exit from the vehicle domain and generate its own vehicle domain.
6.4.3 Traffic explorer service
The master vehicle provides the following vehicle domain service.
VDS1 - 004 — Traffic explorer service
[
The master vehicle should support the traffic explorer service.
]
Figure 5 shows a typical traffic explorer service. The master vehicle asks the domain actors for specific
parameters (type, dimensions) and measured parameters (position, speed) calibrated with VDS master
time. The domain actor responds to it with synchronized information. The master vehicle will create a
vehicle domain map.
Key
1 vehicle domain
2 master vehicle
3 domain vehicle 1
4 domain vehicle 2
5 domain vehicle 3
6 domain vehicle 4
7 domain sensor 1
8 domain sensor 2
9 domain participant 1
10 domain participant 2
11 domain participant 3
Figure 5 — Typical traffic explorer service
In order to generate a VDDM, the master vehicle asks each domain actor to provide a list of its properties.
All property tables with the responses to the master vehicle are required to be synchronized to the
domain master time provided by the master vehicle.
10 © ISO 2021 – All rights reserved

As the one of important procedure of VDDM generation, it is necessary that collected properties are
validated by each other. If validation is completed successfully, the property status changes to trustable.
VDS1 - 005 — Validation of vehicle domain map
[
The master vehicle should validate vehicle domain map to be trusted.
]
More detailed procedures will be provided in the following series part of this document.
6.4.4 Traffic reporter service
The master vehicle provides following vehicle domain service.
VDS1 - 006 — Traffic reporter service
[
The master vehicle should support the traffic reporter service.
]
Figure 6 shows a typical traffic reporter service. There are multiple master vehicles driving on the
road. Master vehicles create their VDS maps information. They report some part of VDS maps to other
master vehicles if foresight information is included. Additionally, they also send the created map report
to the central LDM server for the latest map update.
Key
1 vehicle domain 1
2 vehicle domain 2
3 master vehicle 1
4 master vehicle 2
Figure 6 — Typical traffic reporter service
Before master vehicle 1 builds up vehicle domain 1, it will search for neighbouring vehicle domains.
Master vehicle 1 finds vehicle domain 2 and its driving plan matches that of master vehicle 1; master
vehicle 1 will join vehicle domain 2. If driving plan is different and it is better to establish vehicle domain
1, master vehicle 1 will establish vehicle domain 1 with a different driving plan from vehicle domain 2.
Details of sequences will be defined in subsequent parts of the ISO 23239 series.
Basically, traffic reporter service has valid direction and an area for the receiver of the vehicle domain.
The master vehicle and domain actors within the vehicle domain are driving forward and never
encounter the incident that happened at the back of the vehicle domain. Also, other vehicle domains
driving in the opposite direction on the opposite lane will be invalid to receive the traffic reporter
service.
Vehicle domain service exchanges a lot of messages, giving restrictions to the communication media
access to valid information will have a significant effect on the efficiency of communication.
VDS1 - 007 — Selected media access of vehicle domain service
[
The vehicle domain service should be transmitted only to valid receivers.
]
One of the typical schemas for selected access are filtering access control. A couple of schemas will be
prepared for vehicle domain service message exchange. More detailed procedures will be provided in
the following series part of this document.
NOTE There exists no contradiction between extended vehicle and traffic reporter of vehicle domain service.
V2X solutions could exist in many ways depending on each markets’ requirements.
6.4.5 Manoeuvre coordinator service
The master vehicle provides following vehicle domain service.
VDS1 - 008 — Manoeuvre coordinator service
[
The master vehicle should support the manoeuvre coordinator service.
]
Figure 7 shows a typical manoeuvre coordinator service. The master vehicle generates its manoeuvre
plan with the VDS master time. Domain vehicles respond to it with the synchronized estimated
information.
In general, the typical driving processes consists of the recognition, decision and operation stages.
Recognition of the traffic situation and making the most appropriate and safest driving decisions will be
named as the preparation stage. For example, if preparation stage takes 5 s and the following operation
stage takes the same time, the master vehicle will generate its driving manoeuvre plan starting from
its position of 5 s later, end of preparation stage with following positions of 1 s durations, expressed in
Figure 7 with sequential blue dot squares. Master vehicle will ask the following domain vehicle about
its relevant manoeuvre plan. The domain vehicle will respond with the asked driving manoeuvre plan
expressed with sequential red dot squares. The starting time of each driving manoeuvre plan or turn of
them will be adjusted, if necessary.
Whole processes about driving manoeuvre negotiation are necessary to be successfully finished within
preparation stage. This indicates that the VDS includes this service and will be implemented with the
next generation of communication technology with faster speed, wider traffic bands and lower latency.
The VDS communication is definitely different from existing broadcast message flow.
12 © ISO 2021 – All rights reserved

Key
1 master vehicle
2 domain vehicle
3 master vehicle’s driving manoeuvre plan
4 domain vehicle’s driving manoeuvre plan
Figure 7 — Typical manoeuvre coordinator service
In some cases, it is necessary for the master vehicle and the domain vehicle to arrange their manoeuvre
plan. Negotiated plans will be authorized by driving responsibility, such as driver or automated driving
manager. Judgement criteria of arrangement necessity, basic priorities of manoeuvres and negotiation
strategy and authorization sequence requirements are out of scope of this document, they will be
addressed to other activities.
6.4.6 Scenario variations of vehicle domain service
In addition to service types, traffic conditions and road shape greatly influence for a scenario of the
VDS. The following scenario examples show representative service scenarios. Other examples are
provided in Annex A.
All service scenarios are incorporated into each business use case, to be covered all as an element of the
system use case. As for business use case and system use case, see Clauses 7 and 9.
VDS1 - 009 — Service scenarios and business and system use cases
[
The business use case and system use case element should cover all service scenarios.
]
Figure 8 shows one of the service scenario examples of traffic explorer service. The master vehicle
is driving on a straight road, it collects relevant information from all around actors and generates a
vehicle domain map.
Key
1 master vehicle
2 domain vehicle 1
3 domain vehicle 2
4 domain vehicle 3
5 domain sensor 1
6 domain sensor 2
7 domain participant 1
8 domain participant 2
9 domain participant 3
Figure 8 — Scenario of traffic explorer on straight road
Figure 9 shows one of the service scenario examples of traffic reporter service. The master vehicles are
driving on a straight road. The master vehicle 2 generates its vehicle domain map, including the red
signal and relevant traffic status. It is issued as a traffic report to the following master vehicles to share
incoming traffic situation.
14 © ISO 2021 – All rights reserved

Key
1 vehicle domain 1
2 vehicle domain 2
3 vehicle domain 3
4 master vehicle 1
5 master vehicle 2
6 master vehicle 3
7 domain sensor 1 (belongs to vehicle domain 2)
8 domain sensor 2 (belongs to vehicle domain 3)
9 domain participant 1 (belongs to vehicle domain 1)
10 domain participant 2 (belongs to vehicle domain 3)
11 red signal
Figure 9 — Scenario of traffic reporter of red signal
Figure 10 shows one of the service scenario examples of manoeuvre coordinator service. The master
vehicle is driving on a straight road, it wants to make right-lane change. It generates a vehicle domain
map and learns that a manoeuvre coordination is necessary with domain vehicle #1. The master vehicle
generates a manoeuvre plan of right-lane change with the VDS master time to coordinate it with domain
vehicle 1.
Key
1 master vehicle
2 domain vehicle 1
3 domain vehicle 2
4 driving manoeuvre of master vehicle
5 driving manoeuvre of domain vehicle 1
6 driving manoeuvre of domain vehicle 2
Figure 10 — Scenario of manoeuvre coordinator of right lane change
These scenarios include the behaviour by actors with different responsibilities such as sending
information, validating received information, following decisions and the driving actions to align to
manoeuvres. All behaviours that are required by actors with different responsibilities are authorized
and approved by the necessary authorities or actors with different responsibilities. Details about the
different responsibilities are out of scope of this document.
6.5 Time synchronization in VDDMS
The vehicle domain service uses calibration of position information by synchronized time. This is
applied to both the master vehicle and domain actors. The master vehicle generates the VDS master
synchronization time. The domain actors respond to the master vehicle with their calibrated
information by synchronizing to it.
VDS1 - 010 — VDS master time generation
[
The master vehicle should generate the VDS master time as the standard time of response information
by the domain actors.
]
VDS1 - 011 — Time synchronization in VDS
[
The domain actors should respond to the master vehicle their information calibrated by synchronizing
to the VDS master time sent by the master vehicle.
]
The vehicle-domain service master time is generated on UTC and adjusted by the network time protocol
(NTP) defined in RFC 5905 or the precision time protocol (PTP) defined in IEEE 1588:2008.
NOTE 1 The VDS master time is defined in detail in ISO 23239-2.
NOTE 2 Functional safety has no relation to time synchronization based on the VDS master time.
6.6 Other variations of vehicle domain services
6.6.1 Vehicle domain digital key service
Providing digital key service, the master vehicle issues various types of digital key messages to the
customer, one per domain participant. The secure protected and packaged message for the digital key
is generated by the master vehicle and sent to the customer. The message is received by the customer
with their mobile device, extracted to the functional application of the digital key on the customer’s
mobile device. The digital key services are only applied to stopped or parked vehicles, they are never
activated while the vehicle is driving.
VDS1 - 012 — Vehicle domain digital key service
[
The master vehicle may provide vehicle domain digital key services to a domain participant.
]
There exist some variations of the digital key service according to their objects. General digital key
services have different access control of vehicle functions with restricted time durations. Typical
variations are as follows.
— Car-sharing key service: the master vehicle issues the digital key service with full access control of
vehicle functions with a restricted time duration linked to car rental or sharing period, such as from
3 days to 1 week. The customer receives the digital key application from the master vehicle, and it
will work as the vehicle key device within the car sharing period. It is not necessary for operators to
hand over a vehicle key to their customer.
— Valet parking key service: the master vehicle issues the digital key service wit
...