CN100525223C - 网络建立和管理协议 - Google Patents

Abstract

本发明涉及一种用于在联网设备之间通信的协议。这些设备逻辑上被安排为设备类型分级结构，其包括：没有其它设备类型所取决于的控制器设备类型(52)和许多其它设备类型所取决于的一个基本设备类型(54)。这些设备实现固定长度和格式的包括设备类型的简单设备描述消息，并且一些设备还实现包括附加信息的扩展设备描述消息。

Description

网络建立和管理协议

技术领域

本发明涉及一种网络协议，具体地说涉及协议的实施方式。

背景技术

一种现有技术的网络管理协议是通用即插即用(UPnP)，它对于带宽、电池消耗以及一定程度内的成本都不是问题的互联网应用非常有用。协议在消费类电子学(CE)中的实施方式确实存在，但是由于协议的范围，此类实施方式特别是对在其它情况下可能只需要极小处理能力的最简单的设备施加沉重的负荷。

因此，需要一种适于嵌入诸如灯、自动调温器和CE装置(电视、DVD以及PVR的遥控装置)之类简单设备中的协议，其实现起来简单并且成本有效、需要最小带宽、并且在具有不同性能的设备范围上还是可升级的。

此要求不限制为无线应用，而是可延伸到有线应用。

发明内容

根据本发明的第一方面，提供一种系统，包括：多个联网设备，每个联网设备具有一个用于发送和接收网络消息的收发信机；至少一个联网设备，被安排来发送一则简单设备询问消息给其它设备并接收及解译随后从其它设备中接收到的简单设备描述消息；至少一个联网设备，被安排来发送一个扩展设备询问消息给其它设备并接收和解译随后从其它设备中接收到的扩展设备描述消息；每一联网设备被安排来通过发送一则规定长度的简单设备描述消息来响应来自另一设备的一则输入简单设备询问消息，其中规定长度的简单设备描述消息包括表示设备类型的一个设备类型值；和至少一个联网设备，被安排来通过发送一则扩展设备描述消息来响应来自另一设备的一则输入扩展设备询问消息。

这样一个系统实现了作为此专利申请的主题的协议。该协议本身将被称为归属统一控制语言(HUCL)。

比较起来，发明者所知道的那些现有技术系统只实现单一设备描述消息和响应。通过提供一则规定长度的简单设备描述和一则可变长度的扩展设备描述，本发明使得能够使用HUCL协议来组合只使用简单消息操作的简单设备和使用可以从可变长度的扩展设备描述中获得的更强大功能的复杂设备。简单设备可以简单地忽略扩展的设备描述询问。

简单设备描述包括较少数目或者中等数目的预确定字段，每个字段有固定长度。总的来说，虽然可以有一些变化，但是相同的字段将被用于每个消息。例如，一个复合设备可以包括一个附加整数字段，如下面将描述的那样它包括子设备的数目。

优选地，简单设备描述消息具有从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示该其它设备的类型的设备类型值；设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。

根据HUCL协议的优选实施方式，底层消息格式是诸如XML之类的人类可读格式。可是，为了节省带宽，以压缩的形式在联网设备之间传送信息。然而，因为所使用的压缩方法是令牌压缩(它用令牌替换了公共的串)，所以联网设备仍能够处理此类压缩消息。联网设备因此能够识别已压缩令牌而不必解压缩，至少足以识别一个要求简单设备描述响应的询问，并且然后用一个简单设备描述来响应。因此，能够用很少的开销实现联网设备。

一个适当形式的令牌编码在1999年6月24日的“wap binary XMLcontent format(wap二进制XML内容格式)”中被描述，在撰写本申请时，该文可在http://www.w3.org/TR/wbxml处得到。

应当指出：虽然优选地有取决于基本设备类型的至少一个分级结构(即受控设备的分级结构)，但是却没有相应的控制器设备分级结构。这是为了保持简单设备描述消息尽可能短且简单，诸如通用遥控装置之类的许多控制器能够控制许多不同的设备类型。

