ISO 21218:2018

INTERNATIONAL ISO
STANDARD 21218
Third edition
2018-06
Intelligent transport systems —
Hybrid communications — Access
technology support
Systèmes intelligents de transport — Communications hybrides —
Support à la technologie d'accès
Reference number
©
ISO 2018
© ISO 2018
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: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – 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 . 3
5.1 General . 3
5.2 Communication adaptation layer . 4
5.3 CI management adaptation entity . 4
5.4 CI security adaptation entity . 5
6 Communication interface . 5
6.1 Architecture . 5
6.2 Classification of CIs . 5
6.2.1 CI Classes . 5
6.2.2 CI access classes . 6
6.3 Link identifier . 6
6.4 CI procedures . 7
6.4.1 General. 7
6.4.2 Registration . 7
6.4.3 Deregistration . 9
6.4.4 Inactivation . 9
6.4.5 Activation . 9
6.4.6 Suspension . 9
6.4.7 Resuming .10
6.4.8 Connection .10
6.4.9 Disconnection .10
6.4.10 CI state machine .11
6.4.11 Cross-CI prioritization .12
6.4.12 Protection of CI .14
6.4.13 Regulatory information management .15
7 Virtual communication interface .15
7.1 Concept .15
7.2 VCI procedures .19
7.2.1 Creation of VCI .19
7.2.2 Reset of VCI .20
7.2.3 Deletion of VCI .20
7.2.4 Association of peer with Link-ID .20
7.2.5 Change of I-Parameter settings .21
8 Communication SAP .21
8.1 Addressing .21
8.1.1 IN-SAP nt_protocol_id address .21
8.1.2 IN-SAP source and destination addresses .21
8.2 Service primitives .22
8.2.1 IN-SAP functions .22
8.2.2 IN-UNITDATA.request .23
8.2.3 IN-UNITDATA.indication .24
8.2.4 IN-UNITDATA-STATUS.indication .24
8.2.5 IN-UNITDATAACK.request .26
8.3 Priority .26
8.4 Timeout .27
8.5 Queue management .27
8.6 Access parameters .27
8.7 Transmission status .28
9 Management SAP .28
9.1 MI-SAP services .28
9.2 MI-COMMAND service primitive functions .28
9.2.1 Overview .28
9.2.2 ChangePseudonymMACaddress .29
9.2.3 CIstateChange .29
9.2.4 CnConnect .30
9.2.5 MacManagementFrameTX .30
9.2.6 ManufacturerCommand.31
9.2.7 MonitorIparameters .31
9.2.8 PrioritizedRequestToSend . .31
9.2.9 PrioritizedRTSrelease . .32
9.2.10 RegulatoryInformation .32
9.2.11 VCImanagement .32
9.2.12 WakeUpSignal.33
9.3 MI-REQUEST service primitive functions .33
9.3.1 Overview .33
9.3.2 EventNotification .33
9.3.3 MacManagementFrameRX .34
9.3.4 PositionUpdate .34
9.3.5 PrioritizationRegistration .34
9.3.6 PrioritizationRequest .35
9.3.7 PrioritizationRelease.35
9.3.8 RegistrationCI .35
10 Events .36
11 Dynamic data .36
12 Conformance .37
13 Test methods .37
Annex A (normative) I-Parameters .38
Annex B (normative) ASN.1 definitions .44
Annex C (normative) Extended universal 64 bit identifier .60
Annex D (normative) Path and flow management support .63
Annex E (normative) Implementation conformance statement (ICS) proforma .64
Bibliography .78
iv © ISO 2018 – 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 on 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 the following
URL: www .iso .org/iso/foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
This third edition cancels and replaces the second edition (ISO 21218:2013), which has been technically
revised. It also incorporates the Amendment ISO 21218:2013/Amd 1:2014.
The main changes compared to the previous edition are as follows:
— ASN.1 has been aligned with the latest developments in ISO/TC 204;
— provisioning for path and flow management has been added;
— normative annex related to conformance testing, that contains the PICS proforma, has been added;
— management commands have been added;
— minor technical and editorial improvements.
Introduction
This document is part of a family of International Standards for communications in Intelligent Transport
Systems (ITS) based on the ITS station and communication architecture specified in ISO 21217.
Hybrid communications, i.e. simultaneous support of different communication protocol stacks with
different access technologies, is essential for ITS.
This document supports
— hybrid communications as requested, e.g. for Cooperative ITS in Europe, and
— path and flow management, enabling abstraction of applications from communications details.
It 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;
— functions of the service primitives in the MI-SAP with reference to the generic services of the MI-
SAP specified in ISO 24102-3.
The IN-SAP and the MI-SAP are presented in Figure 1. The specification of the SI-SAP is not within the
scope of the present version of this document.
Figure 1 — ITS station reference architecture with named interfaces
This third edition cancels and replaces the second edition which has been revised and harmonized with
newly developed C-ITS standards.
vi © ISO 2018 – All rights reserved

