ISO 21218:2013

INTERNATIONAL ISO
STANDARD 21218
Second edition
2013-03-15
Intelligent transport systems —
Communications access for land mobiles
(CALM) — Access technology support
Systèmes intelligents de transport — Accès aux communications des
services mobiles terrestres (CALM) — Support à la technologie d'accès

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 . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 Communication module adaptation . 4
5.1 General . 4
5.2 Communication adaptation layer . 4
5.3 CI management adaptation entity . 5
5.4 CI security adaptation entity . 5
6 Communication interface . 5
6.1 Architecture . 5
6.2 Classification of CIs . 5
6.3 Link Identifier . 7
6.4 Procedures . 8
6.4.1 General . 8
6.4.2 Registration . 8
6.4.3 Deregistration . 9
6.4.4 Inactivation . 10
6.4.5 Activation . 10
6.4.6 Suspension . 10
6.4.7 Resuming . 11
6.4.8 Connection . 11
6.4.9 Disconnection . 11
6.4.10 CI state machine . 11
6.4.11 Cross-CI prioritization . 13
6.4.12 Protection of CI . 15
6.4.13 Regulatory information management . 16
7 Virtual communication interface . 16
7.1 Concept . 16
7.2 VCI identifier . 20
7.3 Procedures . 20
7.3.1 Creation of VCI . 20
7.3.2 Reset of VCI . 20
7.3.3 Deletion of VCI . 20
7.3.4 Association of peer with Link-ID . 21
7.3.5 Change of I-Parameter settings . 21
8 Communication SAP . 22
8.1 LLC Types of Operation . 22
8.2 Addressing . 23
8.2.1 SAP addresses . 23
8.2.2 IN-SAP source and destination addresses . 24
8.2.3 SNAP . 25
8.3 Service primitives (informative) . 26
8.3.1 IN-UNITDATA.request . 26
8.3.2 IN-UNITDATA.indication . 26
8.3.3 IN-UNITDATA-STATUS.indication . 27
8.4 Priority .28
8.5 Access parameters .29
8.6 Transmission status .29
9 Management SAP.29
10 Conformance .30
11 Test methods .30
Annex A (normative) I-Parameters .31
Annex B (normative) ASN.1 definitions .37
B.1 Use of modules .37
B.2 ASN.1 modules .37
Annex C (normative) Extended universal 64 bit identifier .47
C.1 EUI-64 format .47
C.2 Encapsulation of 48-bit MAC addresses .48
C.3 Encapsulation of identifiers specific to ITS .48
Bibliography .50

iv © ISO 2013 – 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. 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.
This second edition cancels and replaces the first edition (ISO 21218:2008) which has been technically
revised.
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 International Standard determines general technical details related to the access layer of an ITS station
specified in ISO 21217 and illustrated in Figure 1 which are applicable to all or several access layer
technologies. This includes especially the IN-SAP offered to the ITS-S networking & transport layer for
communication purposes.
The MI-SAP presented in Figure 1 is specified by means of a reference to ISO 24102-3. The specification of
the SI-SAP is not within the scope of this International Standard.
Applications
API
MS
Facilities
NF
Networking &
Transport
IN
Access
Communications
Figure 1 — ITS station reference architecture with named interfaces
vi © ISO 2013 – All rights reserved

Management
MI MN MF
SI SN SF
Security
INTERNATIONAL STANDARD ISO 21218:2013(E)

