CC1312R: Issues related to collector whitelist

The following are supplementary contents:“
4. When I use different PANID for collector1 and collector2, and sensor is not on the whitelist of both collectors, sensor attempts to connect to collector1. It will repeat the attempt every 3 seconds. At this time, I disconnect the power of collector1, and sensor will try to connect to collector2. However, when I reconnect the power of collector1, sensor attempts to connect to collector1 again. It seems that sensor is more interested in connecting to collector1. What is the priority of this connection? Is it based on the signal? At present, my whitelist function does not seem to meet my expectations (as sensors are all trying to connect to a certain collector)

In the assocIndCb function of the collector, I attempted to return the ApiMac-assocStatus-panAccessDenied state and restart the network scan in the sensor. Unfortunately, the sensor is still scanning the same collector. Is there a good solution?

Hi, 

Have you taken a look at this application note?

https://www.ti.com/lit/an/swra734/swra734.pdf

This may have the relevant direction you need to switch the collector for a particular sensor.

Regards

Sid

Hi sid:

I have read this document, which explains that when collector1 needs to be replaced by collector2, the sensor can clear its saved network information after scanning for a period of time, in order to treat itself as a brand new sensor. I have also added this feature to my code, but it seems that it cannot solve the situation of multiple networks in the same area,
I found during today's test that if the sensor attempts to connect to collector1 for the first time, then even if there is collector2 nearby, unless collector1 loses power, the sensor can search and try to connect to collector2. Otherwise, it will continue to try to connect to collector1 (even if collector1 returns ApiMac-assocStatus_panAccess Denied or ApiMac-assocStatus_panAtCapacity in the assocIndCb() function),
Can there be a mechanism in the sensor to record which collector was last rejected, so that the application layer can try not to connect to this collector for a period of time (such as five minutes)

Regards,

faker

The above document provides two solutions:
1. After connecting to collector1, the sensor loses power. If the sensor cannot search for this network for a long time, it will clear its own network information and try to connect to the surrounding network again. This solution is suitable for collectors that are damaged at the customer's site. Replace the previous collector with a new one
2. All sensors are connected to collector1, and collector1 actively sends a disconnection message to the sensors, notifying them to try to connect to other collectors. This solution is suitable for collector1 to connect to all nodes (with sufficient capacity)

But our client's usage scenarios are quite complex:
1. Customers may need to connect many sensors in a scenario, such as around 200 sensors
2. The customer's multiple collectors may have overlapping areas of coverage, as shown in the figure:
3. If collector1 is connected to 200 sensors, it is likely that when a customer deploys a new collector2 for component networking, the new 200 sensors will keep trying to connect to collector1, but collector1 will continue to reject new sensors because the number of nodes is full, and then the sensors will continue to retry the connection, which may cause some sensors to be unable to join collector2. Therefore, although I maintain a whitelist to distinguish the long addresses of sensors, sensor nodes may keep searching for collector1 when searching the network, resulting in the inability to connect to the collectors they are interested in

As shown in the above figure, Sensor5 may search for the wrong network and keep trying to connect,And because sensor5 cannot connect to collector1, the second mode in the document cannot be used,

And I tried to send the COLLECTOR-CLOSE-NWK-EVT event to collector1, but the sensor could still search for this network. However, in the assocCnfCb() function on the sensor side, the value of status changed to an unexpected value instead of being 2

Regards,

faker

Part Number: CC1312R

Hi guys:

I used two CC1312 blocks to form a 15.4 protocol stack network and encountered the following problem:
When two collectors have different panids and the other configurations are the same (referred to as collector1 collector2 below), the sensor starts scanning the surrounding network. If I refuse to allow the sensor to join the network in the code, the sensor will restart the SENSOR-START-EVT event to rescan the network, but it can only scan the network of collector1. I tested for about an hour but have not tried to join collector2. Based on customer requirements, we would prefer the specified sensor to join the specified collector. How can I scan the network and try to join all the surrounding networks? Or how to not join the network that was just rejected within a short period of time (such as one minute)?

Hi sid: 

First of all, thank you for your reply. I'm sorry that I'm in a hurry because we are about to start mass production. We found this problem in the final test stage. For example,

1. After the sensor is rejected from joining the network, it can try not to join the rejected collector for a period of time (for example, within 3 minutes)

2. When searching the network, can the sensor search for multiple collectors in the region, select the collector that it is interested in, and connect to it

Please also check my reply in another thread, thanks

We can discuss this scenario in a single thread

Regards

faker

Hi sid:

I have found a temporary solution:
When there are multiple collectors in a region
1. Sensor attempts to connect to collector1, but collector1 sends a reject command
2. If the sensor receives a reject command, it will restart itself and search the surrounding network again. At this time, it will randomly search for collector1 or collector2
3. The sensor attempts to connect to the collector in this search. If collector 2 is found in this search, the connection is successful and communication begins. Otherwise, try the above steps again
Thank you for your reply and support. I think our product can be released immediately, but I think the above method is just a temporary solution (this solution cannot be quickly added to the corresponding collector). So in step 2 above, I tried restarting the sensor and triggering Util_setEvent (&Sensor_events, SENSOR-START-EVT) myself; Event, however, if the sensor first searches for collector1, calling this event directly will only keep searching until collector1 is reached
Can you help me find any more suitable APIs below? For example, can collector1 be briefly filtered out and other collector networks be triggered directly in the callback?

Regards

faker

Hi Faker,

The issue is still the PAN IDs being same for two collectors. 

It is recommended even in the IEEE 802.15.4 spec to have different PANIDs for independent network in the same radio range. 

Regards,

Sid

Hi sid:

I think I may have underexpressed a situation. In my previous description, collector1 and collector2 used different PANID, with cccollector1=0X0809 and collector2=0x0509

This is good. So you are looking for a way for a sensor to look for a different PAN ID after it receives a pan access denied. 

Hi sid:

Yes, but I don't think restarting the MCU is a good solution (such as increasing power consumption or prolonging the time it takes for the sensor to join the correct collector). I want to know if there is a better API in the 15.4 protocol stack that allows sensors to try to find other networks after being rejected by the collector?

Regards,

faker

Hi Faker, 

I went through the application note that I mentioned before. https://www.ti.com/lit/an/swra734/swra734.pdf

There the second use case mentioned in the app note "6.2 PAN Coordinator Switching Due to a Command Coming From the Central Gateway"

If you notice, the sensor actually chooses not to associate with the first collector, but associates with the second collector. This is the logic that you need. 

So, if you allow the sensor to first join the collector 1 instead of kicking it out in the indication callback itself, then you can send a switch request and then sensor joins the second collector.

Regards,

Sid

Hi sid:

I have carefully read this document and used the first method in my project, but my scenario is as follows:
1. Even if sensor is connected to collector1, collector1 finds that sensor is not on its whitelist and issues instructions to sensor to try to join collector2, but collector1 must know the PANID of collector2 and issue it to sensor to achieve the above steps. However, in the customer's usage scenario, multiple collectors cannot know the PANID of other nearby collectors, so it seems not very suitable for me
2. I am wondering if the library function of the sensor includes a function similar to getting all the surrounding collectors, or if it is possible to continue searching for other networks after receiving the data packet returned by the first collector instead of attempting to join it

Regards,

faker

Hi sid:

I will continue to think of other ways to solve it. If you have a better idea, please let me know

Regards,

faker

Hi sid:

This issue has been resolved. Thank you for your support

Regards,

faker