專利名稱：橋接UPnP網(wǎng)絡(luò)和HAVi網(wǎng)絡(luò)的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種用于橋接UPnP和HAVi網(wǎng)絡(luò)的方法。更具體地，將其應(yīng)用于家用通信網(wǎng)絡(luò)。
背景技術(shù)：
橋接器的功能包括表示UPnP網(wǎng)絡(luò)上的HAVi軟件元素(例如設(shè)備控制模塊和功能部件模塊)以及表示HAVi網(wǎng)絡(luò)上的UPnP設(shè)備和服務(wù)。
根據(jù)HAVi規(guī)范，HAVi網(wǎng)絡(luò)上的每一個設(shè)備均必須擁有配置存儲器，可以從該存儲器中讀取特定的說明性數(shù)據(jù)(“SDD”數(shù)據(jù)表示自說明數(shù)據(jù))。
表示UPnP設(shè)備的橋接器的代理設(shè)備不是實際存在的設(shè)備，因此它不具有這種配置存儲器。
以湯姆森多媒體公司的名義于2000年5月31日提交、并于2000年12月14日公布的專利申請WO 0076131涉及了一種用于橋接HAVi(家庭音頻/視頻互操作性)網(wǎng)絡(luò)和UPnP(通用即插即用)網(wǎng)絡(luò)的方法。

發(fā)明內(nèi)容
本發(fā)明涉及一種用于橋接HAVi網(wǎng)絡(luò)和UPnP網(wǎng)絡(luò)的方法，在橋接器設(shè)備級，這兩種網(wǎng)絡(luò)均與表示一個網(wǎng)絡(luò)上來自另一網(wǎng)絡(luò)的軟件元素的橋接器設(shè)備相連，所述方法包括以下步驟—檢測與UPnP網(wǎng)絡(luò)相連的UPnP設(shè)備；—針對每一個UPnP設(shè)備，創(chuàng)建代理HAVi設(shè)備控制模塊，用于在HAVi網(wǎng)絡(luò)上表示該UPnP設(shè)備；其特征在于以下步驟
—注冊該代理HAVi設(shè)備控制模塊，其中聲明代理HAVi設(shè)備控制模塊是遺留(legacy)設(shè)備型的。
由于UPnP設(shè)備在HAVi網(wǎng)絡(luò)中被表示為遺留(LAV)設(shè)備，因此其他HAVi設(shè)備就不能期望在這些UPnP設(shè)備中存在任何配置存儲器。
根據(jù)本發(fā)明的實施例，該方法還包括以下步驟—至少檢測UPnP網(wǎng)絡(luò)上特定類型的UPnP服務(wù)；—針對每一個檢測到的UPnP服務(wù)，創(chuàng)建代理HAVi功能部件模塊，其中將表示給定UPnP服務(wù)的代理HAVi功能部件模塊集成到代理HAVi設(shè)備控制模塊中，所述代理HAVi設(shè)備控制模塊表示與UPnP網(wǎng)絡(luò)上的UPnP服務(wù)相關(guān)的UPnP設(shè)備；—發(fā)布該代理HAVi功能部件模塊。
根據(jù)本發(fā)明的實施例，該方法還包括以下步驟—檢測HAVi網(wǎng)絡(luò)上的HAVi設(shè)備控制模塊和HAVi功能部件模塊；—針對每一個HAVi設(shè)備控制模塊，創(chuàng)建代理UPnP設(shè)備，并針對每一個HAVi功能部件模塊，創(chuàng)建UPnP服務(wù)；—根據(jù)UPnP規(guī)則，發(fā)布該代理UPnP設(shè)備和服務(wù)。
根據(jù)本發(fā)明的實施例，聲明表示UPnP設(shè)備和/或服務(wù)的代理HAVi軟件元素是非61883類型的。
根據(jù)本發(fā)明的實施例，該方法還包括以下步驟在代理軟件元素注冊之前，請求與該代理軟件元素相關(guān)的說明性數(shù)據(jù)，并只在接收到說明性數(shù)據(jù)之后，注冊該代理軟件元素。


