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

98 lines
3.9 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": {
Removing US915Hybrid PHY This phy implementation was just to support a single sub-band in US region. As we have decided to make FSBs configurable, we do not need this class anymore.
2018-08-16 09:59:12 +00:00
"help": "LoRa PHY region: EU868, AS923, AU915, CN470, CN779, EU433, IN865, KR920, US915",
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
"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
},
Lora: Refactor duty-cycle configuration and introduce config for JOIN request - Duty cycle can be now only disabled with duty-cycle-on flag if region supports duty-cycle. If region does not support duty-cycle, this flag has no effect and duty cycle is always disabled. - Also introduced a new flag (duty-cycle-on-join) to disable duty cycle for JOIN requests. This flag can be used for testing only and is used to speed up JOIN request testing as backoff times for JOIN request are really long (easily several minutes per attempt). This flag works in conjunction with main duty cycle setting. Disabling duty-cycle-on-join works only if duty-cycle-on is disabled (or region settings have duty cycle disabled).
2018-08-17 11:08:27 +00:00
"duty-cycle-on-join": {
"help": "Enables/disables duty cycling for JOIN requests (disabling requires duty-cycle-on to be disabled). NOTE: Disable only for testing!",
"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
Making recv timing error and preamble length configurable We had a bug especially in the reception path. Our recv window opening delays were being calculated on the premise that the radio has to capture 5 preamble symbols out of 8 transmitted by the base station. However, in PHY layer while setting radio rc settings, we were setting preamble length to be 8. Preamble length register needs to be configured differently for Uplink and Downlink. For uplink, we wish to transmit 8 preamble symbols whereas in the reception path we need to receive 5 preamble symbols at least out of 8. Alongwith that the maximum range of timing error may vary from platform to platform as it is based upon the crystal in the chip. We have now made these parameters configurable and have loaded them with the most optimal defaults.
2018-07-26 11:11:56 +00:00
},
"max-sys-rx-error": {
RX window calculation algorithm version 2 In this version we try to mitigate a situation when we start listening right in the middle of a preamble sequence (e.g., in high SF case).
2018-11-28 13:19:54 +00:00
"help": "Max. timing error fudge. The receiver will turn on in [-RxError : + RxError]",
"value": 5
},
"wakeup-time": {
"help": "Time in (ms) the platform takes to wakeup from sleep/deep sleep state. This number is platform dependent",
"value": 5
Making recv timing error and preamble length configurable We had a bug especially in the reception path. Our recv window opening delays were being calculated on the premise that the radio has to capture 5 preamble symbols out of 8 transmitted by the base station. However, in PHY layer while setting radio rc settings, we were setting preamble length to be 8. Preamble length register needs to be configured differently for Uplink and Downlink. For uplink, we wish to transmit 8 preamble symbols whereas in the reception path we need to receive 5 preamble symbols at least out of 8. Alongwith that the maximum range of timing error may vary from platform to platform as it is based upon the crystal in the chip. We have now made these parameters configurable and have loaded them with the most optimal defaults.
2018-07-26 11:11:56 +00:00
},
"downlink-preamble-length": {
Final cleanup and ASCII art for algorithm v2 Final code cleanup and adding ascii art for the version 2 of the algorithm.
2018-12-07 10:47:06 +00:00
"help": "Number of whole preamble symbols needed to have a firm lock on the signal.",
RX window calculation algorithm version 2 In this version we try to mitigate a situation when we start listening right in the middle of a preamble sequence (e.g., in high SF case).
2018-11-28 13:19:54 +00:00
"value": 5
Making recv timing error and preamble length configurable We had a bug especially in the reception path. Our recv window opening delays were being calculated on the premise that the radio has to capture 5 preamble symbols out of 8 transmitted by the base station. However, in PHY layer while setting radio rc settings, we were setting preamble length to be 8. Preamble length register needs to be configured differently for Uplink and Downlink. For uplink, we wish to transmit 8 preamble symbols whereas in the reception path we need to receive 5 preamble symbols at least out of 8. Alongwith that the maximum range of timing error may vary from platform to platform as it is based upon the crystal in the chip. We have now made these parameters configurable and have loaded them with the most optimal defaults.
2018-07-26 11:11:56 +00:00
},
"uplink-preamble-length": {
Mitigating reception problems with lower data rates A new algorithm has been taken in use to calculate the receive window length and the timing offset involved in opening of the said receive window. This algorithm performs better than the stock algorthm and consumes less power.
2018-11-27 10:53:15 +00:00
"help": "Number of preamble symbols to transmit. Default: 8",
"value": 8
Adding FSB selection feature for US915 PHY User can now define a custom frequency sub-band for the US915 PHY. FSB_Usage.txt defines how this parameter will be configured.
2018-08-13 08:22:31 +00:00
},
"fsb-mask": {
Style alignment Minor style alignment.
2018-11-27 10:55:37 +00:00
"help": "FSB mask for upstream [Only for US915 & AU915] Check lorawan/FSB_Usage.txt for more details",
"value": "{0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0x00FF}"
Adding override for TX ch. selection in CN470 PHY set_next_channel() is the base function provided by LoRaPHY class and should be overridden by the PHYs who behave differently as compared to EU868 like PHY layers. CN470 PHY had been missing such an override. In addition to that we have provided a parameter "fsb-mask-china" that can be used to enforce a custom frequency sub-band of operation as most of the base stations in the market may not support all 96 channels. Such a strategy will help in rapid network acquisition.
2018-08-16 13:17:59 +00:00
},
"fsb-mask-china": {
Style alignment Minor style alignment.
2018-11-27 10:55:37 +00:00
"help": "FSB mask for upstream [CN470 PHY] Check lorawan/FSB_Usage.txt for more details",
"value": "{0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF}"
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
}
}
}