优选地，该多个联网设备包括至少一个简单设备以及至少一个复杂设备，其中简单设备没有能力对消息进行解压缩并因此直接解译已压缩消息，而复杂设备包括一个用于对消息进行解压缩的消息解压缩安排以及一个用于解译解压缩消息的消息解译器。

在另一方面，本发明涉及一种能够对简单的和扩展的设备描述询问消息进行响应的一个单独的联网设备。

因此，在第二方面，提供一种联网设备，包括：

用于发送和接收消息的收发信机；和

被安排来执行如下步骤的消息处理器：

在从其它设备之一中接收到简单设备描述询问消息时，向该其它设备发送一则规定长度的简单设备描述消息，所述规定长度的简单设备描述消息包括表示联网设备类型的一个设备类型值；和

在接收到来自另一设备的扩展设备描述询问消息时，向该另一设备发送一则可变长度的扩展设备描述。

除了能够响应此类设备询问消息的联网设备，本发明还涉及生成设备询问消息和对结果进行处理的设备。

因此，在第三方面，提供一个联网设备，包括：用于发送和接收消息的收发信机；

被安排来执行如下步骤的信息处理器：

确立至少一个其它设备的地址；

向请求简单设备描述的另一设备发送一则简单设备描述询问消息；

从其它设备中接收固定长度的简单设备描述消息，所述固定长度的简单设备描述消息包括表示该其它设备的类型的设备类型值和一个表示扩展设备描述是否可用的字段；

并且所述信息处理器还被安排来可选地执行如下步骤：

测试该简单设备描述消息以便确定扩展设备描述是否可用；

发送一则扩展设备描述询问消息给向其它设备以请求来自该其它设备的扩展设备描述；和

从所述其它设备中接收一个可变长度的扩展设备描述。

本发明还涉及第二和第三方面的设备的操作方法。

因此，在第四方面，本发明涉及联网设备的操作方法，包括：向其它设备之一发送一则请求简单设备描述的简单设备描述询问消息；从其它设备中接收规定长度的简单设备描述消息，所述简单设备描述消息包括表示该其它设备的类型的设备类型值和一个表示扩展设备描述是否可用的字段；测试该简单设备描述消息以便确定扩展设备描述是否可用，如果可用，则发送一则扩展设备描述询问消息给向该其它设备以从该其它设备请求扩展设备描述；和从所述其它设备中接收一个可变长度的扩展设备描述。

在第五方面，本发明涉及一个联网设备的操作方法，包括：

从其它设备之一接收一则请求简单设备描述的简单设备描述询问消息；

给该其它设备发送一则规定长度的简单设备描述消息，所述简单设备描述消息包括表示联网设备类型的设备类型值；

从向联网设备请求扩展设备描述的该其它设备中接收一则扩展设备描述询问消息；和

向该其它设备发送一个可变长度的扩展设备描述。

正如前面提到的那样，设备类型值可以从一个设备类型分级结构中选择，该分级结构具有包括控制器设备类型和基本设备类型在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别的设备类型，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。

根据本发明的控制器设备优选地包括一个控制输入，并且基于在控制输入上接收到的信号来控制其它设备。另外，控制器设备可以实现一个或多个确定控制器能够控制什么设备的确定方法。

在设备是控制器设备类型时，一种处理信息缺乏的方法是让控制器设备具有如下功能，即通过利用能够由联网设备控制的设备类型列表中的最低设备类型(其或者是预确定设备类型或者是预确定设备类型所取决于的较高级别的设备类型)级别进行响应，来响应一则询问控制器是否能够控制一个预确定设备类型的输入控制器询问消息。控制器设备随后能根据在控制输入上接收到的信号来把从控制信号的预确定列表中选择的控制信号发送给其它设备。

替代控制器设备，所述设备可以是一个受控设备，它具有基本设备类型的设备类型或者取决于基本设备类型的设备类型；联网设备具有对控制器发送的基本设备指令进行响应的能力，所述指令至少包括一个预确定指令基本集。

