基于個性化互動電視系統框架的單元間信息交互的實現

夏菽蘭，王吉林

(1.鹽城工學院電氣工程學院，江蘇鹽城224051;2.鹽城工學院信息工程學院，江蘇鹽城224051)

基于個性化互動電視系統框架的單元間信息交互的實現

夏菽蘭1*，王吉林2

(1.鹽城工學院電氣工程學院，江蘇鹽城224051;2.鹽城工學院信息工程學院，江蘇鹽城224051)

在現有HTML交互技術的技術上，實現了應用對用戶數據的實時檢測及根據用戶數據的改變實時更新應用內容的功能。在UPnP AV框架基礎上，利用UPnP設備UDN這一參數的唯一性與不變性提出了一種多UPnP設備存在情況下，UPnP設備之間實現雙向數據推送的解決方案，并進行了實際測試。

互動電視;信息交互;實時個性化

隨著技術發展，廣播網絡與其他網絡的融合，家庭內部設備之間的互連及各種應用根據不同的用戶進行個性化定制已經成為可能。由于各種設備上硬件系統，支持的網絡協議，數據媒體格式的不同，各設備之間實現互聯及信息交互存在許多兼容問題，DLNA(Digital Living Network Alliance)及UPnP(Universal Plug and Play)等概念的提出即為旨在提供一種對各種智能電器，無線設備，各種電腦普遍適用的端到端網絡連接，本文將在UPnP協議的基礎上實現電視與用戶設備的互聯。個性化互動電視系統框架中各單元之間信息交互的實現過程，具體包括電視終端與服務器之間的信息交互、TV extension與服務器之間的信息交互及TV extension與用戶設備之間的信息交互，其中解決TV extension與用戶設備信息交互過程中存在的雙向數據推送問題是本文的主要工作內容。

1 電視終端與網頁服務器之間的信息交互

電視終端與應用網頁服務器之間的信息交互如圖1所示。

由圖1可知電視終端與網頁服務器之間的信息交互主要包括3個方面，分別為初始應用數據的傳輸，用戶偏好數據的傳輸及應用發送給用戶的反饋信息。

1.1 初始應用數據的傳輸

本文系統中的初始應用數據的傳輸發生在電視終端解析到廣播信息中新的AIT信令信息時，該部分功能電視終端已經完成，本文涉及的部分只包括設定AIT信令中應用數據在網頁服務器上的具體位置信息。

1.2 用戶偏好數據的傳輸

此部分的用戶偏好數據傳輸是指電視終端上運行的應用對已經存儲在服務器上的用戶數據的狀態進行實時檢測。具體實現方式為通過JavaScript腳本以一定的頻率重復使用XMLHTTPRequest對象請求服務器上的用戶數據，并將其與前一輪獲得的數據進行比較，如果數據發生改變，則認為用戶狀態發生更新，這時，電視終端上運行的應用將通過本地JavaScript腳本結合獲得的最新用戶數據對應用進行動態更新。

圖1 電視終端與網頁服務器之間的信息交互

在實現過程中，本文采用JQuery技術對XMLHTTPRequest進行實際處理，采用JQuery的原因是JQuery較好地解決了XMLHTTPRequest在不同瀏覽器中的處理方式兼容問題，且簡化了處理過程，另外JQuery庫體積較小，不會給瀏覽器帶來過多的負擔。

1.3 應用發送給用戶的反饋信息

由個性化互動電視系統各部分之間的數據傳輸過程及所采用的通信協議及圖1，本文的設計方案中電視終端可以通過應用服務器及TV extension向用戶發送反饋信息，此部分仍然利用XMLHTTPRequest對象實現。具體實現方式為應用利用動態加載JavaScript腳本的方式調用服務器端的PHP腳本，該PHP腳本在收到與調用信息一起傳來的反饋信息時，通過TCP socket將反饋信息進一步發送給TV extension。其中在動態加載JavaScript請求PHP腳本時采用了JSONP數據傳輸方式，JSONP本來是用于實現跨域數據交換［1］的一種技巧，而本文的研究內容中應用需要動態請求的數據與原應用數據屬于同一服務器來源，但考慮到將來可能的擴展需求，本文直接采用JSONP方式進行數據交換，其中服務器端腳本可以進一步設置是否允許跨域請求。

