基于TR069的交互電視終端分組管理設計

趙嫚嫚，劉 學，戴瓊興

（1.中國科學院 聲學研究所南海研究站，海南 海口 570105；2.中國科學院 聲學研究所國家網絡新媒體工程技術研究中心，北京 100190）

0 引 言

作為擁有全球最大用戶群的我國廣播電視網絡，經過多年的建設和發展，已擁有較完整的各級網絡，基本完成了有線數字電視的整體轉換，為用戶提供豐富的交互業務已成為現實。隨著交互業務的多樣性發展，以及用戶的服務要求越來越高，運營商要能夠根據不同的用戶需求提供區分服務，以提高用戶體驗，增加用戶的粘合度［1］。此外，由于網絡運營商在現網運行中安全性和可靠性的要求，新業務的試驗驗證很難在現網內部署和運營，這嚴重影響了新業務的快速進程和產業化，同時，運營商一些新的業務運營模式也很難開展。新業務、新運營模式的測試是亟待解決的問題。

針對以上的問題，本文采用基于TR069的終端分組管理的方法來滿足該需求，設計了不同分組終端的個性化參數配置、升級及日志采集過程，其中終端分組按照不同類型、不同組織、不同區域等屬性進行分組，系統為每組用戶提供個性化服務。

1 基于TR069的終端分組管理的系統架構

1.1 系統架構

TR069是由DSL論壇發起開發的技術規范之一，也被稱為CWMP協議（CPE WAN Management Protocol，CPE廣域網管理協議）［2］，提供了管理終端設備的通用框架、消息規范、管理方法和數據模型［3］［4］，可實現在網絡一端對終端設備的遠程管理。

TR069協議描述了自動配置服務器（auto－configuration server，ACS）和用戶終端設備（customer premise equipment，CPE）之間通信的一個公共平臺，為ACS對CPE 進行的安全自動化配置管理提供了一個框架。在本系統中，CPE對應于交互電視機頂盒（set top box，STB）。基于TR069的終端分組管理系統架構的設計如圖1所示。

圖1 基于TR069的終端分組管理系統架構

在系統架構中，運營支撐系統（business ＆operation support system，BOSS）完成用戶信息管理、運營策略管理、賬務管理及繳費管理。其中，用戶側信息主要包括：用戶類型（普通用戶、VIP用戶、測試用戶）、用戶地域等信息。終端管理系統（terminal management system，TMS）維護終端分組信息、終端組與業務配置項、日志采集項和運營策略實體關聯關系。認證授權計費系統（Authentication，Authorization，Accounting，AAA）根據運營策略執行對終端的認證授權和計費。ACS完成對終端的自動配置及控制，是管理系統與終端之間的橋梁。

1.2 系統中的終端分組

根據系統的運營策略，在現網中不能直接把新開發的業務直接發布給真實用戶，需要在現網中進行測試。同時，在測試中為了不影響真實用戶使用已經發布或上線的業務，就需要限定一些特定的用戶，如測試用戶，可以看到待測試的業務，而其他用戶則看不到這些業務。同樣，在測試一種新的網絡時，也需要做到這樣的效果，僅把特定的用戶配置到待測試的網絡中。

系統中將測試用戶與VIP 用戶、普通用戶區分開，進而可以通過TR069協議根據不同終端用戶分組下發不同的業務訪問地址；同時根據可配置的升級策略，管理不同終端用戶分組的升級；也可以根據不同的終端用戶分組下發采集多項配置、采集和預處理終端日志。這些功能的實現將有利于AAA 進行分組計費認證，更便于整個系統運營的統籌規劃。

系統中的分組方式如下：groupName為普通用戶（CommonUser）、VIP用戶（VIPUser）、測試用戶（TestUser），分別為他們分配一個不同的groupID、groupType。不同groupID 中的終端編號為不同的tmlID，終端有其各自的終端狀態（tmlStatus）、上線時間（OnlineTime）、下線時間（OutlineTime）以及注冊時間（RegTime）。在VOD點播應用中，通過groupID 參數進行用戶定位，每個用戶發起點播時，必須向會話管理器傳送此參數，以便標示用戶所在區域，控制視頻服務器向用戶所管理的IPQAM 進行推流。

