by OAM before the F1 Setup procedure takes place. During the F1 interface operation, a gNB-DU can inform the gNB-CU about configu- ration changes using the gNB-DU Configuration Update procedure. Similar to gNB-DU, the gNB-CU can use the gNB-CU Configuration Update procedure to inform any of the gNB-DUs about changes on its side. For example, a gNB-DU may indicate to a gNB-CU when new cells are configured, previously configured cells are removed, or existing cell configuration (e.g. Cell Global Identifier [CGI] or System Information [SI] is changed. Note that the configuration update procedure names are somewhat misleading, as these are not used to update the configuration (this is done via OAM), but to notify the other network node about the configuration update that has already taken place. The gNB-CU Configuration Update procedure is used for: Activation and de-activation of cells in a gNB-DU; Addition, removal, and update of TNL associations; Indication of cells to be barred; Information transfer on LTE/NR co-existence. A gNB-CU can request a gNB-DU to activate cells (among those that can be served by the gNB-DU, as configured by OAM and indicated to the gNB-CU during F1 Setup or gNB-DU Configuration Update). Along with the activation indication, a gNB-CU sends information such as the list of available PLMNs and a container with part of the SI, which is controlled by a gNB-CU. When certain cells are no longer needed, for example, owing to energy saving or other reasons, a gNB-CU can request to deactivate them. As mentioned above, a single F1 interface can use multiple TNL associations to support RAN deployment in virtualized environments. In such cases, a gNB-CU may be deployed, for example, in a server farm with multiple computational resources and multiple network interfaces. One of the key features of virtualized deployments is the capability to add compu- tational resources "on the fly" and to this end the F1 interface allows addition and removal of TNL associations. This is performed using the gNB-CU Conf