geonetworking

ETSI ITS G5 GeoNetworking Stack

A part of ETSI ITS G5 stack including:

• Layer 7 Application: CAM-DENM
• Layer 6 Presentation: ASN.1 UPER
• Layer 5/4/3 Transport and Network: BTP / GeoNetworking (this library)
• Layer 2 Data link: udp2eth and utoepy
• Layer 1 Physical: see Hardware and Drivers

To test/simulate together with vehicle control models, use e.g. ITT. For a C++ ITS-G5, see vanetza.

GeoNetworking stack

A basic implementation of the ETSI GeoNetworking stack based on ‘Geographical addressing and forwarding for point-to-point and point-to-multipoint communications’ (ETSI EN 302 636-4-1) and ‘Transport Protocols; Sub-part 1: Basic Transport Protocol’ (ETSI EN 302 636-5-1).

Status

Sending and receiving Single Hop Broadcast and GeoBroadcast is supported. Forwarding of GeoBroadcast packets is on the wishlist. There are currently no plans for GeoUnicast or Security (for Security, try FITSec or vanetza).

The code was tested during ETSI ITS CMS 4 PlugTest in March 2015 and during Grand Cooperative Driving Challenge in May 2016.

One way to improve the quality is to set up an automated conformance testing using open-source TTCN-3 Eclipse Titan and ETSI ITS library.

Implementation

The implementation assumes that there is a separate entity, e.g. udp2eth or utoepy (which might be running on the same or on a separate machine) taking care of Data Link Layer communication. Communication between that entity and GeoNetworking stack is implemented via UDP at the moment (see LinkLayerUdpToEthernet). It is easy to change Link Layer entities by implementing a LinkLayer, one option could be to use Java bindings for libpcap to sniff and inject frames.

Implementation targets Java 7 at the moment, with some use of backported features from Java 8.

Building, Testing and Running

Maven is used as a build tool. Compile and install into the local maven repository:

mvn install

Then use geonetworking as a library, see examples in the uppertester, including sending CAM messages. Another example is in the Rendits Router.

Running standalone (mostly for development and testing)

Run with echo link layer

Compile and run command-line client:

sbt assembly
echo 4001 127.0.0.1:4000 | java -cp target/scala-2.10/geonetworking-assembly-0.1.0-SNAPSHOT.jar net.gcdc.UdpDuplicatorRunner
java -cp target/scala-2.10/geonetworking-assembly-0.1.0-SNAPSHOT.jar net.gcdc.BtpStdinClient --local-port 4000 --remote-address 127.0.0.1:4001 --no-ethernet-header --position 13.000,50.000 --btp-destination-port 2001

The first line compiles the source and assembles everything into one big “fat” jar.

The second line starts a fake UDP Link Layer entity that echoes packets back. Echo server listens on UDP port 4001, and forwards all packets to UDP port 4000.

The third line starts a command line client. The client assumes that Link Layer can be reached by sending payload to UDP port 4001, and expects that the payload from Link Layer can be received on UDP port 4000. The client gets BTP payload from stdin, and prints received BTP payload to stdout.

Run with utoepy as link layer

Run command-line client on top of utoepy bound to tap0:

sudo python udp2eth.py 4001 tap0
sudo python eth2udp.py 127.0.0.1:4000 tap0 --keep-own-frames
java -cp target/scala-2.10/geonetworking-assembly-0.1.0-SNAPSHOT.jar net.gcdc.BtpStdinClient --local-port 4000 --remote-address 127.0.0.1:4001 --no-ethernet-header --position 13.000,50.000 --btp-destination-port 2001

With --keep-own-frames, eth2udp will pick even the frames sent by udp2eth, so the sender will hear its own packets. TAP interfaces of multiple computers can be connected with OpenVPN, here is a diagram for that case:

           +--------+                    +---------+    +----------+   +-------+   +----------+    +---------+
           | BTP/GN |     127.0.0.1:4001 | udp2eth |    | Ethernet |   |OpenVPN|   | Ethernet |    | udp2eth |
 Stdin --->|        |------------------->|4001     |--->|  (tap0)  |   |Bridge |   |  (tap0)  |<---|     4001|...
           |        |                    +---------+    |          |   |       |   |          |    +---------+
           |        |                                   |          |<->|       |<->|          |               
           |        |                    +---------+    |          |   |       |   |          |    +---------+
           |        | 127.0.0.1:4000     | eth2udp |    |          |   |       |   |          |    | eth2udp |
Stdout <---|    4000|<-------------------|         |<---|          |   |       |   |          |--->|         |...
           |        |                    +---------+    +----------+   +-------+   +----------+    +---------+
           +--------+

Run with UdpBtpClient

Assuming that link layer is already started (see previous example), here’s how to start UDP BTP client. This client receives the payload of the BTP packet on a UDP port. The destination port for BTP prefixes the BTP payload in the UDP packet. To send CAM to BTP port 2001 (0x07D1), send the following UDP packet to the client: 07.D1.XX.YY.ZZ, where XXYYZZ is the BTP Payload (binary CAM message). Note that there is no way to specify destination port info for BTP, but it is usually not used anyway.

mvn package

java -cp target/geonetworking-0.0.1-SNAPSHOT-jar-with-dependencies.jar net.gcdc.BtpUdpClient --position 13.000,50.000 --local-udp2eth-port 4000 --remote-udp2eth-address 127.0.0.1:4001 --local-data-port 5003 --remote-data-address 192.168.1.23:1236 --mac-address 00:00:00:00:01:11

Related implementations

This implementation was inspired by DriveITS. A good C++ LGPL implementation is vanetza. Another open-source implementation, now outdated, is CarGeo6.

Acknowledgements

This implementation was partly developed within i-GAME project that has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 612035.

License

This GeoNetworking source code is released under Apache 2.0 license.