openairinterface5G merge requestshttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests2024-02-26T16:03:42Zhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/1625Draft: 5G NTN specific changes from ESA 5G-GOA project2024-02-26T16:03:42ZThomas SchlichterDraft: 5G NTN specific changes from ESA 5G-GOA project5G-NTN specific changes from ESA project 5G-GOA:
- PHY Layer
- Extend OAI rf-simulator to support simulation of long delay
- Consider timing relation for UL scheduling at gNB
- Disabling HARQ at gNB and UE
- MAC Layer
- Adapting ...5G-NTN specific changes from ESA project 5G-GOA:
- PHY Layer
- Extend OAI rf-simulator to support simulation of long delay
- Consider timing relation for UL scheduling at gNB
- Disabling HARQ at gNB and UE
- MAC Layer
- Adapting Uplink timing advance and RA procedure
- RLC Layer
- Disabling HARQ-ARQ interaction
- Increased ARQ buffer size to cope with large GEO delay
- Increased maximum Sequence Number value
- PDCP Layer
- Increased discard timer for SDU buffer
- Increased reordering timer for PDU buffer
- Increased size of PDU buffer
- RRC Layer
- Increased selected timers (T300, T301, T311)
Project homepage: https://artes.esa.int/projects/5ggoa
Additional command line options:
| Option | Description | Parameter |
|------------------|------------------------------------------|------------------------------------------------------|
| -P | rf-simulator propagation delay | in samples |
| --no-harq | Disable HARQ | |
| --gnb_k2 | gNB k2-offset | in slots |
| --ue_k2 | NR_UE k2-offset | in slots |
| --ul_sched_f | Extend gNB UL scheduling window | in frames (must be power of two) |
| --ue_slot_Rx_Tx | Extend NR-UE gNB DURATION_RX_TO_TX | in slots |
| --ntn-trs | t_Reassembly timer enum | 0 to 30 |
| --ntn-trs-offset | Offset to be added to t_Reassembly timer | in ms |
| --ntn-rtd | Round trip delay | in ms but has to be matched with the one given by -P |
| --ntn-trd | t_Reordering timer enum | 0 to 35 |
| --ntn-trd-offset | Offset to be added to t_Reordering timer | in ms |
Execution example for this scenario:
- FDD
- 30 kHz SCS
- 10 MHz BW
- 260 ms one-way propagation delay
- 520 ms RTT
- k2_offset = 1040 slots
At gNB:
`RFSIMULATOR=server sudo -E ./ran_build/build/nr-softmodem -O ../targets/PROJECTS/GENERIC-LTE-EPC/CONF/gnb.band66.tm1.24PRB.usrpx300.conf --noS1 --nokrnmod --phy-test --rfsim --no-harq -P 3993600 --gnb_k2 1040 --ul_sched_f 64 --ntn-trs 10 --ntn-trs-offset 200 --ntn-rtd 230 --ntn-trd 15 --ntn-trd-offset 200`
At UE:
`RFSIMULATOR=127.0.0.1 sudo -E ./ran_build/build/nr-uesoftmodem --noS1 --nokrnmod --phy-test --rfsim --no-harq -P 3993600 -A 7987200 --ue_slot_Rx_Tx 1040 --ue_k2 1040 --ntn-trs 10 --ntn-trs-offset 200 --ntn-rtd 230 --ntn-trd 15 --ntn-trd-offset 200`https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/1799Draft: Remove unused Makefiles from project2024-03-15T07:11:32ZRúben Soares SilvaDraft: Remove unused Makefiles from projectRemove Makefiles from project, inline with the L2/L3 Improvements underway.
@lthomas @Cedric.Roux @raymond.knopp @mirazabal @schmidtrRemove Makefiles from project, inline with the L2/L3 Improvements underway.
@lthomas @Cedric.Roux @raymond.knopp @mirazabal @schmidtrCédric Rouxcedric.roux@eurecom.frCédric Rouxcedric.roux@eurecom.frhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/1911Preparatory work for NR DL 4-layer MIMO at gNB2024-03-27T14:21:24ZFrancesco ManiPreparatory work for NR DL 4-layer MIMO at gNBwith 4 layers, MCS is limited to 9, beyond that the connection breakswith 4 layers, MCS is limited to 9, beyond that the connection breaksREVIEW_IN_PROGRESSLuis Pereiralpereira@allbesmart.ptLuis Pereiralpereira@allbesmart.pthttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/1927Draft: Resolve "LDPC Decoder Enhancements"2024-03-19T08:13:10ZSebastian WagnerDraft: Resolve "LDPC Decoder Enhancements"Closes #602Closes #602REVIEW_CAN_STARThttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2111Draft: Terrestrial inter gNB-DU handover from ESA 5G-LEO project2023-12-21T15:40:10ZDaniel AndradeDraft: Terrestrial inter gNB-DU handover from ESA 5G-LEO projectCompletion / implementation of the following messages / procedures:
- Send and receive the measurement configuration
- RSRP measurement of neighboring cells based on SSB
- Send and receive the measurement report
- Implementation of proce...Completion / implementation of the following messages / procedures:
- Send and receive the measurement configuration
- RSRP measurement of neighboring cells based on SSB
- Send and receive the measurement report
- Implementation of procedures to process the measurement report
- UE Context Setup Request
- UE Context Setup Response
- Bearer Context Modification
- UE Context Modification Request
- Downlink Data Delivery status
- UE Context Modification Response
- UE handling signals from/to 2 gNB-DUs in RF Simulator
- Implementation of resynchronization procedures
- Trigger CFRA
- RRC Reconfiguration Complete
- UE Context Release Command
- UE Context Release Complete
The inter gNB-DU handover can be tested in the RFSim by following these steps:
Since the RSRP measured in the active and neighboring cell is exactly the same in RFSim, first we apply the following patch ([Trigger_just_1_handover.patch](/uploads/52aeb2205f46374ce13727ff0a3fd43e/Trigger_just_1_handover.patch)), to decrease the RSRP measured in the active cell by 10 dB (just to force the handover):
Then just run the following commands:
```
################
# Run OAI-CN5G #
################
cd ~/oai-cn5g
docker compose up -d
```
```
################
# Build gNB/UE #
################
cd ~/openairinterface5g
source oaienv
cd cmake_targets/
./build_oai -w SIMU --nrUE --gNB --build-lib "nrscope" --ninja -C
```
```
##################
# Run OAI-gNB-CU #
##################
cd ~/openairinterface5g
source oaienv
cd cmake_targets/ran_build/build
sudo RFSIMULATOR=127.0.0.1 ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/cu_gnb_2multDUs.conf --rfsim --sa
```
```
####################
# Run OAI-gNB-DU 0 #
####################
cd ~/openairinterface5g
source oaienv
cd cmake_targets/ran_build/build
sudo RFSIMULATOR=127.0.0.1 ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/du_gnb_pci0.conf --rfsim --sa
```
```
##############
# Run OAI-UE #
##############
cd ~/openairinterface5g
source oaienv
cd cmake_targets/ran_build/build
sudo RFSIMULATOR=server ./nr-uesoftmodem -r 106 --numerology 1 --band 78 -C 3619200000 --nokrnmod --rfsim --sa --uicc0.imsi 001010000000001
```
```
####################
# Run OAI-gNB-DU 1 #
####################
cd ~/openairinterface5g
source oaienv
cd cmake_targets/ran_build/build
sudo RFSIMULATOR=127.0.0.1 ./nr-softmodem -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/du_gnb_pci1.conf --rfsim --sa
```https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2166nr pdcp: add --pdcp-drop option to drop packets in PDCP instead of RLC2023-12-06T15:23:32ZCédric Rouxcedric.roux@eurecom.frnr pdcp: add --pdcp-drop option to drop packets in PDCP instead of RLCThis only works in monolithic. F1 split to be done later, it's a bit more
complicated.
If the drop is done by PDCP, no drop will happen in RLC and it might happen that memory usage will grow in RLC, in which case there will be some warn...This only works in monolithic. F1 split to be done later, it's a bit more
complicated.
If the drop is done by PDCP, no drop will happen in RLC and it might happen that memory usage will grow in RLC, in which case there will be some warnings at runtime.REVIEW_CAN_STARThttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2181ULSCH power computation2023-11-02T15:16:41ZRoberto Louro MaguetaULSCH power computationWhen the UE does not transmit the ULSCH, the measured power values at gNB in develop are:
```
[NR_PHY] PUSCH not detected in 166.17 (232,309,50)
[NR_PHY] PUSCH not detected in 166.17 (240,309,50)
```
where:
```
LOG_I(NR_PHY,
"...When the UE does not transmit the ULSCH, the measured power values at gNB in develop are:
```
[NR_PHY] PUSCH not detected in 166.17 (232,309,50)
[NR_PHY] PUSCH not detected in 166.17 (240,309,50)
```
where:
```
LOG_I(NR_PHY,
"PUSCH detected in %d.%d (%d,%d,%d)\n",
frame_rx,
slot_rx,
dB_fixed_x10(pusch_vars->ulsch_power_tot),
dB_fixed_x10(pusch_vars->ulsch_noise_power_tot),
gNB->pusch_thres);
```
This does not make sense as everything is noise and therefore `ulsch_power_tot` should be approximately equal to `ulsch_noise_power_tot`. With this MR, we get LOGs like these:
```
[NR_PHY] PUSCH not detected in 104.17 (307,307,50)
[NR_PHY] PUSCH not detected in 105.17 (310,312,50)
[NR_PHY] PUSCH not detected in 106.17 (310,313,50)
[NR_PHY] PUSCH not detected in 106.17 (313,316,50)
[NR_PHY] PUSCH not detected in 107.17 (308,304,50)
[NR_PHY] PUSCH not detected in 107.18 (308,309,50)
```
In the develop version, `ul_ch_estimates` is used to calculate the power. However, when the ULSCH is not received, the `ul_ch_estimates` is just noise that has been shifted, and therefore gives a low value. In this MR, the total ULSCH power is calculated using the same method that is used to calculate noise power, i.e., directly using the `rxdataF`. In addition to the values presented above relative to when the UE does not transmit anything, the values of the method used in this MR are approximately equal to the values obtained in develop, when there is ULSCH.REVIEW_CAN_STARTThomas Laurentlaurent.thomas@open-cells.comThomas Laurentlaurent.thomas@open-cells.comhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2196NR UE Rx Symbol-wise Processing2023-11-09T00:26:29ZSakthivel VelumaniNR UE Rx Symbol-wise ProcessingMajor changes:
1. UE_thread() has been modified to read one OFDM symbol, do DFT and process the signal to generate intermediate results. At the last symbol, the remaining processing for the corresponding channel is performed.
2. nr_slot_...Major changes:
1. UE_thread() has been modified to read one OFDM symbol, do DFT and process the signal to generate intermediate results. At the last symbol, the remaining processing for the corresponding channel is performed.
2. nr_slot_fep() has been altered and renamed to nr_symbol_fep(). rxdata and rxdataF buffers are in stack now instead of heap. The fractional CP removal is implicitly performed while reading samples from the radio. This eliminates the need for memcpy if the starting address is not aligned.
4. Removed nr_slot_fep_init_sync(). By moving the CP removal outside of nr_symbol_fep(), there no need for special function of initial sync. So initial sync also uses nr_symbol_fep().
3. Modified PDSCH, PDCCH, PBCH, CSI & PTRS functions to accommodate the symbol based processing design. Contains both functional modifications and clean-ups.
Minor changes:
1. Clean-up DLSCH functions.
2. Using const for function inputs as much as possible.
Untested changes:
CSI, PTRS and PRS modifications are not tested yet.
The following chart shows the flow of PDSCH implementation and input and output of modified functions.
[new_schema_for_mr.pdf](/uploads/44d3099ac4b8d74df49dd3b9f262fd3d/new_schema_for_mr.pdf)REVIEW_IN_PROGRESShttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/22005G Sidelink Development2023-11-21T08:44:57ZMelissa5G 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 ...## 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:
```bash
$ 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:
```bash
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:
```bash
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.
```bash
$ 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
```bash
$ 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
```bash
$ 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:
```bash
$ 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:
```bash
$ 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 SynchronizationMelissaMelissahttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2203DL-MMSE2024-02-14T17:25:13ZRoberto Louro MaguetaDL-MMSE_This MR is based on MR https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2185_
- Fix rxdataF_comp size in nr_rx_pdsch() function
- Improvements in nr_dlsch_channel_compensation() function
- Noise power estimation for DL..._This MR is based on MR https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2185_
- Fix rxdataF_comp size in nr_rx_pdsch() function
- Improvements in nr_dlsch_channel_compensation() function
- Noise power estimation for DL at UE side
- MMSE computation for DL at UE side
Theoretically, MMSE is better than ZF for low SNR, and then its performance converges as SNR increases. The results on the phy-simulators confirmed this. The gain for a frequency selective channel was not as great as for an AWGN channel. This probably happened because of the DCI, as the following LOGs appeared many times:
[PHY] DCI false positive. Dropping DCI index 0. Mismatched bits: 284/864. Current DCI threshold: 205
**Some results obtained in the phy-simulators were:**
_AWGN channel_
`sudo LD_LIBRARY_PATH=. ./nr_dlsim -n10000 -s4 -x2 -y2 -z2 -e2`
- ZF: `Eff Throughput 50.47`
- MMSE: `Eff Throughput 92.84`
`sudo LD_LIBRARY_PATH=. ./nr_dlsim -n10000 -s9.7 -x2 -y2 -z2`
- ZF: `Eff Throughput 53.63`
- MMSE: `Eff Throughput 94.01`
`sudo LD_LIBRARY_PATH=. ./nr_dlsim -n10000 -s16.6 -x2 -y2 -z2 -e16`
- ZF: `Eff Throughput 78.88`
- MMSE: `Eff Throughput 81.37`
_Frequency selective channel_
`sudo LD_LIBRARY_PATH=. ./nr_dlsim -n10000 -s7 -x2 -y2 -z2 -gR -e2`
- ZF: `Eff Throughput 70.78`
- MMSE: `Eff Throughput 82.81`REVIEW_IN_PROGRESShttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2292NR gNB MAC further improvements for scheduling in common search space2024-03-19T17:39:22ZFrancesco ManiNR gNB MAC further improvements for scheduling in common search spaceThis MR follows !2280 and extends the improvements to RA and ULSCH in case we schedule in common search spaceThis MR follows !2280 and extends the improvements to RA and ULSCH in case we schedule in common search spaceREVIEW_IN_PROGRESShttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2385Draft: L1 and L3 measurements2024-03-27T11:40:14ZRoberto Louro MaguetaDraft: L1 and L3 measurements* A3 event configuration in gNB
* L1 and L3 measurements for the active and neighboring cells
* Implementation of procedures related to MeasurementReport* A3 event configuration in gNB
* L1 and L3 measurements for the active and neighboring cells
* Implementation of procedures related to MeasurementReportREVIEW_CAN_STARTThomas Laurentlaurent.thomas@open-cells.comThomas Laurentlaurent.thomas@open-cells.comhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2386Decrement number of PDU sessions on PDU session release2023-10-26T10:08:32ZVijaykumar ChadachanDecrement number of PDU sessions on PDU session releaseREVIEW_IN_PROGRESSVijaykumar ChadachanVijaykumar Chadachanhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2411Simple and generic trx_write support of out of time order requests2024-03-27T08:15:51ZThomas Laurentlaurent.thomas@open-cells.comSimple and generic trx_write support of out of time order requestsThis MR creates a new RF board write function that handle out of order slots
we may use it also in the gNB laterThis MR creates a new RF board write function that handle out of order slots
we may use it also in the gNB laterREVIEW_IN_PROGRESShttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2412Adding pathloss models as described in 3GPP TR 38.901 v16.1.02023-10-26T10:13:48ZSreeshma ShivAdding pathloss models as described in 3GPP TR 38.901 v16.1.0* In RF Simulator, user can manually set the distance between the UE and gNB, as well as the path-loss. However, changes in distance do not cause any changes to the path-loss.
* Implementing the path-loss models as proposed in 3GPP TR 38...* In RF Simulator, user can manually set the distance between the UE and gNB, as well as the path-loss. However, changes in distance do not cause any changes to the path-loss.
* Implementing the path-loss models as proposed in 3GPP TR 38.901 V16.1.0 to make the increase in distance mimic real-life scenarios.
* The user now has the option to select one of the 13 path-loss models as mentioned in the above document.
* The user also has the option to change various parameters such as average building height, height of the UT, height of BS, average width of the street using telnet server.
* The path-loss model can be applied both at the up-link and down-link individually.
* The path-loss calculated by different path-loss models cannot be applied directly to the channel model, since there's no notion of rx gain at the UE. In order to make use of the complete functionality of these code changes, rx tx gain along with LNA should be implemented within OAI.
test commands:
gNB: `sudo ./nr-softmodem --gNBs.[0].min_rxtxtime 6 --rfsim --sa -E --telnetsrv --rfsimulator.options chanmod -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/gnb.sa.band78.fr1.106PRB.usrpb210_AWGN.conf`
UE: `sudo ./nr-uesoftmodem --rfsimulator.serveraddr 127.0.0.1 -r 106 --numerology 1 --band 78 -C 3619200000 --nokrnmod --rfsim --sa -E --ue-fo-compensation --telnetsrv --rfsimulator.options chanmod -O ../../../targets/PROJECTS/GENERIC-NR-5GC/CONF/ue_AWGN.conf`
telnet commands:
1. `telnet 0 9090`
2. `channelmod modify 1 pathloss_model RMa_LOS` //to select the pathloss model
3. `rfsimu setdistance rfsimu_channel_ue0 100` //to set distance
4. `channelmod modify 1 hBS 125` //to set base station height as 125REVIEW_CAN_STARTSreeshma ShivSreeshma Shivhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2437first version of the NRPPA2024-03-22T12:16:20ZAdeel Malikfirst version of the NRPPAthe first version of the NRPPA with the focus on the following UL TDOA positioning-related messages
Positioning Information Transfer
- POSITIONING INFORMATION REQUEST
- POSITIONING INFORMATION RESPONSE
- POSITIONING INFORMATION FAILURE...the first version of the NRPPA with the focus on the following UL TDOA positioning-related messages
Positioning Information Transfer
- POSITIONING INFORMATION REQUEST
- POSITIONING INFORMATION RESPONSE
- POSITIONING INFORMATION FAILURE
- Positioning Information Update
- POSITIONING ACTIVATION REQUEST
- POSITIONING ACTIVATION RESPONSE
- POSITIONING ACTIVATION FAILURE
- Positioning Deactivation
TRP Information Transfer
- TRP INFORMATION REQUEST
- TRP INFORMATION RESPONSE
- TRP INFORMATION FAILURE
Measurement Information Transfer
- MEASUREMENT REQUEST
- MEASUREMENT RESPONSE
- MEASUREMENT FAILURE
- Measurement Update
- Measurement Report
- Measurement Abort
- Measurement Failure IndicationFlorian KaltenbergerFlorian Kaltenbergerhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2438PSBCH RX,TX and SLSS SEARCH procedures2024-03-19T07:37:48ZRaghavendra DinavahiPSBCH RX,TX and SLSS SEARCH procedures- PSBCH RX/TX and SLSS search procedures according to 3GPP Specs 38.211, 38.212 Rel16
- PSBCH simulator used to validate TX/RX phy processing and SLSS SEARCH functionality
* to test the PSBCH TX and RX functionality - ./nr_psbchsim...- PSBCH RX/TX and SLSS search procedures according to 3GPP Specs 38.211, 38.212 Rel16
- PSBCH simulator used to validate TX/RX phy processing and SLSS SEARCH functionality
* to test the PSBCH TX and RX functionality - ./nr_psbchsim
* option 'I' to trigger sidelink search ex ./nr_psbchsim -I
* option 'T' to change timing in the SL-MIB ex ./nr_psbchsim -T 5 18 -I
* option 's' to change the SLSS idREVIEW_IN_PROGRESSFrancesco ManiFrancesco Manihttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2458Add 5G MAC slice with NVS algo & RC ran func2024-03-25T15:36:33ZChieh-Chun ChenAdd 5G MAC slice with NVS algo & RC ran func- Fix ngap to save correct SD
- Fix missing guami while handle initial context setup reuqest in RRC
- Add NVS slicing algorithm to schedule slice (NVS algo) for RBs before schedule UEs (pf algo)
- Add RC ran func to associate UEs to the ...- Fix ngap to save correct SD
- Fix missing guami while handle initial context setup reuqest in RRC
- Add NVS slicing algorithm to schedule slice (NVS algo) for RBs before schedule UEs (pf algo)
- Add RC ran func to associate UEs to the corresponding slice based on nssai infoRobert SchmidtRobert Schmidthttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2485Create nrUE network interface from SDAP2024-03-28T03:10:24ZSakthivel VelumaniCreate nrUE network interface from SDAP### Changes
1. Move tunnel interface read thread to SDAP for gNB (noS1) and UE (noS1 and SA).
2. Hold tunnel interface socket fd in SDAP entity instead of global variable.
3. Handle UE tunnel interface creation and IP configuration from ...### Changes
1. Move tunnel interface read thread to SDAP for gNB (noS1) and UE (noS1 and SA).
2. Hold tunnel interface socket fd in SDAP entity instead of global variable.
3. Handle UE tunnel interface creation and IP configuration from NAS thread in noS1 and SA modes.
4. Modified UE tunnel interface naming scheme. Additional PDU sessions get `oaitun_ue<id>p<pdusession_id>`.REVIEW_CAN_STARTCédric Rouxcedric.roux@eurecom.frCédric Rouxcedric.roux@eurecom.frhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2504CI: use iperf3, refactor Iperf_Module2024-03-28T06:59:12ZJaroslava FiedlerovaCI: use iperf3, refactor Iperf_ModuleMain improvements:
- simplification of the CI iperf testing framework - rework and cleanup of the Iperf_Module function, remove redundant functions
- introduce TCP target rate check - add TCP tests with rate check to SA-B200 and SA-AW2S...Main improvements:
- simplification of the CI iperf testing framework - rework and cleanup of the Iperf_Module function, remove redundant functions
- introduce TCP target rate check - add TCP tests with rate check to SA-B200 and SA-AW2S pipelines
- improve analysis of the iperf3 test reports (analysis from json reports, check receiver report for each test)
- undeploy gNB/UE after each OTA test run - should reduce interference caused by UE which remained ON after the test
TBD:
- [ ] RAN-LTE-TDD-LTEBOX and RAN-LTE-FDD-LTEBOX: check TCP rate?
- [ ] RAN-L2-Sim-Test-4G - lower tested UL bitrate?
- [x] recheck SABOX target TCP
- E1+F1 testcase, we can set higher TCP target rates (UL: 8 -> 15 Mbps, DL: 20 -> 30 Mbps)
- [ ] recheck AW2S target TCP
- we can set higher TCP target rates (UL: 1 -> 2 Mbps/UE, DL: 4 -> 6 Mbps/UE)
- [x] RAN-RF-Sim-Test-4G --> Could not analyze from server log
- [x] FEMBMS does not work with iperf3 because of the control channel (TCP messages) during test init
- [x] log collection from the test - to be fixed
- [x] undeploy gNB/UE after each testcase
- SA-AERIAL-CN5G
- SA-OAIUE-CN5G
- SA-AW2S-CN5G
- LTE-TDD-2x2
- LTE-FDD-OAIUE-OAICN4G
- [x] `--get-server-report` for TCP and BIDIR testcases - could be skipped?
- [x] Possibility to use JSON reports from iperf3 for all test cases? --> not possible with UDP iperf3 version 3.9
- `iperf 3.9 (cJSON 1.7.13)`
- TCP - check sender/receiver "bits_per_second"
- BIDIR - check sender/receiver UL/DL "bits_per_second"
- UDP - receiver "bits_per_second" reports 0
- [x] Check iperf3 analysis function - correct checks done?
- [x] Iperf server ID usage
- [x] TCP bitrate check for B200 pipelines
- [x] RAN-L2-Sim-Test-4G --> Could not analyze from server log - log looks OK
- [x] RAN-SA-B200_Module-SABOX-Container --> add TCP with target rate check, so we will test UDP, TCP, BIDIR
Iperf3 test list:
![image](/uploads/a6fe4638bbfd0fd3c192bbe0419f69f9/image.png)REVIEW_IN_PROGRESS