Posts

lighty.io runs 5G on xRAN

In April 2018, the xRAN forum released the Open Fronthaul Interface Specification. The first specification made publicly available from xRAN since its launch in October 2016. The released specification has allowed a wide range of vendors to develop innovative, best-of-breed remote radio unit/head (RRU/RRH) for a wide range of deployment scenarios, which can be easily integrated with virtualized infrastructure & management systems using standardized data models.

This is where PANTHEON.tech came to the scene. We became one of the first companies to introduce full stack 5G compliant solution with this specification.

Just a few days spent coding and utilizing the readily available lighty.io components, we created a Radio Unit (RU) simulator and an SDN controller to manage a group of Radio Units.

Now, let us inspect the architecture and elaborate on some important details.

We have used lighty.io, specifically the generic NETCONF simulator, to set up an xRAN Radio Unit (RU) simulator. xRAN specifies YANG models for 5G Radio Units. lighty.io NETCONF device library is used as a base which made it easy to add custom behavior and 5G RU is ready to stream data to a 5G controller.

The code in the controller pushes the data collected from RUs into Elasticsearch for further analysis. RU device emits the notifications of simulated Antenna Line Devices connected to RU containing:

  • Measured Rx and Tx input power in mW
  • Tx Bias Current in mA (Internally measured)
  • Transceiver supply voltage in mV (Internally measured)
  • Optional laser temperature in degrees Celsius. (Internally measured)

*We used device xRAN-performance-management model for this purpose.

lighty.io as a 5G controller

With lighty.io we created an OpenDaylight based SDN controller that can connect to RU simulators using NETCONF. Once RU device is connected, telemetry data is pushed via NETCONF notifications to the controller, and then directly into Elasticsearch.
Usually, log stash is required to upload data into Elasticsearch. In this case, it is the 5G controller that is pushing device data directly to Elasticsearch using time series indexing.
On Radio Unit device connect event, monitoring process automatically starts. RPC-ald-communication is called on RU device collecting statistics for:

  • The Number of frames with incorrect CRC (FCS) received from ALD – running counter
  • The Number of frames without stop flag received from ALD – running counter
  • The number of octets received from HDLC bus – running counter

*We used xran-ald.yang model for this purpose.
The lighty.io 5G controller is also listening to notifications from the RU device mentioned above.

Elasticsearch and Kibana

Data collected by the lighty.io 5G controller via RPC calls and notifications are pushed directly into Elasticsearch indices. Once indexed, Elasticsearch provides a wide variety of queries upon stored data.
Typically, we can display several faulty frames received from “Antenna Line Devices” over time, or analyze operational parameters of Radio Unit devices like receiving and transmitting input power.
Such data are precious for Radio Unit setup, so the control plane feedback loop is possible.

By adding Elasticsearch into the loop, data analytics or the feedback loop became ready to perform complex tasks. Such as: Faulty frame statistics from the “Antenna Line Devices” or the  Radio Unit operational setup

How do we see the future of xRAN with lighty.io?

The benefit of this solution is a full stack xRAN test. YANG models and its specifications are obviously not enough considering the size of the project. With lighty.io 5G xRAN, we invite the Radio Unit device vendors and 5G network providers to cooperate and build upon this solution. Having the Radio Unit simulators available and ready allows for quick development cycle without being blocked by the RU vendor’s bugs.

lighty.io has been used as a 5G rapid application development platform which enables quick xRAN Radio Unit monitoring system setup.
We can easily obtain xRAN Radio Unit certification against ‘lighty.io 5G controller’ and provide RU simulations for the management plane.

Visit lighty.io page, and check out our GitHub for more details.

PANTHEON.tech releases lighty.io version 9.0

OpenDaylight Fluorine 9 LogoPANTHEON.tech is proud to announce the release of lighty.io 9.0 following the official  OpenDaylight Fluorine release.

lighty.io has been adapted to reflect the latest upstream changes and made fully compatible with.

Check out our latest lighty.io release on our GitHub account.

Here are some noteworthy improvements what OpenDaylight Fluorine established:

  •  Yangtools cleanup and refactoring.
  •  Streamlined generated Yang module APIs.
  •  Improved Java bindings.
  •  NETCONF and RESTCONF improvements.

The biggest ODL improvement is the new set of core services provided by the MD-SAL project. Older services provided previously by the controller project have been marked as dprecated and will be removed in future ODL/lighty.io releases.

lighty.io provides new MD-SAL services as well as deprecated controller implementations.

Please see lighty.io Services for reference.

If your application uses any of the deprecated marked services, you should consider refactoring. Contact us for any troubleshooting requirements.

In addition to the latest ODL improvements, lighty.io has more to offer:

  • Up-to-date web server Jetty 9.4.11.v20180605 with better HTTP2 support.
  • RESTCONF implementations are now in compliance with HTTP2.
  • YANG actions implementation as it was defined in RFC 7650.
  • gNMI / OpenConfig south-bound plugin.
  • Minor changes leading the controller to startup faster
  • Improved Javadoc for main APIs.
  • The easier pathway towards JDK 11 adoption.
  • Spring.io dependency injection integration.
  • And many more, please check them out on the lighty.io web.

List of new and deprecated services:

List of new MD-SAL services:  List of deprecated services:
org.opendaylight.mdsal.binding.api.DataBroker

org.opendaylight.mdsal.binding.api.MountPointService

org.opendaylight.mdsal.binding.api.NotificationPublishService

org.opendaylight.mdsal.binding.api.NotificationService

org.opendaylight.mdsal.binding.api.RpcProviderService

org.opendaylight.mdsal.binding.dom.codec.api.BindingCodecTreeFactory

org.opendaylight.mdsal.binding.dom.codec.api.BindingNormalizedNodeSerializer

org.opendaylight.mdsal.dom.api.DOMDataBroker

org.opendaylight.mdsal.dom.api.DOMDataTreeService

org.opendaylight.mdsal.dom.api.DOMDataTreeShardingService

org.opendaylight.mdsal.dom.api.DOMMountPointService

org.opendaylight.mdsal.dom.api.DOMNotificationPublishService

org.opendaylight.mdsal.dom.api.DOMNotificationService

org.opendaylight.mdsal.dom.api.DOMRpcProviderService

org.opendaylight.mdsal.dom.api.DOMRpcService

org.opendaylight.mdsal.dom.api.DOMSchemaService

org.opendaylight.mdsal.dom.api.DOMYangTextSourceProvider

org.opendaylight.mdsal.dom.spi.DOMNotificationSubscriptionListenerRegistry

org.opendaylight.controller.sal.binding.api.NotificationProviderService

org.opendaylight.controller.sal.binding.api.RpcProviderRegistry

org.opendaylight.controller.md.sal.dom.spi.DOMNotificationSubscriptionListenerRegistry

org.opendaylight.controller.md.sal.dom.api.DOMMountPointService

org.opendaylight.controller.md.sal.dom.api.DOMNotificationPublishService

org.opendaylight.controller.md.sal.dom.api.DOMNotificationService

org.opendaylight.controller.md.sal.dom.api.DOMDataBroker

org.opendaylight.controller.md.sal.dom.api.DOMRpcService

org.opendaylight.controller.md.sal.dom.api.DOMRpcProviderService

org.opendaylight.controller.md.sal.binding.api.MountPointService

org.opendaylight.controller.md.sal.binding.api.NotificationService

org.opendaylight.controller.md.sal.binding.api.DataBroker

org.opendaylight.controller.md.sal.binding.api.NotificationPublishService

 lighty.io by PANTHEON.tech