- 11 Feb, 2025 9 commits
-
-
Robert Schmidt authored
Reset E1 UE contexts after E1 Setup Response 38.463 sec. 8.2.3 says > This procedure also re-initialises the E1AP UE-related contexts (if > any) and erases all related signalling connections in the two nodes > like a Reset procedure would do. Hence, delete all contexts after reception of E1 Setup Response. This minimizes a risk of receiving an E1 bearer setup req for an existing UE, which currently leads to an assert [we trust the CU-CP does not send the same UE ID twice, as we only "mirror" the existing UE ID]. After this MR, this is what happens if these entities fail: - CU-CP fails: all context lost implicitly, upon reconnection, both DU and CU-UP reset all contexts (like "start from zero") - DU fails: CU-CP triggers NGAP UE context release request immediately (radio connection with UE lost), all UE contexts attached to this DU cleared (like "start from zero" for affected DU) - CU-UP fails: initially, nothing (UE has no user plane); upon reconnection of CU-UP, CU-CP triggers NGAP UE context release request (cause radio connection with UE lost) and sends F1 Reset to DU, all UE contexts associated to this DU cleared (like "start from zero") for the last case, a possible improvement could be to use the F1 Reset message to only clear affected UE conetxts. I chose not to do this, because this MR is very big now already, and possible "victim" UEs that were not at that CU-UP will reconnect as well
-
Robert Schmidt authored
As in deba3ae0 ("Reset CU-UP E1 UE contexts after E1 Setup Response"), the CU-CP should reset the E1 UE contexts after E1 Setup Response. 38.463 sec. 8.2.3 says > This procedure also re-initialises the E1AP UE-related contexts (if > any) and erases all related signalling connections in the two nodes like > a Reset procedure would do. In the case of CU-CP, this is a bit more complicated. More precisely, we need to wait for the CU-UP to be available again before informing the DU about the loss (implemented via an F1 Reset message), because otherwise, the UE might reconnect immediately, before the CU-UP is online again. Hence, on connection loss, we mark affected UEs (by setting their E1 association ID to 0); as long as the CU-UP does not connect, nothing will happen (but UEs don't have user plane). Upon CU-UP connecting again, we request release of the UEs via NGAP (similarly to what is done if the DU goes offline, see invalidate_du_connections()), free the UE contexts locally, and send an F1 Reset message to the DU, because 38.473 sec 8.2.1.2.1 says > a failure at the gNB-CU [...] has resulted in the loss of some or > all transaction reference information [...] a RESET message shall be > sent to the gNB-DU. The core should accept and send an NGAP release command message; since no UE contexts are to be found (already deleted), the CU-CP will just send a release complete (together with some warnings). It might be possible to more gracefully handle the situation (e.g., as described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but - we lack the PDCP SN exchange - the current procedure has the advantage of being equivalent to "restart of the entire gNB", with less downtown.
-
Robert Schmidt authored
The next commit will use rrc_remove_ue() to delete a CU(-CP+-UP) context. However, we don't send NGAP UE context release at that moment (we will instead *request* the release); more generally, it's not clear that every user of rrc_remove_ue() wants to actually send this message. Hence, refactor the code by separately calling rrc_gNB_send_NGAP_UE_CONTEXT_RELEASE_COMPLETE() where appropriate.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
nFAPI: make 4-layer on 100MHz work 5G nFAPI headers specify 32 bits for the length field, so use it also when segmenting messages. This should stabilize 4-layer MIMO operation on 100MHz with nFAPI.
-
Robert Schmidt authored
Deadlock avoidance in rfsimulator This change introduces a countermeasure for deadlock in rfsimulator. The deadlock happens when all entities are waiting for new data to come in, and happens with 2+ clients, when a new client connects. I think this issue is due to ordering of fullwrite calls, resulting in out-of-order delivery of packets and eventually trashing the packets on the receiving side. The out-of-order delivery warnings are printed just before the system deadlocks but I have not found a better solution so far. The workaround makes the server never lock up permanently by ignoring the client failure to write on time after 10 tries. This was tested locally for both UE as server and gNB as server and works correctly, causing the deadlock to clear and the added log to be printed several times when the deadlock is detected, after which the system goes back to normal. I have some gdb output of the executables during deadlock: UE: $7 = {conn_sock = 98, lastReceivedTS = 3226163740, headerMode = true, trashingPacket = false, th = {size = 13184, nbAnt = 1, timestamp = 3226150556, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a500018a8 "\200\063", remainToTransfer = 24, circularBufEnd = 0x7f6a503b3ac0 "", circularBuf = 0x7f6a501f1ac0, channel_model = 0x0} (gdb) p t->buf[5] $8 = {conn_sock = 97, lastReceivedTS = 0, headerMode = true, trashingPacket = false, th = {size = 0, nbAnt = 0, timestamp = 0, option_value = 0, option_flag = 0}, transferPtr = 0x7f6a50001900 "", remainToTransfer = 24, circularBufEnd = 0x7f6a50575ad0 "", circularBuf = 0x7f6a503b3ad0, channel_model = 0x0} nextRxTimestamp 3225937740 nsamps = 30720 gNB 1: (gdb) p t->buf[0] $4 = {conn_sock = 95, lastReceivedTS = 3226026876, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0}, transferPtr = 0x7f8dfc003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7f8e1c3ff010 "", circularBuf = 0x7f8e1c23d010, channel_model = 0x0} nextRxTimestamp 3225996956 gNB 2: lastReceivedTS = 3226026875 $2 = {conn_sock = 95, lastReceivedTS = 3226026875, headerMode = true, trashingPacket = false, th = {size = 1, nbAnt = 1, timestamp = 3226026875, option_value = 0, option_flag = 0}, transferPtr = 0x744898003ab8 "\001", remainToTransfer = 24, circularBufEnd = 0x7448bc2e7010 "", circularBuf = 0x7448bc125010, channel_model = 0x0} nextRxTimestamp 3226026875 As you can see all executables are in have_to_wait state.
-
- 10 Feb, 2025 4 commits
-
-
Robert Schmidt authored
f1ap_lib_common should help with common message enc/dec inside lib/, and not be used directly.
-
Robert Schmidt authored
38.463 sec. 8.2.3 says > This procedure also re-initialises the E1AP UE-related contexts (if > any) and erases all related signalling connections in the two nodes like > a Reset procedure would do. Hence, delete all contexts after reception of E1 Setup Response. This minimizes a risk of receiving an E1 bearer setup req for an existing UE, which currently leads to an assert [we trust the CU-CP does not send the same UE ID twice, as we only "mirror" the existing UE ID].
-
Robert Schmidt authored
Refactor into remove_ue_e1(), to be used in the next commit, independent of e1_bearer_release_cmd().
-
Robert Schmidt authored
-
- 08 Feb, 2025 2 commits
-
-
Robert Schmidt authored
Make the same change as in parent commit, i.e., write the full 32-bit segment size. I could not test this, as we do not reach these rx_data.indication length. It's based on the fix in the parent commit, and to avoid future bad surprises.
-
Robert Schmidt authored
The 5G nFAPI message length is 32bits. In particular tx_data.requests can be longer than 64kB. When segmenting, we should correctly write the message of the current segment (across all 32bits), because the length would interpreted wrongly otherwise. This fixes a bug in which tx_data.requests were discarded for 4-layer DL MIMO on 100 MHz with this message: P7 unpack message length is greater than the message buffer Further, increase the type of various (segment-related) variables to 32 bits. Currently, the maximum segment size is sxt to 65000 bytes (and in will likely remain, because the maximum UDP size is 65536); nevertheless, increase it in case we will ever go beyond this. See also commit dee68e63 ("nFAPI: increase maximum segment size to 65000")
-
- 07 Feb, 2025 8 commits
-
-
Robert Schmidt authored
Remove inexistant SIMD instruction develop branch doesn't compile with AVX2 only. For instance, mm_loadi_epi32() doesn't exist in SSE, only in the AVX512 family, despite it being a 128 bit vector size instruction. See also: https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html#_mm_loadi_epi32() This was masked by using SIMDE.
-
Robert Schmidt authored
Refactor tun_if.h Use a common function for generating interface name. Use full interface name in tun_if.h functions.
-
Robert Schmidt authored
Improvements for NR dlsim and ulsim
-
Robert Schmidt authored
Period based phytest bitmap phy-test slot bitmap tdd period based to minimize the chance to need it larger than 64 slots
-
Robert Schmidt authored
Merge remote-tracking branch 'beraoud/beraoud-develop-patch-76226' into integration_2025_w06 (!3240) Fix typos in NR_SA_Tutorial_OAI_multi_UE.md
-
Robert Schmidt authored
Simplify usage of the old segment decoding libraries with the slot coding interface This MR transforms the segment coding libraries into slot coding libraries by statically linking the adaptation layer and the segment coding libraries. Therefore they can be used directly in ldpctest which uses the segment coding interface as well as in all the other PHY simulators and the NR softmodem which use the slot coding interface. It is not anymore needed to use the --nrLDPC_coding_segment.segment_shlibversion flag. Instead a segment coding library can be directly chosen with --loader.ldpc.shlibversion since it implements the slot coding interface.
-
Robert Schmidt authored
5G nFAPI headers specify 32 bits for the length field, so use it here as well.
-
Bartosz Podrygajlo authored
Use a common function for generating interface name. Use full interface name in tun_if.h functions.
-
- 05 Feb, 2025 4 commits
-
-
francescomani authored
-
francescomani authored
-
Romain Beurdouche authored
-
Romain Beurdouche authored
feat(nrLDPC_coding): Transform segment coding libraries into slot coding libraries by statically linking the adaptation layer and the segment coding libraries
-
- 04 Feb, 2025 9 commits
-
-
Abdelkhalek Beraoud authored
-
Laurent THOMAS authored
-
francescomani authored
-
francescomani authored
-
francescomani authored
-
francescomani authored
-
francescomani authored
-
francescomani authored
-
francescomani authored
-
- 03 Feb, 2025 3 commits
-
-
Robert Schmidt authored
Integration: `2025.w05` Closes #885 See merge request oai/openairinterface5g!3233 * !3102 Dockerized development environment * !3185 Add IQ file recording and IQ file viewer to ImScope * !3218 more layer1 cleaning * !3224 Ensure execution of processSlotTX in order in NR UE * !3231 Bugfix in frame and slot setting for ULSCH beam allocation * !3229 Verify the integrity protection of the RRCReestablishment message * !3230 FHI72: fix for single distributed antenna array for xran F release * !2984 NAS 5GS refactor * !3235 Parametrized JenkinsNode and JenkinsResource * !2799 Changes to support multiple TDD patterns * !3208 Downgrade gNB power limit LOG from "warning" to "debug"
-
Robert Schmidt authored
Downgrade gNB power limit LOG from "warning" to "debug" Downgrade the UE power limited LOG from LOG_W to LOG_D. This is to avoid flooding stdout when UE in low coverage enters power limited state for a longer period of time. The same information can be inferred from the periodic UE print which also contains PH value (negative PH values indicate that the UE is power limited) Also, correct some typos in PH calculation. Closes #885
-
Robert Schmidt authored
Changes to support multiple TDD patterns - Updated the configuration changes for 2 Patterns - Update the TDD table configuration for NFAPI - Added the tdd bitmap for the period - Adapted the bitmap for UL/DL for the multi TDD pattern - Updated the RACH procedure for multi TDD pattern - Updated DL and UL scheduler for multi TDD pattern
-
- 31 Jan, 2025 1 commit
-
-
Robert Schmidt authored
Merge remote-tracking branch 'origin/nu-ci-colosseum-jenkins-update' into integration_2025_w05 (!3235) Parametrized JenkinsNode and JenkinsResource Parametrized variables in Jenkinsfile for automated tests on Colosseum after update of OAI Jenkins server.
-