• Robert Schmidt's avatar
    Reset CU-CP E1 UE context after E1 Setup Response · e8661f5a
    Robert Schmidt authored
    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.
    e8661f5a
rrc_gNB_cuup.c 13.4 KB