igBee桥的其他ZigBee设备生成的消息。
[0037]日志管理。例如出于维护目的，ZigBee桥ZBR维护活动、异常和事件日志。
[0038]用于网络管理系统的API。在MDY网络中存在的所有设备可以经由网络管理接口被管理。与NMS的任何交互经由在每个设备上的一组暴露的API而被实现。
[0039]本地设备配置。例如在ZigBee桥ZBR并且需要对其进行更换的情况下，该接口允许现场工程师在将其置于网络中之前配置新的设备。
[0040]RF设备列表管理。ZigBee桥维护其连接到的设备的列表，并且这些设备处于ZigBee桥的RF范围内。这有助于避免位于两个或更多ZigBee桥的RF范围内的ZigBee设备由所有的这些寻址。
[0041 ]如GB1411267.6中公开的MDU高层解决方案提供了待被智能能源设备以及被能源供应商通过外部WAN接口使用的通信基础设施。该方案向布置在建筑物中的所有ZigBee智能能源(ZSE)设备和ZigBee家庭自动化(ZHA)设备提供了它们需要通信到的设备在其自身的RF范围以内的假象，但它们实际上在RF范围以外。RF范围在IP主干上被延伸，这包括但不限于使用在建筑物以内的现有电力线。IP主干的接口是通过IP接口设备或网关的，但从IP接口设备到ZSE和/或ZHA设备的接口经由ZigBee桥ZBR而被实现。
[0042]ZigBee桥的一个职责是提供ZigBee消息可以通过其在IP主干与ZigBee RF之间传送的接口。图4中的示例性流程图示出了ZigBee分组如何包装有IP并在IP接口上被发送以及IP包装的ZigBee消息如何从IP接口被接收。
[0043]该过程在步骤301处开始。在步骤302中，ZigBee桥ZBR在上电之后激活其ZigBee和IP接口。在步骤303中，ZigBee桥ZBR从ZigBee接口接收ZigBee分组。在步骤304中，ZigBee桥ZBR从接收到的ZigBee分组读取IEEE 802.15.4头部。
[0044]随后，在步骤305中，ZigBee桥检查包括在IEEE 802.15.4头部中的源地址。假设ZigBee桥已经存储了支持的ZigBee设备的白名单列表，其根据该列表检查该源地址是否是有效的地址。如果其不是这样的情况(“否”)，故ZigBee桥并不支持已经从其接收到分组的该ZigBee设备，则在步骤306中丢弃该分组并且该过程在步骤307停止。附加地或可替代地，ZigBee桥也可以检查包括在头部中的目的地地址以根据该列表确定目的地地址是否是有效的地址。
[0045]如果根据该白名单列表，包括在接收到的分组中的该源地址是有效的地址(“是”)，那么ZigBee桥生成IEEE 802.15.4MAC层ack(确认)并在ZigBee接口上向源ZigBee设备传送(步骤316)。在步骤317中，ZigBee桥使用BCC的IP地址作为目的地地址、包装接收到的ZigBee分组以带有IP头部。其随后向其IP接口发送消息。在步骤318中，ZigBee桥将IP包装的Z i gBe e分组经由其IP接口传到BPL路由器。在步骤319中，包装的分组由路由器在宽带电力线(BPL)通信主干网络上被发送到建筑物控制中心BCC。因为BCC以及所有的BPL设备是相同的局域网(LAN)中的部分，基于BCC的目的地IP地址，包装的分组到达BCC。在步骤320中，BCC从接收到的包装的分组移除IP头部并且读取IEEE 802.15.4头部来确定原始分组旨在被发往的ZigBee设备的目的地地址。
[0046]在步骤321中，BCC检查目的地ZigBee设备的IP地址是够在所有ZigBee桥的白名单列表中。附加地，BCC也可以检查个人区域网络标识符(PAN ID)是否包括在白名单列表中。如果目的地ZigBee设备不能在任何的清单中被找到(“否”)，那么在步骤322中BCC丢弃接收到的分组并且提起异常，因为该分组已经在步骤316由接收ZigBee桥被MAC确认。该过程随后终止在步骤323。
[0047]取而代之的是，如果BCC发现目的地ZigBee设备的IP地址在白名单列表中(“是”)，其在步骤332中确定处于目的地ZigBee设备的RF范围内的ZigBee桥的IP地址。BCC随后包装接收到的ZigBee分组以带有IP头部，并且将ZigBee桥的IP地址作为目的地IP地址。在步骤333中，包装的ZigBee分组经由BPL主干网络和关联的路由器而由寻址的目的地ZigBee桥的IP接口接收。在步骤334中，目的地ZigBee桥解包该接收到的包装的ZigBee分组并且从包括在ZigBee分组中的IEEE 802.15.4头部确认目的地ZigBee设备IP地址。ZigBee分组随后经由ZigBee桥的ZigBee接口被发送到目的地ZigBee设备(步骤335)。在步骤336中，目的地ZigBee设备生成对目的地ZigBee桥的MAC层确认。如果该确认并未在目的地ZigBee桥处被接收到，ZigBee桥再次发送该分组。若在最大数量的传送之后来自目的地ZigBee设备的MAC确认并未在ZigBee桥处被接收到，那么提起异常并且丢弃该分组。该过程随后再次终止在步骤323。
[0048]ZigBee桥的另一职责是为在其RF范围内的所有授权的ZigBee设备提供MAC层确认。图5中的示例性流程图示出了 ZigBee桥在该处发出MAC确认的实例。
[0049]由IEEE 802.15.4标准定义的MAC确认超时接近864微秒。在GB1411267.6中提出的系统中并且特别是在大型MDU中，如果MAC确认要由远程目的地ZigBee设备发出，发送这样的确认的期间将很可能经常超出定义的超时期间。这继而增加基于IP的主干通信网络中的ZigBee分组的重新传送数。为了减少这样的传送数，针对ZigBee桥提出了首先从源ZigBee设备接收分组以生成MAC层确认。然而，对于应用层确认，提出的系统设置允许充分周转时间用于ZigBee分组到达其目的地ZigBee设备，以及用于源ZigBee设备从目的地ZigBee设备接收应用层确认。
[0050]图5的过程在步骤401处开始。在步骤402中，在上电之后，ZigBee桥激活其ZigBee和IP接口。在步骤403中，ZigBee桥ZBR从ZigBee接口接收ZigBee分组。在步骤404中，ZigBee桥ZBR从接收到的ZigBee分组读取IEEE 802.15.4头部。
[0051 ] 随后，ZigBee桥ZBR检查包括在IEEE 802.15.4头部中的源地址(步骤405)。再次地，假设ZigBee桥已经存储了支持的ZigBee设备的白名单列表，其根据该列表检查该源地址是否是有效的地址。若其不是这样的情况(“否”)，即ZigBee桥并不支持已经从其接收到分组的该ZigBee设备，在步骤406中丢弃该分组并且该过程在步骤407停止。附加地或可替代地，ZigBee桥也可以检查包括在头部中的目的地地址以根据该列表确定目的地地址是否是有效的地址。步骤401至407可以与图4中的步骤301至307相同地实现。
[0052]如果根据该白名单列表，包括在接收到的分组中的该源地址是有效的地址(“是”)，那么ZigBee桥生成IEEE 802.15.4MAC层确认ack并在ZigBee接口上向源ZigBee设备传送(步骤416)。该MAC层确认在步骤417中由源ZigBee设备接收。随后，在已经接收到MAC确认之后，源ZigBee设备等待由目的地ZigBee设备发出的响应ZigBee分组。源ZigBee设备由此等待，直到如ZigBee协议桟定义的接收到的分组超时已经发生。
[0053]在步骤419中，源ZigBee设备检查分组响应超时是否已经发生。如果其不是这样的情况(“否”)，该过程被停止(步骤422)。取而代之的是如果超时已经发生(“是”)，源ZigBee设备在步骤420检查这是否已经发生连续的η次(步骤420)，其中η由ZigBee协议桟定义。如果该超时实际上已经发生连续的η次(“是”)，该过程再次在步骤422中停止。如果该超时尚未发生连续的η次(“否”)，源ZigBee设备在步骤421中向ZigBee桥重新发送相同的ZigBee分组，并且该过程在步骤402处再次开始。
[0054]ZigBee桥的进一步的职责是为等待被发送到睡眠ZigBee设备的消息提供存储机构，该睡眠设备即处于睡眠模式并且因而不能接收新消息的ZigBee设备，其中ZigBee桥可以支持睡眠以及非睡眠的ZigBee设备。取决于处于其RF范围内的ZigBee设备的类型，ZigBee桥或者为设备存储到达消息并且等待该设备醒来并收集所存储的消息，或者其直接向该设备递送消息。
[0055]ZigBee桥的职责也是支持所谓的白名单列表。这是个人区域网络(PAN)的标识符PAN ID和与特定ZigBee桥关联的ZigBee设备(即针对其ZigBee桥将在IP主干网络上转发消息并且经由已经从其他ZigBee桥或ZigBee设备接收到的其ZigBee接口传送消息到的设备)的地址的列表。
[0056]这样的白名单列表的示例性格式在图6中示出。该白名单列表保持ZigBee设备的EUID(扩展的唯一标识符)以及它们的PAN ID，对于这些设备应当在IP主干网络上转发消息。ZigBee设备的标识符可以是源和/或目的地ZigBee设备的那些。该白名单列表有助于ZigBee桥仅针对需要消息在IP上被发送的ZigBee设备而接受ZigBee消息，因而避免用来自位置ZigBee设备的ZigBee消息(即来自对ZigBee桥未知的ZigBee设备的消息)洪泛I