ISO 24102-1:2013

INTERNATIONAL ISO
STANDARD 24102-1
First edition
2013-07-01
Intelligent transport systems —
Communications access for land
mobiles (CALM) — ITS station
management —
Part 1:
Local management
Systèmes intelligents de transport — Accès aux communications des
services mobiles terrestres (CALM) — Gestion des stations ITS —
Partie 1: Gestion locale
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, 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
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 2
5 Requirements . 2
6 CI basic management . 3
6.1 General . 3
6.2 CI status . 3
6.3 Cross-CI prioritization . 8
6.4 VCI I-Parameters.10
6.5 Regulatory information management .11
6.6 Manufacturer access .11
7 Congestion control .11
8 Neighbour list .13
9 Paths and flows.13
10 Legacy CI .15
10.1 Registration .15
10.2 CI states .16
11 Management data elements .16
11.1 ITS-SCU list .16
11.2 VCI list .16
11.3 VCI performance parameter list .16
11.4 Cross-CI prioritization list .17
11.5 Application requirements list .18
12 Conformance
..........................................................................................................................................................................................................19
13 Test methods .19
Annex A (normative) ASN.1 modules .20
Annex B (normative) Management parameters .23
Bibliography .28
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. 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. 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.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
ISO 24102 consists of the following parts, under the general title Intelligent transport systems —
Communications access for land mobiles (CALM) — ITS station management:
— Part 1: Local management
— Part 3: Service access points
— Part 4: ITS station-internal management communications
— Part 5: Fast service advertisement protocol (FSAP)
The following parts are under preparation:
— Part 2: Remote management
— Part 6: Path and flow management
iv © ISO 2013 – All rights reserved

Introduction
This International Standard is part of a family of International Standards for communications access for
land mobiles (CALM). An introduction to the whole set of International Standards is provided in ISO 21217.
This part of ISO 24102 is part 1 of a multipart International Standard which determines the intelligent
transport systems (ITS) local station management.
The ITS station management entity provides functionality related to the management of communication
protocol layers and the security entity presented in the ITS station reference architecture specified in
ISO 21217 and presented in Figure 1, and in line with the general ITS architecture specified in ISO 21217.
Applications
API
MS
Facilities
NF
Networking &
Transport
IN
Access
Communications
Figure 1 — ITS station reference architecture with named interfaces
ITS station management is specified as a distributed process, where no supervisory entity is employed.
Management
MI MN MF
SI SN SF
Security
INTERNATIONAL STANDARD ISO 24102-1:2013(E)
Intelligent transport systems — Communications access
for land mobiles (CALM) — ITS station management —
Part 1:
Local management
1 Scope
This part of ISO 24102 provides specifications for intelligent transport systems (ITS) station management
to be compliant with the ITS station reference architecture and the set of communications access for
land mobiles (CALM) related standards.
Local ITS station management protocols are specified by means of management messages and data that
flow between the ITS station management entity and
— the security entity,
— the application entity, and
— the various communication protocol layers
of the ITS station reference architecture specified in ISO 21217.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2
ISO 21217, Intelligent transport systems — Communications access for land mobiles (CALM) — Architecture
ISO 21218, Intelligent transport systems — Communications access for land mobiles (CALM) — Access
technology support
ISO 24102-3, Intelligent transport systems — Communications access for land mobiles (CALM) — ITS station
management — Part 3: Service access points
ISO 24102-4, Intelligent transport systems — Communications access for land mobiles (CALM) — ITS station
management — Part 4: Station-internal management communications
ETSI TS 102 797-1, Intelligent Transport Systems (ITS); Road Transport and Traffic Telematics (RTTT);
Test specifications for Intelligent Transport Systems, Communications access for land mobiles (CALM), ITS
station management (ISO 24102); Part 1: Protocol Implementation Conformance Statement (PICS) proforma
ETSI TS 102 797-2, Intelligent Transport Systems (ITS); Road Transport and Traffic Telematics (RTTT);
Test specifications for Intelligent Transport Systems, Communications access for land mobiles (CALM), ITS
station management (ISO 24102); Part 2: Test Suite Structure and Test Purposes (TSS & TP)
ETSI TS 102 797-3, Intelligent Transport Systems (ITS); Road Transport and Traffic Telematics (RTTT);
Test specifications for Intelligent Transport Systems, Communications access for land mobiles (CALM), ITS
station management (ISO 24102); Part 3: Abstract Test Suite (ATS) and partial PIXIT information
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21217, ISO 21218, ISO 24102-3,
and the following apply.
3.1
regulatory information
set of regulatory requirements for radio wave emission
3.2
ITS-S communication unit
addressable instance of the ITS station reference architecture comprising as a minimum the ITS-S router
functionality
3.3
ITS-S path
part of a communication path between a source node and an anchor node being uniquely identified by a
LinkID (identifying a CI in the source node and the next hop node) and by the anchor node
4 Abbreviated terms
For the purposes of this document, the abbreviated terms given in ISO 21217, ISO 21218, ISO 24102-3,
and the following apply.
ITS-SCU ITS station communication unit
ITS-SSI ITS station state information
LDM local dynamic map
n.a. not applicable
PDUs protocol data units
QoS quality of service
RI regulatory information
5 Requirements
The ITS station management entity provides functionality specified in the various parts of this multipart
International Standard:
1) The functionality of local ITS station management specified in this part of ISO 24102.
2) The functionality of remote ITS station management will be specified in ISO 24103-2.
3) The functionality of management service access points specified in ISO 24102-3.
4) The functionality of ITS station-internal management communications specified in ISO 24102-4.
5) The functionality of the “Fast Service Advertisement Protocol” (FSAP) specified in ISO 24103-5.
General management functionality shall be as specified in this part of ISO 24102.
Means to secure the access to management functionality need to be specified within the global context
of CALM security. Details are outside the scope of this part of ISO 24102.
2 © ISO 2013 – All rights reserved

