General
The purpose of this document is to describe the purpose of the E2 Terminator (E2T), how its architecture is built, what RAN methods it supports, what E2M / xAPP methods it supports.
RIC Hosts one or more “xApps” that use E2 interface to collect near Realtime information and provide value added services
RIC may obtain other information from “External sources” including ONAP, see Figure 1 RIC and its relation in the network.
RIC platform contains E2 termination, shared data and common functions to form the “RIC Platform”, running on a PaaS platform.
Common functions on RIC provide generic services (databases, ML tools, message bus, etc.) and have no role in RAN functionality
E2 termination is independent and binding messages to xApps, according RMR routing.
xApps, hosted on RIC Platform, provide RAN with services beyond functionality provided by BTS
RIC contains:
- E2 termination acting as RAN Function. The E2AP is done over SCTP Connection
- Central database assessible by xApps
- Multiple xApps including “E2 Manager” as xApp (0)
The service Bus, described in Figure 2 The RIC Platform, implemented by RMR.
Assumptions:
- RIC has E2 interface to one or more RAN nodes
- Each RAN node informs RIC of list of functions supporting RIC Services and the corresponding RIC Service Information Model
- xApps may address individual functions in specific RAN with messages routed via E2 termination in RIC and E2 agent in RAN
- Functions in specific RAN may respond to individual xApp in RIC with messages routed via E2 agent in RAN and E2 termination in RIC
- RIC E2 Termination acts as a RAN Function and provides both global procedures and RIC Services to a specialized “E2 Manager” xApp
ET Terminator Architecture
The E2T should supports the following:
- Open or remove SCTP Connection upon E2/EN-DC Setup or Removal
- Handle own repository to map RAN to SCTP Connection,
- Listen to all its SCTP Connection. Upon E2 method, decode it and sends it over the RMR to the relevant xAPP.
- Listen to the RMR Connection. Upon on RMR Request, convert it to E2AP, map the target RAN to SCTP Connection, decode it and sends it over the relevant SCTP.
Due to high performance and multiple connections, E2T is using epoll - a Linux kernel system call for a scalable I/O event notification mechanism. Its function is to monitor multiple file descriptors to see whether I/O is possible on any of them
So, E2T is one thread that listens (using epoll() ) to any event coming from E2 or from RMR, and accordingly handles the message.
2 Comments
allan martins
Hello,
Sorry if that is not the right forum for this question, but we are trying to implement a module to communicate via E2 with the E2T and are facing some doubts about the E2SM (in general). We have the mapping of the Ran Function OID to a specific service model (SM). Where do we find a list of OIDs and their respective ran function descriptions? Moreover, what is the difference between the Ran Function ID and OID? Is the OID a unique identifier and the ID allow us to have multiple SMs for the same Ran Function? (so that the Ran Function ID would be unique for THAT SM)?
Thoralf Czichy
That's the way it works. OIDs are static and defined by the standard (plus proprietary extensions). Function IDs are defined by the actual E2 node you communicate with. Multiple function IDs can exist for the same E2SM/OID. xApps need to find the right one based on the function definitions stored in RNIB, which have been transferred by the E2 node as part of the E2 Setup. Function definitions can change, or removed/added, e.g., if the E2 node configuration or software version changes. There's a diagram that, with its numbering, gives some idea on this in "IEEE ComSoc Bangalore" (slide 12 from the "part 1" slideset; in the video I decided to skip this slide due to time): Overall architecture (not component-specific).
The OIDs are standardized in table 5-2 of O-RAN.WG3.E2SM-R003-v03.00.