INTERNATIONAL STANDARD ISO 21218:2018(E)
Intelligent transport systems — Hybrid communications —
Access technology support
1 Scope
This document specifies general technical details related to the access layer of the ITS station reference
architecture specified in ISO 21217 including:
— the service access point (SAP) of a communication interface (CI) as provided by the communication
adaptation layer (CAL) for communication, named IN-SAP, and related service primitives and service
primitive functions;
— the SAP provided by the CI management adaptation entity (MAE) for management of the
communication interface, named MI-SAP, and related service primitives by reference to ISO 24102-3,
and service primitive functions.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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 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-3, Intelligent transport systems — ITS station management — Part 3: Service access points
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21217, ISO 24102-3 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http: //www .electropedia .org/
— ISO Online browsing platform: available at https: //www .iso .org/obp
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
[9]
EXAMPLE An example of an ITS-S access layer technology and protocol is IR specified in .
3.3
medium
physical properties of a CI used to transmit a modulated signal, e.g. wireless or on a wire
Note 1 to entry: Medium is 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
3.7
temps atomique international
time since 00:00:00 UTC, 1 January, 2004, identical with UTC except that no leap seconds need to be added
4 Abbreviated terms
APN Access point name
BC-VCI VCI for transmission to the broadcast MAC address
CAL Communication adaptation layer
CEN Comité Européen de Normalisation (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 (5,8 GHz back-scatter technology used in Eu-
rope for e.g. road tolling). This term is used in the USA to indicate IEEE 802.11 OCB
[10]
communications in the 5,9 GHz band, see ISO 21215
ETSI European Telecommunications Standards Institute
EUI ESxtended universal identifier
EUI-64 64-bit EUI
ICS Implementation conformance statement
IN-SAP Communication SAP as offered by the CAL to the ITS-S networking & transport layer
ITS-APDU ITS station Access layer Protocol Data Unit
LocalCIID CIID of a local CI
2 © ISO 2018 – All rights reserved

LSB Least significant bit
MAC-48 48 bit MAC address
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
[16]
NOTE  Term used for DSRC .
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
TAI Temps Atomique International
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
UTC Temps Universel Coordonné/Coordinated Universal Time
VCI virtual communication interface
WAVE Wireless access in vehicular environments
NOTE  IEEE work item related to [10].
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);
— the management interface to the MI-SAP by means of a management adaptation entity (MAE);
— the security interface to the SI-SAP by means of a security adaptation entity (SAE).
The CI adaptation is outlined in Figure 2.
Figure 2 — Architecture
This document 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 use the
same type of IN-SAP between the ITS-S networking & transport layer and the CAL.
The medium-specific CAL provides an IN-SAP to the ITS-S networking & transport layer.
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 use 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
[2]
ISO/IEC/IEEE 8802-11 with respect to the station management entity. The MI-SAP offers the services
presented in Clause 9.
4 © ISO 2018 – All rights reserved

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 document does not provide the specification of the SAE.
6 Communication interface
6.1 Architecture
This document 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 CI Classes
CIs can be classified. Complementary classes shall be distinguished by means of CI classes presented
in Table 1. A CI typically supports exctly one of the CI classes presented presented in Table 1. The set of
applicable CI classes of a CI is given in I-Parameter CIclass of ASN.1 type CIclass. A single CI class is of
ASN.1 type CIclassSingle.
NOTE New CI classes can be added as dynamic data, see Clause 11.
Table 1 — CI classes
Communication
Definition and explanations
interface class
CIC-l1 CI that is capable of establishing simultaneous associations with different peer sta-
tions for unicast communication, and of receiving from and transmitting to broad-
cast and multicast (group) addresses.
EXAMPLE  Access technologies specified in [9],[10],[11].
CIC-l2 CI that is capable of establishing a session via a single base station of a cellular net-
work (typically to access Internet). Handover between different base stations may be
possible, but not visible to the ITS upper layers and the ITS-S management.
EXAMPLE  Access technologies specified in [3],[7],[8]…
CIC-l3 CI that is capable to transmitting only on the basis of broadcast/multicast (group)
addresses.
EXAMPLE  Access technologies specified in [9],[10],[11]…
CIC-l4 CI that is capable only of receiving frames from a broadcast station.
EXAMPLE  Satellite navigation receiver, satellite broadcast receiver, …
Table 1 (continued)
Communication
Definition and explanations
interface class
CIC-l5 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 mas-
ter. Communication session establishment is done inside the CI.
EXAMPLE  Japanese DSRC, CEN DSRC, …
CIC-l6 CI for a cellular network technology that is capable of supporting one-to-many com-
munications either with support of a base station of a cellular network (allocation
of resources on a packet-per-packet basis) or without support of the base station
(pre-configured resources).
Example: LTE technologies specified in [4],[5].
CIC-il1 CI for station-internal network of an ITS station. Non-deterministic.
CIC-il2 CI for station-internal network of an ITS station. Deterministic.
6.2.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 complementary CI access classes, i.e. a CI supports exactly one of the
CI access classes presented in Table 2. The applicable CI access classes of a CI is given in I-Parameter
CIaccessClass of ASN.1 type CIaClass.
NOTE New CI access classes can be added as dynamic data, see Clause 11.
Table 2 — CI access classes
CI access class Definition and explanations
CIAC-1 No user authentication required.
CIAC-2 CI requires access credentials, e.g. PIN and operator data.
CIAC-3 CI may require access credentials, e.g. PIN and operator data, dependent
on the operational mode.
6.3 Link identifier
CIs and VCIs are referenced/addressed by a unique Link-ID. The Link-ID shall be constructed according
to Figure 3.
6 © ISO 2018 – All rights reserved

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.
[13]
NOTE A two octet ITS-SCU-ID specified in ISO 24102-4 , identifying uniquely an ITS-SCU of an ITS-SU, can
be derived from LocalCIID by 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 identifies the CI which is addressed by the value
of LocalCIID. This reserved number shall be
— the distinct null identifier (DNI) presented in D.2 for CIs supporting 48-bit MAC addresses;
— the "VCISerialNumber" field set to zero combined with the "UC/GC" field set to zero presented in D.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 D.1, which may
contain a 48-bit MAC address as illustrated in D.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 use the numbering scheme specified in D.3.
The 48-bit MAC address is one example of a link layer address. Registered unique link layer addresses
are presented in the medium-specific I-Parameter 8 "LLaddress". Locally assigned temporary values of
a link layer address are stored in the I-Parameter 9 "LLaddressTemp".
6.4 CI procedures
6.4.1 General
The procedures as specified here use management services of the MI-SAP, as specified in Clause 9. The
dynamic registration and deregistration procedures do not apply for CIs that are statically registered
by implementation.
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".
A CI shall request registration of itself at the ITS-S management upon power-up, or upon physical
insertion/activation of it. Two procedures are distinguished.
The following registration procedure shall be performed for CIs supporting 48-bit MAC addresses.
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 8 "LLaddress", with RemoteCIID equal to the "Distinct
Null Indicator" (DNI) value presented in Annex C.
2) Send MI-REQUEST.request of ASN.1 type RegistrationCI indicating I-Parameter 14 "MedType"
using the Link-ID constructed in step 1).
3) Set timer T_register to the value given in I-Parameter 7 "TimeoutRegister".
4) Await MI-REQUEST.confirm of ASN.1 type RegistrationCIconf providing the "ITS-SCU-ID"
and "MedID" as long as T_register has not expired.
5) If the registration request was successfully performed, 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 4 "ITS-SCU-ID" as received in step 4. Set I-Parameter
12 "CIstatus" to the value "registered", and notify the new CIstatus value to the ITS-S management
using MI-REQUEST.request of ASN.1 type Event21218Notification with event E21218-5.
The following registration procedure shall be performed for CIs not supporting 48-bit MAC addresses.
1) Create a preliminary Link-ID illustrated in Figure 3 with LocalCIID and RemoteCIID constructed as
illustrated in Figure D.3 with:
i) LocalCIID
I) Set VCISerialNumber to the value zero, indicating the local CI.
[13]
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.
The selected value of MedID might already be in use by another CI. Thus this value shall 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 MI-REQUEST.request of ASN.1 type RegistrationCI indicating I-Parameter 14 "MedType".
3) Set timer T_register to the value given in I-Parameter 7 "TimeoutRegister".
4) Await MI-REQUEST.confirm of ASN.1 type RegistrationCIconf providing true values of "ITS-
SCU-ID" and "MedID" as long as T_register has not expired.
5) If the registration request was successfully performed, 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).
8 © ISO 2018 – All rights reserved

