陳 淡，沈 琳

（福州大學(xué) 福建省數(shù)字電視工程研究中心，福建 福州 350002）

近年來，智能手機和平板電腦保有量的不斷上升沖擊著傳統(tǒng)通信和互聯(lián)網(wǎng)行業(yè)，而智能電視整合了多屏互動、語音識別、云端技術(shù)等諸多移動領(lǐng)域的熱點概念，通過OTT業(yè)務(wù)渠道對廣電傳統(tǒng)DVB業(yè)務(wù)發(fā)起挑戰(zhàn)。隨著三網(wǎng)融合的進一步推進，整個DVB產(chǎn)業(yè)都面臨著轉(zhuǎn)型升級的關(guān)鍵階段，可以預(yù)見未來幾年的數(shù)字電視產(chǎn)業(yè)將通過Android這個開放式的開發(fā)平臺，傳統(tǒng)DVB業(yè)務(wù)與互聯(lián)網(wǎng)TV業(yè)務(wù)進一步融合創(chuàng)新，進入下一個爆發(fā)式的增長點。

OTA（Over The Air）空中升級，是指用戶終端可以直接通過信號通道的接收下載，進行軟件的更新升級[1]。而通過完善Android平臺提供的軟件升級功能，保障平臺前期較頻繁的更新升級，是提高產(chǎn)品競爭力和用戶滿意度的重要保證，因此保證OTA的通暢和穩(wěn)定具有極大的實用意義。本設(shè)計結(jié)合Android平臺的OTA技術(shù)特點，按照盡量節(jié)省帶寬和流量資源以及穩(wěn)定易維護的設(shè)計思想，提出了一套綜合DVB業(yè)務(wù)OTA、網(wǎng)絡(luò)服務(wù)器的OTA以及本地升級等多途徑的復(fù)合空中升級的部署方案，以實現(xiàn)降低DVB業(yè)務(wù)升級的復(fù)雜度與運維成本的目的。

1 Android平臺的OTA機制

Android開放源代碼項目（AOSP）提供了相當(dāng)完善的OTA機制，其特性有：支持完整包升級和增量升級包升級兩種方式；通過對升級插件擴展，可支持升級所有的分區(qū)和啟動鏡像；數(shù)字簽名升級包，防止升級包遭篡改；升級時掉電的安全恢復(fù)處理。

1.1 軟件升級包的編譯系統(tǒng)（Releasetools）

軟件升級包的生成主要由AOSP中的發(fā)行工具包（Releasetools）來實現(xiàn)。升級軟件生成的流程圖如圖1所示。在build/core/Makefile中定義的$(BUILT_TARGET_FILES_PACKAGE)依賴定義升級相關(guān)的文件，生成一個zip格式的中間升級包。ota_from_target_files的Python腳本以中間zip作為輸入，生成可用于OTA升級的zip包。調(diào)用ota_from_target_files時，可以使用-i選項指定一個前期版本的中間升級包作為基準(zhǔn)包，用于生成增量升級包。在理解升級包的生成原理后，可以實現(xiàn)一種只升級指定分區(qū)部分文件集合的升級包，本文將其稱為獨立升級包。獨立升級包的生成，實際是對正常流程得到的中間升級包進行干涉，使編譯得到的zip中間包只包含指定的文件集合，參考ota_from_target_files的做法，對Edify腳本的生成進行修改，在升級時不做格式化的操作，而后再對其進行簽名處理。

圖1 升級軟件生成原理圖

1.2 系統(tǒng)應(yīng)用層升級接口

RecoverySystem作為Android框架的軟件升級API，提供應(yīng)用程序框架與Android的Recovery系統(tǒng)交互的能力[2]。RecoverySystem 中 installPackage，reboot-WipeCache，rebootWipeUserData，verifyPackage四個靜態(tài)方法提供了應(yīng)用層校驗與安裝軟件升級包、驗證升級包數(shù)字簽名、清空Cache和Data分區(qū)的功能。

1.3 Recovery內(nèi)核

顧名思義，Recsovery內(nèi)核與系統(tǒng)內(nèi)核相區(qū)別，從Recovery內(nèi)核啟動得到的是升級軟件系統(tǒng)環(huán)境。軟件的校驗升級、已經(jīng)擦除相應(yīng)的分區(qū)等工作，都是在升級環(huán)境中完成的。而系統(tǒng)應(yīng)用層升級接口可以通過向/cache/recovery文件中寫RC命令，與Recovery內(nèi)核的升級環(huán)境交互。

