ARMmbed
/
mbed-os
mirror of https://github.com/ARMmbed/mbed-os.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
mbed-os/features/lorawan/mbed_lib.json

70 lines
2.7 KiB
JSON
Raw Normal View History

Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
{
"name": "lora",
"config": {
"phy": {
LoRa: Improved handling of region selection - This implements IOTCELL-697 - This touches API, but does not break it, old ones still work in a same manner!
2018-04-06 06:33:50 +00:00
"help": "LoRa PHY region: EU868, AS923, AU915, CN470, CN779, EU433, IN865, KR920, US915, US915_HYBRID",
"value": "EU868"
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
},
"over-the-air-activation": {
"help": "When set to 1 the application uses the Over-the-Air activation procedure, default: true",
"value": true
},
"nb-trials": {
Major PHY layer modifications The PHY layer had a lot of duplicated code in various geographic regions. In this commit we have tried to concentrate all common functionaliy into one single class which LoRaPHY that provides three kind of methods: i) Non virtual base methods which are there for upper layer use, e.g., providing access to driver or generic PHY layer functionality which needs to be exposed to upper layers. ii) Virtual methods (no hard limit on implementation) that can be overriden in derived classes. Some PHY implementations will need that as they may come with very peculiar channel schemes, e.g., dynamic channel schemes in US bands. iii) Protected methods which are only available for the derived PHYs We have adopted a mechanism for the dervied PHYs to announce their differenmtiating parameters in their constructors by filling up a data structure known as lora_phy_params_t which exists at base level. Access modifier for this data structure is protected so it can only be used by the base or derived classes, i.e., no exposure to upper layers. For extra functionality and differentiating controls, a derived PHY can override any virual method as necessary. In addition to that we have adopted the Mbed-OS style guide and have changed data structures and code to reflect that. Some data structures are removed. * Algorithm to get alternate DR is modified. Current scheme, works as multiples of 6 as EU and EU like PHYs provide 6 datarates. We make sure that we try a datarate at least once. If nuber of join retries is a multiple of 6, we may try multiple times on each data rate. * Most of the PHYs with dynamic channel plans, always override the above mentioned algorithm as the rules governing this algorithm do not hild in their case. * band_t data structure is enhanced with lower band frequency and higher band frequency. That enables us to validate frequency based upon the band and hence we can have a single function for all PHYs to validate frequency. * In some PHYs, there were some extra channel masks were defined which were not being used. Hence removed. * EIRP table corrected in some PHYs based upon spec. * PHY functions in response to Mac commands are renamed to reflect what they exactly do. for example accept_rx_param_setup_req() because that's what they do. they can either accept the mac command or reject it.# Please enter the commit message for your changes.
2018-01-16 14:58:18 +00:00
"help": "Indicates how many times join can be tried, default: 12",
"value": 12
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
},
"device-eui": {
"help": "Mote device IEEE EUI",
"value": "{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}"
},
"application-eui": {
"help": "Application IEEE EUI",
"value": "{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}"
},
"application-key": {
"help": "AES encryption/decryption cipher application key",
"value": "{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}"
},
"device-address": {
"help": "Device address on the network",
"value": "0x00000000"
},
"nwkskey": {
"help": "AES encryption/decryption cipher network session key",
"value": "{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}"
},
"appskey": {
"help": "AES encryption/decryption cipher application session key",
"value": "{0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}"
},
"app-port": {
"help": "LoRaWAN application port, default: 15",
"value": 15
},
"tx-max-size": {
"help": "User application data buffer maximum size, default: 64, MAX: 255",
"value": 64
},
"adr-on": {
"help": "LoRaWAN Adaptive Data Rate, default: 1",
"value": 1
},
"public-network": {
"help": "LoRaWAN will connect to a public network or private network, true = public network",
"value": true
},
"duty-cycle-on": {
Remove duplicate configuration flags This commit changes code to use directly mbed os configuration system generated compilation flags.
2018-01-11 09:49:52 +00:00
"help": "Enables/disables duty cycling. NOTE: Disable only for testing. Mandatory in many regions.",
"value": true
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
},
"lbt-on": {
Remove duplicate configuration flags This commit changes code to use directly mbed os configuration system generated compilation flags.
2018-01-11 09:49:52 +00:00
"help": "Enables/disables LBT. NOTE: [This feature is not yet integrated].",
"value": false
Lora: Make automatic uplink message configurable Currently lora stack will automatically send an empty uplink message to lora gateway in case of: - Node received message with pending bit set. - Node received MAC command which requires instant response (sticky MAC command) - Node received confirmed message in class C mode This commit makes this configurable via config item "automatic-uplink-message": { "help": "In case of pending bit, class c confirmed message or sticky MAC command, stack will automatically send empty uplink message", "value": true } Default value is true. If sending an empty message fails, stack will send event AUTOMATIC_UPLINK_ERROR application. If automatic uplink sending is disabled, stack will send application UPLINK_REQUIRED -event to indicate application should issue a new uplink to gateway as soon as possible.
2018-04-09 12:11:08 +00:00
},
"automatic-uplink-message": {
"help": "Stack will automatically send an uplink message when lora server requires immediate response",
"value": true
Adding LoRaWANStack class to control MAC and PHY LoRaWANStack class is our controller layer on top of our current MAC and PHY layer. It provides services to an implementation of LoRaWANBase class. It is a singleton class owing to the fact that the mac layer underneath is not a class object. Instead, it uses the MAC via setting mib, mlme, mcps requests and getting responses back from the mac layer using confirmations and indications. In essense this class is a special handle for mac layer underneath which is predominantly reference design based. In future we may refactor the LoRaMac.cpp code to make it object oriented and cleaner. At one end, it binds the application selected radio driver with the PHY layer and at the other end it provides services to upper layers handling the mac via well defined APIs. For proper selection of a PHY layer, user must use Mbed config system. For this purpose an mbed_lib.json is provided which can be overriden by the user defined mbed_app.json. By default the EU868 band is selected as a PHY layer. User must set relevant keys for the selected connection mechanism.
2017-11-27 13:17:18 +00:00
}
}
}