Intelligent transport systems — Communications access for
land mobiles (CALM) — Access technology support
1 Scope
This International Standard determines general technical details related to the access layer of the ITS station
reference architecture specified in ISO 21217 which are applicable to all or several access layer technologies.
This includes especially the service access point (SAP) of a communication interface (CI) as provided by the
communication adaptation layer (CAL) for communication. The SAP provided by the CI management
adaptation entity (MAE) for management of the communication interface is specified by reference
to ISO 24102-3.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 8802-2, Information technology — Telecommunications and information exchange between
systems — Local and metropolitan area networks — Specific requirements — Part 2: Logical link control
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 24102-1, Intelligent transport systems — Communications access for land mobiles (CALM) — ITS station
management — Part 1: Local management
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 760-1, Intelligent transport systems; Road Transport and Traffic Telematics (RTTT); Test
specifications for ITS; Communications Access for Land Mobiles (CALM), Medium Service Access Points
(ISO 21218); Part 1: Protocol Implementation Conformance Statement (PICS) proforma
ETSI TS 102 760-2, Intelligent transport systems; Road Transport and Traffic Telematics (RTTT); Test
specifications for ITS; Communications Access for Land Mobiles (CALM), Medium Service Access Points
(ISO 21218); Part 2: Test Suite Structure and Test Purposes (TSS & TP)
3 Terms and definitions
For the purposes of this document, the terms and definitions given
in ISO/IEC 8802-2, ISO 21217, ISO 24102-1, ISO 24102-3, ISO 24102-4 and the following apply.
3.1
(V)CI identifier
unique identifier of a (virtual) CI
3.2
communication interface
CI
instantiation of a specific ITS-S access layer technology and protocol
EXAMPLE An example of communication protocol is IR [5].
3.3
medium
physical properties of a CI used to transmit a modulated signal, e.g. wireless or on a wire, also referred to as
access technology
3.4
virtual communication interface
logical entity in a CI that is associated with a peer station
3.5
CI priority manager
logical entity in a CI that is managing priority queues
3.6
Link-ID
identifier of a link given by the address of a VCI
4 Abbreviated terms
NOTE See also: ISO/IEC 8802-2, ISO 21217, ISO 24102-1, ISO 24102-3, ISO 24102-4.
APN Access point name
BC-VCI VCI for transmission to the broadcast MAC address
CAL Communication adaptation layer
CEN "European Committee for Standardization"
CI communication interface
CIC communication interface class
CIID CI / VCI Identifier presented in a 64-bit EUI field
DLL Data link layer
DNI Distinct null identifier
DSRC Dedicated short range communication
ETSI "European Telecommunications Standards Institute"
EUI Extended universal identifier
EUI-64 64-bit EUI
IN-SAP Communication SAP as offered by the CAL to the ITS-S networking & transport
layer
LocalCIID CIID of a local CI
LSB Least significant bit
MAC-48 48 bit MAC address
2 © ISO 2013 – All rights reserved

MAE Management adaptation entity
MC-VCI VCI for transmission to a multicast (group) MAC address
MI-SAP Management SAP as offered by the ITS-S management towards the MAE
MSB Most significant bit
OBU On-board unit
NOTE Term used for DSRC [14]
OSI Open system interconnection
OUI Organizational universal identifier
PIN Personal identification number
RemoteCIID CIID of a VCI enabling MAC groupcast transmissions and MAC unicast
communication
RX/TX-CI CI capable of operating in receive and transmit mode
RX-CI CI capable of operating in receive mode only
RX-VCI VCI for reception
SAE Security adaptation entity
SIM Subscriber identity module
SNAP Sub-network access protocol
TDMA Time division multiple access
TX-CI CI capable of operating in transmit mode only, either broadcast or multicast
TX-VCI VCI for unicast transmission
UC-VCI VCI for reception from and transmission to a unicast MAC address
VCI virtual communication interface
WAVE Wireless access in vehicular environments
NOTE IEEE work item related to [6]

5 Communication module adaptation
5.1 General
As ITS and the concept of an ITS station as a bounded secured managed domain (BSMD) specified
in ISO 21217 does not only support access technologies (media) which are especially designed for
implementations of ITS, there is a need to adapt the interfaces of these other access technologies to those
interfaces expected by the ITS networking & transport layer, the ITS-S management entity, and the ITS-S
security entity.
For these other access technologies, the task is to adapt
 the interface on top of the access technology to the IN-SAP by means of a communication adaptation
layer (CAL), and
 the management interface to the MI-SAP by means of a management adaptation entity (MAE), and
 the security interface to the SI-SAP by means of a security adaptation entity (SAE).
