ETSI TR 103 099 V1.3.1 (2015-07)

Intelligent Transport Systems (ITS); Architecture of conformance validation framework

RTR/ITS-00346

General Information

• Status: Published
• Publication Date: 20-Jul-2015
• Technical Committee: ITS WG3 - Transport and Network
• Current Stage: 12 - Completion
• Due Date: 16-Jul-2015
• Completion Date: 21-Jul-2015

Standards Content (Sample)

TECHNICAL REPORT
Intelligent Transport Systems (ITS);
Architecture of conformance validation framework

2 ETSI TR 103 099 V1.3.1 (2015-07)

Reference
RTR/ITS-00346
Keywords
architecture, conformance, ITS, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TR 103 099 V1.3.1 (2015-07)
Contents
Intellectual Property Rights . 6
Foreword . 6
Modal verbs terminology . 6
Introduction . 6
1 Scope . 7
2 References . 7
2.1 Normative references . 7
2.2 Informative references . 7
3 Abbreviations . 8
4 Test platform overview . 9
4.1 Constraints and requirements . 9
4.2 General architecture . 9
5 Hardware equipment . 10
5.1 PC . 10
5.2 G5 adapter box . 11
6 Codecs . 11
6.1 Introduction . 11
6.2 Advanced details of implementation . 11
7 Test Adapter . 13
7.1 Introduction . 13
7.2 Lower Tester . 14
7.2.1 Overview . 14
7.2.2 Advanced details of implementation . 16
7.2.3 Extensibility of the test adapter. 18
7.2.4 Adapter Control primitives . 18
7.2.5 Adapter configuration parameters . 18
7.3 Platform Adapter . 20
7.4 Upper Tester . 20
Annex A: Codecs Source Code . 22
Annex B: Test Adapter Source Code . 23
Annex C: Upper Tester Message Format. 24
C.1 Introduction . 24
C.2 Common Upper Tester Primitives . 24
C.2.1 UtInitialize . 24
C.2.2 ChangePosition . 25
C.2.3 ChangePseudonym . 26
C.3 CAM Upper Tester Primitives . 26
C.3.1 ChangeCurvature . 26
C.3.2 ChangeSpeed . 27
C.3.3 SetAccelerationControlStatus. 27
C.3.4 SetExteriorLightsStatus . 29
C.3.5 ChangeHeading . 29
C.3.6 SetDriveDirection . 30
C.3.7 ChangeYawRate . 30
C.3.8 CamEventIndication . 31
C.3.9 SetStationType . 31
C.3.10 SetVehicleRole . 32
C.3.11 SetEmbarkationStatus . 32
ETSI
4 ETSI TR 103 099 V1.3.1 (2015-07)
C.3.12 SetPtActi vatio n . 33
C.3.13 SetDangerousGoods . 33
C.3.14 SetLightBarSiren . 34
C.4 DENM Upper Tester Primitives . 35
C.4.1 GenerateDenmEvent . 35
C.4.2 UpdateDenmEvent . 37
C.4.3 TerminateDenmEvent . 38
C.4.4 DenmEventIndication . 38
C.5 GeoNetworking Upper Tester Primitives . 39
C.5.1 GenerateGeoUnicast . 39
C.5.2 GenerateGeoBroadcast . 39
C.5.3 GenerateGeoAnycast . 40
C.5.4 GenerateSHB . 41
C.5.5 GenerateTSB . 41
C.5.6 GnEventIndication. 42
C.6 IPv6OverGeoNetworking Upper Tester Primitives . 42
C.6.1 SendIPv6Message . 42
C.6.2 GetInterfaceInfos . 43
C.6.3 Gn6EventIndication. 43
C.7 BTP Upper Tester Primitives . 44
C.7.1 GenerateBtpA . 44
C.7.2 GenerateBtpB . 44
C.7.3 BtpEventIndication . 45
C.8 MAP SPAT Upper Tester Primitives . 45
C.8.1 UtMapSpatTrigger. 45
C.8.2 UtMapEventInd . 46
C.8.3 UtSpatEventInd . 46
Annex D: Example of Test Platform implementation . 47
Annex E: Complete Test Adapter class diagram . 52
Annex F: Bibliography . 53
History . 54

