We provide now downlink channel frequency and time on air for the
received frame in the RX metadata.
Previously the channel information in both TX and RX metada contained
the index number of the channel. That information wasn't very useful
except the index numbers of default channels. To make more sense of the
meta data, we now store the channel frequency in the channel parameter
rather than the index number of the channel.
RX time on air is collected from the radio driver and it is assumed that
the downlink frame had 8 downlink preamble symbols (plus 4.25 of the
preambles added by the chip) for LoRa modulation.
This commit also include a bit of tidying of RX frequency storage in rx
configuration parameters storage. Previously we were missing filling in
the RX1 frequency correctly.
A bug while setting up RX start timers would result in premature closusre
of RX2 window. The 'ack_Timeout_timer' would be invoked prematurely and
at that time RX2 window may be being demodulating. This resulted in
massive instability with any test that relied on Confirmed traffic or
lower data rates.
To fix the issue, we must know the length of the RX window in
milliseconds and for this purpose we have extended the
'get_rx_window_params(...)' API. The length of the time the window
may remain open must be accounted for while setting up
'ack_timeout_timer'.
Previously we had been incrementing UL frame counter for a CONFIRMED
message only when the transmission was deemed successful i.e., we would
have received an ack before all the retries would have exhausted.
Now we have opted to increment the frame counter if all the retries are
exhausted considering the fact that we essentially treat the next
message after retry exhaustion as a new packet so we should also
increment the frame counter.
Previously, we weren't filling in RX1 frequecny in rx_window1_config
structure. However, everything worked as in LoRaPHY::rx_config() API
there was a check which filled in correct RX1 frequency.
Now we are filling in RX1 freq. properly while we are computing
parameters for RX1 window.
LinkADRReq mac command can be used by the network server to set a
certain level of QOS using NbTrans field which is applicable to
Unconfirmed traffic only for 1.0.2 spec.
This commit introduces mechanisms to facilitate this QOS. It means to
repeat an outgoing unconfirmed message NbTrans times without changing
its frame counter.
For class C, we have retired the ack_expiry_timer_for_class_c and have
replaced it with another timer which mimics the RX2 closure as in Class
A but doesn't actually close RX2 window. It's just a mechanism by which
the state machine is informed that the you can proceed forward, we have
not received anything in RX2 window either. This is needed as RX2
doesn't timeout in class C (i.e., the radio remains in continuous mode).
In addition to that we need to close any pending timers for Receive
windows after the MIC has passed and the Duplicate counter check has
also been passed.
If the packet is already handed over to the PHY layer, we shouldn't be
able to cancel that particular transmission. In addition to that if the
backoff timer is either not applied or has been deactivated, should end
up in no-op rather than having normal termination. A new error code has
been introduced to cover no-op cases. This error code replaces the
compliance test related error code which is no longer relevant.
clear_tx_pipe() does nothing if:
- The stack cannot cancel TX (already handed over to PHY)
- The backoff timer is not active at all
- The event is disaptched to schedule
stop_sending() will only post process ongoin TX if the pipe was
definitely cleared.
Previously, we weren't filling in RX1 frequecny in rx_window1_config
structure. However, everything worked as in LoRaPHY::rx_config() API
there was a check which filled in correct RX1 frequency.
Now we are filling in RX1 freq. properly while we are computing
parameters for RX1 window.
LinkADRReq mac command can be used by the network server to set a
certain level of QOS using NbTrans field which is applicable to
Unconfirmed traffic only for 1.0.2 spec.
This commit introduces mechanisms to facilitate this QOS. It means to
repeat an outgoing unconfirmed message NbTrans times without changing
its frame counter.
For class C, we have retired the ack_expiry_timer_for_class_c and have
replaced it with another timer which mimics the RX2 closure as in Class
A but doesn't actually close RX2 window. It's just a mechanism by which
the state machine is informed that the you can proceed forward, we have
not received anything in RX2 window either. This is needed as RX2
doesn't timeout in class C (i.e., the radio remains in continuous mode).
In addition to that we need to close any pending timers for Receive
windows after the MIC has passed and the Duplicate counter check has
also been passed.
While performing compliance tests with an industry tester, we realized
that there was no need for any extra handling code for the compliance
tests. The tests would run fine, if we only have a handling application.
However, in normal operation we wouldn't like the network to send us any
traffic on compliance testing port. To mitigate that, on the reception
path we filter out any traffic on compliance testing port if compliance
testing is not underway. User should define LORAWAN_COMPLIANCE_TEST macro
in mbed_app.json to enable traffic on compliance test port.
This commit fixes two bugs related to ADRAckReq:
- adr_ack_counter must be incremented for all uplink messages (not just confirmed)
- When ADR_ACK_LIMIT + ADR_ACK_DELAY has been reached, stack decreased used
datarate twice.
- 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).
LoRaMAC was not initialized properly if application called
connect(const lorawan_connect_t &connect);
This causes problems for example in case where application
first disconnects and then reconnects as counter values are not
initialized.
When node sends a CONFIRMED message and gateway sends ACK in RX1 window but the
message gets corrupted during the transmission (e.g. MIC fails), currently
our stack already checks for retransmission after RX1 and if retries attemps are
exhausted, TX_ERROR event is sent to application. This is wrong as MAC layer
will still attempt reception in RX2 window.
This commit fixes the behaviour so that TX_ERROR is not sent until RX2 window
has been closed.
It is quite possible that the user request for scheduling an uplink is deferred because of backoff or if it was a CONFIRMED message, a retry may take place on a different datarate and different channel.
We didn't have a hook for such deferred scheduling, telling the user whether the async rescheduling worked or not. This commit adds that capability and now we can tell the application if a scheduling failure took place after the original schedule request was accepted.
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.
The issue rose up when using ARMC6. A test case didn't initialize NetID
parameter for ABP while using connect(params) API. NetID is the first 7 bits
of the Device Address. It makes sense to actually remove the net-id parameter
from ABP settings as the stack can deduce it from device address. However, the ABP
structure is exposed in public APIs, so we can't really do that at the moment.
Simpler fix is to move the mask that helps us to extract first 7 bits of the device address
is exposed in lorawan_types.h and the user can use it to deduce correct net-id.
The stack was trying to connect with default data rates which happened to be
the lowest data rates in a specific region. In the beginning device and NS do
not have agreed upon tx rx parameters and there can be synchronization issues.
When we use lower datarates, we may end up having a minute and a half long
transmissions that hnot only blocks the channel for a long time but also reduce
the chance of proper synch between device and NS. That's why we have decided to
begin with higher data rates and gradually decrease datarate if we do not hear
from the network server.
This commit fixes some bugs from cancel_sending() method:
- System crashed if method was called before initialization.
Now LORAWAN_STATUS_NOT_INITIALIZED will be returned.
- Method returned LORAWAN_STATUS_BUSY error when no send request was pending.
LORAWAN_STATUS_OK should be returned in this case.
- LORAWAN_STATUS_BUSY is now returned if backoff timer is just about to be
dispatched (time_left returns 0).
51f92b0efd introduced
handling for connection attempts while a connection was already underway or have been
completed. Unfortunately a similar check slipped through and the stack was not able to continue
sending join requests if an error happened.
It was pointed out in #7432 and #7232 that the stack was comparing frame payload size
with the allowed payload size in a wrong manner in shcedule_tx().
We must strip the overhead from the frame before comparison.
We did have a similar check in prepare_ongoing_tx() API which would correctly analyse
the situation but a check was needed in schedule_tx() as well. The reason is that the
schedule_tx() API can be called automatically by the stack if the user intiated requested
was not promptly entertained because of duty cycle restriction. Now, the datarate can change
here (for CONFIRMED messages if the ack was not received after retries max out). That's why
a test for validity was needed.
We now perform a comparison using _ongoing_tx_message structure which contains the actual
FRMPayload size.
For proprietary type of messages only MHDR and Port field is used so we shouldn't add MAC commands
and other overhead into them.
In order to have consistent frame overhead, we have opted to always include Port field in the
frame.
This is a remedy for the issue #7230.
While the device is joining, LORAWAN_STATUS_CONNECT_IN_PROGRESS is returned.
However, if the device is already joined, we will return LORAWAN_STATUS_ALREADY_CONNECTED.
Instead of giving LoRaWANTimeHandler object as parameter for constructor,
object is now given via own initialize() method.
This change is needed for future refactoring where application can give own
PHY object for LoRa stack.
In rx_config(params) API we shouldn't check for radio state as radio may never get
idle for a class C device. That check made sense only for class A. As the PHY layer
have no conecpt of receive windows which is a MAC layer construct, we should remove the
state check.
The API will be changed later to void rx_config(params).
In addition to that another bug is fixed in the open_rx2_windows() API. We should set the rx slot
first before instantiating a test based on its value.
This commit fixes the issue reported in #7285.
If the radio is unable to transmit, its a fatal error and can happen
both while joining or sending a normal packet. In the case of such
a catastrophy we ought to tell the application that this happened.
A fix for the radio driver will also be patched.
receive(uint32_t) API in the LoRaRadio class (base class for the radio drivers) should
not take any argument as we decided to take hardware timers for RX timeout interrupts
instead of software timers. It is being refactored to receive(void).
This is an API change, but as it is not an application interface, we will not put a
deprecation notice. Only user of this API is our stack (LoRaPHY layer) which has been updated
accordingly.
Actual driver comes out of the tree and a PR is open there to update the drivers:
https://github.com/ARMmbed/mbed-semtech-lora-rf-drivers/pull/22
In addition to this an internal API belonging to LoRaPHY class is refactored.
set_rx_window(parameters) is refactored to handle_receive(void) which is more consistent with
handle_send().
Hasnain Virk
Cruz Monrreal
itziar
Antti Kauppila
Martin Kojtal
Kimmo Vaisanen