当前位置：文档库 › 《国家标准》zigbee两种绑定机制

《国家标准》zigbee两种绑定机制

我使用的协议栈版本及例子信息:

ZigBee2006\ZStack-1.4.3-1.2.1个人注释版_5.24\Projects\zstack\Samples\SimpleApp\CC2430DB

建立一个绑定表格有3种方式：

(1)ZDO绑定请求:一个试运转的工具能告诉这个设备制作一个绑定报告

(2)ZDO终端设备绑定请求:设备能告诉协调器他们想建立绑定表格报告。该协调器将使协调并在这两个设备上创建绑定表格条目。

(3)设备应用:在设备上的应用能建立或管理一个绑定表格。

有两种可用的机制配置设备绑定:

(1)如果目的设备的扩展地址是已知的，则zb_BindDeviceRequest()函数能创建一个绑定条目。

(2)如果扩展地址是未知的，则一个"按钮"可以利用。这样的话，这个目的设备首先处于一种状态，它将被zb_AllowBindResponse()发出一个匹配响应；然后在源设备处，zb_AllowBindRequest()函数带着空地址出发.

以上两种绑定机制，最终都是用函数APSME_BindRequest()创建绑定。不同的是，前者采用的目的地址是64位扩展地址，而后者采用的目的地址是16位网络地址。前者已知扩展地址，调用了

ZDP_NwkAddrReq()函数获得目的设备短地址；后者利用描述匹配得到了短地址，然后调用了

ZDP_IEEEAddrReq()函数，获取目的设备的扩展地址.

********************************************************************************************************************** ****

1、已知扩展地址的绑定

这里可以直接调用函数zb_BindDevice()发起绑定请求：

zb_BindDevice ( uint8 create, //是否创建绑定，TRUE则创建,FALSE则解除

uint16 commandId, //命令ID,基于某命令的绑定,相当于簇

uint8 *pDestination ) //指向扩展地址的指针

函数程序如下(已知扩展地址的绑定部分)

******************************************

void zb_BindDevice ( uint8 create, uint16 commandId, uint8 *pDestination )