The implementation of an existing access technology, which was not designed especially for ITS, may include
higher layers of the OSI communication protocol stack than just the ITS access layer including the related
management. This inclusion of higher protocol layers shall be restricted to those communication technologies
already existing and not being aware of ITS and the concept of a BSMD, e.g. the cellular media [3, 4].
The CI adaptation is outlined in Figure 2.
ITS-S networking & transport layer
IN
Communication
adaptation
sub-layer (CAL)
Data link layer (DLL)
Physical layer (PHY)
Communication interface (CI) in
the ITS-S access layer
Figure 2 — Architecture
This International Standard provides common basic functional specifications for the communication adaptation
Layer, for the management adaptation entity (MAE), and for the security adaptation entity (SAE). It specifies
the communication SAP (IN-SAP), the station management SAP (MI-SAP), and the security management
SAP (SI-SAP).
5.2 Communication adaptation layer
The CIs built on different media are using the same ITS-S networking & transport layer. All CIs shall use the
same type of IN-SAP between the ITS-S networking & transport layer and the CAL.
4 © ISO 2013 – All rights reserved

ITS-S
ITS-S security
management
entity
entity
MI SI
Management
Security
adaptation adaptation
entity (MAE) entity (SAE)
Layer management
The medium-specific CAL provides an IN-SAP to the ITS-S networking & transport layer following the same
principles as outlined in ISO/IEC 8802-2. The supported types of LLC operation and LLC services may
depend on the ITS-S networking & transport layer protocol selected.
 For ad-hoc communications, Type I. operation is mandatory, with the LLC service XID being prohibited.
 The other types of LLC operation, i.e. Type II. and Type III., are optional.
The CAL can be considered as an access technology (medium)-specific LLC or as an extension of an existing
LLC providing the adaptation of the specific needs of an access technology (medium) to the common
communication IN-SAP.
5.3 CI management adaptation entity
The CIs built on different media are using the same ITS-S management, applying the functionality specified
for the MI-SAP.
The MAE provides the MI-SAP to the ITS-S management following the same principles as outlined in
ISO/IEC 8802-11 with respect to the station management entity. The MI-SAP offers the services presented in
Clause 9.
The MAE can be considered as medium-specific management providing the adaptation of the specific needs
of an access technology (medium) to the common MI-SAP.
5.4 CI security adaptation entity
The current version of this International Standard does not provide the specification of the SAE.
6 Communication interface
6.1 Architecture
This International Standard uses the concept of
 Communication interface (CI) with
 virtual communication interfaces (VCIs).
A CI is a real communication equipment containing functionality of the ITS-S access layer. On top of a CI, one
or several VCIs for transmission (TX-VCIs) to specific peer ITS-Ss, groups of ITS-Ss, or all ITS-Ss, and one or
several receive VCIs (RX-VCIs), may be created.
NOTE The number of RX-VCIs is equal to the number of receive channels which can be operated simultaneously by
the CI.
Further details on VCIs are specified in Clause 7.
6.2 Classification of CIs
6.2.1.1 CI Classes
Table 1 identifies and distinguishes the classes of CIs.
Table 1 — CI classes
Communication interface class Definition and explanations
CIC-wl1 Wireless CI that is capable of establishing simultaneous associations with
different peer stations for MAC unicast communication, and of receiving
from and transmitting to MAC broadcast and multicast (group) addresses.
Examples: Access technologies specified in [5, 6, 7, …]
CIC-wl2 Wireless CI that is capable of establishing a session with a single base
station. Handover between different base stations may be possible, but
not visible to the ITS upper layers and the ITS-S management.
Examples: Access technologies specified in [3, 4, …]
CIC-wl3 Wireless CI that is capable to transmitting only on the basis of MAC
broadcast/multicast (group) addresses.
Examples: Access technologies specified in [5, 6, 7, …]
CIC-wl4 Wireless CI that is capable only of receiving frames from a broadcast
station.
Examples: Satellite navigation receiver, satellite broadcast receiver, …
CIC-wl5 Wireless CI that is capable only of performing communications between a
car and a roadside station based on the master-slave principle with the
roadside station being the master. Communication session establishment
is done inside the CI.
Examples: Japanese DSRC, CEN DSRC, …
CIC-lan1 CI for station-internal network of an ITS station. Non-deterministic.
CIC-lan2 CI for station-internal network of an ITS station. Deterministic.

6.2.1.2 CI Access Classes
Access to a remote station may require authentication, for example:
 PIN for a SIM card;
 operator data:
 provider name;
 APN;
 user name;
 password.
This is identified by means of CI access classes. A CI shall support exactly one of the CI access classes
presented in Table 2 in line with requirements presented in Table 3.
6 © ISO 2013 – All rights reserved

