Reset CU-CP E1 UE context after E1 Setup Response
As in deba3ae0 ("Reset CU-UP E1 UE contexts after E1 Setup Response"), the CU-CP should reset the E1 UE contexts after E1 Setup Response. 38.463 sec. 8.2.3 says > This procedure also re-initialises the E1AP UE-related contexts (if > any) and erases all related signalling connections in the two nodes like > a Reset procedure would do. In the case of CU-CP, this is a bit more complicated. More precisely, we need to wait for the CU-UP to be available again before informing the DU about the loss (implemented via an F1 Reset message), because otherwise, the UE might reconnect immediately, before the CU-UP is online again. Hence, on connection loss, we mark affected UEs (by setting their E1 association ID to 0); as long as the CU-UP does not connect, nothing will happen (but UEs don't have user plane). Upon CU-UP connecting again, we request release of the UEs via NGAP (similarly to what is done if the DU goes offline, see invalidate_du_connections()), free the UE contexts locally, and send an F1 Reset message to the DU, because 38.473 sec 8.2.1.2.1 says > a failure at the gNB-CU [...] has resulted in the loss of some or > all transaction reference information [...] a RESET message shall be > sent to the gNB-DU. The core should accept and send an NGAP release command message; since no UE contexts are to be found (already deleted), the CU-CP will just send a release complete (together with some warnings). It might be possible to more gracefully handle the situation (e.g., as described in 38.401 section 8.9.5 "Change of gNB-CU-UP"), but - we lack the PDCP SN exchange - the current procedure has the advantage of being equivalent to "restart of the entire gNB", with less downtown.
Showing
Please register or sign in to comment