Introduction

The purpose of this software is to provide an interface for transmitting LTE-V2X messages on the PC-5 cellular sidelink in Mode 4. Ideally, users would just need to provide the hexadecimal transport block and a few parameters and this tool would transmit them over a provided SDR.

This software is based on the work of others. Here is the approximate timeline:

• First, the majority of the code and dependencies utilize the srsRAN 4G project.
• Second, using srsRAN, (being called srsLTE at the time), Eckermann created a cv2x_traffic_generator tool.
  • His contributions included custom ue_sl code that was buried in srsRAN's source and the cv2x_traffic_generator.c.
  • His work can be cited as:

  F. Eckermann, C. Wietfeld, "SDR-based open-source C-V2X traffic generator for stress testing vehicular communication", In 2021 IEEE 93rd Vehicular Technology Conference (VTC-Spring), Helsinki, Finland, April 2021.

  • Published paper
• Third, using Eckermann's work, Twardoku updated the code to work on the version of srsRAN current to him.
  • Published paper

Taking Twardoku's source, I have updated the ue_sl to be once again compatible with the 2023 version of srsRAN (as far as I can tell).

Both of these tools claimed to be transmitting according to the rules of the V2X protocols, but were filling the transport blocks with random information. The idea then was to modify these tools to instead include meaningful information in the transport blocks.

Hardware requirements

• An SDR capable of running srsRAN. We used an EttusResearch USRP X410.

Prerequisites

Install UHD or other appropriate SDR driver software.

Build and install srsRAN. The key detail is that srsRAN libraries (the .so and .a files) need to appear in /usr/local/lib/ and srsRAN headers (the .h files) need to appear in /usr/include/srsran/ because that is where my makefile looks for them.

Compiling

One you have fulfilled the prerequisites:

git clone https://github.com/NET-BYU/cv2x-msg-tx
cd cv2xc-msg-tx
make build

This will create an executable called transmitter in build/

Typical Usage

This project is in very early stages, so many of the parameters that the interface provides are ignored, and default hard-coded values are used instead.

Some typical commands I've used to run this in the past are:

./build/transmitter -m abcd -a "clock_source=gpsdo,time_source=gpsdo"

./build/transmitter -m abcd -a "clock_source=external,time_source=internal"

Current issues

This project is at a state where it will transmit energy over the spectrum. What is being transmitted matches the duration, bandwidth, channel, and frequency as what our reference OBU transmits. The two messages even look similar to each other on a spectrogram.

Here is a picture of the spectrogram of our OBU's transmissions:

Here is a picture of the spectrogram of the transmissions generated by this software:

We have tried two different configurations of transmitters and receivers:

Configuration 1:

• USRP X410, set to external GPS clock as transmitter
• Various off-the-shelf RSUs as receivers (programmed to forward any received messages over UDP to a local computer on the network)
• HackRF transmitting GPS signalling information for the two devices

We suspect this configuration struggles with timing, since our X410 never indicates that it indeed has a GPS lock. We've modified our HackRF One with a Nooelec Tiny TXCU P22 to give it a more accurate GPS signal, which was enough to convince our OBU/RSUs to behave, but may not be enough for the X410. We've considered attaching our Rubidium oscillator to the "CLKIN" port of the HackRF One, with the hope that perhaps the X410 could get a lock that way.

Configuration 2:

• USRP B200mini set to an external clock as transmitter
• USRP B200mini set to an external clock as receiver (using the srsRAN pssch_ue example script)
• Rubidium oscillator as external clock source

Neither of these configurations were able to achieve a valid reception of our transmission. Configuration 2, while likely having a correct timing configuration, introduced the secondary variable of the pssch_ue script, which we haven't been able to successfully use.

srsRAN's example script, pssch_ue, reports any SCI (sidelink control information) headers that it decodes as well as the contents of any transport blocks it decodes. This script found SCI messages... but none of them matched what we were attempting to transmit, so we assumed it was pulling them out of the background noise. This seems to indicate that something might be wrong with how we are encoding our SCI.