为了应付多功能设备，预确定最高级别元件可以包括具有预确定数目的其它设备类型的功能的复合设备类型，并且被安排来通过发送包括作为复合设备的设备类型和其它设备类型的瞬时数目在内的一则简单设备描述来对一则要求简单设备描述的输入设备询问消息进行响应。

联网设备可以包括一个存储器，该存储器存储：预确定简单设备描述消息，其中描述消息是从包括设备类型在内的人类可读形式的消息中预先压缩的一则消息；一个指示发送设备是否具有可用扩展设备描述的标记；和一个预确定数目的附加标记，其标识预确定数目的附加状态设定。因此，当需要时预先储存并发送出一则适当的消息，而不是在内部生成一则简单设备描述消息。

本发明还涉及一种用于控制联网设备的计算机程序。

所述系统可以包括具有简单功能并且没有能力对消息进行解压缩的许多简单设备以及对消息进行解压缩以便解译它们并对它们进行操作的更为复杂的设备。更为复杂的设备可以具有复杂得多的功能，其代价是增加的开销以及处理器能力要求。

在另一方面，本发明涉及一种用于控制电子设备的网络建立和管理协议，所述协议被记录在记录媒体上，所述协议包括：定义对所述消息进行压缩的机制的一个压缩算法；通用消息格式的一个定义，所述消息是XML兼容的消息；和消息定序要求的一个定义。

所述协议可以规定控制器设备并且控制器设备的发现可以被规定为包括一个机制，用于发现控制设备并针对将来的操作对所述控制设备进行指示。

所述协议还可以将设备描述消息规定成是固定长度和内容的第一消息和未规定长度和内容的第二消息二者之一。

所述协议可以规定设备描述消息的发现以便允许逐渐发现第二设备描述消息。

所述协议可以规定复合设备并且复合设备的设备描述消息被规定成包括复合体中的子设备数目。

复合设备的设备描述消息的发现可以被规定成又允许子设备的发现。

附图说明

为了更好地理解本发明，现在将纯粹以举例的方式参考附图来描述实施例，附图中：