1.4 Updater升級執(zhí)行文件

Updater升級執(zhí)行文件包含在軟件升級包中，實現(xiàn)升級時處理流程，支持Edify升級腳本語言，并能通過插件實現(xiàn)平臺相關(guān)的升級定制需求。

Android的升級基本流程如圖2所示，其主要思想就是通過Bootlooder根據(jù)BCB（Bootloader Control Block）定義的命令來判斷是否加載Recovery內(nèi)核，進而使用Recovery內(nèi)核中ramdisk包含的updater工具進行Edify腳本升級操作。

Android平臺的完整OTA流程，由軟件升級包的生成、客戶端OTA升級、OTA服務(wù)器端部署三個部分組成。遺憾的是，AOSP中并沒有完整的OTA解決方案，因此無法獲取到升級包的服務(wù)器部署方法和客戶端的下載更新和通知更新模塊的開放源碼。本文將補充這個部分，給出一套結(jié)合DVB和IP信道的混合OTA解決方案。

圖2 Android升級流程示意圖

2 OTA系統(tǒng)設(shè)計

2.1 智能機頂盒系統(tǒng)總體結(jié)構(gòu)

DVB+OTT機頂盒的系統(tǒng)整體架構(gòu)基本分為DVB+受控OTT、DVB+開放OTT兩種結(jié)構(gòu)，受控OTT的視頻內(nèi)容是通過廣電網(wǎng)絡(luò)的內(nèi)容監(jiān)控線路后，再通過有線運營商的HFC寬帶IP網(wǎng)絡(luò)傳輸，開放OTT則是直接通過其他ISP提供的網(wǎng)絡(luò)連接使用一家互聯(lián)網(wǎng)電視牌照商的播控平臺接受視頻內(nèi)容[3]。受控OTT和開放OTT都需要通過互聯(lián)網(wǎng)接入視頻內(nèi)容，而DVB還是通過傳統(tǒng)的信道接入視頻內(nèi)容。考慮到兩者相互獨立，本文提出對智能機頂盒的DVB和OTT兩部分部署兩套OTA系統(tǒng)。

2.2 智能機頂盒DVB功能的OTA設(shè)計

DVB部分的OTA系統(tǒng)，主要針對獨立的DVB功能模塊升級，保證了在互聯(lián)網(wǎng)無法接入的情況下DVB系統(tǒng)升級的可靠性。另外，DVB模塊升級方案使用獨立升級包作為系統(tǒng)升級包，可以避免完整升級包體積太大、差分升級包必須使用雙向網(wǎng)絡(luò)的劣勢，兼顧了DVB系統(tǒng)的前向兼容，無需對升級系統(tǒng)進行改造即可使用。

在DVB系統(tǒng)前端上，NIT表的傳送系統(tǒng)描述符包含升級頻點的參數(shù)信息，OTA控制信息存放在下載服務(wù)器初始信息DSI和下載信息標(biāo)識信息DII中，OTA升級包存放在下載數(shù)據(jù)塊信息DDB中。智能機頂盒終端需要通過監(jiān)控并分析NIT、SSU BAT表獲取升級服務(wù)的頻點，并進一步匹配盒子的唯一標(biāo)識符OUI獲取OTA基本流的PID，通過分析DSI、DII表獲取DDB中升級包數(shù)據(jù)。最后檢驗獲取升級包的完整性后，調(diào)用RecoverySystem的API接口進入升級。該升級的流程如圖3所示。

圖3 DVB功能的OTA順序圖

2.3 智能機頂盒OTT功能的OTA設(shè)計

由于接入網(wǎng)絡(luò)是互聯(lián)網(wǎng)，OTT部分的OTA系統(tǒng)天生適合使用差分升級包進行OTA部署。差分包是通過舊版本軟件和目標(biāo)升級軟件二進制比較獲得的，升級文件體積小，相應(yīng)的代價是需要額外的開銷進行升級版本關(guān)系維護。因此差分升級系統(tǒng)必須要通過雙向通信，確保差分包之間的前后關(guān)系。

