NITlab have upgraded the NITOS testbed to an Intelligent Transport System (ITS) compatible facility, by implementing the key components of the ITS protocol stack. The designed platform is given freely to the experimenters who want to conduct experiments with Vehicular Ad-Hoc Networks (VANETs).

The different sub-applications needed to run on our platform for real world experiments are

• the basic GeoNetworking protocol core,
• the Basic Transport Protocol (BTP) as a means of a Transport layer protocol,
• a minimal facility layer used to generate traffic,
• a minimal implementation of the ITS management layer
• the mobility emulation environment

Our implementation realizes the ETSI TS 102 636-4-1 for Geographical addressing and forwarding for point-to-point and point-to-multipoint communications, providing media independent functionality. The address format specified in the standard is using a 64-bit representation, comprised of a bit for distinguishing whether the address is set automatically or manualy, a 4-bit field representing the ITS station type (roadside unit or a vehicle), a 1-bit indicator of whether the station is a private or public transport vehicle, a 10-bit field indicating the country code and finally a 48-bit field with the MAC address of the station. Since our implementation targets at giving open access to the experimenters to a working GeoNetworking protocol, we use a configuration file as an input to the GeoNetworking daemon. As it is specified in the standard, a GeoNetworking implementation should be configured through a Management Information Base (MIB). We consider that provisioning a MIB is beyond our initial goals, so we expose some of the MIB parameters through an external configuration file. All these aforementioned parameters can be setup through the
configuration file provided to the experimenter. Moreover, through the configuration file the experimenters can setup the communication parameters with the facility
and management layer, in case they want to use their own implementation, and the primary interface that will be used for communication. It is worth to mention that we currently support only Ethernet and WiFi interfaces, but we intend to extend it to using WiMAX and LTE interfaces.

The standard specifies six different types of packets;
1) Beacons

2) Single Hop Broadcast (SHB)

3) Topologically Scoped Broadcast (TSB)

4) GeoBroadcast/GeoAnycast

5) GeoUnicast

6) Location Service packets

Our implementation is able to support all GeoNetworking type of packets, except for the creation of the Location Service packets. These type of packets are triggered when no entry of the location of a specified host is found in the Location Table (LocT). Beacon packets are exchanged when a specific timer expires, which is reset each time that the GeoNetworking enabled station sends a packet of a different type. This feature explicitly defines that Beacon packets are sent only when no other communication involving the specific station takes place, so as for it to advertise its location. The rest type of packets are triggered when receiving an appropriate indication by the facility layer. TSB messages are used for broadcasting messages to nodes located more than one hop away. GeoBroadcast messages are used in the case of broadcasting/anycasting messages inside a geographical region, and are used mainly for road safety and event information applications implemented in
the application layer. Finally, GeoUnicast messages are used for transmitting messages to a specific host whose location information is already known.

Our daemon is written in a way that can scale in terms of heavy node network congestion. It is multi-threaded, using different threads for the process of beaconing, receiving packets from the network, receiving packet requests from the facility layer, receiving management messages from the management
layer, holding the location table and finally for invalidating expired entries in the LocT. The threads responsible for receiving messages are subsequently forked in the case that a transmission of a packet is required, either when the station is a transmitter and the network packet has been received from a higher layer or when the station is a forwarder of a packet already received from the Link Layer. Furthermore, since the GeoNetworking protocol is built so as to maximize the spreading of information in a geographical area, each packet might be retransmitted several times within it. Typical examples are the TSB and GeoBroadcast packets, where each receiving host will retransmit the packet if either the hop count is greater than zero or the host is inside a defined geographical area. For this reason, a duplicate packet detection mechanism has to be used. The packets which are meant to be retransmitted bear a sequence number (SN) incremented by one each time that such a packet is triggered.

By retaining an entry in the LocT with the last SN received from each neighbour, each host manages to keep track of the packets received per host. Using this kind of mechanism, GeoNetworking core is able to detect duplicate packets and discard them without any further processing. In order to accomplish true communication using location information, we used the definitions of a geographical area as defined in the ETSI EN 302 931 standard. The standard defines three different types of geographical areas; circular, rectangular and elliptical. Each one of the areas is defined using two points and the azimuth angle of the longest axis.
The GeoNetworking protocol is using this information in the cases of GeoBroadcast and GeoAnycast messages only and should totally be agnostic to these parameters; the protocol receives these parameters by means of a data request received from the facility layer.

Mobility Emulation Framework

Since the nodes comprising the testbed are static, we had to create an environment that would emulate the mobility at least at the GeoNetworking layer.
To this aim, we employed the gpsfake and the gpsd applications. The former is used for parsing a file with NMEA sentences and feeding this data directly to the latter. Gpsd is the state-of-the-art application in UNIX systems for parsing data from a GPS device. Any application can query a running gpsd instance for position information which is returned to it in a JSON format. 

Our Management layer is using this exact procedure; queries the gpsd daemon, parses the JSON file and creates the appropriate position update message for the GeoNetworking daemon. By using this approach, we have managed to emulate mobility in the Network layer of the NITOS nodes. The validity of our approach has been verified through our experimental framework where the nodes inside a geographical area only retransmit the GeoBroadcast packets in the case that they are all located inside it. However, action has to be taken in order to have a fully working mobility setup in the Link layer as well, so as the nodes defined under different geographical areas are outside each other’s coverage area. We are able to currently support this action manually by carefully selecting the nodes that comprise our experiment and change their transmission power. Using the ath5k driver we are able to configure the transmission power of the WiFi card with a value between 0-27dBm. Although this process takes place by issuing the appropriate commands, we are currently in the process of extending this kind of support by using UNIX debugfs filesystem. Directly from the management layer we will inform the wireless driver about the node’s position to appropriately adjust its transmission power, thus enhancing our
framework with a cross-layer approach.