Create a Loriot service

[rhythnic]

Create the Loriot networkProtocol handler.

[rhythnic]

Refactoring "NetworkProtocolAccess", which is how the models interact with network protocol implementations. It is where sessions are cached. There is a map of network protocols, but the keys used within the map are confusing. Firstly, the top-level keys used in the networkProtocol map are network IDs, not networkProtocol IDs. There is also a nested object called sessionData, which is where sessions are cached. Network IDs are used again as the key to the session cache, but then the username from the network credentials is used when removing the session from cache. I'm going to update to make networkProtocol IDs the top-level key and use network IDs consistently as the session cache key.

[rhythnic]

LoRa NetworkProtocol handlers are calling PUT /devices/{devEUI}/activate, which doesn't exist. Will change to DELETE activation and then POST new activation.

[rhythnic]

In regards to the company discussion, I like the idea of companies; however, the problem is that the implementation of companies is coupled with companies on network servers. I think they should be separate. Credentials specified for an account on a network server should already be scoped to a company on that server. LPWAN Server should not attempt to create companies or users on network servers.

[rhythnic]

When creating a company on LoRa Server, the network settings are not saved in CompanyNetworkTypeLink afterwords. They are only added to the object in memory, but then the function returns and the data is not saved. Will change to persist. I don't think the tests cover creating an org on LoRa Server.

[rhythnic]

A network session is being stored in the record, including access token. The only reason I can find for doing this is that a networkProtocol handler's "test" method gets the access token from the network record instead of being passed the session like the other methods. Will refactor to pass session to "test" method. "test" is also updating the in-memory record after testing, but not persisting.

[rhythnic]

Encountered an issue where the cache in the networkProtocolDataAccess.js was causing a deviceNetworkTypeLink to return missing the deviceProfile reference, even though the ref is in the DB. Going to disable all caching in that file.

[rhythnic]

There seems to be a conflict in ApplicationNetworkTypeLink.networkSettings in that the network-specific IDs aren't nested according to the network. For instance, AppNtwkTypeLink.networkSettings.serviceProfileID gets set according to the network from which the app was pulled, but when that app get's pushed to a different network, that serviceProfileID would be wrong.

It's working in the case of LoRa server because when building the app to submit to LoRa Server, LPWAN Server ignores the references in AppNtwkTypeLink.networkSetting and passes new references to the "denormalize" function. LPWAN Server is storing each of the references in a remote application separately via dataAPI.putProtocolDataForKey, using cryptic key names like coSPId. I'm going to update networkSettings to not store references to reduce the confusion.

[rhythnic]

Loriot requires creating an application with a capacity prop (how many devices it supports). I got a "too many devices for new dev" error when trying 1000 and 100, so it's hard coded to 10 now.

[rhythnic]

Loriot doesn't support DeviceProfiles. I'm looking at TTN as an example of what to do because TTN also doesn't support it. A DeviceProfile reference is required for DeviceNetworkTypeLink, so TTN is creating a DeviceProfile for every device pulled. I don't like that solution, but I'm going to do the same with Loriot because to refactor so that it's not required would take too long.

[rhythnic]

Loriot devices have fCntUp of -1 if they haven't joined. It causes an error on LoRa Server device activation, so I added a check. Devices pulled from Loriot will not be activated on LoRa Server if the fCntUp is less than 0.

[rhythnic]

I've started to restrict the activation of devices depending on network protocol version. Before, all LoRa activation properties were normalized to MAC version 1.1, and all device activations were pushed everywhere. After reading the spec and talking with Orne on Slack, its apparently problematic to transfer sessions as the default behavior.

• LoRaWAN 1.1 devices can't transfer at all to LoRaWAN 1.0 servers, as the serve won't support the device.
• LoRaWAN sessions can't transfer across versions, for either ABP or OTAA
• ABP devices can only transfer name/description and other basic device props across versions.
• OTAA devices can transfer keys from 1.0 to 1.1, if the 1.1 server supports 1.0, but activation props can't transfer.

I've set it up in LoRa Server and Loriot so sessions only transfer when Devices/DeviceProfiles have the same major+minor version. I've stopped attempting to normalize device activation properties, and DeviceNetworkTypeLink.networkSettings contains the activation properties pulled from the network, with normalized names (fCntUp, fCntDwn). Since they are only pushed to networks of the same version, it doesn't need normalized across versions.

The previous strategy meant that in the UI, activation properties could always be for LoRaWAN 1.1, since they were denormalized to LoRaWAN 1.0 when pushed to a 1.0 network server. In the UI, activation fields don't reflect the MAC version. I think the activation fields should reflect the MAC version. I made an issue for it in web client: https://github.com/cablelabs/lpwanserver-web-client/issues/63

Creating a device within LPWAN Server is where I get confused. If there are LoRa networks of both LoRaWAN MAC versions, and you create a device:

• Is there any point in pushing a 1.1 device to the 1.0 network?
• For a 1.1 device, if devices can be active on multiple LoRa networks at a time (can they?), you could format the activation props for ABP devices to support activating that device on multiple networks, but right now LPWAN server can't discriminate devices created in LPWAN, so behavior that would support that would also enable transferring incompatible sessions.

[rhythnic]

The keys used to encrypt the network security data payloads are also being stored in the DB. If DB is compromised, it doesn't matter much that the security data is encrypted because the acting party will also have access to the keys to decrypt the security data. It would be better to use a key or secret in the environment.