具体实施方式
下面的本发明示例性实施例的框架是HAVi适用到IP型网络,但显然本发明不限于这种类型的网络,而是可以用于适用到任何类型的网络。如果要发现连接到网络的设备,本发明还可以用在HAVi以外的规范的背景中。
图1表示在由1394总线组成的网络上的HAVi规范中定义的HAVi栈的结构。HAVi栈在JAVA中可以通过API(“应用编程接口”)1.1编程。设备的栈可以包括用于控制设备的模块(DCM,“设备控制模块”)或用于控制设备的功能性的模块(FCM,代表“功能控制模块”)1.7。栈还可以包括固有模块(native module)1.8。登记库1.2(“登记”)维护网络上所有设备的库(base)。事件管理器1.3负责在网络上传输由设备状态改变引起的事件。资源管理器1.4允许共享资源和调度动作。设备控制模块管理器1.5使之能够安装和删除允许控制网络上其他设备的模块。流管理器1.6使之能够管理网络上的音频和视频内容的实时传输流。消息收发系统1.9负责在系统各个部件之间传递消息。用于适配传输层的模块1.10(TAM代表“传输适配模块”)允许组装和拆分HAVi消息。传输介质管理器1.11(CMM代表“通信介质管理器”)允许系统的其他元件直接使用传输介质而不必和消息管理器打交道。这对于实现其中控制依赖于专有协议的非HAVi设备控制模块尤其必要。流管理器、TAM或CMM与网络(在这个例子中为1394)驱动程序1.12对话。
图2表示本发明示例性实施例的背景中HAVi栈的结构。除了传输层适配模块2.10以外,其余与前一图中的元件相同。这里,我们发现用作TAM的TCP协议。传输介质管理器必须适配于IP而不再是1394。于是我们有了CMMIP 2.11。这些模块与IP层2.12交互。流管理器自身将与提供用于流交换的IP上服务质量的802.1p/Q2.13层交互。
HAVi规范为软件组件定义了网络上的唯一标识符,该标识符称为SEID,代表“软件元素标识符”。该标识符用80位编码,并且包括两个不同的元素,第一标识符对应于网络上容纳(host)软件组件的设备的唯一标识符。该标识符64位,称为GUID,代表“全球唯一标识符”。该GUID由IEEE 1394标准定义,用于唯一标识1394设备,也就是说,存储在任何1394设备的只读存储器中的1394部件的EUI-64。让我们回想一下,如IEEE在其文档“Guidelinefor 64-bit Global Identifier (EUI-64TM)Registration Authority”中定义的那样,EUI-64由24位的公司标识符和后面的40位扩展组成。
构成SEID的第二元素是使之能够在其所在的设备内标识组件的16位标识符。通过将网络上设备的唯一标识符与该设备上组件的标识符相拼接,可以唯一地标识HAVi网络内的任何软件组件。
然而,在IP网络上并没有等效的64位标识符。在该网络上,只存在IPv4中的32位IP地址和IPv6中的128位地址,或者当网络是以太网时的48位MAC地址。第一种构思是通过将相关网络的自身标识符与设备本地的标识符拼接起来构建SEID,补充后者来构建80位的SEID。事实上这种解决方案在要连接异构网络(例如,连接基于1394的总线和基于IP的另一个)的情况下无效。在这种情况下,根据64位GUID和16位本地标识符构建的SEID与例如根据32位IP地址和48位本地标识符构建的其他SEID共存,这可能导致标识符的不唯一。特别地,对应于IP地址169.254.100.16和本地标识符0x000000123456的SEID 0xA9FE6410000000123456可能与由GUID0xA9FE641000000012和本地标识符0x3456组成的SIED冲突。因此,不管希望管理HAVi的网络类型如何,保持作为标识符的SEID、64位GUID和16位本地标识符的结构都是合适的。
因此,需要找到在目的网络上创建GUID而不干扰1394上的标准GUID(即,IEEE的EUI-64)的方法。这些EUI-64是用于表示生产该设备的公司的24位公司标识符和由产生EUI-64的公司管理的40位扩展的拼接,40位扩展负责它在所产生的整个标识符集合内的唯一性。公司标识符由IEEE登记管理机构以集中的方式管理。第一种在IPv4网络上构建这样的GUID的方法是用0xFFFFFFFE与所讨论的32位IP地址拼接。由于0xFFFFFFF不能由IEEE分配为公司标识符,因此这种构建GUID的方法一定会产生不与EUI-64形成的GUID冲突的标识符。
另一种解决途径是使用IEEE提出的通过扩展48位MAC地址构造EUI-64的方法,也就是说,选择0xccccccFFFFeeeeee的构建形式,其中0xcccccc表示MAC地址中标识公司的部分,而0xeeeeee表示MAC地址中的扩展。在这种情况下,根据IEEE限制40位扩展分配不能以0xFFFFFF或0xFFFFFE(它们分别预留为MAC-48和EUI-48的扩展标记)开始这一事实来确保不与EUI-64冲突。
下面的表归纳了前面段中提到的各种格式的地址或标识符。
MAC-48地址 |
{公司id 24位扩展 24位} |
EUI-48 |
{公司id 24位扩展 24位} |
EUI-64 |
{公司id 24位扩展 40位} |
SEID |
{GUID 80位本地id 16位} |
在IPv6网络的情况下,问题稍有不同。特别地,这个版本的IP提出128位地址。IPv6地址由两个64位部分组成,接口的前缀和标识符。该标识符设计成对应于除了公司标识符中的“u/l”位以外的EUI-64。然而,该差别并不影响EUI-64的唯一性。因此可以直接采用IPv6地址的后64位来构建HAVi设备的GUID。
在IPv4和IPv6双兼容设备的情况下,我们应当采用设备的IPv6地址所定义的标识符。对于按照IPv4在网络上启动并随后变为v6兼容的设备,将该设备当作断开并且再连接,因此为其分配从其v6地址产生的标识符。
当HAVi设备连接到网络上时,它进入网络发现阶段,使它能确定该网络上可用的其他设备。在低层网络是1394总线的传统情况下,由插入新设备引起的总线复位阶段随着每个设备获得连接到总线的每个其他设备的总线上的地址列表而终止。然后,新设备可以询问网络的每个设备以便在其只读存储器中读出该设备的自我描述数据(SDD代表“Self Describing Device”自我描述数据)。特别地,HAVi规范要求每个设备具有此类可寻址的数据,以遵从IEEE 1212标准。
因此,出现了将该发现阶段移植到1394总线之外的网络上的问题。一方面,我们没有允许网络设备取得连接到网络的所有设备的地址列表的固有机制。另一方面,像遵从IEEE 1212标准时那样到远程设备的存储器中读取通常是不可能的。相反,IP网络拥有广播机制,能够在网络上没有特定接收者地发送消息,每个连接的设备接收所述消息。每个连接到网络的设备因此可以在网络上发送广播消息来声明自己。
还存在组播机制。该机制定义组播地址。通过该机制,任何送往该组播地址的分组由订阅该广播地址的任何设备接收。因此可以定义公知的组播地址来专门在网络上声明HAVi设备。每个连接到网络上的设备在该组播地址上声明自己,并且订阅该专用地址的网络的所有其他设备将接收该声明。
该消息还可以包括包含在SDD中的自我描述信息,这样网络的每个设备可以用其信息更新其表,就仿佛它去从设备的存储器中读取它一样。该消息可以例如使用IP上UDP协议。这样,我们将从UDP错误检测中受益。还可以定义专用于HAVi的UDP端口。图3中给出了该信息的一个例子。其中有:
-HAVi消息版本:如在HAVi 1.1规范中一样,它给出该设备支持的HAVi系统的版本。
○第一字节预留,必须为0×00
○第二字节是主版本号
○第三字节是副版本号
-操作码:值为
○0:有效
○1:退出
○2:请求
○3到255:预留
-更新标识符:初始化为0的8位字段,每当消息中的值改变时递增。这使得可以在不必比较所有值的情况下确定消息是否发生改变。
-设备种类:定义设备的种类,可以是:
○0b0000:预留
○0b0001:基本音频视频(BAV)
○0b0010:中间音频视频(IAV)
○0b0011:完全音频视频(FAV)
○0b0100到0b1111:预留
-DM:该位对IAV设备指定是否实现DCM管理器,对于BAV设备必须设为0,对FAV设备必须设为1。
-SM:该位对IAV设备指定是否实现流管理器,对于BAV设备必须设为0,对FAV设备必须设为1。
-RM:该位对IAV设备指定是否实现资源管理器,对于BAV设备必须设为0,对FAV设备必须设为1。
-DC:该位对IAV设备指定是否实现数据所指向的交互的控制器(DDI代表“Data Driven Interaction”,数据驱动交互),对于FAV设备指定是否实现DDI控制器和2级用户接口,对BAV设备必须设为0。
-DS:该位指定设备的状态是活动还是不活动的,在IP网络上的HAVi设备的情况下必须设置为1,这是由于在网络上声明自己的事实表示该设备是活动的。
-Br:该位指定设备是否是桥。
-GUID:设备的全球唯一设备标识符。
-IPV4地址:设备的IPv4地址,如果未定义的话必须设为0。
-IPV6地址:设备的IPv6地址,如果未定义的话必须设为0。
-厂商ID:厂商的标识符,由IEEE以全球和唯一的方式定义,能够标识设备的制造商。
-厂商长度:指定标识厂商的文本的长度,每个字符编码为16位统一码(unicode)。
-厂商文本:标识厂商的字符串,HAVi规范中限于50个字符。
-型号ID:标识由设备制造商定义的设备型号。
-型号长度:指定标识型号的文本的长度,每个字符编码为16位统一码。
-型号文本:标识模块的字符串,HAVi规范中限于50个字符。
下面的字段只对BAV设备可用。对于IAV、FAV设备和不提供该信息因而也没有DCM(“设备控制模块”)、编码单元的BAV设备,这些字段必须存在,并且必须设为0,直到后面跟着两个零填充字节的“DCU URL大小”字段。
-DCU大小:传输的DCM编码单元的字节大小。
-DCU安装空间:不包括工作区在内,安装该单元所需的存储器大小。
-DCU工作区:编码单元所需的工作区的估计。
-DCU URL大小:DCU的地址的字节大小。
-URL数据:形成找到编码单元的地址的字符串。
我们刚刚看到,连接到网络上的设备如何向网络的其他设备声明自己。现在有必要定义该设备如何发现网络的其他设备。为此,设备在网络上发出询问。该询问可以以与前面所述的声明消息相同的方式发出,也就是说,通过利用公知地址广播或组播。该地址可以与声明消息所定义的相同,或者可以是该消息特定的另一地址。接收到该询问的网络的每个设备用单播消息响应。该响应消息因而只发送到新连接的设备。该响应消息必须包括作为声明的、一般从SDD中读取的自我描述信息。该响应消息可以采用与声明消息相同的形式,将操作码字段设为0,代表“有效”。请求的格式可以是图3所述的格式,其中“HAVi消息版本”字段具有与声明中相同的含义,而“操作码”字段设为2。也可以想象,在新设备连接到网络后响应于声明消息直接发送响应消息。在这种情况下,声明消息和请求消息被合并。
连接到该网络上的设备发现网络阶段的步骤归纳在图5中。在步骤5.1中,设备连接到网络上。一旦连接后,它在步骤5.2中向已经连接到网络的设备发出包含与其相关的自我描述信息的声明消息。该自我描述信息是1394设备的SDD中包含的信息的对应部分。一旦该设备在网络上声明了自己后,它通过广播或组播向所有其他设备(5.3)发出请求。网络的其他设备在步骤5.4中通过向请求的发送者发送响应消息来响应该请求,该响应消息包含关于它们的自我描述信息。
HAVi规范在其结构中提供通信介质管理器CMM。CMM是取决于HAVi规范使用的底层网络的实体。该管理器提供到网络的接口,从而HAVi组件可以与不能完全通过HAVi消息交换监视的设备交互。通过提供允许直接使用底层网络的接口,HAVi模块可以驱动网络上的任何设备,而不管其操作模式和它使用的协议(甚至是专有的)如何。该管理器提供的另一功能是实现网络上的HAVi设备的全球唯一标识符(GUID)与它们的IP地址之间的链接。该管理器还使之能够实现网络上指示的机制。依靠该指示机制,设备将可以订阅网络上另一设备发送的指示。因此它将能够以消息的形式接收这些指示并且管理这些订阅,这将在构成该管理器的各种功能的描述中看出。这些指示的订阅对应于接收到的IP分组的过滤(作为它们来源的函数和该分组参与的IP上协议的函数)。适用于IP网络(CMMIP)的管理器包括下面函数:
Cmmip∷GetGuidList
Status Cmmip∷GetGuidList(out sequence<GUID>guidList)
guidList是网络的所有设备的GUID的列表。
该函数使之能够取得网络的所有HAVi设备的GUID的列表。
Cmmip∷GetIP Address
Status Cmmip∷GetIPAdress(
In GUID guid,
Out sequence<IpAddress>ipAddressList)
guid是HAVi设备的GUID。
IpAddressList是其GUID是网络上的guid的设备的IP地址列表。一个设备最多能有一个IPv4地址和一个IPv6地址。
该函数返回其GUID所标识的设备的IP地址。
Cmmip∷GetGuid
Status Cmmip∷GetGuid(
in IpAdress ipAdress,
out GUID guid)
ipAdress是设备的IP地址,
guid是设备的GUID。
该函数返回其IP地址所标识的设备的GUID。
Cmmip∷Send
Status Cmmip∷Send(
In Boolean useGuid,
In GUID guid,
In IpAddress ipAdress,
In uchar hopLimit,
In uchar upperProtocol,
In sequence<octet>data)
useGuid是布尔值,用于确定是使用目的设备的GUID还是IP地址来标识它。
guid是在useGuid设为true时消息目的设备的GUID。
ipAdress是在useGuid设为false时消息目的设备的IP地址。
hopLimit是消息在被销毁前可以经过的路由器的最大数量。
upperProtocol是IP分组中包含的协议的代码,例如UDP的代码是17。
data表示希望发送的数据的字节序列。
该函数使之能够将IP分组发送到由其GUID或其IP地址所标识的设备。
Cmmip∷EnrollIndication
Status Cmmip∷EnrollIndication(
in Boolean useGuid,
in GUID guid,
in IpAdresse ipAdress,
in OperationCode opCode,
in uchar upperProtocol,
out Boolean conflicts)
useGuid是布尔值,用于确定是使用目的设备的GUID还是IP地址来标识它。
guid是在useGuid设为true时消息目的设备的GUID。
ipAdress是在useGuid设为false时消息目的设备的IP地址。
opCode是呼叫方提供的操作码,也就是说,管理器CMMIP将放在它要发送给客户端的通知消息的“操作码”字段中的值。
upperProtocol是希望接收的指示所使用的协议。
conflicts在该订阅或(“登记”)与另一订阅冲突时具有值true。
该函数允许管理器CMMIP的客户端使用给定的协议订阅设备在网络上发送的指示。该机制使之能够作为发送者和IP上使用的协议的功能,过滤设备的接口接收到的IP分组。所有位设为1的IP地址(IPv4中的0xffffffff或IPv6中的0xffffffffffffffffffffffffffffffff)或者所有位设为1的GUID使之能够指示不希望对于发送者地址的过滤,而是希望接收具有正确协议的所有接收的分组而不管发送者是谁。管理器CMMIP将存储产生其从消息管理系统获得的Cmmip∷EnrollIndication的客户端的SEID,从而允许在它接收对应于该订阅的IP分组之后利用我们稍后要见到的CmmipIndication通过消息向其送回所讨论的分组。同一IP分组可以对应于几个订阅,并且在这种情况下,将被发送到所有订阅模块。CMMIP也负责当删除客户端时或者从网络拔出设备时更新过滤器。
Cmmip∷DropIndication
Status Cmmip∷DropIndication(
in Boolean useGuid,
in GUID guid,
in IpAdresse ipAdress,
in uchar upperProtocol)
useGuid是布尔值,用于确定是使用目的设备的GUID还是IP地址来标识它。
guid是在useGuid设为true时消息目的设备的GUID。
ipAdress是在useGuid设为false时消息目的设备的IP地址。
upperProtocol是不再希望接收的指示所使用的协议。
该函数允许客户端解除订阅。
<Client>∷CmmipIndication
Status<Client>∷CmmipIndication(
in Boolean useGuid,
in GUID guid,
in IpAdresse ipAdress,
in uchar upperProtocol,
in ushort dataSize,
in sequence<octet>indicationData)
useGuid是布尔值,用于确定是使用目的设备的GUID还是IP地址来标识它。
guid是在useGuid设为true时消息目的设备的GUID。
ipAdress是在useGuid设为false时消息目的设备的IP地址。
upperProtocol是希望发送的指示所使用的协议。
dataSize是估计要发送的数据字节大小。
indicationData,这是表示构成该指示的实际数据的字节序列。
CMMIP使用该函数将对应于满足订阅准则的IP分组的消息发送给客户端。在接收到IP分组后,CMMIP测试设备上存在的客户端的当前的各种订阅。如果IP分组的来源和协议对应于客户端的订阅所确定的准则,则通过该函数向其发送分组。
NewDevice
void NewDevices(in sequence<GUID>guidList)
guidList是新设备的GUID列表。
该事件是由CMMIP在一个或多个新设备在网络上声明它们自己时产生的。该事件仅在容纳CMMIP的设备上本地提供,这是因为网络上的每个HAVi设备都具有它自己的HAVi,因此没有必要广播该事件。
GoneDevices
void GoneDevices(in sequence<GUID>guidList)
guidList是已被断开的设备的GUID列表。
该事件是由CMMIP在一个或多个设备断开网络时产生的。通过发送通知断开的消息,或者通过尝试与所讨论的设备通信或在发现阶段期间的时限超时,检测到设备与网络的断开。在这种情况下,CMMIP通过事件管理器发送事件,通知退出网络的设备的GUID。该事件仅在容纳CMMIP的设备上本地提供,这是因为网络上的每个HAVi设备都具有它自己的CMMIP,因此没有必要广播该事件。
ChangedDevices
void ChangedDevices(in sequence<GUID>guidList)
guidList是改变了IP地址的设备的GUID列表。
该事件是由CMMIP在网络的一个或多个设备改变了IP地址时产生的。该改变可能是由于检测到IP或其他地址之间的冲突而引起的。CMMIP通过事件管理器发送事件,通知改变了IP地址的设备的GUID。该事件仅在容纳CMMIP的设备上本地提供,这是因为网络上的每个HAVi设备都具有它自己的CMMIP,因此没有必要广播该事件。希望如此的客户端可能在接收到该事件后通过Cmmip∷GetIpAddress函数请求所讨论的一或多个设备的新地址。
GuidListReady
void GuidListReady(
in sequence<GUID>guidList,
in sequence<GUID>goneDevices,
in sequence<GUID>newDevices,
in sequence<GUID>changedDevices)
guidList是连接到网络的所有HAVi设备的GUID列表。
goneDevices是在重新配置期间从网络中消失的设备的GUID列表(可能为空)。
newDevices是在重新配置期间网络上出现的设备的GUID列表(可能为空)。
changedDevices是在重新配置期间改变了IP地址的设备的GUID列表(可能为空)。
该事件是由CMMIP在网络的设备的GUID列表可用时产生的。事实上,在网络的重新配置期间,在CMMIP完成新配置的网络发现阶段的时刻之时,该列表不再可以通过Cmmip∷GetGuidList函数得到。该事件是设备本地的事件。
ProxyGuidCreated
void ProxyGuidCreated(
in GUID proxyGuid,
in sequence<IpAddress>ipAddressList)
proxyGuid是为非HAVi设备创建的GUID。
ipAddressList是非HAVi设备的IP地址列表。
当网络的HAVi设备希望与网络上的非HAVi设备交互时(LAV代表“Legacy Audio Video device”,传统音频视频设备),它可以安装能够管理该交互的设备控制模块(DCM)。为了在HAVi环境中标识该设备,需要为它分配GUID,非HAVi设备不具有这样的标识符。希望与其交互的HAVi设备因此将为它分配GUID并且将用作由该GUID寻址的该设备在HAVi环境中的中继(代理)。将通过该事件在网络上(而不是本地地)通知该中继GUID的创建,通知创建的中继GUID和由此标识的设备的IP地址。
因此,如此实现的CMMIP模块使之能够构建网络的设备的GUID列表,并且实现这些设备的GUID与IP地址之间的链接。还可以在网络上向通过其GUID或其IP地址已知的设备发送IP消息。也提供了以它们的来源和IP上使用的协议为特征登记来接收IP消息的可能性。
能够在IP网络上支持HAVi的设备6.1具有图6所述的结构。它必须具有内部总线6.4,链接执行HAVi栈所述模块的处理器6.2。存储在设备的只读存储器6.3中的这些程序将被上载到随机存取存储器6.5中以便执行。与Ip网络6.7的交流将通过IP网络接口6.6实现。