CC1310: 15.4 Stack: CONFIG_FH_NETNAME question.

Thanks for the clarification. I have a specific use case followup question:

First let's assume that the sensor has associated with the collector since they share the same net name = "NAME_A". Then later the collector decides to change the net name to "NAME_B".

1. Must the collector restart, or can it still be in normal operation as before the name change?

2. Will the sensor still be able to communicate with the collector? Will it eventually become orphan?

3. If I introduce a second sensor, but now with net name = "NAME_B", this will associate with the collector of course. Afterwards I change the sensor net name to "NAME_C". Will this still be able to communicate with the collector?

The reason I ask is because I would like to use one net name when a sensor associates (for the first time) with a collector. Let's call this net name "JOIN-NAME". When the sensor joins the network, the collector sends the actual net name to be used during normal operation which is a specific net name for the specific network. Then both the collector and sensor change their net name to the specific net name. However, it is important that all the other sensors which already are connected to the network don't loose contact with the collector while the collector temporarily changes net name to "JOIN-NAME". The reason behind this idea is if one sensor looses contact with a collector and becomes orphan, it shall try to associate with another collector belonging to the same customer. If there is another customer nearby I don't want the senor to associate with the other customer's collector. 

Thanks.

I dont think you would have this problem of your devices joining another customer nearby unless both networks are the exact net name and if they are not using security or using the same key for encryption.

I would recommend you implement an application layer authentication mechanism instead of using the netnames to implement this.
But if you want to use the netname to do something like this I believe the netname is only used to filter Async messages and you can modify the function "wsAsyncIndCb" accordingly to allow multiple netnames.

Thanks. I was also under the impression that only Async messages used the NET NAME (and the Async messages are just used when a sensor wants to join a network or becomes orphan - to my understanding).

The "issue" arises from ease of manufacturing and sales. We would like to install the same firmware for all devices (sensors and collectors - of course different for the two(!)). The devices shall not require any loading of customer specific parameters before being shipped out - this would otherwise be a huge hassle. The collector will also have a wifi chip (cc3220xx), and the gateway claiming to specific customer has been solved.

So all of our devices will have the same security key initially and the same net name "out of the box / factory reset". We can also change the security key to be customer specific in the same manner described in the previous post - if this is needed... This may be a better idea than having specific net names - since the net names will solely act as a filter for the async messages. Otherwise we must ensure that all collectors (even the neighbour) have unique PAN ID's. But changing the security keys temporarily when in "claim" mode, would cause all the other normally operating sensors to loose contact with the collector. So the very best solution, perhaps, would be if the collector could have a set of encryption keys consisting of 2 keys. 1 being unique for the network and the other being the common "out of the box" key. The collector would then have to be able to support both key sets simultaneously. Does the stack support this?

When the customer first takes out the the sensor from the shipment-box, the customer must "claim" the sensor to belong to his/her set of gateway(s). It's in this step the specific "credentials" are transferred from the gateway to the sensor - and hence the GW must temporarily be in "default" mode in order to communicate with the sensor.

So this is the actual problem definition, and we are trying to solve this issue - provided that a neighbour also has our company's sensors/GW product.

Another sort of off topic question: It is a requirement that nearby collectors have unique PAN ID's. But can collectors have the same PAN ID, provided that they use security and with different encryption keys? I understand that they will not associate with one another, but will there be more over the air "overhead" due to ACK frames etc - which otherwise would not be present if unique PAN ID's were used?

Another observation: When security is enabled, only some types of frames are actually encrypted (verified by wireshark). Hence, "encryption enabled" will not act as a filter for association request frames. However, since there are some more frames involved in the "whole" association procedure - I would assume that the remaining frames are encrypted and ensures that the collector will not add the sensor to its list... I'm not even sure if message integrity code (MIC) is on or off...

These are the frames which have security:

STATIC CONST ApiMac_securityPibSecurityLevelEntry_t securityLevelEntry =
    {
      0,
      { MAC_FRAME_TYPE_DATA, MAC_DATA_REQ_FRAME, 0, false }
    };

/*! Security Level Descriptor */
typedef struct _apimac_securityleveldescriptor
{
    /*! Frame Type */
    uint8_t frameType;
    /*! Command Frame ID */
    uint8_t commandFrameIdentifier;
    /*!
     The minimal required/expected security level for incoming MAC frames.
     */
    uint8_t securityMinimum;
    /*!
     Indication of whether originating devices for which the Exempt flag is
     set may override the minimum security level indicated by the Security
     Minimum element. If TRUE, this indicates that for originating devices
     with Exempt status, the incoming security level zero is acceptable.
     */
    bool securityOverrideSecurityMinimum;
} ApiMac_securityLevelDescriptor_t;

Where can I find all the possible security constant values for both frameType and commandFrameIdentifier? The example only lists MAC_FRAME_TYPE_DATA and MAC_DATA_REQ_FRAME. I have tried to find the list of possible values here, but have not found any: dev.ti.com/.../struct__apimac__securityleveldescriptor.html