本文中以動態加載腳本的方式調用服務器端腳本時的源目的地址實例如下:

其中sendTTSCmd.php為服務器端用于向TV extension發送反饋消息的腳本，且可以向應用返回一個簡單的處理結果;speechText為應用發送給用戶的反饋信息;handleTTSResponse為應用端用來處理返回的JSON數據的方法。

2 TV extension與網頁服務器之間的信息交互

根據個性化互動電視系統各部分之間的數據傳輸過程及所采用的通信協議，TV extension與網頁服務器之間的信息交互如圖2所示，主要包括服務器通用TV extension向用戶發送應用的反饋信息和TV extension向服務器發送用戶數據。

圖2 TV extension與網頁服務器之間的信息交互

2.1 服務器向TV extension發送應用反饋信息

對于這一部分的信息交互實現，本文中采用的為基本的TCP stream socket。因為TV extension無法提前獲知服務器何時會向自己發送反饋信息，而服務器只有在運行的應用調用其腳本時才向TV extension發送信息，因此實現過程中服務器端作為TCP client，TV extension作為TCP server實現信息的監聽。

2.1.1 服務器端發送數據

具體地，服務器端使用PHP腳本實現的簡單TCP socket發送功能實例如下:

其中192.168.0.2:27016為TV extension的IP地址及接收服務器數據的端口號，此處服務器將發送給TV extension的反饋信息(speechText)封裝為JSON格式以便于TV extension端對各種收到的數據采用同一規則進行判斷。

2.1.2 TV extension端接收數據

在Android設備上，TV extension的功能具體以Android獨立應用(app)的形式存在，TV extension app里利用server socket對服務器(此時為TCP client)的數據進行監聽。此部分的實現是在 UPnP TV-TTS的項目基礎上完成的，UPnP TV-TTS項目中已經實現了中間設備(相當于本文中的TV extension)通過server socket對電視終端發送的數據的監聽功能，本文主要的工作為重新定義TV extension收到服務器端數據以后的各種工作步驟，關于server socket與服務器端TCP client之間的通信連接建立過程，可以參見文獻［2］。

在本文的實現中，TV extension的server socket在收到數據以后，首先將數據還原為JSON對象，判斷其是否含有“ServerData”節點，如果有，則說明該數據來自服務器。接著，TV extension將進一步獲取的數據的“ServerDataType”信息，如code example 4.2中的“UseTTS”，如果此時有用戶存在，TV extension會將接收到的數據進一步推送給用戶設備。

2.2 TV extension向服務器發送用戶數據

實現方案中TV extension在收到或刪除用戶數據時會將新的用戶數據或者默認用戶設置數據發送給網頁服務器，網頁服務器收到這一請求后會將其中的用戶數據以TV extension的名稱保存下來。具體地通過HTTP GET的方式將用戶數據作為請求的附加參數進行傳送，實例如下:

其中，服務器端的getUserProfile.php可以獲得請求參數TVid與profile，并將profile的具體內容保存為名稱為TV1的文件。

使用HTTP［3］GET的原因為HTTP GET是網頁服務器支持的基本協議類型，其他可用的協議如HTTP PUT，HTTP POST等，可能需要對服務器作進一步的配置，本文實際使用的HTTP協議均為HTTP GET協議。

3 TV extension與用戶設備之間的信息交互

TV extension與用戶設備之間的信息交互是本文的主要工作內容，具體工作為在UPnP AV框架及TTS(Text To Speech)功能基礎［4］之上，完成用戶的實時檢測，用戶數據從用戶設備向TV extension方向的傳輸，TV extension收到用戶數據后的處理過程，及應用反饋信息從TV extension向用戶設備方向的反向傳輸。下面將首先對UPnP基本工作過程及UPnP-TTS項目進行簡單介紹，并指出其用于本文工作中的不足之處。

3.1 UPnP基本工作過程

根據控制點與設備的連接與交互過程，UPnP網絡的工作過程［5］分為六步即尋址、發現、描述、控制、事件及展示。本文的具體工作為在此基礎上實現設備之間的雙向通信及信息交換。

