Zstack_2007_Join_Network

3.6.1.4.2  Joining or Rejoining a Network Using NWK Rejoin
Devices that have lost all connection to the network, for example a ZED that can
no longer communicate successfully with its parent, can rejoin the network using
the NWK rejoin request and NWK rejoin response commands. The rejoining
procedure is identical to the association procedure described in the previous
section, except that the MAC association procedure is replaced by an exchange
involving the rejoin request and rejoin response commands, and, because NWK
commands make use of NWK security, no authentication step is performed. Using
these commands instead of the MAC procedure allows a device to rejoin a
network that does not currently allow new devices to join.
Devices that are joining a network for the first time may also use a variant of this

procedure as described in the following sub-clauses.

3.6.1.4.2.1    Child Procedure
The procedure for joining or rejoining a network using the NWK rejoin procedure
shall be initiated by issuing the NLME-JOIN.request primitive, as shown in
Figure 3.36, with the RejoinNetwork parameter set to 0x02 and the
ExtendedPANId parameter set to the ExtendedPANId of the network to rejoin.
The device type field of the CapabilityInformation parameter shall be set to 1 if
the device is intended to join as a router and to 0 otherwise.
The ScanChannels parameter shall be set to indicate which channels are to be
scanned to locate this network and the ScanDuration parameter set to indicate the
length of time to be spent scanning each channel.
Upon receipt of this primitive, the NWK layer shall issue an MLME-
SCAN.request primitive asking the MAC sub-layer to perform an active scan.
Every beacon frame received during the  scan having a non-zero length payload
shall cause the MLME-BEACON-NOTIFY.indication primitive to be issued from
the MAC sub-layer of the scanning device to its NLME. The NLME of the
scanning device shall check the ExtendedPANId contained within the beacon
payload to see if it is of the correct value. If not, the beacon is ignored. Otherwise,
the device shall copy the relevant information from each received beacon (see
Figure 3.49 for the structure of the beacon payload) into its neighbor table (see
Table 3.48 and Table 3.49 for the contents of a neighbor table entry).
Once the MAC sub-layer signals the completion of the scan by issuing the
MLME-SCAN.confirm primitive to the NLME, the NWK layer shall search its
neighbor table for a suitable parent device. A suitable parent device shall advertise
device capacity of the type requested in the JoinAsRouter parameter, shall have
the most recent update id, where the determination of most recent update id must
take into account that the update id will wrap back to zero, and shall have a link
cost (see sub-clause 3.6.3.1) of 3, at most. If the neighbor table contains no
devices that are suitable parents, the NLME shall respond with an NLME-JOIN.confirm with a Status parameter of NOT_PERMITTED. If the neighbor
table has more than one device that could be a suitable parent, the device which is
at a minimum depth from the ZigBee coordinator shall be chosen.
Once a suitable parent is identified,  the NLME shall construct a NWK rejoin
request command frame. The destination address field of the NWK header shall
have a value equal to the 16-bit network address of the parent candidate chosen
from the neighbor table. The source address field of the NWK header shall be set
to the value of the nwkNetworkAddress attribute of the NIB. Both the source IEEE
address field and the destination IEEE address field shall be present in the NWK
header. If the device is joining this network for the first time, and the value of the
nwkNetworkAddress attribute of its NIB has a value of 0xffff indicating that it is
not currently joined to a network, the device shall select a 16-bit network address
for itself and set the  nwkNetworkAddress attribute to this value. The address
should be randomly selected according to the procedures outlined in sub-
clause 3.6.1.7. In this case, and in any case where the nwkAddrAlloc attribute of
the NIB has a value of 0x02 indicating stochastic addressing, the allocate address
sub-field of the capability information field of the command payload shall be set
to 0 indicating a self-selected address.
After the successful transmission of the rejoin request command using the MAC
data service, the network layer shall  load a countdown timer with a value of
aResponseWaitTime ([B1]). If this timer elapses before a rejoin response
command frame is received, then the rejoin was unsuccessful. If the receiver on
when idle field of the CapabilityInformation parameter is equal to 1, the device
shall issue a MLME-POLL.request to the potential parent to retrieve the rejoin
response command. If the receiver on when idle field is equal to 0, polling is not
required.
20
On receipt of a rejoin response command frame, after the above procedure or at
any other time, the device shall check the destination IEEE address field and the
source IEEE address fields of the command frame NWK header. If the destination
IEEE address field is not equal in value to the IEEE address of the receiving
device or if the source IEEE address field is not equal in value to the IEEE address
of the most recent potential parent to which a rejoin request command frame was
sent (or the current parent in the case of an unsolicited rejoin response), then the
rejoin response command frame shall be discarded without further processing.
If the rejoin status field within the rejoin response command frame indicates a
refusal to permit rejoining on the part of the neighboring device (that is, PAN at
capacity or PAN access denied), then the device attempting to rejoin should set the
potential parent bit to 0 in the corresponding neighbor table entry to indicate a
failed join attempt. Setting the potential parent bit to 0 ensures that the NWK layer

