Separate NR from LTE

[teodora-vladic]

Not yet finished.

I need CI results for all pipelines in order to continue reworking NR APIs.

[durantabot]

CI Build: #447 | Failed on the following stages:

• RAN-RHEL-Cluster-Image-Builder

[durantabot]

CI Build: #446 | Failed on the following stages:

• RAN-RHEL-Cluster-Image-Builder

[durantabot]

CI Build: #449 | Failed on the following stages:

• OAI-CN5G-COTS-UE-Test
• OAI-FLEXRIC-RAN-Integration-Test
• RAN-NSA-B200-Module-LTEBOX-Container
• RAN-L2-Sim-Test-4G
• RAN-LTE-TDD-2x2-Container
• RAN-SA-Handover-CN5G
• RAN-PhySim-Cluster-4G
• RAN-SA-B200-Module-SABOX-Container
• RAN-SA-FHI72-MPLANE-CN5G
• RAN-gNB-N300-Timing-Phytest-LDPC
• RAN-SA-AW2S-CN5G
• RAN-LTE-TDD-LTEBOX-Container
• RAN-LTE-FDD-LTEBOX-Container
• RAN-LTE-FDD-OAIUE-OAICN4G-Container
• RAN-SA-OAIUE-CN5G
• RAN-SA-Multi-Antenna-CN5G
• RAN-RF-Sim-Test-5G
• RAN-SA-AERIAL-CN5G
• RAN-SA-AERIAL-OAIUE-CN5G

[durantabot]

CI Build: #457 | Failed on the following stages:

• RAN-RHEL-Cluster-Image-Builder

[durantabot]

CI Build: #450 | Failed on the following stages:

• OAI-CN5G-COTS-UE-Test
• OAI-FLEXRIC-RAN-Integration-Test
• RAN-NSA-B200-Module-LTEBOX-Container
• RAN-LTE-TDD-2x2-Container
• RAN-SA-B200-Module-SABOX-Container
• RAN-L2-Sim-Test-4G
• RAN-SA-Handover-CN5G
• RAN-gNB-N300-Timing-Phytest-LDPC
• RAN-SA-OAIUE-CN5G
• RAN-SA-FHI72-MPLANE-CN5G
• RAN-SA-AW2S-CN5G
• RAN-LTE-TDD-LTEBOX-Container
• RAN-LTE-FDD-LTEBOX-Container
• RAN-LTE-FDD-OAIUE-OAICN4G-Container
• RAN-RF-Sim-Test-5G
• RAN-SA-Multi-Antenna-CN5G
• RAN-SA-AERIAL-OAIUE-CN5G
• RAN-SA-AERIAL-CN5G

[durantabot]

CI Build: #458 | Failed on the following stages:

• OAI-CN5G-COTS-UE-Test
• RAN-SA-B200-Module-SABOX-Container
• RAN-NSA-B200-Module-LTEBOX-Container
• RAN-LTE-FDD-OAIUE-OAICN4G-Container
• RAN-L2-Sim-Test-4G
• RAN-LTE-TDD-2x2-Container
• RAN-SA-AW2S-CN5G
• RAN-gNB-N300-Timing-Phytest-LDPC
• RAN-SA-OAIUE-CN5G
• RAN-SA-FHI72-MPLANE-CN5G
• RAN-LTE-FDD-LTEBOX-Container
• RAN-SA-AERIAL-OAIUE-CN5G
• RAN-LTE-TDD-LTEBOX-Container
• RAN-SA-Multi-Antenna-CN5G
• RAN-RF-Sim-Test-5G

[durantabot]

CI Build: #488 | Failed on the following stages:

• RAN-Ubuntu-Jetson-Image-Builder
• RAN-Ubuntu-ARM-Image-Builder
• RAN-Ubuntu-Image-Builder

[durantabot]

CI Build: #499 | Failed on the following stages:

• OAI-CN5G-COTS-UE-Test
• RAN-NSA-B200-Module-LTEBOX-Container
• RAN-SA-Handover-CN5G
• RAN-SA-AW2S-CN5G
• RAN-L2-Sim-Test-4G
• RAN-SA-Multi-Antenna-CN5G
• RAN-SA-FHI72-MPLANE-CN5G
• RAN-gNB-N300-Timing-Phytest-LDPC
• RAN-SA-OAIUE-CN5G
• RAN-LTE-TDD-LTEBOX-Container
• RAN-LTE-TDD-2x2-Container
• RAN-LTE-FDD-LTEBOX-Container
• RAN-LTE-FDD-OAIUE-OAICN4G-Container
• RAN-RF-Sim-Test-5G

