专利名称：网络建立和管理协议的制作方法
技术领域：
本发明涉及一种网络协议，具体地说涉及协议的实施方式。
一种现有技术的网络管理协议是通用即插即用(UPnP)，它对于带宽、电池消耗以及一定程度内的成本都不是问题的互联网应用非常有用。协议在消费类电子(CE)中的实施方式确实存在，但是由于协议的范围，此类实施方式特别是对在其它情况下可能只需要极小处理能力的最简单的设备施加沉重的负荷。
因此，需要一种适于嵌入诸如灯、自动调温器和CE装置(电视、DVD以及PVR的遥控装置)之类简单设备中的协议，其实现起来简单并且成本有效、需要最小带宽、并且在具有不同性能的一个设备范围上更是可升级的。
此要求不限制为无线应用，而是可延伸到有线应用。
根据本发明的第一方面，提供一种包括如下数据的简单设备描述消息信号设备类型；一个指示发送设备是否具有可用扩展设备描述的字段；和一个规定数目的附加字段，其标识一个规定数目的附加状态设定，其中设备类型是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并且继承了该附属设备类型所取决于的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。
应当指出，虽然有取决于基本设备类型的至少一个分级结构(即受控设备的分级结构)，但是却没有控制器设备的相应的分级结构。这是为了保持简单设备描述消息尽可能短且简单，诸如通用遥控装置之类的许多控制器能够控制许多不同的设备类型。
简单设备描述包括较少数目或者中等数目的预确定字段，每个字段有固定长度。总的来说，虽然可以有一些变化，但是相同的字段将被用于每个消息。例如，一个复合设备可以包括一个附加整数字段，如下面将描述的那样它包括子设备的数目。
一些附加字段可以是可选的。例如，消息可以包括指示复合设备的子设备数目的一个字段。为了减少网络开销，只有在设备类型被记录为复合的一则消息的情况下可以包括此字段。
在一个特别优选的实施例中，本申请涉及一个将被称为归属统一控制语言(HUCL)的协议。消息信号实现由HUCL提供的简单功能。
优选地，简单设备描述消息具有一种令牌压缩消息的形式。根据HUCL协议，底层消息格式是诸如XML之类的人类可读格式。可是，为了节省带宽，以压缩的形式在联网设备之间传送信息。然而，因为所使用的压缩方法是令牌压缩(它用令牌替换了公共的串)，所以联网设备能够处理此类压缩消息。联网设备因此能够识别已压缩令牌而不必解压缩，至少足以识别一个要求简单设备描述响应的询问，并且然后用一个简单设备描述来响应。因此，能够用很少的开销实现联网设备。
一个适当形式的令牌编码在1999年6月24日的“wap binary XMLcontent format(wap二进制XML内容格式)”中被描述，该文可在http//www.w3.org/TR/wbxml处得到。
在第二方面，本发明涉及一个联网设备的操作方法，包括发送或接收一个规定长度的简单设备描述消息，该简单设备描述消息是从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示另一设备的类型的一个设备类型值；设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。
在第三方面，本发明涉及一种包括消息处理器的相应设备，所述消息处理器被安排来发送或接收规定长度的简单设备描述消息，简单设备描述消息是从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示另一设备的类型的一个设备类型值；设备类型值是从一个设备类型分级结构选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。
联网设备的操作方法可以涉及一种联网设备，其用适当的响应来响应输入的询问消息。因此，该方法可以包括从请求简单设备描述的另一设备接收一则简单设备描述询问消息；和向所述其它设备发送固定长度的简单设备描述消息。
本发明还涉及一种确定另一设备的设备类型的方法，相应地本发明可以包括如下步骤确立至少一个其它设备的地址；发送一则请求简单设备描述的简单设备描述询问消息给所述其它设备或者一个或多个其它设备；和从该其它设备或多个其它设备中接收简单设备描述消息。
为了找到比在简单设备描述询问消息中可用的更多的信息，该方法还可以包括发送一则扩展设备描述询问消息给所述其它设备或者多个其它设备中的一个，以向其它设备请求一个扩展设备描述；和从所述其它设备或者多个其它设备之一中接收一个可变长度的扩展设备描述。
该操作方法尤其可以涉及一种控制器设备，其具有该控制器能够控制的设备类型列表。
根据本发明的控制器设备优选地包括一个控制输入，并且基于在控制输入上接收到的信号来控制其它设备。另外，控制器设备可以实现一个或多个确定控制器能够控制什么设备的确定方法。
一种处理由设备是控制器设备类型这一事实引起的信息缺乏的方法是让控制器设备具有如下功能，即通过用能够由联网设备控制的设备类型列表中的最低设备类型(其或者是预确定设备类型或者是预确定设备类型所取决于的更高级别设备类型)级别进行响应来响应一则询问控制器是否能够控制一个预确定设备类型的输入控制器询问消息。控制器设备随后能根据在控制输入上接收到的信号来把从控制信号的预确定列表中选择的控制信号发送给其它设备。
替代控制器设备，所述设备可以是一个受控设备，它具有基本设备类型的设备类型或者取决于基本设备类型的设备类型；联网设备具有对控制器发送的基本设备指令进行响应的能力，所述指令至少包括一个预确定指令基本集。
为了应付多功能设备，预确定最高级别元件可以包括一个复合设备类型。
复合设备类型的联网设备具有一个预确定数目的其它设备类型的功能，并且被安排来通过发送一个包括作为复合设备的设备类型和其它设备类型的瞬时数目在内的简单设备描述来对一则要求简单设备描述的输入设备询问消息进行响应。
联网设备可以包括一个存储器，该存储器存储预确定简单设备描述消息，其中描述消息是从包括设备类型在内的人类可读形式的消息中预先压缩的一则消息；一个指示发送设备是否具有可用扩展设备描述的标记；和一个预确定数目的附加标记，其标识预确定数目的附加状态设定。因此，当需要时预先储存并发送出一则适当的消息，而不是在内部生成一则简单设备描述消息。
在另外一个方面，本发明涉及一个系统，包括多个联网设备，每个联网设备具有一个用于发送和接收网络消息的收发信机，所述联网信息包括标识联网设备的设备类型的设备描述消息；其中每个联网设备具有一个预确定设备类型，该预确定设备类型是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别；至少一个联网设备具有控制器设备类型；并且至少一个联网设备具有基本设备类型的设备类型或者取决于基本设备类型的设备类型。
该系统可以包括具有简单功能并且没有能力对消息进行解压缩的许多简单设备以及对消息进行解压缩以便解译它们并对它们进行操作的更为复杂的设备。更为复杂的设备可以具有复杂得多的功能，其代价是增加的开销以及处理器能力要求。
该系统还可以包括复合设备类型的至少一个联网设备，它具有预确定数目的其它设备的功能，所述预确定数目是一个大于等于2的整数；并且复合设备类型的至少一个联网设备的每一个通过发送一则包括作为复合设备的设备类型和表示预确定数目的其它设备的一个子设备数目在内的简单设备描述来对要求简单设备描述的一则输入设备询问消息进行响应。
本发明还涉及一种计算机程序，它定义一个设备类型分级结构，该设备类型分级结构具有包括控制器设备类型和基本设备类型在内的预确定最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别，所述计算机程序被安排来使联网设备发送和/或接收包括从该设备类型分级结构中选择的设备类型的简单设备描述消息。
所述计算机程序尤其可以包括实现用于与传输栈连接的传输适配层的代码；实现用于与应用程序连接的应用程序编程接口的代码；和实现一个消息传送层的代码，该消息传送层包括发送和接收令牌编码的人类可读消息传送格式的消息的能力，所述代码被安排来使联网设备识别要求简单设备描述响应的输入设备询问消息并且提供一个包括控制器设备类型的设备类型在内的简单设备描述响应；通过用能够由联网设备控制的设备类型列表中的最低设备类型(其或者是预确定设备类型或者是预确定设备类型所取决于的更高级别设备类型)级别进行响应来响应一则询问该联网设备是否能够控制一个预确定设备类型的输入控制器询问消息；并且执行下列步骤发送一则设备询问消息给另一设备；接收来自该其它设备的指示该其它设备的设备类型的一则响应，该设备类型是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别；在可以由联网设备控制的设备类型列表中，通过确定设备类型(其或者是所述其它设备的设备类型或者是该其它设备的设备类型所取决于的更高级别设备类型)的最低级别来确定联网设备能够控制该其它设备的程度；和通过发送从属于所确定的最低设备类型级别的控制信号列表中选择的控制信号来用所确定的最低设备类型级别的功能来控制该其它设备。
为了更好地理解本发明，现在将纯粹以举例的方式参考附图来描述各实施例，附图中
图1示出了一个使用根据本发明一个实施例来通信的设备对；图2示出了一个设备中的软件简图；图3是所述设备发现过程的流程图；图4是设备类型分级结构的简图；图5示出了控制器为了向受控设备通知它对那个设备的控制能力而执行的步骤；图6示出了控制器为了确定它对受控设备的控制能力而执行的步骤；图7是一个复合设备的设备发现过程的流程图；图8说明了一个复合设备的实施例；图9说明了一个复合设备的另一实施例；图10示出了软件的结构；图11说明了HUCL协议；和图12说明了一个简单设备描述消息。
协议HUCL是一个主要针对无线系统而设计的简洁低带宽控制协议。消息传送的格式基于XML，并且消息在发送之前被压缩。XML的使用提供一种可扩展可升级的压缩解决方案，这减少了所发送的数据，从而减少了发送机打开的时间量和功耗。
现在将参考一个简单的示例论述HUCL协议总的原理以及它在一个设备上如何操作。
参见图1，提供一个灯开关2和一个灯配件4。灯开关2有一个由用户操作的物理翘板开关6，和一个RF收发信机8及电池10，以及控制电路12及存储器14。灯配件也有一个RF收发信机8和存储器14，但是它是电源供电的并且有控制电路20来把功率施加到灯泡22。灯开关2因此是控制器的一种示例，它具有控制输入6(开关)，而灯配件是受控设备4的一种示例。控制器中的存储器14包括该控制器能够控制的设备类型列表24以及属于这些设备类型的控制功能。受控设备4和控制器设备2中的存储器14还包含代码26，用于使控制电路执行下面将更详细描述的方法。
图2示出了在每个设备上驻留于存储器14中的软件表示。当特定事件发生时，控制应用程序30与HUCL软件栈32通信。
同理，HUCL软件栈32与RF软件栈34通信，并且当特定事件发生时(例如接收到数据时)，RF软件栈34将回过来与HUCL软件栈32通信。
发送和接收消息36。消息可以是许多类型，包括简单设备描述询问消息或者许多其它消息类型中的任何一个。
现在将参考图3描述这些设备的操作。这样一对设备的操作中的第一阶段是开关发现配件的地址。这被称作设备发现，并且底层RF传输栈的一个要求是，设备发现或者被提供(在RF软件栈中)或者也可在传输栈之上实现设备发现(在HUCL软件栈的较低层中)。
通过向HUCL软件栈执行首先请求已知设备数目然后请求那些设备的网络地址的HUCL软件栈执行调用，发现过程由控制应用程序开始(100)(或许是作为某种用户交互的结果)。这些设备地址被返回。
取决于底层RF协议，可以以其它的方式建立网络地址。
设备发现阶段的最终结果是向控制应用程序提供(102)RF栈已知的全部设备的一个地址列表。在该过程中的这一时刻，控制应用程序除了每个其它设备的地址之外对每个其它设备一无所知。
应该注意虽然在此描述的过程中所有设备地址在请求描述之前被检索，但是技术人员应该明白存在其它可能性。例如，控制应用程序可以在接收每个设备地址之后、在所有设备地址都被获取之前立即请求一个描述。
配对过程中的第二阶段是控制应用程序搜集关于它有其地址的那些设备的信息。此信息被称为设备描述。控制应用程序通过向HUCL软件栈中进行调用、传送它从中需求设备描述的设备的地址，从而来完成这一点。
对于简单设备描述的请求然后通过RF链路被传送(104)到目的地设备，因此在上述开关/配件示例中，该请求被从开关发送到配件。在接收到请求时，目的地设备处的HUCL软件栈向控制应用程序进行请求设备描述的调用。定义描述的格式。如果还不是压缩形式，则该描述在被发送回到该请求的发送方之前被压缩。
当请求设备上的HUCL软件栈接收到(106)设备描述时，它被向上传递给控制应用程序。此时，该应用程序具有关于该设备的某些基本信息并且能够判断它是否希望与此设备进一步通信。
HUCL的一个设计目标是它适合于在非常简单的设备上操作，可是，彻底地描述一个设备所需要的信息可能十分复杂。下面的列表示出了一个设备可能想要提供的作为它的一部分描述的那类信息。
设备类型 例如DVD厂商名称 例如Philips(菲利蒲)型号 例如DVD1010/002序列号例如AH06848032345厂商URL 例如www.philips.com对于诸如在本章节一直使用于示例中的开关之类的最简的控制设备，许多这种信息可能是多余的。可是，它在一个更高端的‘PDA’类型的遥控装置上会有用，这类遥控装置具有一个能够向用户显示这些信息的屏幕。
在低端设备上的此类描述的处理会出现一个问题，因为它可能需要存储器(RAM)高速缓存它接收到的完整信息。这个问题比它最初看起来更糟糕，因为如上所示的描述数据的总的大小不确定，许多信息是‘自由文本’；厂商名称可以很长，URL甚至可能规定具有下面参数的精确页面，例如http//www.consumer.philips.com/global/b2c/ce/catalog/subcategory.jhtml？groupld＝VIDEO&divld＝0&catld＝DVD&sub Catld＝DVDPLAYER。
在HUCL中克服这一点的方法是设备描述被分裂为两列(tier)信息。第一列是一个简单化的、但是标识另外信息是否可用的设备描述。它不包含任何自由文本字段，因此它的全长是确定的。第二列扩展信息是可选的，但是提供附加信息。
参见图12，简单设备描述消息230包括设备类型字段232、指示扩展设备描述是否可用的字段238以及标识关键信息的其它字段236，其中关键信息例如是一个指示事件预订是否可用的标记。可选的整数字段234表示复合设备的子设备数目。技术人员应该理解消息230也可以包括为了简洁而被省略的报头和页脚。消息将包括为了清楚也同样被被省略了的压缩的XML令牌。简单设备描述的字段都是固定长度的，因此它们能够很容易被处理而不必解压缩。
在接收(106)(图3)简单设备描述230之后，简单设备描述230被传送回HUCL栈。
如果扩展设备描述可用并且控制器设备要求它时，则控制器设备控制应用程序可以发回一个“Get Extended Description(获得扩展描述)”请求108给设备。
在设备上接收此请求的HUCL栈向控制应用程序进行请求扩展设备描述的获得扩展描述调用。
扩展设备描述被传送回HUCL栈，并回到请求它的那个设备上的控制应用程序。扩展描述然后被返回(110)给请求设备。
如果在没有提供扩展设备描述的一个设备上接收到一个GetExtended Description(获得扩展描述)询问，则该请求将被简单地忽略。
再一次返回到本节一直所使用的开关/配件示例，从开关只知道配件地址的时候开始，开关向配件请求它的简单设备描述。在接收这个描述时，该描述提供足够的信息以使开关知道它正在与符合标准配件命令集的一个灯配件通话，它还知道(例如)该灯配件不能提供任何扩展设备描述。
当被请求时，设备应用程序被强制提供一个简单设备描述给HUCL栈。一个不提供任何扩展设备描述的设备可以忽略它接收到的对于此类信息的任何请求。
设备类型字段232被包括在一个由设备返回的简单设备描述(当被请求时)中，该字段标识设备的类型，例如电视、DVD、灯配件4等等。设备类型字段232将向(请求简单设备描述的)控制器标识该设备所符合的指令集。HUCL设备只须通过它们的类型标识符来标识它们自己，它们然后不接着发送消息来描述它们如何被控制；在HUCL中没有‘运行时间’业务描述概念。如果一个设备把它自己标识为一个灯配件，那么在此设备上可以被调用的命令集在HUCL规范中被标识用于灯配件类型设备。
参见图4，所有的设备类型取决于基本设备类型50。最高级别元件58在此示例中包括控制器设备类型52、受控设备的基本设备类型54以及告警设备类型56。
附属设备类型68取决于基本设备类型。在这个示例中，这些附属设备类型包括电视设备类型64、可调灯设备类型62以及PVR设备60。
设备类型分类是要产生一个系统，其目的是允许一个简单控制器识别它是否可以把一个设备控制到控制器能力的程度。
一个简单的开关可以与灯配件配对来开灯和关灯，但是人们可能主张开关的控制功能(即它打开或关闭一个设备的能力)应适用于能够接受打开/关闭概念的任何设备，例如电视、加热器、打印机。
能够实现这一点的一种方法是开关具有它知道如何控制(打开或关闭)的所有设备的一个列表，因此当它请求一个设备的简单设备描述时，它能够查看在返回的描述中的设备类型字段并确定该设备类型是否在它知道如何控制的它的设备类型列表内。
这种方法有两个显著的缺点。首先，开关是一个非常简单的设备，于是不希望在它内部的应用程序必须保存它能够控制的所有可能设备的一个列表，该列表将会相当大；其次，如果在生产开关之后创建一个新的设备类型(它能够接受简单的开关功能)，那么开关在它的列表中将没有这个新的设备类型，并且将认为它不能够控制该新的设备类型，即它不是可扩展的。
HUCL以一种分级的方式来对设备进行分类，如图4所示。设备类型字段232(图15)标识分级结构内的设备并因此即使新的设备被创建，只要它是从分级结构内的一个适当点所导出，则简单的开关将仍然知道它能够在一定程度上控制它。
在树中落得较低的设备继承了它上面的设备类型的功能。当命令被应用到树中的较低设备时，可能需要向那些命令附加某些解释，例如打开/关闭命令在被发送给一盏灯时将很显然把它打开/关闭，但是同一命令在被发送给电视时将把它置于或令它退出待机状态。
设备类型分级结构的关键益处是即使控制器不了解特定设备类型本身，它也能确定从中导出该特定设备类型的那个设备，它可能具有对于所确定的设备的某些知识，并因此也许能在某个较小的程度上(从所述特定设备的角度看)控制该特定设备。
例如，设想这样一个情况一个灯开关获得一个设备的地址，它向此设备请求简单设备描述；设备类型字段把该设备标识为电视，但是开关不把这识别为它知道的一个设备。可是，该开关还可以从该描述中确定该设备是它所知道的‘基本设备’的一个衍生物。最终的结果是尽管关于设备本身根本一无所知，开关也能够在控制器能力范围内控制电视，即开和关。该设备可以是在开关制造出来很久以后发明的被称为‘XYZ’的一个全新设备类别，但是只要它从一个基本设备中导出，则该开关仍然能够在一定程度上控制它。
虽然设备类型分级结构可以只有两列，控制器和基本设备最高级别元件，但是至少另外一列和/或最高级别元件是所希望的。这迎合了不遵守基本设备中的如上所示的功能的那些设备，即不具有基本‘打开’、‘关闭’功能的设备，例如告警。为了说明的目的，一个‘告警’类型设备56已如图4所示，并且可以理解，此‘告警’设备不想实现从基本设备中导出的设备所必须具有的正常的打开/关闭功能；因此它在分级结构中位于与基本设备54本身相同的最高级别58。
对分级结构的第二个扩展也如图4所示，即常规电视设备64下面的增强型电视设备66。在这里，增强型电视设备继承了基本设备54和电视设备64二者的所有功能，而且包括在常规电视中不存在的一些扩展功能。被设计来操作常规电视设备的常规电视遥控装置可以把增强型电视设备操作到常规电视设备功能的级别，但是不能控制扩展功能。
HUCL协议因此提供一种用于描述设备类型及其从中继承功能的、处在其之中的设备的可扩展机制。虽然多层分级结构的思想看起来可能是吸引人的，可是把它扩展超过三或四级将开始对简单设备描述的大小发生影响。
在HUCL内，可向控制器以及可控设备请求一个设备描述。当一个设备发送“获得简单描述”给一个控制器设备(例如一个开关)时，它被返回一个包含“控制器”设备类型的简单设备描述。控制器设备还可以使得扩展设备描述可用，所述扩展设备描述提供诸如生产商、型号等等之类另外的信息。
重要的是要注意由控制器设备返回的设备类型只是“控制器”52，没有在设备类型树中定义不同控制器类型设备的分级结构。这样做的原因同样是试图保持协议和消息大小小而简单。可以感觉到从诸如开关、电视遥控装置、PVR遥控装置等等之类的基本控制器中导出不同的控制器类型将是可能的。可是，对于诸如能够控制一个较宽设备范围的通用遥控装置之类的智能控制器将出现问题。为了在一个简单设备描述中包括所有可能的控制器类型将导致一个可能较大的消息，这违反了试图使初始简单设备描述简单的理想。为了确定一个控制器设备的准确能力，使用不同的机制。
确定控制器设备性能的第一个手段是借助在控制器设备上允许的扩展设备描述，并且该扩展设备描述可以包括诸如设备名(例如“通用遥控装置”)之类的信息，并且虽然这是文本信息且不是可由应用软件直接解译的，可是它可以被呈递给用户以帮助做出有关控制器的有信息根据的选择。
一个设备确定有关控制器的更多信息的第二个手段是对其进行询问。
询问的使用是一种对设备信息进行滴馈(drip-feeding)的强大机制，如果所述信息被一同提供，则将使请求者过载。
控制器类型的每个设备为其它设备提供一个装置，以便询问(120)它是否能够控制一个特定设备类型(图5)。在询问中传送的设备类型是与在设备类型分级结构中定义的简单设备描述中所使用的相同的字段。通过返回储存在控制器存储器14中的列表中的最低设备类型(即，在询问中传送的设备类型或者该设备类型所取决于的设备类型)，控制器返回(122)它能够将设备控制到的级别。例如，询问一个简单的开关它是否能够控制一个增强型电视设备。基于图4中说明的分级结构，应答是它能够将其控制到基本设备的级别。该开关本身通常将对增强型电视设备的设备类型毫无所知，但是由于设备类型还包括所继承的设备，所以它能识别基本设备并且把这作为它能够控制的最低的、在分级结构中更高的设备类型而返回。
这例如可以允许PDA类型的控制器设备充当控制网络的网络管理应用程序。
控制器还实现一个算法来确定开关是否能够控制在一则简单设备描述中返回给它的设备类型(图6)。当开关发现设备地址时，它向该设备询问(124)其简单设备描述，在接收此信息126后，开关测试(128)它是否能够在任何程度上控制此类型的设备，这是作为询问过程120的结果它所需要响应的同样的问题。结果是两个询问过程120、122、124、126、128没有太多增加简单开关设备的复杂度。这同样适用于其它简单设备。
可以预见，将有这些情况其中一个设备可以是全部经由同一物理地址访问的许多分离设备(例如全部都共同位于单个RF收发信机上)的一个复合体。
这类设备的示例是一组通过单个RF收发信机受控的单独可切换的灯，或者具有集成闹钟的一台电视，其中两个组件都同样可通过同一收发信机被遥控。
图7说明了发现过程。开关最初获取底层传输媒体已知的所有设备的地址，这包括四个单独可控灯的单一地址。开关发出(140)一个获得简单描述命令给该灯组，并且所出现的问题是答复应该是什么？如果四个设备描述被返回，那么这将是开关期望接收的四倍数据。返回多个简单设备描述不是怎么可升级的，并且例如如果在照明组中有20个灯，则将引起问题。
由HUCL提供的对此的解决方案是用于复合设备的特定设备类型。
复合设备返回(142)它的简单设备描述，其在设备类型字段232中包括它的作为“复合设备”的设备类型。该简单设备描述还在字段234中标识在此单一设备内有四个嵌入设备(在这个示例中)。
下一阶段，一旦控制器已经识别它正在与一个复合设备通信，则它将确定什么设备被嵌入在该复合设备内部。控制器还对复合设备进一步提出(144)获得简单描述请求，但是把所述请求定址到的特定嵌入设备。嵌入设备返回(146)它们的设备描述。
一旦控制器决定它将控制嵌入设备之一，则通过在每个命令中包括一个嵌入设备ID来将所有控制命令导向特定的嵌入设备。一旦复合设备的概念已经被建立，则它展现出将受益的若干感兴趣设备组合的可能性，在下面将讨论其中一些。
一个示例是由具有整体开关的一盏灯组成的单个设备，在此，所述开关功能是暴露的以便能够控制其它设备。当为了它的简单设备描述而被询问时，此设备把它自己展示为一个复合设备，但是当进一步被询问时，将发现一个嵌入设备是一个控制器，而另一个是一个可控设备，即灯设备。可以以这样的方式配置许多这样的设备以使操作任何一个设备上的开关令在所有设备上的灯被打开/关闭，例如，打开休息室中的任何一个桌灯使休息室中的所有桌灯都打开。
CE域内的复合设备的其它可能组合例如包括一个电视+录像机(VCR)或者DVD和VCR。如果需要，这些组合的每一个都可以把它自己描述为两个设备的复合物。
概念上，一个设备由核心设备加零个或多个子组件组成，例如电视设备60例如可以由电视设备60本身加调谐器64、音频66和显示器68子组件组成(见图8)。
还可设想单个设备可以具有一个子组件的一个以上实例的情况，例如一个电视/VCR混合设备可以具有两个调谐器62、64(其中电视有一个，VCR有一个(参见图9))以及音频66和显示器68组件。
可能会觉得XML和它的压缩/解压缩的使用在最简单的设备上是重量级的。使用XML来描述协议提供一种很容易为未来的增强而扩展并且描述和理解起来相对简单的解决方案，该解决方案能够很容易处理所构建的信息并立即与‘互联网域’兼容。
在XML(在HUCL内部定义)上使用加标记的压缩技术使得相对冗长的协议在大小方面传统纯粹的基于二进制的协议方向减小，其中某些附加的开销用来保持内容结构。
如果以压缩形式向一个人呈现一个命令，则使用关于指令结构的信息和数据值定义表，可以以与阅读任何其它基于二进制的协议的类似方式阅读该命令。二进制数据可能起源于基于XML的符号的唯一暗示是表示结构的数据的存在。
HUCL规范规定消息总是以它的压缩形式通过传输介质发送。可是，在一个简单设备上，应用程序可以对压缩消息直接操作，因此在该设备上不需要在HUCL软件栈内存在压缩/解压缩软件。在这种情况下，应用程序将以其预先压缩的形式储存(作为ROM中的一部分应用程序镜像)简单设备描述，它具有一个用于分析它接收的压缩协议消息的分析器，此分析器实质上与任何其它二进制协议分析器类似；任何响应消息也将需要以它们的压缩形式被储存。
使用此方法，诸如在本节一直使用的灯开关和灯配件示例之类的简单设备可以以简化的软件栈来实现，并且假定简单设备需要理解和发送的命令数相对小(开灯，关灯，切换，获得当前状态，获得设备描述等等)，则在应用软件上的开销最小。
这向设备提供一种可升级的解决方案，其中，实现对压缩数据进行操作的应用程序是实际的，可以这样做，但是当设备变得更复杂时，将有一个点，在这个点上，在栈中包括压缩/解压缩功能并且使应用程序以其完整的XML符号的形式使用协议消息变得更容易。此截止点完全降至设备设计者并且根本未被HUCL定义或规定。
图10说明了组成HUCL的组件如何装配在一起。应该理解那些组件是记录在存储器中的软件组件。
如下部分更详细地讨论了形成HUCL软件栈32的各层以及它们提供的功能。
正如早先已经叙述了的，HUCL不依靠一个特定的传输协议(例如与TCP/IP不同)，而是相反直接位于传输栈34之上。不同的传输栈34本身将向应用程序提供不同服务并且是通过不同的API；HUCL传输适配层180充当特定传输层的一个缓存器。
传输适配层180向HUCL栈中的更高层提供一致的传输独立服务集(a consistent transport independent set of services)。此层的要求在协议规范中被详细地定义。
消息传送层182提供HUCL软件栈的大部份功能。应用程序通过HUCLAPI与此层通信并且当需要时(例如当数据被接收时)它将向应用程序执行回调。
消息传送层182还处理任何初始错误报告，并且必要时处理确认。用于检查丢失消息以及用于把消息与应答相耦合的消息ID和事务ID也完全由此层处理。
当一则消息需要被压缩或解压缩时消息传送层182还利用压缩/解压缩服务184。正如早先讨论的，一个应用程序专门处理压缩形式的消息，不向这些服务进行调用并且它们可以从运行时间栈中被移除。
压缩和解压缩服务只须向消息传送层提供在其压缩和解压缩形式之间转换HUCL消息的手段。系统的这个组件可在低端设备中缺省，其中与应用的所有数据交换以压缩消息进行。
应用程序编程接口API 186是这样一个接口，通过该接口，所有应用程序与HUCL软件栈通信。通信是双向的，因为作为在较低层中发生的特定事件(例如经由传输栈接收到的消息)的结果，HUCL栈将对应用程序进行异步回调。
HUCL是传输栈34独立的，并且这意味着HUCL消息协议可以建立于各种传输栈(有线与无线)的顶部。
由于HUCL被设计为一种简洁的协议，因此它也最适于诸如正在形成的Zigbee(802.15.4)标准之类的简洁传输栈，但是它也同样能够位于展开广泛的其他协议(有线(例如以太网)以及无线(例如802.11b))的TCP&UDP/IP之上。
对于将在一个传输栈34上实现的一个HUCL，必须有可能向HUCL栈的消息传送层提供大量服务。这意味着这些服务能够存在于传输栈本身中或者必须有可能在HUCL栈的传输抽象层中实现任何缺失的服务。这些服务可以覆盖诸如寻址、消息传送与设备发现(例如发现在网络上的其它设备的地址)之类的各方面。
协议本身是记录在介质214上的一个文档，包括如图11所示的下列信息一种通用HUCL消息格式200，其定义所有HUCL消息所符合的格式；消息定义202，它定义形成控制协议的特定消息；消息定序要求204，它规定何时哪些消息被发送，以及应用程序对接收一则消息的要求；HUCL API定义206，它定义HUCL和使用它的应用程序之间的双向接口；HUCL软件栈的消息传送系统要求和功能208；一个压缩算法210，它定义HUCL消息的压缩机制；和一个传输适配层定义212，它定义HUCL软件栈如何被连接到传输系统(例如一个RF栈)。HUCL因此不只是一个消息格式定义而且还封装一个消息互换和压缩。上面列表中的后四项形成将存在于设备中的HUCL软件栈，头三项定义所述栈和应用程序必须符合的要求。
阅读本公开内容之后，其它变化和修改对本领域技术人员来说很显然。这些变化和修改可以涉及在网络的设计、制造和使用中早已已知的等效特征和其它特征，并且所述特征可以除了在此描述的特征之外或者代替在此描述的特征而被使用。虽然权利要求在此申请中已经被制定为特定的特征组合，但是应该理解公开内容的范围也包括在此明确或隐含公开的任何新颖特征或任何新颖的特征组合或者对其的任意推广，而不论它是否缓和与本发明所缓和的相同的任何或者所有技术问题。申请人因此提请注意在本申请的审查期间新的权利要求可以被制定为任何此类特征和/或此类特征的组合或者从中导出的其它应用的组合。
具体地说，在示例中所使用的特定子例程名可以很容易变化。控制设备的计算机程序被表示为记录在存储器14中，但是技术人员应该理解它可以被记录在许多其它类型的记录载体上，比如CD、软盘等等。
另外，应当指出灯配件和灯开关的一个非常简单的示例已在前面广泛描述。技术人员应该理解许多更复杂的控制情景也是可能的。
权利要求
1.一种包括如下数据的简单设备描述消息信号(230)一个设备类型(232)；一个指示发送设备是否具有可用扩展设备描述的字段(238)；和一个规定数目的附加字段(236)，其标识规定数目的附加状态设定；其中设备类型(232)是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外级别的附属设备类型。
2.根据权利要求1的简单设备描述消息是令牌压缩的XML的形式。
3.一种操作联网设备的操作方法，包括发送或接收(104)一个规定长度的简单设备描述消息(230)，所述简单设备描述消息具有从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示其它设备类型的一个设备类型值；设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别(68)，所述附属设备类型取决于基本设备类型(54)并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型(52)的任何另外的附属设备类型级别。
4.根据权利要求3的方法，还包括如下步骤确立(102)至少一个其它设备的地址；发送(104)一则请求简单设备描述的简单设备描述询问消息给所述其它设备或者一个或多个其它设备；从所述其它设备或多个其它设备中接收(106)简单设备描述消息。
5.根据权利要求3的方法，还包括发送(108)一则扩展设备描述询问消息给所述其它设备或多个其它设备中的一个，以向其它设备请求扩展设备描述；和从所述其它设备或者多个其它设备之一中接收(110)一则可变长度的扩展设备描述。
6.根据权利要求3的方法，其中联网设备是一个控制器设备(2)，它具有该控制器能够控制的一个设备类型列表(24)。
7.根据权利要求6的方法，还包括在可以由控制器控制的设备类型列表中，通过确定或者是所述其它设备的设备类型或者是所述其它设备的设备类型所取决于的更高级别设备类型的最低设备类型级别来确定控制器能够控制所述其它设备的程度。
8.根据权利要求7的方法，还包括从另一设备中接收(120)一则包括被请求设备类型值在内、用于请求控制器是否能够控制被请求设备类型的设备的控制器询问消息；和用一则包括表示设备类型列表中的、或者是被请求设备类型或者是被请求设备类型所取决于的更高级别设备类型的最低设备类型级别的设备类型值在内的控制器响应消息来进行响应(122)。
9.根据权利要求3的方法，包括从请求简单设备描述的另一设备接收一则简单设备描述询问消息；和向所述其它设备发送固定长度的简单设备描述消息(230)。
10.根据权利要求9的方法，其中设备类型分级结构中的预确定的最高级别元件还包括一个复合设备类型，并且联网设备是具有整数个其它设备的功能的复合设备类型，所述方法还包括通过发送一则包括表示设备作为复合设备的设备类型值(232)和作为其它设备数目(234)的整数子设备数在内的简单设备描述消息(230)来对接收到的简单设备描述询问消息进行响应。
11.一个系统，包括多个联网设备(200)，每个联网设备具有一个用于发送和接收网络消息的收发信机(8)，该联网消息包括标识联网设备的设备类型的设备描述消息；其中每个联网设备具有一个预确定设备类型，该预确定设备类型是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别(68)，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别；至少一个联网设备是一个具有控制器设备类型(52)的控制器设备(2)；和至少一个联网设备是一个受控设备(4)，它具有基本设备类型(54)的设备类型或者取决于基本设备类型(54)的设备类型(62，64，66)。
12.根据权利要求11的系统，其中多个联网设备包括至少一个简单设备和至少一个复杂设备，其中简单设备没有能力对消息进行解压缩而直接解译已压缩的简单设备描述询问消息，而复杂设备包括一个用于对消息进行解压缩的消息解压缩设备(184)以及一个用于解译解压缩消息的消息解译器。
13.根据权利要求11或12的系统，其中预确定的最高级别元件还包括一个复合设备类型；所述系统包括复合设备类型的至少一个联网设备，它具有预确定数目的其它设备的功能，所述预确定数目是一个大于等于2的整数；和复合设备类型的该至少一个联网设备的每一个通过发送一则包括作为复合设备的设备类型(230)和表示预确定数目的其它设备的一个子设备数目(234)在内的简单设备描述(230)来对要求简单设备描述的一则输入设备询问消息进行响应。
14.一个联网设备，包括一个收发信机(8)，用于发送和接收消息；和一个消息处理器(26，182)，它被安排来发送或接收规定长度的简单设备描述消息，该简单设备描述消息具有从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示其它设备类型的一个设备类型值；该设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别(68)，所述附属设备类型取决于基本设备类型(54)并继承了该附属设备类型所依赖的高层设备类型的属性，但是该分级结构不包括取决于控制器设备类型(52)的任何另外的附属设备类型级别。
15.根据权利要求14的联网设备，其中，消息处理器被安排来执行如下步骤确立(102)至少一个其它设备的地址；向另一设备发送(104)一则请求简单设备描述的简单设备描述询问消息；从该其它设备中接收(106)固定长度的简单设备描述消息，所述简单设备描述消息包括表示该其它设备的类型的设备类型值和一个表示扩展设备描述是否可用的字段；并且所述消息处理器还被安排来可选地执行如下步骤测试简单设备描述消息以便确定扩展设备描述是否可用；发送(108)一则扩展设备描述询问消息给该其它设备，以向该其它设备请求扩展设备描述；和从所述其它设备中接收(110)一个可变长度的扩展设备描述。
16.根据权利要求14的联网设备，其中，消息处理器(26，182)被安排来执行如下步骤从请求简单设备描述的另一设备接收一则简单设备描述询问消息；和向该其它设备发送固定长度的简单设备描述消息，所述简单设备描述消息具有从人类可读的消息格式压缩的一种令牌压缩消息的形式。
17.根据权利要求16的联网设备，还包括一个存储器(14)，它储存一则从人类可读格式预压缩的预确定简单设备描述消息，其中消息处理器被安排来从存储器中读取该预确定简单设备描述消息并响应于一则输入设备询问消息通过收发信机对其进行发送。
18.根据权利要求17的联网设备，其中联网设备是一个控制器设备(2)，它包括一个存储器(14)，存储器(14)包含能够由该控制器控制的设备类型列表，用于通过确定能由所述联网设备控制的设备类型列表中的或者是已知设备类型或者是已知设备类型所取决于的更高级别设备类型的最低设备类型级别来确定联网设备能够把已知设备类型的另一设备控制到的程度。
19.根据权利要求18的联网设备，其中消息处理器被安排来从另一设备接收一则包括被请求设备类型值在内的、用于请求控制器是否能够控制被请求设备类型的设备的控制器询问消息；和用一则包括表示设备类型列表中的或者是被请求设备类型或者是被请求设备类型所取决于的更高级别设备类型的最低设备类型级别的设备类型值在内的控制器响应消息来进行响应。
20.规定一个设备类型分级结构的计算机程序，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别(68)，所述附属设备类型取决于基本设备类型(54)并且继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型(52)的任何另外的附属设备类型级别，所述计算机程序被安排来使联网设备(2，4)发送和/或接收包括从该设备类型分级结构中选择的设备类型的简单设备描述消息(230)。
21.根据权利要求20的计算机程序，用于控制控制器类型的联网设备，所述联网设备具有一个传输栈和一个应用程序，所述计算机程序包括实现用于与传输栈连接的传输适配层(180)的代码；实现用于与应用程序连接的应用程序编程接口(186)的代码；和实现一个消息传送层(182)的代码，消息传送层包括发送和接收令牌编码的人类可读消息传送格式的消息的能力，所述代码被安排来导致该联网设备识别要求简单设备描述响应的输入设备询问消息并且提供一个包括控制器设备类型的设备类型在内的简单设备描述响应；通过用能够由所述联网设备控制的设备类型列表中的或者是预确定设备类型或是预确定设备类型所取决于的更高级别设备类型的最低设备类型级别进行响应来响应一则询问所述联网设备是否能够控制一个预确定设备类型的输入控制器询问消息；以及执行下列步骤发送一则设备询问消息给另一设备；接收来自其它设备的指示该其它设备的设备类型的一则响应，该设备类型是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别；在可以由所述联网设备控制的设备类型列表中，通过确定或者是该其它设备的设备类型或者是该其它设备的设备类型所取决于的更高级别设备类型的最低设备类型级别来确定所述联网设备能够控制该其它设备的程度；和通过发送从属于所确定的最低设备类型级别的控制信号列表中选择的控制信号来用所确定的最低设备类型级别的功能来控制该其它设备。
22.被安排来使一个联网设备执行权利要求3到10的任何一个的方法的计算机程序。
全文摘要
本发明涉及一种用于在联网设备之间通信的协议。这些设备逻辑上被安排为设备类型分级结构，其包括没有其它设备类型所取决于的控制器设备类型(52)和许多其它设备类型所取决于的一个基本设备类型(54)。这些设备实现固定长度和格式的包括设备类型的简单设备描述消息，并且一些设备还实现包括附加信息的扩展设备描述消息。
文档编号H04L29/06GK1675887SQ03818858
公开日2005年9月28日 申请日期2003年7月24日 优先权日2002年8月6日
发明者R·J·布拉克维尔, N·A·汉金, P·J·拉尼甘, N·B·谢菲尔德, P·A·鲁兰德 申请人:皇家飞利浦电子股份有限公司