Table 2 — CI access classes
CI access class Definition and explanations
CIAC-1 No user authentication required. Usage of CI is free of any charge.
CIAC-2 CI requires access credentials, e.g. PIN and operator data. Usage of CI is
subject of a service charge, e.g. price per time unit/per data amount
unit/flat-rate.
CIAC-3 CI requires access credentials, e.g. PIN and operator data. However,
usage of CI is free of any charge.

6.2.1.3 Mapping
The possible relations between CI classes and CI access classes shall be as presented in Table 3.
Table 3 — CI classes and access classes
CI classes CI access classes
CIAC-1 CIAC-2 CIAC-3
CIC-wl1 mandatory prohibited prohibited
CIC-wl2 Exactly one out of the three CI access classes is mandatory
CIC-wl3 Exactly one out of the three CI access classes is mandatory
CIC-wl4 prohibited prohibited prohibited
CIC-wl5 mandatory prohibited prohibited
CIC-lan1 mandatory not applicable not applicable
CIC-lan2 mandatory not applicable not applicable

6.3 Link Identifier
CIs and VCIs shall be referenced/addressed by a unique Link-ID. The Link-ID shall be constructed according
to Figure 3.
Link-ID
RemoteCIID (remoteCIID) LocalCIID (localCIID)
EUI-64 field EUI-64 field
MSB . LSB MSB . LSB
Byte 15 . Byte 8 Byte 7 . Byte 0

Figure 3 — Link-ID
The LocalCIID field identifies uniquely a specific CI in a specific ITS-S communication unit (ITS-SCU) in an
instance of an ITS station.
NOTE A two octet ITS-SCU-ID specified in ISO 24102-4, identifying uniquely an ITS-SCU of an ITS-S, can be
derived from LocalCIID be means of a look-up table.
The RemoteCIID field identifies a VCI of the CI identified by LocalCIID which connects to a remote ITS-S unit
(e.g. MAC unicast communication), or to a group of them (e.g. MAC broadcast or multicast communication).
One reserved number of RemoteCIID shall identify the CI which is addressed by the value of LocalCIID. This
reserved number shall be
 the distinct null identifier (DNI) presented in Annex C.2 for CIs supporting 48-bit MAC addresses,
 the VCISerialNumber zero presented in Annex C.3 for CIs which do not support 48-bit MAC addresses.
LocalCIID and RemoteCIID are presented in 64-bit global identifier (EUI-64) fields, see annex C.1, which may
contain a 48-bit MAC address as illustrated in Annex C.2.
For access technologies using 48-bit MAC addresses, LocalCIID may contain the globally unique MAC
address of the CI, and RemoteCIID may contain either the individual MAC address reported in a received
frame, or broadcast MAC address or a multicast MAC address.
Other access technologies shall use the numbering scheme specified in Annex C.3.
NOTE LocalCIID andRemoteCIID may appear in an access layer frame in the communication link between peer ITS
station units as part of an NPDU dependent on the networking & transport layer protocol being used. Thus LocalCIID and
RemoteCIID may become subject for considerations on privacy.
6.4 Procedures
6.4.1 General
The procedures as specified here use management services of the MI-SAP, as specified in 8.5.
6.4.2 Registration
Registration of a CI at the ITS-S management is the process of making the CI known at the ITS-S
management, and of making it addressable via a unique Link-ID. See the state machine in Figure 4.
The status of the CI before successful registration shall be CIstatus equal to "not existent".
Upon power-up, or upon physical insertion/activation of a CI, a CI supporting 48-bit MAC addresses shall
request registration of itself at the ITS-S management. The following procedure shall apply.
1) Create a Link-ID illustrated in Figure 3 with LocalCIID representing the globally valid unique MAC
address of the CI as stored in I-Parameter 9 "MAC address", with RemoteCIID equal to the "Distinct
Null Indicator" (DNI) value presented in Annex C.
2) Send MI-REQUEST "RegReq" indicating I-Parameter 17 "MedType" using the Link-ID constructed in
step 1).
3) Set timer T_register to the value given in I-Parameter 8 "TimeoutRegister".
4) Await MI-COMMAND "RegCmd" providing the "ITS-SCU-ID" and "MedID" as long as T_register has
not expired.
5) If the command in the previous step was successfully received, stop T_register and continue with the
next step. If T_register had expired, start again with step 2).
6) Upon successful registration, set I-Parameter 5 "ITS-SCU-ID" as received in MI-COMMAND
"RegCmd". Set I-Parameter 13 "CIstatus" to the value "registered", and notify this value to the ITS-S
management. This setting shall trigger creation of VCIs as specified in Clause 7.
8 © ISO 2013 – All rights reserved

