Product Specifications

The first step to get a fully functional product is the 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.

Device Firmware

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

MSO Specific Apps

MSOs will be having a range of MSO specific applications from simple generic device information apps to MSO specific content applications. RDK's Yocto based layered structure allows MSOs 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  as well as MSO Platform Firmware for the engineering details.

MSO Specific UI

RDK supports usage of multiple User Interface in the RDK IP Set-top devices. MSOs can choose from among the already available UIs that are available with RDK as well as develop and use their own UI. For more information on UI support in RDK, please refer User Interface.

App Support

Along with the MSO specific apps, MSO 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 can easily port native apps in their platforms (for some third party apps, MSO 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.

Provisioning Support

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 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.

Disaster Recovery

Disaster recovery is an inevitable part of the CPE life cycle. MSO, 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 could easily add their business logic to RDK as part of MSO firmware engineering as described in MSO Platform Firmware.

As an operator they have to handle crashes/disaster happens and support any factory reset like OTA upgrade.

Test & Certification of devices

Once the device engineering is completed from MSO 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 .

what are the things required for MSO to get started?

TODO

To start with rdk mso needs

• RDK license
• Project agreement with OEM's
• UI Specific 

what is available and what they need to do?

TODO

Available is:

• Pre-certified stack is available in rdk ,pre-certified stack means pre-certified youtube ,pre-certified amazon, pre-certified netflix as a common port architecture bcz netflix 2 things 1 is common port n davanche port(other general community use)
• RDK common port (youtube, amazon, netflix etc) is available
• RDKService are available to customise rdkservice plugn plugout components for all the stacks mainly bluetooth, wifi and front panel, power manager, device settings, all these kinds of plug in plugout configurable rdkservices is available that is also pre-available,pre set apps are available,basic architecture of OTA are available.

What Operators need to get :

• Customisation of boot loader for operator specific , operator specific UI, Operator specific any customisation on the stack like power manager like any specific requirements

Operator specific:

1. Licenses:
   1. Operator has to get a license RDK licensee and  then any premium apps porting operators should have a project agreed with the corresponding premium app like for youtube it is google.

   2. <RDK license agreements with operators>

      that is for rdk license.rdk will tell that we r pre-certified n go to amazon or netflix to get a business level agreement that u can access our code base.Support some abc company comes to adopt they ll get rdk license they ll not get access to our amazon plugin or code implementation for netflix n amazon plugin bcz amazon team has to agree that we can release the code base to them for that they ll have agreement with amazon n netflix that ok we r working with rdk we ll be accessing amazon souce code from them those kind of license agreements ll be there.

2. UI Integration:
   1. Operator specific task on RDK are customization of UI to adopt RDKServices so as part of customization of UI they can refer the resident app implementation. As part of customisation of UI,OTA upgrade is one of the first main point .As an operator they need to get the OTA backend server . Xconf is the RDK recommended OTA method.It is not mandatory this can be optional 
   2. Operator specific requirements has to be implemented by operator eg.frontpanel related or any customisation of UI and any such requirements.

Operators actually 2 things.

1 is UI, UI integration with RDKServices. for them actually only main change will be UI because the stack which they ll receive from OEM will be already proven like it is been validated by OEM SOC certification which we have RDK.It has to pass through SOC certification when it goes to opertaor.Basically that means SOC certification or OEM device certification means RDK is been validated i.e.TDK suites have been validated.For operator actually it will be main challenge will be the UI integration where they have for example in multi choice case they have a UI & their UI is actually the browser instance which they create is a web kit browser instance they ll just create a webkit browser instance and they ll use that browser for Ui they have something called system manager.They make a copy of this webkit browser n they define that so whatever configuration it needs basically the resolution settings, port related things like which port it has to be the data socket communication which port like the current RDK we are having port 9998 for all the communications will be on port 9998 but for multichoice they have already UI it is from the previous project when they try to migrate so there UI is being configured to listen on port 80 that's the first challenge they faced.there actually akhil's team suggested in RDKServices currently everywhere it is hardcoded to 9998 so they raised Jira for comcast to make it configurable but it is current RDKServices everywhere it is been hardcoded with 9998 .So then we requested them whether they can move to 9998 or we already provided a patch to configure to port 80 they initially took our patch but later they changed UI to listen on port 80 .So all the socket communication n the navigation from the application manager will be based on port 9998.That was one of the major challenge we had in the multichoice.2nd thing is UI integration n Dial related  integration for the youtube certification.For the youtube certification dial has to be integrated in the Ui we have provided a sample app current resident app is the source code right those actually we pass on that .....so these are the operators specific related stuff which they need to do .1 is bring up the UI based  on the resident app reference implementation and as part of that i.e.1 line actually -based on resident app reference implementation they need to bring up the UI so internally to that there are so many things 1 is the eg:dial , the other one is webkit browser instance which i mentioned n other configurations settings n their persistents areas.The RDK we are mapping the persistent related whatever default persistent like OPT or whatever it is ,as a operator they might be having different it is not just youtube,those things right as a operator they have their own live TV applications just like TATA SKY or other things.there also they have a user based ,user data have to be stored.So their account for that show macs or the DSTV application they have a account manager there which will have like headend backend for billing na ll ,like how to request channels subscription those are part of Ui,those has to be integrated with RDK also,Like there the challenges are like mainly the persistent data i mean the user data where to store n whether it is secure or not those kind of info they ll tc that is another part of a sa operator they need to bring in.4 th is OTA upgrade.So OTA upgrade from RDK point of view we have provided 2 solutions 1 is xconf based where we r giving listen of xconf server like as  a sample server to they can any operator can refer to xconf server n create their OTA server but in the multi choice case they have already have a OTA backend  from the, they are having market sinnce very long time they have  headend n the backend server they have alraedy a OTA server so they don;t use xconf there,there actually we have a firmware update plugin so they will use that firmware upgrade plugin for OTA upgrade this is 1 more area where operator has to their own specific changes.till 8;05.

Some features are optional whether they can adopt or can use the existing ones.

They can use existing ones.Like the firmware update plugin is available there readily they can directly use that infrastructure otherwise they need to configure their headend with the xconf server.

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.

----------------------------------------------------------------------------

They have to have agreements with youtube,netflix,amazon (add those points here)