Integration: 2024.w01
See merge request oai/openairinterface5g!2502
* !2482 Trigger UL Failure if Ack of Msg4 not received and implement RA Contention Resolution timer in gNB
* !2484 function to harmonize handling of NAS registraction accept
* !2487 Rework PUCCH codec with c16_t type and functions to make readable code
* !2491 improvements for NR UE detaching
* !2499 Update L1sim and RFsim documentation
* !2500 Fix FAPI CoreSetType enumeration options after the fix on the description made by SCF
* !2489 NR UE improvements RRCSetup
- update explanation for noS1
- better help for nr-uesoftmodem options
- consistent writing of name "RFsimulator"
- remove LDPC section at end, is already referenced in doc/README.md
- Add TOC
- Better describe what RFsim does
- Remove misleading, wrong, unnecessary information
* It is futile to mention --phy-test or other modes, RFsim works with
all
* Explaining how to ping is not the task of the RFsim documentation
(that is what tutorials are for)
* Remove useless/outdated build log information
- Add some more information on which flags to run
- Improve formatting, and minor clarifications
SCF FAPI 222.10.02 had a bug on the description of CoreSetType:
0: CORESET is configured by the PBCH or SIB1
(subcarrier 0 of CRB0 for DMRS mapping)
1: otherwise (subcarrier 0 of CORESET)
That was fixed in SCF 222.10.04:
0: CORESET is configured by the PBCH or SIB1
(subcarrier 0 of the CORESET)
1: otherwise (subcarrier 0 of CRB0 for DMRS mapping)
That wrong description created a misunderstanding, to overcome it we "wrongly" added a third value. This commit fixes that and aligns the CoreSetType with FAPI 222.10.04
- Do not list L1sim as a way of running OAI: it is untested, and might
not work
- Reword the tutorial where necessary, remove outdated/wrong information
(e.g., we don't test this mode AFAIK)
The UE will trigger new RA either with MAC CE C-RNTI or with new RRCSetupRequest:
- MAC CE C-RNTI: The ul_failure_timer will be reset
- RRCSetupRequest: New UE will be created and the previous one will be deleted
Integration: 2023.w51
See merge request oai/openairinterface5g!2483
* !2221 NR UE going to IDLE state
* !2464 move common .h file in common directory, remove mem_block_t
* !2479 CI: test with 2 UL layers in AW2S pipeline
* !2468 LDPC T2 card: fix and doc update
* !2480 Enabling multi-ue support in the open-source L2 proxy
* !2476 Fixes for multi-DU/CU-UP and CI test
* !2482 Trigger UL Failure if Ack of Msg4 not received
* !2484 function to harmonize handling of NAS registraction accept
The 5G-RFsim F1 test tested multiple DUs at one CU. This
functionality is retained in the new F1+E1 test.
The 5G-RFsim E1 test tested a single CU-UP at a single CU-CP. Here, we
extend to use multiple CU-UPs, one for each DU. The associated is
ensured by using three different F1-U transport networks, one for each
DU/CU-UP pair.
- Test only one DU at the CU (3 DUs is tested in F1+E1)
- Harmonize IP configuration to make it simpler to reuse in the F1+E1
test
- Speed up the test by reducing the number of steps to deploy core/RAN
- Add traffic test
binding the local address for SCTP is pointless, because we don't really
care through which interface SCTP traffic goes. Actually, we even might
want to set the DU remote_n_addr and the the local_n_addr to addresses
in different networks, because we might want to have GTP traffic go
through a different interface than SCTP, as done in the CI test for E1.
MR-2401 changed the argument to the init_nrUE_standalone_thread
to be zero instead of the ue_id_g. This causes every port to be
opened for multiple UEs to have the same value, therefore only
allowing one UE to be connected to the proxy. If the ue_id_g
global is an issue, we should open a new ticket for a proper fix.
We set the RFsim TCP socket to non-blocking. Thus, it may happen that we
cannot write() to the socket when the kernel cannot handle the request,
in which case we wait some time before trying again. This is the
correct/expected behavior.
Since this is *normal*, an error message is not justified; we did not
even print a message in this case before commit 21790f9c4f introduced it.
When setting up bearer(s) through F1, the corresponding F1 message has
QoS fields for the DRB(s) to be set up, as well as for all flows
associated to this DRB. In this commit, set the DRB QoS field to be
equal to the first flow (it is unclear/unspecified how it should be set
up, based on the flows), which was not set before and therefore
contained unitialized data.
The F1 module uses this data, and in split mode, F1 message generation
failed due to uninitialized data.
We reuse RRC UE IDs at the RRC. Previous to this commit, we did not
release a UE at the CU-CP's PDCP (for SRBs). Thus, when reconnecting a
UE, the PDCP might not be in a good state, since we did not release the
previous PDCP UE context.
Duncan Joly