will not issue another request to rejoin to the same neighboring device. If the

attempt to join was unsuccessful, the NLME shall attempt to find another suitable

parent from the neighbor table. If no such device can be found, the NLME shall
issue the NLME-JOIN.confirm primitive with the Status parameter set to
NOT_PERMITTED. If the attempt to join  is unsuccessful and there is a second
neighboring device that could be a suitable parent,  the NWK layer shall initiate
the NWK rejoin procedure with the second device. The NWK layer shall repeat
this procedure until it either rejoins the PAN successfully or exhausts its options to
rejoin the PAN. If the device cannot successfully rejoin the PAN specified by the
next higher layer, the NLME shall terminate the procedure by issuing the NLME-
JOIN.confirm primitive with the Status parameter set to NOT_PERMITTED. In
this case, the device shall not receive a  valid logical address and shall not be
permitted to transmit on the network. If the attempt to rejoin was successful, the
NWK rejoin response command received by the NWK layer shall contain a 16-bit
logical address unique to that network, which the child can use in future
transmissions. Note that this address  may be identical to the current 16-bit
network address of the device stored in the nwkNetworkAddress attribute of the
NIB. The NWK layer shall then set the  relationship field  in the corresponding
neighbor table entry to indicate that the neighbor is its parent. By this time, the
parent shall have added the new device to its neighbor table. Furthermore, the
NWK layer shall update the values of  nwkNetworkAddress,  nwkUpdateId, and

nwkPANId in the NIB if necessary

3.6.1.4.2.2    Parent Procedure
The procedure for a ZigBee coordinator or router to rejoin a device to its network
using the NWK rejoin procedure is initiated by the arrival of a NWK layer rejoin
command frame via the MAC data service. Only those devices that are either
ZigBee coordinators or ZigBee routers  shall initiate this procedure. If this
procedure is initiated on any other  device, the NLME shall terminate the
procedure. When this procedure is initiated, the NLME of a potential parent shall
first determine whether it already has knowledge of the requesting device. To do
this, the NLME shall search its neighbor table in order to determine whether a
matching 64-bit, extended address can be found. If an extended address match is
found, the NLME shall check that  the supplied DeviceCapabilities match the
device type on record in the neighbor table. If the device type matches, the NLME
shall consider the join attempt successful and use the 16-bit network address
found in its neighbor table as the network address of the joining device. If a device
type match is not found, the NLME shall remove all records of the device in its
neighbor table and restart processing of the NWK layer rejoin command.
If the potential parent does not have the capacity to accept the joining device, the
NLME shall terminate the procedure and indicate this fact in the subsequent rejoin


response command. The Status parameter of this command shall indicate that the
PAN is at capacity.
If the request to rejoin is granted, the NLME of the parent shall create a new entry
for the child in its neighbor table, or modify the existing entry if one such already
exists, using the supplied device information, and indicate a successful rejoin by
replying to the requesting device with a NWK rejoin response command. If the
nwkAddrAlloc attribute of the NIB has a value of 0x00, indicating tree addressing,
the NLME shall allocate new a 16-bit network address for the joining device. See
sub-clause 3.6.1.6 and sub-clause 3.6.1.7 for an explanation of the address
assignment mechanisms.
If the  nwkAddrAlloc attribute of the NIB does not have a value of 0x00, the
allocate address sub-field of the capabilities information field of the rejoin request
command frame payload may have a value of 0 indicating a self-assigned or pre-
existing network address. In this case,  as is the case with all NWK command
frames, the 16-bit network address in the source address field of the NWK header,
in combination with the 64-bit IEEE address from the source IEEE address field
of the network header should be checked for address conflicts as described in sub-
clause 3.6.1.9. If an address conflict is discovered, a new, and non-conflicting,
address shall be chosen for the joining device and shall be placed in the network
address field of command frame payload of the outgoing rejoin response
command frame. Otherwise, the contents of the source address field of the
incoming rejoin request command frame shall be placed in the network address
field of the command frame payload of the outgoing rejoin response command
frame.
The NLME shall then notify the next higher layer that a child has just rejoined the
network by issuing the NLME-JOIN.indication primitive. The procedure for
successfully rejoining a device to the network is illustrated in the MSC shown in
Figure 3.37