Upon power-up, or upon physical insertion/activation of a CI, a CI not supporting 48-bit MAC addresses shall
request registration of itself at the ITS-S management. The following procedure shall apply.
1) Create a preliminary Link-ID illustrated in Figure 3 with LocalCIID and RemoteCIID constructed as
illustrated in Figure with
i) LocalCIID:
I) Set VCISerialNumber to the value zero, indicating the local CI.
II) Set ITS-SCU-ID to the value zero, see ISO 24102-4.
III) Set MedID to a value.
IV) Set all bits in the UC/GC field to zero.
NOTE The selected value for MedID might already be in use by another CI. Thus this value needs to be confirmed by
the ITS-S management entity in order to become valid.
ii) RemoteCIID:
I) Set VCISerialNumber to the value zero, indicating the address of the CI.
II) Set ITS-SCU-ID to the value zero.
III) Set MedID to the same value as used in LocalCIID.
IV) Set all bits in the UC/GC field to zero.
2) Send REQUEST "RegReq" indicating I-Parameter 17 "MedType".
3) Set timer T_register to the value given in I-Parameter 8 "TimeoutRegister".
4) Await COMMAND "RegCmd" providing true values of "ITS-SCU-ID" and "MedID" as long as
T_register has not expired.
5) If the command in the previous step was successfully received, stop T_register and continue with the
next step. If T_register had expired, start again with step 1), using a different value for MedID.
6) Create the valid Link-ID of the CI using the values of ITS-SCU-ID, MedID as given by the ITS-S
management in step 4).
7) Upon successful registration, set I-Parameter 5 "ITS-SCU-ID" and I-Parameter 6 "MedID" as
received in COMMAND "RegCmd". Set I-Parameter 13 "CIstatus" to the value "registered", and notify
this value to the ITS management. This setting shall trigger creation of VCIs as specified in 7.
6.4.3 Deregistration
Deregistration of a CI at the ITS-S management is the reversal of the registration process of the CI. See the
state machine in Figure 4.
Deregistration may be performed by the MAE or may be requested by the ITS-S management by sending the
MI-COMMAND "CIstateChng" with the value "deregister".
Deregistration shall result in
 setting the ITS-SCU-ID to the value zero,
 deletion of all VCIs and
 setting of I-Parameter 13 "CIstatus" to the value "not existent".
Successful deregistration shall be notified to the ITS-S management using the Link-ID as used for registration.
Upon successful deregistration, the CI may be physically removed from the system.
6.4.4 Inactivation
Inactivation of a CI is the process to reset the CI and to block all subsequent communications. See the state
machine in Figure 4.
Inactivation may be performed by the MAE or may be requested by the ITS-S management by sending the
MI-COMMAND "CIstateChng" with the value "inactivate".
Inactivation shall result in resetting the CI. As a consequence, all VCIs shall be deleted and no more pending
data packets shall be existent in the CI.
NOTE In a CI of class "CIC-wl2" and access class "CIAC-2" such as specified in [3 or 4], inactivation will result in
disconnecting from the wireless service, i.e. ringing off.
The MAE shall set I-Parameter 13 "CIstatus" to the value "inactive" and shall notify the ITS-S management.
6.4.5 Activation
Activation of a CI is the process to enable communications in an inactive CI. See the state machine in
Figure 4.
Activation may be performed by the MAE or may be requested by the ITS-S management by sending the MI-
COMMAND "CIstateChng" with the value "activate".
This command shall trigger creation of VCIs as specified below in this document.
Successful activation shall be notified to the ITS-S management.
NOTE In a CI of class "CIC-wl2" and access class "CIAC-2" such as specified in [3 or 4], the state "active" indicates
that the CI is within the communication zone of a base station and thus might connect to the service.
6.4.6 Suspension
Suspension of a CI is the process to put all communications of a CI on hold, without deleting any packets or
state variables. See the state machine in Figure 4. A CI being in the state "suspended" shall still properly
support the functionality of the primitives of the IN-SAP service IN-UNITDATA.
Suspension may be performed by the MAE or may be requested by the ITS-S management by sending the
MI-COMMAND "CIstateChng" with the value "suspend".
All VCIs shall be maintained. No pending data packets shall be lost. An on-going frame transmission shall be
stopped as quickly as possible. An on-going frame reception shall be finalized.
The MAE shall set I-Parameter 13 "CIstatus" to the value "suspended" and shall notify it to the ITS-S
management.
10 © ISO 2013 – All rights reserved

