Fix bug "no AMF for UE"
It might happen that the RRC does not know the AMF UE NGAP ID, yet. Even
in that case, we should forward the release request to the NGAP module,
which can either forward a message to the AMF, or reply back to release
the UE. This avoids an error where the CU claims there was no AMF, when
there actually is.
One possible problematic behavior is if a UE disconnects before the gNB
receives an NGAP Initial Context Setup. In this case, the AMF UE NGAP ID
was not forwarded to the RRC (although it was known at NGAP), thus
blocking the release of the UE.
This is the main fix, the rest are minor fixes:
- store AMF UE NGAP ID as early as possible
- warn in MAC if UE unknown for UE context release command
- show TEIDs with correct endianness in GTP
- avoid NG Setup Failure+Setup log.
Introduce SRS physical simulator and improvements
This MR consists of two parts:
- Introduces SRS physical simulator to test different configurations of
SRS
- Improvements in the SRS channel estimation (Addressing the comments
from old, unfinished MR !2875)
- rewrite nr_srs_channel_estimation() to loop over rx antennas and
antenna ports to be able to parallelize
- Improvements in timing_advance_offset and timing_advance_offset_nsec
computation
- Introduce SRS multi-symbol channel estimation
- The channel impulse response is estimated from the averaged
channel frequency response over multiple symbols
- The channel frequency estimates are left as they are to be able to
estimate doppler in the future
- Simplify SRS channel estimation to handle memory alignment in the
case of different SRS configurations (eg: comboffset)
To use multiple symbols when running gNB, the following parameters needs
to be edited in the function get_srs_resource()
- srs_res->resourceMapping.startPosition with a range from {0,1,..,5}
corresponds to the start symbol {13, 12, .. 8} with in a slot
- srs_res->resourceMapping.nrofSymbols indicates the number of symbols
{n1, n2, and n4}
Make sure the that start symbol + number of symbols is < 14
The timing results for SRS in develop and srs_phy_simulator are as follows:
Command used: sudo ./nr_ulsim -n1000 -s50 -S50 -R273 -W2 -y2 -z2 -E 1 -P
develop
|__ RX SRS time 124.94 us (1000 trials) (124.94 total [ms])
|__ Generate SRS sequence time 0.05 us (1000 trials) ( 0.05 total [ms])
|__ Get SRS signal time 19.41 us (1000 trials) ( 19.41 total [ms])
|__ SRS channel estimation time 89.11 us (1000 trials) ( 89.11 total [ms])
|__ SRS timing advance estimation time 13.10 us (1000 trials) ( 13.10 total [ms])
|__ SRS report TLV build time 2.80 us (1000 trials) ( 2.80 total [ms])
|__ SRS beam report build time 0.00 us ( 0 trials)
|__ SRS IQ matrix build time 2.73 us (1000 trials)
srs_phy_simulator
|__ RX SRS time 211.93 us (1000 trials) (211.93 total [ms])
|__ Generate SRS sequence time 0.04 us (1000 trials) ( 0.04 total [ms])
|__ Get SRS signal time 19.55 us (1000 trials) ( 19.55 total [ms])
|__ SRS channel estimation time 152.05 us (1000 trials) (152.05 total [ms])
|__ SRS timing advance estimation time 36.67 us (1000 trials) ( 36.67 total [ms])
|__ SRS report TLV build time 2.96 us (1000 trials) ( 2.96 total [ms])
|__ SRS beam report build time 0.00 us ( 0 trials)
|__ SRS IQ matrix build time 2.88 us (1000 trials)
Note that in srs_phy_simulator, to compute timing offset ns, an
oversampling factor of 2 is performed. Also, for peak detection, we
average the channel estimates for every port.
During N2 handover, the UE receives reconfigurationWithSync which correctly
sets the target cell frequency in mac->phy_config.config_req.carrier_config
via config_common_ue() call.
However, when SIB1 is decoded after reconfiguration,
nr_rrc_mac_config_req_sib1() calls config_common_ue_sa() which unconditionally
overwrites the frequency with the command-line parameter (downlink_frequency),
which corresponds to the source cell frequency.
This causes a critical issue during RRC re-establishment:
- The UE uses the wrong frequency (source cell) for key derivation (kgnb*)
- The gNB uses the correct frequency (target cell) for key derivation
- This mismatch results in different kgnb* keys on UE and gNB
- Integrity check fails: "Integrity of RRCReestablishment failed, going to IDLE"
Root cause:
config_common_ue_sa() is used for SIB1 processing (initial cell selection) and
uses ServingCellConfigCommonSIB which doesn't contain absoluteFrequencyPointA.
It must derive frequency from command-line parameters. However, after handover,
the frequency has already been correctly set by config_common_ue() (used for
reconfigurationWithSync) which uses ServingCellConfigCommon with absolute
frequency information.
Solution:
Modify config_common_ue_sa() to preserve the existing frequency if it's already
initialized (non-zero). Only set frequency from command-line parameters during
initial cell selection when dl_frequency is 0. This ensures:
- Initial cell selection: frequency derived from command-line parameter, just once
- After handover: frequency preserved from reconfigurationWithSync
- MAC maintains its own frequency state independently
The fix applies to both DL and UL frequencies to maintain consistency.
There is probably room for more refactoring to the resync flow, since
the functionalities in config_common_ue and config_common_ue_sa are
partially overlapping and upon reconfigurationWithSync some other
configurations might be applied twice.
These logs are very helpful to identify cell configuration
changes in MAC/PHY, for monitoring purposes, and to rapidly
signal integrity failures during re-establishment.
gNB: apply new NR_CellGroupConfig when RRCReconfiguration is acknowledged
Currently part of the NR_CellGroupConfig is already applied when the
RRCReconfiguration message is created. This is not correct and this MR
fixes this by applying it when the RRCReconfiguration message is
acknowledged.
With this fixed, we also move disabling the feedback (in case
disable_harq is used) from the RRCSetup message to the
RRCReconfiguration message.
Closes: #1002
CORESET start multiple of 6 fix
According to the standard any CORESET (except CSET0) would always start
from the first common resource block index which is multiple of 6 in the
BWP. This was not taken into account in the code. The BWP switch CI test
is modified to test a BWP start not multiple of 6.
An exception is the case where rb-Offset-r16 parameter is set, but can't
be used at gNB for FAPI compatibility.
Closes: #1037
Make sure to apply Doppler and TA not directly when receiving the target cell ntn_config,
but apply Doppler just before the initial sync, and the TA after the initial sync when
we have tha actuel cell frame and slot numbers.
We need the ntn_config when reconfiguring the PHY layer for a new initial sync,
e.g. for calculating the DL Doppler frequency.
As a dedicated scheduled_response dl_config PDU it reaches the PHY layer too late,
as part of the phy_config.config_req it reaches the PHY layer in time with the
other configuration values.
Reset outdated PUCCHs to avoid Assertion caused by non-processed and
active PUCCHs
When there is real-time issues in L1 it may happen that the scheduler
misses/skips some slots, thus, L2 not processing and not freeing some
structures like PUCCH. This commit avoids the Assertion by resetting
any Active outdated PUCCH
Pass beam ID as per FAPI v222.10
This MR
1. Sets MSB of beam ID when passing beam ID to 7.2 radio
2. Modifies phytest scheduler to allocate SSBs on different beams
3. Introduce new MAC config parameter for beam mode to specify HiPHY or LoPHY
beamforming
When doing analogue beamforming, the beam ID for a pre-defined beam
table is passed directly to RU and there is no need to store the beam
table in PHY.
When there is real-time issues in L1 it may happen that the scheduler misses/skips some slots, thus, L2 not processing and not freeing some structures like PUCCH.
This commit avoids the Assertion by resetting any Active outdated PUCCH
Robert Schmidt