- 28 Jan, 2025 1 commit
-
-
Robert Schmidt authored
Integration: `2025.w04` Closes #876, #896, #875, #893, and #878 See merge request oai/openairinterface5g!3226 * !3198 remove a set of compile options that don't work anyway * !3171 Refactor SCTP Association Response Handling and E1 connection loss at CU-UP * !3023 usrp constant and slow derive timestamp * !3215 Remove unused code * !3192 fix nr phy-test mode in ntn * !3214 fix(nrLDPC_coding_t2): Miscellaneous fixes related to T2 * !3020 use ML receiver for 64 QAM UL-MIMO * Demote error logs to debug for "PUCCH not processed" * !3217 minor improvements in T hacks * !3199 Add a small FAPI Hex parser utility * !3209 Remove most of m64 type usage * !3211 Avoid huge calloc by alloc'ing TBs independently * !3212 F1AP IDs: Allow AddMod, fix concurrency bug * !3152 E1 Setup enc/dec library and unit test * !2999 Repair nFAPI in 5G * !3210 FHI72: FDD support * !3220 Improve RA logs
-
- 27 Jan, 2025 39 commits
-
-
Jaroslava Fiedlerova authored
Improve RA logs Modify existing LOG entries to include preamble index, timing advance and estimated distance from the gNB. This makes mapping RA attempts to physical/simulated UEs easier via sent/received preamble index or physical distance from the gNB in scenarios with >1 UE.
-
Jaroslava Fiedlerova authored
FHI72: FDD support - harmonize DL/UL PRB mapping in one get_xran_prb_map() function with support of mixed slot and duplex mode - do not assume TDD by default
-
Jaroslava Fiedlerova authored
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
-
Robert Schmidt authored
-
Robert Schmidt authored
This function packs P7 messages. At least RX_data.indication messages might be much bigger than the global buffer that is used here. Allocate the buffer on the stack, and make it bigger. Do not use the global buffer, it's simply not necessary; increasing the global tx buffer size might have negative effects elsewhere in the code. That change might make the function reentrant. The mutex seems to only guards the codec config. However, leave it to not introduce any regressions as of now.
-
Robert Schmidt authored
E1 Setup enc/dec library and unit test This MR is adding a library for E1 Setup enc/dec functions: - E1 CU-UP Setup Request - E1 CU-UP Setup Response - E1 Setup Failure and relevant unit tests
-
Robert Schmidt authored
F1AP IDs: Add update, fix concurrency bug I suspect a concurrency bug: For instance, during reestablishment, the CU needs to update the DU UE ID under which the UE is identified in the DU. Previously, the CU would remove, then add the DU UE ID info. At the same time, the PDCP thread might look up the information. This can lead to asserts. Modify the code to do the update under (one) lock. Also, refactor some code.
-
Robert Schmidt authored
Avoid huge calloc by alloc'ing TBs independently Fix real-time problems on smaller machines due to big calloc(). See the commit(s) for more details.
-
Robert Schmidt authored
-
Robert Schmidt authored
Modify the existing 4x4 60MHz USRP+COTS UE test to use nFAPI. The throughput tests remain the same.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Similar to the parent commit, make the numerology in the VNF configurable. Unlike for the PNF change, the VNF frame/slot info is in a per-PNF connection structure to which the "oai_integration" code has no access. So we need to hack the nfapi_vnf_p7_add_pnf() function signature to take the numerology, to be able to save this on a per-PNF basis. The fact that we store this on a per-PNF basis is not strictly required, as the VNF cannot handle multiple numerologies as of now, either. However, we might want to extend this in the future, so it seems prudent to store this on a per-PNF basis, so that we could start handling multiple numerologies at the L2 without the need to change the L1 or nFAPI code itself. Also, the numerology is not needed except for some code that deals with timing over nFAPI. As of now, we don't use this code (nFAPI gets a trigger every slot, as per the VNF request, see an earlier commit in this series), but also here, let's not make the future more complicated by storing the numerology for each PNF now (this could always be reverted). For 4G, put numerology 0 (15kHZ SCS), which is the SCS that LTE uses.
-
Robert Schmidt authored
Fill in the dynamically received numerology, and make the numerology at the PNF configurable, following the changes in the parent commit. The change for the reading is somewhat of a hack, because nFAPI, as of now, does not really foresee to store the numerology, so we fill the numerology during the start request, when the numerlogy has been received in the config request, but at that time, the structure for the time information (frame/slot) does not exist yet.
-
Robert Schmidt authored
-
Robert Schmidt authored
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.
-
Robert Schmidt authored
Similarly as the parent commit(s): - remove hardcoding to specific numerology - avoid conversion when we don't need it
-
Robert Schmidt authored
Similar as the parent comment, remove time macros. In this particular case, we can just pass the exact frame/slot information, instead of squeezing it in a single integer.
-
Robert Schmidt authored
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).
-
Robert Schmidt authored
This file is 8y old. It does not seem to serve any purpose. Remove it.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
the L1 needs both a PDU (in TX_data.req) as well instructions for the actual transmission (in DL_TTI.req) to encode a PDSCH message. In nFAPI, it can happen that a DL_TTI.request message has been received (configuring the PDSCH transmission), without the TX_data.request having reached the PNF. The L1 assumes to have the PDU. To avoid problems, ensure that only the pair of DL_TTI.req/TX_data.req is delivered. Otherwise, drop either message.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Rúben Soares Silva authored
-
Robert Schmidt authored
nFAPI has a mechanism to segment messages that are too big for transport over a given medium (see e.g. SCF 225, section 2.3.2). The maximum segment size of 10000 makes that for larger payloads, e.g. TX_data.request, many small segments are to be sent. This can create or increase delays on the transport. On the other hand, the currently only available transport mechanism, UDP, allows to transport packets of up to almost 65535 bytes. Correspondingly, increase the maximum segment size so that less segments are to be created, and potentially, less delay is to be incurred. # Please enter the commit message for your changes. Lines starting
-
Robert Schmidt authored
-
Robert Schmidt authored
-
hsum authored
Same as parent. Co-authored-by:
hsum <ming-hong.hsu@eurecom.fr> Co-authored-by:
chenyi <Yi-Quan.Chen@eurecom.fr> Co-authored-by:
Rúben Soares Silva <rsilva@allbesmart.pt>
-
hsum authored
Same as parent. Co-authored-by:
hsum <ming-hong.hsu@eurecom.fr> Co-authored-by:
chenyi <Yi-Quan.Chen@eurecom.fr> Co-authored-by:
Rúben Soares Silva <rsilva@allbesmart.pt>
-
chenyi authored
Same as parent commit. Co-authored-by:
hsum <ming-hong.hsu@eurecom.fr> Co-authored-by:
chenyi <Yi-Quan.Chen@eurecom.fr> Co-authored-by:
Rúben Soares Silva <rsilva@allbesmart.pt>
-
Robert Schmidt authored
Avoid delays in tx_data.request handling by avoiding big malloc()s and copy operations. Reimplement function to (1) peek the frame/slot numbers, (2) decide on buffer, and (3) unpack directly into pre-allocated memory. Co-authored-by:
hsum <ming-hong.hsu@eurecom.fr> Co-authored-by:
chenyi <Yi-Quan.Chen@eurecom.fr> Co-authored-by:
Rúben Soares Silva <rsilva@allbesmart.pt>
-
Rúben Soares Silva authored
Some messages might arrive for the wrong slot; in those cases, the message has to be dropped. The next commits will make use of this functionality.
-