CU-UP UE Management: E1 vs. integrated CU

The CU-UP UE ID management is not implemented properly. Currently, functions e1_bearer_context_setup() and e1_bearer_release_cmd() add and remove CU UE IDs using cu_add_f1_ue_data() and cu_remove_f1_ue_data(). This is problematic, as these functions use hashtables used by the CU-CP to correlate DU UE IDs and CU UE IDs; currently, for adding, it is not a problem because a second write of a CU UE ID does not overwrite an entry. However, removing the entry too early in e1_bearer_release_cmd() can lead to asserts in an integrated CU if the CU-CP/RRC uses the lookup function cu_get_f1_ue_data() afterwards. A temporary workaround is to check in the handler if we really run in E1: if yes, we add/remove the IDs using the hashtables; if not, we don't do anything

This workaround however forces us to use the same CU-UP UE ID in PDCP/RRC, which might have repercussions w.r.t. to interoperability, if we ever want to interoperate CU-CP/UP with something that delivers different UE IDs (because we cannot look up a conversion of CU-CP UEID to CU-UP UE ID). Thus, a natural solution would be to establish a third hashtable (changing all cu_*_f1_ue_data() to cucp_*_f1_ue_data() for CU-CP and cuup_*_f1_ue_data() for CU-UP, next to the existing du_*_f1_ue_data()). However, then we have to use the CU-UP variants when forwarding UP packets in PDCP down to RLC because it has to work in E1. But since the PDCP calls directly into the RLC in monolithic, it will do so with the wrong IDs, looking up the CU-CP UE ID instead of the DU UE ID as done currently when using the CU-CP hashtable. Simply, the CU-UP has no notion of the RNTI used at RLC, and in the E1/F1 split case, GTP manages the conversion through TEIDs; in the monolithic case, we don't have the right ID if adding the new functions.

To fix that problem, we might therefore use (dummy) TEIDs between RLC and PDCP. However

• we need to implement the infrastructure to look up these IDs, or somehow store it at RLC and PDCP;
• the F1 message encoding/decoding does the GTP tunnel creation: it should be moved to the handlers in mac_rrc_dl_handler.c to either use the real TEID, or set up a fake TEID and give that to RLC when creating a new bearer.
• same for PDCP;
• currently, we send data through GTP by giving it a UE ID + RBID, but in this case and in general, it would make more sense to expose the TEID from GTP directly, simplifying the GTP module;
• after changing the RLC/PDCP interface, everything should still work using RNTI + RB ID in the UE.

Since all of this is a lot of work, a temporary workaround has been implemented (see !2428 (merged)).