前言
在无线感测网络的技术领域中，与传统无线通信解决方案最大的区别，就在于无线网络的标准化。在传统的无线通信解决方案中，各家的产品缺乏共通标准，只能与自家的产品互动。不同产品之间产生的干扰问题也时有所闻。无线感测网络的标准化，以及认证制度的推行，使得厂商有一个可以依循的方向。只要依循此一标准设计制造的产品，便可以保证与不同厂商装置之间的兼容性。这种特性对于厂商而言，最直接的效益就是产品将不再受到无线信号本身的局限。
传统的无线通信解决方案，套接字与接收端必须维持在无线电信号范围内。而在无线感测网络技术领域，利用无线感测网络协议的多点传输特性，便可仅依靠低传输功率的通信装置，达到广域服务涵盖面积的目的。无线感测网络协议的标准化，更进一步扩展了无线感知网络的功能性：符合通信协议标准的装置，即可无障碍地利用一个已经建构完成的无线感测网络系统进行通信。
由于这样的特性，在无线感测网络的市场中自然衍生出两种不同特性的装置：不具备特定应用程序功能、但可用来架设无线感测网络骨干（Backbone）的装置，以及专门为了某些特定目的而开发的无线感测网络应用装置。
无线感测网络应用装置本身仅需具备通信协议的存取界面，需要的技术能力比较少。然而无线感测网络骨干装置则是需要考虑到现实世界实际布建的各种问题，同时需要考虑到各种多元化应用装置的扩充性，无轮在设计上、或是实际布建上，都会面临相当多的挑战。
本文将以ZigBee无线感测网络骨干装置为核心，介绍两种结合IP网络的ZigBee交换装置。两种装置各自有不同的系统，以及不同的适用情境。然而两种装置对于架设多元化的无线感测网络环境此一目标，皆有着相当重要的地位。
布建的常见问题
任何一种无线感知网络，都存在各式各样的限制。在一个环境受到控制的实验室中，我们可以很简单的建构出一个理想的网络，让网络完全按这我们想要的方式扩张，让封包按照我们想要的方式传送。然而，当我们进入现实世界，我们会受到各式各样的环境因素限制。在大多数的布建案中，想要完全依靠无线技术来建构一个能够传递数据的感知网络，是一件极端困难的挑战。
在现实世界中基本布建的规则是：节点的无线信号范围必须能够互相涵盖。这项要求在开放空间或许很容易达成，但是在复杂空间中，往往会产生各种意料之外的问题。布建在室内空间的ZigBee网络，除非是在建筑物建造或装潢的时候就嵌入成为建材的一部份，否则必然是等装潢完成后才进驻布建。
ZigBee的无线信号可以穿越木板、玻璃、石膏板、砖墙、水泥装饰墙等装潢隔间材质，但是无法穿越内含钢骨的结构墙、金属门、金属隔间柜等厚重物体，因此网络联机必定会受到建筑结构的限制。举例来说，房间与房间之间可能受到结构墙阻隔无法直接通信，必须在房门口附近装设一个中继节点；楼层与楼层之间可能会因为加重承载结构无法直接通信，需要由外墙、阳台、天井、楼梯井等地方架设数个中继节点。这些问题通常会导致两种常见的问题：网络传输路径过长导致延迟过高，或是造成一个特别繁忙的瓶颈节点。
对于这些现实布建物理限制所造成的问题，最有效率的解决方案就是将网络拆分成数个较小的区块。每一个区块可以被视为是一个小型的独立网络，因此在这些区块中，比较容易形成“平衡的”网络拓璞。每一个独立区块可以被视作为一个丛集（Cluster）。每个丛集会设置一个主要的控制节点，用来作为丛集数据的统一出入口。利用这种方式，可以比较有效率的达成流量分散、降低干扰等功用。然而丛集控制点的设计，变成很重要的关键。在某些应用情境中，会将依靠异质网络来作为丛集控制点与丛集控制点之间数据传输的信道，亦即丛集控制点本身即是扮演一个网桥（Bridge）装置的功用。
有相当多的实际应用案例采用这种方式布建。低成本布建的解决方案通常会使用一些现成的转换装置，例如RS232-to-Ethernet的转接器，后端则是连接普通IP网络。这样的解决方案相当有效率，然而这种解决方案通常伴随着潜在问题。这种类型的布建方式，桥接装置几乎毫无例外的采用应用层级的方式来实作封包转发功能。由于通信协议天生的封装与解封装（Capsulation & De-capsulation）性质，应用层级只能取得封装的内容（Payload），无法取得封装的标头（Header）。因此应用层级的封包转发网桥，只能依靠封装内容来作为转发判断的依据。要做到这一点，封装内容必须有一定的格式要求；换句话说，就是缺乏共通性与兼容性。
在实际的布建案例中，采用RS232-to-Ethernet转接器的低成本布建解决方案，几乎都是为了单一用途而建构。在这种网络中如果想要增加新的功能，是非常困难的事。在不变更原有节点的前提下，几乎不可能容纳另外一个不同厂商的系统。
兼容性的极限
通信协议确保的是数据传输与转发的兼容性，而不是数据本身的兼容性。以应用程序的层级来说，除非应用程序本身也依循某些标准规范，例如X.10自动控制，否则不同厂商生产的装置，几乎不可能兼容。
这一点对于生产终端设备的厂商来说，可能反而是一种求之不得的垄断优势：任何购买Ａ公司的控制器的使用者，只能回过头来购买Ａ公司生产的设备；因为Ａ公司的控制器，无法控制Ｂ公司的设备。从设备业者或是工程师的角度思考，这是很合情合理的结果；但是对于一个只是想要整合不同解决方案的使用者来说，这种缺乏兼容的特性就显得荒谬而可笑。
试想一个情境：在一个会议室中，先要寻找控制器Ａ来启动空调设备，然后寻找控制器Ｂ来放下窗帘与投影屏幕，然后寻找控制器Ｃ来启动投影机，最后再拿一开始用过的控制Ａ来关闭灯光。这样的情境不只让人不耐，更会让人产生一种“无线感测网络并没有带来多少便利性”的负面印象。
将控制界面用个人计算机应用程序的方式制作，看似一个可行的解决方案：至少你可以在一台计算机前控制所有东西，而不需要去找一大堆控制器。但是以目前现行的众多实作，这种做法也只是换汤不换药。
采用这种解决方案的厂商，会提供你一个安装软件，以及一个硬件插件（Dangle），同时会指示你用RS232或是USB联机把这个硬件插件连接到计算机上，然后执行控制程序。问题是：控制程序只认得特定的硬件插件，于是Ａ公司控制程序无法控制Ｂ公司硬件插件的老戏码再次上演。各位可以试着想象另外一个情境：一个工程师捧着一台Notebook计算机站在会议室一角，Notebook后面接了一个USB Hub，然后Hub上插满了各种形状、颜色、大小都不同的硬件插件。
相信不用我说各位也晓得：这样看起来真的很蠢。
标准化的解决方案
在上述各种问题重重的解决方案中，核心的问题其实只有一个：缺乏标准。其实针对这两个主要的议题，异质网络整合以及图形使用界面，早已有标准存在，只是比较鲜为人知。
ZigBee标准组织在 2005 年底，正式把整合异质网络来克服各种实际布建问题的概念纳入 ZigBee通信协议的发展蓝图之中。Gateway Workgroup（GWG）是目前负责制定相关应用规格的组织，日前该组织公布了一份新的标准：ZigBee Bridge。
ZigBee Bridge与传统依靠应用层级来进行封包桥接的做法不同，ZigBee Bridge在第二层 Data-link层进行分组交换。这样的特向可以让一个ZigBee Bridge完全不需要依靠用户自动的应用程序，便可以交换所有类型的封包。因此ZigBee Bridge可以视作是一个单纯的“路由器”。ZigBee Bridge的系统架构相当直观；一个新的分组交换层介于网络层以及MAC层之间，原始数据在这一层进行交换，上层的通信协议不需要任何修改便可正常工作。
ZigBee Bridge最早的构想，是使用IP网络来连接一个PAN里面的两个节点，藉此制造一个封包的“虫洞”；可以用来缩短封包路由的路径，或是用来连接两个被空间隔离的网络。但是开发人员很快就发现了ZigBee Bridge另外一种用处：虚拟ZigBee装置。ZigBee Bridge的桥接层，在设计上被视为一个拥有抽象界面的存取层。这样的设计可以让网络层以上的层级不需要关心数据到底是从无线界面还是从IP网络接收的。理论上，这样的结构可以延伸发展并包含更多不同种类的界面，或是反过来将某些实体界面从架构中抽离。由于有这样的特性，我们可以建构一个只包含IP界面的装置，换句话说，我们可以建构一个“不包含无线界面的 ZigBee装置”这样的东西。
这种不包含无线界面的ZigBee装置，可以完全由软件构成，不再受到现有的2.4GHz无线传输平台限制。这个“装置”可能是一个在UNIX服务器上运作的daemon，或是在Windows 服务器上运作的Service。我们甚至可能让多个不同的虚拟设备同时存在于一台主机之上。“虚拟ZigBee装置”为现实应用情境的发展带来很多的可能性。用户程序现在可以使用正常的 IPC（Inter-Process Communication）管道与ZigBee装置进行数据交换。应用程序也可以在任何一个有IP网络联机的装置上执行，不必局限于布建的现场。
利用这项技术，我们得以描绘出一个新的系统布建方式。首先我们藉由 Ethernet、HomePNA、WiFi或是Power-Line等异质网络建构一个IP网络骨干，接下来我们布建的环境条件，将整个网络划分成多个小区块。每一个小区块安装一个ZigBee Bridge装置，连接至IP骨干网络。最后，我们架设一台服务器，上面执行虚拟的ZigBee 根节点，藉此形成整个 ZigBee网络。在这样的架构中，所有的ZigBee Bridge都被视为是虚拟根节点底下的第一层 Router，数据首先透过IP网络传至 Bridge，在透过无线信号传至小区块里面的无线节点。
上图显示一个典型的ZigBee Bridge使用情境。在原本的使用情境中，系统被布建在一栋大楼中，由于楼板本身会阻隔无线信号，因此必须沿着楼梯天井或是外墙布建中继节点，以确保数据路径的畅通。如果大楼的层数很高，可以预期顶楼的通信会有严重的延迟与封包遗失问题。若使用ZigBee Bridge，整个网络将会有完全不同的架构。每个楼层可被划分成一个区块，每个楼层安装一个ZigBee Bridge装置并透过骨干网络直接与虚拟ZigBee根节点建立联机，每层楼的传感器直接与Bridge装置进行联机（只要无线信号能够涵盖）。亦即在这个网络中，整体的最大深度大幅度降低。与传统的布建方式相比，差异非常明显。
整合多元化的应用程序环境
ZigBee Bridge成功的解决了与异质网络整合的问题，然而ZigBee Bridge使用的技术方法其实并非Gateway Workgroup最初成立的本意。Gateway Workgroup成立的用意，其实非常单纯：“希望能有一个机制，让用户透过Internet控制ZigBee装置”。在制定初期，GWG的主要目的，是建立一个跨网络存取的服务器界面标准，此一界面将可提供ZigBee堆栈相关服务，以及网络远程访问的能力。如同这个组织的全名，这种装置就称为一个“网关”（Gateway）。
如同Gateway这个英文单字的定义：一个预设的存取界面，ZigBee Gateway也是期望能作为因特网与ZigBee网络的一个整合存取界面。与前述的ZigBee Bridge标准不同，ZigBee Bridge标准在信息传递上，还是使用ZigBee的封包，只是利用IP网络穿遂传输封包；ZigBee Gateway则是更进一步整合了ZigBee堆栈的服务。
目前ZigBee Gateway标准，是架构在原有的ZigBee之上，在不影响原有ZigBee堆栈的前提之下，能透过原本ZigBee堆栈定义的服务存取接口与ZigBee装置作沟通，并增加了传统通信堆栈概念中的表示层（Presentation Layer），作为与IP网络界接的界面。换句话说，ZigBee Gateway在IP端所提供的服务，即是以原本的ZigBee应用程序框架层的服务界面为蓝本，提供远程的应用程序以远程过程调用（Remote Procedure Call）的方式，来存取ZigBee网络服务。
这种特性使得开发者可以用更具有弹性的方式来开发ZigBee应用程序，而不需要像以前一样，将应用程序刻录至通信模块的嵌入式硬件芯片上。对于设备生产者来说，不会再受到通信模块硬件资源的限制，而且也不再需要跟特定的芯片组绑在一起。对通信模块制造者来说，应用程序移至外部系统，表示嵌入式系统芯片只需要满足ZigBee通信协议本身的需求即可，不再需要为了满足所有可能的应用情境，而设计成一个包山包海的高成本芯片。
上图显示一个典型的ZigBee Gateway应用情境。使用者在个人终端界面（通常是一台PC）上安装不同厂商提供的程序，程序各自透过 IP 网络与同一台Gateway装置联机，然后存取各自的装置。与上述“一台笔记计算机后面挂了一串硬件插件”的情境相比，两者差距高下判若云泥！
依照情境选择适用的技术
本篇文章介绍了两种不同的ZigBee整合IP网络的装置。这两种装置各自拥有不同的架构，以及不同的适用情境。ZigBee Bridge装置的角色是一个可用于扩充网络规模的中继节点，适用于ZigBee无线感知网络的骨干建构；ZigBee Gateway装置则是一个具有高度扩充能力的应用程序存取框架。这两种装置的出现，赋予了ZigBee无线感测网络市场前所未有的可能性，以往ZigBee无线感测网络难以触及的广域网，以及整合多元解决方案的应用情境，如今藉由这两种技术，都可以轻易的达成需求。
这两种新技术承诺了美好的未来远景，不过有心尝鲜的设备制造商与整合服务供货商还是得等一等。目前ZigBee联盟公布的Gateway标准只有草案，正式的标准文件截至截稿日期尚未完全定案。部份心急的上游供货商已经开始依照草案的架构来实作产品，但是依据ZigBee 联盟过去的行事风格，不太可能会上演类似“蓝光DVD大战”这样的戏码。
ZigBee Gateway的实际推出时间，在下半年应该会有比较明确的讯息。在目前的阶段，各家厂商不妨开始评估ZigBee技术应用在自己产品服务的可行性，规划自己该如何搭上这一列无线感测网络风潮的列车。
在无线感测网络的技术领域中，与传统无线通信解决方案最大的区别，就在于无线网络的标准化。在传统的无线通信解决方案中，各家的产品缺乏共通标准，只能与自家的产品互动。不同产品之间产生的干扰问题也时有所闻。无线感测网络的标准化，以及认证制度的推行，使得厂商有一个可以依循的方向。只要依循此一标准设计制造的产品，便可以保证与不同厂商装置之间的兼容性。这种特性对于厂商而言，最直接的效益就是产品将不再受到无线信号本身的局限。
传统的无线通信解决方案，套接字与接收端必须维持在无线电信号范围内。而在无线感测网络技术领域，利用无线感测网络协议的多点传输特性，便可仅依靠低传输功率的通信装置，达到广域服务涵盖面积的目的。无线感测网络协议的标准化，更进一步扩展了无线感知网络的功能性：符合通信协议标准的装置，即可无障碍地利用一个已经建构完成的无线感测网络系统进行通信。
由于这样的特性，在无线感测网络的市场中自然衍生出两种不同特性的装置：不具备特定应用程序功能、但可用来架设无线感测网络骨干（Backbone）的装置，以及专门为了某些特定目的而开发的无线感测网络应用装置。
无线感测网络应用装置本身仅需具备通信协议的存取界面，需要的技术能力比较少。然而无线感测网络骨干装置则是需要考虑到现实世界实际布建的各种问题，同时需要考虑到各种多元化应用装置的扩充性，无轮在设计上、或是实际布建上，都会面临相当多的挑战。
本文将以ZigBee无线感测网络骨干装置为核心，介绍两种结合IP网络的ZigBee交换装置。两种装置各自有不同的系统，以及不同的适用情境。然而两种装置对于架设多元化的无线感测网络环境此一目标，皆有着相当重要的地位。
布建的常见问题
任何一种无线感知网络，都存在各式各样的限制。在一个环境受到控制的实验室中，我们可以很简单的建构出一个理想的网络，让网络完全按这我们想要的方式扩张，让封包按照我们想要的方式传送。然而，当我们进入现实世界，我们会受到各式各样的环境因素限制。在大多数的布建案中，想要完全依靠无线技术来建构一个能够传递数据的感知网络，是一件极端困难的挑战。
在现实世界中基本布建的规则是：节点的无线信号范围必须能够互相涵盖。这项要求在开放空间或许很容易达成，但是在复杂空间中，往往会产生各种意料之外的问题。布建在室内空间的ZigBee网络，除非是在建筑物建造或装潢的时候就嵌入成为建材的一部份，否则必然是等装潢完成后才进驻布建。
ZigBee的无线信号可以穿越木板、玻璃、石膏板、砖墙、水泥装饰墙等装潢隔间材质，但是无法穿越内含钢骨的结构墙、金属门、金属隔间柜等厚重物体，因此网络联机必定会受到建筑结构的限制。举例来说，房间与房间之间可能受到结构墙阻隔无法直接通信，必须在房门口附近装设一个中继节点；楼层与楼层之间可能会因为加重承载结构无法直接通信，需要由外墙、阳台、天井、楼梯井等地方架设数个中继节点。这些问题通常会导致两种常见的问题：网络传输路径过长导致延迟过高，或是造成一个特别繁忙的瓶颈节点。
对于这些现实布建物理限制所造成的问题，最有效率的解决方案就是将网络拆分成数个较小的区块。每一个区块可以被视为是一个小型的独立网络，因此在这些区块中，比较容易形成“平衡的”网络拓璞。每一个独立区块可以被视作为一个丛集（Cluster）。每个丛集会设置一个主要的控制节点，用来作为丛集数据的统一出入口。利用这种方式，可以比较有效率的达成流量分散、降低干扰等功用。然而丛集控制点的设计，变成很重要的关键。在某些应用情境中，会将依靠异质网络来作为丛集控制点与丛集控制点之间数据传输的信道，亦即丛集控制点本身即是扮演一个网桥（Bridge）装置的功用。
有相当多的实际应用案例采用这种方式布建。低成本布建的解决方案通常会使用一些现成的转换装置，例如RS232-to-Ethernet的转接器，后端则是连接普通IP网络。这样的解决方案相当有效率，然而这种解决方案通常伴随着潜在问题。这种类型的布建方式，桥接装置几乎毫无例外的采用应用层级的方式来实作封包转发功能。由于通信协议天生的封装与解封装（Capsulation & De-capsulation）性质，应用层级只能取得封装的内容（Payload），无法取得封装的标头（Header）。因此应用层级的封包转发网桥，只能依靠封装内容来作为转发判断的依据。要做到这一点，封装内容必须有一定的格式要求；换句话说，就是缺乏共通性与兼容性。
在实际的布建案例中，采用RS232-to-Ethernet转接器的低成本布建解决方案，几乎都是为了单一用途而建构。在这种网络中如果想要增加新的功能，是非常困难的事。在不变更原有节点的前提下，几乎不可能容纳另外一个不同厂商的系统。
兼容性的极限
通信协议确保的是数据传输与转发的兼容性，而不是数据本身的兼容性。以应用程序的层级来说，除非应用程序本身也依循某些标准规范，例如X.10自动控制，否则不同厂商生产的装置，几乎不可能兼容。
这一点对于生产终端设备的厂商来说，可能反而是一种求之不得的垄断优势：任何购买Ａ公司的控制器的使用者，只能回过头来购买Ａ公司生产的设备；因为Ａ公司的控制器，无法控制Ｂ公司的设备。从设备业者或是工程师的角度思考，这是很合情合理的结果；但是对于一个只是想要整合不同解决方案的使用者来说，这种缺乏兼容的特性就显得荒谬而可笑。
试想一个情境：在一个会议室中，先要寻找控制器Ａ来启动空调设备，然后寻找控制器Ｂ来放下窗帘与投影屏幕，然后寻找控制器Ｃ来启动投影机，最后再拿一开始用过的控制Ａ来关闭灯光。这样的情境不只让人不耐，更会让人产生一种“无线感测网络并没有带来多少便利性”的负面印象。
将控制界面用个人计算机应用程序的方式制作，看似一个可行的解决方案：至少你可以在一台计算机前控制所有东西，而不需要去找一大堆控制器。但是以目前现行的众多实作，这种做法也只是换汤不换药。
采用这种解决方案的厂商，会提供你一个安装软件，以及一个硬件插件（Dangle），同时会指示你用RS232或是USB联机把这个硬件插件连接到计算机上，然后执行控制程序。问题是：控制程序只认得特定的硬件插件，于是Ａ公司控制程序无法控制Ｂ公司硬件插件的老戏码再次上演。各位可以试着想象另外一个情境：一个工程师捧着一台Notebook计算机站在会议室一角，Notebook后面接了一个USB Hub，然后Hub上插满了各种形状、颜色、大小都不同的硬件插件。
相信不用我说各位也晓得：这样看起来真的很蠢。
标准化的解决方案
在上述各种问题重重的解决方案中，核心的问题其实只有一个：缺乏标准。其实针对这两个主要的议题，异质网络整合以及图形使用界面，早已有标准存在，只是比较鲜为人知。
ZigBee标准组织在 2005 年底，正式把整合异质网络来克服各种实际布建问题的概念纳入 ZigBee通信协议的发展蓝图之中。Gateway Workgroup（GWG）是目前负责制定相关应用规格的组织，日前该组织公布了一份新的标准：ZigBee Bridge。
ZigBee Bridge与传统依靠应用层级来进行封包桥接的做法不同，ZigBee Bridge在第二层 Data-link层进行分组交换。这样的特向可以让一个ZigBee Bridge完全不需要依靠用户自动的应用程序，便可以交换所有类型的封包。因此ZigBee Bridge可以视作是一个单纯的“路由器”。ZigBee Bridge的系统架构相当直观；一个新的分组交换层介于网络层以及MAC层之间，原始数据在这一层进行交换，上层的通信协议不需要任何修改便可正常工作。
ZigBee Bridge最早的构想，是使用IP网络来连接一个PAN里面的两个节点，藉此制造一个封包的“虫洞”；可以用来缩短封包路由的路径，或是用来连接两个被空间隔离的网络。但是开发人员很快就发现了ZigBee Bridge另外一种用处：虚拟ZigBee装置。ZigBee Bridge的桥接层，在设计上被视为一个拥有抽象界面的存取层。这样的设计可以让网络层以上的层级不需要关心数据到底是从无线界面还是从IP网络接收的。理论上，这样的结构可以延伸发展并包含更多不同种类的界面，或是反过来将某些实体界面从架构中抽离。由于有这样的特性，我们可以建构一个只包含IP界面的装置，换句话说，我们可以建构一个“不包含无线界面的 ZigBee装置”这样的东西。
这种不包含无线界面的ZigBee装置，可以完全由软件构成，不再受到现有的2.4GHz无线传输平台限制。这个“装置”可能是一个在UNIX服务器上运作的daemon，或是在Windows 服务器上运作的Service。我们甚至可能让多个不同的虚拟设备同时存在于一台主机之上。“虚拟ZigBee装置”为现实应用情境的发展带来很多的可能性。用户程序现在可以使用正常的 IPC（Inter-Process Communication）管道与ZigBee装置进行数据交换。应用程序也可以在任何一个有IP网络联机的装置上执行，不必局限于布建的现场。
利用这项技术，我们得以描绘出一个新的系统布建方式。首先我们藉由 Ethernet、HomePNA、WiFi或是Power-Line等异质网络建构一个IP网络骨干，接下来我们布建的环境条件，将整个网络划分成多个小区块。每一个小区块安装一个ZigBee Bridge装置，连接至IP骨干网络。最后，我们架设一台服务器，上面执行虚拟的ZigBee 根节点，藉此形成整个 ZigBee网络。在这样的架构中，所有的ZigBee Bridge都被视为是虚拟根节点底下的第一层 Router，数据首先透过IP网络传至 Bridge，在透过无线信号传至小区块里面的无线节点。
上图显示一个典型的ZigBee Bridge使用情境。在原本的使用情境中，系统被布建在一栋大楼中，由于楼板本身会阻隔无线信号，因此必须沿着楼梯天井或是外墙布建中继节点，以确保数据路径的畅通。如果大楼的层数很高，可以预期顶楼的通信会有严重的延迟与封包遗失问题。若使用ZigBee Bridge，整个网络将会有完全不同的架构。每个楼层可被划分成一个区块，每个楼层安装一个ZigBee Bridge装置并透过骨干网络直接与虚拟ZigBee根节点建立联机，每层楼的传感器直接与Bridge装置进行联机（只要无线信号能够涵盖）。亦即在这个网络中，整体的最大深度大幅度降低。与传统的布建方式相比，差异非常明显。
整合多元化的应用程序环境
ZigBee Bridge成功的解决了与异质网络整合的问题，然而ZigBee Bridge使用的技术方法其实并非Gateway Workgroup最初成立的本意。Gateway Workgroup成立的用意，其实非常单纯：“希望能有一个机制，让用户透过Internet控制ZigBee装置”。在制定初期，GWG的主要目的，是建立一个跨网络存取的服务器界面标准，此一界面将可提供ZigBee堆栈相关服务，以及网络远程访问的能力。如同这个组织的全名，这种装置就称为一个“网关”（Gateway）。
如同Gateway这个英文单字的定义：一个预设的存取界面，ZigBee Gateway也是期望能作为因特网与ZigBee网络的一个整合存取界面。与前述的ZigBee Bridge标准不同，ZigBee Bridge标准在信息传递上，还是使用ZigBee的封包，只是利用IP网络穿遂传输封包；ZigBee Gateway则是更进一步整合了ZigBee堆栈的服务。
目前ZigBee Gateway标准，是架构在原有的ZigBee之上，在不影响原有ZigBee堆栈的前提之下，能透过原本ZigBee堆栈定义的服务存取接口与ZigBee装置作沟通，并增加了传统通信堆栈概念中的表示层（Presentation Layer），作为与IP网络界接的界面。换句话说，ZigBee Gateway在IP端所提供的服务，即是以原本的ZigBee应用程序框架层的服务界面为蓝本，提供远程的应用程序以远程过程调用（Remote Procedure Call）的方式，来存取ZigBee网络服务。
这种特性使得开发者可以用更具有弹性的方式来开发ZigBee应用程序，而不需要像以前一样，将应用程序刻录至通信模块的嵌入式硬件芯片上。对于设备生产者来说，不会再受到通信模块硬件资源的限制，而且也不再需要跟特定的芯片组绑在一起。对通信模块制造者来说，应用程序移至外部系统，表示嵌入式系统芯片只需要满足ZigBee通信协议本身的需求即可，不再需要为了满足所有可能的应用情境，而设计成一个包山包海的高成本芯片。
上图显示一个典型的ZigBee Gateway应用情境。使用者在个人终端界面（通常是一台PC）上安装不同厂商提供的程序，程序各自透过 IP 网络与同一台Gateway装置联机，然后存取各自的装置。与上述“一台笔记计算机后面挂了一串硬件插件”的情境相比，两者差距高下判若云泥！
依照情境选择适用的技术
本篇文章介绍了两种不同的ZigBee整合IP网络的装置。这两种装置各自拥有不同的架构，以及不同的适用情境。ZigBee Bridge装置的角色是一个可用于扩充网络规模的中继节点，适用于ZigBee无线感知网络的骨干建构；ZigBee Gateway装置则是一个具有高度扩充能力的应用程序存取框架。这两种装置的出现，赋予了ZigBee无线感测网络市场前所未有的可能性，以往ZigBee无线感测网络难以触及的广域网，以及整合多元解决方案的应用情境，如今藉由这两种技术，都可以轻易的达成需求。
这两种新技术承诺了美好的未来远景，不过有心尝鲜的设备制造商与整合服务供货商还是得等一等。目前ZigBee联盟公布的Gateway标准只有草案，正式的标准文件截至截稿日期尚未完全定案。部份心急的上游供货商已经开始依照草案的架构来实作产品，但是依据ZigBee 联盟过去的行事风格，不太可能会上演类似“蓝光DVD大战”这样的戏码。
ZigBee Gateway的实际推出时间，在下半年应该会有比较明确的讯息。在目前的阶段，各家厂商不妨开始评估ZigBee技术应用在自己产品服务的可行性，规划自己该如何搭上这一列无线感测网络风潮的列车。