Detailed mandatory requirements are specified in the following clauses of this part of ISO 24102.
— Clause 6 specifies basic management procedures related to communication interfaces.
— Clause 7 describes congestion control.
— Clause 8 specifies neighbour lists and the link to the “Local Dynamic Map” (LDM) application.
— Clause 9 describes the concept of flow and path management.
— Clause 10 specifies management of “Legacy CIs”.
— Clause 11 specifies management data elements.
— Clause 12 specifies conformance declaration.
— Clause 13 specifies test methods.
— Annexes provide further mandatory requirements.
6 CI basic management
6.1 General
Basic management procedures related to communication interfaces (CI) shall access a “(Virtual)
Communication Interface” (CI/VCI) via the MI-SAP specified in ISO 24102-3.
Any change of status of a CI/VCI shall be reported to all ITS-SCUs with ITS-SCU-Mngmt-Request “VCI-
update” specified in ISO 24102-4. Reception of such a notification shall not be acknowledged.
Management communications with CIs/VCIs in other ITS-SCUs shall be with ITS station-internal
management communication PDUs “MI-rcmd”, “MI-rreq”, “MI-rget”, and “MI-rset” specified in ISO 24102-4.
Although SAPs and the related service primitives specified in ISO 24102-3 cannot be tested and are not
mandatory, in the context of this part of ISO 24102, the elements of the service primitives may be an
integral part of PDUs exchanged between physical entities in an ITS station using “ITS station-internal
management communications” specified in ISO 24102-4. As PDUs are testable, those elements of service
primitives that are part of a PDU become testable.
6.2 CI status
6.2.1 CI state machine
Figure 2 shows the CI state machine specified in ISO 21218.
power on /
activate
deregister
not_existent
existent
inactive
deregister
activate
register
inactivate
deregister
registered
deregister
suspended
inactivate
inactivate
delete VCI
deregister
create VCI
resume
active
disconnect
suspend
connect
connected
Figure 2 — CI state machine ISO 21218
6.2.2 Registration
Registration of a CI at the ITS station management entity is the process to make the CI known to the ITS
station management entity, and to make it addressable via a unique Link-ID (see ISO 21218).
Registration of a CI shall be done as specified in ISO 21218.
The medium identifier MedID, part of the Link-ID specified in ISO 21218, and assigned to a CI during the
process of registration shall be unique within an ITS-SCU.
Upon successful registration of a CI, the ITS station management entity shall create an entry in the VCI
list with the values specified in Table 1.
Table 1 — Entry in VCI list upon registration of CI
LocalCIID Medium CI Status ConnectMode RemoteCIID
Identifying the I-Parameter I-Parameter CIstatus I-parameter “Con- Not applicable.
CI as specified in “MedType” as speci- equal to “registered”, nect”.
Value identifying
ISO 21218. fied in ISO 21218. see ISO 21218.
the CI as specified in
ISO 21218.
4 © ISO 2013 – All rights reserved