[bpodrygajlo]

It would be better to use established terms in names and use existing architectures as the base of this work. I don't know about AW2S or legacy LTE radios, but what you are describing here is a lower-layer split, specifically a family of 7.x splits. To me this does not necessarily fit the openair0_device interface, which fits split8 devices the best. Its is visible that some functions were crammed into openair0_device to make it work for frequency-domain interfaces.

I think it would be best if the name was related to LLS / Split7.x. We should also drop all names like if5, if4.5 as these are historical synonyms to the now industry-standard split8/split7 nomenclature.

The entire integration layer should be inside the application instead of the openair0_device. Accesses to RU_t and gNB_t just make the code more difficult to understand inside the libraries.

One thing that is missing is the 7.2 extensions related to beamforming and precoding. We should identify these extensions and add them to the interface. An example is of these extensions are seen here: https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/4016.

[teodora-vladic]

It would be better to use established terms in names and use existing architectures as the base of this work. I don't know about AW2S or legacy LTE radios, but what you are describing here is a lower-layer split, specifically a family of 7.x splits. To me this does not necessarily fit the openair0_device interface, which fits split8 devices the best. Its is visible that some functions were crammed into openair0_device to make it work for frequency-domain interfaces.

I think it would be best if the name was related to LLS / Split7.x. We should also drop all names like if5, if4.5 as these are historical synonyms to the now industry-standard split8/split7 nomenclature.

The entire integration layer should be inside the application instead of the openair0_device. Accesses to RU_t and gNB_t just make the code more difficult to understand inside the libraries.

One thing that is missing is the 7.2 extensions related to beamforming and precoding. We should identify these extensions and add them to the interface. An example is of these extensions are seen here: https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/4016.

Thanks @bpodrygajlo.

I will delete if5/if4p5 naming. I just need to do step by step to make sure that CI is unaffected with my cleanup. But yes, I completely agree it's outdated.

I want to completely remove NR dependency on RU_t. However, I disagree with putting all L1 inside the application because an application should only contain the relations between layers, and libraries should take care of each layer. For different radios, we have a device (rfsimulator, oai_usrpdevif, oran_fhlib_5g,...). And currently, we use openair0_device_t for time-domain samples, stopping, ending the device,... I would like that device be also used for split handling.

I am aware for precoding and beamforming, that I still have to do. At the moment, we use nr_feptx_prec() function, that shall incorporate multi-sections handling as well.

[rorsc]

And currently, we use openair0_device_t for time-domain samples, stopping, ending the device,... I would like that device be also used for split handling.

"Split handling" means LLS/7.2/frequency domain?

can you please say why you would like to use openair0 for frequency domain, please? I agree with Bartosz in that this seems to be made for time-domain signals, and that at least for 7.2, people crammed it there because they did not know where to put it, not because that was the best choice.

[teodora-vladic]

And currently, we use openair0_device_t for time-domain samples, stopping, ending the device,... I would like that device be also used for split handling.

"Split handling" means LLS/7.2/frequency domain?

can you please say why you would like to use openair0 for frequency domain, please? I agree with Bartosz in that this seems to be made for time-domain signals, and that at least for 7.2, people crammed it there because they did not know where to put it, not because that was the best choice.

Yes, I want a device to take care of all LLS (time and frequency domain) splits.

Since initially, 7.2 is designed to use oai_transpro, and loaded by transport_init(), I assumed that a device should take care of all existing LLS splits. But that is not the case at the moment. If we don't go through that route, and just leave openair0_device_t as it is in develop, then I would suggest to not use a device for 7.2 at all because it only starts/stops/ends the plugin for xran, which can be then done through another way and delete device for 7.2 entirely.

My main goals would be to:

1. delete RU_t dependency for NR,
2. create one struct for split 8,
3. one struct for split 7.2,
4. reference both structs in a new NR_L1_info_t (or NR_LLS_t) struct,
5. create function pointers for:
   • time domain samples,
   • frequency domain samples,
   • triggering UL slot when ready (in order to push into the Tx FIFO queue),
   • remove prach_l1rx_queue and trigger PRACH slot when ready

That would be it for now, and then I need to figure out the sync time for 7.2 (because I would like to remove ru_thread dependency for 7.2), precoding/beamforming and multi-sections.