An error occurred fetching the project authors.
- 25 Oct, 2024 12 commits
-
-
Robert Schmidt authored
This commit implements reestablishment during handover when occurring at the source DU, either as a handover Failure or "normal" reestablishment (something else went wrong). In this case, the CU will trigger HO cancel, which in F1, means to cancel on the target DU. Also, undo any previous ID changes. Retain the old CellGroupConfig (before handover) for the case of reestablishment at source. If not needed, it is freed after the reconfiguration complete. Reestablishment on target cell during handover cannot be handled by the gNB (yet). It is the same as with a normal reestablishment (not during handover) on a different cell: that cell has no notion of the old UE, so we cannot simply indicate the old UE to reestablish; at least, we would need to cleanup the CellGroupConfig, and I am not sure this works out of the box, either.
-
Robert Schmidt authored
After handover, the last CellGroupConfig received is the one for handover, containing a reconfigurationWithSync. Resending this CellGroupConfig to the UE after reestablishment would trigger a handover. Free the reconfigurationWithSync to have the UE complete reestablishment at the current cell. The CU implementation of reestablishment modifies the CellGroupConfig. It should not do this, but does as of now. The specification (38.473 Sec 8.7) foresees an optional F1 UE context modification procedure (which can be used to receive the CellGroupConfig). This should be done instead to retrieve the correct CellGroupConfig. Note that the F1 UE context setup procedure, similar to the UE context modification procedure, would also allow to perform reestablishment on a DU that is not the original one.
-
Robert Schmidt authored
If we release a request from a DU during, handle as follows: - from the source: Handover is still ongoing, so ignore it by acknowledging the release, and marking handover as done. In this case, we did not receive an acknowledgement from the target, but since the source DU does not keep the UE context, we could not cancel the handover anymore either. The UE might come back on any DU through reestablishment (or simply be connected on the target) - from the target: consider this to be a genuine release, and forward to AMF. Co-authored-by:
batuhanduyuler <batuhan.duyuler@firecell.io> Co-authored-by:
rmagueta <rmagueta@allbesmart.pt>
-
Robert Schmidt authored
The HO is completed (from a pure RAN perspective) when receiving reconfiguration complete. In that case, remove the HO context, and signal successful handover through the callback. For the F1 handover, this means releasing the UE at the source DU. Co-authored-by:
batuhanduyuler <batuhan.duyuler@firecell.io> Co-authored-by:
rmagueta <rmagueta@allbesmart.pt>
-
Robert Schmidt authored
We expect the UE's RRC Reconfiguration Complete to come through the target DU, as the "new UE" at the target CU. Also, function CU_handle_UL_RRC_MESSAGE_TRANSFER() checks that the UL RRC Message, through which we will receive RRC Reconfiguration Complete, matches the DU UE ID stored in RRC. Since the DU UE ID will be the one at the target DU, while up to now, we stored the DU UE ID at the source DU. Correspondingly, update the DU UE ID to the one at the target DU; also update the corresponding assoc_id. Co-authored-by:
batuhanduyuler <batuhan.duyuler@firecell.io> Co-authored-by:
rmagueta <rmagueta@allbesmart.pt>
-
Robert Schmidt authored
In this commit, handle the reception of a UE context setup response, in the case of handover. In that case, store the gNB-DU UE ID and C-RNTI of the UE at the target DU, and trigger a reconfiguration towards the UE at the source DU via the callback. To ensure that the CU-UP's PDCP is SN-aligned with the UE, use cuup_notify_reestablishment() to reset the bearers with PDCP reestablishment, which has already been implemented in the last commit. Co-authored-by:
batuhanduyuler <batuhan.duyuler@firecell.io> Co-authored-by:
rmagueta <rmagueta@allbesmart.pt>
-
Robert Schmidt authored
This is preparatory work to handle the UE context setup response from the target DU. There are two cases: - "Initial" UE context setup response (during connection setup): we need to inform the CU-UP via an E1 message of the new bearers (GTP tunnel update) - F1 handover: we need to inform the CU-UP via an E1 message that there are DRBs to reestablish There are two different functions, e1_send_bearer_updates() and cuup_notify_reestablishment(), to do this. Harmonize the code, before implementing the actual handover logic in the next commit.
-
Robert Schmidt authored
Functions get_qos_char_from_qos_flow_param() and get_qos_characteristics() will be used in rrc_gNB_mobility.c to read PDU information for handover. Move the definitions to a header to reuse later.
-
Robert Schmidt authored
-
Robert Schmidt authored
This F1 message sends us the CellGroupConfig of the UE. Store it in case we need it. For instance, at least in OAI, it is possible to make a handover without a DRB (this might or might not be standard compliant). However, in this case, we did never receive a UE context setup request, which stores the CellGroupConfig. Hence, store the first CellGroupConfig we receive, to be able to do e.g., handover.
-
Robert Schmidt authored
RETURN_IF_INVALID_ASSOC_ID() checks if an assoc_id (of a DU) is valid. It will be also used in the mobility RRC module later. Move it to the DU header (where it logically belongs) to move it from there.
-
Roberto Magueta authored
Co-authored-by:
Luis Pereira <lpereira@allbesmart.pt>
-
- 22 Oct, 2024 1 commit
-
-
Robert Schmidt authored
Refactor the RRC reconfiguration function to reuse it also later for sending the reconfiguration including the handover trigger.
-
- 17 Oct, 2024 20 commits
-
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Pass RRC and UE context pointers directly.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Pass UE context pointer directly. In the switch, do not return to not create memory leaks (after the switch, memory is freed). Move the function up to make it appear before the use of the function.
-
Robert Schmidt authored
The xer_fprintf() call is already present in rrc_gNB_decode_dcch() above.
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
-
Robert Schmidt authored
Pass UE context, without protocol_ctxt_t, for cleanup. Remove the return from within the switch, as this would lead to memory leaks; nothing is executed after the switch statement (except for freeing memory).
-
Robert Schmidt authored
-
Robert Schmidt authored
A UE might send a MeasurementReport without the actual IEs present (intentionally or not). Check this and handle appropriately to avoid assertion Assertion (measurementReport->criticalExtensions.present == NR_MeasurementReport__criticalExtensions_PR_measurementReport && measurementReport->criticalExtensions.choice.measurementReport != ((void*)0)) failed! In rrc_gNB_process_MeasurementReport() ../../../openair2/RRC/NR/rrc_gNB.c Closes: #859
-
Robert Schmidt authored
A UE might send a UE Capability Information without unsolicitatedly (intentionally or not). Check this and handle appropriately to avoid assertion Assertion (UE->xids[xid] == RRC_UECAPABILITY_ENQUIRY) failed! In handle_ueCapabilityInformation() ../../../openair2/RRC/NR/rrc_gNB.c Closes: #858
-
Robert Schmidt authored
A UE might send a rrcReestablishmentComplete without the actual IEs present (intentionally or not). Check this and handle appropriately to avoid assertion Assertion (reestablishment_complete->criticalExtensions.present == NR_RRCReestablishmentComplete__criticalExtensions_PR_rrcReestablishmentComplete) failed! In handle_rrcReestablishmentComplete() ../../../openair2/RRC/NR/rrc_gNB.c:1364 Closes: #854
-
Robert Schmidt authored
-
- 16 Oct, 2024 2 commits
-
-
Robert Schmidt authored
Cleanup this function: pass UE context directly, remove protocol_ctxt_t.
-
Robert Schmidt authored
Pass directly pointer to UE context, remove protocol_ctxt_t (which simply is not required, and supposed to be removed anyway).
-
- 27 Sep, 2024 2 commits
-
-
Guido Casati authored
-
Robert Schmidt authored
Co-authored-by:
Guido Casati <hello@guidocasati.com>
-
- 25 Sep, 2024 2 commits
-
-
Robert Schmidt authored
Co-authored-by:
Guido Casati <hello@guidocasati.com>
-
Robert Schmidt authored
The currently used type does not cover all possibilities. While we don't encode&decode them, it might still be good to be able to express it, so introduce the new type. Co-authored-by:
Guido Casati <hello@guidocasati.com>
-
- 11 Sep, 2024 1 commit
-
-
Cedric Roux authored
-