6.2.3 VCI creation
Creation of a VCI may be done
— upon request of the ITS station management entity, or
— by the CI on its own.
Creation of a VCI shall be done as specified in ISO 21218.
Upon successful creation of a VCI, the ITS station management entity
— shall create an entry in the VCI list with the values specified in Tables 2, 3, and 4, as applicable, and
— shall create initial entries in the forwarding tables of all supported networking protocols using MN-
COMMAND “FWTset” specified in ISO 24102-3, if applicable.
Table 2 — Entry in VCI list indicating an active CI
LocalCIID Medium CI Status ConnectMode RemoteCIID
Identifying the Set equal to I-param- Set equal to I-Param- Set equal to I-param- Not applicable.
CI as specified in eter “Medium”. See eter CIstatus. See eter “Connect”. See
Value identifying
ISO 21218. ISO 21218. ISO 21218. ISO 21218.
the CI as specified in
ISO 21218.
Table 3 — Entry in VCI List upon creation of a broadcast VCI
LocalCIID Medium CI Status ConnectMode RemoteCIID
As specified in Set equal to I-param- Set equal to I-Param- Set equal to I-param- As specified in
ISO 21218. eter “Medium”. See eter CIstatus. See eter “Connect”. See ISO 21218.
ISO 21218. ISO 21218. ISO 21218.
Table 4 — Entry in VCI List upon creation of a multicast VCI
LocalCIID Medium CI Status ConnectMode RemoteCIID
As specified in Set equal to I-Param- Set equal to I-Param- Set equal to I-param- As specified in
ISO 21218. eter “Medium”. See eter CIstatus. See eter “Connect”. See ISO 21218.
ISO 21218. ISO 21218. ISO 21218.
Upon request of an ITS-S networking and transport layer protocol to create a VCI with a specific
relation to a peer station, of which the MAC address is known a priori, and with specific settings of the
I-parameters, the ITS station management entity shall create the VCI and perform all required settings.
The state of the CI shall be set to “connected” (see Table 5). The ITS station management entity shall
update the VCI list and the forwarding tables.
6.2.4 Deregistration
Deregistration of a CI at the ITS station management entity is the process reversal to the registration
process. Successful deregistration is a prerequisite to remove a CI from the system during operation.
Deregistration of a CI may be done
— by the CI on its own,
— upon request of the ITS station management entity as specified in this part of ISO 24102.
Deregistration of a CI shall be done as specified in ISO 21218.
Upon successful deregistration, the ITS station management entity
— shall delete all entries of this CI and the related VCIs in the VCI list, and
— shall delete all entries of this CI and the related VCIs in the forwarding tables using MN-COMMAND
“FWTdelete” specified in ISO 24102-3, if applicable.
6.2.5 Inactivation
Inactivation of a CI is the process to reset the CI and to block all subsequent communications.
Inactivation of a CI may be done upon request of the ITS station management entity.
NOTE Conditions when a CI shall or may be inactivated are not specified in this part of ISO 24102.
Inactivation of a CI shall be done as specified in ISO 21218.
Upon successful inactivation, the ITS station management entity
— shall change the status element of this CI in the VCI list to “inactive”, and shall delete the entries of
all related VCIs in the VCI list, and
— shall change the CI state of this CI in the forwarding tables to “inactive”, and shall delete the
entries of all related VCIs in the forwarding tables using MN-COMMAND “FWTdelete” specified in
ISO 24102-3, if applicable.
6.2.6 Activation
Activation of a CI is the process to enable communications in an inactive CI. Upon successful activation,
the ITS station management entity shall change the status element of this CI to the value “registered”.
Activation of a CI may be done upon request of the ITS station management entity as specified in this
part of ISO 24102.
NOTE Requirements on events upon which a CI shall or may be activated are not specified in this part of ISO 24102.
Activation of a CI shall be done as specified in ISO 21218.
Upon successful activation, the ITS station management entity shall change the status element of this CI
in the VCI list to the value “registered”.
6.2.7 Suspension
Suspension of a CI is the process to put all communications of a CI on hold, without deleting any packets
or state variables.
Suspension of a CI may be done upon request of the ITS station management entity as specified in this
part of ISO 24102.
NOTE Requirements when a CI shall or may be suspended are not specified in this part of ISO 24102.
Suspension of a CI shall be done as specified in ISO 21218.
Upon successful suspension, the ITS station management entity shall change
— the status element of this CI and the related VCIs in the VCI list to “suspended”, and
— the CI state of this CI and the related VCIs in the forwarding tables to “suspended” using MN-
COMMAND “FWTupdate” specified in ISO 24102-3, if applicable.
6 © ISO 2013 – All rights reserved

