- 11 Aug, 2023 22 commits
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
- Use the same CU-UP in E1 as in CU-CP: we don't have a separate entity to allocate IDs, and we just use the same as the CU-CP - Correct gNB CU-UP/CP UE IDs in E1AP message types to 32bit - Set CU UP UE ID explicitly for clarity - Remove RNTI from E1 messages, E1 does not know what an RNTI is
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
The UE had a list of known UEs. With the introduction of a separate module for F1 UE ID handling that is also used in monolithic (to separate CU UE ID from DU UE ID), this functionality is not needed, and deleted in this commit.
-
Robert Schmidt authored
Previously, the F1AP handler called various functions directly, instead of sending an ITTI message to the RRC thread. This has two drawbacks: - it can lead to data races if the RRC task uses functionality that is being accessed by the F1 task through this function - no homogeneity: all other handlers send an ITTI message, so this one should too
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
- The CU/DU UE ID is used in DL RRC Message Transfer - Note: The CU UE ID currently is still the RNTI - on every DL RRC Message, the DU verifies that the UE exists - Refactor RRC: common function to forward protected SRB PDUs
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
The RRC uses gNB_ue_ngap_id as its primary ID; the following commits will introduce the usage of the (F1) gNB CU UE ID. This commits renames the gNB_ue_ngap_id to rrc_ue_id to better reflect its usage as the RRC's primary UE ID. It will be used as the NGAP and F1 (CU) UE IDs.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
To avoid 0 in the ID
-
Robert Schmidt authored
-
Robert Schmidt authored
for reusing the old UE Context after reestablishment: we have to free a UE context, but that also free's the RA process that we still need. Remove here Is this necessary?
-
- 08 Aug, 2023 7 commits
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
integration_2023_w31 See merge request oai/openairinterface5g!2282 * !1932 Introduce basic unit testing framework, cleanup * !2259 NR_UE: improve NFAPI_NR_DMRS_TYPE1_linear_interp() * !2271 Draft: Make asn1c debug traces functional * !2274 remove NR UE RRC sub state * !2278 CI: AW2S - update of AmariUE commands * !2004 Fix gNB LLR plot view * !2265 chore(ci): adding back LTE-UE Radio tests * !2268 fix for PDCCH unscrambling at UE * !2269 fixes for PUCCH F1 at UE * !2258 pdcp_config_req_asn1 bug fix * !2263 UE ServingCellConfigCommon cleanup * !2275 Fix RRC UE timers based on frames and not slots * !2280 handle scheduling of DLSCH with DCI10 in common search * !2277 CI: no Jenkins mail, iperf refactor, add Quectel E1 test * !2260 Preparation of release v2.0.0
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Raphael Defosseux authored
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
-
Robert Schmidt authored
-
- 07 Aug, 2023 11 commits
-
-
Robert Schmidt authored
Merge remote-tracking branch 'origin/NR_MAC_gNB_handle_DLSCH_with_DCI10_common_SS' into integration_2023_w31
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
- throughput test in DL - UL throughput: 30s is enough - increase bidir test time for more reliable measurement - increase retx thresholds: 1% for first round is too low
-
Robert Schmidt authored
The results of individual UEs (e.g., ping) is listed vertically, like so: | ping results | UE1 | | | UE2 | | | UE3 | Where UE1, UE2, ... represents an entire box with results for UE 1, 2, ... For many UEs, this results in considerable need for vertical space. This commit changes to something like the following to save space: | ping results | UE1 UE2 UE3 | For a single UE, this commit has no major impact (the boxes are not stretched to width anymore).
-
Robert Schmidt authored
A side effect of the previous commit's refactoring is that we mark the pipeline as failed if a (packet loss/bitrate) threshold is violated. Previously, the HTML would contain a "Perf not met" hint, but be marked as successful. This commit introduces more realistic thresholds for various pipeline runs. The values are arbitary, following the performances in pipelines that were marked as successful, but actually had performance problems. They allow, though, a pipeline to pass following the normal performance we saw the last weeks.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-