在IPQAM 上為每個輸出碼流配置碼流標識號（TSid），其取值范圍為0至65535，TS－id值即為groupID 參數值；在每個groupID 下的所有QAM 信道中，設置若干頻點為主搜索頻點，要求互動機頂盒每次開機搜索這些頻點對應的TS－id，并從中解析groupID 參數，實現定位過程。

2 實體關系的設計

根據以上需求，為了達到靈活的分組，本文采用如圖2所示的 實體關系模型［4－6］。

圖2 實體關系模型

在實體關系模型中，包括終端、終端組、業務配置項、日志采集項及運營策略實體［7－8］，它們之間的關系如下：

（1）終端與終端組為多對一關系，即一個終端只能關聯一個終端組，一個終端組可以包括多個終端；

（2）終端組與業務配置項為多對多關系，即一個終端組可以關聯多個業務配置項，一個業務配置項可以關聯多個業務組；

（3）終端組與日志采集項為多對多關系，即一個終端組可以采集多種日志；

（4）運營策略與終端組為多對一關系，即一個終端組可以有多個運營策略。

3 基于TR069的終端分組管理業務流程

本節通過TR069實現用戶分組參數的下發，并描述了分組管理的業務流程［6］［9］，主要包括：業務配置信息的配置流程、日志采集項配置流程與終端個性化升級流程。按照分組權限的需要，給測試用戶下發不同的配置參數，實現對分組的管理和維護。

3.1 業務配置信息的配置流程

（1）業務配置信息參數說明

業務配置項包括：configID、configType、configName和configValue。其中configType分為終端能力信息和個性化參數。configValue為configName的參數取值。config－Name為終端能力信息和個性化參數中的各個參數名稱，具體如下：

1）終端能力信息

終端能力信息包括：終端廠商（Manufacturer）、終端型號名稱（ModelName）、終端硬件版本號（HardwareVersion）、終端軟件版本號（SoftwareVersion）、終端當前狀態（tmlStatus）及所支持的傳輸層協議（TranseferProtocol）、流封裝協議（MultiplexTypes）、音頻編碼格式（AudioStandards）、視頻編碼格式（VideoStandards）等。

2）個性化參數

個性配置的參數包括業務訪問地址、網絡參數、告警門限、日志上報周期等。目前所提供的服務器業務訪問地址有：應用門戶地址（AppPortal）、應用文件傳輸服務器地址（AppFTP）、TV點播門戶地址（TVPortal）、圖片服務器門戶地址（PicPortal）、系統升級服務器地址（SUSURL）、在線管理系統服務器地址（OLS）、業務提供設備列表中的各服務器地址（SPElist）、機頂盒操作日志更新系統服務器地址（STBlogUpdateSystemURL）。

根據不同的groupID配置不同的前端服務器地址或URL，并有全局的默認配置；待配置的前端服務器地址可以實現動態增加或修改。ACS可以根據終端用戶的不同分組，向TMS請求不同的地址，然后下發給用戶終端。

（2）業務配置信息的配置流程如圖3所示。

1）STB 開機與ACS 建立連接后，調用Inform 方法，上報終端能力信息的各個參數給ACS。

2）ACS得到這些參數后，把參數上報給AAA，發起Auth Request。

3）AAA 收到這些參數來匹配不同的groupID，并根據不同的運營策略opID 對機頂盒進行認證授權，并返回Auth Response。

4）ACS得到認證信息后，返回Inform Response。

5）STB發起一條空的HTTP Post請求。

圖3 業務配置信息的配置流程

6）TMS判斷是否有適合該型號終端的軟件升級，并進行更新，升級流程可參見圖5。

7）ACS向TMS請求需要查詢參數的終端的分組情況。

8）TMS把分組詳情返回給ACS，并告知ACS該終端是否有參數配置。

9）如果該終端有參數配置，ACS就向STB 發起Get－ParameterValues的請求，要求查詢指定的終端能力信息參數或個性化參數。

10）STB 返回GetParameterValues Response，攜帶著指定參數的值。

11）如果需要重新配置指定參數的值，ACS就向STB發起SetParameterValues的請求，配置相應的參數。

12）STB返回SetParameterValues Response，攜帶參數值設定的結果。

13）ACS不需要進行其他操作時，就返回空的HTTP Post Response，并斷開連接。

