iguration Update procedure, which allows a gNB-CU to add, remove, and update TNL association information. To this 4.2 High-Level gNB-CU/DU Split end, gNB-CU TNL Association To Add List IE, gNB-CU TNL Association To Remove List IE, and gNB-CU TNL Association To Update List IE are used. The gNB-DU can also add and remove SCTP endpoints on its side; however, the procedure used is slightly different - a gNB-DU can add endpoints "implicitly" by simply initiating a SCTP connection from a new endpoint, but it must "explicitly" remove an endpoint using gNB-DU TNL Association To Remove List IE. There is no good technical reason for using two different procedures to achieve a very similar goal. Since LTE and 5G can share spectrum, a coordination mechanism (between gNB-CUs) has been defined to prevent co-existence issues. Information about which E-UTRA resources needs to be protected is exchanged between gNB-CUs via the Xn interface and propagated to gNB-DUs via the F1 interface, using the gNB-CU Configuration Update procedure and the Protected E-UTRA Resources List IE. In the case where a gNB-DU is experiencing an overload, it can indicate SO to the gNB-CU using the gNB-DU Status Indication class 2 procedure. This indication is rather coarse and is limited to "overloaded"/"not-overloaded" states. It can be used by the gNB-CU for load-balancing purposes, for example. More details about load in the DU can be deduced based on the per-bearer assistance information that is provided within the NR user plane (e.g. Average HARQ Failure or Power Headroom Report). This information may not always be available: first, it is part of the user plane and thus its usage for control-plane decisions requires implementation of cross-domain triggers; and second, in the case of dual connectivity, the NR user plane may connect the hosting node and the DU directly, SO the content is not available for the CU (dual connectivity is explained in Section 4.3). We further illustrate the concepts described above by one typical F1 interface manage- ment 