Per TS 33.501 6.9.2.3.4 and Fig 6.9.2.1.1-1, when sending
RRCReestablishment with nextHopChainingCount, the gNB is staying at
the same NCC level (not advancing). Therefore, horizontal derivation
from the currently active KgNB must be used, not vertical derivation
from NH.
Vertical derivation (from NH) is only used when advancing to a new
NCC level, which happens during handover or masterKeyUpdate procedures.
The previous implementation incorrectly used vertical derivation from
NH whenever nh_ncc > 0, which caused key mismatch between gNB and UE
during reestablishment after handover, leading to integrity check
failures.
This fix ensures both gNB and UE use horizontal derivation when
nextHopChainingCount matches the current NCC level, aligning with the
specification's "virtual NH at NCC=0" model where:
- Horizontal derivation = derive KNG-RAN* from currently active KgNB
- Vertical derivation = derive KNG-RAN* from NH (only when advancing NCC)
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.
The RNTI from the target context was not updated after HO acknowledge
this led to a failure in the first re-establishment after HO.
This commit is introducing the function nr_rrc_apply_target_context
in nr_rrc_n2_ho_acknowledge() and also updates the cell ID for
consistency.
Refactor handover target context application logic into a reusable
function nr_rrc_apply_target_context() that updates both F1AP
associations (secondary UE and DU association) and RNTI from the
target handover context.
And apply to rrc_CU_process_ue_context_modification_response()
Integration: `2025.w52`
* !3809 [FHI72] Fix the PRACH FFT size
* !3829 Hotfix for handling the case where the number of physical antennas is larger than the number of logical antennas
* !3663 NR UE: calculate DL and UL Doppler based on SIB19 information in NTN mode, fixing LEO reestablishment
* !3819 CORESET start multiple of 6 fix
* !3641 automatic selection of SIB1 TDA
* !3804 gNB: apply new NR_CellGroupConfig when RRCReconfiguration is acknowledged
* !3833 Add missing CMakeLists entries for test_nr_frame_params
* !3656 Rfsimulator beam reception/transmission
Closes#1037 and #1002
See merge request oai/openairinterface5g!3830
Rfsimulator beam reception/transmission
A simplified beam switching simulation for rfsimulator. This works
mainly in 1 gNB - N UEs scenarios. This is not a real beamformer with
antenna, channel and propagation model. The way it works is that the
peers inform each other about the beams they transmit in, and on
reception before channel modelling, the beam data is combined based on
preconfigured rx_beam/tx_beam gain matrix.
Usage:
- Add --rfsimulator.enable_beams to enable beam simulation
- Add --rfsimulator.beam_gains .
Example list: 0,-5,-10
Resulting matrix:
[[0, -5, -10] [-5, 0, -5]] [-10, -5, 0]]
- Add --telnetsrv if you want to control the beams manually. The command
in telnet is "rfsimu setbeam <beam_map>", where beam_map is a uint64_t
controling the reception beam and transmission beam. If the
application is switching the beams automatically the beams will be
overwritten as soon as the application chooses to switch beams.
Supports up to 64 concurrent TX and RX beams.
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
Add CLI parameter rfsimulator.beam_ids which uses a list of beam ids instead of a
beam map. The beam map API is still present and can be used interchangably.
Add telnet command setbeamids which has similar semantics
Allow arbitrary order of beam ids in set_beams2 function. This
allows the application to select any arbitrary order of beam ids.
The underlying transport mechanism still uses beam_map so the beam_ids
are ordered before sending.
Also replaced tx_beam_map/rx_beam_map into beam_map.
Also fixed an issue where --rfsimulator.enable_beams required an argument.
- Added first beam optimization to combine_tx_buffers.
- Added first beam & first peer optimization to rfsimulator_read_internal
This results in significant speed up for the first rx beam, first tx
beam and first peer which is the base case with beam simulation disabled.
In rfsim, received packets are dynamically allocated and freed when no longer
needed, which is dependent on the channel model, packet timestamp and packet
size (number of samples carried).
This commit fixes the packet age check for channels with nonzero channel offset
(most notalby NTN channels).
Also present:
- extract the NTN satellite position update code to a separate function and
call it once per trx_read call instead of once per rx beam.
Add a set of macros with designated initializers to simplify using
paramdef_t arrays in C++ source code. Fix clang error with
RFSIMULATOR_PARAMS_DESC using mixed designated and non-designated
initializers.
- Received packets are dynamically allocated and kept in a
queue for as long as they are needed.
- The layout of the packets was changed from interleaved antennas
to non-interleaved antennas.
- Generate a contiguous buffer from saved packets as needed.
There is extra work caused by this change due to recv() call no
longer saving data directly into the circular buffer, however further
processing is easier due to contiguous nature of the tx antenna buffers
prepared. The impact on performance was not measured.
A simplified beam switching simulation for rfsimulator. This works
mainly in 1 gNB - N UEs scenarios. This is not a real beamformer with
antenna, channel and propagation model. The way it works is that the
peers inform each other about the beams they transmit in, and on
reception before channel modelling, the beam data is combined based on
preconfigured rx_beam/tx_beam gain matrix.
Usage:
- Add --rfsimulator.enable_beams to enable beam simulation
- Add --rfsimulator.beam_gains <comma separated Toepliz form matrix of gains in dB>.
Example list: 0,-5,-10
Resulting matrix:
[[0, -5, -10]
[-5, 0, -5]]
[-10, -5, 0]]
- Add --telnetsrv if you want to control the beams manually. The command in telnet
is "rfsimu setbeam <beam_map>", where beam_map is a uint64_t controling the
reception beam and transmission beam. If the application is switching the beams
automatically the beams will be overwritten as soon as the application chooses to
switch beams.
Co-authored-by: Laurent Thomas <laurent.thomas@open-cells.com>
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
[FHI72] Fix the PRACH FFT size
ru_config->fftSize is used for the C-plane Section Type 3 which is
dedicated for PRACH and mixed numerology. Previously, we assumed that
PRACH FFT size is equivalent to PxSCH FFT size, but should be based on
the PRACH format.
Tests with the following RUs:
- [x] Benetel v1.2.2 & v1.4.1
- [x] VVDN Gen 3
- [x] Liteon 02.00.10
- [x] Metanoia v2.2.8 (Jura)
Integration `2025.w51`
* !3816 Add two missing include guards
* !3715 Pass beam ID as per FAPI v222.10
* !3777 UE NTN : Fix in case SIB19 periodicity is greater than 2 secs
* !3813 Reset outdated PUCCHs to avoid Assertion caused by non-processed and active PUCCHs
* !3815 Remove phy_extern_nr_ue file
* !3824 CI: adjust UE attach timeout handling
* !3735 vrtsim: Optimize channel modelling
See merge request oai/openairinterface5g!3817
Per TS 33.501 6.9.2.3.4 and Fig 6.9.2.1.1-1, when sending
RRCReestablishment with nextHopChainingCount, the gNB is staying at
the same NCC level (not advancing). Therefore, horizontal derivation
from the currently active KgNB must be used, not vertical derivation
from NH.
Vertical derivation (from NH) is only used when advancing to a new
NCC level, which happens during handover or masterKeyUpdate procedures.
The previous implementation incorrectly used vertical derivation from
NH whenever nh_ncc > 0, which caused key mismatch between gNB and UE
during reestablishment after handover, leading to integrity check
failures.
This fix ensures both gNB and UE use horizontal derivation when
nextHopChainingCount matches the current NCC level, aligning with the
specification's "virtual NH at NCC=0" model where:
- Horizontal derivation = derive KNG-RAN* from currently active KgNB
- Vertical derivation = derive KNG-RAN* from NH (only when advancing NCC)
Refactor key derivation logic to properly handle Next Hop (NH) chain
synchronization according to 3GPP TS 33.501 specifications for both
RRC Reestablishment and Master Key Update procedures.
Changes in rrc_gNB.c:
- Clarify key derivation in rrc_gNB_generate_RRCReestablishment by
explicitly selecting base key (NH or KgNB) based on nh_ncc value
- Add comment explaining vertical vs horizontal derivation logic
Changes in rrc_UE.c:
- Add nr_sync_nh_chain(): Common helper to synchronize NH parameter
chain per TS 33.501 Annex A.10, supporting both Master Key Update
and RRC Reestablishment procedures
- Add nr_derive_kgnb_horizontal(): Derive KNG-RAN* from current KgNB
when NCC values match (horizontal derivation per TS 33.501 A.11/A.12)
- Add nr_derive_kgnb_vertical(): Derive KNG-RAN* from synchronized NH
after NH chain sync (vertical derivation per TS 33.501 A.11/A.12)
- Add nr_update_kgnb_from_ncc(): Unified function implementing TS 33.501
6.9.2.3.4 logic for updating KgNB based on received nextHopChainingCount
- Refactor as_security_key_update(): Use new nr_update_kgnb_from_ncc()
helper function for cleaner, more maintainable code
- Fix nr_rrc_ue_process_rrcReestablishment(): Properly handle received
nextHopChainingCount and update KgNB using unified helper function
- Add debug logging for key derivation process
Key NAS deriver utils:
- update derive_kgnb documentation and protect input keys with const attribute
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.
Guido Casati