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

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


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

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


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

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