SWRA734 December   2021 CC1312PSIP , CC1312R , CC1312R7 , CC1314R10 , CC1352P , CC1352P7 , CC1352R , CC2652P , CC2652P7 , CC2652R , CC2652RB , CC2652RSIP

 

  1.   Trademarks
  2. 1Introduction
  3. 2Benefits of Having Multiple Gateway Support
    1. 2.1 Node Balancing
    2. 2.2 Robustness
    3. 2.3 Extended Coverage and Network Redundancy
  4. 3Current SDK Examples and Coprocessor Configuration
  5. 4Central Gateway
  6. 5Enabling Multiple Gateway Support
    1. 5.1 PAN Coordinator Switching Due to Sync Loss
    2. 5.2 PAN Coordinator Switching Due to a Command Coming From the Central Gateway
  7. 6Basic Implementation of PAN Coordinator Switching
    1. 6.1 PAN Coordinator Switching Due to Sync Loss
    2. 6.2 PAN Coordinator Switching Due to a Command Coming From the Central Gateway
  8. 7Summary
  9. 8References

PAN Coordinator Switching Due to a Command Coming From the Central Gateway

This scenario is more complex and it is particularly pertinent to this application note because it directly relates to most of the network features described in the first sections of this document. Features such as node balancing, extended network coverage, and increased node count, require an application layer capable of performing coordinator switching triggered by a command sent by the central gateway.

Having said this, the approach is similar to the one previously described for coordinator switching due to a sync loss, except that in this case the application layer of the collector also needs to be modified.

The following steps assume that an existing network has at least two local gateways and some associated sensors. For practical purposes, the first local gateway will be referred as LG1 and the second local gateway will be referred as LG2.

  1. The network is formed and the central gateway coordinates LG1 and LG2. The local networks managed by LG1 and LG2 use different PAN IDs and short address ranges, and each PAN coordinator has some associated sensor devices.
  2. The central gateway sends a command to LG1 and LG2 notifying both local gateways that a particular sensor device in the network of LG1 should switch PAN coordinator and connect to the local network set up by LG2. That is, LG2 will replace LG1 as PAN coordinator for that particular sensor.
  3. Both local gateways acknowledge the command sent by the central gateway.
  4. LG2 opens its local TI 15.4 network to allow new devices to join.
  5. LG1 notifies the sensor device of the switch request by sending a command that may include (depending on the application) the following things:
    • The PAN ID of LG2
    • The channel currently being used by LG2
  6. The sensor receives the switch request, acknowledges it, and sends a disassociation request to LG1.
  7. Once the disassociation request succeeds, the sensor performs an active scan (Non-Beacon mode) or a passive scan (Beacon mode) to detect other PAN coordinators.
  8. If the scan succeeds, the sensor verifies that the coordinator data sent from LG1 corresponds to the data coming from LG2, and if it does, it starts the association procedure.
  9. Once the association procedure succeeds, LG2 notifies the central gateway that the sensor is now part of its local network.

NOTE: This sequence does not cover communication between the local gateways and the central gateway.

Figure 5-2 PAN Coordinator Switching Due to a Command From the Central Gateway