oai issueshttps://gitlab.eurecom.fr/groups/oai/-/issues2024-03-28T14:43:28Zhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/726"T_IDs.h" not found when building targets2024-03-28T14:43:28ZJaroslava Fiedlerova"T_IDs.h" not found when building targetsFor instance, compilation fails for `./build_oai --gNB --build-e2 --ninja -c` and returns:
```
/home/eurecom/jaroslava/integration_2024_w03_2/common/utils/T/T.h:15:10: fatal error: T_IDs.h: No such file or directory
15 | #include "T_I...For instance, compilation fails for `./build_oai --gNB --build-e2 --ninja -c` and returns:
```
/home/eurecom/jaroslava/integration_2024_w03_2/common/utils/T/T.h:15:10: fatal error: T_IDs.h: No such file or directory
15 | #include "T_IDs.h"
| ^~~~~~~~~
compilation terminated.
```
Full compilation log attached. [all.txt](/uploads/10223a196f0e5f272eee2eee1f635ea8/all.txt)Jaroslava FiedlerovaJaroslava Fiedlerovahttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/768build_oai asking for Accelercomm drivers even when we dont have this board at...2024-03-28T14:43:26ZJulian Garrettbuild_oai asking for Accelercomm drivers even when we dont have this board attachedWhen attempting to build any of the scopes we are getting the following from oai_build:
Cambridge ❆ sudo ./build_oai --build-lib nrscope\
Enabling build of optional shared library nrscope
OPENAIR_DIR = /home/lime/openairinterface5g
...When attempting to build any of the scopes we are getting the following from oai_build:
Cambridge ❆ sudo ./build_oai --build-lib nrscope\
Enabling build of optional shared library nrscope
OPENAIR_DIR = /home/lime/openairinterface5g
Running "cmake -DENABLE_NRSCOPE=ON ../../.."
cmake: /usr/local/lib/libcurl.so.4: no version information available (required by cmake)
\-- Found ccache in /usr/bin/ccache. Using ccache. CMake \>= 3.4
\-- Check if /opt/asn1c/bin/asn1c supports -gen-APER
\-- Check if /opt/asn1c/bin/asn1c supports -no-gen-UPER
\-- Check if /opt/asn1c/bin/asn1c supports -no-gen-JER
\-- Check if /opt/asn1c/bin/asn1c supports -no-gen-BER
\-- Check if /opt/asn1c/bin/asn1c supports -no-gen-OER
\-- CMAKE_BUILD_TYPE is RelWithDebInfo
\-- CPU architecture is x86_64
\-- AVX512 intrinsics are ON
\-- AVX2 intrinsics are ON
\-- Selected E2AP_VERSION: E2AP_V2
\-- Selected KPM Version: KPM_V2_03
**CMake Error at CMakeLists.txt:506 (message): could not find poll-mode driver for AccelerComm T2 LDPC Offload (rte_baseband_accl\_****ldpc.so****)**
\-- Configuring incomplete, errors occurred! See also "/home/lime/openairinterface5g/cmake_targets/ran_build/build/CMakeFiles/CMakeOutput.log". build have failed
How do we disable this in the setup options - we dont have any T2 board installed.https://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/619Define priority between re-transmissions and periodic scheduling for UL and m...2024-03-28T13:49:06ZFrancesco ManiDefine priority between re-transmissions and periodic scheduling for UL and modify the scheduler consequentlyCurrently there is no priority and in case of multi-UE the choice is made depending on which UE comes first in `UE_list` which is not ordered. To verify if there is the same issue in DL.Currently there is no priority and in case of multi-UE the choice is made depending on which UE comes first in `UE_list` which is not ordered. To verify if there is the same issue in DL.https://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/644SecurityModeCommand integrity protection check at UE2024-03-28T13:28:43ZFrancesco ManiSecurityModeCommand integrity protection check at UEUpon reception of SecurityModeCommand at UE, lower layers need to verify the integrity protection. This is currently not done yet but we send securityModeComplete regardless.Upon reception of SecurityModeCommand at UE, lower layers need to verify the integrity protection. This is currently not done yet but we send securityModeComplete regardless.https://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/708OAI UE: Assertion (is_nr_UL_slot(tdd_config, slot, mac->frame_type) != 0) fai...2024-03-28T13:06:47ZLuis Pereiralpereira@allbesmart.ptOAI UE: Assertion (is_nr_UL_slot(tdd_config, slot, mac->frame_type) != 0) failed!In a FR2 setup with X410 and 120 kHz SCS we get this Assertion very often at OAI UE:
```
Assertion (is_nr_UL_slot(tdd_config, slot, mac->frame_type) != 0) failed!
In get_ul_config_request() /home/user/openairinterface5g/openair2/LAYER2/...In a FR2 setup with X410 and 120 kHz SCS we get this Assertion very often at OAI UE:
```
Assertion (is_nr_UL_slot(tdd_config, slot, mac->frame_type) != 0) failed!
In get_ul_config_request() /home/user/openairinterface5g/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:117
UL config_request called at wrong slot 51
```
How to reproduce: TBDhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/693Polar encoder performance degradation2024-03-28T12:55:12ZSakthivel VelumaniPolar encoder performance degradationAfter !2131 there is a significant increase in polar encoding time of about 100x.
The attached patch can be used to measure this and the following are the encoding time measured on my testbench.
Before the merge `PDCCH encoding: 1.051 ...After !2131 there is a significant increase in polar encoding time of about 100x.
The attached patch can be used to measure this and the following are the encoding time measured on my testbench.
Before the merge `PDCCH encoding: 1.051 us; 2247; 2.848 us`
After the merger `PDCCH encoding: 130.489 us; 2205; 236.611 us;`
[pdcch_stats.patch](/uploads/3a14d281fcd03fdbfc4f99da40fd27cf/pdcch_stats.patch)Roberto Louro MaguetaRoberto Louro Maguetahttps://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-smf/-/issues/60N1/N2 refactor with new library from AMF2024-03-28T10:52:01ZStefan SpettelN1/N2 refactor with new library from AMF* coming out of QoS project, follow-up task
* We should use new NAS library from common-src* coming out of QoS project, follow-up task
* We should use new NAS library from common-srchttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/762CU-CP assert on unknown F1 UE RRC message transfer2024-03-28T07:55:51ZSagar Arorasagar.arora@openairinterface.orgCU-CP assert on unknown F1 UE RRC message transfer**Scenario**: Trying to connect 3 UEs with benetel 650, in E1-F1 split mode.
**Branch**: `Version: Branch: phr_handling_for_develop Abrev. Hash: ad5281aef6 Date: Sat Mar 9 10:29:29 2024 +0100`
CU-CP issue:
```
Assertion (ret == HASH...**Scenario**: Trying to connect 3 UEs with benetel 650, in E1-F1 split mode.
**Branch**: `Version: Branch: phr_handling_for_develop Abrev. Hash: ad5281aef6 Date: Sat Mar 9 10:29:29 2024 +0100`
CU-CP issue:
```
Assertion (ret == HASH_TABLE_OK && data != ((void *)0)) failed!
In cu_get_f1_ue_data() ../../../openair2/F1AP/f1ap_ids.c:80
element for ue_id 5 not found
```
[du-logs.txt](/uploads/a3b2cdf406e582c03e7271e0c26f7fd1/dummy_du.txt)
[cu-cp-error-3-ues.log](/uploads/9ca3effc7716c048f57bc176da3c685b/cu-cp-error-3-ues.log)
**PS**: The branch of CU-CP and DU are not the same. If you want to dismiss this issue because of this reason let me know.Robert SchmidtRobert Schmidthttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/706CU-UP UE Management: E1 vs. integrated CU2024-03-28T07:55:51ZRobert SchmidtCU-UP UE Management: E1 vs. integrated CUThe CU-UP UE ID management is not implemented properly. Currently, functions `e1_bearer_context_setup()` and `e1_bearer_release_cmd()` add and remove CU UE IDs using `cu_add_f1_ue_data()` and `cu_remove_f1_ue_data()`. This is problematic...The CU-UP UE ID management is not implemented properly. Currently, functions `e1_bearer_context_setup()` and `e1_bearer_release_cmd()` add and remove CU UE IDs using `cu_add_f1_ue_data()` and `cu_remove_f1_ue_data()`. This is problematic, as these functions use hashtables used by the CU-CP to correlate DU UE IDs and CU UE IDs; currently, for adding, it is not a problem because a second write of a CU UE ID does not overwrite an entry. However, removing the entry too early in `e1_bearer_release_cmd()` can lead to asserts in an integrated CU if the CU-CP/RRC uses the lookup function `cu_get_f1_ue_data()` afterwards. A temporary workaround is to check in the handler if we really run in E1: if yes, we add/remove the IDs using the hashtables; if not, we don't do anything
This workaround however forces us to use the same CU-UP UE ID in PDCP/RRC, which might have repercussions w.r.t. to interoperability, if we ever want to interoperate CU-CP/UP with something that delivers different UE IDs (because we cannot look up a conversion of CU-CP UEID to CU-UP UE ID). Thus, a natural solution would be to establish a third hashtable (changing all `cu_*_f1_ue_data()` to `cucp_*_f1_ue_data()` for CU-CP and `cuup_*_f1_ue_data()` for CU-UP, next to the existing `du_*_f1_ue_data()`). However, then we have to use the CU-UP variants when forwarding UP packets in PDCP down to RLC because it has to work in E1. But since the PDCP calls directly into the RLC in monolithic, it will do so with the wrong IDs, looking up the CU-CP UE ID instead of the DU UE ID as done currently when using the CU-CP hashtable. Simply, the CU-UP has no notion of the RNTI used at RLC, and in the E1/F1 split case, GTP manages the conversion through TEIDs; in the monolithic case, we don't have the right ID if adding the new functions.
To fix that problem, we might therefore use (dummy) TEIDs between RLC and PDCP. However
- we need to implement the infrastructure to look up these IDs, or somehow store it at RLC and PDCP;
- the F1 message encoding/decoding does the GTP tunnel creation: it should be moved to the handlers in `mac_rrc_dl_handler.c` to either use the real TEID, or set up a fake TEID and give that to RLC when creating a new bearer.
- same for PDCP;
- currently, we send data through GTP by giving it a UE ID + RBID, but in this case and in general, it would make more sense to expose the TEID from GTP directly, simplifying the GTP module;
- after changing the RLC/PDCP interface, everything should still work using RNTI + RB ID in the UE.
Since all of this is a lot of work, a temporary workaround has been implemented (see !2428).https://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/765Heap-use-after-free in UE MAC2024-03-27T18:06:12ZSakthivel VelumaniHeap-use-after-free in UE MAC```[PHY] [UE0] Initial sync: pbch decoded sucessfully, ssb index 0
[PHY] [UE0] In synch, rx_offset 109696 samples
[PHY] [UE 0] Measured Carrier Frequency 3619200010 Hz (offset 10 Hz)
[PHY] HW: Configuring channel 0 (rf_chain 0): ...```[PHY] [UE0] Initial sync: pbch decoded sucessfully, ssb index 0
[PHY] [UE0] In synch, rx_offset 109696 samples
[PHY] [UE 0] Measured Carrier Frequency 3619200010 Hz (offset 10 Hz)
[PHY] HW: Configuring channel 0 (rf_chain 0): setting tx_freq 3619200010 Hz, rx_freq 3619200010 Hz, tune_offset 0
[PHY] Got synch: hw_slot_offset 7, carrier off 10 Hz, rxgain 0.000000 (DL 3619200010.000000 Hz, UL 3619200010.000000 Hz)
Entering ITTI signals handler
TYPE <CTRL-C> TO TERMINATE
[PHY] UE synchronized! decoded_frame_rx=200 UE->init_sync_frame=1 trashed_frames=48
[PHY] Resynchronizing RX by 109696 samples
[NR_RRC] SIB1 decoded
[NR_MAC] NR band duplex spacing is 0 KHz (nr_bandtable[37].band = 78)
[NR_MAC] NR band 78, duplex mode TDD, duplex spacing = 0 KHz
[NR_PHY] ============================================
[NR_PHY] Harq round stats for Downlink: 1/0/0
[NR_PHY] ============================================
[NR_PHY] ============================================
[NR_PHY] Harq round stats for Downlink: 1/0/0
[NR_PHY] ============================================
[NR_MAC] NR band duplex spacing is 0 KHz (nr_bandtable[37].band = 78)
[NR_MAC] NR band 78, duplex mode TDD, duplex spacing = 0 KHz
[MAC] Initialization of 4-step contention-based random access procedure
[NR_MAC] PRACH scheduler: Selected RO Frame 343, Slot 19, Symbol 0, Fdm 0
[PHY] PRACH [UE 0] in frame.slot 343.19, placing PRACH in position 2828, msg1 frequency start 0 (k1 0), preamble_offset 7, first_nonzero_root_idx 0
[NR_MAC] [UE 0][RAPROC] Got BI RAR subPDU 5 ms
[NR_MAC] [UE 0][RAPROC] Got RAPID RAR subPDU
[NR_MAC] [UE 0][RAPROC][344.7] Found RAR with the intended RAPID 28
[MAC] received TA command 31
[PHY] RAR-Msg2 decoded
[NR_MAC] [RAPROC][344.17] RA-Msg3 transmitted
[NR_RRC] Timer T300 expired! No timely response to RRCSetupRequest
[NR_PHY] ============================================
[NR_PHY] Harq round stats for Downlink: 2/0/0
[NR_PHY] ============================================
=================================================================
==2531496==ERROR: AddressSanitizer: heap-use-after-free on address 0x7fffe4809800 at pc 0x5555566c67a4 bp 0x7fffef6884b0 sp 0x7fffef6884a0
READ of size 4 at 0x7fffe4809800 thread T8
#0 0x5555566c67a3 in get_nr_prach_info_from_ssb_index /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:1966
#1 0x5555566d05a1 in nr_ue_prach_scheduler /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:2431
#2 0x5555566ae3ce in nr_ue_ul_scheduler /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:1050
#3 0x5555565730ca in nr_ue_ul_indication /home/sakthi/oai_dev/openair2/NR_UE_PHY_INTERFACE/NR_IF_Module.c:1147
#4 0x5555561ef415 in processSlotTX /home/sakthi/oai_dev/executables/nr-ue.c:601
#5 0x5555562aa67e in one_thread /home/sakthi/oai_dev/common/utils/threadPool/thread-pool.c:86
#6 0x7ffff6694ac2 in start_thread nptl/pthread_create.c:442
#7 0x7ffff672684f (/lib/x86_64-linux-gnu/libc.so.6+0x12684f)
0x7fffe4809800 is located 1146880 bytes inside of 1146888-byte region [0x7fffe46f1800,0x7fffe4809808)
freed by thread T9 here:
#0 0x7ffff74b4537 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:127
#1 0x5555565d5354 in reset_mac_inst /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/main_ue_nr.c:199
#2 0x5555565ac6c8 in nr_rrc_mac_config_req_reset /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/config_ue.c:1378
#3 0x55555651b729 in handle_t300_expiry /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_UE.c:2226
#4 0x555556523740 in nr_rrc_handle_timers /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_timers_and_constants.c:125
#5 0x555556501eb7 in rrc_nrue /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_UE.c:1699
#6 0x5555564ffea6 in rrc_nrue_task /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_UE.c:1667
#7 0x7ffff6694ac2 in start_thread nptl/pthread_create.c:442
previously allocated by thread T9 here:
#0 0x7ffff74b4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x5555566bf216 in build_ssb_list /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:1745
#2 0x5555566c7f1e in build_ssb_to_ro_map /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:2040
#3 0x5555565ad3b8 in nr_rrc_mac_config_req_sib1 /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/config_ue.c:1424
#4 0x5555564d9f96 in nr_rrc_ue_decode_NR_BCCH_DL_SCH_Message /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_UE.c:755
#5 0x555556503842 in rrc_nrue /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_UE.c:1724
#6 0x5555564ffea6 in rrc_nrue_task /home/sakthi/oai_dev/openair2/RRC/NR_UE/rrc_UE.c:1667
#7 0x7ffff6694ac2 in start_thread nptl/pthread_create.c:442
Thread T8 created by T0 here:
#0 0x7ffff7458685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216
#1 0x5555562af86a in threadCreate /home/sakthi/oai_dev/common/utils/system.c:265
#2 0x5555562ab9c0 in initNamedTpool /home/sakthi/oai_dev/common/utils/threadPool/thread-pool.c:156
#3 0x5555561d857e in main /home/sakthi/oai_dev/executables/nr-uesoftmodem.c:484
#4 0x7ffff6629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Thread T9 created by T0 here:
#0 0x7ffff7458685 in __interceptor_pthread_create ../../../../src/libsanitizer/asan/asan_interceptors.cpp:216
#1 0x5555562af86a in threadCreate /home/sakthi/oai_dev/common/utils/system.c:265
#2 0x55555676c605 in itti_create_task /home/sakthi/oai_dev/common/utils/ocp_itti/intertask_interface.cpp:317
#3 0x5555561cf681 in create_tasks_nrue /home/sakthi/oai_dev/executables/nr-uesoftmodem.c:201
#4 0x5555561d887e in main /home/sakthi/oai_dev/executables/nr-uesoftmodem.c:510
#5 0x7ffff6629d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
SUMMARY: AddressSanitizer: heap-use-after-free /home/sakthi/oai_dev/openair2/LAYER2/NR_MAC_UE/nr_ue_scheduler.c:1966 in get_nr_prach_info_from_ssb_index
Shadow bytes around the buggy address:
0x10007c8f92b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x10007c8f92c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x10007c8f92d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x10007c8f92e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x10007c8f92f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x10007c8f9300:[fd]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x10007c8f9310: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x10007c8f9320: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x10007c8f9330: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x10007c8f9340: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x10007c8f9350: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==2531496==ABORTING
[Thread 0x7fffe5b2f640 (LWP 2531587) exited]
[Thread 0x7fffebd18640 (LWP 2531555) exited]
[Thread 0x7fffec519640 (LWP 2531554) exited]
[Thread 0x7fffecd1a640 (LWP 2531553) exited]
[Thread 0x7fffed51b640 (LWP 2531552) exited]
[Thread 0x7fffedd1c640 (LWP 2531549) exited]
[Thread 0x7fffee51d640 (LWP 2531546) exited]
[Thread 0x7fffef8f8640 (LWP 2531525) exited]
[Thread 0x7ffff00f9640 (LWP 2531522) exited]
[Thread 0x7ffff08fa640 (LWP 2531519) exited]
[Thread 0x7ffff10fb640 (LWP 2531516) exited]
[Thread 0x7ffff18fc640 (LWP 2531513) exited]
[Thread 0x7ffff20fd640 (LWP 2531510) exited]
[Thread 0x7ffff28fe640 (LWP 2531507) exited]
[Thread 0x7ffff30ff640 (LWP 2531504) exited]
[Thread 0x7ffff7eaa440 (LWP 2531496) exited]
[Thread 0x7fffe5298640 (LWP 2531592) exited]
[New process 2531496]
[Inferior 1 (process 2531496) exited with code 01]
```
The timer expires sometimes with ASan (maybe because the execution is slow?) but the heap-use-after-free is the main issue here.Francesco ManiFrancesco Manihttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/728Entire UL MAC transport blocks consists of zeros2024-03-27T14:59:19ZLuis Pereiralpereira@allbesmart.ptEntire UL MAC transport blocks consists of zerossome of the UL transport blocks consist in zeros only.
In the below pcap, we can see "RRC Resume Request [Malformed Packet]"... (for example packet number 80), which is shown as the entire TB is only zeros.
This need to be investigated...some of the UL transport blocks consist in zeros only.
In the below pcap, we can see "RRC Resume Request [Malformed Packet]"... (for example packet number 80), which is shown as the entire TB is only zeros.
This need to be investigated, why the packet contains only `0s`
Attached follows a .pcap that contains the all the MAC packets.
[iPhone_PDUSessions_In_ICS_3_all.pcapng](/uploads/fdcd0429edc894f307a542463aac3043/iPhone_PDUSessions_In_ICS_3_all.pcapng)Robert SchmidtRobert Schmidthttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/767Overflow using X310 instantly after finding a UE2024-03-27T11:45:42Zdavid laidOverflow using X310 instantly after finding a UEWhen using the X310 the eNB sends an OVERFLLOW ERROR directly after finding the UE, im using this command to run the eNB : sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.100PRB.usrpx310.conf
here ar...When using the X310 the eNB sends an OVERFLLOW ERROR directly after finding the UE, im using this command to run the eNB : sudo ./lte-softmodem -O ../../../targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.100PRB.usrpx310.conf
here are the logs just before getting the overflow on the eNB
[MAC] [eNB 0][RAPROC] CC_id 0 Frame 246 Activating RAR generation in Frame 246, subframe 6 for process 0, rnti 7a0, state 1
[RRC] [FRAME 00247][eNB][MOD 00][RNTI 7a0] Decoding UL CCCH 5b.90.62.7b.25.f6 (0x7869f17f2541)
[RRC] [FRAME 00247][eNB][MOD 00][RNTI 7a0] Accept new connection from UE random UE identity (0x5fb22706b9000000) MME code 0 TMSI 0 cause 3
[MAC] UE 0 RNTI 7a0 adding LC 1 idx 0 to scheduling control (total 1)
[MAC] UE 0 RNTI 7a0 adding LC 2 idx 1 to scheduling control (total 2)
[MAC] Added physicalConfigDedicated 0x7869d457df80 for 0.0
[RRC] [FRAME 00247][eNB][MOD 00][RNTI 7a0] [RAPROC] Logical Channel DL-CCCH, Generating RRCConnectionSetup (bytes 29)
[RRC] [FRAME 00247][eNB][MOD 00][RNTI 7a0]CALLING RLC CONFIG SRB1 (rbid 1)
[PDCP] add new uid is 0 7a0
[PDCP] [FRAME 00247][eNB][MOD 00][RNTI 7a0][SRB 01] Action ADD LCID 1 (SRB id 1) configured with SN size 5 bits and RLC AM
[MAC] [eNB 0][RAPROC] CC_id 0 Frame 247, subframeP 6: Generating Msg4 with RRC Piggyback (RNTI 7a0)
[RRC] [FRAME 00000][eNB][MOD 00][RNTI 7a0] [RAPROC] Logical Channel UL-DCCH, processing LTE_RRCConnectionSetupComplete from UE (SRB1 Active)
[NAS] AttachRequest.c:39 EMM - attach_request len = 99
[NAS] UeNetworkCapability.c:46 decode_ue_network_capability len = 5
[NAS] UeNetworkCapability.c:63 uenetworkcapability decoded UMTS
[NAS] UeNetworkCapability.c:74 uenetworkcapability decoded GPRS
[NAS] UeNetworkCapability.c:82 uenetworkcapability decoded=6
[NAS] UeNetworkCapability.c:86 uenetworkcapability then decoded=6
[RRC] [FRAME 00000][eNB][MOD 00][RNTI 7a0] UE State = RRC_CONNECTED
[S1AP] [eNB 0] Chose MME '(null)' (assoc_id 27) through selected PLMN Identity index 0 MCC 222 MNC 1
[S1AP] Found usable eNB_ue_s1ap_id: 0xfe04db 16647387(10)
[RRC] [eNB 0] Received S1AP_DOWNLINK_NAS: ue_initial_id 1, eNB_ue_s1ap_id 16647387
[RRC] sent RRC_DCCH_DATA_REQ to TASK_PDCP_ENB
[RRC] [eNB 0] Received S1AP_DOWNLINK_NAS: ue_initial_id 1, eNB_ue_s1ap_id 16647387
[RRC] sent RRC_DCCH_DATA_REQ to TASK_PDCP_ENB
[RRC] [eNB 0] Received S1AP_DOWNLINK_NAS: ue_initial_id 1, eNB_ue_s1ap_id 16647387
[RRC] sent RRC_DCCH_DATA_REQ to TASK_PDCP_ENB
[S1AP] Received NAS message with the E_RAB setup procedure
[S1AP] S1AP_FIND_PROTOCOLIE_BY_ID: /home/rt2024/openairinterface5g/openair3/S1AP/s1ap_eNB_handlers.c 927: ie is NULL
[RRC] [eNB 0] Received S1AP_INITIAL_CONTEXT_SETUP_REQ: ue_initial_id 1, eNB_ue_s1ap_id 16647387, nb_of_e_rabs 1
[GTPU] [101] Created tunnel for UE ID 1952, teid for incoming: 63a0fc54, teid for outgoing 6 to remote IPv4: 192.168.61.133, IPv6 ::
[RRC] [FRAME 00000][eNB][MOD 00][RNTI 7a0] rrc_eNB_process_GTPV1U_CREATE_TUNNEL_RESP tunnel (1671494740, 1671494740) bearer UE context index 0, msg index 0, id 5, gtp addr len 4
[RRC] [eNB 0][UE 7a0] Selected security algorithms (0x7869e0004e70): 0, 2, changed
[RRC] [eNB 0][UE 7a0] Saved security key 85A980D87A0AA582213D5E4122FC5BBF6B2B4FE0DD2A60C93D294828FBBB29FA
U[RRC]
KeNB:85 a9 80 d8 7a 0a a5 82 21 3d 5e 41 22 fc 5b bf 6b 2b 4f e0 dd 2a 60 c9 3d 29 48 28 fb bb 29 fa
[RRC]
KRRCenc:35 74 58 b6 41 ab 8c ef 6b d3 13 e5 81 b5 06 36 75 bd e3 39 de a2 0a cc 37 d2 0c 3d 7f ce b8 c4
[RRC]
KRRCint:6a bf 42 e3 e8 63 4e 9f f9 5f 36 6e e2 0a b9 35 01 08 e9 99 83 e5 ff 0e 80 3d f8 aa 23 d3 05 e2
[RRC] [FRAME 00000][eNB][MOD 00][RNTI 7a0] Logical Channel DL-DCCH, Generate SecurityModeCommand (bytes 3)
[RRC] calling rrc_data_req :securityModeCommand
[RRC] sent RRC_DCCH_DATA_REQ to TASK_PDCP_ENB
LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
Also here are the ONLY errors that i found on the MME logs
[222010100001120] Did not insert enb_s1ap_id_key 60146189531 to enb_ue_s1ap_key2mme_ueid_map enb_ue_s1ap_ue_id 16647387 mme_ue_s1ap_id 7
persist_state_enabled is not enabled
Failed to remove enb_s1ap_id_key from enb_ue_s1ap_key2mme_ueid_map! enb_ue_s1ap_id 16647387 mme_ue_s1ap_id 7
i will also provide the config file of the eNB
Active_eNBs = ( "eNB_Eurecom_LTEBox");
# Asn1_verbosity, choice in: none, info, annoying
Asn1_verbosity = "none";
eNBs =
(
{
////////// Identification parameters:
eNB_ID = 0xe00;
cell_type = "CELL_MACRO_ENB";
eNB_name = "eNB_Eurecom_LTEBox";
// Tracking area code, 0x0000 and 0xfffe are reserved values
tracking_area_code = 1;
plmn_list = ( { mcc = 222; mnc = 01; mnc_length = 2; } );
tr_s_preference = "local_mac"
////////// Physical parameters:
component_carriers = (
{
node_function = "eNodeB_3GPP";
node_timing = "synch_to_ext_device";
node_synch_ref = 0;
frame_type = "FDD";
tdd_config = 3;
tdd_config_s = 0;
prefix_type = "NORMAL";
eutra_band = 7;
downlink_frequency = 2680000000L;
uplink_frequency_offset = -120000000;
Nid_cell = 0;
N_RB_DL = 25;
Nid_cell_mbsfn = 0;
nb_antenna_ports = 1;
nb_antennas_tx = 1;
nb_antennas_rx = 1;
tx_gain = 90;
rx_gain = 125;
pbch_repetition = "FALSE";
prach_root = 0;
prach_config_index = 0;
prach_high_speed = "DISABLE";
prach_zero_correlation = 1;
prach_freq_offset = 2;
pucch_delta_shift = 1;
pucch_nRB_CQI = 1;
pucch_nCS_AN = 0;
pucch_n1_AN = 0;
pdsch_referenceSignalPower = -27;
pdsch_p_b = 0;
pusch_n_SB = 1;
pusch_enable64QAM = "DISABLE";
pusch_hoppingMode = "interSubFrame";
pusch_hoppingOffset = 0;
pusch_groupHoppingEnabled = "ENABLE";
pusch_groupAssignment = 0;
pusch_sequenceHoppingEnabled = "DISABLE";
pusch_nDMRS1 = 1;
phich_duration = "NORMAL";
phich_resource = "ONESIXTH";
srs_enable = "DISABLE";
/* srs_BandwidthConfig =;
srs_SubframeConfig =;
srs_ackNackST =;
srs_MaxUpPts =;*/
pusch_p0_Nominal = -96;
pusch_alpha = "AL1";
pucch_p0_Nominal = -104;
msg3_delta_Preamble = 6;
pucch_deltaF_Format1 = "deltaF2";
pucch_deltaF_Format1b = "deltaF3";
pucch_deltaF_Format2 = "deltaF0";
pucch_deltaF_Format2a = "deltaF0";
pucch_deltaF_Format2b = "deltaF0";
rach_numberOfRA_Preambles = 64;
rach_preamblesGroupAConfig = "DISABLE";
/*
rach_sizeOfRA_PreamblesGroupA = ;
rach_messageSizeGroupA = ;
rach_messagePowerOffsetGroupB = ;
*/
rach_powerRampingStep = 4;
rach_preambleInitialReceivedTargetPower = -108;
rach_preambleTransMax = 10;
rach_raResponseWindowSize = 10;
rach_macContentionResolutionTimer = 48;
rach_maxHARQ_Msg3Tx = 4;
pcch_default_PagingCycle = 128;
pcch_nB = "oneT";
bcch_modificationPeriodCoeff = 2;
ue_TimersAndConstants_t300 = 1000;
ue_TimersAndConstants_t301 = 1000;
ue_TimersAndConstants_t310 = 1000;
ue_TimersAndConstants_t311 = 10000;
ue_TimersAndConstants_n310 = 20;
ue_TimersAndConstants_n311 = 1;
ue_TransmissionMode = 1;
}
);
srb1_parameters :
{
# timer_poll_retransmit = (ms) [5, 10, 15, 20,... 250, 300, 350, ... 500]
timer_poll_retransmit = 80;
# timer_reordering = (ms) [0,5, ... 100, 110, 120, ... ,200]
timer_reordering = 35;
# timer_reordering = (ms) [0,5, ... 250, 300, 350, ... ,500]
timer_status_prohibit = 0;
# poll_pdu = [4, 8, 16, 32 , 64, 128, 256, infinity(>10000)]
poll_pdu = 4;
# poll_byte = (kB) [25,50,75,100,125,250,375,500,750,1000,1250,1500,2000,3000,infinity(>10000)]
poll_byte = 99999;
# max_retx_threshold = [1, 2, 3, 4 , 6, 8, 16, 32]
max_retx_threshold = 4;
}
# ------- SCTP definitions
SCTP :
{
# Number of streams to use in input/output
SCTP_INSTREAMS = 2;
SCTP_OUTSTREAMS = 2;
};
////////// MME parameters:
mme_ip_address = ( { ipv4 = "192.168.61.149";
ipv6 = "192:168:30::17";
active = "yes";
preference = "ipv4";
}
);
enable_measurement_reports = "no";
///X2
enable_x2 = "no";
t_reloc_prep = 1000; /* unit: millisecond */
tx2_reloc_overall = 2000; /* unit: millisecond */
t_dc_prep = 1000; /* unit: millisecond */
t_dc_overall = 2000; /* unit: millisecond */
NETWORK_INTERFACES :
{
ENB_INTERFACE_NAME_FOR_S1_MME = "br-9a30d6f7a08e";
ENB_IPV4_ADDRESS_FOR_S1_MME = "192.168.68.129";
ENB_INTERFACE_NAME_FOR_S1U = "br-9a30d6f7a08e";
ENB_IPV4_ADDRESS_FOR_S1U = "192.168.68.129";
ENB_PORT_FOR_S1U = 2152; # Spec 2152
ENB_IPV4_ADDRESS_FOR_X2C = "192.168.68.129";
ENB_PORT_FOR_X2C = 36422; # Spec 36422
};
}
);
MACRLCs = (
{
num_cc = 1;
tr_s_preference = "local_L1";
tr_n_preference = "local_RRC";
puSch10xSnr = 200;
puCch10xSnr = 200;
}
);
L1s = (
{
num_cc = 1;
tr_n_preference = "local_mac";
}
);
RUs = (
{
local_rf = "yes"
nb_tx = 1
nb_rx = 1
att_tx = 0
att_rx = 0;
bands = [7];
max_pdschReferenceSignalPower = -27;
max_rxgain = 116;
eNB_instances = [0];
sdr_addrs = "type=x300";
}
);
THREAD_STRUCT = (
{
#three config for level of parallelism "PARALLEL_SINGLE_THREAD", "PARALLEL_RU_L1_SPLIT", or "PARALLEL_RU_L1_TRX_SPLIT"
parallel_config = "PARALLEL_SINGLE_THREAD";
#two option for worker "WORKER_DISABLE" or "WORKER_ENABLE"
worker_config = "WORKER_ENABLE";
}
);
log_config :
{
global_log_level ="info";
hw_log_level ="info";
phy_log_level ="info";
mac_log_level ="info";
rlc_log_level ="info";
pdcp_log_level ="info";
rrc_log_level ="info";
};
I noticed that the S1AP maybe a problem but i think i gave the eNB the right IP addresses
here is my ifconfig command
br-9d793d75f682: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.68.129 netmask 255.255.255.192 broadcast 192.168.68.191
inet6 fe80::42:22ff:fea7:d9c prefixlen 64 scopeid 0x20<link>
ether 02:42:22:a7:0d:9c txqueuelen 0 (Ethernet)
RX packets 53 bytes 3164 (3.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 71 bytes 7428 (7.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
br-a91338c6a7fe: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.61.129 netmask 255.255.255.192 broadcast 192.168.61.191
inet6 fe80::42:53ff:fe6b:1bd prefixlen 64 scopeid 0x20<link>
ether 02:42:53:6b:01:bd txqueuelen 0 (Ethernet)
RX packets 330 bytes 27684 (27.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 329 bytes 34346 (34.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.17.1 netmask 255.255.255.0 broadcast 192.168.17.255
ether 02:42:40:ea:e1:d9 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.74 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::6862:819b:3471:f71b prefixlen 64 scopeid 0x20<link>
ether 74:27:ea:f2:da:83 txqueuelen 1000 (Ethernet)
RX packets 95672 bytes 124980086 (124.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 45988 bytes 4249514 (4.2 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf7e00000-f7e20000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Boucle locale)
RX packets 1552773 bytes 47248894634 (47.2 GB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1552773 bytes 47248894634 (47.2 GB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth0ffe7c6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::4e4:5ff:fedb:ea27 prefixlen 64 scopeid 0x20<link>
ether 06:e4:05:db:ea:27 txqueuelen 0 (Ethernet)
RX packets 607 bytes 359381 (359.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 883 bytes 147206 (147.2 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
veth5e2647e: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::14bc:daff:fe44:1806 prefixlen 64 scopeid 0x20<link>
ether 16:bc:da:44:18:06 txqueuelen 0 (Ethernet)
RX packets 568 bytes 60496 (60.4 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 695 bytes 77020 (77.0 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethc01c0cc: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::d8ce:acff:fed3:850a prefixlen 64 scopeid 0x20<link>
ether da:ce:ac:d3:85:0a txqueuelen 0 (Ethernet)
RX packets 2065 bytes 118876 (118.8 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2200 bytes 132558 (132.5 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethc3984e8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::bc54:c8ff:fe1a:c9ae prefixlen 64 scopeid 0x20<link>
ether be:54:c8:1a:c9:ae txqueuelen 0 (Ethernet)
RX packets 2045 bytes 117294 (117.2 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2177 bytes 129882 (129.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethcb57d7b: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::48c5:d5ff:fe53:edd prefixlen 64 scopeid 0x20<link>
ether 4a:c5:d5:53:0e:dd txqueuelen 0 (Ethernet)
RX packets 15 bytes 1146 (1.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 158 bytes 14766 (14.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethd645098: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::a43a:beff:fef3:2de3 prefixlen 64 scopeid 0x20<link>
ether a6:3a:be:f3:2d:e3 txqueuelen 0 (Ethernet)
RX packets 635 bytes 116684 (116.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 509 bytes 275767 (275.7 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
vethec96822: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::9048:30ff:feb0:27d1 prefixlen 64 scopeid 0x20<link>
ether 92:48:30:b0:27:d1 txqueuelen 0 (Ethernet)
RX packets 269 bytes 34078 (34.0 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 436 bytes 45146 (45.1 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0https://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/748Wrong UL BLER Calculations at Low SNR2024-03-27T09:58:59ZAbdo GaberWrong UL BLER Calculations at Low SNRCheck BLER calculations in OAI at low SNRs, sometimes on terminal, a BLER value > 1
In addition, assume the re-transmission (ul_harq_round_max) has been configured to 4 (the default value), the UL BLER calculations are based on the first...Check BLER calculations in OAI at low SNRs, sometimes on terminal, a BLER value > 1
In addition, assume the re-transmission (ul_harq_round_max) has been configured to 4 (the default value), the UL BLER calculations are based on the first two rounds only. Look to the below code:
- Path: …/openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_primitives.c
- Function: get_mcs_from_bler
- Code:
```
- // last update is longer than x frames ago
const int dtx = (int)(stats->rounds[0] - bler_stats->rounds[0]);
const int dretx = (int)(stats->rounds[1] - bler_stats->rounds[1]);
const float bler_window = dtx > 0 ? (float) dretx / dtx : bler_stats->bler;
float bler_old = bler_stats->bler;
bler_stats->bler = BLER_FILTER * bler_stats->bler + (1 - BLER_FILTER) * bler_window;
```
You can see in the above code, only the statistics of rounds[0] and rounds[1] have been taken into account onlyhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/766PHY Test Mode – Every second packet is skipped and CRC is OK (BLER 50%) at lo...2024-03-27T09:58:58ZAbdo GaberPHY Test Mode – Every second packet is skipped and CRC is OK (BLER 50%) at low SNRs instead of 100% BLER**System Configuration:**
- PHY Test mode: UL slot = 8 of every radio frame
**Goal:**
- Have our own UL BLER calculations and be able to monitor the CRC per each UL slot.
- The existing UL BLER calculations is not 100% precise, since i...**System Configuration:**
- PHY Test mode: UL slot = 8 of every radio frame
**Goal:**
- Have our own UL BLER calculations and be able to monitor the CRC per each UL slot.
- The existing UL BLER calculations is not 100% precise, since it considers only the first HARQ proc, which has been already reported here: https://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/748
**Implementation:** To get CRC fails counter, we did the following modifications:
- Add crc_fail_cnt to the NR_mac_stats
- File: /openair2/LAYER2/NR_MAC_gNB/nr_mac_gNB.h
```
typedef struct NR_mac_stats {
NR_mac_dir_stats_t dl;
NR_mac_dir_stats_t ul;
uint32_t ulsch_DTX;
uint32_t ulsch_crc_fail_cnt;
uint64_t ulsch_total_bytes_scheduled;
uint32_t pucch0_DTX;
int cumul_rsrp;
uint8_t num_rsrp_meas;
char srs_stats[50]; // Statistics may differ depending on SRS usage
} NR_mac_stats_t;
```
- Get crc_fail_count:
- File: openair2/LAYER2/NR_MAC_gNB/gNB_scheduler_ulsch.c
```
void handle_nr_ul_harq()
line 553:
if (!crc_pdu->tb_crc_status) {
...
} else if (harq->round >= RC.nrmac[mod_id]->ul_bler.harq_round_max - 1) {
...
UE->mac_stats.ulsch_crc_fail_cnt++;
} else {
...UE->mac_stats.ulsch_crc_fail_cnt++;
}
```
- It is worth mentioning that the overall ul packet count = SUM of all ul harq process counters:
`" numAllUlPackets " << std::accumulate(std::begin(macUeStatsDstBuffer[i].ul_harq), std::next(std::end(macUeStatsDstBuffer[i].ul_harq), -1), 0)`
**Observation:**
- At low SNRs, we observe that every second CRC is OK. It seems every second packet is skipped. In the attached figure, for MCS 14 and SNR 10 dB, the BLER reported by OAI (blue curve) is 100% while the BLER calculated based on CRC status (orange curve) is 50%. We observed one UL slot with CRC 0 and the next UL Slot with CRC 1 and so on.
- ![image](/uploads/1ff43f021a829eea726cda73215a25b4/image.png)Robert SchmidtRobert Schmidthttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/727F1: Received unsuccessful result for SCTP association2024-03-26T15:02:38ZLuis Pereiralpereira@allbesmart.ptF1: Received unsuccessful result for SCTP associationDescription: When running F1 split with CU running in one host and DU in another host, CU prints these logs after the DU connection:
```
[RRC] Accepting DU 3584 (gNB-OAI), sending F1 Setup Response
[SCTP] SCTP_ASSOC_CHANGE to SCTP_C...Description: When running F1 split with CU running in one host and DU in another host, CU prints these logs after the DU connection:
```
[RRC] Accepting DU 3584 (gNB-OAI), sending F1 Setup Response
[SCTP] SCTP_ASSOC_CHANGE to SCTP_COMM_LOST
[SCTP] sctp_recvmsg (fd 106, len -1 ): Connection reset by peer:104
[F1AP] Received unsuccessful result for SCTP association (3), instance 0, cnx_id 0
```
When a UE tries to connect, the CU gets an Assertion at RRCSetupRequest (more details can be provided)
How to fix:
Reverting this commit:
https://gitlab.eurecom.fr/oai/openairinterface5g/-/merge_requests/2476/diffs?commit_id=284116522b7d90d9dfb08d7b72397b3c8fde207e
This can also be reproduced between 2 Virtual Machines. When CU and DU run in the same host the issue does not happen.Robert SchmidtRobert Schmidthttps://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-smf/-/issues/23static ip-address allocation smf does not remove the user context if the UE i...2024-03-26T10:24:17ZSagar Arorasagar.arora@openairinterface.orgstatic ip-address allocation smf does not remove the user context if the UE is not properly disconnectedIf the UE is not properly de-registered or gNB crashed or stopped.
The UE will receive the same ip-address but there will be no downlink traffic because upf is sending packets in old tunnel id. The SMF needs to remove the pfcp session ...If the UE is not properly de-registered or gNB crashed or stopped.
The UE will receive the same ip-address but there will be no downlink traffic because upf is sending packets in old tunnel id. The SMF needs to remove the pfcp session from upf but that is not happening.Tien-Thinh NguyenTien-Thinh Nguyenhttps://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-smf/-/issues/59[Issue] SMF can't re-register to NRF if registration/heartbeat lost e.g., whe...2024-03-26T10:23:00ZTien-Thinh Nguyen[Issue] SMF can't re-register to NRF if registration/heartbeat lost e.g., when NRF restartsTien-Thinh NguyenTien-Thinh Nguyenhttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/764NR PUSCH DMRS type 2 at gNB2024-03-26T10:09:56ZFrancesco ManiNR PUSCH DMRS type 2 at gNB`nr_pusch_channel_estimation` computes `nushift = (p >> 1) & 1`. Assuming this would correspond to `delta` in 38.211 6.4.1.1.3, it would be valid only for type 1 DMRS (see tables Table 6.4.1.1.3-1 and Table 6.4.1.1.3-2 in the same document)`nr_pusch_channel_estimation` computes `nushift = (p >> 1) & 1`. Assuming this would correspond to `delta` in 38.211 6.4.1.1.3, it would be valid only for type 1 DMRS (see tables Table 6.4.1.1.3-1 and Table 6.4.1.1.3-2 in the same document)https://gitlab.eurecom.fr/oai/cn5g/oai-cn5g-nrf/-/issues/9NRF crashes when received a PATCH request with op: INVALID_VALUE_OPENAPI_GENE...2024-03-25T15:06:55ZTien-Thinh NguyenNRF crashes when received a PATCH request with op: INVALID_VALUE_OPENAPI_GENERATEDAn example for requested message: [{"op":"INVALID_VALUE_OPENAPI_GENERATED","path":"/nfStatus","value":"REGISTERED"}]An example for requested message: [{"op":"INVALID_VALUE_OPENAPI_GENERATED","path":"/nfStatus","value":"REGISTERED"}]Lakhan GhayadeLakhan Ghayadehttps://gitlab.eurecom.fr/oai/openairinterface5g/-/issues/763O1 module not appearing when we attach to the telnetsrv2024-03-25T13:32:56ZJulian GarrettO1 module not appearing when we attach to the telnetsrvHi, we do not seem to be able to see any o1 module appearing when we manually telnet into the nr-softmodem.
We are invoking the softmodem with the following script:
sudo ./ran_build/build/nr-softmodem -O /home/lime/openairinterface5g/...Hi, we do not seem to be able to see any o1 module appearing when we manually telnet into the nr-softmodem.
We are invoking the softmodem with the following script:
sudo ./ran_build/build/nr-softmodem -O /home/lime/openairinterface5g/targets/PROJECTS/GENERIC-NR-5GC/CONF/lmssdr_3p5_40M_MIMO.conf --rf-config-file /home/lime/openairinterface5g/cmake_targets/lms.cfg --sa --telnetsrv --telnetsrv.listenport 8091 --telnetsrv.shrmod o1 --telnetsrv.shrmod ci --websrv --websrv.listenport 8092 --log_config.global_log_options level,nocolor,time,line_num,function
It does say in the literature to invoke o1 and ci with --telnetsrv.shrmod o1,ci but neither combination is working for us currently. (comma separated and the method above).
Its something simple, but we're lost. Thanks for any support you can provide.