6.2.8 Resuming
Resuming of a CI is the process to enable communications in a suspended CI.
Resuming of a CI may be done upon request of the ITS station management entity.
NOTE 1 Conditions when a CI shall or may be resumed are not specified in this part of ISO 24102.
Resuming of a CI shall be done as specified in ISO 21218.
Upon successful resuming, the ITS station management entity shall
— change the status element of this CI in the VCI list to “active” and the status of the related VCIs in the
VCI list to “connected”, and
— change the CI state of this CI and the related VCIs in the forwarding tables to “connected” using MN-
COMMAND “FWTupdate” specified in ISO 24102-3, if applicable.
NOTE 2 This VCI state might be wrong. However, this will be resolved automatically.
6.2.9 Connection
Connection establishment of a CI is the process to initiate and maintain a relation to a specific peer
station. Distinction is made according to the CI access class.
Connection of a VCI may be done
— by the CI on its own,
— upon request of the ITS station management entity as specified in this part of ISO 24102.
Connection of a VCI shall be done as specified in ISO 21218.
Upon successful connection to a peer station, the ITS station management entity shall
— create an entry in the VCI list with the values specified in Table 5, and
— change the CI state of this VCI in the forwarding tables to “connected”, using MN-COMMAND
“FWTupdate” specified in ISO 24102-3.
Table 5 — Entry in VCI list upon successful connection of a unicast VCI
LocalCIID Medium CI Status ConnectMode RemoteCIID
As specified in Set equal to I-param- Set equal to I-Param- Set equal to I-param- Value identifying the
ISO 21218. eter “Medium”. See eter CIstatus. See eter “Connect”. See peer station as speci-
ISO 21218. ISO 21218. ISO 21218. fied in ISO 21218.
NOTE Access technologies may either be uniquely identified in the OSI MAC layer by means of a 48-bit MAC
address, or by other means. As specified in ISO 21218, RemoteCIID contains this information.
6.2.10 Disconnection
Disconnection of a VCI is the process to close relations to a peer station. Distinction is made according to
the CI access class as specified in ISO 21218.
Disconnection of a VCI may be done
— by the CI on its own,
— upon request of the ITS station management entity as specified in this part of ISO 24102.
Disconnection of a VCI shall be done as specified in ISO 21218. Upon successful disconnection of a VCI by
the ITS station management entity or by the CI, the ITS station management entity shall
— update the entry of the VCI in the VCI list, and
— change the CI state of this VCI in the forwarding tables to “active”, using MN-COMMAND “FWTupdate”
specified in ISO 24102-3, if applicable.
6.2.11 Deletion of a VCI
Deletion of a VCI may be done
— by the CI on its own,
— upon request of the ITS station management entity as specified in this part of ISO 24102.
Deletion of a VCI shall be done as specified in ISO 21218.
Upon successful deletion of a VCI, the ITS station management entity shall delete
— the entry in the VCI list, and
— the entries of this VCI in the forwarding tables using MN-COMMAND “FWTdelete” specified in
ISO 24102-3, if applicable.
6.3 Cross-CI prioritization
6.3.1 General
Wireless TX-VCIs in an ITS station might suffer from cross-interference. This clause considers the case
that at least two local TX-VCIs, e.g. using the same medium, need to be synchronized in order to avoid
cross-interference. The procedure to synchronize transmission of multiple CIs based on user priority is
called “Cross-CI prioritization”.
The design and integration goal shall be to avoid such cross-interference as far as possible. A possible
means to achieve this is proper assignment of orthogonal wireless communication channels to the CIs.
Priority management across CIs is a somewhat slow process which requires involvement of the ITS
station management entity for every packet to be prioritized.
The procedure of cross-CI prioritization is an optional procedure. The part of it related to the CI is
specified in ISO 21218.
NOTE An implicit option of cross-CI prioritization is CI protection. A CI to be protected is a device for radio
communications such as passive transponder systems based on [2] and [3] which cannot harm other CIs.
In CI protection mode, the CI to be protected does not need to await the positive acknowledgement of a
prioritization request, but may try to perform communication at any time.
6.3.2 Registration of CI for prioritization request
Upon request of a CI to register for the cross-CI prioritization procedure by means of the MI-REQUEST
“PrioReg” specified in ISO 24102-3, the ITS station management entity shall
— create the header of the prioritization table for this CI (see Table 10) containing the Link-ID.LocalCIID
of the CI and the timeout information. The list entries “Request number”, “Priority”, and “Status”, if
already created, shall be set to zero,
— evaluate the list of MedType information contained in “PrioReg” in order to identify the LocalCIID of
all possible interferers in the ITS station, and
8 © ISO 2013 – All rights reserved