图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软件栈执行首先请求已知设备数目然后请求那些设备的网络地址的调用，发现过程由控制应用程序开始(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&subCatld＝DVDPLAYER。

在HUCL中克服这一点的方法是：设备描述被分裂为两列(tier)信息。第一列是一个简单化的、但是标识另外信息是否可用的设备描述。它不包含任何自由文本字段，因此它的全长是确定的。第二列扩展信息是可选的，但是提供附加信息。

参见图12，简单设备描述消息230包括设备类型字段232、指示扩展设备描述是否可用的字段238以及标识关键信息的其它字段236，其中关键信息例如是一个指示事件预订是否可用的标记。可选的整数字段234表示复合设备的子设备数目。技术人员应该理解：消息230也可以包括为了简洁而被省略的报头和页脚。消息将包括为了清楚也同样被被省略了的压缩的XML令牌。简单设备描述的字段都是固定长度的，因此它们能够很容易被处理而不必解压缩。

在接收(106)(图3)简单设备描述230之后，简单设备描述230被传送回HUCL栈。

如果扩展设备描述可用并且控制器设备要求它时，则控制器设备控制应用程序可以发回一个“GetExtendedDescription(获得扩展描述)”请求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(图12)标识分级结构内的设备并因此即使新的设备被创建，只要它是从分级结构内的一个适当点所导出，则简单的开关将仍然知道它能够在一定程度上控制它。

在树中落得较低的设备继承了它上面的设备类型的功能。当命令被应用到树中的较低设备时，可能需要向那些命令附加某些解释，例如打开/关闭命令在被发送给一盏灯时将很显然把它打开/关闭，但是同一命令在被发送给电视时将把它置于或令它退出待机状态。

设备类型分级结构的关键益处是：即使控制器不了解特定设备类型本身，它也能确定从中导出该特定设备类型的那个设备，它可能具有对于所确定的设备的某些标识，并因此也许能在某个较小的程度上(从所述特定设备的角度看)控制该特定设备。

例如，设想这样一个情况：一个灯开关获得一个设备的地址，它向此设备请求简单设备描述；设备类型字段把该设备标识为电视，但是开关不把这识别为它知道的一个设备。可是，该开关还可以从该描述中确定该设备是它所知道的‘基本设备’的一个衍生物。最终的结果是：尽管关于设备本身根本一无所知，开关也能够在控制器能力范围内控制电视，即开和关。该设备可以是在开关制造出来很久以后发明的被称为‘XYZ’的一个全新设备类别，但是只要它从一个基本设备中导出，则该开关仍然能够在一定程度上控制它。

虽然设备类型分级结构可以只有两列，控制器和基本设备最高级别元件，但是至少另外一列和/或最高级别元件是所希望的。这迎合了不遵守基本设备中的如上所示的功能的那些设备，即不具有基本‘打开’、‘关闭’功能的设备，例如告警。为了说明的目的，一个‘告警’类型设备56已如图4所示，并且可以理解，此‘告警’设备不想实现从基本设备中导出的设备所必须具有的正常的打开/关闭功能；因此它在分级结构中位于与基本设备54本身相同的最高级别58。

对分级结构的第二个扩展也如图4所示，即：常规电视设备64下面的增强型电视设备66。在这里，增强型电视设备继承了基本设备54和电视设备64二者的所有功能，而且包括在常规电视中不存在的一些扩展功能。被设计来操作常规电视设备的常规电视遥控装置可以把增强型电视设备操作到常规电视设备功能的级别，但是不能控制扩展功能。

HUCL协议因此提供一种用于描述设备类型及从中继承功能的、处在其上的可扩展机制。虽然多层分级结构的思想看起来可能是吸引人的，可是把它扩展超过三或四级将开始对简单设备描述的大小发生影响。

在HUCL内，可向控制器以及可控设备请求一个设备描述。当一个设备发送“获得简单描述”给一个控制器设备(例如一个开关)时，它被返回一个包含“控制器”设备类型的简单设备描述。控制器设备还可以使得扩展设备描述可用，所述扩展设备描述提供诸如生产商、型号等等之类另外的信息。

重要的是要注意：由控制器设备返回的设备类型只是“控制器”52，没有在设备类型树中定义不同控制器类型设备的分级结构。这样做的原因同样是试图保持协议和消息大小小而简单。可以感觉到：从诸如开关、电视遥控装置、PVR遥控装置等等之类的基本控制器中导出不同的控制器类型将是可能的。可是，对于诸如能够控制一个较宽设备范围的通用遥控装置之类的智能控制器将出现问题。为了在一个简单设备描述中包括所有可能的控制器类型将导致一个可能较大的消息，这违反了试图使初始简单设备描述简单的理想。为了确定一个控制器设备的准确能力，使用不同的机制。

确定控制器设备性能的第一个手段是借助在控制器设备上允许的扩展设备描述，并且该扩展设备描述可以包括诸如设备名(例如“通用遥控装置”)之类的信息，并且虽然这是文本信息且不是可由应用软件直接解译的，可是它可以被呈递给用户以帮助做出有关控制器的有信息根据的选择。

一个设备确定有关控制器的更多信息的第二个手段是对其进行询问。

询问的使用是一种对设备信息进行滴馈(drip-feeding)的强大机制，如果所述信息被一同提供，则将使请求者过载。

控制器类型的每个设备为其它设备提供一个装置，以便询问(120)它是否能够控制一个特定设备类型(图5)。在询问中传送的设备类型是与在设备类型分级结构中定义的简单设备描述中所使用的相同的字段。通过返回储存在控制器存储器14中的列表中的最低设备类型(即，在询问中传送的设备类型或者该设备类型所取决于的设备类型)，控制器返回(122)它能够将设备控制到的级别。例如，询问一个简单的开关它是否能够控制一个增强型电视设备。基于图4中说明的分级结构，应答是：它能够将其控制到基本设备的级别。该开关本身通常将对增强型电视设备的设备类型毫无所知，但是由于设备类型还包括所继承的设备，所以它能识别基本设备并且把这作为它能够控制的最低的、在分级结构中更高的设备类型而返回。

控制器还实现一个算法来确定开关是否能够控制在一则简单设备描述中返回给它的设备类型(图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、软盘等等。

另外，应当指出：灯配件和灯开关的一个非常简单的示例已在前面广泛描述。技术人员应该理解许多更复杂的控制情景也是可能的。

Claims (17)

1.一种在具有至少一个其它设备的网络中操作联网设备的方法，所述方法包括：

向至少一个其它设备发送(104)一则请求简单设备描述的简单设备描述询问消息；

从该其它设备中接收(106)规定长度的简单设备描述消息，所述简单设备描述消息包括表示该其它设备类型的设备类型值；

发送(108)一则扩展设备描述询问消息给该其它设备以向该其它设备请求扩展设备描述；和

从所述其它设备中接收(110)一个可变长度的扩展设备描述。

2.根据权利要求1的方法，还包括：在发送(104)一则简单设备描述给至少一个其它设备的步骤之前确立(102)所述至少一个其它设备的网络地址。

3.根据权利要求1或2的方法，其中：简单设备描述消息(230)具有从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示该其它设备类型的一个设备类型值(232)；设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级别元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。

4.根据权利要求3的方法，其中：联网设备是一个控制器设备(2)，它包括该控制器能够控制的一个设备类型列表(24)。

5.根据权利要求4的方法，所述方法还包括确定联网设备是否能够控制所述至少一个其它设备，这是通过：在可以由控制器控制的设备类型列表中，确定或者是该其它设备的设备类型或者是该其它设备的设备类型所取决于的更高级别设备类型的最低级别的设备类型，以便确定联网设备能够控制该所述至少一个其它设备的程度。

6.根据权利要求5的方法，还包括：

从所述其它设备之一中接收一则包括被请求设备类型值在内的控制器询问消息，以便请求控制器是否能够控制被请求设备类型的设备；和

用一则包括表示或者是被请求设备类型或者是被请求设备类型所取决于的更高级别设备类型的设备类型列表中的最低设备类型级别的设备类型值在内的控制器响应消息来进行响应。

7.根据权利要求2的方法，其中：设备类型分级结构中的预确定的最高级别元件还包括一个复合设备类型，并且联网设备是具有整数(234)个的子设备的功能的复合设备类型，所述方法还包括：

通过发送一则包括表示设备作为复合设备时的设备类型值(232)和表示子设备整数数目(234)的另一整数在内的简单设备描述消息(230)来对接收到的简单设备描述询问消息进行响应。

8.一种操作联网设备的操作方法，包括：

从请求简单设备描述的其它设备之一接收(104)一则简单设备描述询问消息；

向该其它设备发送(106)规定长度的简单设备描述消息，所述简单设备描述消息包括表示联网设备类型的设备类型值；

从向联网设备请求扩展设备描述的该其它设备中接收(108)一个扩展设备描述询问消息；和

给所述其它设备发送(110)一个可变长度的扩展设备描述。

9.一个联网设备，包括：

一个收发信机(8)，用于发送和接收消息：和

消息处理器(26，182)，被安排来执行如下步骤：

在从其它设备之一中接收(104)简单设备描述询问消息时，向从其接收所述简单设备描述询问消息的该其它设备发送一则规定长度的简单设备描述消息，所述规定长度的简单设备描述消息包括表示联网设备类型的一个设备类型值；和

在接收(108)来自所述其它设备之一的扩展设备描述询问消息时，向从其接收所述扩展设备描述询问消息的该其它设备发送(110)一个可变长度的扩展设备描述。

10.根据权利要求9的联网设备，其中：简单设备描述消息(230)具有从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示该其它设备类型的一个设备类型值(232)；设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。

11.一个联网设备，包括：

一个收发信机(8)，用于发送和接收消息：

消息处理器(26，182)，被安排来执行如下步骤：

向其它设备之一发送一则请求简单设备描述的简单设备描述询问消息；

从该其它设备中接收固定长度的简单设备描述消息，所述简单设备描述消息包括表示该其它设备之一的类型的设备类型值和一个表示扩展设备描述是否可用的字段；

并且该消息处理器还被安排来可选地执行如下步骤：

测试简单设备描述消息以便确定扩展设备描述是否可用；

发送一则扩展设备描述询问消息给该其它设备之一以从该其它设备请求扩展设备描述；和

从所述其它设备中接收一个可变长度的扩展设备描述。

12.根据权利要求11的联网设备，其中：简单设备描述消息(230)具有从人类可读的消息格式压缩的一种令牌压缩消息的形式，该消息包括表示该其它设备类型的一个设备类型值(232)；设备类型值是从一个设备类型分级结构中选择的，该分级结构具有包括控制器设备类型(52)和基本设备类型(54)在内的预确定的最高级元件以及至少一个另外的附属设备类型级别，所述附属设备类型取决于基本设备类型并继承了该附属设备类型所依赖的更高级别设备类型的属性，但是该分级结构不包括取决于控制器设备类型的任何另外的附属设备类型级别。

13.根据权利要求12的联网设备，其中：联网设备具有控制器设备类型，其中联网设备包括一个能够由该联网设备控制的设备类型列表，因此通过在能够由该控制器控制的设备类型的列表中确定或者是该其它设备的设备类型或者是该其它设备的设备类型所取决于的更高级别设备类型的最低级别的设备类型，则联网设备能够确定所述联网设备能够控制其它设备之一的程度。

14.根据权利要求13的联网设备，其中，信息处理器被安排来：

从所述其它设备之一接收一则包括被请求设备类型值在内的控制器询问消息，以便请求该控制器是否能够控制被请求设备类型值的设备；和

用一则包括表示设备类型列表中或者是被请求设备类型或者是被请求设备类型所取决于的更高级别设备类型的最低级别的设备类型的设备类型值在内的控制器响应消息来进行响应。

15.一个系统，包括：

多个联网设备，每个联网设备具有一个用于发送和接收网络消息的收发信机；

至少一个联网设备，被安排来发送一则简单设备询问消息给至少一个其它设备并接收并解译随后从其它设备中接收到的简单设备描述消息；

至少一个联网设备，被安排来发送一则扩展设备询问消息给所述至少一个其它设备并接收和解译随后从其它设备中接收到的扩展设备描述消息；

每一所述联网设备被安排来通过向从其接收所述简单设备描述询问消息的其它设备发送一则规定长度的简单设备描述消息来响应来自所述其它设备之一的一则输入简单设备询问消息，其中所述规定长度的简单设备描述消息包括表示该联网设备类型的一个设备类型值；和

至少一个所述联网设备被安排来通过向从其接收所述扩展设备描述询问消息的其它设备发送一则可变长度的扩展设备描述消息来响应来自所述其它设备之一的一则输入扩展设备询问消息。

16.根据权利要求15的系统，其中：该多个联网设备包括至少一个简单设备以及至少一个复杂设备，其中简单设备没有能力对消息进行解压缩并且直接解译已压缩消息，而复杂设备包括一个用于对消息进行解压缩的消息解压缩设备(184)以及一个用于解译解压缩消息的消息解译器。

17.根据权利要求15或16的系统，其中：设备具有从包括控制器设备类型(52)、基本设备类型(54)和复合设备类型的预确定的设备类型中选择的设备类型；

所述系统包括该复合设备类型的至少一个联网设备，其具有预确定数目的其它设备的功能，所述预确定数目是一个大于等于2的整数；和

该复合设备类型的该至少一个联网设备的每一个通过发送一则包括作为复合设备的设备类型(232)和表示预确定数目的其它设备的一个子设备数目(234)在内的简单设备描述(230)来对要求简单设备描述的一则设备询问消息进行响应。

Images