5G Sidelink Development

Overview of 5G SL Features

The current progress of EpiSci 5G sidelink is the full PHY implementation of the PSBCH (Physical Broadcast Channel). This channel is responsible for the synchronization of multiple UEs (mode 2). Our efforts were soley focused on mode 2, meaning a basestation is not present.

To establish a sidelink connection, synchronization information is broadcasted from a Synchronization Reference (SyncRef) UE and potentially decoded and accepted by other nearby UEs. By detecting the SLSS (SL Synchronization Signal), a nearby UE is able to extract critical pieces of information about the SyncRef UE. This synchronization procedure is required for establishing a 5G sidelink connection between multiple UEs.

Specifically, the information contained in the SLSS allows the nearby UE to synchronize with the SyncRef UE in both time and frequency. The SLSS is sent within the S-SSB frame and is made up of four main symbols. The S-SSB frame is broadcasted perioidically and made up of three main symbols: the PSBCH (and associated DMRS for decoding), S-PSS, and S-SSS. Each of these symbols contain relevant frequency and time information, which is extracted through correlation. Furthermore, these signals contain identifying information specific to the SyncRef UE to ensure proper connectivity. The S-SSS symbol can be analyzed for Reference Signal Received Power (RSRP) measurements for reporting current channel conditions.

Added Features:

• PSBCH (Broadcast Channel) TX/RX Procedures: For the PSBCH the preconfiguration was hard coded.
• PSSCH (Shared Channel) TX/RX Procedures: These procedures were added as brand new source code. Others have added SCI1/2 and PSSCH support in the PUSCH source code of the gNB. This makes sense for simplicity and to retrieve new bug fixes. Perhaps in the future we can update the PSSCH code to include these small if/else changes rather than an entire new source code files.
• SynchRef can broadcast PSBCH and we have tested up to 3 Nearby UEs (both in RFSIM and OTA) that can retrieve the PSBCH signal, decode it, and update their timing and frequency information to match the synchref.
• PSSCH data can be transmitted from the SyncRef to a synchronized nearby UE. We only tested a 2.6 and 3.3 gHZ scenario with 106 RBs. We hardcoded the configuration parameters in the pssch_ue source code. These ultimately should come from MAC FAPI interface.
• We implemented a basic multi-hop relay scenario, where the nearby UE will decode the received PSSCH data packet, if the packet has a destination ID different from itself, it will broadcast the PSBCH and then the PSSCH for other nearby UEs to receive. This was tested OTA with 3 N310 USRPs.

Test 5G Sidelink:

At the moment, we have three methods in which we test the detection and decoding of the SSB frame. 1) PSBCH Simulator, 2) RFSIMULATOR, 3) OTA URSP testing with B210s or N310s.

PSBCH Simulator:

