CC1310: Collector congestion

John Tauch

Part Number: CC1310

Hello,

Tools SDK 2_1_00_36

Device CC1310F128.

We are operating the 15.4 stack in FH (using 50% of channels), LRM mode and are seeing issues with what we believe is network congestion.

We are operating 4 collectors in a small area and have different nodes associated with each collector. Each

collector has a Unique PAN_ID and a unique coordinator address. We have 4 nodes on collector 8, 1 nodes on collector 3,

1 node on collector 9 and 2 nodes on collector 11. What I am seeing now, is that additional nodes trying to join collector 11 seem to get stuck in

PA solicit i.e. TX followed by RX butter never join. My questions are as follows:

1. Is there a limit to the number of collectors that can co-exist. It would seem that at some point the node could have a high probability of always

getting a response form the wrong collector. Is there a mechanism to prevent this i.e. some form of filter?

2. What is a expected join time? we were seeing anywhere between a few minutes up to 10 minutes. are there any knobs to speed this up?

I should add that once the nodes join, The four systems operate without any issues, Perhaps we have simply found the limit.

Thanks,

John

over 7 years ago

0 IUsedToBeARealPerson (M-W) over 7 years ago

TI__Guru 58425 points

Hi John,

Sounds to be that you are experiencing some significant package drops based on the joining times of the sensors. Just running the default examples using FH mode, I would expect < 10 seconds join time for a single network, up to 10min sounds like there is a lot of radio interference. I would guess LRM adds on to this as it would increase the active radio time even further.

Have you tried sniffing the network to see how it looks when a sensor tries to join? If so, do you have any logs to share (such as Wireshark captures)?

0 John Tauch over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 585 points

Thanks for the reply M-W.

We may have found a way to mitigate the PA Solicit response (PA) from the collector. We believe that in a collector congested environment that the node might be unable to connect with the correct collector. This is due to all collectors responding to a PA Solicit. We thought that perhaps if the PA solicit included a MAC id then we could filter the attachment process, but this does not seem to be the case.

Join times definitely increase when more collectors are co-located.

Wireshark logs are difficult when using FH. We have only been able to configure the sniffer for a single channel.

Thanks,

JOhn

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to John Tauch

TI__Guru 58425 points

Hi John,

In your scenario, do all collector always allow joining nodes at all times or are this disabled on the collectors you do not intend to join?

Yeah Wireshark logs for FH is tricky due to the single channel limitation, the asynchronous messages such as PAS and PA should however still be transmitted on all channels from what I can tell.

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to IUsedToBeARealPerson (M-W)

TI__Guru 58425 points

Hi John,

When running these four collectors, have you given unique "CONFIG_FH_NETNAME" to each of them?
If not, try to assign unique (possibly shorter) names to each of the collector, and use the name of the desired collector in the sensor configuration.

0 An Bui26 over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 435 points

Yes, pairing each collector/sensor system with a unique FH Name will prevent the collector from sending PA the sensor that does not have a matching FH Name.

Giving a unique name to each collector/node systems not an option.

We found that the PAS has the sensor MAC address.

We will compare this MAC address with the master list we received from the cellular back-end to suppress the PA response.

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to An Bui26

TI__Guru 58425 points

Hi John,

Ok, if unique names is not an option you idea sounds like the next best bet.

Let me know how it works and possible findings you do along the way!

0 Sanchitha Dias over 7 years ago in reply to IUsedToBeARealPerson (M-W)

Intellectual 795 points

Hi M-W,

Would this issue be fixed if we use unique FH_ASYNC_CHANNEL_MASK's for each collector?

Kind Regards,

Sanchitha

0 IUsedToBeARealPerson (M-W) over 7 years ago in reply to Sanchitha Dias

TI__Guru 58425 points

Hi,

Yes that should help mitigating the issue.

Sub-1 GHz

Sub-1 GHz forum

CC1310: Collector congestion