NR gNB handling TCI state indication for beam switching
This MR implements the procedure to send in DLSCH MAC-CE for TCI state
indication to UE
- if new beam is reported via SSB RSRP, gNB allocates MAC-CE with TCI
indication
- DLSCH is scheduled to be transmitted with priority
- a timer is started when receiving ACK according to the delay mandated
by standard (8.10.3 of 38.133)
- at timer expiry the gNB switches beam
Check for PDSCH overlapping CORESET during RA
CORESET 0 is configured in the configuration file by
'initialDLBWPcontrolResourceSetZero' and PDSCH TDA list is configured based on
the current BWP size.
It may happen that the user configures a 2 symbol CORESET 0 for a BWP >= 48 PRBs
(which is a valid 3GPP configuration) but in function 'nr_rrc_config_dl_tda'
this scenario is not taken in account causing an overlap between PDSCH and PDCCH
symbols during RA.
This leads to very unreliable Msg2 and Msg4 decoding at the UE, but from time to
time it succeeds, which becomes hard to identify this issue.
closes#705
NR UE: add neighboring cell measurements and measurement report of event A3
This is a rework of MR !2385 (closed), the goal is to add neighboring cell
measurements and measurement report of event A3 for NR UE.
This MR was tested with:
- 3rd-party gNB
- 2 OAI-gNB-DUs
The neighboring cell measurements and measurement report of event A3 for OAI-UE
are working as expected.
CORESET 0 is configured in the configuration file by 'initialDLBWPcontrolResourceSetZero' and PDSCH TDA list is configured based on the current BWP size.
It may happen that the user configures a 2 symbol CORESET 0 for a BWP >= 48 PRBs (which is a valid 3GPP configuration) but in function 'nr_rrc_config_dl_tda' this scenario is not taken in account causing an overlap between PDSCH and PDCCH symbols.
This leads to very unreliable Msg2 and Msg4 decoding at the UE, but from time to time it succeeds, which becomes hard to identify this issue.
Correct how the slot for SIB1 is computed in case of MUX pattern 2 and 3.
Renamed n_0 to slot for clarity. n_c was never used outside of the function, so
remove it where it is not used.
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
maki
Jaroslava Fiedlerova