RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Background Color | ||||||
---|---|---|---|---|---|---|
| ||||||
Overview Anchor |
|
This page provides the details and guidance to the Operators on how to adopt RDK. The step by step procedure for an operator to get an RDK based Platform up and running is also described in detail.
Excerpt Include | ||||||
---|---|---|---|---|---|---|
|
Background Color | ||
---|---|---|
| ||
Product Specifications |
The first step to get a fully functional product is
theto define the product features and see if they meet the standard requirements.
A list of expected features from an IP based Set-top box are listed at Product Specifications. MSO can cross check the expected features/specifications with the capabilities of the OEM device being used and can finalize the features supported by the product.See here to know what are all the features available in RDK-V and can implement based on your requirement. Operator can use this as a guide while engineering the RDK Operator platform.
Background Color | ||||
---|---|---|---|---|
| ||||
Device Firmware Anchor |
| |||
Info | ||||
For details of product specifications, please refer: Product Specifications
|
Operators can make use of the details available at MSO Platform Firmware below to start developing a Yocto build to do the final additions of MSO Operator specific changes to the device. This will help MSO Operator to add their own final product features as well as MSO Operator specific patches/changes.
Info | ||||||
---|---|---|---|---|---|---|
For details, please refer:
|
Yocto based RDK builds are flexible enough to easily accommodate SoC / OEM / Operator / third party changes. The starting point for the Yocto builds are 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
Expand | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
The default manifest repo in RDKM Git is at https://code.rdkcentral.com/r/#/c/manifests/ . Operator need to have their own manifest file in this location which will be mentioned in the 'Device specific manifest' - which is the starting point of builds for a particular target device |
To match the layered structure of Yocto builds, a Operator specific layer is used to include Operator changes and additions. Use the yocto-layer create sub-command to create a new general layer.
Code Block | ||||
---|---|---|---|---|
| ||||
$ yocto-layer create mylayer |
There shall be 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-<soc name>
The device (machine) configuration file shall include corresponding include (.inc) file to get machine configuration details.
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 platform, the package group file will be grouped into multiple files with one bitbake fiile and multiple append files. Operator can add the Operator layer details to required package group append files applicable to the target device build to get the features into the final build
Background Color | ||
---|---|---|
| ||
Operator Specific Apps |
Operators will be having a range of Operator
MSOs will be having a range of MSO specific applications from simple generic device information apps to MSO Operator specific content applications. RDK's Yocto based layered structure allows MSOs Operators to easily integrate, upgrade and maintain their apps in their RDK based IP Set-top devices. For more details on App support in RDK, please refer Applications(only for RDK licensee) as well as MSO Operator Platform Firmwarefor the engineering details.
Info | ||||||
---|---|---|---|---|---|---|
For details of MSO Specific Apps, please refer:
|
Background Color | ||
---|---|---|
| ||
Operator Specific UI |
RDK supports usage of multiple User Interface in the RDK IP Set-top devices. MSOs Operators can choose from among the already available UIs that are available with RDK as well as develop and use their own UI.
Follow the below steps to get Lightning UI running in devices:
Expand | ||
---|---|---|
| ||
Clone and Build InstructionsThis section details about how to customize the current UI |
source code and develop further. Follow the commands to run the application on you laptop.
|
What operators need to do if they plan to use Accelerator UI as such ( or with minimal changes )?
What operators need to do if they plan to use a different UI?
Background Color | ||
---|---|---|
| ||
Info | ||
Link to New Window | ||
page | https://wiki.rdkcentral.com/display/RDK/RDK+Video+Accelerator+-+User+Interface | link-text | User Interface
App Support |
Along with the MSO Operator specific apps, MSO Operator can support a lot of generic apps in RDK IP Set-top devices by taking advantage of RDK Support for Native as well as Web Apps in IP based Set-top platforms. MSO Operator can easily port native apps in their platforms (for some third party apps, MSO Operator need to obtain certification from those third party) or can host their own app store and then use Web Apps to show content. For more information on App support in RDK, please refer Applications (only for RDK licensee).
Background Color | ||
---|---|---|
| ||
Factory Test App |
The Factory Test App is a special standalone application used for production line testing at the TV assembly factory of the OEM manufacturer. It is embedded directly in the firmware image that gets flashed onto the boards on the TV production line.
<ToDo>
Background Color | ||
---|---|---|
| ||
Provisioning Support |
Operator
Info | ||||||
---|---|---|---|---|---|---|
For details of App support in RDK IP based Set-top devices, please refer:
|
MSO needs to add provisioning support in device so that Device provisioning can be done once deployed at customer premise. The steps for this varies based on platform as well as MSO Operator type.
Provisioning support refers to the scenario such as when you launch Sample app on your mobile it takes to login page and so you have to login there, account there i.e. actually the app has to authenticate your login.
Background Color | ||
---|---|---|
| ||
Disaster Recovery |
Disaster recovery is an inevitable part of the CPE life cycle. MSOOperator, based on their disaster recovery strategy, could add support for this in the device. While there are some generic guidelines followed across industry, there is no single step that works for all. MSOs Operators could easily add their business logic to RDK as part of MSO Operator firmware engineering as described in MSO Operator Platform Firmware.
As an operator they have to handle crashes/disaster happens and support any factory reset like OTA upgrade.
Background Color | ||
---|---|---|
| ||
Test & Certification of devices |
Once the device engineering is completed from MSO Operator side, the device can be test and verified easily by the Certification support provided by RDKM. Details of coverage as well as major cases are explained here .
Info | ||||||
---|---|---|---|---|---|---|
For details on test & certification of devices, please refer:
|
(only for RDK licensee) .
Certification suite is available at RDK IP Set-top Product Certification (only for RDK licensee) and for TDK test app please refer TDK-V Documentation.
In short, to get an RDK based device to field, Operators need to get
To start with RDK, MSO needs
Some features are optional whether they can adopt or can use the existing ones.
They can use existing ones.Some customisation of remote actually, remote and operator specific operations for eg:in multi choice case south africa ,it depends on region .In europe they have some power standards like the device shd consume this much power they ll do all those kind of hw related testing those are they ll work with OEM's to get those done.Combing back to certification as a operator certification has to be done by them actually ,we are RDk n we r pre-certified we r not certified ,the common port youtube,netflix,amazon RDK is only pre-certified OEM is also only integrated with rdk precertified but stamp what device will get is for eg in the case of multi choice they ll call as multi choice box it's not RDK box or skywoth box or whatever it is a multi choice streamer device that product name is streama like Xi3, like we have comcast products like Xi device,platco device those are actually device name here the operator device in the case of multi choice they call it streama, youtube certification,amazon certification,netflix certification so it has to be done on streama device so it is operators responsibility to get that certified.But obviously they only ust pass on the work we RDK or the OEM do for this certifications so SOC has to implement their part n RDK has to implement their part as a operator they only publish those reports to the they ll talk to the youtube, i mean google,netflix n amazon.RDK will not talk to directly with these guys.It is multichoice who talks to these operators.As a operator they need to have a for eg:for these premium apps they need to have a project with netflix to get the netflix working n they need to have a project with amazon to get amazon specific actually every device will have like any device which will have amazon prime that will have unique dtid that is specific to customer only.Like now today if i have a customer tata sky n they have ported amazon prime app in their box side so they will have separate dtid n similarly any operator TEL or multichoice they will have separate dtid so taht dtid they need to have agreement with amazon team and they will be commercial license agreement between these 2 partners amazon n the operator similarly for netflix n operator \\y for utube ,u tube n operator they ll be having a business level agreement so that dtid will be pass on to , like as a RDK we have only test accounts we don't verify on commercial accounts ,as a rdk we only use test accounts n get pre-certified as a operator to deploy there are some more things actually all these netflix,amazon,u tube pre-certification will be done but the actual certification ghas to be done in the actual UI, so what all additional will come like the symbol which they show on the UI like u tube, amazon symbol they ahve test like the symbol shd be this much cm n this color have some specific related n they have product specifications like standby if there is a device in standby whether it shd be waking up through key press,if remote had hard key like the remote has direct key for amazon if i press that prime shd launch amazon it shdn't go to ui n then go to app n bring up there all these r operator specific... who ll do these changes operator or oems support operator like how we r supporting multi choice to get these changes whenever there is a key navigation they ll map their ui to listen that key it is downlevel RDK n skyworth as a oem we r supporting them to get that functionality.