【转】ZigBee终端入网方式深入分析

前述

继之前对终端Direct Join的分析，发现很多东西还很模糊，存在很多问题。终于找到时间继续深入挖下去，这次应该比较完整地搞清了终端的入网机制，并纠正之前的几个认识偏差。

由于Z-Stack网络层并不开源，所以一些地方是靠的推测，很多地方的结论也没有实验验证，谨留给诸君参考和斧正。

ZigBee2007协议规范分析

先来看看ZigBee2007协议规范是怎样规定入网请求的：

The semantics of this primitive are as follows:
NLME-JOIN.request
{
ExtendedPANId,
RejoinNetwork,
ScanChannels,
ScanDuration,
CapabilityInformation,
SecurityEnable
}

The next higher layer of a device generates this primitive to request to:
– Join a network using the MAC association procedure.
– Join or rejoin a network using the orphaning procedure.
– Join or rejoin a network using the NWK rejoin procedure.
– Switch the operating channel for a device that is joined to a network.

就此原语的描述可以看出，前三种情况均为设备入网的方式，最后一个是为设备切换信道所用，暂不考虑。所以ZigBee设备入网有三种方式，我们分别称之为Join、Orphan Join、Rejoin。三种方式RejoinNetwork参数分别设置为0x00、0x01、0x02。

Join入网过程。首先发起Network Discovery，返回所有应答的节点的信息。在发现的结果中找出符合要求（这里的要求是一些最基本的条件，详见ZigBee协议规范3.6.1.4.1.1节，下同）的父节点，向它发送入网请求。父节点分配16位网络地址。
Rejoin入网过程。发起Network Discovery，在应答的节点中挑选出和自己的ExtendedPANID相同的节点，在这些节点中找出符合要求的父节点，发送入网请求，并且使用自己已拥有的16位网络地址（若没有，则随机生成一个）。
Orphan Join过程。发起Orphan Scan，寻找邻居表中保存有本设备IEEE地址的父节点，在返回结果中找出符合要求的父节点，发送入网请求。父节点返回邻居表中保存的16位网络地址。

可以看出三种入网的过程都可以归纳为网络扫描+选择目标。三者的选择的筛选条件是递增的：任何节点—>指定PANID的节点—>邻居表中有自己信息的节点。

Z-Stack协议栈分析

版本号：ZStack-CC2530-2.5.1a

1. 第一步扫描

下面是设备启动的函数ZDO_StartDevice，它是设备入网流程的入口，这个函数仅在ZDApp_event_loop事件轮询函数中发生ZDO_NETWORK_INIT事件的时候被调用，而ZDApp_NetworkInit函数就是用来延时发送ZDO_NETWORK_INIT事件的，所以ZDApp_NetworkInit函数也是设备入网过程的触发，这个函数下面将被用到。

这里我只把与终端启动的相关代码贴了出来：