在現有的UPnP設備框架標準及UPnP AV框架標準中，控制點與設備連接之后，在控制點發送給設備一個信息之后，設備返回的信息內容及返回信息的時間是相對于發來的信息是固定的無法任意修改的，而本文需要實現在設備收到另一設備的信息之后，在一個不可預知的時間延遲之后返回一個自行設定的可變信息參數，為需要在UPnP協議的基礎上進行擴展。具體地，本文利用UDN參數的唯一性與固定性，在一個設備(此處僅指物理設備)向另一個設備發送信息時同時將自己的UDN參數發送給該設備，這樣該設備就可以判斷出在眾多的設備中信息是由哪一個設備發出的，且在需要時發送反饋信息給該特定設備。

3.2 UPnP TV-TTS項目基礎

基于TCP/IP及UPnP協議實現的TTS功能框架［4］如圖3所示。

圖3 基于TCP/IP及UPnP協議實現的TTS功能框架

圖3中的Philips電視內嵌了為TTS特殊定制的TCP/IP通信模塊，當遙控器選中電視屏幕上的文本信息時電視上的TTS模塊會將當前選中的文本信息通過TCP socket發送給control point，control point在收到該信息后會將有用的文本信息通過UP-nP連接發送給用戶設備(圖中的media renderer)，用戶設備在接收到該信息后會通過內嵌的TTS功能讀出接收到的文本信息。

3.3 基于UPnP TV-TTS項目實現的TV extension與用戶設備之間的雙向通信

3.3.1 TV extension與用戶設備之間的基本通信過程

圖4 基于本文的個性化互動電視系統實現的TTS功能框架

在本文的工作過程中，TV extension相當于圖3中的control point，用戶設備相當于圖3中的media renderer。與圖3不同的是，本文使用的Philips TV沒有內嵌TCP/IP TTS通信模塊，且本文中設定的電視發送給用戶的反饋信息來自運行在電視終端上的應用，因此實際上與TV extension進行通信的為網頁服務器。另外圖3中的用戶設備(media renderer)與中間設備(control point)之間的通信是單向進行的，即用戶設備只需要接收中間設備發送來的文本信息并讀出。而本文中需要用戶設備首先將自己的偏好設置數據通過中間設備(TV extension)傳送給應用，為此需要實現中間設備與用戶設備的雙向數據推送。

相對于圖3，以TTS功能為個性化案例，本文基于個性化互動電視系統實現的TTS功能框架如圖4所示。

圖5 TV extension與用戶設備之間的基本通信過程

前述已經闡明了圖4中電視終端、網頁服務器及TV extension之間的信息交互，TV extension與用戶設備之間的信息交互過程如圖5所示，其中為方便描述，仍然保留TV extension與服務器之間的信息交互部分，其中假設UPnP設備搜索與描述部分的功能已經完成。用戶設備需要向TV extension推送偏好設置數據，同時TV extension需要向用戶推送TTS文本信息。由于 media renderer不具備向control point主動推送數據的功能，因此圖3中中間設備僅具有 control point功能，用戶設備僅具有media renderer功能的實現機制不能滿足本文的工作需求。同時由于物理設備在具體實現UPnP功能時可以同時具有多種邏輯功能，因此本文的初步設想是使得TV extension與用戶設備均具有control point與media renderer的功能，從而完成雙向的數據推送。二者在作為media renderer時都通過Play-Text接口接收傳送給自己的數據。

3.3.2 用戶向TV extension發送數據的流程

用戶設備作為control point向TV extension推送自己的偏好設置信息時的信息交互是TV extension作為media renderer在收到PlayText發來的用戶數據信息之后觸發PlayTextCB回調函數，PlayTextCB將進一步完成用戶數據向應用服務器的推送。

3.3.3 TV extension向用戶設備發送數據的流程及用戶離開時的數據處理

用戶設備作為 media renderer在收到 PlayText發來的TTS文本信息之后觸發PlayTextCB回調函數，PlayTextCB將會調用Android設備內嵌的TTS功能讀出收到的TTS文本信息。另外本文的TV extension端control point監聽了設備離去事件，用戶離開時會發送離開消息給TV extension，觸發設備離開事件，此時TV extension會將一套應用默認設置數據發送給服務器并覆蓋原來的用戶數據。