參考附圖，通過對實施例的非限制性說明，將使本發(fā)明的其它特性和優(yōu)點顯而易見，其中圖1是包括HAVi-UPnP橋接器設(shè)備的網(wǎng)絡(luò)的方框圖。
圖2是在連接UPnP設(shè)備之前，包括HAVi設(shè)備的圖1所示網(wǎng)絡(luò)的方框圖。
圖3是在UPnP設(shè)備的發(fā)布階段，圖4所示網(wǎng)絡(luò)的方框圖。
圖4是創(chuàng)建了UPnP設(shè)備的DCM和FCM之后，圖5所示網(wǎng)絡(luò)的方框圖。
圖5是詳細示出了當(dāng)HAVi設(shè)備控制UPnP設(shè)備時的消息流程的圖6所示網(wǎng)絡(luò)的方框圖。
圖6是當(dāng)由HAVi設(shè)備發(fā)起時，圖1所示網(wǎng)絡(luò)的方框圖以及用在本實施例中以在橋接器上建立連接的步驟的方框圖。
圖7是當(dāng)由UPnP設(shè)備發(fā)起時，網(wǎng)絡(luò)的方框圖以及用在本實施例中以在橋接器上建立連接的步驟的方框圖。
具體實施例方式
根據(jù)本實施例，橋接器設(shè)備連接HAVi網(wǎng)絡(luò)和UPnP網(wǎng)絡(luò)。HAVi表示“家庭音頻/視頻互操作性”并定義了特別是基于IEEE1394總線的、用于控制家庭網(wǎng)絡(luò)的軟件棧。HAVi規(guī)范的當(dāng)前版本是2002年5月15日發(fā)布的v1.1，可以從HAVi公司得到，其地址是2694 Bishop Drive，Suite 275 San Ramon，CA 94583，USA。UPnP表示“通用即插即用”，并且也提供了基于因特網(wǎng)協(xié)議(IP)的網(wǎng)絡(luò)控制軟件棧。可以從微軟公司管理的UPnP論壇得到UPnP規(guī)范。
如果處于HAVi網(wǎng)絡(luò)或UPnP網(wǎng)絡(luò)中，則應(yīng)用程序和其他元素必須能夠確定有效的功能性。
在HAVi網(wǎng)絡(luò)中，功能性由被稱作FCM(功能控制模塊)的軟件元素表示。從等級上說，F(xiàn)CM表示設(shè)備，始終包含于DCM(設(shè)備控制模塊)中。一個DCM可以包含多個FCM(例如，一個表示數(shù)字VCR的DCM包含調(diào)諧器FCM以及VCR FCM)。對于每一個設(shè)備只有一個DCM。
在HAVi網(wǎng)絡(luò)中，如果軟件元素希望將其功能性提供給網(wǎng)絡(luò)，它必須將自己注冊到被稱作“注冊處”的本地軟件元素。當(dāng)創(chuàng)建FCM時(可以在設(shè)備啟動時期或運行時期進行，例如DCM控制單元或DCU的下載)，軟件元素將自身注冊到其自身設(shè)備的注冊處。
當(dāng)應(yīng)用程序希望知道在網(wǎng)絡(luò)中哪個服務(wù)可用時，向網(wǎng)絡(luò)的所有注冊處發(fā)送查詢。
此外，在系統(tǒng)運行的同時，存在著針對動態(tài)創(chuàng)建的軟件元件的事件系統(tǒng)。為了發(fā)布軟件元素的注冊或刪除，注冊處可以使用兩種事件新軟件元素(NewSoftwareElement，表示剛剛注冊了軟件元素)以及離去的軟件元素(GoneSoftwareElement，表示剛剛解除了軟件元素的注冊)。在HAVi網(wǎng)絡(luò)中不需要輪詢。
如果軟件元素比HAVi注冊處更新(即該軟件元素是未知類型的)，則該軟件元素還將被識別且表示為HAVi網(wǎng)絡(luò)中的新功能性。
UPnP不會集成與HAVi注冊處類似的概念。不過，在UPnP網(wǎng)絡(luò)中，可以在網(wǎng)絡(luò)中發(fā)布設(shè)備的服務(wù)。出于此目的，UPnP使用了“用于組播的UDP上的HTTP”(HTTPMU)。應(yīng)用程序還可以搜索網(wǎng)絡(luò)中的服務(wù)。這種網(wǎng)絡(luò)發(fā)現(xiàn)協(xié)議是SSDP(簡單服務(wù)發(fā)現(xiàn)協(xié)議)?？梢詫⑵渑c針對事件通知的GENA協(xié)議(普通事件通知體系結(jié)構(gòu))結(jié)合。當(dāng)應(yīng)用程序希望知道哪個服務(wù)可用時，它發(fā)送SSDP發(fā)現(xiàn)組播消息。與該請求匹配的服務(wù)會以單播模式(HTTPU)發(fā)回響應(yīng)。查詢可以非常廣(例如所有服務(wù))或有更多的限制(例如，特定類型的服務(wù))。
當(dāng)服務(wù)在網(wǎng)絡(luò)中是新的時，該服務(wù)會發(fā)送GENA-SSDP“有效(alive)”組播消息，從而發(fā)布它的出現(xiàn)。
該有效消息和發(fā)現(xiàn)響應(yīng)消息包括使用時限(‘max_age’)字段。該最大使用時限字段以秒為單位表示該服務(wù)的有效性。如果服務(wù)在此時間之后仍然出現(xiàn)，則服務(wù)必須發(fā)送另一有效消息(或進行另一次發(fā)現(xiàn)查詢)。
在UPnP網(wǎng)絡(luò)中，使用簡單對象訪問協(xié)議(SOAP)消息進行控制。
為了使一個網(wǎng)絡(luò)中的任意設(shè)備能夠與另一個網(wǎng)絡(luò)中的任意設(shè)備進行通信，橋接器設(shè)備的任務(wù)是以將消息從一側(cè)轉(zhuǎn)換到另一側(cè)的方式連接兩個網(wǎng)絡(luò)。橋接器還應(yīng)該能夠使流通過。
圖1給出了HAVi網(wǎng)絡(luò)的例子，該網(wǎng)絡(luò)包括與IEEE 1394總線2相連的HAVi設(shè)備1，此HAVi網(wǎng)絡(luò)與包括連接了IP網(wǎng)4的UPnP設(shè)備3的UPnP網(wǎng)絡(luò)相連，這兩個網(wǎng)絡(luò)均通過橋接器設(shè)備5進行連接。橋接器5包括HAVi協(xié)議棧、IP協(xié)議棧以及用于執(zhí)行從一個網(wǎng)絡(luò)到另一個網(wǎng)絡(luò)的控制消息、事件、流、…的轉(zhuǎn)換或映射的軟件。
根據(jù)本實施例，對于設(shè)備和應(yīng)用程序而言，該橋接器是透明的。
根據(jù)本實施例，UPnP設(shè)備由HAVi DCM表示，而UPnP服務(wù)由DCM中的HAVi FCM表示，該DCM表示與該服務(wù)相連的UPnP設(shè)備。相反，HAVi DCM設(shè)備由UPnP設(shè)備表示，而HAVi FCM服務(wù)由與表示包括此FCM的DCM的設(shè)備相關(guān)的服務(wù)表示。下文中，將橋接器創(chuàng)建的軟件元素稱作“代理”軟件元素。
橋接器的功能是在每一個網(wǎng)絡(luò)中適當(dāng)?shù)乇硎驹O(shè)備針對HAVi網(wǎng)絡(luò)上的每一個DCM或FCM，橋接器創(chuàng)建UPnP設(shè)備或UPnP服務(wù)。相反，分別針對每一個UPnP設(shè)備和服務(wù)，橋接器分別創(chuàng)建HAVi DCM和FCM。
每當(dāng)添加或刪除服務(wù)、設(shè)備、FCM或DCM時，橋接器設(shè)備負(fù)責(zé)更新每一個網(wǎng)絡(luò)的表示。
橋接器可以管理多個表示UPnP設(shè)備的HAVi DCM，這取決于每一個網(wǎng)絡(luò)的配置。由于橋接器設(shè)備本身除了其橋接器功能之外還有其他功能，因此橋接器還可以管理其自身的DCM。例如，可以將橋接器功能包含于諸如電視接收機或衛(wèi)星解碼器之類的設(shè)備中。
根據(jù)HAVi規(guī)范并符合IEEE 1212標(biāo)準(zhǔn)，作為IEEE 1394設(shè)備的每一個HAVi設(shè)備包括配置存儲器。HAVi和IEEE 1394定義了多個保存于該存儲器中的參數(shù)。這些HAVi定義的參數(shù)被稱作自說明數(shù)據(jù)或“SDD”，而且可以被其它設(shè)備讀取。表示UPnP設(shè)備的橋接器的DCM不表示真實的IEEE 1394設(shè)備，因此不具有符合HAVi/IEEE 1394的、可以包含SDD數(shù)據(jù)的配置存儲器。
為了避免這個問題，聲明橋接器為了表示UPnP設(shè)備而創(chuàng)建的DCM是遺留設(shè)備(“LAV”或遺留音頻/視頻設(shè)備)。認(rèn)為這些可能是或可能不是IEEE 1394設(shè)備的設(shè)備不遵循HAVi，并因此不會要求包含SDD數(shù)據(jù)。其他軟件元素可以使用被稱作DCM∷GetDeviceClass的DCM應(yīng)用程序編程接口(API)函數(shù)，識別該DCM的本質(zhì)。
根據(jù)HAVi規(guī)范，DCM或FCM自身向本地注冊處注冊。在注冊過程中，DCM提供一定量的信息，其中有被稱作目標(biāo)ID(TargetID)的數(shù)據(jù)結(jié)構(gòu)，其表示正在注冊的軟件元素是設(shè)備(DCM)、設(shè)備的功能部件(FCM)還是應(yīng)用程序模塊。在前面兩種情況下，TargetID數(shù)據(jù)結(jié)構(gòu)還表示出該DCM或FCM是否符合IEC 61883標(biāo)準(zhǔn)，該標(biāo)準(zhǔn)中定義了IEEE1394網(wǎng)絡(luò)上同步流(即音頻和視頻流)的傳送。沒有哪兩個TargetID數(shù)據(jù)結(jié)構(gòu)是相同的。
HAVi規(guī)范需要TargetID數(shù)據(jù)結(jié)構(gòu)中包含全局惟一標(biāo)識符(“GUID”)，該GUID標(biāo)識符具有惟一識別IEEE 1394設(shè)備的64位的數(shù)值。將此GUID標(biāo)識符存儲于設(shè)備的配置ROM中，并且在網(wǎng)絡(luò)復(fù)位中保持不變。在流的上下文中，目標(biāo)ID中給定的GUID識別要發(fā)送此流或是要接收此流的物理HAVi設(shè)備。針對特定的設(shè)備類型，該物理HAVi設(shè)備可以不是與流源或宿設(shè)備相關(guān)的DCM的主機設(shè)備，而是最終目標(biāo)設(shè)備GUID。
表示UPnP設(shè)備的DCM沒有自己的GUID標(biāo)識符。但是，由于橋接器也向HAVi網(wǎng)絡(luò)發(fā)送從UPnP網(wǎng)絡(luò)接收到的流，或是接收要傳遞到UPnP設(shè)備的來自HAVi設(shè)備的流，這些表示UPnP設(shè)備的DCM必須在它們的TargetID數(shù)據(jù)結(jié)構(gòu)中使用橋接器的GUID標(biāo)識符。
在家庭網(wǎng)絡(luò)環(huán)境中，獨立于其作為HAVi和UPnP網(wǎng)絡(luò)之間橋接器的功能，典型地將橋接器設(shè)計用于發(fā)送或接收以及處理音頻和視頻流。于是，它具有自己的DCM，并且此DCM是符合IEC 61883的類型的。在其注冊過程中，橋接器本身的DCM使用其自己的GUID標(biāo)識符。
在這種情況下，表示UPnP設(shè)備的DCM的設(shè)備類型不能是符合IEC61883的DCM，這是因為這樣會導(dǎo)致在HAVi網(wǎng)絡(luò)中有兩個相同TargetID數(shù)據(jù)結(jié)構(gòu)。即使橋接器本身的DCM不是DCM_61883類型的，如果該橋接器處理多于兩個UPnP設(shè)備的DCM，將會出現(xiàn)同樣的問題。
建議將UpNP設(shè)備的DCM聲明為非61883 DCM。在這種情況下，這些DCM的TargetID數(shù)據(jù)結(jié)構(gòu)仍然包含該橋接器的GUID標(biāo)識符(該橋接器是這些DCM的主機)，但通過另一參數(shù)將這些TargetID加以區(qū)分，該參數(shù)是橋接器內(nèi)部賦予每一個DCM的標(biāo)識符。
在網(wǎng)絡(luò)的HAVi側(cè)將UPnP設(shè)備表示為非61883設(shè)備的事實并不意味著這些設(shè)備不能發(fā)送或接收流，只是這些流不必符合IEC 61883。
類似方式，將表示UPnP服務(wù)的代理FCM聲明為非61883 FCM。
如上所述，針對目標(biāo)軟件元素類型，HAVi規(guī)范定義了五個不同的值(DCM_61883、DCM_NON61883、FCM_61883、FCM_NON61883以及AM)。作為解決上述問題的不同實施例，定義了附加的目標(biāo)類型
DCM_PROXY或DCM_NON1394-將DCM識別為表示UPnP設(shè)備(或另一非HAVi網(wǎng)絡(luò)上的設(shè)備)FCM_PROXY或FCM_NON1394-將FCM識別為表示UPnP服務(wù)(或另一非HAVi網(wǎng)絡(luò)上的服務(wù)或功能性)由于以可以包含多個設(shè)備和服務(wù)的根設(shè)備來表示物理設(shè)備，因此在UPnP側(cè)不存在這種問題。
當(dāng)它接收到已經(jīng)為UPnP設(shè)備或服務(wù)而創(chuàng)建了新代理DCM或FCM的事件時，HAVi應(yīng)用程序可能希望獲得有關(guān)這個DCM或FCM的附加信息。當(dāng)將由橋接器處理的新代理設(shè)備或服務(wù)通知給UPnP設(shè)備或服務(wù)時，反向情況也是一樣的。
出于此目的，橋接器組合了與為其創(chuàng)建代理的每一個HAVi DCM或FCM，或是UPnP服務(wù)或設(shè)備有關(guān)的信息。在發(fā)布代理軟件元素的創(chuàng)建之前，組合此信息。
橋接器執(zhí)行下列步驟(a)針對新HAVi軟件元素，橋接器從注冊處請求該元素的屬性(使用Registry∷RetrieveAttribute函數(shù))。
針對新UPnP軟件元素，橋接器通過前述的簡單服務(wù)發(fā)現(xiàn)協(xié)議“有效”消息，接收該軟件元素的說明。此說明是按照XML編寫的統(tǒng)一資源定位器(URL)，并且根據(jù)本發(fā)明，由橋接器對其進行解析，以提取出所有的相關(guān)信息。
(b)橋接器創(chuàng)建新代理軟件元素。
(c)橋接器使用HAVi網(wǎng)絡(luò)上的“NewSoftwareElement”事件消息(針對代表UPnP軟件元素的代理)或者使用UPnP網(wǎng)絡(luò)上的‘ssdp∷alive’組播消息(以發(fā)布HAVi軟件元素的代理)，發(fā)送發(fā)布該代理軟件事件的有效性的事件。與UPnP相一致，周期性地重復(fù)此組播消息。
表1中給出了事件映射