6.4.7 Resuming
Resuming of a CI is the process to resume communications in a suspended CI. See the state machine in
Figure 4.
Resuming may be performed by the MAE or may be requested by the ITS-S management by sending the MI-
COMMAND "CIstateChng" with the value "resume".
The MAE shall set I-Parameter 13 "CIstatus" to the value "connected" and shall notify it to the ITS-S
management. Pending packets shall be processed after resuming, if possible, otherwise pending packets may
be deleted without notification to the ITS-S management.
6.4.8 Connection
Connection of a CI is a process that depends on the CI access class. See the state machine in Figure 4.
For CI access class "CIAC-1" connection is established upon first usage of a TX-VCI or upon reception of a
frame from a peer station.
For CI access classes "CIAC-2" and "CIAC-3" connection is achieved upon confirmed establishment of a
connection to the communication network. Connection may be requested by the ITS-S management by
sending the MI-COMMAND "CIstateChng" with the value "connect".
The MAE shall set the I-Parameter 42 "CIstatus" to the value "connected" and shall notify it to the ITS-S
management.
6.4.9 Disconnection
Disconnection of a CI is a process that depends on the CI access class. See the state machine in Figure 4.
For CI access class "CIAC-1", disconnection shall be performed upon the situation that no more TX-VCI with a
relation to a peer station are known.
For CI access classes "CIAC-2" and "CIAC-3" this is the termination of the connection to the communication
network. Disconnection may be requested by the ITS-S management by sending MI-COMMAND
"CIstateChng" with the value "disconnect". There may be an implicit disconnection caused by deletion of a
VCI.
The MAE shall set I-Parameter 42 "CIstatus" to the value "active" and shall notify the ITS-S management.
6.4.10 CI state machine
Figure 4 shows the state machine of a CI. It covers
a) the start and end state
1) not_existent,
b) the interim states
1) existent, and
2) registered,
c) the operational states
1) active, and
2) connected,
d) the non-operational states
1) suspended, and
2) inactive,
see I-Parameter 13 "CIstatus". The transitions between the states are
 power on/activate, see 6.4.2,
 register, see 6.4.2,
 deregister, see 6.4.3,
 create VCI, see 7.3.1,
 inactivate, see 6.4.4,
 activate, see 6.4.5,
 suspend, see 6.4.6,
 resume, see 6.4.7,
 connect, see 6.4.8,
 disconnect, see 6.4.9, and
 delete VCI, see 7.3.3.
Requests to perform invalid transitions shall be acknowledged with error code ErrStatus="INVALID
COMMAND/REQUEST VALUE" specified in ISO 24102-3.
12 © ISO 2013 – All rights reserved

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 4 — CI state machine
6.4.11 Cross-CI prioritization
6.4.11.1 General
Wireless TX-VCIs in an instance of an ITS station might suffer from cross-interference. 6.4.11 considers the
case in which 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 to the greatest possible extent. A
possible means of achieving this is proper assignment of allowed wireless communication channels to the CIs.
Priority management across CIs requires involvement of the ITS-S management for every packet to be
prioritized.
This procedure "Cross-CI prioritization" is an optional procedure.
6.4.11.2 Registration of CI for prioritization REQUEST
A CI may register itself at the ITS-S management for the cross-CI prioritization procedure. This registration
shall include
 the types of potentially interfering media, see I-Parameter 17 "MedType", and
 the prioritization timeout in milliseconds.