{

zAddrType_t destination;

uint8 ret = ZB_ALREADY_IN_PROGRESS;

if ( create ) //create = true 建立绑定

{

if (sapi_bindInProgress == 0xffff) //不允许绑定过程??

{

//---------------------------------

if ( pDestination ) //已知扩展地址的绑定，即*pDestination 为非NULL

{

destination.addrMode = Addr64Bit;

osal_cpyExtAddr( destination.addr.extAddr, pDestination );

//直接调用APS绑定请求函数

ret = APSME_BindRequest( sapi_epDesc.endPoint, //源EP

commandId, //簇ID

&destination, //目的地址模式

sapi_epDesc.endPoint ); //目的EP

if ( ret == ZSuccess ) //绑定成功

{

// Find nwk addr 发现网络地址,得到被绑定设备的短地址

ZDP_NwkAddrReq(pDestination, ZDP_ADDR_REQTYPE_SINGLE, 0, 0 );

osal_start_timerEx( ZDAppTaskID, ZDO_NWK_UPDATE_NV, 250 );

}

//---------------------------------

else //未知目的扩展地址，即*pDestination=NULL

{

ret = ZB_INVALID_PARAMETER;

destination.addrMode = Addr16Bit;

destination.addr.shortAddr = NWK_BROADCAST_SHORTADDR; //0xffff 描述符匹配请求：广播

/*检测输出簇；如果是输出簇，则去匹配一个处于允许绑定模式的设备*/

if ( ZDO_AnyClusterMatches( 1, &commandId,

sapi_epDesc.simpleDesc->AppNumOutClusters,

sapi_epDesc.simpleDesc->pAppOutClusterList ) ) {

// Try to match with a device in the allow bind mode

ret = ZDP_MatchDescReq( &destination, NWK_BROADCAST_SHORTADDR, sapi_epDesc.simpleDesc->AppProfId, 1, &commandId, 0, (cId_t *)NULL, 0 );

}

/*检测输入簇；如果是输入簇，则去匹配一个处于允许绑定模式的设备*/

else if ( ZDO_AnyClusterMatches( 1, &commandId,

sapi_epDesc.simpleDesc->AppNumInClusters,

sapi_epDesc.simpleDesc->pAppInClusterList ) )

{

ret = ZDP_MatchDescReq( &destination, NWK_BROADCAST_SHORTADDR, sapi_epDesc.simpleDesc->AppProfId, 0, (cId_t *)NULL, 1, &commandId, 0 );

}

if ( ret == ZB_SUCCESS )

{

// Set a timer to make sure bind completes

osal_start_timerEx(sapi_TaskID, ZB_BIND_TIMER, AIB_MaxBindingTime);

sapi_bindInProgress = commandId;

return; // dont send cback event

}

//---------------------------------

}

SAPI_SendCback( SAPICB_BIND_CNF, ret, commandId );

}

else //create = false 删除绑定

{

// Remove local bindings for the commandId

BindingEntry_t *pBind;

// Loop through bindings an remove any that match the cluster

while ( pBind = bindFind( sapi_epDesc.simpleDesc->EndPoint, commandId, 0 ) )

{

bindRemoveEntry(pBind);

}

osal_start_timerEx( ZDAppTaskID, ZDO_NWK_UPDATE_NV, 250 );

}

return;

}

******************************************

在上面已知扩展地址的绑定程序中调用了APS绑定函数APSME_BindRequest()，这个函数在两个设备间建立绑定，通过APSME_BIND.confirm原语返回，而且这两者是不可分割的。如果绑定成功，则调用函数ZDP_NwkAddrReq()得到目的设备的短地址。ZDP_NwkAddrReq()这个函数可以产生一个根据已知遥远设备的IEEE地址,请求得到16位短地址的信息.该信息以广播的方式发送给网络中的所有设备.

2、未知扩展地址的绑定(simpApp例子中默认的绑定机制)

该绑定方式下，在发送绑定请求前，先要让被绑定的目的设备处于允许绑定模式。可以调用函数

zb_AllowBind()进入该模式，函数如下：

******************************************

//函数设置设备处于允许绑定模式

//timerout=0x00：不允许绑定

//timerout=0xff：一直处于绑定模式

//0

void zb_AllowBind ( uint8 timeout )

{

osal_stop_timerEx(sapi_TaskID, ZB_ALLOW_BIND_TIMER);

if ( timeout == 0 )

{

afSetMatch(sapi_epDesc.simpleDesc->EndPoint, FALSE);

}

else

{

afSetMatch(sapi_epDesc.simpleDesc->EndPoint, TRUE);//设置允许响应匹配描述符请求

if ( timeout != 0xFF )

{

if ( timeout > 64 )

{

timeout = 64;

}

//设置了允许匹配后，开启一个定时器，时间为timeout*1000，

//时间一到触发sapi任务ZB_ALLOW_BIND_TIMER事件，SAPI_ProcessEvent()对其的处理是//afSetMatch(sapi_epDesc.simpleDesc->EndPoint, FALSE)而取消允许绑定

osal_start_timerEx(sapi_TaskID, ZB_ALLOW_BIND_TIMER, timeout*1000);

}

return;

}

******************************************

参数timeout是进入绑定模式持续的时间(s)。如果设置为OxFF,则设备在任何时候都在允许绑定模式;如果设置为OxOO,则设备将通过该命令取消允许绑定模式.

调用该函数使设备在给定时间内进入允许绑定模式.一个在允许绑定模式下同等的设备调用函数

zb_BindDevice()能与之建立绑定，此时目的扩展地址为空(参见上面zb_BindDevice()未知目的扩展地址部分).zb_AllowBind()调用afSetMatch()，使之允许响应ZDO的匹配描述符请求.

以上设置目的设备允许绑定模式(比如simpleApp的灯设备)，那在目的设备处于允许绑定模式的时间内，源设备(比如simpleApp的开关设备)可以调用zb_BindDevice()来发起绑定请求.此时执行的程序如下:

******************************************

void zb_BindDevice ( uint8 create, uint16 commandId, uint8 *pDestination )

{

…………

//---------------------------------

else //未知目的扩展地址，即*pDestination=NULL

{

ret = ZB_INVALID_PARAMETER;

destination.addrMode = Addr16Bit;

destination.addr.shortAddr = NWK_BROADCAST_SHORTADDR; //0xffff

/*检测输出簇，如果是输出簇，则去匹配一个处于允许绑定模式的设备*/

if ( ZDO_AnyClusterMatches( 1, &commandId,

sapi_epDesc.simpleDesc->AppNumOutClusters,

sapi_epDesc.simpleDesc->pAppOutClusterList ) )

// Try to match with a device in the allow bind mode

//匹配一个在允许绑定模式下的设备

ret = ZDP_MatchDescReq( &destination, NWK_BROADCAST_SHORTADDR, sapi_epDesc.simpleDesc->AppProfId, 1, &commandId, 0, (cId_t *)NULL, 0 );

}

/*检测输入簇，如果是输入簇，则去匹配一个处于允许绑定模式的设备*/

else if ( ZDO_AnyClusterMatches( 1, &commandId,

sapi_epDesc.simpleDesc->AppNumInClusters,

sapi_epDesc.simpleDesc->pAppInClusterList ) )

{

ret = ZDP_MatchDescReq( &destination, NWK_BROADCAST_SHORTADDR, sapi_epDesc.simpleDesc->AppProfId, 0, (cId_t *)NULL, 1, &commandId, 0 );

}

if ( ret == ZB_SUCCESS )

{

// Set a timer to make sure bind completes 设置一个时间，确保绑定完成

osal_start_timerEx(sapi_TaskID, ZB_BIND_TIMER, AIB_MaxBindingTime);

sapi_bindInProgress = commandId; //允许基于commandId命令的绑定过程

return; // dont send cback event

}

//---------------------------------

…………

}

******************************************

在之中调用了函数ZDP_MatchDescReq()，将建立和发送一个匹配描述符请求。用这个函数在一个应用中的输入/输出簇列表中搜索匹配某条件的设备/应用。该绑定响应处理在SAPI_ProcessEvent事件处理函数中

case ZDO_CB_MSG: /*ZDO信息数据*/

SAPI_ProcessZDOMsgs( (zdoIncomingMsg_t *)pMsg );

看下SAPI_ProcessZDOMsgs()函数

******************************************

// SAPI_Init()函数中注册了以下两个ZDO信息

// ZDO_RegisterForZDOMsg( sapi_TaskID, NWK_addr_rsp );

// ZDO_RegisterForZDOMsg( sapi_TaskID, Match_Desc_rsp );

void SAPI_ProcessZDOMsgs( zdoIncomingMsg_t *inMsg )

{

switch ( inMsg->clusterID )

{

//--------------------

case NWK_addr_rsp:

…………

//--------------------

case Match_Desc_rsp:

{

zAddrType_t dstAddr;

ZDO_ActiveEndpointRsp_t *pRsp = ZDO_ParseEPListRsp( inMsg );

if ( sapi_bindInProgress != 0xffff ) //commandId

{

// Create a binding table entry 创建一个绑定条目

dstAddr.addrMode = Addr16Bit;

dstAddr.addr.shortAddr = pRsp->nwkAddr;

/*调用这个函数来实现两个设备的绑定*/

if ( APSME_BindRequest( sapi_epDesc.simpleDesc->EndPoint, //源EP

sapi_bindInProgress, //簇ID

&dstAddr, //目的地址模式

pRsp->epList[0] ) == ZSuccess ) //目的EP

//成功实现绑定后

{

//zb_BindDevice()中开启了一个定时器，用于接收Match_Desc_rsp计时

//如果接收到，则停止这个定时器，如下；如果溢出，则触发相应任务事件

osal_stop_timerEx(sapi_TaskID, ZB_BIND_TIMER);

osal_start_timerEx( ZDAppTaskID, ZDO_NWK_UPDATE_NV, 250 );

sapi_bindInProgress = 0xffff;

// Find IEEE addr

ZDP_IEEEAddrReq( pRsp->nwkAddr, ZDP_ADDR_REQTYPE_SINGLE, 0, 0 );

// Send bind confirm callback to application

zb_BindConfirm( sapi_bindInProgress, ZB_SUCCESS );

}

break;

}

******************************************

以上内容摘自《zigbee2006无线网络与无线定位实战》这本书，根据协议版本的不同作了一些修改。

实例中的两种绑定机制，第一种(已知扩展地址的绑定)流程，就是zb_BindDevice()根据扩展地址直接调用APSME_BindRequest()创建绑定条目实现绑定，再得到其16位网络地址；第二种(未知扩展地址的绑定)，因地址未知，须先经过一个描述符匹配过程得到相匹配设备的16位短地址，然后通过

APSME_BindRequest()创建绑定条目实现绑定，再得到其扩展地址.

下面引用《zigbee2006无线网络与无线定位实战》对未知扩展地址的绑定流程的描述(以simpApp灯开关实验为例),根据协议版本不同作了相应修改:

(1)首先调用zb_AllowBind(myAllowBindTimeout)函数，使管理设备(灯)处于允许绑定(匹配)响应模式

(2)在myAllowBindTimeout规定的时间内，终端设备需要调用zb_BindDevice(TRUE,

TOGGLE_LIGHT_CMD_ID, NULL)函数发送绑定(描述符匹配ZDP_MatchDescReq)请求.

(3)当管理器接收到匹配请求后，对该匹配作出响应，发送一个匹配响应(P:在

ZDO_ProcessMatchDescReq()函数中)，之后可以看到发送匹配响应后的确认事件(P:在

ZDO_ProcessMatchDescReq()函数中)：

pRspSent->hdr.event = ZDO_MATCH_DESC_RSP_SENT;

(4)当终端接收到匹配响应后，产生该事件:

case Match_Desc_rsp：

该事件详细处理过程参见SAPI_ProcessZDOMsgs，这里面调用了APSME_BindRequest()建立绑定，而且调用了ZDP_IEEEAddrReq()得到被绑定的IEEE地址.

(5)最后完成绑定,在终端设备建立绑定表格.

一开始看书上这匹配过程还是蛮纠结的,下面详细记录下个人对未知扩展地址的绑定流程的理解:

********************************************************************************************************************** ****

首先理清两个节点,以灯开关实验为例:

管理器(灯) 终端(开关)

1、-------------允许绑定模式----------------------- ----------

2、------------- --<----<---<--------广播发送描述符匹配请求(绑定请求)

3、-----接收后发送描述符匹配响应-->--->--->-- -----------

4、------------- ---------------接收后获得管理器地址，建立终端与管理器间的绑定---

第一步:管理器处于允许绑定模式，参见上面的记录

第二步:终端调用zb_BindDevice()发送描述符匹配请求(即绑定请求)给管理器.

zb_BindDevice()调用ZDP_MatchDescReq()：

******************************************

//函数建立和发送一个匹配描述请求.灯开关实验zb_BindDevice()中初始化为广播：

//destination.addr.shortAddr = NWK_BROADCAST_SHORTADDR;

//使用这个函数查询与应用程序输入或输出簇列表相匹配的应用程序或设备.

//即发现服务，或者叫自动寻求匹配设备。

afStatus_t ZDP_MatchDescReq(

zAddrType_t *dstAddr, //目的地址类型

uint16 nwkAddr, //16位目的网络地址

uint16 ProfileID,

byte NumInClusters, cId_t *InClusterList, //簇输入列表簇ID数及簇ID输入数组

byte NumOutClusters, cId_t *OutClusterList, //簇输出列表簇ID数及簇ID输出数组

byte SecurityEnable )

{

/*指针pBuf指向ZDP_TmpBuf，下面为配置数组ZDP_TmpBuf[ ]*/

byte *pBuf = ZDP_TmpBuf;//ZDP_TmpBuf=ZDP_Buf+1; ZDP_Buf[80]

// nwkAddr+ProfileID+NumInClusters+NumOutClusters.

byte i, len = 2 + 2 + 1 + 1; // nwkAddr+ProfileID+NumInClusters+NumOutClusters.

len += (NumInClusters + NumOutClusters) * sizeof(uint16);

if ( len >= ZDP_BUF_SZ-1 )

{

return afStatus_MEM_FAIL;

}

*pBuf++ = LO_UINT16( nwkAddr ); // NWKAddrOfInterest

*pBuf++ = HI_UINT16( nwkAddr );

*pBuf++ = LO_UINT16( ProfileID ); // Profile ID

*pBuf++ = HI_UINT16( ProfileID );

//-------------------------

*pBuf++ = NumInClusters; // Input cluster list

if ( NumInClusters )

{

for (i=0; i

*pBuf++ = LO_UINT16( InClusterList[i] );

*pBuf++ = HI_UINT16( InClusterList[i] );

}

//-------------------------

*pBuf++ = NumOutClusters; // Output cluster list

if ( NumOutClusters )

{

for (i=0; i

*pBuf++ = LO_UINT16( OutClusterList[i] );

*pBuf++ = HI_UINT16( OutClusterList[i] );

}

//-------------------------

//注意这里clusterID设置为Match_Desc_req

return fillAndSend( &ZDP_TransID, dstAddr, Match_Desc_req, len );

}

******************************************

ZDP_MatchDescReq()中配置了clusterID=Match_Desc_req，dstAddr为广播，数据为ZDP_TmpBuf 的信息，通过fillAndSend()来发送，看下fillAndSend()：

******************************************

static afStatus_t fillAndSend( uint8 *transSeq, zAddrType_t *addr, cId_t clusterID, byte len )

{

afAddrType_t afAddr;

ZADDR_TO_AFADDR( addr, afAddr );

*(ZDP_TmpBuf-1) = *transSeq;

return AF_DataRequest( &afAddr, &ZDApp_epDesc, clusterID,

(uint16)(len+1), (uint8*)(ZDP_TmpBuf-1),

transSeq, ZDP_TxOptions, AF_DEFAULT_RADIUS );

}

******************************************

可以看到fillAndSend()最终调用AF_DataRequest()来广播发送描述符匹配请求.

第三步：管理器接收到终端发送的描述符匹配请求(也即绑定请求).

那管理器是如何作出处理的?

因为ZDO层是管理绑定的(绑定表建在APS中),管理器接收到的描述符匹配请求是发往其ZDO层的,首先来看下这个函数:ZDP_IncomingData()

******************************************

* @fn ZDP_IncomingData

* @brief This function indicates the transfer of a data PDU (ASDU)

* from the APS sub-layer to the ZDO.

* @param pData - Incoming Message

* @return none

//APS-->ZDO

void ZDP_IncomingData( afIncomingMSGPacket_t *pData )

{

uint8 x = 0;

uint8 handled;

zdoIncomingMsg_t inMsg;

inMsg.srcAddr.addrMode = Addr16Bit;

inMsg.srcAddr.addr.shortAddr = pData->srcAddr.addr.shortAddr;

inMsg.wasBroadcast = pData->wasBroadcast;

inMsg.clusterID = pData->clusterId;

inMsg.SecurityUse = pData->SecurityUse;

inMsg.asduLen = pData->cmd.DataLength-1;

inMsg.asdu = pData->cmd.Data+1;

inMsg.TransSeq = pData->cmd.Data[0];

//通过ZDO_SendMsgCBs()这个函数把ZDO信息发送到注册过ZDO信息的任务中去.

//比如sapi中SAPI_Init()注册过两种类型clusterId的ZDO信息：NWK_addr_rsp 和

Match_Desc_rsp

//因此其它命令，比如请求命令不会发送到sapi应用层中

//注意，End_Device_Bind_req这个ZDO信息是注册在ZDAppTaskID任务中的.

handled = ZDO_SendMsgCBs( &inMsg );

#if defined( MT_ZDO_FUNC )

MT_ZdoRsp( &inMsg );

#endif

//注意，这里只会对请求/设置/通知命令才调用相应处理函数，如果是响应命令则不处理

//但是要ZDO信息处理表中包含的命令才有相应的处理函数,有些没有的就不会调用

//比如End_Device_Bind_req，这个很重要，它在哪里被处理呢?在ZDApp层任务中，

//函数ZDApp_RegisterCBs()把这个请求命令登记到了ZDAppTaskID，具体参见

ZDApp_RegisterCBs()

while ( zdpMsgProcs[x].clusterID != 0xFFFF ) //一个个查询过去

{

if ( zdpMsgProcs[x].clusterID == inMsg.clusterID )

{

zdpMsgProcs[x].pFn( &inMsg ); //调用相应ZDO信息处理函数

return; //如x=6，为ZDO_ProcessMatchDescReq();

}

x++;

}

// Handle unhandled message

if ( !handled )

ZDApp_InMsgCB( &inMsg );

}

******************************************

这里涉及到三个函数：ZDO_SendMsgCBs()；zdpMsgProcs[x].pFn( &inMsg )；ZDApp_InMsgCB (1)ZDO_SendMsgCBs()：把ZDO接收信息发送到注册过ZDO信息的任务中去；具体流程是比较接收信息的簇ID与注册过的簇ID,有相同则调用osal_msg_send()触发相应任务事件，事件这里默认为

ZDO_CB_MSG，因此可以看到SAPI_ProcessEvent()中有这个事件.注意这个函数只会传送信息到注册过相应ZDO信息的任务中去.

(2)对于zdpMsgProcs[x].pFn( &inMsg )，ZDProfile.c如下定义：

//把pfnZDPMsgProcessor声明为一种函数指针的类型别明,指向类似Fun(*inMsg)这种类型

//的函数.如果用此别名来声明一个指针变量，如:pfnZDPMsgProcessor pFn,则当pFn获取

//函数的地址后，就可以像调用原函数一样来使用这个函数指针：pFn(*inMsg)

typedef void (*pfnZDPMsgProcessor)( zdoIncomingMsg_t *inMsg );

typedef struct

{

uint16 clusterID;

pfnZDPMsgProcessor pFn;

} zdpMsgProcItem_t;

//定义一个zdpMsgProcItem_t类型的数组zdpMsgProcs[]，则数组zdpMsgProcs[]中

//的每个元素都是zdpMsgProcItem_t类型的结构体:{clusterID,pFn}

CONST zdpMsgProcItem_t zdpMsgProcs[ ] =

{

{ NWK_addr_req, zdpProcessAddrReq },

{ IEEE_addr_req, zdpProcessAddrReq },

{ Node_Desc_req, ZDO_ProcessNodeDescReq },

{ Power_Desc_req, ZDO_ProcessPowerDescReq },

{ Simple_Desc_req, ZDO_ProcessSimpleDescReq },

{ Active_EP_req, ZDO_ProcessActiveEPReq },

{ Match_Desc_req, ZDO_ProcessMatchDescReq },

…………(后面省略)

{0xFFFF, NULL} // Last

};

(3)ZDApp_InMsgCB()：函数说明如下：

* @brief This function is called to pass up any message that is

* not yet supported. This allows for the developer to

* support features themselves..

这函数我就不去管了.

回到刚才问题：管理器接收到描述符匹配请求后是如何处理的?

因为这里是接收到描述符匹配请求，SAPI_Init中没有注册过这个ZDO信息,因此不会通过

ZDO_SendMsgCBs()发送到sapi应用.然后查询ZDO信息处理表,当x=6时发现命令相符，调用ZDO_ProcessMatchDescReq()对描述符匹配请求进行处理.

下面来看下ZDO_ProcessMatchDescReq()函数：

******************************************

void ZDO_ProcessMatchDescReq( zdoIncomingMsg_t *inMsg )

{

…………

// Parse the incoming message

…………

//--------------------------发送描述符匹配请求的响应

if ( ADDR_BCAST_NOT_ME == NLME_IsAddressBroadcast(aoi) )

{

ZDP_MatchDescRsp( inMsg->TransSeq, &(inMsg->srcAddr), ZDP_INVALID_REQTYPE, ZDAppNwkAddr.addr.shortAddr, 0, NULL, inMsg->SecurityUse );

return;

}

else if ( (ADDR_NOT_BCAST == NLME_IsAddressBroadcast(aoi)) && (aoi != ZDAppNwkAddr.addr.shortAddr) )

{

ZDP_MatchDescRsp( inMsg->TransSeq, &(inMsg->srcAddr), ZDP_INVALID_REQTYPE,

ZDAppNwkAddr.addr.shortAddr, 0, NULL, inMsg->SecurityUse );

return;

}

//--------------------------

…………

//发送匹配响应后的确认事件ZDO_MATCH_DESC_RSP_SENT

pRspSent->hdr.event = ZDO_MATCH_DESC_RSP_SENT;

…………

osal_msg_send( *epDesc->epDesc->task_id, (uint8 *)pRspSent );

…………

}

******************************************

可以看到这里管理器首先通过ZDP_MatchDescRsp()发送匹配响应给终端.而ZDP_MatchDescRsp()宏定义为ZDP_EPRsp()，ZDP_EPRsp()设置clusterID为Match_Desc_rsp并调用FillAndSendTxOptions()，FillAndSendTxOptions()中调用fillAndSend()，fillAndSend()中最终调用AF_DataRequest()来发送匹配响应给终端(灯).发送完匹配响应后管理器触发一个确认事件

ZDO_MATCH_DESC_RSP_SENT，来指示有个设备试图与自己绑定.管理器是如何对这个确认事件进行处理的?如下：

SAPI_ProcessEvent()中对ZDO_MATCH_DESC_RSP_SENT的处理：

case ZDO_MATCH_DESC_RSP_SENT: /*发送匹配响应*/

SAPI_AllowBindConfirm( ((ZDO_MatchDescRspSent_t *)pMsg)->nwkAddr );

来看下SAPI_AllowBindConfirm()这个函数：

******************************************

* @fn SAPI_AllowBindConfirm

* @brief Indicates when another device attempted to bind to this device

* @param

* @return none

void SAPI_AllowBindConfirm( uint16 source )

{

#if defined ( MT_SAPI_CB_FUNC )

/* First check if MT has subscribed for this callback. If so , pass it as

a event to MonitorTest and return control to calling function after that */

if ( SAPICB_CHECK( SPI_CB_SAPI_ALLOW_BIND_CNF ) )

{

zb_MTCallbackAllowBindConfirm( source ); //这里应该是把请求匹配的设备的网络地址通过串口发PC

}

else

#endif //MT_SAPI_CB_FUNC

{

zb_AllowBindConfirm( source ); //未定义

}

******************************************

管理器接收到终端发送的描述符匹配请求后,发送一个描述符匹配请求的响应给终端,并触发一个确认事件指示有个设备试图与本设备进行绑定.

第四步:终端接收到管理器发送的描述符匹配响应.

同样，这个响应信息也是发往ZDO层的,因此首先要来看ZDP_IncomingData()这个函数,具体见第三步.因为接收到的响应信息clusterID为Match_Desc_rsp，SAPI_Init注册过，因此会通过

ZDO_SendMsgCBs()把这个描述符匹配响应信息发送到sapi应用层，而在ZDO信息处理表中查询不到相符合的clusterID,因此不会调用任何处理函数.这里刚好与第二步中对描述符匹配请求的处理相反.下面来看下ZDO_SendMsgCBs()把这个描述符匹配响应信息发送到sapi应用层后的处理，

ZDO_SendMsgCBs()发送的流程参见第三步，其最终触发任务sapi的ZDO_CB_MSG事件，而sapi任务事件处理函数SAPI_ProcessEvent()通过调用SAPI_ProcessZDOMsgs()对其进行处理：case ZDO_CB_MSG: /*ZDO信息*/

SAPI_ProcessZDOMsgs( (zdoIncomingMsg_t *)pMsg );

break;

来看下SAPI_ProcessZDOMsgs()：

******************************************

// SAPI_Init()函数中注册了以下两个ZDO信息

// ZDO_RegisterForZDOMsg( sapi_TaskID, NWK_addr_rsp );

// ZDO_RegisterForZDOMsg( sapi_TaskID, Match_Desc_rsp );

void SAPI_ProcessZDOMsgs( zdoIncomingMsg_t *inMsg )

{

switch ( inMsg->clusterID )

{

//--------------------

case NWK_addr_rsp:

{

…………

break;

//--------------------

case Match_Desc_rsp:

{

zAddrType_t dstAddr;

ZDO_ActiveEndpointRsp_t *pRsp = ZDO_ParseEPListRsp( inMsg );

if ( sapi_bindInProgress != 0xffff ) //允许基于commandID的绑定

{

// Create a binding table entry 创建一个绑定条目

dstAddr.addrMode = Addr16Bit;

dstAddr.addr.shortAddr = pRsp->nwkAddr; //通过描述符匹配响应信息得到管理器的网络地址

/*调用这个函数来实现两个设备的绑定*/

if ( APSME_BindRequest( sapi_epDesc.simpleDesc->EndPoint, //源EP

sapi_bindInProgress, //簇ID

&dstAddr, //目的地址模式

pRsp->epList[0] ) == ZSuccess ) //目的EP

//成功实现绑定后

{

//zb_BindDevice()中开启了一个定时器，用于接收Match_Desc_rsp计时

//如果接收到，则停止这个定时器，如下；如果溢出，则触发相应任务事件

osal_stop_timerEx(sapi_TaskID, ZB_BIND_TIMER);

osal_start_timerEx( ZDAppTaskID, ZDO_NWK_UPDATE_NV, 250 );

sapi_bindInProgress = 0xffff;//不允许绑定过程

// Find IEEE addr

ZDP_IEEEAddrReq( pRsp->nwkAddr, ZDP_ADDR_REQTYPE_SINGLE, 0, 0 );

// Send bind confirm callback to application

//告诉应用绑定成功

zb_BindConfirm( sapi_bindInProgress, ZB_SUCCESS );

}

break;

}

******************************************

可以看到通过接收到的描述符匹配响应信息，终端获得允许绑定模式下管理器的16位网络地址：dstAddr.addr.shortAddr = pRsp->nwkAddr;最终调用APSME_BindRequest()来绑定终端设备与管理器.

引用《ZigBee四种绑定方式在TI Z-Stack中的应用》的一段话：

一、“终端设备绑定请求”这一命名有误导的嫌疑。这一请求不仅仅适用于终端设备，而且适用于对希望在协调器上绑定的两个设备中匹配的簇实施绑定。一旦这个函数被调用，将假设REFLECTOR这一编译选项在所有希望使用这一服务的节点中都已经打开。具体操作如下：

（1）(Bind Req) Device 1 --> Coordinator <--- Device 2 (Bind Req)

协调器首先找出包含在绑定请求中的簇，然后对比每一设备的IEEE地址，如果簇可以匹配，而且这几个设备没有已经存在的绑定表，那他将发送一个绑定应答给每一个设备。

（2）Device 1 <--- NWK Addr Req ------ Coordinator ------- NWK addr Req ----> Device 2

（3）Device 1 ----> NWK Addr Rsp ---> Coordinator <---- NWK addr Rsp <--- Device 2

（4）Device 1 <----- Bind Rsp <----- Coordinator -----> Bind Rsp ----> Device 2

二、“描述符匹配”为源设备的服务发现提供了一种灵巧的方法。下面是具体的操作，这一过程并没有通过协调器。

（1）Device 1 ----> Match Descriptor request (broadcast or unicast) Device 2

（2）Device 1 <---- Match Descriptor response (if clusters, application profile id match) that includes src endpoint, src address <---- Device 2

1号设备需要维护一个端点和地址的记录。

许多应用服务最终都会使用第二种方法。

ZigBee重要结构及表解释

ZigBee重要结构及表解释 ZigBee 2010-06-13 10:31:26 阅读103 评论0 字号：大中小订阅各表中的元素结构： 1、组表的元素结构aps_Group_t; typedef struct { uint16 ID; // 组ID uint8 name[APS_GROUP_NAME_LEN]; // 组名称 } aps_Group_t; 2、组列表的元素结构 typedef struct apsGroupItem { struct apsGroupItem *next; //指向下一个组表条目 uint8 endpoint; //此终端接收发送给组的信息 aps_Group_t group; //组ID和组名 } apsGroupItem_t; 3、路由表的元素结构rtgEntry_t; typedef struct { uint16 dstAddress; //目标地址 uint16 nextHopAddress; //单跳地址 byte expiryTime; //有效时间 byte status; //状态 } rtgEntry_t; 4、绑定表的元素结构BindingEntry_t; typedef struct

{ uint8 srcEP; // 没有源地址自从源地址一直是本地设备uint8 dstGroupMode; // 目标地址类型; 0 –正常地址, 1 –组地址 uint16 dstIdx; //在两种模式中(组或非组) 保存到NV 和RAM // dstGroupMode = 0 - Address Manager index // dstGroupMode = 1 –组地址 uint8 dstEP; //目标地址 uint8 numClusterIds; //簇个数 uint16 clusterIdList[MAX_BINDING_CLUSTER_IDS]; // Don't use MAX_BINDING_CLUSTERS_ID when // using the clusterIdList field. Use // gMAX_BINDING_CLUSTER_IDS } BindingEntry_t; 5、相邻表的元素结构neighborEntry_t; typedef struct { uint16 neighborAddress; //相邻地址 uint16 panId; //所属的PAN网络ID linkInfo_t linkInfo; //连接信息（包括发送/接收和安全帧计数） } neighborEntry_t; 6、路由发现表的元素结构rtDiscEntry_t; typedef struct { byte rreqId; //接收请求ID

ZigBee 协议架构

根据应用和市场需要定义了ZigBee 协议的分层架构，其协议的体系结构如图1 所示，其中物理层（physical layer，PHY）和媒介访问控制层（medium access control sub-layer,MAC）是由IEEE802.15.4-2003 标准定义的，在这个底层协议的基础上ZigBee 联盟定义了网络层（network layer,PHY）和应用层（application layer,APL）架构. 图1 zigbee协议栈体系结构物理层规范物理层定义了它与MAC 层之间的两个接口：数据服务接口PD-SAP 和管理服务接口PLME-SAP，其中PD-SAP 接口还为物理层提供了相应的数据服务，负责从无线物理信道上收发数据，而PLME-SAP 接口同时为物理层提供相应的管理服务，用于维护一个由物理层相关数据组成的数据库。物理层负责数据的调制、发送和接收、空闲信道评估（clear channel assessment,CCA）信道能量的监测（energy detect,ED）和链接质量指示（link quality indication，LQI）等。物理层帧结构由同步头、物理层帧头和物理层有效载荷三部分组成，如表1 所示。

同步头又包括32bit 的前同步码和8bit 的帧定界符，前同步码用来为数据收发提供码元或数据符号的同步；帧界定符用来标识同步域的结束及数据的开始。物理层帧头包括7bit 的帧长度和1bit 的预留位，帧长度定义了物理层净荷的字节数。物理层有效载荷就是MAC层的帧内容。表一物理层帧格式媒体接入控制层规范 MAC 层定义了它与网络层之间的接口，包括提供给网络层的数据服务接口MLDE-SAP 和管理服务接口MLME-SAP，同时提供了MAC 层数据服务和MAC 层管理服务。MAC层数据服务主要实现数据帧的传输；MAC 层管理服务主要负责媒介访问控制、差错控制等。 MAC 层主要功能包括以下几个方面：（1）ZigBee 协调器产生网络信标（2）设备与信标同步（3）支持节点加入或着退出操作（4）信道接入方式采用免冲突载波检测多路访问（CSMA-CA）机制（5）建立并维护保护时隙机制（6）为设备提供安全支持 MAC 帧格式由三个基本部分组成：MAC 帧头、MAC 帧载荷和MAC 帧尾。不同类型的MAC 帧，其帧头和帧尾都是一样的，只是MAC 帧载荷有差别，通用MAC 帧格式如表2所示。表二通用MAC帧格式网络层规范网络层定义了它与应用层之间的接口，包括提供给应用层的数据服务接口NLDE-SAP和管理服务接口NLME-SAP , 同时提供了网络层数据服务和网络层管理服务。网络层主要负责拓扑结构的建立和网络的维护，具体的功能如下：（1）初始化网络，即建立一个新的包含协调器、路由器和终端设备的网络（2）设备连接和断开时所采用的机制（3）对一跳邻居节点的发现和相关节点信息的存储（4）ZigBee 协调器和路由器为新加入节点分配短地址

Zigbee技术主流芯片比较 2概况

Zigbee技术主流芯片调研 1、Zigbee芯片调研当今市场已有大量集成Zigbee协议和射频电路的芯片。以下是市场上主流的生成Zigbee的公司及其生产的典型Zigbee芯片。公司TI FREESCALE ATMEL Nordic 芯片CC2530 MC1321 AT86RF230 nRF24E1/nRF9E5 MCU内核8051 HCS08 无（通过SPI接口由外接MCU连接） 8051 通过在淘宝上的调查，TI公司的CC2530和FREESCALE的MC1321用户量比较大，有大量的公司提供基于这两款芯片的Zigbee模块，使用这些模块可以减少大量的硬件调试工作，而较容易的实现我们所需的传输功能。以下就这两类主流芯片进行详细介绍。 1.1 CC2530调研 CC2530是市场最主流的Zigbee芯片，TI公司推出的ZIGBEE网络处理器，将复杂的ZIGBEE网络协议栈，处理成了简单的用户接口命令，用户只要使用任何简单的单片机（微控制器），就可以容易的实现对ZIGBEE网络的控制；TI推出这个芯片的目的，就是希望ZIGBEE容易被使用。CC2530是TI公司推出的最新一代ZigBee标准芯片，适用于2.4GHz、IEEE802.15.4、ZigBee和 RF4CE应用。 CC2530包括了极好性能的一流RF收发器，工业标准增强性8051MCU，系统中可编程的闪存，8KB RAM以及许多其它功能强大的特性，可广泛应用在2.4-GHzIEEE802.15.4系统，RF4CE遥控制系统，ZigBee系统，家庭/建筑物自动化，照明系统，工业控制和监视，低功耗无线传感器网络，消费类电子和卫生保健。主要参数如下：

ZigBEE RF4CE规范基本概念及配对详细讲解

一．节点的安装初始化 1.1建立网络的过程 (1)目标节点：首先，扫描信道，对各个信道进行能量检测，选择可允许能量水平的信道进行操作。然后，发送执行活动的扫描操作，识别其他在工作在所选信道上的属于其他PAN网络的identifiers，允许一个统一的PAN identifier接入它的网络。最后，目标节点运行常规功能。 (2)控制节点：接入网络之后，运行常规功能。二.网络帧结构 Frame control：控制信息 Frame counter：技术，防止重复和延时攻击 Profile identifier：应用帧的传输格式 Vendor identifier：供应商标识符，允许商家进行扩展 Frame payload：传输的应用层数据 Message integrity code：进行认证（安全）三.传输选项四.发现（Discovery）发现服务必须是在非节能模式下才能进行。节点通过执行发现服务，来寻找能够进行配对的节点；发现服务会在一个固定的期间内在三个PAN网络中重复的进行，直到收到所有的应答。在此期间，设备之间会交换如下信息： Node capabilities：节点的类型（目标节点或控制节点），节点的供电类型，是否支持

安全性。 Vendor information：ZigBee RF4CE提供一个Vendor identifier或者vender string 来制定一个特定的供应商标识。 Application information：用户自定义一个字符串用来描述节点的应用功能（例如Lounge TV），一个设备类型列表可以制定哪些类型的设备室被支持的（例如一个综合性设备可能同时支持TV和DVD的功能），profile identifier列表制定该节点支持哪些类型的profiles。 Requested device type：discovery期间可以被请求的设备类型（比如一个多功能遥控器可能寻找TV的功能）。五、频率捷变（1）目标节点可以根据3个信道的变化，更换信道。（2）控制节点会记录目标节点的信道，当目标节点信道发生改变时，控制节点会尝试从其他信道发送给目标节点，直到目标节点发送确认信息；之后，控制节点会记录上新的信道。六、配对在发现期间，当节点确定在它的通信范围有其他能够提供稳定服务的节点时，可以通过建立配对从而进行通信。在RC网络中在存在配对的发送端和接收端之间只能直接通信。配对连接可以建立在应用层的要求上，通过交换类似于discovery期间交换的消息。目标节点可以选择是否接受配对并发送请求配对信息给源节点。配对成功后，源节点和目标节点会在它们各自的配对表中存储配对链接。这个使得源节点可以和目标节点通信，目标节点也可以和源节点通信。在配对表中的实体包含网络层传输信息给目标节点的所有信息。这消除了寻址的负担，要实现和相应设备的通信，应用层可以简单的提供一个链接配对表的index。配对表中的每个实体包含的信息如下： Pairing reference Source network address Destination logical channel Destination IEEE address Destination PAN identifier Destination network address Recipient nod capabilities Recipient frame counter Secutity link key

Zigbee协议栈原理基础

1Zigbee协议栈相关概念 1.1近距离通信技术比较：近距离无线通信技术有wifi、蓝牙、红外、zigbee，在无线传感网络中需求的网络通信恰是近距离需求的，故，四者均可用做无线传感网络的通信技术。而，其中（1）红外（infrared）：能够包含的信息过少；频率低波衍射性不好只能视距通信；要求位置固定；点对点传输无法组网。（2）蓝牙（bluetooth）：可移动，手机支持；通信距离10m；芯片价格贵；高功耗（3）wifi：高带宽；覆盖半径100m；高功耗；不能自组网；（4）zigbee:价格便宜；低功耗；自组网规模大。?????WSN中zigbee通信技术是最佳方案，但它连接公网需要有专门的网关转换→进一步学习stm32。 1.2协议栈协议栈是网络中各层协议的总和，其形象的反映了一个网络中文件传输的过程：由上层协议到底层协议，再由底层协议到上层协议。 1.2.1Zigbee协议规范与zigbee协议栈 Zigbee各层协议中物理层（phy）、介质控制层（mac）规范由IEEE802.15.4规定，网络层（NWK）、应用层（apl）规范由zigbee联盟推出。Zigbee联盟推出的整套zigbee规范：2005年第一版ZigBeeSpecificationV1.0，zigbee2006，zigbee2007、zigbeepro zigbee协议栈：很多公司都有自主研发的协议栈，如TI公司的：RemoTI，Z-Stack，SimpliciTI、freakz、msstatePAN 等。 1.2.2z-stack协议栈与zigbee协议栈 z-stack协议栈与zigbee协议栈的关系：z-stack是zigbee协议栈的一种具体实现，或者说是TI公司读懂了zigbee 协议栈，自己用C语言编写了一个软件—---z-stack，是由全球几千名工程师共同开发的。ZStack-CC2530-2.3.1-1.4.0软件可与TI的SmartRF05平台协同工作，该平台包括MSP430超低功耗微控制器(MCU)、CC2520RF收发器以及CC2591距离扩展器，通信连接距离可达数公里。 Z-Stack中的很多关键的代码是以库文件的形式给出来，也就是我们只能用它们，而看不到它们的具体的实现。其中核心部分的代码都是编译好的，以库文件的形式给出的，比如安全模块，路由模块，和Mesh自组网模块。与z-stack 相比msstatePAN、freakz协议栈都是全部真正的开源的，它们的所有源代码我们都可以看到。但是由于它们没有大的商业公司的支持，开发升级方面，性能方面和z-stack相比差距很大，并没有实现商业应用，只是作为学术研究而已。还可以配备TI的一个标准兼容或专有的网络协议栈（RemoTI，Z-Stack，或SimpliciTI）来简化开发,当网络节点要求不多在30个以内，通信距离500m-1000m时用simpliciti。 1.2.3IEEE802.15.4标准概述 IEEE802.15.4是一个低速率无线个人局域网(LowRateWirelessPersonalAreaNetworks，LR-WPAN)标准。定义了物理层(PHY)和介质访问控制层(MAC)。 LR-WPAN网络具有如下特点： ◆实现250kb/s，40kb/s，20kb/s三种传输速率。 ◆支持星型或者点对点两种网络拓扑结构。 ◆具有16位短地址或者64位扩展地址。 ◆支持冲突避免载波多路侦听技术(carriersensemultipleaccesswithcollisionavoidance，CSMA/CA)。（mac层） ◆用于可靠传输的全应答协议。(RTS-CTS) ◆低功耗。 ◆能量检测(EnergyDetection，ED)。 ◆链路质量指示(LinkQualityIndication，LQI)。 ◆在2.45GHz频带内定义了16个通道；在915MHz频带内定义了10个通道；在868MHz频带内定义了1个通道。为了使供应商能够提供最低可能功耗的设备，IEEE(InstituteofElectricalandElectronicsEngineers，电气及电子工程师学会)定义了两种不同类型的设备：一种是完整功能设备(full．functionaldevice，FFD)，另一种是简化功能设备

zigbee,ha协议标准

竭诚为您提供优质文档/双击可除 zigbee,ha协议标准篇一：zigbee3.0协议姗姗来迟,首批产品已经推出 zigbee3.0姗姗来迟，顶尖产品已经推出 zigbee联盟(zigbeealliance)今天宣布，将其市场领先的无线标准统一成名为zigbee3.0的单一标准。该标准将为最广泛的智能设备提供互操作性，让消费者和企业能获得可无缝协作并为人们日常生活带来便利的创新产品与服务。当今有数以千万的设备采用了zigbee标准，为消费者带来极大好处，zigbee3.0的发布让这些标准得以统一。zigbee3.0标准让用于家庭自动化、连接照明和节能等领域的设备具备通信和互操作性，因此产品开发商和服务提供商可以打造出更加多样化、完全可互操作的解决方案。开发商可以用新标准来定义目前基于zigbeepRo标准的所有设备类型、命令和功能。飞利浦(philips)互联照明部营销与合作关系主管Filipjandepauw表示：“让消费者满意是飞利浦hue智能照明系统的核心驱动力。消费者希望他们的智能设备简单好用，因此我们会继续带来容易控制和创造的更加丰富的照明新

体验。zigbee协议是实现这一目标的关键推动力，覆盖更广泛的zigbee3.0标准进一步实现了不同设备间的无缝通信，从而使我们能够为用户提供更强大的功能。更广泛的互操作性让创造新的用例和提升消费者满意度变得更简单。” zigbee3.0覆盖了最广泛的设备类型，包括家庭自动化、照明、能源管理、智能家电、安全装置、传感器和医疗保健监控产品。它同时支持易于使用的diy设备以及专业安装系统。基于ieee802.15.4标准、工作频率为2.4ghz(全球通用频率)的zigbee3.0使用zigbeepRo网络，以便为最小、功耗最低的设备提供可靠通信。目前基于zigbeehomeautomation(家庭自动化)和zigbeelightlink的zigbeecertified认证产品可与zigbee3.0互操作。欲查看统一成zigbee3.0的标准的完整列表，请访问官网 /retype/zoom/1b4a9975eff9aef8941e06f5pn=2&x=0&y=126 8&raww=561&rawh=20&o=png_6_0_0_135_299_631_23_892.9 79_1262.879&type=pic&aimh=17.112299465240643&md5sum =0e396de6e9a428054feedca137422c24&sign=dc869e5ba0&z oom=&png=2119-5028&jpg=0-0"target="_blank">点此查看j.m.Richardson说：“zigbee联盟一直认为，真正的互操作性来自于各个级别尤其是跟用户关系最为密切的应用级的标准。联盟成员在从全球产品销售中总结的经验教训让

zigbee各版本规范比较

ZigBee各版本规范比较 ZigBee是ZigBee联盟建立的技术标准，它是一种工作在900MHZ和2.4GHZ频段的新兴无线网络技术，具有中等通讯距离（10米到数百米），比较灵活经济的通讯速率（40Kbps到250Kbps），并且有星状，网状（MESH），树状等多种网络拓扑，低的功耗等特点，所以在当今无线通讯技术和无线网络技术领域中占有比较重要的地位。第一个ZigBee协议栈规范于2004年12月正式生效，称为ZigBee 1.0或ZigBee 2004。第二个ZigBee协议栈规范于2006年12月发布，称为ZigBee 2006规范，主要是用“群组库（cluster library）”替换了ZigBee 2004中的MSG/KVP结构。最为重要的新的ZigBee 2006协议栈将不兼容原来的ZigBee 2004技术规范，对于已经投入ZigBee 2004的厂商而言，这是一个大悲剧。例如Jennic 公司将ZigBee2004协议栈固化在ROM中（JN5121/JN5139）。将无法和ZigBee 2006以后的协议栈兼容。ZigBee 2006协议栈，将是ZigBee兼容的一个战略分水岭，从这里开始，ZigBee将实现完全向后兼容性。 2007年10月发布了ZigBee 2007规范，ZigBee 2007规范定于了两套高级的功能指令集（feature set）：分别是ZigBee功能命令集和ZigBee Pro功能命令集。（ZigBee 2004和2006都不兼容这两套新的命令集）。ZigBee 2007包含两个协议栈模板（profile）,一个是ZigBee协议栈模板(Stack Profile 1)，它是2006年发布的，目标是消费电子产品和灯光商业应用环境，设计简单，使用在少于300个节点的网络中。另一个是ZigBee Pro协议栈模板 (Stack Profile 2)，它是在2007年发布，目标是商业和工业环境，支持大型网络，1000个以上网络节点，相应更好的安全性。ZigBee Pro提供了更多的特性，比如：多播、多对一路由和SKKE（Symmetric-key key establishment）高安全，但ZigBee（协议栈模板1）在内存和flash中提供了一个比较小的区域。两者都提供了全网状网络与所有的ZigBee应用模板工作。 ZigBee 2007 是向后完全兼容ZigBee 2006设备。ZigBee 2007设备可以加入一个ZigBee 2006网络，并能再ZigBee 2006网络中运行，反之亦然。由于路由选择不同，ZigBee Pro设备必须变成非路由ZigBee End-Devices（ZEDs）设备才可加入ZigBee 2006或ZigBee 2007网络。同样ZigBee 2006或ZigBee 2007设备必须变成ZEDs才可加入ZigBee Pro 网络。在这些设备上的应用程序工作是相同的，它们不管在这些设备上的协议栈模板。下面的图表从高层次进行比较，列出2004、2006及2007/PRO ZigBee规范之间的异同。比较图

zigbee技术分析——经典

与蜂共舞—ZigBee技术一瞥本文从ZigBee的发展历史入手，探讨了这种基于无线传感器技术的网络应用的协议栈、性能分析和各种应用领域，全面构建了完整的ZigBee技术应用与发展蓝图。 “ZigBee”是什么?从字面上猜像是一种蜜蜂。因为“ZigBee”这个词由“Zig”和“Bee”两部分组成，“Zig”取自英文单词“zigzag”，意思是走“之”字形，“bee”英文是蜜蜂的意思，所以“ZigBee”就是跳着“之”字形舞的蜜蜂。不过，ZigBee 并非是一种蜜蜂，事实上，它与蓝牙类似是一种新兴的短距离无线通信技术，国内也有人翻译成“紫蜂”。下面就让我们一起进入这只蜜蜂的世界，与蜂共舞吧! 这只蜜蜂的来头还是要从它的历史开始说起，早在上世纪末，就已经有人在考虑发展一种新的通信技术，用于传感控制应用(sensor and control)，这个想法后来在IEEE 802.15工作组当中提出来，于是就成立了TG4工作组，并且制定了规范IEEE 802.15.4。但是IEEE 802的规范只专注于底层，要达到产品的互操作和兼容，还需要定义高层的规范，于是2002年ZigBee Alliance成立，正式有了“ZigBee”这个名词。两年之后，ZigBee的第一个规范ZigBee V1.0诞生，但这个规范推出的比较仓促，存在一些错误，并不实用。此后ZigBee Alliance又经过两年的努力，推出了新的规范ZigBee 2006，这是一个比较完善的规范。据联盟最新的消息，今年年底将会发布更新版本的规范ZigBee 2007，这个版本增加了一些新的特性。从ZigBee的发展历史可以看到，它和IEEE 802.15.4有着密切的关系，事实上ZigBee的底层技术就是基于IEEE 802.15.4的，因此有一种说法认为ZigBee和IEEE 802.15.4是同一个东西，或者说“ZigBee”只是IEEE 802.15.4的名字而已，其实这是一种误解。实际上ZigBee和IEEE 802.15.4的关系，有点类似于WiMAX和IEEE 802.16，Wi-Fi和IEEE 802.11，Bluetooth和IEEE 802.15.1。“ZigBee”可以看作是一个商标，也可以看作是一种技术，当把它看作一种技术的时候，它表示一种高层的技术，而物理层和MAC层直接引用IEEE 802.15.4。事物是不断的发展变化的，尤其是通信技术，可以想象将来的ZigBee可能不会使用IEEE 802.15.4定义的底层，就跟蓝牙(Bluetooth)宣布下一代底层采用UWB技术一样，但是“ZigBee”这个商标以及高层的技术还会继续保留。 ZigBee协议栈速读我们无法预料将来ZigBee会基于怎样的底层技术，只好从它现在的底层——IEEE 802.15.4开始了解，IEEE 802.15.4包括物理层和MAC层两部分。ZigBee工作在三种频带上，分别是用于欧洲的868MHz频带，用于美国的915MHz频带，以及全球通用的2.4GHz频带，但这三个频带的物理层并不相同，它们各自的信道带宽分别是0.6MHz, 2MHz和5MHz，分别有1个，10个和16个信道。不同频带的扩频和调制方式也有所区别，虽然都使用了直接序列扩频(DSSS)的方式，但从比特到码片的变换方式有比较大的差别;调制方面都使用了调相技术，但868MHz和915MHz频段采用的是BPSK，而2.4GHz频段采用的是OQPSK。我们可以以2.4GHz频段为例看看发射机基带部分的框图(如图1)，可以看到物理层部分非常简单，而IEEE 802.15.4芯片的低价格正是得益于底层的简单性。可能我们会担心它的性能，但我们可以再看看它和Bluetooth/IEEE 802.15.1以及WiFi/IEEE 802.11的性能比较(如图2)，

zigbee解决方案比较

Zigbee 解决方案总结一．非开源协议栈 1.freescale 解决方案协议栈种类： 1.1 80 2.15.4标准mac 1.2 SMAC 1.3 SynkroRF 1.4 ZigBee RF4CE 1.5 ZigBee 2007 最简单的就是SMAC，是面向最简单的点对点应用的，不涉及网络的概念；其次是IEEE802.15.4，一般用来组建简单的星型网络，而且提供了源代码，可以清楚地看到网络连接的每个步骤，分别调用了哪些函数； BeeStack（符合zigbee 2007）是提供的最复杂的协议栈，但是看不到代码，它提供给你一些封装好的函数，比如创建网络函数，你直接调用它，协调器就把网络创建好了，终端节点调用它则寻找可以加入的ZigBee网络并尝试加入。其中硬件平台可以为下面中的任一种： MC13202 （2.4 GHz射频收发器） MC13213 （2.4 GHz射频收发器和带60K闪存的8位MCU）MC13224V （2.4 GHz平台级封装(PIP) –带有128KB闪存、96KB RAM、80KB ROM的32位TDMI ARM7处理器） MC13233 （带有HCS08 MCU的2.4 GHz片上系统） MC13202没有自带mcu，在做应用时，需要用户在自己的扩展板上加上mcu，既需要实现对外围设备的底层控制，也需要实现

协议栈。下面的几种均有自带mcu，协议栈的实现在自带的mcu 上实现，功能较简单的可直接使用片上的mcu资源进行控制；功能复杂的应用，最好协议栈实现与外围控制分开，大多数应用都选择arm芯片作为控制芯片；详细信息可以查看https://www.wendangku.net/doc/ba11930384.html,/products/rf/ZigBee.asp 2.microchip 解决方案协议栈种类： ZigBee? Smart Energy Profile (SEP) Suite ZigBee? PRO ZigBee? RF4CE 均是一整套的协议集，价格不菲；硬件平台: Pic18(mcu)+MRF24J40（2.4GHZ 射频收发器）+天线与freescale 的mc13202相似，MRF24J40也只是射频收发器，不包含mcu，协议栈的实现需要借助于外围的mcu,当然微芯公司选择的是pic18及以上的芯片作为其主控mcu，通过spi接口与MRF24J40通信，查询其寄存器的状态，实现协议栈功能。详见：https://www.wendangku.net/doc/ba11930384.html,/ 3.ST 意法半导体解决方案协议栈： EMZNET ZigBee? protocol stack 硬件平台：

Zigbee网关通信协议

Z i g b e e网关通信协议 Prepared on 24 November 2020

无线传感器网络（Zigbee）网关的的通信协议网关是通过串口与PC 机相连的。PC 机可以通过串口发送采集命令和收集采集数据,为了能有效管理这些数据,需要执行统一的数据通信格式。下面介绍该系统中所使用的通用数据格式。每一帧数据都采用相同的帧长度,且都带有帧头、数据和帧尾。具体格式如下: 如上所示,每一帧数据的长度都是32字节。除帧头和帧尾,每一帧数据都由命令头、发送地址、有效数据和校验和组成。命令头:所执行的命令。地址:所访问模块的长(前8字节)/短地址(后2字节)。数据:传送各个参数、变量与返回值及各种需要突发发送的数据。校验和:从命令头到数据尾的加和校验,用于确定数据正确与否。注:命令头、地址的长地址部分和数据都采用ASCII码。这个系统的命令分为3种,分别为读命令R(ead):包括读各个传感器或网络状态命令。测试命令T(est):测试LED、BEEP或电池寿命命令。扩展板命令E(xtend):控制和读扩展板命令。下面介绍具体命令格式。 1.读命令 1) RAS RAS(ReadallSensor):读传感器。

RAS具体格式如下: 需要加入地址和数据——地址:传感器模块地址;数据:GM***/WD***。传感器种类包括光敏:GM;温度:WD;可调电位器:AD。 (1)读取成功返回格式如下: 地址:加入传感器模块地址。数据:传感器+ 测量值(ASSII码)。其中光敏:GM+ * * * (3 字节ASII码);温度:WD +***(3字节ASII码);可调电位器:AD+*** (3字节ASII码)。 (2)读取失败返回格式如下: 2) RND RND:无线网络发现。 RND 具体格式如下: 需要加入地址和数据———地址:无;数据:无,只需要命令头。(1)读取成功返回格式如下: 返回网络中节点的性质:RFD(终端节点)/ROU(路由器)+地址+第几个。例如:如果返回第1个RFD 节点,则数据段为RFD01。具体格式如下： (2)读取成功结束格式如下: 2.测试命令 1) TLD

F8913 ZigBee 技术规范

F8913 ZigBee 模块技术规范产品特点---------------------------------------------------------------------------------------------------- 简介 F8913 ZigBee 模块是一种物联网无线数据终端，利用ZigBee 网络为用户提供无线数据传输功能。该产品采用高性能的工业级ZigBee 方案，以嵌入式实时操作系统为软件支撑平台，同时提供2.0的SMA 与DIP 接口，可直接连接TTL 串口设备，实现数据透明传输功能；低功耗设计，最低功耗小于1mA ；提供17路I/O ，可实现数字量输入输出、脉冲输出；提供5路ADC ，模拟量输入、脉冲计数等功能。该产品已广泛应用于物联网产业链中的M2M 行业，如智能电网、智能交通、智能家居、金融、移动POS 终端、供应链自动化、工业自动化、智能建筑、消防、公共安全、环境保护、气象、数字化医疗、遥感勘测、军事、空间探索、农业、林业、水务、煤矿、石化等领域。文档编号文档版本密级工业级应用设计 ◆ 采用高性能工业级ZigBee 处理芯片 ◆ 低功耗设计，支持多级休眠和唤醒模式，最大限度降低功耗 ◆ 采用2.0的SMA 与DIP 双排接口，较适合客户的需求。 ◆ 电源输入（DC 3.0～3.6V ）稳定可靠 ◆ WDT 看门狗设计，保证系统稳定 ◆ 提供TTL 串行接口，SPI 接口。 ◆ 天线接口防雷保护（可选）标准易用 ◆ 采用2.0的SMA 与DIP 接口，特别适合于不同用户的应用需求。 ◆ 提供TTL 接口可直接连相同电压的TTL 串口设备 ◆ 智能型数据模块，上电即可进入数据传输状态 ◆ 使用方便，灵活，多种工作模式选择 ◆ 方便的系统配置和维护接口 ◆ 支持串口软件升级和远程维护功能强大 ◆ 支持ZigBee 无线短距离数据传输功能 ◆ 具备中继路由和终端设备功能 ◆ 支持点对点、点对多点、对等和Mesh 网络 ◆ 网络容量大：65000个节点 ◆ 节点类型灵活：中心节点、路由节点、终端节点可任意设置； ◆ 发送模式灵活：广播发送或目标地址发送模式可选 ◆ 通信距离大 ◆ 提供17路I/O ，可实现17路数字量输入输出；兼容10路脉冲输出、5路模拟量输入、5路脉冲计数功能

ZigBee协议架构

编号：_______________本资料为word版本，可以直接编辑和打印，感谢您的下载 ZigBee协议架构甲方：___________________ 乙方：___________________ 日期：___________________

(application layer,APL )架构. 图1 zigbee协议栈体系结构物理层规范物理层定义了它与MAC层之间的两个接口：数据服务接口PD-SAP和管理服务接口PLME-SAP其中PD-SAP接口还为物理层提供了相应的数据服务，负责从无线物理信道上收发数据,而PLME-SAPg口同时为物理层提供相应的管理服务，用丁维护一个由物理层相关数据组成的数据库。物理层负责数据的调制、发送和接收、空闲信道评估(clear channel assessment,CCA)信道能量的监测(energy detect,ED )和链接质量指示(link quality indication , LQI)等。物理层帧结构由同步头、物理层帧头和物理层*效载荷三部分组成，如表1所示。同步头乂包括32bit的前同步码和8bit的帧定界符，前同步码用来为数据收发提供码元或数据符号的同步；帧界定符用来标识同步域的结束及数据的开始。物理层帧头包括7bit的帧长度和1bit的预留位，帧长度定义了物理层净荷的字节数。物理层有效载荷就是MAC层的帧内容。表一物理层帧格式

媒体接入控制层规范 MAC层定义了它与网络层之间的接口，包括提供给网络层的数据服务接口MLDE-SAFffi管理服务接口MLME-SAP同时提供了MAC层数据服务和MAC层管理服务。MA@数据服务主要实现数据帧的传输；MAC层管理服务主要负责媒介访问控制、差错控制等。 MAC层主要功能包括以下几个方面： (1) ZigBee协调器产生网络信标 (2) 设备与信标同步 (3) 支持节点加入或着退出操作 (4) 信道接入方式采用免冲突载波检测多路访问(CSMA-CA机制 (5) 建立并维护保护时隙机制 (6) 为设备提供安全支持 MAC帧格式由三个基本部分组成：MAC帧头、MAC帧载荷和MAC帧尾。不同类型的MAC帧，其帧头和帧尾都是一样的，只是MAC帧载荷有差别，通用MAC帧格式如表2所小。表二通用MA#格式网络层规范网络层定义了它与应用层之间的接口 ,包括提供给应用层的数据服务接口 NLDE-SAP管理服务接口NLME-SAP，同时提供了网络层数据服务和网络层管理服务。网络层主要负责拓扑结构的建立和网络的维护，具体的功能如下： (1) 初始化网络，即建立一个新的包含协调器、路由器和终端设备的网络 (2) 设备连接和断开时所采用的机制 (3) 对一跳邻居节点的发现和相关节点信息的存储 (4) ZigBee协调器和路由器为新加入节点分配短地址（5）确保MAC正常工作，并且为应用层提供合适的服务接口网络层帧结构包括网络层帧头（Network header, NHR和网络层载荷（Network payload,NPL）两部分，其中网络层帧头域由帧控制域、目的设备地址、源设备地址、广播半径和广播序列号等部分组成，通用网络帧的结构如表3所示。表3通用网络层帧结构

zigbee芯片与zigbee模块的区别和优缺点对比

zigbee芯片与zigbee模块的区别和优缺点对比 ZigBee在个人网络中越来越被称为短距离无线通信协议。它的最大特点是具有低功耗，低网络，特别是可路由的网络功能，并且在理论上可以无限扩展ZigBee期望的通信范围。对于蓝牙，红外点对点通信和WLAN星型通信，ZigBee协议要复杂得多。因此，我应该选择ZigBee芯片自行开发协议，还是应该直接选择具有ZigBee协议的模块直接应用？芯片研发：需要足够的人力和技术储备以及长时间的开发市场上的ZigBee无线收发器“芯片”实际上是符合物理层标准的芯片。因为它仅调制和解调无线通信信号，所以必须将其与单片机结合使用以完成数据收发器和协议的实现。另一方面，单片机仅集成了射频部分和单片机部分，并且不需要额外的单片机。它的优点是节省成本和简化电路。在这两种情况下，用户都需要自己通过微控制器的结构和寄存器的设置自行开发所有软件部分，还要参考物理层部分的IEEE802.15.4协议和网络层部分的ZigBee协议。对于实际应用用户而言，这种工程量很大，开发周期和测试周期都非常长，并且由于它是无线通信产品，因此不容易保证其产品质量。目前，许多ZigBee公司都在提供自己的芯片ZigBee协议栈，它仅提供该协议的功能，并不意味着它具有真正的适用性和可操作性。没有提供用户数据界面的详细描述。用户为什么可以忽略芯片中的程序，而只使用芯片来传输自己的数据？这不仅可以简单地实现包含ZigBee协议栈的芯片，也不能仅实现包含ZigBee协议栈的芯片。所有这些都要求用户基于完整的协议代码和他们自己的上层通信协议，完整的简单

数据无线发送和接收，完整的路由，完整的网络通信以及调试步骤，来修改协议栈的内容。因此，对于实际应用的用户来说，开发周期大大延迟了，具有如此复杂协议的无线产品具有更多不确定因素，并且容易受到外部环境条件的影响。实际的发展问题是多种多样的，难以解决。模块生产的成本通过节省ZigBee开发周期，或许可以抓住项目推广的第一个机会。ZigBee模块已经包括所有外围电路和完整的协议栈。这是一种即用型产品。经过制造商的优化设置修订和老化测试，具有一定的质量保证。出色且可靠的zigBee应用程序“模块”紧凑，硬件小巧，具有芯片焊盘设置校正功能，能够内置芯片和外部SMA天线，通信距离范围为100米至1200米。该软件包括完整的ZigBee协议栈。它在PC上具有自己的部署工具。它可以使用串行端口与用户的产品通信并部署模块的网络拓扑参数，例如发射功率和信道，使用方便快捷。透传模块的优点在于，用户无需考虑其程序的工作方式，只要用户通过串行端口将其数据发送到模块，模块就会根据预设的网络自动无线传输数据结构体。

Zigbee协议栈中文说明免费

Zigbee协议栈中文说明 1.概述 1.1解析ZigBee堆栈架构 ZigBee堆栈是在IEEE 802.15.4标准基础上建立的，定义了协议的MAC和PHY层。ZigBee设备应该包括IEEE802.15.4(该标准定义了RF射频以及与相邻设备之间的通信)的PHY和MAC层，以及ZigBee堆栈层：网络层(NWK)、应用层和安全服务提供层。图1-1给出了这些组件的概况。 1.1.1ZigBee堆栈层每个ZigBee设备都与一个特定模板有关，可能是公共模板或私有模板。这些模板定义了设备的应用环境、设备类型以及用于设备间通信的簇。公共模板可以确保不同供应商的设备在相同应用领域中的互操作性。设备是由模板定义的，并以应用对象(Application Objects)的形式实现(见图1-1)。每个应用对象通过一个端点连接到ZigBee堆栈的余下部分，它们都是器件中可寻址的组件。图1-1 zigbe堆栈框架从应用角度看，通信的本质就是端点到端点的连接(例如，一个带开关组件的设备与带一个或多个灯组件的远端设备进行通信，目的是将这些灯点亮)。端点之间的通信是通过称之为簇的数据结构实现的。这些簇是应用对象之间共享信息所需的全部属性的容器，在特殊应用中使用的簇在模板中有定义。图1-1-2就是设备及其接口的一个例子：

图1-1-2 每个接口都能接收(用于输入)或发送(用于输出)簇格式的数据。一共有二个特殊的端点，即端点0和端点255。端点0用于整个ZigBee设备的配置和管理。应用程序可以通过端点0与ZigBee 堆栈的其它层通信，从而实现对这些层的初始化和配置。附属在端点0的对象被称为ZigBee 设备对象 (ZD0)。端点255用于向所有端点的广播。端点241到254是保留端点。所有端点都使用应用支持子层(APS)提供的服务。APS通过网络层和安全服务提供层与端点相接，并为数据传送、安全和绑定提供服务，因此能够适配不同但兼容的设备，比如带灯的开关。APS使用网络层(NWK)提供的服务。NWK负责设备到设备的通信，并负责网络中设备初始化所包含的活动、消息路由和网络发现。应用层可以通过ZigBee设备对象(ZD0)对网络层参数进行配置和访问。 1.1.2 80 2.15.4 MAC层 IEEE 802.15.4标准为低速率无线个人域网(LR-WPAN)定义了OSI模型开始的两层。PHY层定义了无线射频应该具备的特征，它支持二种不同的射频信号，分别位于2450MHz波段和868/915MHz 波段。2450MHz波段射频可以提供250kbps的数据速率和16个不同的信道。868 /915MHz波段中，868MHz支持1个数据速率为20kbps的信道，915MHz支持10个数据速率为40kbps的信道。MAC层负责相邻设备间的单跳数据通信。它负责建立与网络的同步，支持关联和去关联以及MAC 层安全：它能提供二个设备之间的可靠链接。 1.1.3 关于服务接入点 ZigBee堆栈的不同层与802.15.4 MAC通过服务接入点(SAP)进行通信。SAP是某一特定层提供的服务与上层之间的接口。 ZigBee堆栈的大多数层有两个接口：数据实体接口和管理实体接口。数据实体接口的目标是向上层提供所需的常规数据服务。管理实体接口的目标是向上层提供访问内部层参数、配置和管理数据的机制。 1.1.4 ZigBee的安全性安全机制由安全服务提供层提供。然而值得注意的是，系统的整体安全性是在模板级定义的，这意味着模板应该定义某一特定网络中应该实现何种类型的安全。每一层(MAC、网络或应用层)都能被保护，为了降低存储要求，它们可以分享安全钥匙。SSP是通过ZD0进行初始化和配置的，要求实现高级加密标准(AES)。ZigBee规范定义了信任中心的用途。信任中心是在网络中分配安全钥匙的一种令人信任的设备。 1.1.5 ZigBee堆栈容量和ZigBee设备根据ZigBee堆栈规定的所有功能和支持，我们很容易推测ZigBee堆栈实现需要用到设备中的大量存储器资源。不过ZigBee规范定义了三种类型的设备，每种都有自己的功能要求：ZigBee

ZIGBEE主要竞争对手分析

ZIGBEE主要竞争对手分析一．ZIGBEE无线技术一鸣惊人 Zigbee是一种崭新的,专注于低功耗、低成本、低复杂度、低速率的近程无线网络通信技术。也是目前嵌入式应用的一个大热点。 Zigbee的特点主要有以下几个方面： 1．低功耗。在低耗电待机模式下，2节5号干电池可支持1个节点工作6~24个月，甚至更长。这是Zigbee的突出优势。相比较，蓝牙能工作数周、Wi-Fi可工作数小时。 2．低成本。通过大幅简化协议（不到蓝牙的1/10），降低了对通信控制器的要求，按预测分析，以8051的8位微控制器测算，全功能的主节点需要32KB代码，子功能节点少至4KB代码，而且Zigbee免协议专利费。 3．低速率。Zigbee工作在250kbps的通讯速率，满足低速率传输数据的应用需求。 4．近距离。传输范围一般介于10～100m之间，在增加RF发射功率后，亦可增加到1~3km。这指的是相邻节点间的距离。如果通过路由和节点间通信的接力，传输距离将可以更远。 5．短时延。Zigbee的响应速度较快，一般从睡眠转入工作状态只需15ms，节点连接进入网络只需30ms，进一步节省了电能。相比较，蓝牙需要3~10 s、Wi-Fi需要 3 s。

6．高容量。Zigbee可采用星状、片状和网状网络结构，由一个主节点管理若干子节点，最多一个主节点可管理254个子节点；同时主节点还可由上一层网络节点管理，最多可组成65000个节点的大网。 7．高安全。Zigbee提供了三级安全模式，包括无安全设定、使用接入控制清单 (ACL)防止非法获取数据以及采用高级加密标准 (AES128)的对称密码，以灵活确定其安全属性。 8．免执照频段。采用直接序列扩频在工业科学医疗 2.4GHz(全球) (ISM)频段。 ZIGBEEZ在2004年推出2004（ZIGBEE 1.0）的基础上，年前又推出了功能更加强大的ZIGBEE2006协议栈，增加了ZIGBEE PRO 扩展指令集，功能更加强大；据行家分析，ZIGBEE技术将在无线数传,无线传感器网络，无线实时定位，射频识别，数字家庭，安全监视, 无线键盘，无线遥控器，无线抄表,汽车电子,医疗电子,工业自动化等方面得到非常广阔的应用, 目前有个口号”WIRELESS ANY WHERE”,要实现这个口号的目标,Zigbee 技术的广泛应用 , 可能是一个重要的前提; 正是因为ZIGBEE具有广阔的市场前景,所以引来了全球众多厂商的青睐, 纷纷推出各种ZIGBEE无线芯片,无线单片机, ZIGBEE开发系统,形成了百花争艳的市场局面,这种局面,对应降低芯片价格,丰富ZIGBEE技术的应用软件,加快ZIGBEE技术普及,是大有好处的事情；