3.3.4 TV extension與用戶設備之間實現雙向數據推送時存在的問題及本文提出的解決方案

在本文的個性化系統設計中，TV extension向用戶設備發送數據的流程及用戶離開時的數據傳輸過程總是在用戶向TV extension發送數據之后，因為TV extension只有在已經有用戶連接到網絡并獲得該用戶的個人偏好設置數據之后，才有可能發送反饋信息給該設備。這里存在的一個問題是，當系統中有多個相同類型的設備存在時(本文僅考慮media renderer設備類型)，TV extension將獲得多個設備描述信息，而之前用戶設備在使用Play Text發送信息時不會自動將自己的設備位置信息同時發送給TV extension，因此TV extension無從獲知之前發送信息的是哪一個用戶設備，同時由于TV extension沒有獲知發來信息的設備是哪一個，因此當檢測到設備離開事件時，TV extension也無法確認當前離開的設備是之前發送信息的設備還是無關設備。

基于上述問題描述，本文基于設備device UDN (Unique Device Name)這一參數的唯一性與不變性提出了一種解決方案，具體方式為將用戶的device UDN參數也包含在用戶向TV extension發送的數據之中，詳細描述如圖6所示。

如圖6用戶設備在發送自己的偏好設置數據之前，將自己的device UDN參數也加入到該數據之中，這樣TV extension在收到用戶數據之后就可以從中獲得用戶的device UDN參數，并在之后發送反饋信息給用戶時利用該device UDN作為PlayText的參數定位到用戶設備。另外，當TV extension檢測到設備離開事件時，也可以將離開設備的UDN與該當前用戶的device UDN參數進行比較，從而判斷出離開的設備是否為正在使用的用戶設備，如果離開的設備是正在使用的用戶設備，TV extension將會發送默認的應用設置參數給應用服務器覆蓋之間的用戶數據，并將之前存儲的用戶device UDN參數及用戶數據刪除。

圖6 TV extension與用戶設備之間進行雙向數據推送的解決方案

4 結語

闡述了個性化互動電視系統框架中各單元即電視終端與服務器之間、TV extension與服務器之間及TV extension與用戶設備之間信息交互的實際實現過程，在UPnP AV基礎之上提出了一種多UPnP設備存在情況下在UPnP設備之間實現雙向數據推送的解決方案，并描述了其實現方式。

［1］ http://developer.yahoo.com/javascript/howto-proxy.html［EB/ OL］.2010.

［2］ 小胖’s Blog.簡單的tcp socket編程及分析［EB/OL］.http:// eshock.blogbus.com/logs/43398355.html，2009.

［3］ Hypertext Transfer Protocol—HTTP/1.1，Internet RFC 2616［S］. http://www.w3.org/Protocols/rfc2616/rfc2616.html，2004.

［4］ Yu Weiwei.Text-To-Speech Interface for TV［Z］.Internship Report for Fontys University of Applied Sciences，2012.

［5］ UPnPTMDevice Architecture v1.1［S］.2008.

夏菽蘭(1969- )，女，副教授，研究方向為電子技術與信息處理;

王吉林(1966- )，男，江蘇鹽城人，鹽城工學院信息學院教師，副教授，主要研究方向為電子技術與信息處理。

Implementation of Information Interaction among the Units Based on Personalized Interactive Television System

XIA Shulan1*，WANG Jilin2
(1.School of Electrical Engineering，Yancheng Institute of Technology，Yancheng Jiangsu 224051，China; 2.School of Information Engineering，Yancheng Institute of Technology，Yancheng Jiangsu 224051，China)

The communication between assistance device and user device is based on UPnP AV architecture.The paper proposes a solution to realize the two-way data push between two UPnP devices when there are multiple devices existing via taking use of the uniqueness and stability of the deivce parameter UDN.

interactive television;information interaction;real-time personalization

10.3969/j.issn.1005－9490.2014.02.010

TN919.8;TN943

A

1005－9490(2014)02－0215－06

2013-06-07修改日期:2013-07-05

EEACC:6430J