Registration for cross-CI prioritization shall use MI-REQUEST "PrioReg".
It is assumed that potentially interfering media are known a priori by the CI. Settings shall be made by the
manufacturer of the victim device. Settings may be overruled by the ITS-S management.
6.4.11.3 Prioritization request
If registration for the cross-CI prioritization procedure is performed, a packet to be transmitted with a given
high priority is notified via the ITS-S management to other CIs not being in charge of transmitting this packet
by means of a dummy transmission request, i.e. by sending MI-REQUEST "RTSreq". The minimum required
priority is specified in the I-Parameter “MinPrioCrossCI”.
 RTSreq.priority shall be set equal to the user priority of the pending packet,
 RTSreq.seqNo shall be set to a value unique for this CI,
 RTSreq.status shall be set to "request".
NOTE The ITS-S management accepts a prioritization request only if RTSreq.priority is at least equal to
MinPrioCrossCI.
Upon transmission of the request, the CI may start a timer T_DummyAckReq for this request.
In the case of protection only (see 6.4.12) the CI may try immediately to perform the intended transaction
without awaiting receipt of an acknowledgement, if it will not cause interference to other CIs in this ITS station.
Otherwise, upon reception of the acknowledge MI-COMMAND "RTSackCmd" from the ITS-S management
with
 RTSackCmd.seqNo equal to the related request, and
 RTSackCmd.status equal to "granted",
the CI shall send the pending packet. The CI shall cancel the timer T_DummyAckReq.
If the acknowledge command shows RTSackCmd.status equal to "ignored", the CI may either send the
pending packet or delete it. The CI shall cancel the timer T_DummyAckReq. The MAE shall set I-
Parameter 34 "MinPrioCrossCI" equal to the value provided in RTSackCmd.priority.
Upon expiration of the timer T_DummyAckReq, if applicable, the CI may either send the pending packet or
may delete it.
6.4.11.4 Prioritization release
Upon transmission or deletion of the pending packet, the CI shall release the prioritization request by means
of MI-REQUEST "RTSreq" to the ITS-S management:
 RTSreq.priority shall be set equal to the request value;
 RTSreq.seqNo shall be set equal to the request value;
 RTSreq.reqStatus shall be set to "release".
The CI priority manager shall continue to serve the priority queues.
14 © ISO 2013 – All rights reserved

6.4.11.5 Interferer procedures
The information contained in MI-REQUEST "RTSreq" shall be used in the priority queue of the potential
interferer CI. All potential interferers shall be notified by the ITS-S management by means of the MI-
COMMAND "RTScmd":
 RTScmd.reqID shall be set equal to LocalCIID of the related request;
 RTScmd.priority shall be set equal to the user priority of the related request;
 RTScmd.seqNo shall be set equal to the value of the related request;
 RTScmd.status shall be set to "request".
Once such a dummy entry in the priority queue is subject to transmission,
 the dummy request shall be acknowledged by means of MI-REQUEST "RTSackReq", thus
 RTSackReq.reqID shall be set equal to LocalCIID of the related request,
 RTSackReq.seqNo shall be set equal to the value of the related request, and
 RTSackReq.status shall be set to "granted", then
 the transmitter shall be disabled and a timer T_dummyAckGrant for this request shall be started,
 the CI priority manager shall await either time out of T_dummyAckGrant or shall await release of this
dummy transmission request by means of the MI-COMMAND "RTScmd", with the parameters set as
follows:
 RTScmd.reqID shall be set equal to LocalCIID of the related request;
 RTScmd.priority shall be set equal to the user priority of the related request;
 RTScmd.seqNo shall be set equal to the value of the related request;
 RTScmd.status shall be set to "release";
 the CI priority manager shall then delete the dummy transmission request from the queue and shall
continue serving the priority queues.
6.4.12 Protection of CI
Wireless transmitters and receivers integrated in an instance of an ITS station may suffer from cross-
interference. Depending on user priorities, the interfering local CI transmitters are disabled for a defined
period. This is called "Protection of CI".
NOTE An example of a CI in need of protection is a CEN DSRC OBU as widely used in payment and access control
systems.
The design and integration goal is to avoid such cross-interference to the greatest possible extent.
"Protection of CI" shall make use of the "Cross-CI Prioritization" procedure.
Independent of the protection status, the CI may try to perform an intended communication at any time, unless
it is requested to disable its transmitter due to a transmission r
...