— create an entry in the prioritization table for each identified interferer with the interferer LocalCIID
and with “Status Interferer” set to “released”.
6.3.3 Prioritization request
As specified in ISO 21218, a CI may request cross-CI prioritization by means of the MI-REQUEST “RTSreq”
specified in ISO 24102-3.
Upon reception of such a request, the ITS station management entity shall compare the presented priority
with the minimum priority required for cross-CI prioritization given in parameter “MinPrioCrossCI”
specified in ISO 21218. If the presented priority is less than the minimum priority required, then
the ITS station management entity shall notify unsuccessful prioritization to the requesting CI by
means of MI-COMMAND “RTSackCmd”, specified in ISO 24102-3, with priority set equal to parameter
“MinPrioCrossCI” and with status set to “ignored”. Otherwise, continue with the following steps.
The ITS station management entity shall
— either create or update the cross-CI prioritization table entries “Status”, “Priority”, and “Request
number” as given in RTSreq,
— start a prioritization timer T_prioritization for this request,
— forward the prioritization request to all known potential interferers by means of the MI-COMMAND
“RTScmd” specified in ISO 24102-3, and shall update the status interferer entries in Table 10 to the
value “requested”, and
— await acknowledgement messages from all interferers until end of the prioritization period, i.e. either
— the timer T_prioritization expired according to the timeout value given in Table 10, or
— the CI requesting prioritization released prioritization by means of MI-REQUEST “RTSreq”
specified in ISO 24102-3 with “status” set to “release”.
Upon expiration of the timer T_prioritization, the ITS station management entity shall notify unsuccessful
prioritization to the requesting CI by means of MI-COMMAND “RTSackCmd” specified in ISO 24102-3 with
“priority” set equal to parameter “MinPrioCrossCI” specified in ISO 21218 and with “status” set to “ignored”.
Upon reception of an acknowledgement message from an interferer, the ITS station management entity shall
— set the status of the interferer in Table 10 to “prioritization granted”, and
— notify successful prioritization to the requesting CI by means of MI-COMMAND 4 “RTSackCmd”
with “priority” set equal to parameter “MinPrioCrossCI” and with status set to “granted” once all
interferers disabled their transmitter.
The ITS station management entity shall apply “ITS station-internal management communications”
specified in ISO 24102-4 in case other ITS-SCUs need to be addressed.
6.3.4 Prioritization release
Upon the end of the prioritization period, the ITS station management entity shall
— send the prioritization release MI-COMMAND “RTScmd” specified in ISO 24102-3 with
status = “release” to all known potential interferers, and shall update Table 10 for this request, and
— stop the timer T_prioritization, if applicable.
The ITS station management entity shall apply “ITS station-internal management communications”
specified in ISO 24102-4 in case other ITS-SCUs need to be addressed.
6.4 VCI I-Parameters
6.4.1 General
Upon registration of a CI, its RX-VCI and TX-VCI, if applicable, shall operate on the default settings of
I-Parameters.
NOTE The default settings of the access technologies are specified in the media standards.
6.4.2 Setting of parameter values
Setting of I-Parameter values shall be done as specified in ISO 21218.
I-Parameter settings of a VCI may be changed
— by the ITS station management entity according to rules specified in this part of ISO 24102, or
— by the VCI on its own according to rules specified in the related medium standard.
I-Parameter values shall be set in accordance with regulatory requirements, if applicable.
Transmit parameters of a VCI may be changed temporarily on a packet-by-packet basis, applying CIP-
management as specified in ISO 21218 and in [9]. This shall not affect VCI I-Parameter-settings.
6.4.3 Retrieval of parameter values
Retrieval of I-Parameter values — either of a single parameter, or of multiple parameters, or of the
complete set — of a VCI shall be done as specified in ISO 21218.
Retrieval of I-Parameter values may be done by the ITS station management entity according to rules
specified in this part of ISO 24102.
6.4.4 Monitoring of parameters
CIs/VCIs shall notify the ITS station management entity of changes of the following parameters:
— those that are required to be reported, i.e. mandatory change notification, according to Table 6;
— those requested by the ITS station management entity by means of the MI-COMMAND “Monitor”
specified in ISO 24102-3.
Table 6 shows those I-Parameters for which mandatory monitoring shall apply, and the related mandatory
behaviour of the ITS station management entity upon notification of a new value. The ITS station
management entity shall request automatic monitoring to be performed by all CIMAEs (see ISO 21218).
A specific access technology may not support all parameters listed in Table 6. Consequently, non-
supported parameters will never change value, thus a notification will never happen.
Further parameters may be subject to automatic notification of value-changes as defined by
implementation or according to other specifications.
6.4.5 Access to other ITS-SCUs
Direct access of the ITS station management entity in an ITS-SCU to parameters of other ITS-SCUs shall
be prohibited, except for the following cases:
— read only access;
— manufacturer access.
10 © ISO 2013 – All rights reserved

