• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 55 subscribers
  • Views 487 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Original question:

CC1310 Sensor/collector/gateway Beaglebone example

TI-15.4-STACK-GATEWAY-LINUX-SDK: FH netname to segment FH networks?

Nick Beckmann
Prodigy 90 points

Part Number: TI-15.4-STACK-GATEWAY-LINUX-SDK

It seems from the collector/sensor implementations and previous forum posts that the network name is meant to segment frequency hopping networks.  However, when I attempt to use different network names I see my sensors getting confused and following collectors with a different network names.

It seems to me like this problem is caused in the handling of async frames.  PAS, PCS, and PA frames "from other networks" are dropped but the config frames do not include a network name.  In example asyncInd call back any config frame received is processed without any check.  When a collector from network B responds to a config solicit request my sensors (already joined to network A) sometimes (frequently) process the config async indication and start tracking this collector.  I think this is a bug in the implementation - or am I misunderstanding the use of the netname?

It seems to me like this should be a very rare occurrence as I would expect the frequency hopping schedules of my sensors to rarely align with the async indication response from a different collector but I see it very consistently. 

Thanks,

Nick

  • 0
    TI__Mastermind 28440 points
    Hi,

    If you are using the default FH implementation of the collector/sensor examples, they all follow the WiSun spec. So it is possible that the FH schedules could align.
    Please see e2e.ti.com/.../2873003

    According the WiSun spec:
    "The NETNAME-IE is used to match nodes with specifically named FANs. Note that multiple PANs may advertise the same Network Name."
    Please see e2e.ti.com/.../2697556

    Let us know if you have further questions.


    Regards,
    Toby
  • 0 in reply to Toby Pan
    Prodigy 90 points
    I don't think this addresses my concern. As you quoted there, the netname is meant to match nodes with specific FANs. Looking at the collector/sensor examples, my point is that any config frame received by a sensor is blindly processed. It does not filter on netname, pan id, or any other attribute. It seems that the implementation assumes that a config frame will only be received directly after a panAdvertSolicit request when the sensor is joining and that the source of that frame will be the collector that previously sent a pan advertisement (where matching does take place).

    This assumption can cause a sensor, after receiving an async config from another network (distinguished by netname), to track a collector it is not intended to.

    Just to illustrate my example a little further. Say sensor A joins PAN xAABB, with netname FHTEST. It's alive and operating fine when much later sensor B tries to join PAN xCCDD with netname DIFFERENTORGANIZATION. If sensor A receives the config frame sent as part of this join procedure, it will track the collector that sent the config frame, effectively not segmenting the network as it's intended to.

    Thanks,
    Nick
  • 0 in reply to Nick Beckmann
    TI__Mastermind 19135 points
    Hello Nick,

    This NetName value is not used by the TI 15.4-Stack to make any decision; instead, the value is carried in a PAN Advertisement frame that can be parsed by a receiving application. The network name (NetName) is a unique network identifier that is configured by the application using frequency hopping and PAN information base (FH-PIB) attributes. Maintenance of the NetName is beyond the scope of TI 15.4-Stack and is not used to filter frames.

    Regards,
    AB
  • 0 in reply to AB
    Prodigy 90 points

    I understand the netname from the 15.4 stack and WiSun stack perspective.  My observation was that the Linux Collector and 1312 sensor example "applications" look like they use the netname to segment the network.  This is in part true but the implementation relies on the WiSun configuration request not being received by nodes that don't share MAC encryption keys.  As these keys are determined by the "application" I can see how netname and keys are used by the Linux Collector and sensor example to segment a FH network from an application perspective.

    My issue was that I disabled security within my network (undef FEATURE_MAC_SECURITY).  This caused the async config requests to be received by all sensors, which causes some sensors to follow the wrong collector and essentially become lost.

    I think my takeaway here is the Linux gateway and 1312 sensor examples are meant to be used as loose starting points, and although they have many knobs (like featurized security code under FEATURE_MAC_SECURITY) different configurations are not meant to be supported.