系統(tǒng)管理員在網(wǎng)絡(luò)服務(wù)器端配置對應(yīng)的軟件版本信息和上傳相應(yīng)的升級包，內(nèi)部驗證測試升級成功后，將配置修改為正式升級配置發(fā)布升級。智能機頂盒終端定期連接網(wǎng)絡(luò)升級服務(wù)器，發(fā)送配置描述信息，查詢是否有升級包更新。如果獲取到服務(wù)器的升級描述文件，則對文件解析后，獲取相應(yīng)的升級包。最后校驗升級包的完整性，調(diào)用Recovery System的API進行升級。該OTA流程順序圖如圖4所示。

圖4 OTT功能的OTA順序圖

2.4 智能機頂盒OTA系統(tǒng)測試

本設(shè)計的OTA系統(tǒng)的集成測試集合分別從功能、性能、異常處理三個方面進行了驗證。DVB的OTA測試環(huán)境主要由前端碼流播放器、TS復(fù)用器、功分器、小批量樣機組成。DVB的OTA功能測試包括：升級流程測試、升級超時處理測試、升級版本和配置處理測試。DVB的OTA性能測試包括：接收時間測試、升級時間測試。DVB的OTA異常處理測試包括：掉線測試、接收數(shù)據(jù)時掉線測試、接收數(shù)據(jù)時掉電測試、升級時掉電測試。而OTT的OTA測試環(huán)境由升級服務(wù)器、路由器、小批量測試樣機以及仿真樣機客戶端組成。OTT的OTA功能測試的功能測試、性能測試與DVB相同，OTA異常處理測試還包含了錯誤版本測試、升級包篡改測試。OTT的OTA測試還包括對升級服務(wù)器的并發(fā)處理能力測試、大量客戶端請求壓力測試。

因為篇幅所限，功能測試和異常處理測試用例對應(yīng)的測試結(jié)果不一一列出，主要給出OTT升級和DVB升級的性能測試的關(guān)鍵數(shù)據(jù)，如表1所示。差分升級包大小與兩次中間包的差異有關(guān)，考慮比較極端的情況，兩個中間包的網(wǎng)絡(luò)相關(guān)預(yù)置App都有改動，得到的升級包為47.3 Mbyte，與完整升級包相比動輒150 Mbyte以上的空間，差分升級包的優(yōu)勢非常明顯，在分配帶寬為800 kbit/s的測試環(huán)境下，接收時間令人滿意。獨立升級包主要包含了DVB相關(guān)的App，最終得到的升級包大小為5.2 Mbyte，配合DVB運營商的前端帶寬進行下載升級也較合適，在15 kbit/s的較小帶寬下，接收時間和傳統(tǒng)DVB機頂盒接收時間相同。經(jīng)測試，153 Mbyte的完整升級包平均升級時間是154.2 s，而極端情況的差分升級包的升級時間較之還要快20 s。因為升級過程中，獨立升級包執(zhí)行的是校驗替換的操作，升級時間較OTT的差分升級包要快100 s。綜上所述，性能測試得到的接收時間和升級時間均達到系統(tǒng)設(shè)計要求。

表1 OTA性能測試數(shù)據(jù)

本文提出的OTA系統(tǒng)，通過了大量的測試用例驗證，達到設(shè)計預(yù)期效果。該系統(tǒng)設(shè)計兼容了傳統(tǒng)的DVB升級配置，整合OTT的差分升級模式，并對異常狀況處理可靠，屬于性能良好的DVB+OTT機頂盒OTA解決方案。

3 總結(jié)

本文提出的智能機頂盒OTA系統(tǒng)已經(jīng)在自主研發(fā)的機頂盒上實現(xiàn)，并在海外市場上使用反饋良好。目前，DVB+OTT機頂盒在技術(shù)層面上已經(jīng)不存在任何障礙，隨著技術(shù)的融合與演進，可以預(yù)見未來家庭的數(shù)字機頂盒將向家庭網(wǎng)關(guān)的方向發(fā)展，成為智能化家居網(wǎng)絡(luò)的關(guān)鍵節(jié)點，為人們提供更加方便舒適的數(shù)字化生活體驗。

[1]呂梓凌.利用電子節(jié)目指南私有描述符實現(xiàn)機頂盒空中升級功能[J].中國有線電視，2009（8）：806-809.

[2] Recovery System[EB/OL].[2013-09-03].http://developer.android.com/reference/android/os/RecoverySystem.html.

[3] 鄧水森，王立軍.OTT智能終端典型功能及運營模式探析[J].電視技術(shù)，2013，37（6）：17-20.