ETSI
5 ETSI TR 103 099 V1.3.1 (2015-07)
List of figures
Figure 1: General architecture .10
Figure 2: Communication via G5 adaptation box .11
Figure 3: Communication via Ethernet .11
Figure 4: Codec class diagram .13
Figure 5: Message sending sequence diagram .15
Figure 6: Message reception sequence diagram .15
Figure 7: Test Adapter class diagram .16
Figure 8: Port initialization sequence diagram .17
Figure 9: Upper Tester architecture .21
Figure E.1: Test adapter complete class diagram .52

ETSI
6 ETSI TR 103 099 V1.3.1 (2015-07)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Intelligent Transport Systems (ITS).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
In response to EC mandate M/453 [i.10], ETSI Technical Committee (TC) ITS has standardized base and test
specifications for ITS protocols. In a next step a prototype TTCN-3 test system was built and validated. The present
document describes the design and validation of the prototype TTCN-3 test system.
The action described in the present document has supported the implementation of ITS standards by:
• Making available validated and standardized test specifications and thus enabling the application of reliable
certification schemes.
• Executing conformance validation framework against real Implementations Under Test (IUTs) from industry
and thus providing these companies a conformance assessment of their implementations. During the lifetime
of this action, the conformance validation framework was as well provided at ITS Cooperative Mobility
Services Interoperability events.
• Releasing all software as open source and thus allowing industry to build and run their own conformance
validation framework.
ETSI
7 ETSI TR 103 099 V1.3.1 (2015-07)
1 Scope
The present document provides a description of the architecture of the ITS conformance validation framework,
including definition of the test environment, codec and test adapter. It provides, as well, all the necessary source code to
build and run the ITS conformance validation framework.
The ITS conformance validation framework integrates the test suites ETSI TS 102 871-3 [i.4], ETSI TS 102 868-3 [i.5],
ETSI TS 102 869-3 [i.6], ETSI TS 102 870-3 [i.7], ETSI TS 102 859-3 [i.8] and ETSI TS 103 191-3 [i.9].
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or non-
specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or non-
specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] ETSI ES 201 873-5 (V4.5.1): "Methods for Testing and Specification (MTS); The Testing and
Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)".
[i.2] ETSI EG 201 015 (V2.1.1): "Methods for Testing and Specification (MTS); Standards engineering
process; A handbook of validation methods".
[i.3] IEEE 802.11p™: "IEEE Standard for Local and Metropolitan Area Networks - Specific
requirements; Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications; Amendment 6: Wireless Access in Vehicular Environments".
[i.4] ETSI TS 102 871-3 (V.1.3.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for GeoNetworking ITS-G5; Part 3: Abstract Test Suite (ATS) and Protocol
Implementation eXtra Information for Testing (PIXIT)".
[i.5] ETSI TS 102 868-3 (V.1.3.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Cooperative Awareness Basic Service (CA); Part 3: Abstract Test Suite (ATS)
and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.6] ETSI TS 102 869-3 (V.1.4.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Decentralized Environmental Notification Basic Service (DEN); Part 3: Abstract
Test Suite (ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
ETSI
8 ETSI TR 103 099 V1.3.1 (2015-07)
[i.7] ETSI TS 102 870-3 (V.1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Geonetworking Basic Transport Protocol (BTP); Part 3: Abstract Test Suite
(ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.8] ETSI TS 102 859-3 (V.1.2.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Transmission of IP packets over Geonetworking; Part 3: Abstract Test Suite
(ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.9] ETSI TS 103 191-3 (V.1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Signal Phase And Timing (SPAT) and Map (MAP); Part 3: Abstract Test Suite
(ATS) and Implementation eXtra Information for Testing (IXIT)".
[i.10] EC mandate M/453: "Standardisation mandate addressed to CEN, CENELEC and ETSI in the
field of Information and Communication Technologies to support the interoperability of co-
operative systems for Intelligent Transport in the European Community".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AC Adapter Control
ACC Adaptive Cruise Control
API Application Programming Interface
ASN Abstract Syntax Notation
AT Authorization Ticket
ATS Abstract Test Suite
BTP Basic Transport Protocol
BTP-A Basic Transport Protocol - Type A
BTP-B Basic Transport Protocol - Type B
CAM Cooperative Awareness Message
CC Cruise Control
DENM Decentralized Environmental Notification Message
EC European Commission
ETH ETHernet
GN GeoNetworking
HB High Beam
IP Internet Protocol
ITS Intelligent Transportation Systems
ITS-S Intelligent Transportation Systems - Station
IUT Implementation Under Test
JDK Java™ Development Kit
LB Low Beam
LS Location Service
LT Left Turn
MAC Media Access Control
MAP MapData
MTC Main Test Component
OS Operating System
OSI Open Systems Interconnection model
PC Personal Computer
Pcap Packet capture
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
RT Right Turn
SHB Single Hop Broadcast
SPAT Signal Phase And Timing
SUT System Under Test
TA Test Adapter
TC Test Cases
TCI TTCN-3 Control Interface
TP Test Purposes
ETSI
9 ETSI TR 103 099 V1.3.1 (2015-07)
TRI TTCN-3 Runtime Interface
TSB Topology Scoped Broadcast
TTCN-3 Testing and Test Control Notation 3
UDP User Datagram Protocol
UT Upper Tester
XP Windows™ XP operating system
4 Test platform overview
4.1 Constraints and requirements
The purpose of the ITS test platform is to provide a reliable set of software and hardware equipments that can be used to
validate TTCN-3 abstract test suites (ATS) developed in ETSI.
The architecture of this test platform has been designed with respect to the following constraints:
• to be compatible with the requirements expressed in the validation handbook (ETSI EG 201 015 [i.2]);
• to be independent of the platform used to implement the test system;
• to be independent of the TTCN-3 tool provider;
• to be configurable and customizable;
• to provide tools and well defined interfaces to system under test (SUT), allowing test automation;
• to be easily extensible for future ITS protocols;
• to provide generic components that can be reused in other test platforms.
In order to ensure independence of hardware platforms, all software pieces running on the test platform have been
implemented using Java™ language, using generic and widely used libraries.
Test tool independence has been achieved by isolating the tool specific interfaces from core functionalities of the
platform. Adapting the current platform to a different test tool would only require the implementation of a very simple
piece of software mapping tool-specific functions to generic functions defined in this project.
In addition, great care has been taken to separate ITS specific functionalities from generic test platform tasks in order to
provide a maximum number of reusable components for future test platforms.
4.2 General architecture
Typically a TTCN-3 test platform is composed of four different components:
• The TTCN-3 test tool providing necessary software to execute the abstract test suites.
• The hardware equipment supporting TTCN-3 test execution and adaptation to SUTs.
• The codecs which convert protocol messages into their abstract TTCN-3 representation.
• The Test Adapter (TA) implementing interfaces with the device under test.
The interaction of these components is described in figure 1.
ETSI
10 ETSI TR 103 099 V1.3.1 (2015-07)
ITS test system SUT
Upper tester
Test control
application
TTCN-3 test components
IUT
Port Upper
Port
tester
Test adapter
Upper tester ITS lower ITS lower Upper tester
transport layers layers transport
Lower layers link
Upper tester transport link
Figure 1: General architecture
The TTCN-3 test tools are usually provided by commercial companies and their description is out of the scope of the
present document. The implementation details of the other components are described in the present document.
5 Hardware equipment
5.1 PC
The main hardware component of the ITS test platform is a standard PC. Its role is to host the execution of the test
suites using a commercial TTCN-3 test tool.
Whatever operating system is installed on the computer, it is necessary to ensure that the following points are taken into
account:
• No firewall interference with traffic generated by the Test System and/or SUT.
• Excellent time synchronization between the SUT and the test system.
• Test system processes (especially the test adapter) have to be granted unrestricted control to
telecommunication hardware.
Time synchronization is maybe the most critical point to be checked before starting any test session, as it can be the
source of strange SUT behaviour and generate incoherent results. Indeed, most ITS protocol messages feature a time tag
used by the receiver to determine if the information it carries is still valid; if the test system is ahead in time, all
messages it sends will be considered either as coming from the future or from a very old date, and be discarded.
This PC is equipped with two network cards, one being used for ITS communication with SUT (lower layers link), the
other one being used for exchanging upper tester messages (upper tester transport link). Separating these two
communications on different hardware interfaces is not an absolute necessity, but it is a good practice and it ensures that
there will be no interaction between the flows.
The communication between the SUT and the test system is achieved through Ethernet if the SUT supports it or using a
G5 adaptation box, as shown in figure 2 and in figure 3.
ETSI
11 ETSI TR 103 099 V1.3.1 (2015-07)

Figure 2: Communication via G5 adaptation box

Figure 3: Communication via Ethernet
5.2 G5 adapter box
The ITS protocol stack makes use of G5 radio protocol in order to establish communication between ITS devices. To
achieve G5 connectivity, a dedicated hardware equipment needs to be added to the test platform. The role of this
adaptation box is to handle all radio-related tasks transparently and to act as a bridge for the test system.
TM
MK2 has been chosen to fulfil this task. This device is fully IEEE 802.11p [i.3] compliant and
Cohda Wireless
provides as well an Ethernet interface so that it can be used as a transparent bridge between the test system and the
SUT, as depicted in figure 2.
To transfer frames received on the Ethernet interface to the radio interface and vice versa, it is necessary to install and
execute a small bridge application on the MK2. Only the frame featuring a specific ethertype (0x0707 by default) will
be transferred from one interface to the other, so that only desired traffic will cross the bridge.
6 Codecs
6.1 Introduction
The codec entity is responsible for the encoding and decoding of TTCN-3 abstract values into bitstrings suitable to be
sent to the System Under Test (SUT).
In order to simplify implementation and to ease the maintenance, coding and decoding tasks are handled by several
codecs:
• One independent codec package per tested protocol;
• One codec package for TTCN-3 types that do not correspond to real protocol messages. It includes for
example all auxiliary types used to carry information to/from Test Adapter, like the ones defined in
TestSystem modules (CoapInd, CoapReq, etc.);
• One generic codec package available for handling default codec operation non related to any specific protocol.
Theses codecs will be used if no protocol-specific codec exists for one type.
6.2 Advanced details of implementation
Figure 4 gives an overview of the relations between the different Java™ classes implementing the codecs. Connection
with the tool-dependent classes is realized through the ITERquired interface and the associated factory class.
Each codec is responsible for correctly encoding and decoding one specific type and implements the ICodec interface.
ETSI
12 ETSI TR 103 099 V1.3.1 (2015-07)
Selection of correct codec for encoding or decoding a message at runtime is managed by the CodecFactory class, via the
getCodec() method. This method will select the appropriate codec based on three parameters:
• the type name;
• the encoding as specified in TTCN-3 modules using "with encode" statements;
• the type class (record, union, etc.).
The rules for selecting the correct codec are the following:
1) If a codec is registered for type name in the package corresponding to encoding, then select this codec
and call encode() or decode() method;
2) Otherwise, if a codec is registered for type class in the package corresponding to encoding, then select
this codec and call encode() or decode() method;
3) Otherwise, use codec corresponding to type class in generic package.
This design provides both flexibility and easy extensibility. For most protocols, the "generic" codec package will handle
most of the encoding and decoding operations. Specific encoding processes can be handled case by case by adding
minimal codecs and registering them in the CodecFactory.
ETSI
13 ETSI TR 103 099 V1.3.1 (2015-07)

Figure 4: Codec class diagram
7 Test Adapter
7.1 Introduction
The test adapter conceptually splits into three parts:
• a lower test adapter;
• a TTCN-3 platform adapter implementing timers;
• an upper test adapter.
ETSI
14 ETSI TR 103 099 V1.3.1 (2015-07)
7.2 Lower Tester
7.2.1 Overview
TTCN-3 test suites are usually focusing on a single protocol layer and designed to be executed against real
implementations (IUT). However, it is unusual to find standalone implementations as they are commonly integrated as
an internal component of a physical device (SUT).
The purpose of a lower test adapter is to prepare and adapt the protocol messages used by TTCN-3 test suites so that
they can be transmitted successfully to the SUT. One way to achieve this goal is for example to implement lower layers
and encapsulate protocol messages accordingly. For instance, CAM and DENM messages need to be encapsulated in
BTP datagrams, themselves encapsulated into GeoNetworking packets, and transmitted over G5 radio link. The higher
up the IUT is located in the OSI stack, the more complex is the test adapter.
TTCN-3 test suites send and receive protocol messages via TTCN-3 communication ports. For each of these ports
defined in the test suites, a corresponding port entity needs to be implemented in the test adapter using standardized TRI
interface (ETSI ES 201 873-5 [i.1]). To provide maximum flexibility and allow for extensibility, the test adapter ports
of the ITS test platform have been designed with the following constraints:
• For each port family, the lower stack can be configured using test adapter parameters (see annex D). As a
consequence it is possible to dynamically define what will be the lower layers used to communicate with SUT,
and how protocol messages will be encapsulated.
• All the instances of ports are independent.
• Behaviour of ports and lower layers can be dynamically modified by using predefined AC (Adapter Control)
primitives directly sent from TTCN-3 script using dedicated port AcPort. For example, the AC primitive
'startBeaconing' requests the test adapter to start sending beacons.
The test adapter implementation mainly features Port and Layer objects. The relationship and interactions between
these objects will be further detailed in clause 7.2.2, but it is important to notice the main differences between these
objects, as misunderstanding their roles can lead to confusion:
• Port objects are the counterpart of TTCN-3 communication ports.
• Layer objects implement the minimal functionalities of a protocol layer and provide facilities for
encapsulating or decapsulating packets.
• Port objects are configured with a lower stack composed of cascading Layer objects.
Layer objects usually implement more functionalities than Port objects.
• For a same protocol layer,
Figures 5 and 6 show an example of interactions between these objects respectively when sending and receiving a
message. The port described in this example is a CAM port configured with a BTP/GN/G5 lower stack.
ETSI
15 ETSI TR 103 099 V1.3.1 (2015-07)

Figure 5: Message sending sequence diagram

Figure 6: Message reception sequence diagram
ETSI
16 ETSI TR 103 099 V1.3.1 (2015-07)
7.2.2 Advanced details of implementation
Figure 7 presents the simplified class diagram of the test adapter. For better readability, auxiliary classes such as
factories are not represented. The complete class diagram, also featuring design pattern indications, can be found in
annex E.
Figure 7: Test Adapter class diagram
The main class of this implementation is the TestAdapter class. It implements the standardized interface
TriCommunicationSA and uses the ITERequired interface implemented by test tool providers. These interfaces
are part of the TRI API defined in ETSI ES 201 873-5 [i.1]. All other classes of this implementation are completely
TRI-agnostic. The main purpose of the TestAdapter class is to instantiate and manage the different ports.
ETSI
17 ETSI TR 103 099 V1.3.1 (2015-07)
There are two different kinds of ports:
• Protocol ports realizing communication between TTCN-3 and SUT.
• Adapter ports which are used for test adapter configuration and upper tester communication.
Upon protocol port initialization, lower layers are instantiated in cascade and chained as depicted in figure 8, based on
lower stack description. Figure 8 also illustrates the usage of "Factory" design patterns for instantiating Layer and
Port objects. Each Layer is responsible for encapsulating and decapsulating packets and transmitting result to lower
and upper layer using send()/receive() methods.

Figure 8: Port initialization sequence diagram
Currently the following layers have been implemented:
• GnLayer: basic functionalities of GeoNetworking layer, including beaconing.
• BtpLayer.
• EthernetLayer. It is important to note that this class requires the usage of the external library JnetPcap for
capturing and injecting Ethernet frames.
• G5Layer.
ETSI
18 ETSI TR 103 099 V1.3.1 (2015-07)
The Management class, implementing IManagementTA and IManagementLayers interfaces is used for
handling the dynamic configuration of Layer objects. It is directly linked to the AdapterControlPort and implements the
AC primitives defined in the TTCN-3 test suites. It is important to notice that this class is implemented using a
"Multiton or Multiple Singleton" design pattern: one single instance of this class can be instantiated per TTCN-3
component.
7.2.3 Extensibility of the test adapter
The test adapter can be extended in several ways. The first option is to add new protocol layers by adding new classes
inheriting from the Layer class. These new layers have then to be assigned a short name and registered in the
LayerFactory.
It is also possible to define new protocol ports. To do so, it is necessary to implement new classes inheriting from the
ProtocolPort class. These new ports have then to be assigned a short name and registered in the
ProtocolPortFactory.
Furthermore, it is also possible to extend AC primitives. This requires to enrich IManagementLayers and
IManagementTA interfaces and to implement new functionalities in the Management class.
7.2.4 Adapter Control primitives
The following adapter control primitives are used to control the dynamic configuration of the various layers:
Table 1: Adapter Control primitives
Adapter Control Primitive Description
startBeaconing
Requests Test Adapter to start sending periodic beacons for the current
component
stopBeaconing
Requests Test Adapter to stop sending periodic beacons for the current component
startEnqueueingBeacons
Requests Test Adapter to start enqueueing beacon messages on the current
component GN port
stopEnqueueingBeacons
Requests Test Adapter to stop enqueueing beacon messages on the current
component GN port
startMultipleBeaconing
Requests Test Adapter to start simulating neighbour presence by sending multiple
periodic beacons for the current component
stopMultipleBeaconing
Requests Test Adapter to stop simulating neighbour presence
getLongPositionVector
Gets the long position vector of a neighbour given its GN_Address

7.2.5 Adapter configuration parameters
The test adapter provides several parameters to configure and adapt its behaviour. Some of those parameters are generic
and apply globally to the complete test adapter, and some are specific to a particular protocol (i.e. those are mainly
parameters used by Port object).
Table 2: Generic test adapter configuration parameters
Parameter name Description Example
UpperTesterSettings 192.168.56.129:1501
IUT's Upper Tester module IP
address and port, to which Test
System UT primitives will be sent.

:
TsLatitude 7 000
Latitude of the Test System
TsLongitude 520 000
Longitude of the Test System
TsSecuredMode Indicates whether ITS security is false
enabled or disabled.
"true" or "false"
For more
If set to 'true' then the test adapter will
process all security actions internally.
If set to false then the test adapter
LocalEthernetMAC 005056C00008
Link layer address of the physical
interface to be used to communicate
with IUT
IutEthernetTypeValue 0x8947
Ethertype value used by IUT
ETSI
19 ETSI TR 103 099 V1.3.1 (2015-07)
Table 3: GeoNetworking test adapter configuration parameters
Parameter name Description Example
geoNetworkingPort ETH
Configuration of GnPort's lower layers
//./
LinkLayer_MTC BABEBABE0000
Link layer address of simulated ITS-S
MTC
LinkLayer_NodeA BABEBABE0001
Link layer address of simulated ITS-S
NodeA
LinkLayer_NodeB BABEBABE0002
Link layer address of simulated ITS-S
NodeB
LinkLayer_NodeC Link layer address of simulated ITS-S BABEBABE0003
NodeC
LinkLayer_NodeD BABEBABE0004
Link layer address of simulated ITS-S
NodeD
LinkLayer_NodeE BABEBABE0005
Link layer address of simulated ITS-S
NodeE
LinkLayer_NodeF BABEBABE0006
Link layer address of simulated ITS-S
NodeF
TsBeaconInterval 1 000
Beaconing interval to be used by
GnPort
Table 4: BTP test adapter configuration parameters
Parameter name Description Example
btpPort GN/ETH
Configuration of BtpPort's lower
layers
//./

Table 5: CAM test adapter configuration parameters
Parameter name Description Example
camPort BTP/GN/ETH
Configuration of CamPort's lower
layers
//./

Table 6: DENM test adapter configuration parameters
Parameter name Description Example
denmPort BTP/GN/ETH
Configuration of DenmPort's lower
layers
//./

Table 7: GN6 test adapter configuration parameters
Parameter name Description Example
ipv6OverGeoNetworkingPort Configuration of Gn6Port's lower Debug
layers
//./
Gn6RemoteAdapterIp 192.168.56.11
IP address of the GN6 remote
adapter
Gn6RemoteAdapterPort 42 000
Listening port of the remote GN6
adapter
ETSI
20 ETSI TR 103 099 V1.3.1 (2015-07)
Table 8: Security test adapter configuration parameters
Parameter Description Example
TsSecuredMode false
Indicates that test adapter performs all security tasks internally (see
notes 1 and 2)
TsSecuredPath "data/certificates"
Secured root path to access certificate files
TsSecuredConfiId vendorA
Vendor specific configuration identifier. This should be actually a
name of the subfolder inside the TsSecuredPath, containing the
IUT certificates or digests, e.g. "data/certificates/vendorA"
NOTE 1: The parameter TsSecuredMode==true indicates that all security tasks are performed by the test adapter. This
includes that the test adapter will decapsulate the received secured message and pass the payload to the
upper layer as well as to encapsulate the toBeSent message
The parameter TsSecuredMode==false indicates that the test adapter passes the received secured message
to the
...