Access to I-Parameters of another ITS-SCU shall be achieved by means of the ITS station-internal
management communication PDUs “MI-rget” and “MI-rset” specified in ISO 24102-4.
Table 6 — List of CI parameters subject to mandatory notification
I-Parameter Name Behaviour
RI Upon notification of change of regulatory information, the ITS station
management shall accept the new limits for subsequent operations
until a new update of RI will be available.
MACaddrTemp Upon notification of change of own MAC address, the ITS station man-
agement entity shall send “ITS-SSI Data” in a broadcast frame.
CIstatus
The following parameters are contained in the VCI performance parameter list presented in Table 9.
ChannelType Upon notification of change of a performance parameter, the CI selec-
tion manager shall recalculate the mapping of ITS-S applications on CIs.
ChannelNo
DataRateNW
DataRatesNW
Directivity
MinimumUserPriority
CommRangeRef
Cost
Reliability
All parameters are subject to regulation, e.g. frequencies of operation, maximum transmit power.
6.5 Regulatory information management
All ITS stations shall comply with regional regulations. Management of regulatory information (RI) uses
mechanisms specified in ISO 21218. A request from the ITS station management entity to set one or
more parameters in a CI/VCI that would violate the associated regulatory information contained in the
CI/VCI shall result in a confirm from the CI/VCI containing the error code “RI VIOLATION” as specified
in ISO 21218. Upon such an error indication, the ITS station management entity may
— retrieve from the CI/VCI the RI parameter values,
— retrieve RI from a trusted source,
— request new settings of RI in the CI.
6.6 Manufacturer access
A manufacturer of a CI may access its CI via the MI-SAP as specified in ISO 21218.
Access security is outside the scope of the set of ISO International Standards on ITS, i.e. the manufacturer
shall implement its own security scheme.
7 Congestion control
In some radio communication systems, congestion control is managed only at the MAC sub-layer. For
many envisaged ITS applications, this approach is not sufficient. Thus, congestion control needs to be
extended to involve other layers of the OSI protocol stack including the ITS-S management, taking into
consideration all available information on potential traffic in all communication channels.
Congestion control is a set of functions implemented in one or more ITS stations that is used to address
congestion in the various ITS communication links. Congestion control is decentralized in the sense
that ITS stations exchange as little information as possible in the ITS communication links and control
decisions are preferably taken locally inside each ITS station.
Figure 3 shows the basic architecture of congestion control.
ITS-S facilities layer
NF-SAP
ITS-S networking & transport layer
FAST IPv6
Networking Networking
Other
M5 IR LTE
Congestion
Congestion Congestion Congestion
Node
Node Node Node
IN-SAP
M5 IR LTE Other media
ITS-S access layer
Figure 3 — Congestion control architecture
There are internal congestion nodes in the transmit path of each CI, e.g. M5 and IR ad hoc access
technologies, and LTE cellular network technology, and others presented in Figure 3. External congestion
nodes are the physically available channels.
NOTE Congestion in the receive path of a CI is not considered in this part of ISO 24102.
A wireless medium shared by all neighbouring ITS stations constitutes the essential congestion node.
Thus, congestion control shall take care of the actual communication channel load observed at the
external congestion node and at the internal congestion node.
Whereas the external congestion load cannot be influenced directly, the internal congestion load can be
adjusted. This adjustment also has impact on the external congestion load.
Congestion control management may be based on
a) QoS management based on user priority as specified in ISO 21218,
b) I-Parameters accessible via MI-SAP as specified in ISO 24102-3,
c) CIP management via IN-SAP on a packet per packet basis as specified in [9],
12 © ISO 2013 – All rights reserved
ITS-S management
Congestion Control Manager
MI-SAP MN-SAP MF-SAP
TX data  low
d) networking information accessible via MN-SAP, e.g. contained in the neighbour list,
e) application information accessible via MF-SAP, e.g. provided at time of registration at the ITS station
management entity for the purpose of CI selection, as specified in [5].
The part of the congestion control algorithm running autonomously in a station is a pure performance
matter and may be subject to continuous improvements.
ETSI TC ITS is working on standards for congestion control algorithms with a focus on the M5 ad hoc
access technology. A congestion control algorithm allocated in the access layer is specified in [8].
8 Neighbour list
The ITS station management entity may maintain a neighbour list, i.e. a list of all known neighbouring
stations. This list shall contain
— “ITS-SSI Data” information specified in this part of ISO 24102, received via MN-SAP with MN-
REQUEST Its-ssiPeerNot specified in ISO 24102-3, and
— forwarding table information of networking protocols received via MN-SAP with MN-REQUESTS
“FWTsetNot”, “FWTupdateNot”, and FWTdeleteNot specified in ISO 24102-3.
The neighbour list information shall be made available to the LDM application via the MF-SAP using MF-
COMMAND “LDMnotify” specified in ISO 24102-3, if applicable.
NOTE 1 The LDM application is considered to be a facilities layer service made available to the ITS station and
the ITS-S applications. ETSI TC ITS, ISO TC204 WG18, and CEN TC278 WG16 are developing standards on LDM.
[1]
NOTE 2 An early LDM implementation was already developed and validated in the CVIS project of the
European Union.
The neighbour list process shall not send updates to the LDM application prior to registration of the LDM
application at the neighbour list. Registration of the LDM application is made by means of the MF-SAP
request MF-REQUEST “LDMregister” specified in ISO 24102-3. This request shall be acknowledged.
NOTE 3 ITS-SSI data are exchanged between ITS stations using e.g. the “Cooperative Awareness Message”
(CAM) specified in [7].
9 Paths and flows
The general concept of paths and flows in ITS communications is based on similar concepts in
IPv6 networking. This concept of paths and flows is essential in describing the abstraction of ITS-S
applications from the communications services available in an ITS station (see ISO 21217). This clause
provides definitions for path and flow in the context of the ITS station reference architecture specified
in ISO 21217. Identification of paths and flows is unique within an ITS station.
A communication path is defined as a sequence of nodes connected by links, starting at a source node
and ending at one or more destination nodes. All communication paths have at least one fixed node
between the source and the destination node that is referred to as an anchor node. The anchor node
divides the communication path into two parts, one part from the source node to the anchor node and
the second from the anchor node to the destination node. The anchor node and the destination node may
be one and the same node. The part of the communication path between the source node and the anchor
node is referred to as an “ITS-S Path”. An “ITS-S Path” is uniquely identified by a LinkID (identifying a
CI in the source node and the next hop node) and by the anchor node. The next hop node and the anchor
node may be one and the same node.
A flow type is a set of communication requirements/characteristics associated with a specific flow.
NOTE Categories of communication requirements/characteristics include QoS, security, priority, and
communication type (unicast, broadcast, multicast, bicast, anycast, geocast).
A flow is an identifiable sequence of packets of a given flow type to be transmitted to one or more
entities. Each flow is identified by a FlowID which is unique in an ITS station and is mapped to a given
path or a set of available paths.
Procedures for ascertaining available ITS-S paths and for mapping flows to those paths are divided into
distinct functions within the ITS-S management.
— Path management is a process for obtaining information about the anchor nodes, next hop nodes,
and available CIs. This process results in a local list of currently available paths and potentially
available paths to be used in the future. The ITS-S management entity exchanges path management
information with various communication protocol layers using well-defined service primitives, e.g.
MN-Request.STAGeoNot, MN-Request.STATopoNot, MN-Request.STAServNot, MN-Request.PathNot,
MN-Request.PathMetricNot, MN-Commmand.PathMNGT, and MN-Commmand.STAServDiscov.
— Flow management is a process of keeping track of the requirements of all flows and collecting flow
statistics. The ITS-S management entity exchanges flow management information with various
communication protocol layers using well-defined service primitives, e.g. MF-Request.ITS-S-Appl-
RegMN-Request.FlowStat, MN-Command.FlowFeedback.
— Path selection is a process of determining the most appropriate path(s) from
...