Embed Size (px)
Citation preview
DigiMesh Network Discovery With an Emphasis on Proper Parameter Selection
A whitepaper by: Douglas George
Firmware Engineer Digi International
Page 2 of 12
What is Network Discovery?
A very useful command for characterizing DigiMesh networks is the Network Discovery (ND) command.
When a Network Discovery is requested (via AT command mode or an API AT command request packet)
the module sends a Node Discovery Request broadcast to all modules in the network. Every module in
the network that receives the ND Request sends a Node Discovery Response unicast to the requesting
module containing identifying information. To mitigate collisions of the responses a random delay is
inserted before sending the response. This information is output on the requesting node’s UART in
either text format (when in AT command mode) or as an API frame (in API mode). The format of these
responses can be found in the product manual.
Data contained in a Node Discovery Response:
What Description
16-bit address 16-bit address for ZigBee modules, 0xFFFE for DigiMesh Modules.
64-bit address MAC address of responding node
NI String Node Identifier string of responding node.
Profile ID Profile ID of responding node.
Manuf. ID Manufacturer ID of responding node.
DD Digi Device Identifier of responding Node
RSSI Received Signal Strength Indicator of the last hop of the responding path.
To make the ND command even more useful there is the option to limit the number of hops the ND
request can traverse. This limits the number of responding nodes to a subset within the specified
number of hops of the ND requester. At one extreme the user could discover every node in the entire
network and at the other extreme could discover all of the immediate neighbors of a specific node.
Network Discovery Variants
A number of useful variants of the Network Discovery variants exist. These utilize the same basic
mechanism but are designed for slightly different purposes than ND. These variants are described here:
Find Neighbor Command: The Find Neighbor command can be used to find the modules which are within direct RF range (1 network hop) of the command initiator. This command is very useful in determining the topology of a network. Unlike the ND command the Find Neighbor command can be remotely initiated. It allows any radio in the network to select any other radio in the network and determine what its neighbors are. This remote capability makes the Find Neighbor very useful in determining network links.
Page 3 of 12
Node Discovery: The Network Discovery can optionally accept a Node Identification string as a parameter. When a parameter is used, only modules with an NI string matching the parameter will respond to the ND Request. This is a useful way to determine if a certain node currently exists in the network.
Example Diagrams
This diagram demonstrates a basic Network Discovery:
A
B
D
E
F
C
A
B
D
E
F
C
A
B
D
E
F
C
1 2 3
A
B
D
E
F
C
4
The ND request is broadcast The ND request is broadcast
The ND request is broadcast
A
B
D
E
F
C
5 Responses are sent at random times (D)
The ND request is broadcast
12:00:00.0000 PM 12:00:00.0010 PM 12:00:00.0020 PM
12:00:00.0030 PM 12:00:01.9456 PM
A
B
D
E
F
C
6 Responses are sent at random times (E)
12:00:02.0012 PM
A
B
D
E
F
C
7 Responses are sent at random times (C)
12:00:02.9654 PM
A
B
D
E
F
C
8 Responses are sent at random times (B)
12:00:04.0612 PM
A
B
D
E
F
C
9 Responses are sent at random times (F)
12:00:08.3012 PM
Page 4 of 12
This diagram illustrates a Network Discovery in which an NI string is used as a parameter to the ND
command. In this example the NI string parameter matches the NI string of radio D in the diagram.
This diagram illustrates a Network Discovery in which the number of broadcast hops is limited to 1.
A
B
D
E
F
C
1 The ND request is broadcast 1 hop
12:00:00.0000 PM
A
B
D
E
F
C
3 Responses are sent at random times (E)
12:00:04.0762 PM
Responses are sent at random times (B)
2
A
B
C
E
D
F
12:00:00.0000 PM
f
A
B
D
E
F
C
A
B
D
E
F
C
A
B
D
E
F
C
1 2 3
A
B
D
E
F
C
4
The ND request is broadcast The ND request is broadcast
The ND request is broadcast
A
B
D
E
F
C
5 The response is sent immediately.
The ND request is broadcast
12:00:00.0000 PM 12:00:00.0010 PM 12:00:00.0020 PM
12:00:00.0030 PM 12:00:00.0040 PM
6
Page 5 of 12
This diagram illustrates a Network Discovery in which the number of broadcast hops is limited to 2.
How Long Does it Take?
To become an expert user of the ND commands it is necessary to understand the underlying timing mechanisms involved. The forthcoming equations use the following platform dependent constants:
Note that RN is a hidden AT command. The default value should be used in nearly all cases. All other undefined variables refer to AT command parameters. All calculations result in a time in millisecond units. Broadcast One-Hop Time: The time it takes for a broadcast of the ND request to traverse one hop in the network is a critical calculation used in many of the formulas below. The equation to calculate the broadcast one-hop time (in mS) is given here:
Platform PhyTxTime (uS) DELAY_SLOT_TIME (uS) RN default
DigiMesh2.4 – 8x4x, 8x5x 4256 1636 4
DigiMesh2.4 – 8x6x 4256 1136 4
DigiMesh900 17524 1600 0
A
B
D
E
F
C
A
B
D
E
F
C
1 2 The ND request is broadcast The ND request is broadcast
12:00:00.0000 PM 12:00:00.0010 PM
A
B
D
E
F
C
3 Responses are sent at random times (E)
12:00:02.1012 PM
A
B
D
E
F
C
4 Responses are sent at random times (C)
12:00:03.1454 PM
A
B
D
E
F
C
5 Responses are sent at random times (B)
12:00:03.9612 PM
6
Page 6 of 12
Max Hops: MaxHops is the maximum number of hops that a broadcast of an ND request can take. It is defined to be 1 in the case of the FN command. In all other cases it is defined to be the smaller of the NH and BH parameters. Network Broadcast Time: The Network Broadcast Time is the amount of time it takes for the ND Request to reach every node in the network. This is dependent upon the following parameters: MT, BH, and NN and is calculated as follows (units of mS):
UnicastOneHopTime: The following table defines the maximum amount of time necessary to transmit a unicast transmission
one hop:
For timing calculations a maximum of 3 MAC level retries is used. It is assumed that on multi-hop
transmissions the average number of MAC retries will not exceed 3. Note that these values represent
the worst case. Typical timing values will be shorter.
Maximum Known Route Unicast Time: The maximum time it takes to send a unicast to a node with a discovered route, within BH hops, using all
possible network retries is defined by the following formula:
The preceding formula is not actually used in the calculation of Network Discovery Timing, but is
provided to help the user better understand the reasoning behind some of the formulas which are used.
Known Route Unicast Time: The time it takes to send a unicast to a node with a discovered route, within BH hops, without using
network retries is defined by the following formula:
UnicastOneHopTime(mS)
RR DigiMesh2.4 (8x4x, 8x5x) DigiMesh2.4 (8x6x) DigiMesh900
0 5 5 17
1 24 23 40
2 40 37 64
3+ 63 56 95
Page 7 of 12
Unknown Route Unicast Time: When the route to a node is not known a route discovery process must be executed before the unicast
can be transmitted. The maximum time it takes to send a unicast to a node with an unknown route is
defined by the following formula (no network retries used):
Network Discovery Time: When calculating the amount of time to wait for ND responses, DigiMesh modules use the following
calculation:
What can go wrong? How do I compensate?
There are three main phases of a Network Discovery. The failure of any one of these will prevent a Network Discovery Response from reaching the requestor. This section is intended to describe methods that can be used to increase the robustness of the individual phases. These three phases are:
1) Sending the Network Discovery Broadcast 2) Finding a route to the Network Discovery requestor 3) Unicasting the Network Discovery Response to the requestor.
Distributing the ND Request Reliably: The first step in maximizing the reliability of Network Discoveries is to maximize the reliability of network broadcasts. Network Discovery Request messages are sent as a broadcast to all nodes in the network. Nodes which do not receive this broadcast will not be able to send a response to the request. Increasing the reliability of broadcasts will also increase the effectiveness of any route discoveries which will need to be performed. To appreciate the best way to improve broadcast reliability it is helpful to understand the DigiMesh broadcast methodology. This is best explained by examining the behavior of 3 different node types:
Broadcast originator: The node which originates a broadcast will immediately send the message to all nodes within immediate (one-hop) range. It will then repeat the same message MT times (3 by default). Router receiving broadcast: Any router (a node which has a CE setting of 0) which receives a copy of the broadcast for the first time will randomly delay for a period of time (controlled by the NN command) and then it will transmit the message MT+1 times to its immediate neighbors. A router will only forward a particular broadcast message once. When a broadcast receives a copy of a broadcast which it has already received and forwarded then it will silently discard the message.
Page 8 of 12
All broadcast messages are tracked to see how many hops they traverse. If a broadcast message has reached the maximum number of hops allowed it will not be forwarded any further. End device receiving broadcast: An end device (CE=2) which receives a copy of a broadcast will accept the first copy of the broadcast it receives but will not forward it. Only one copy of the broadcast will be sent out the data port of the module.
Four parameters affect the reliability of broadcasts: NH, BH, NN, and MT. The following section describes how best to modify these parameters to increase Network Discovery reliability:
Network Hops/Broadcast Radius (NH & BH): Broadcasts will not propagate more hops than specified by the minimum of the BH or NH commands. To maximize reliability it is essential that these parameters be made at least as large as the network diameter. It is wise to be conservative when estimating the network diameter. In other words, it is better to set these parameters too large rather than too small. Network Delay Slots (NN): The NN command is used to reduce the likelihood that two routers which receive the same copy of a broadcast message will attempt to retransmit the message at the same time. If they transmit at the same time it is possible that a node in range of both routers would receive an invalid and unusable packet. Increasing the NN parameter value has the effect of increasing the maximum random delay that a router will wait before retransmitting a message. Increasing this window of time decreases the likelihood of collisions. As with most parameters there are tradeoffs. The NN parameter value can be increased to improve broadcast reliability but doing so has the side effect of increasing the time it takes for a broadcast to propagate across the entire network. This affects broadcasts sent by the user application and internal functions which use broadcasts like route discovery and synchronous sleep sync messages. Fortunately many applications can tolerate increased delays in timing. For example, a system to monitor water meters may only need to send transmissions every few hours. In this case increased broadcast timing would have little detriment. The system designer should evaluate their timing requirements and, if deemed appropriate, modify the NN value accordingly. Multi-Transmit (MT): The MT command is used to specify the number of times a node originating a broadcast or a router relaying a broadcast will repeat the message. By increasing this number it increases the number of chances a node has to hear the message. The increased reliability of broadcasts which comes from increasing the MT command also comes with side effects. Increasing this number increases the time it takes for a broadcast to propagate across the network. Additionally, if the command is increased too high then it actually increases the probability of collisions in dense portions of the network. It is not advisable to set MT to 0. As a rule of thumb, in very dense networks increasing NN is more effective than increasing MT, and in very sparse networks the opposite is true; in many networks a combination may be most effective.
Page 9 of 12
The following table shows the maximum time it takes for a broadcast to propagate across an entire network. The table is provided to allow the system developer to gain a better understanding of how changing these parameters affect timing:
NH/BH min. NN MT
DigiMesh2.4 8x6x broadcast
time (mS)
DigiMesh900 broadcast time
(mS)
4 3 3 420 1116
4 3 6 732 1956
4 3 9 1032 2796
4 6 3 840 2232
4 6 6 1464 3912
4 6 9 2064 5592
4 9 3 1260 3348
4 9 6 2196 5868
4 9 9 3096 8388
7 3 3 735 1953
7 3 6 1281 3423
7 3 9 1806 4893
7 6 3 1470 3906
7 6 6 2562 6846
7 6 9 3612 9786
7 9 3 2205 5859
7 9 6 3843 10269
7 9 9 5418 14679
10 3 3 1050 2790
10 3 6 1830 4890
10 3 9 2580 6990
10 6 3 2100 5580
10 6 6 3660 9780
10 6 9 5160 13980
10 9 3 3150 8370
10 9 6 5490 14670
10 9 9 7740 20970
Minimizing Route Discovery on ND Responses: Route discovery is the process by which a path from a transmitter to its destination across a network is located. This is an intensive procedure on the network because it involves sending a transmission to every node in the network and awaiting a response from the destination node. If a network discovery is attempted on a network in which many or all of the nodes do not have a discovered route to the ND requestor then all of the responding nodes will need to perform a route discovery in the relatively short time window afforded by the NT parameter. This can be a very taxing process on the network. In cases where there are many nodes in the network then a notable percentage of the ND responses may not be successfully delivered to the requestor.
Page 10 of 12
Fortunately, the Aggregate Routing (AG) command can be used to minimize the necessity for many route discoveries when performing a Network Discovery. The AG command provides a method whereby all nodes in the network can establish routes to a certain node without excessively taxing the system. If a Network Discovery originator precedes the Network Discovery with an issuance of the AG command then the majority of the nodes in the network will not need to perform a route discovery prior to sending the Network Discovery Response. This can greatly improve Network Discovery Reliability. Getting the ND Response Back: When a route is known for the Network Discovery Response the responding node will send the response. To increase the reliability of this unicast reaching the Network Discovery originator two parameters can be modified to increase reliability. Both of these commands control the maximum number of retries which will be attempted on a unicast.
Unicast Mac Retries (RR): The RR command can be used to increase the number of retries that can be used between adjacent radios as the message is forwarded along its route. Mesh Network Retries (MR): The mesh retries parameter is used to specify the number of times that the originator of the unicast will attempt to re-send the message across the network before it reports a failure.
For both of these commands increasing the parameter will increase the maximum time it can take for the unicast to reach its destination. Fortunately in a network with strong links, most of the time these retries will be unused. Increasing these parameters does increase the amount of time that a Network Discovery originating node will wait for responses. Increasing the Node Discovery Backoff Time using the NT parameter is very effective in reducing collisions. This command controls the maximum amount of random delay that will be inserted before a Network Discovery Response unicast is sent. By increasing this parameter the likelihood of two or more unicasts being initiated at the same time decreases. Reduce probability of missing a response by doing multiple Network Discoveries: In applications where it is very important to reliably get all Network Discovery responses it is advantageous at times to do multiple Network Discoveries. Doing multiple Network Discoveries reduces the probability that a response will be missed. Most of the preceding parameter optimizations affect timing for both the Network Discovery and for normal network traffic. If the optimum parameter settings needed for Network Discovery are incompatible with the network settings needed for normal operation then performing multiple Network Discoveries is oftentimes a way to improve reliability without adversely affecting normal network operations. When doing multiple Network Discoveries it is important to be sure that a previous Network Discovery has completed before initiating a new one. The Remote Find Neighbor Command: The Find Neighbor command is essentially a Network Discovery in which only the immediate neighbors of the requestor node responds to the request. Unlike the Network Discovery command, the Find Neighbor command can be issued remotely. Any node in the network can send a remote FN command request to any other node in the network. The recipient of the remote command request will function
Page 11 of 12
as the requestor. Unlike the Network Discovery command the Network Discovery Responses are not sent to the requestor, but rather directly to the originator of the remote command request. The nuances of the Remote Find Neighbor command require care when applying the preceding suggestions. Specifically it is important to note that the responding nodes will attempt to send the unicast Network Discovery Response directly to the originator of the remote command request, and thusly may attempt to do route discovery. This may be a motivation to precede the remote command request with an AG command. Because only the immediate neighbors of the requestor will be responding (and not the entire network) one’s best judgment should be employed in determining if the AG command is necessary. This decision can be assisted by evaluating the average number of neighbors a node will have and by doing adequate testing.
When would Network Discovery Be Useful?
An innovative engineer can invent numerous uses for the network discovery command. The majority of
these uses will be tightly coupled with the specific customer application in which they are used. The
following section is intended to outline some possible uses (which are not tightly coupled with a specific
application) to help spark the imagination of the system designer:
Example 1: Installation:
After setting up a new network of DigiMesh modules it can be very useful for an installer to use the ND
command to ascertain some basic idea of the topology of the network. The following sequence of ND
commands could be used to acquire information:
1) Choose a centrally located module in the network (or any convenient module). Perform a max
hop ND. Ask the following question: What nodes in my network did not respond to the Node
Discovery?
2) Repeat the max hop ND a number of times. Note if any modules respond unreliably (or not at
all). The unreliable nodes can be investigated for poor network linkage or other problems.
3) Choose a module located on the periphery of the network. Perform a number of Network
Discoveries, starting with a hop limit of 1 and incrementing the hop limit each ND. Observe how
large the hop limit needs to be to get all modules in the network to respond. This will allow the
installer to estimate the number of hops it takes to traverse the network. If the entire network
cannot be discovered with a hop limit less than the NH parameter of the network then it would
be wise to increase the NH of the network.
4) Randomly choose a node in the network. Perform a ND with a hop limit of one on that node. Determine the number of neighbors the particular node has. Repeat the process with an appropriate number of nodes in the network to establish the average and maximum number of immediate neighbors to the nodes in the network. This information can be useful in choosing the NN value of the network.
Page 12 of 12
Example 2: Mobile Node Location:
In certain applications the Find Neighbors command (FN) which is closely related to Network Discovery
can be used to determine the proximity of a mobile node or nodes in relation to fixed location nodes in
the network.
1) The application will need to record the location of fixed position nodes in the network and be
able to identify them in a meaningful manner. The Node Identifier (NI) string can be a useful
way to identify the nodes because it appears in Network Discovery responses.
For example, if the application was to track expensive mobile equipment in a hospital setting
fixed nodes could be placed in hospital rooms and identified via the NI string (WingA_room1,
WingA_room2, WingC_room10, etc.)
2) The mobile node could issue a Find Neighbor command, or a controlling node in the network
could remotely initiate a Find Neighbor command on the mobile node.
3) Nodes in one hop range of the mobile node would respond to the Find Neighbor command.
4) The mobile node (or remote command initiator) could analyze the responses to determine
approximate location.
Continuing the hospital example, if the mobile node was in room 15 of Wing B of the hospital
the following would represent the pertinent information contained in conceivable responses:
Responder Serial Number Responder NI String Responder RSSI
0013a200 4052c507 WingB_room12 -63
0013a200 40671289 WingB_room14 -50
0013a200 40891265 WingB_room13 -65
0013a200 40546545 WingB_room15 -42
0013a200 40789123 WingB_room17 -67
0013a200 40654729 WingB_room16 -62
5) The responses could be analyzed. Immediately the user would know that the equipment is in
Wing B in the proximity of rooms 12 through 17. By analyzing the RSSI values the user could
then estimate that the equipment is likely in room 15 of Wing B.
