Posts

[Release] OpenDaylight Sodium, YANG Tools & MD-SAL

It is no secret, that OpenDaylight is more than a passion project here at PANTHEON.tech. As one of the staples in the SDN revolution, we are also proud that we are one of the largest contributors to the project, with our CTO Robert Varga leading in the number of individual commits. Let us have a look at what is new.

YANG Tools 3.0.0

YANG Tools is a set of libraries and data modeling language, used to model state & configuration data. It’s libraries provide support for NETCONF and YANG for Java-based projects and applications.  What’s new in the world of the latest Yangtools release?

It implements new RFCs: RFC7952 (Defining and Using Metadata with YANG) and RFC8528 (YANG Schema Mount).

YANG parser now supports RFC6241 & RFC8528, while adding strict QName rules for “node identifiers”.

JDK11 support has been added together with lots of small bugfixes, which you can read in detail in its changelog.

MD-SAL 4.0.0

The Model-Driven Service Abstraction Layer is OpenDaylight’s kernel – it interfaces between different layers and modules. MD-SAL uses APIs to connect & bind requests and services and delegates certain types of requests.

The new version of MD-SAL has been released for ODL. MD-SAL is one of the central OpenDaylight components. This release contains mainly bugfixes and brings pre-packaged model updates for newly released IETF  models: RFC8519, RFC8528, RFC8529, RFC8530.

Get ready for OpenDaylight Sodium

OpenDaylights development has a new important milestone ahead: the Sodium release, currently scheduled around September 2019. This release will bring new versions of YANG Tools, MD-SAL and other core OpenDaylight components.

JDK11, as well as JKD8, is supported, providing an opportunity for OpenDaylight users to try new features of JDK11. It bids farewell to Java EE modules & JavaFX, as well as performance & bug fixes.

We believe you are also looking forward to these releases and encourage you to try them out!

Don’t forget to contact us, in case you are interested in a commercial solution for your business!


You can contact us at https://pantheon.tech/

Explore our Pantheon GitHub.

Watch our YouTube Channel.

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