other RAN control-plane application protocols. Figure 4.4.1 zooms in on NG-RAN and does not show the 5GC and other NG-RAN network nodes; however, from the overall 5GS perspec- tive the control-plane interfaces NG-C and Xn-C are terminated in the gNB-CU-CP, while user-plane interfaces NG-U ¹ and Xn-U are terminated in the gNB-CU-UP (or directly in the gNB-DU). As mentioned above, this is defined in such a manner that the 5GC or the other NG-RAN network nodes are not exposed to the details of the NG-RAN architecture. More details about the overall NG-RAN architecture can be found in the 3GPP specifica- tion (3GPP TS S 38.401). 4.4.3.1 Control Plane Unlike most other NG-RAN interfaces (e.g. F1 and Xn), E1AP is a pure control-plane pro- tocol, as there is no need to carry user data between the control- and user-plane network 11 Referred to as N2 in 3GPP specifications describing 5GC. 4.4 Control-User Plane Separation nodes. Similarly to F1-C and other NG-RAN control-plane interfaces, E1 relies on SCTP, which provides reliable transport for in-sequence delivery of E1AP messages. E1AP func- tionalities can be categorized as follows: Interface management procedures Bearer context management procedures. Note that, unlike many other NG-RAN interfaces, formally there is no "UE management" procedure - the high-level gNB-CU-CP design principle is that it operates on bearers, rather than UEs. Therefore, unlike, for example, an Xn interface, there is no notion of "UE context establishment" on E1. However, a UE context is implicitly established using the Bearer Context Setup procedure and is identified by a pair of gNB-CU-CP and gNB-CU-UP E1AP identifiers. Moreover, some bearer management procedures (e.g. the Bearer Context Setup Request) carry some UE-specific information (e.g. UE inactivity timer). As for all other RAN interfaces, E1AP procedures can be class 1 (request and response) and class 2 (single message). In E1AP design, provisions have been made to facilitate the deployment of a gNB-CU-UP node in a virtualized enviro