Operations, maintenance and configuration of telecom systems are performed from remote through the usage of standard interface protocols (SNMP, NETCONF, RESTCONF, …) which are serviced by commercial or open source servers running on board. These make a good job at identifying message chunks, managing multiple clients, and checking for the formal consistency of values written to the parameters of the model, on the external (“northbound”) interface. The system O&M application connects to their internal (“southbound”) interface in the form of plugins. From this point, everything is custom.
The main problem of an O&M application, albeit for trivial ones where every manageable component is reachable right from the plugins (e.g. linking a firmware library), is delivering a big amount of possible event triggers, i.e. the read/write of parameters, deep into the system and also reacting to spontaneous notifications that go through the opposite way. After processing logical constraints, all the signals have to reach the correct destination where every macro-component, because of complexity, might have a dedicated handler in the form of a controller daemon.
This is certainly the case of an O-RAN RU system, where the M-plane model encompasses thousands of parameters in both directions.
How to create an efficient transport of these signals then? If each one of them required the management of a unix or TCP socket, the system would rapidly become bloated with similar code, but also sharing one socket per daemon, and then use a big case statement to route the messages, would be all but safe and efficient.
Azcom Technology solved this problem in its 4G equipment and now is able to reuse the solution for the O-RUs. We developed a proprietary middleware that allows a server and the clients to become peers and communicate without the need to know the actual positioning of the counterpart, thus also allowing flexible refactoring of the system. The model serviced by the middleware is idempotent to the Yang model of O-RAN M-plane and can always be inspected by GUI or CLI tools as an organic whole, no matter where the peers are. A client can listen to changes of a server and be notified in real-time, thus making the management of async notifications a trivial task.
The AzBus middleware allows creating and referencing service objects just as if they were local variables of the type they represent, thanks to C++ assignment and casting operators overloading. All the protocol complexity is therefore hidden and the outcome summarized in a status flag.
In synthesis, the components that need to obey to configuration commands just need to declare on the bus the existence of the configuration endpoint using an identifier path derived from the Yang models; then, the service can be looked for from anywhere using the path as a reference, and a “smart handler” is returned, which can be read and assigned as an ordinary variable.
In this way, a hardware abstraction API can be created deep into the system, exactly where the configuration commands can apply the intended action. Azcom provides the system-agnostic parts of the hardware abstraction API, thus pushing the frontier of reusability from the external protocol down into the deep. The southbound plugins would never be changed and are the same for every O-RU implementation. Every kind of controller daemon can easily step into the bus metaphore.
This is a great starting point for M-plane integration in an O-RU project with a very custom shape for what concerns the CUS-plane. When developing a system, the middleware can easily allow simulating missing elements too.
