RDK License

Operators are advised to get into an agreement with RDK Management LLC to obtain the free license so as to use the complete RDK Code base in their platform. More details about license is available at https://rdkcentral.com/licenses/ . Please email info@rdkcentral.com if you have additional questions about licenses or membership

The Operator can choose the preferable device from OEM and also get details from SoC vendors, SoC vendors will already have RDK ported on top of their SoC so they will be having all the features supported in SoC so based on that Operator's can select an OEM with preferred SoC platform and then they can start integrating features that Operator requires on top of the OEM layer so that they can have the final product.

This document will detail the recommended step-by-step procedure of adopting RDK by an Operator.

Product Specifications

The first step to getting a fully functional product is to define the product features and see if they meet the standard requirements. See here to know what are all the features available in RDK-B and can implement based on your requirement. Operators can use this as a guide while engineering the RDK Operator platform.

Device Firmware

Operators can make use of the details available below to start developing a Yocto build to do the final additions of Operator specific changes to the device. This will help Operator to add their own final product features as well as Operator specific patches/changes.

Yocto Manifests

Yocto based RDK builds are flexible enough to easily accommodate SoC / OEM / Operator / third party changes. The starting point for the Yocto builds is a manifest file. The manifest file is an xml file that contains details of the different open embedded Yocto build layers, meta layers , RDK as well as open-source components that needs to be fetched during initial stages ( than during bitbake time ) as well as the URL locations from where the data can be pulled. A set of sample manifests that can be used as a template for developing Operator specific manifests are given below

Operator meta-layer creation

To match the layered structure of Yocto builds, an Operator-specific layer is used to include Operator changes and additions. Use the yocto-layer create sub-command to create a new general layer.

$ yocto-layer create mylayer

There shall be a separate device (machine) configuration file (.conf) for each device for the particular chip family for which the layer is intended for. The general naming terminology for Operator layer is meta-rdk-<operator name>

The device (machine) configuration file shall include the corresponding include (.inc) file to get machine configuration details.

Adding the Machine Configuration File for the new Operator

Each meta-* layer should have a conf folder containing the machine configuration we can select during 'source setup environment. Optionally it can also have a class/classes folder for keeping information that is useful to share between metadata files.

To add a machine configuration, you need to add a .conf file with details of the device being added to the conf/machine/ file. In the machine conf file the basic machine configuration should be defined.

Once the conf files are in place, the layer details need to be added to the corresponding package group file. Based on the platform, the package group file will be grouped into multiple files with one bitbake file and multiple append files. The Operator can add the Operator layer details to the required package group append files applicable to the target device build to get the features into the final build

Operator Specific Apps

Operators will be having a range of Operator specific applications from simple generic device information apps to Operator specific applications. RDK's Yocto based layered structure allows Operators to easily integrate, upgrade and maintain their apps in their RDK

Operator Specific UI

RDK supports the usage of User Interface in the RDK router device. Operators can use the available UIs with RDK as well as develop and use their own UI. For more information on UI support in RDK, please refer to WebUI, a graphical user interface that is available to the connected devices.

Provisioning Support

The Operator needs to add provisioning support in the device so that Device provisioning can be done once deployed at the customer premise. The steps for this varies based on platform as well as Operator type.

Provisioning support refers to the scenario such as when you launch Sample app on your mobile it takes to the login page and so you have to log in there, account there i.e. actually the app has to authenticate your login.

Disaster Recovery

Disaster recovery is an inevitable part of the CPE life cycle. Operators, based on their disaster recovery strategy, could add support for this in the device. While there are some generic guidelines followed across the industry, there is no single step that works for all. Operators could easily add their business logic to RDK as part of Operator firmware engineering

As an Operator, they have to handle crashes/disaster happens and support any factory reset scenarios

TDK

In short, to get an RDK based device to the field, Operators need to get

• RDK license
• Commercial License Agreement
• Project agreement with OEM's/ SoC
  

What Operators get from RDK:

• RDK can combine devices with operator and third-party applications in order to support a wider range of experiences
• RDK allows operators to deliver the best broadband experience and build custom apps

What Operators need to do:

• As an Operator, the certification for the Operator's device has to be done by them
• Customer specific UI, boot loader and any other operator specific implementations to be taken care by operators.