表1現(xiàn)在對橋接器中消息的傳輸進行說明。當(dāng)HAVi軟件元素將消息發(fā)送到代理DCM或FCM時，橋接器將該消息轉(zhuǎn)換為UPnP消息。如果該消息涉及設(shè)備或服務(wù)控制，則它基于簡單對象訪問協(xié)議，或者如果它涉及事件通知，則它基于普通事件通知體系結(jié)構(gòu)協(xié)議。當(dāng)UPnP設(shè)備或服務(wù)尋址橋接器的代理設(shè)備或服務(wù)時，使用相反的原則。
這種轉(zhuǎn)換并不應(yīng)用于所有消息。在下面的非限制性示例中，并未轉(zhuǎn)發(fā)HAVi消息，而是直接通過代理元素應(yīng)答代理FCM接收Fcm∷GetDcmSeid命令；其應(yīng)答返回其所屬代理DCM的SEID。
將HAVi惟一標(biāo)識符(HUID)用于惟一地識別DCM、FCM或應(yīng)用程序模塊。針對UPnP設(shè)備或服務(wù)的每一個HAVi代理，創(chuàng)建HUID。HUID標(biāo)識符包括TargetID以及多個其它標(biāo)識符“InterfaceId”、“Vendorld”、“n1Uniqueness”以及“n2Assigner”。將“n1Uniqueness”設(shè)為真(TRUE)，對于DCM，將“n2Assigner”設(shè)為非(NONE)，而對于FCM，則將“n2Assigner”設(shè)為NONE或DCM。結(jié)果，將請求UPnP設(shè)備的HAVi代理的HUID傳輸?shù)南⒆鳛檎埱骃EID標(biāo)識符傳輸?shù)南⑦M行處理。
至少不將HAVi實體發(fā)送的下列消息轉(zhuǎn)發(fā)到UPnP側(cè)，而是直接由橋接器進行應(yīng)答Fcm∷GetDcmSeidDcm∷GetHuidDcm∷GetFcmSeidListFcm∷GetHuid為了實現(xiàn)適當(dāng)?shù)霓D(zhuǎn)換，在HAVi API和UPnP API之間建立了等效關(guān)系。由于不可能始終存在直接一對一的對應(yīng)，因此橋接器必須利用多個消息來仿真單個消息以得到適當(dāng)結(jié)果，或者發(fā)回對初始消息的響應(yīng)，通知發(fā)送者不能處理他的請求。
當(dāng)存在這種等效關(guān)系時，表2中給出了HAVi VCR API、HAVi音頻/視頻桌面APi與UPnP AV傳送API之間的等效關(guān)系