/*********************************************************************
 * @fn          ZDO_StartDevice
 *
 * @brief       This function starts a device in a network.
 *
 * @param       logicalType     - Device type to start
 *              startMode       - indicates mode of device startup
 *
 * @return none */ void ZDO_StartDevice( byte logicalType, devStartModes_t startMode, byte beaconOrder, byte superframeOrder ) { ZStatus_t ret; ret = ZUnsupportedMode; if ( (startMode == MODE_JOIN) || (startMode == MODE_REJOIN) ) { devState = DEV_NWK_DISC; ret = NLME_NetworkDiscoveryRequest( zgDefaultChannelList, zgDefaultStartingScanDuration ); } else if ( startMode == MODE_RESUME ) //Orphan Join { devState = DEV_NWK_ORPHAN; ret = NLME_OrphanJoinRequest( zgDefaultChannelList, zgDefaultStartingScanDuration ); } if ( ret != ZSuccess ) { osal_start_timerEx(ZDAppTaskID, ZDO_NETWORK_INIT, NWK_RETRY_DELAY ); } }

从上面可以看出，终端的入网第一步就是调用了这两个函数NLME_NetworkDiscoveryRequest、
NLME_OrphanJoinRequest（放到第3步再看），而Join和Rejoin方式的这一部分是完全相同的。从TI的API手册中可以查到：

NLME_NetworkDiscoveryRequest()

此函数请求网络层寻找相邻路由器。这个函数应该在加入并执行网络扫描前调用。扫描确认结果将被返回到ZDO_NetworkDiscoveryConfirmCB()回调函数中。……

2. 扫描结果

在ZDO_NetworkDiscoveryConfirmCB()回调函数中发现，就做了一件事，就是向ZDApp_event_loop发送ZDO_NWK_DISC_CNF事件，直接找到ZDO_NWK_DISC_CNF事件的处理函数（为了方便分析，只留下了关键的函数名）：

case ZDO_NWK_DISC_CNF:
      if (devState != DEV_NWK_DISC)
        break;

      if ( ZG_BUILD_JOINING_TYPE && ZG_DEVICE_JOINING_TYPE ) { networkDesc_t *pChosenNwk; if ( ( (pChosenNwk = ZDApp_NwkDescListProcessing()) != NULL ) && (zdoDiscCounter > NUM_DISC_ATTEMPTS) ) { if ( devStartMode == MODE_JOIN ) { devState = DEV_NWK_JOINING; if ( NLME_JoinRequest( pChosenNwk->…… ) != ZSuccess ) { ZDApp_NetworkInit(…… ); } } else if ( devStartMode == MODE_REJOIN ) { devState = DEV_NWK_REJOIN; if ( _NIB.nwkDevAddress == INVALID_NODE_ADDR ) { // Before trying to do rejoin, // check if the device has a valid short address // If not, generate a random short address for itself } if ( _NIB.nwkPanId == INVALID_PAN_ID ) { // Check if the device has a valid PanID, // if not, set it to the discovered Pan } if ( NLME_ReJoinRequest( ……) != ZSuccess ) { ZDApp_NetworkInit( …… ); } } } else { if ( continueJoining ) { zdoDiscCounter++; ZDApp_NetworkInit( …… ); } } } break;

通过简化了的代码可以看出，对于扫描结果的处理是这样一个流程：首先需进行至少NUM_DISC_ATTEMPTS次扫描，每次都调用ZDApp_NetworkInit进行重新扫描，如果找到了合格的父节点（pChosenNwk = ZDApp_NwkDescListProcessing()) != NULL），就依照MODE_JOIN或 MODE_REJOIN 分别调用NLME_JoinRequest或NLME_ReJoinRequest向目标父节点发送请求。由于后者的请求中要附带自己的PANID和ShortAddress，所以要事先检查和处理。

从这里可以看出，不管是Join还是Rejoin，如果找不到可用的父节点，将持续调用ZDApp_NetworkInit扫描网络，陷入死循环。

3. 加入父节点

着眼到NLME_JoinRequest和NLME_ReJoinRequest，以及前面的NLME_OrphanJoinRequest上，从TI的API手册中可以查到：

NLME_OrphanJoinRequest()
此函数请求网络层孤立地连接到网络上。此函数是一个默示加入形式的扫描。此函数的结果（状态值）返回到ZDO_JoinConfirmCB()回调函数中。……

NLME_JoinRequest ()
此函数允许相邻的更高层请求设备将自己加入到一个网络中。此函数的结果（状态）返回到ZDO_JoinConfirmCB()回调函数中。……

NLME_ReJoinRequest ()
使用此函数重新加入一个设备已经加入过的网络。此函数的结果（状态）返回到ZDO_JoinConfirmCB()回调函数中。……

ZDO_JoinConfirmCB()一样只做了一件事，就是向ZDApp_event_loop发送事件ZDO_NWK_JOIN_IND。

下面是ZDO_NWK_JOIN_IND事件的处理函数ZDApp_ProcessNetworkJoin（已简化）：

void ZDApp_ProcessNetworkJoin( void )
{
if ( (devState == DEV_NWK_JOINING) ||
      ((devState == DEV_NWK_ORPHAN)  &&
       (ZDO_Config_Node_Descriptor.LogicalType == NODETYPE_ROUTER)) )
  {
    // Result of a Join attempt by this device.
    if ( nwkStatus == ZSuccess ) { osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT ); if ( devState == DEV_NWK_JOINING ) { ZDApp_AnnounceNewAddress(); } devState = DEV_END_DEVICE; } else { if ( (devStartMode == MODE_RESUME) && (++retryCnt >= MAX_RESUME_RETRY) ) { if ( _NIB.nwkPanId == 0xFFFF || _NIB.nwkPanId == INVALID_PAN_ID ) devStartMode = MODE_JOIN; else { devStartMode = MODE_REJOIN; _tmpRejoinState = true; } } /******************************/ /*some process*/ /******************************/ zdoDiscCounter = 1; ZDApp_NetworkInit( …… ); } } else if ( devState == DEV_NWK_ORPHAN || devState == DEV_NWK_REJOIN ) { // results of an orphaning attempt by this device if (nwkStatus == ZSuccess) { devState = DEV_END_DEVICE; osal_set_event( ZDAppTaskID, ZDO_STATE_CHANGE_EVT ); ZDApp_AnnounceNewAddress(); } else { if ( devStartMode == MODE_RESUME ) { if ( ++retryCnt <= MAX_RESUME_RETRY ) { if ( _NIB.nwkPanId == 0xFFFF || _NIB.nwkPanId == INVALID_PAN_ID ) devStartMode = MODE_JOIN; else { devStartMode = MODE_REJOIN; _tmpRejoinState = true; } } // Do a normal join to the network after certain times of rejoin retries else if( AIB_apsUseInsecureJoin == true ) { devStartMode = MODE_JOIN; } } // Clear the neighbor Table and network discovery tables. nwkNeighborInitTable(); NLME_NwkDiscTerm(); // setup a retry for later... ZDApp_NetworkInit( …… ); } } }

至此终端就完成了入网的全部流程，如果被父节点接受，那么入网成功；如果失败，则重新开始入网流程。

4. 提出问题

可以看出，函数中没有对失败时的Join方式或Rejoin方式做任何的处理，毫无疑问，两种方式下都将无限重试直到入网成功。并没有实现所谓的：

// Do a normal join to the network after certain times of rejoin retries

那么分析Orphan Join，而根据源代码的逻辑，如果是路由器（NODETYPE_ROUTER）执行Orphan Join，那么当重试次数超过MAX_RESUME_RETRY时，将根据是否搜索到了父节点（_NIB.nwkPanId == 0xFFFF || _NIB.nwkPanId == INVALID_PAN_ID），将入网方式重置为Join方式或Rejoin方式。那么针对Rejoin方式和终端（NODETYPE_DEVICE）的Orphan Join方式呢，很令人费解：

if ( devStartMode == MODE_RESUME )
{
  if ( ++retryCnt <= MAX_RESUME_RETRY )
  {
    if ( _NIB.nwkPanId == 0xFFFF || _NIB.nwkPanId == INVALID_PAN_ID )
      devStartMode = MODE_JOIN;
    else { devStartMode = MODE_REJOIN; _tmpRejoinState = true; } } // Do a normal join to the network after certain times of rejoin retries else if( AIB_apsUseInsecureJoin == true ) { devStartMode = MODE_JOIN; } }

不管怎样，失败的Orphan Join都将直接被置为Join或Rejoin，在这里条件（++retryCnt <= MAX_RESUME_RETRY）好像总是成立的。那么有没有可能是其他地方对retryCnt进行了修改，搜索遍整个工程，除了这个函数中有对retryCnt的+操作外，只有两处地方对retryCnt进行了赋值，一处是定义时的初始化，一处是断网重连，执行Orphan Join前对retryCnt的清零。

所以，对于终端来说，都只能执行一次Orphan Join，与宏定义MAX_RESUME_RETRY毫无关系。

这到底是TI有意为之，还是逻辑的Bug呢？这个问题有待日后解决。

转自：
https://www.cnblogs.com/yelin/p/6054611.html

【转】ZigBee终端入网方式深入分析

前述

由于Z-Stack网络层并不开源，所以一些地方是靠的推测，很多地方的结论也没有实验验证，谨留给诸君参考和斧正。

ZigBee2007协议规范分析

Z-Stack协议栈分析

1. 第一步扫描

2. 扫描结果

3. 加入父节点

4. 提出问题

归档

分类

【转】ZigBee终端入网方式深入分析

前述

由于Z-Stack网络层并不开源，所以一些地方是靠的推测，很多地方的结论也没有实验验证，谨留给诸君参考和斧正。

ZigBee2007协议规范分析

Z-Stack协议栈分析

1. 第一步 扫描

2. 扫描结果

3. 加入父节点

4. 提出问题

相关文章

归档

分类

1. 第一步扫描