3.2 日志采集項配置流程

（1）日志采集項參數說明

日志采集主要包括終端業務使用記錄和維護記錄，不同的分組可以采集到不同類型的日志，不同類型的日志都有一個不同的itemID。日志類型分為故障日志和日常日志。

終端具有告警能力，能夠將終端業務質量等信息上報給ACS 或TMS，如對超過閾值的丟包率（PacketsLost）、業務訪問失敗（BusinessaccessFailure）等信息進行告警上報。在機頂盒發生系統、業務、網絡等故障時，由ACS進行平臺側診斷，可以滿足終端遠程診斷、遠程排障的需求。當發生的事件達到設置的上限時，終端會立即與ACS建立連接，并發送故障日志，攜帶告警的參數，將告警主動上報給ACS。同時，終端會定時采集認證次數、認證失敗詳細信息等日常日志參數，上報給ACS或TMS。

（2）日志采集項的配置流程

日志可以由STB主動實時上報，也可以由ACS定期向STB采集。由于實時采集大量終端的日志會造成服務器的負擔過重，故使用ACS定期采集。日志定期采集流程如圖4所示。

圖4 日志定期采集流程

1）STB 開機與ACS 建立連接后，調用Inform 方法，獲取事件類型。

2）ACS返回Inform Response。

3）STB發起一條空的HTTP Post請求。

4）ACS通過調用STB的SetParameterValues方法設置STB日志定時上報周期及服務器地址。

5）STB 返回SetParameterValues Response，攜帶設定的結果。

6）ACS不需要進行其他操作時，就返回空的HTTP Post Response，并斷開本次連接。

7）STB進行其他事務處理。當STB本地時間相對于本次開機時間的間隔到達設定的日志上報周期則生成日志文件，上報周期為PeriodicLogReportInterval。

8）STB通過設置的日志服務器地址，采用HTTP 或FTP的方式［10］進行日志上傳。如果上傳失敗，則要求保存數據并合并下個統計周期，生成新的日志文件，至上傳成功；上傳成功后，原統計周期內的數清空。

3.3 終端個性化升級流程

（1）終端個性化升級說明

ACS的升級策略可以根據用戶分組、終端廠商型號、固件版本號等信息進行選擇性配置，如分別給不同用戶分組的終端升級到不同的軟件版本。開發的系統軟件和應用軟件，需要上傳到TMS，供終端下載使用。TMS需要對開發者上傳的軟件進行完整性和安全性驗證，并進行功能和性能的測試，測試通過的軟件才允許上線，供終端下載使用。

（2）終端個性化升級的流程如圖5所示。

圖5 終端個性化升級流程

1）STB發送內容為空的HTTP請求。

2）ACS向TMS請求需要查詢參數的終端的分組情況。

3）TMS把該分組詳情返回給ACS，并告知ACS該分組的軟件是否有新版本，并把下載升級的URL給ACS。

4）如果有新版本，ACS先通過GetParameterValues請求來查詢終端的軟件版本號。

5）STB通過GetParameterValues Response攜帶軟件版本號給ACS。

6）如果STB的版本不是最新的，ACS就會向STB 發起Download請求。

7）STB返回Download Response，隨后打開該文件的URL，采用HTTP或FTP的方式下載文件［10］。當文件下載完成后就會進行軟件升級，如果升級成功后需要重啟，則終端會在Inform 方法的Eventcode 中至少包含“1 BOOT”和“4 VALUECHANGE”，表明STB 加電啟動，同時STB的軟件版本有變化。

8）之后STB 通過TransferComplete通知ACS 此次升級是否成功應用。

9）ACS 返回TransferCompleteResponse，隨后可進行其他請求的處理。

3.4 實驗結果

本文中的設計在支持跨區域、多運營商的新一代廣播電視服務系統中進行了部署和使用，將終端分成了三個組：普通用戶、VIP用戶和測試用戶。為了測試需要，并根據個性化參數的配置，分別給三組終端用戶提供了不同的業務訪問地址，最終達到了以下效果：普通用戶只能使用直播及部分第三方應用的體驗業務；VIP 用戶可以使用點播、直播、時移、回看及淘寶、科協等多種第三方應用的業務；測試用戶可以使用點播、直播、時移、回看、多種第三方應用及融合通道網關加速業務。

