K-offset updated with configured sub carrier spacing
According to 38.331 , cell specific K-OFFSET provided in SIB19 is provided in
number of slots as per 15Khz SCS Koffset before being applied, needs to be
updated to the slots according to the configured subcarrier spacing.
According to 38.331 , cell specific K-OFFSET provided in SIB19 is provided in number of slots as per 15Khz SCS
Koffset before being applied, needs to be updated to the slots according to the configured subcarrier spacing.
Handle N_TA_offset update the same way timing advance changes are handled:
modify writeBlockSize to ensure continuous transmission. Also address possible
data races by making sure the new timing_advance/N_TA_offset is only read
once from global memory.
This prevents the UE to use an outdated timing_advance after a re-sync. It prevents the UE to send a PRACH with a wrong TA, thus preventing a RAPID mismatch in Msg2 (example: '[UE 0][RAPROC][0.0] Received RAR preamble (29) doesn't match the intended RAPID (30)')
Long PRACH extends beyond a slot. Changes necessary to mark future slots
that may contain prach in ru, phy and mac functions.
In RU, the PRACH IDFT is done only after receiving last slot and marks
for L1 to start processing. The L1 processes at the last prach slot and
reports to MAC with the first slot index.
In MAC scheduler, the VRB for future slots are also marked as used.
PRACH scheduler is called in advance one frame minus num prach slots.
FHI72: remove polling, fix memory leak
- FHI72 used polling to track the next slot. This is not necessary, a
simple queue does the job and allows to save one core that was
previously at 100%
- Remove a workaround to avoid a memory leak (fixes#812); allows to
also run RFsim/USRP/otehr radios when compiling for FHI72
fix NTN LEO scenarios
- gNB: add support for NTN parameter ta-CommonDrift-r17
- NR UE: fix application of NTN TA information
- NR UE: add command line parameter ntn-initial-time-drift to compensate
time drift during initial sync
- NR UE: fix writeTimestamp inconsistencies
- NR UE: add MAC state UE_RECEIVING_SIB ensuring to start RA only after
successfully receiving SIBs
- rfsimulator: update earth radius for LEO simulation to match UE
position in ue.conf file
- update conf files for NTN LEO scenario
- update description how to run NTN scenarios in RUNMODEM.md
- fix: ta-Common is a round-trip-time, not a one-way delay
- NR UE: simplify calculation of next_tx_slot_and_frame by moving up
assignment of duration_rx_to_tx
- cellbarredNTN indicates notbarred in SIB1 if NTN access is available
- Removed b66 NTN and enabled B254 NTN conf file in CI
- NR UE: RRC layer now explicitly tells MAC layer when the RA procedure
can be started
- move NTN LEO config to band 254 and update doc/RUNMODEM.md
Closes#901
The "writeTimestamp inconsistencies" are coming from the fact that during the actual processing we write `N_TA_offset` samples _and_ `NR_UE_CAPABILITY_SLOT_RX_TO_TX` slots ahead,
but both was not corrently considered in readFrame() and syncInFrame().
Therefore, there was always a warning about a gap in write timestamps as soon the actual processing starts.
The value of ntn_init_time_drift is used at initial sync to compensate for the time drift during initial sync detection.
To perform the initial time and frequency sync, the OAI UE currently takes a snapshot of two frames and then performes PSS correlation, SSS detection and MIB decoding.
Doing this takes much time, several tens of ms. During that time, the DL timing drifts so much, that we immediatedly lose sync again.
Therefore the current OAI UE implementation needs to know the drift rate to compensate for this drift, as we are "blind" while performing the initial sync.
To my undestanding, commercial UEs simply have a faster initial sync, so the DL timing will not drift away too much while performing that initial sync.
The queue L1_rx_out was in place to keep RX/TX processing relatively
"close" to each other (in terms of time, since in RFsim, they might
advance faster than realtime; see also parent commit). This lead to a
memory leak in radios that do not use ru->feprx (no front-end processing
for RX, e.g., PRACH), as the code to read the L1_rx_out messages was
inside a block of if (ru->feprx). Move it out so that the queue is
always read and messages are freed to eliminate the memory leak, and
remove the workaround for FHI72 to avoid this memory leak.
This also allows to run RFsim when compiling FHI72, which was not
possible before this commit.
Closes: #812
Some radios (e.g., RFsim) can run faster. A mechanism has been put in
place to keep RX/TX frame/slot numbers not too far from each other.
Refactor in a separate function with documentation to make this clearer.
NAS 5GS refactor
The goal of this MR is to reorganize the NR NAS code into:
- enc/dec library functions (5GS, 5GMM, 5GSM, NR_NAS_defs.h,
nr_fgs_nas_lib.c)
- handlers and callbacks (nr_nas_msg.c)
The following changes are introduced:
1. migrate 5GS enc/dec lib (5GMM and 5GSM) to a dedicated folder
2. add a nested CMakeLists structure
3. refactor NR NAS enc/dec functions
4. refactor NR NAS messages struct definitions
5. remove most of dependency from NAS LTE
6. further refactor of PDU Session Establishment Accept processing to
separate enc/dec from handling
7. made naming of 5GS definitions consistent whenever necessary
8. cleanup unused code
9. remove redundant struct definitions
Also:
1. fix decoding of AMF Set ID in 5G-S-TMSI UE identity
2. replace Byte_t directly with uint8_t
Ensure execution of processSlotTX in order in NR UE
Make sure that processSlotTX is executed in slot order.
There is a bug that causes decoding error when processSlotTX is executed
out of order. The root cause is not known at this point, but this change
avoids the bug altogether.
This commit is introducing the following macro changes:
(1) Migrate NAS 5GS lib files to a new 5GS subfolder in NR_UE
and organize NAS 5GS lib messages into 5GMM and 5GSM subfolders.
A nested CMake structure was implemented and CMakeLists.txt were
added whenever necessary. This is effectively separating 5GS
libraries from LTE libraries.
(2) In order to simplify the separation of 5GS libs from LTE libs,
remaining dependencies from NAS LTE (e.g. nas_ue_task.c, ue-idx-standalone)
were removed in the process
(3) ExtendedProtocolDiscriminator.c/.h and SpareHalfOctet.c/.h were deleted
and affected types were replaced with simple integer types
(4) Cleanup: unused definitions and libs (e.g. LIB_5GNAS_GNB)
were removed
(5) Update doc/Doxyfile
(6) clang-formatted the migrated files in the process
(7) Update includes of headers in affected files
This commit introduces the following changes to ImScope:
- Added the ability to record IQ data using the same mechanism as ImScope.
- Added a new executable target `imscope_iq_file_viewer` for viewing IQ files.
- Introduced a command line argument `--imscope-record` that enables data recording mode.
- Refactored a lot of the scope code
Usage:
- To record IQ data, run a modem with `--imscope-record` flag.
The recording happens whenever a modem calls dumpScopeData, which currently is
done only in gNB on PUSCH DTX and PUSCH CRC NOK.
There is a limit of ~1GB of files written by the thread in a signle run to avoid
accidentally exhausting disk space.
If a directory `imscope-dump` is available the data will be recorded there in .imscope
files. Otherwise files are written to the directory the modem was run. This is done so that
the directory can be mapped in a docker container.
- To view recorded IQ files, use the new executable `imscope_iq_file_viewer`. This can be done by running:
```
./imscope_iq_file_viewer <path_to_iq_file>
```
Replace `<path_to_iq_file>` with the path to the IQ file you want to view.
Repair nFAPI in 5G
Add 5G nFAPI in OAI/Make it it work.
Many commits in this branch are basically bug fixes of things that don't work
properly, such as
- check for correct conditions (e.g. instance numbers in the RAN context)
- remove artificial limitation (e.g. only one PUCCH per TDD period in the PNF)
- improve performance (reduce big mallocs, make some static buffers such as a
global ring buffer for nFAPI messages in the PNF)
- fix bugs in nFAPI (e.g., increase maximum message size to ~64kB instead of
1500 bytes, because the latter is way too small for many TX_data.requests in
5G, and it will delay message arrival unduly)
- fix bugs in message enc/dec (e.g., handle FDD in config.request)
- adjust the L1 such that the condition "we run monolithic" is not necessery
(e.g., some message numbers in nFAPI struct where reset in MAC, instead of
L1, and this breaks when running the PNF)
There are instructions that explain how to set it up. Two CI tests have been
added, one with COTS UE and MIMO in DL+UL in TDD numerology 1 (30kHz), and a
second test with FDD mu=0 (15kHZ) in RFsimulator.
These were some old to-dos that have been addressed.
- test with COTS UE - 4x4 pipeline works good in DL, UL now also work
- test in RFsim
- make PNF status message
- make FDD in u0 work
At both the PNF and the VNF, introduce a separate numerology field, and
pass the numerology when converting time information using macros from
nfapi_interface.h. The actually numerology is still hardcoded to 1 (as it
was before), but the follow-up commits will put a suitable numerology.
In both cases, but the numerology next to the frame/slot information.
The next commits will modify the time macros used in the 5G nFAPI code
to handle different numerologies. As a preparation, remove all the
usages of these macros where they really don't matter (e.g., don't
convert if we don't need to).
The usage of this flag in the L1 is simply wrong: either, the NFAPI mode
runs L1, or not. Correspondingly, add an assert to check this invariant.
In the NR_IF_module, the correct check to do is for VNF (implying no L1,
or "emulation of L1" [which is not true]), in which case we use
queues.
In monolithic, the sched_response mechanism ensures that FAPI messages
for one slot are not overwritten by scheduler instructions for the
following slots (i.e., it is like a memory allocation pool).
The allocation happens in nr_schedule_response(), not used by the PNF.
Hence, only deallocate when in monolithic.
The PNF uses a big ring buffer over all slots in a frame to ensure the
same.
We are required to store multiple PUCCH (e.g., for multiple UEs).
However, nr_fill_pucch() automatically freed the previously active PUCCH
structure. Of course(!) this does not make sense.
However, the problem is that init_nr_transport() allocated only one
PUCCH structure. Also this does not make sense to me. The problem was
that slot_ahead was 0, which logically cannot happen in this function
(because slot_ahead is illogical, we must give the radio some time). The
reason is that it uses if_inst->sl_ahead, which, prior to this commit,
was not set.
The init_nr_transport() function is called normally from main() through
init_eNB_afterRU(). In this case, we initialize if_inst->sl_ahead to
what is set in main(). In the PNF case, however, we call
init_nr_transport() from the PNF thread, when receiving the start
request. In the main(), we wait for this to happen, before setting
if_inst->sl_ahead. Hence, initializing this variable (which we should
safely be able to do) before solves the problem.
The radio gives the clock. Therefore, we do not need to keep the time
separately in the PNF.
Also, the VNF should not run the ru_thread, as this is an L1 thread.
fix(nrLDPC_coding_t2): Miscellaneous fixes related to T2
1. HARQ combined offset:
The offset provided for each code block in the HARQ combined input and output
buffer shall not be above 512. A modulus was performed on the offset of the TB
in the buffer to avoid this situation. But the offset of the code block was
added afterward so that the total offset was sometimes going above 512.This
commit performs the modulus after adding the code block offset. Usually this
issue was triggering a segfault after less than 2 minutes of an iperf test on
some setup using T2. The same iperf test was successfully performed during 10
minutes on the same setup with this change.
2. Properly stop LDPC coding in gNB and UE:
LDPC coding was yet not properly stopped by using free_nrLDPC_coding_interface
in gNB and UE. This was not causing major issue until now. It was especially not
causing any issue with T2 LDPC coding using the PF. But using T2 VFs, if the
coding library is not properly stopped then the VF cannot be used anymore unless
the admin app is restarted. So this MR adds the missing free_nrLDPC_coding_interface.
- Refactor SCTP Association Response Handling
- Unified function for both CU-CP and CU-UP handling
- CU-CP: Notifies RRC of E1 connection loss with CU-UP
- CU-UP: Initiates a new SCTP association request to regain E1 connection
- this fix will prevent issue #878 from happening
- Send list of PDU Session Resources to Failed Setup in the (PDU Session
Resource/Initial Context) Setup Response
- depending on different failure scenarios
- e.g. (#878) when No CU-UP is associated and still the CU-CP receives a PDU
Session Setup Request
- add relevant functions to handle NGAP Setup Response messages with failed
list of items
- this is an extra failure handling to make #878 is handled if it ever happens
again
- NGAP Cause Refactoring
- Refactor struct for NGAP cause group and value
- Add extended radio network cause enumeration values
- Refactor redundant code into a new NGAP cause encoding function
- Minor logging, function descriptions improvements
Closes#878
Jaroslava Fiedlerova