This simulator is a standalone executable. It simply tests the generation of the SSB frame and the receiving (near by UE's) ability to decode and interpret this frame. The PSBCH simulator (nr_psbchsim) does not test any of the other PHY functionality (threat starting, OTA transmission, etc.). The simulator takes in a range of SNR values, which it will create an AWGN "channel" to apply to the TX buffer prior to memcopying the data into the RX buffer for decoding. These results were used as preliminary steps prior to moving to RFSIM and OTA testing. This simulator can be ran with the following:

$ cd openairinterface5g/cmake_targets
$ sudo LD_LIBRARY_PATH=$PWD/ran_build/build:$LD_LIBRARY_PATH ./ran_build/build/nr_psbchsim -s-11 -S9 -n 1 -R 106  2>&1 | tee psbchsim.log

Where in this case, we sweep through SNR -11 dB to 9 dB. Note, the nr_psbchsim executable is located in openairinterface5g/cmake_targets/ran_build/build. The successful decodes can be then plotted across the sweep. -n sets the number of trials to be conducted per SNR value and -R sets the number of resource blocks (RBs).

RF Simulator:

The commands for launch the RFSIM (SL version) are very similar to 5G standard CL inputs. We set one UE as the SyncRef UE with the --syncref flag; this UE will also be denoted as the SERVER in the case of RFSIM. A second UE can be launched, and this (nearby) UE is the client. The commands to launch the RFSIM in sidelink mode 2 are shown below: SSH to Machine 1:

cd openairinterface5g/cmake_targets/ran_build/build
sudo -E RFSIMULATOR=server $HOME/openairinterface5g/cmake_targets/ran_build/build/nr-uesoftmodem --sync-ref --rfsim --sl-mode 2 --rbsl 106 --SLC 2600000000 --rfsimulator.serverport 4048 --log_config.global_log_options time,nocolor 2>&1 | tee ~/syncref.log

SSH to Machine 2:

cd openairinterface5g/cmake_targets/ran_build/build
sudo -E RFSIMULATOR=127.0.0.1 $HOME/openairinterface5g/cmake_targets/ran_build/build/nr-uesoftmodem --rfsim --sl-mode 2 --rbsl 106 --SLC 2600000000 --rfsimulator.serverport 4048 --log_config.global_log_options time,nocolor 2>&1 | tee ~/nearby.log

OTA USRP Testing:

The OTA USRP testing was conducted using two N310s and two B210s. At the moment, we can successfully run a combination of different USRP types. We have tested up to a 3 UE scenario, where one N310 is the syncref, one B210 is nearby and one N310 is nearby. One of our internal B210s is not performing well. The following commands are OTA USRP commands used for Sidelink. The following UHD commands will verify the USRP is ready for deployment and provide you with the necessary information, such as the serial and addr values.

$ uhd_find_devices # This will find all USRPs 
$ uhd_usrp_probe # This will probe the USRP and will ensure the status is ready

N310 USRPs:

SSH to Machine 1. Note, the addr field may need to be changed to match the USRPs

$ cd ~/openairinterface5g/cmake_targets
2.6 GHz Test:
$ sudo -E ./ran_build/build/nr-uesoftmodem --sl-mode 2 --sync-ref --rbsl 52 --numerology 1 --band 38 --SLC 2600000000 --ue-txgain 0 --usrp-args "type=n3xx,addr=192.168.10.2,subdev=A:0,master_clock_rate=122.88e6" --log_config.global_log_options time,nocolor 2>&1 | tee ~/tx.log
3.3 GHz Test:
$ sudo -E ./ran_build/build/nr-uesoftmodem --sl-mode 2 --sync-ref --rbsl 52 --numerology 1 --band 38 --SLC 3300000000 --ue-txgain 0 --usrp-args "type=n3xx,addr=192.168.10.2,subdev=A:0,master_clock_rate=122.88e6" --log_config.global_log_options time,nocolor 2>&1 | tee ~/tx.log

SSH to Machine 2. Note, the addr field may need to be changed to match the USRPs

$ cd ~/openairinterface5g/cmake_targets
2.6 GHz Test:
$ sudo -E ./ran_build/build/nr-uesoftmodem --sl-mode 2 --rbsl 52 --numerology 1 --band 38 --SLC 2600000000 --ue-rxgain 20 --usrp-args "type=n3xx,addr=192.168.20.2,subdev=A:0,master_clock_rate=122.88e6" --log_config.global_log_options time,nocolor 2>&1 | tee ~/rx.log 
3.3 GHz Test:
$ sudo -E ./ran_build/build/nr-uesoftmodem --sl-mode 2 --rbsl 52 --numerology 1 --band 38 --SLC 3300000000 --ue-rxgain 20 --usrp-args "type=n3xx,addr=192.168.20.2,subdev=A:0,master_clock_rate=122.88e6" --log_config.global_log_options time,nocolor 2>&1 | tee ~/rx.log

B210 USRPs:

SSH to Machine 1. Note, the serial field may need to be changed to match the USRPs:

$ cd ~/openairinterface5g/cmake_targets
$ sudo LD_LIBRARY_PATH=$PWD/ran_build/build:$LD_LIBRARY_PATH \
  ./ran_build/build/nr-uesoftmodem -E --sl-mode 2 --rbsl 50 --numerology 1 \
            --band 38 -C 2600000000 \
            --usrp-args "type=b200,serial=3150361,clock_source=external" \
            --nokrnmod 1 2>&1 | tee ~/rx.log

SSH to Machine 2. Note, the serial field may need to be changed to match the USRPs:

$ cd ~/openairinterface5g/cmake_targets
$ sudo LD_LIBRARY_PATH=$PWD/ran_build/build:$LD_LIBRARY_PATH \
  ./ran_build/build/nr-uesoftmodem -E --sl-mode 2 --rbsl 50 --numerology 1 \
    --band 38 -C 2600000000 --sync-ref \
    --usrp-args "type=b200,clock_source=external,serial=3150384" \
    --nokrnmod 1 2>&1 | tee ~/tx.log

Preliminary Test Script:

Running 5G Sidelink Mode 2 Tests

To launch tests, a python script run_sl_test.py is provided. It provides 2 test modes, RFSIM or OTA via USRPs. There are two preconfigured scenarios for the RFSIM test and four preconfigured scenarios for the USRP test. The configurations of different tests are specified in sl_net_config.json.

RFSim Preconfigured Scenarios:

• Net 1 is a two node scenario with one SyncRef and one nearby UE. The UEs are configured with 106 resource blocks and carrier frequency of 2.6 GHz.
• Net 2 is a three node scenario with one SyncRef UE and two nearby UEs. The UEs are configured with 52 resource blocks and carrier frequency of 2.6 GHz.

USRP Preconfigured Scenarios:

There are four tests scenarios defined for USRP: net_0, net_1, net_2, and net_3. All are configured with 52 resource blocks. The tx gain for all transmitting UEs is set to 0. In the net_0 scenario the rx_gain is 90, in all other preconfigured scenarios the UEs rx gain is 80. net_0, net_1 and net_2 are two nodes scenarios with 1 SyncRef and 1 nearby UE.

• Net_0 is configured for testing the 2 node scenario with B210 USRPs.
• Net_1 is configured for testing the 2 node scenario with N310 USRPs.
• Net_2 is configured for testing the 2 node scenario where the SyncRef is deployed on an N310 and the nearby UE is deployed on a B210 USRP.
• Net 3 is a three node scenario with one SyncRef UE and two nearby UEs. The SyncRef UE is deployed on an N310 and one nearby UE is deployed on an N310 and the other is deployed on a B210. The scenario is configured with carrier frequency of 2.6 GHz.

The python run script and configurations files are located under ~/openairinterface5g/ci-scripts.

The following examples demonstrate three node (1 SycnhRef, 2 Nearby UEs) scenarios:

Launching RFSIM Test

To run RFSIM, the --test rfsim flag is provided to the test script. In this example, scenario 2 is used (specified by the --net 2 flag).

cd ~/openairinterface5g/ci-scripts
python3 run_sl_test.py --test rfsim --net 2

Launching in USRP Test

The following is an example to run the nearby UE on a remote machine. The SyncRef UE is launched on the current machine, and a single nearby UE is launched on the machine specified by the --host and --user flags. The -r will enable this simulation to be repeated three times. To run USRP test, the --test usrp flag is provided to the test script. In this example, Scenario 1 (default) is used, as no --net flag is provided.

cd ~/openairinterface5g/ci-scripts
python3 run_sl_test.py --user account --host 10.1.1.68 -r 3 --test usrp

The following is an example to run just the Sidelink Nearby UE on a remote machine. By specifying -l nearby, only the nearby UE will be launched on the machine specified by the --host and --user flags. The -r will enable this simulation to be repeated two times.

python3 run_sl_test.py -l nearby --user account --host 10.1.1.68 -r 2 --test usrp

See --help for more information. All results will be logged into log files in home folder by default. The file name will match the argument of the -l flag. In the example, the following files will be created after the test has completed.

ls ~/*.log
~/syncref1.log
~/nearby2.log
~/nearby3.log

MR Status:

The current MR status and procedure is as follows. EpiSci has their own internal master branch, and to keep that branch up to date with Eurecom's develop branch we have created a sort of "master" MR. This MR (MR-2200) will continuously be kept up to date with EpiSci SL development and Eurecom's develop branch. The table below will define, enumerate, and describe the progress of each ongoing MR at EpiSci for SL development:

MR #	Status	Description
MR2215	In Review	Clean up of SL mode variables to use ENUMs and Booleans where necessary
MR2216	In Review	Clean up of existing 5G PSS and SSS functions
MR2201	In Reveiw	MIB MAC stub functions (ASN1 encoding/decoding) or MIB
MR2217	In Work	Addition of new files for SL source code; specifically, PSS, SSS and PSBCH TX and RX procedures
MR2204	In Work	Sidelink Initialization Synchronization