3.5 設計特點

基于TR069終端分組管理的設計具備以下特點：

（1）安全性：TR069 協議中的加密認證采用了SSL／TLS、HTTP basic或HTTP digest等方法［10］，使得設計出的系統安全可靠；

（2）普適性：TR069協議是一個位于IP之上的應用層協議，采用HTTP 協議，可以有效地穿越復雜的網絡環境，這使得該協議的適用性很廣，對接入方式沒有限制；另外，用Web中成熟的技術，使本系統的實現簡單，開發難度小；

（3）標準化和開放性：TR069協議是由DSL 論壇所開發的技術規范之一，提供了通用框架和協議，并制定了數據模型標準，大大提高了本系統的互操作性。

（4）高效性：TR069 協議允許ACS和CPE 任意一個發起連接請求，且不需要長期的連接，沒有會話請求時就斷開連接，使得系統所需帶寬減少，可以節省系統的成本；通過以上的流程及參數設計，使得系統可以軟件自動升級以及業務自動推送，比使用其他傳統協議進行管理更高效。

4 結束語

本文結合終端分組管理的需要，即對測試用戶進行獨立管理，對其下發個性的業務配置信息、日志采集信息及運營策略，基于TR069協議設計了終端分組管理。TR069對終端分組進行自動配置和動態業務提供，可以對分組進行管理和統一維護；同時可以根據業務發展進一步的需求，增加或刪除需要獲取的業務信息的參數。本文對運營商在業務運營時開展業務測試、提高區分服務等方面具有一定的參考價值。

［1］ZHANG Zhiqiang.Analysis of the realization and development of customized home network terminal［J］.Information and Communications Technologies，2008，6（5）：6－10（in Chi－nese）.［張志強.家庭網絡終端客戶化的實現與發展分析［J］.信息通信技術，2008，6（5）：6－10.］

［2］MENG Jing.Implementation of STB’s management function using TR069protocol［J］.Video Engineering，2009，33（12）：49－51（in Chinese）.［孟靜.采用TR069協議實現機頂盒的管理功能［J］.電視技術，2009，33（12）：49－51.］

［3］DSLForum.TR－069 ＿Amendment－3［S］.http：／／www.broadband－forum.org／technical／download／TR－069 ＿Amendment－3.pdf，2011.

［4］DSLForum.TR－135 ＿Amendment－1［S］.http：／／www.broadband－forum.org／technical／download／TR－135 ＿Amendment－1.pdf，2010.

［5］CHEN Yiwen.Design and implementation of CPE management system based on TR069［J］.Computer Engineering and Design，2008，29（5）：1108－1111（in Chinese）.［陳毅文.基于TR069的終端管理系統的設計和實現［J］.計算機工程與設計，2008，29（5）：1108－1111.］

［6］WU Chunmin.Research and implementation of remote configuration management terminal base in TR－069 protocol［D］.Chengdu：Southwest Jiaotong University，2009（in Chinese）.［吳春敏.基于TR－069協議的遠程配置管理終端的研究與實現［D］.成都：西南交通大學，2009.］

［7］China Telecom Shanghai Telecom.IPTV set top box and terminal management system’s interface requirements［M］.Shanghai，2008（in Chinese）.［中國電信集團上海市電信公司.IPTV機頂盒與終端管理系統接口要求［M］.上海，2008.］

［8］China Telecom Shanghai Telecom.Set top box and IPTV business operation platform interface technical specifications V2.2［M］.Shanghai，2007（in Chinese）.［中國電信集團上海市電信公司.機頂盒與IPTV 業務運營平臺接口技術規范V2.2［M］.上海，2007.］

［9］XIONG Qi.Implementation of TR－069in residential gateway［D］.Wuhan：Huazhong University of Science and Technology，2007（in Chinese）.［熊琦.TR－069協議在家庭網關中的實現［D］.武漢：華中科技大學，2007.］

［10］QI Shaoan，MEI Bin.Terminal management of IPTV based on TR069［J］.Designing Techniques of Posts and Telecommunications，2011（12）：7－12（in Chinese）.［齊少安，梅斌.基于TR069 協議實現IPTV 盒端管理［J］.郵電設計技術，2011（12）：7－12.］