7) Upon successful registration, set I-Parameter 4 "ITS-SCU-ID" and I-Parameter 5 "MedID"to the
values received from the ITS station management. Set I-Parameter 12 "CIstatus" to the value
"registered", and notify this value to the ITS management.
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.request of ASN.1 type CIstateChange with the value "deregister".
Deregistration results in
— setting the ITS-SCU-ID to the value zero,
— deletion of all VCIs, and
— setting I-Parameter 12 "CIstatus" to the value "not existent".
The ITS- managament shall be notified of successful deregistration 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.request of ASN.1 type CIstateChange with the value "inactivate".
As a consequence of resetting a CI, no more VCIs exist, and thus there are no more pending data packets
of the previously existing VCIs.
[7] [8]
NOTE In a CI of class "CIC-l2" and access class "CIAC-2" such as specified in or, inactivation will result in
disconnecting from the wireless service, i.e. ringing off.
The MAE shall set I-Parameter 12 "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.request of ASN.1 type CIstateChange with the value "activate".
This command shall trigger creation of VCIs as specified in 7.2.1.
The ITS-S management shall be notified of successful activation.
NOTE In a CI of class "CIC-l2" such as specified in [3],[7],[8] 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.request of ASN.1 type CIstateChange with the value "suspend".
All VCIs shall be maintained. No pending data packets shall be lost. An on-going frame transmission
may be finalized. An on-going frame reception shall be finalized.
The MAE shall set I-Parameter 12 "CIstatus" to the value "suspended" and shall notify it to the ITS-S
management.
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.request of ASN.1 type CIstateChange with the value "resume".
The MAE shall set I-Parameter 12 "CIstatus" to the value "connected" and shall notify the ITS-S
management. Pending packets shall be processed after resuming, if possible, otherwise pending
packets may be deleted.
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" 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.request of ASN.1 type CIstateChange with the value "connect".
The MAE shall set the I-Parameter 12 "CIstatus" to the value "connected" and shall notify the ITS-S
management about the change of status.
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 is performed upon the event that no more TX-VCIs 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.request of ASN.1
type CIstateChange with the value "disconnect". There may be an implicit disconnection caused by
deletion of a VCI.
The MAE shall set I-Parameter 12 "CIstatus" to the value "active" and shall notify the ITS-S management.
10 © ISO 2018 – All rights reserved

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;
2) registered;
c) the operational states:
1) active;
2) connected, not applicable for receive-only CIs (CIC-l4);
d) the non-operational states, not applicable for receive-only CIs (CIC-l4):
1) suspended;
2) inactive;
see I-Parameter 12 "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.2.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;
— delete VCI, see 7.2.3.
Requests to perform invalid transitions shall be acknowledged with error code ErrStatus="INVALID
COMMAND/REQUEST VALUE" specified in ISO 24102-3.
© I
...