The F1AP UE context release procedure can happen in at least two cases:
1. core requested a release of a UE
2. CU requests DU a release of a UE without a core release (e.g.,
handover)
In case 1., the CU has to fully release the UE in the CU, then ack the
NGAP message from the core, whilst in 2., nothing of that should happen
after the DU acknowledges the F1AP UE context release cmd.
cuup_notify_reestablishment() used
&ue_p->established_drbs[drb_id]
to look up a bearer, which is wrong, because it should be drb_id - 1
as in the top of the loop. Also, it used the dedicated get_drb()
function; harmonize to use only this function.
A follow-up commit refactors the filling of information of DRBs to set
up in a separate function (to be reused for handover later). Hence, we
cannot store the DRB TEID/address in the same functions, because it is
a logically separate step, and might not always be available.
In e1_send_bearer_updates(), we send the DL (DU) TEID and address to the
CU-UP. Therefore, correct the variable names to reflect that the F1-U
information pertains to the DU.
Also, move the tunnel info update function f1u_dl_gtp_update() to a more
prominent place, and take the pointer to the struct containing the
"interesting" information.
A maximum RRC buffer size of 1024 might be very small. We should
increase it, but then the 5G RRC_BUF_SIZE does conflict with other
definitions. To make it unique, also rename to NR_RRC_BUF_SIZE.
Always set the firstActive and defaultBWP in the initial
cellGroupConfig. This is necessary to make the Quectel accept the
handover RRCReconfiguration; it seems that this also works reliably in
normal connection set up, so we can add it.
Pass consistently the NR_timer_t object through a pointer. Since we have
to modify all occurrences of is_nr_timer_active(), we use that occasion
and rename that function to nr_timer_is_active() to make it consistent
with all other functions, starting with nr_timer.
Reorganize the sequence of checks done in reestablishment to make it
more logical:
- check conditions of request (correct C-RNTI)
- check conditions of DU (has MIB/SIB1, MTC)
- check the UE, and from which DU it comes
This will also help to extend it towards reestablishment coming from
different DUs in the case of handover.
Before this bug fix, when using F1, we get this warning:
Constraint validation failed: LCID: constraint failed (/home/richie/openairinterface5g/cmake_targets/ran_build/build/openair2/F1AP/MESSAGES/F1AP_LCID.c:30)
This is because (1) we don't actually store the LCID, then (2) we did
not put it into the F1 ASN.1 structures. Fix both, to make this warning
disappear.
To actually print the full error message, increase the error buffer
size. Also, for the future, to avoid guessing, print ASN.1 XML when we
encounter a failed constraint validation.
Jaroslava Fiedlerova