表2表3中列出了與表2中給出的API相關(guān)的事件之間的等效關(guān)系

表3圖2到5示出了通過將UPnP設(shè)備與UPnP網(wǎng)絡(luò)相連而在橋接器觸發(fā)的處理。在圖2的初始網(wǎng)絡(luò)中，只有HAVi設(shè)備1與該HAVi網(wǎng)絡(luò)相連，并且沒有設(shè)備與IP網(wǎng)絡(luò)相連。橋接器將該HAVi設(shè)備向UPnP網(wǎng)絡(luò)表示為包括代理服務(wù)16和代理連接管理器服務(wù)10的代理設(shè)備15。為了使說明清晰，除非說明需要，圖3到圖5沒有示出對應(yīng)橋接器UPnP側(cè)HAVi設(shè)備的代理軟件元素。
如圖3所示，在UPnP VCR的情況下，UPnP設(shè)備3與IP網(wǎng)絡(luò)4相連。通過SSDP協(xié)議，將此連接通知給橋接器5。然后，橋接器分析設(shè)備的XML說明并發(fā)現(xiàn)新連接的設(shè)備是包括VCR服務(wù)的VCR設(shè)備。
如圖4所示，為了仿真該UPnP VCR設(shè)備和服務(wù)，橋接器創(chuàng)建了HAVi DCM 8和HAVi VCR FCM 9作為代理軟件元素。然后，這兩個代理軟件元素向橋接器的消息傳送系統(tǒng)(圖4中的“MSG”)請求SEID標(biāo)識符并向橋接器的注冊處(“REG”)注冊。此注冊使注冊處在HAVi網(wǎng)絡(luò)上發(fā)送新軟件元素事件。
當(dāng)HAVi設(shè)備1的應(yīng)用程序希望向UPnP VCR 3發(fā)送播放(PLAY)命令時，該應(yīng)用程序通過使用其本身的消息傳送系統(tǒng)向橋接器5的VCRDCM發(fā)送“VCR∷Play”消息來實現(xiàn)。然后橋接器的應(yīng)用程序向UPnP VCR服務(wù)發(fā)送適當(dāng)?shù)目刂葡?。這如圖5所示。
流的建立如圖6和7所示，其中圖6涉及建立由HAVi設(shè)備1發(fā)起的流，而圖7涉及建立由UPnP設(shè)備3發(fā)起的流。
在圖6的情況下，設(shè)備1的應(yīng)用程序—例如用戶接口—調(diào)用其流管理器(SM)中的“FlowTo”函數(shù)，其是HAVi中負(fù)責(zé)建立流的軟件元素。FlowTo函數(shù)調(diào)用的參數(shù)是源和宿FCM插頭的標(biāo)識符。該信息由被稱作“FcmPlug”的數(shù)據(jù)結(jié)構(gòu)提供。使用前面已經(jīng)說明過的“TargetID”數(shù)據(jù)結(jié)構(gòu)識別要連接的FCM(在這種情況下，是HAVi設(shè)備1的FCM以及表示UPnP設(shè)備3的橋接器代理FCM)。源插頭的TargetID表示橋接器的GUID標(biāo)識符。
流管理器在有關(guān)DCM和FCM的級別中使用“DCM∷Connect”函數(shù)調(diào)用觸發(fā)需要的內(nèi)部插頭連接。流管理器還保留IEEE 1394同步資源并更新有關(guān)設(shè)備的IEC 61883插頭控制寄存器(步驟E1和E2)。
根據(jù)本實施例，通過對代理DCM 8的函數(shù)調(diào)用“DCM∷Connect”觸發(fā)UPnP網(wǎng)絡(luò)上對應(yīng)的連接處理。代理DCM調(diào)用UPnP連接管理器服務(wù)10和11，UPnP連接管理器服務(wù)10和11分別是表示為UPnP設(shè)備的HAVi設(shè)備1(即，連接管理器服務(wù)10是代理連接管理器服務(wù))的一部分以及UPnP VCR 3的一部分。被調(diào)用的函數(shù)是“ConnectionMgr∷PrepareForConnection”(步驟E3)。代理DCM還建立IP連接(步驟E4)以及橋接器中的內(nèi)部連接(E5)。
盡管在圖6的示例中，代理DCM建立了內(nèi)部橋接器連接，而在另一個實施例中，此任務(wù)由橋接器的專用軟件模塊執(zhí)行。此模塊集中了所有的內(nèi)部流連接，這簡化了處理及帶寬資源管理。
注意到在實現(xiàn)相同結(jié)果的同時，可以改變某些步驟的次序。
圖7示出了當(dāng)由UPnP設(shè)備3發(fā)起時，建立流的步驟?？刂泣c13(即UPnP控制器)在源和宿連接設(shè)備10和11同時調(diào)用UPnP的“ConnectionMgr∷PrepareForConnection”命令(步驟E1)?？刂泣c13還創(chuàng)建了IP連接(步驟E2)。橋接器15對來自控制點13的命令的接收觸發(fā)了對橋接器的流管理器14的函數(shù)調(diào)用(“FlowTo”函數(shù)—步驟E3)。與前面的情況相同，流管理器調(diào)用DCM并建立HAVi設(shè)備和橋接器之間的61883連接(步驟E6)。
在圖6和圖7的情況下，代理DCM和代理UPnP設(shè)備都必須確定它們是否應(yīng)當(dāng)分別在接收到DCM∷Connect函數(shù)調(diào)用和ConnectionMgr∷PrepareForConnection函數(shù)調(diào)用時進行動作。
例如，當(dāng)UPnP設(shè)備發(fā)起連接時，當(dāng)接收到來自設(shè)備1的流管理器的命令時，代理DCM應(yīng)當(dāng)建立連接，而在接收到來自橋接器的流管理器的命令時，代理DCM則不建立連接。類似地，當(dāng)連接服務(wù)10接收到來自DCM 8的“ConnectionMgr∷PrepareForConnection”函數(shù)調(diào)用時，應(yīng)當(dāng)建立UPnP網(wǎng)絡(luò)中的連接，而當(dāng)從UPnP設(shè)備3的控制點接收到函數(shù)調(diào)用時，則不應(yīng)有所動作。
上述說明主要集中于HAVi DCM/FCM和UPnP設(shè)備/服務(wù)的等效關(guān)系。應(yīng)當(dāng)注意到，除DCM和FCM之外的某些HAVi軟件元素可能需要UPnP側(cè)的代理。此外，代理UPnP設(shè)備可能還必須集成除了表示HAViFCM的代理服務(wù)之外的其它服務(wù)。例如，盡管HAVi使用了系統(tǒng)元素流管理器，UPnP設(shè)備還需要連接管理器服務(wù)，從而能夠處理某些流。還可以添加其他服務(wù)。
權(quán)利要求
1.一種用于橋接HAVi網(wǎng)絡(luò)和UPnP網(wǎng)絡(luò)的方法，在橋接器設(shè)備級，這兩個網(wǎng)絡(luò)均與表示一個網(wǎng)絡(luò)上來自另一網(wǎng)絡(luò)的軟件元素的橋接器設(shè)備相連，所述方法包括以下步驟—檢測與UPnP網(wǎng)絡(luò)相連的UPnP設(shè)備；—針對每一個UPnP設(shè)備，創(chuàng)建代理HAVi設(shè)備控制模塊，用于在HAVi網(wǎng)絡(luò)中表示該UPnP設(shè)備；其特征在于以下步驟—注冊該代理HAVi設(shè)備控制模塊，其中將代理HAVi設(shè)備控制模塊聲明為遺留設(shè)備型。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于還包括以下步驟—至少檢測UPnP網(wǎng)絡(luò)上特定類型的UPnP服務(wù)；—針對每一個檢測到的UPnP服務(wù)，創(chuàng)建代理HAVi功能部件模塊，其中將表示給定UPnP服務(wù)的代理HAVi功能部件模塊集成到代理HAVi設(shè)備控制模塊中，所述代理HAVi設(shè)備控制模塊表示與UPnP網(wǎng)絡(luò)上的UPnP服務(wù)相關(guān)的UPnP設(shè)備；—發(fā)布該代理HAVi功能部件模塊。
3.根據(jù)權(quán)利要求1或2所述的方法，其特征在于還包括以下步驟—檢測HAVi網(wǎng)絡(luò)上的HAVi設(shè)備控制模塊和HAVi功能部件模塊；—針對每一個HAVi設(shè)備控制模塊，創(chuàng)建代理UPnP設(shè)備，并針對每一個HAVi功能部件模塊，創(chuàng)建代理UPnP服務(wù)；—根據(jù)UPnP規(guī)則，發(fā)布該代理UPnP設(shè)備和服務(wù)。
4.根據(jù)權(quán)利要求1至3之一所述的方法，其特征在于將表示UPnP設(shè)備和/或服務(wù)的代理HAVi軟件元素聲明為非61883類型。
5.根據(jù)權(quán)利要求1至4之一所述的方法，其特征在于還包括以下步驟在代理軟件元素注冊之前，請求與該代理軟件元素相關(guān)的說明數(shù)據(jù)，并只在接收到說明數(shù)據(jù)之后，注冊該代理軟件元素。
6.根據(jù)權(quán)利要求4所述的方法，其特征在于包括以下步驟向表示UPnP設(shè)備01和/或服務(wù)的非IEEE 1394代理軟件元素提供特定的目標(biāo)類型。
全文摘要
一種用于橋接HAVi網(wǎng)絡(luò)和UPnP網(wǎng)絡(luò)的方法，其中，在橋接器設(shè)備級，這兩種網(wǎng)絡(luò)均與從其中一個網(wǎng)絡(luò)到另一個網(wǎng)絡(luò)表示軟件元素的橋接器設(shè)備相連。該方法包括以下步驟－檢測與UPnP網(wǎng)絡(luò)相連的UPnP設(shè)備；－針對每一個UPnP設(shè)備，創(chuàng)建代理HAVi設(shè)備控制模塊，用于在HAVi網(wǎng)絡(luò)上表示該UPnP設(shè)備。本方法的特征在于以下步驟－注冊該代理HAVi設(shè)備控制模塊，其中將代理HAVi設(shè)備控制模塊聲明為遺留設(shè)備型。
文檔編號H04L12/40GK1545781SQ02816459
公開日2004年11月10日 申請日期2002年8月20日 優(yōu)先權(quán)日2001年8月22日
發(fā)明者讓-巴蒂斯特·亨利, 赫爾穆特·比爾克林, 特 比爾克林, 讓-巴蒂斯特 亨利 申請人:湯姆森許可貿(mào)易公司