Use close_rx_window callback to disable active class b window. This change protects against disabling the radio during class A transmit
Move class B resume notification to one location in LoRaMac::set_tx_ongoing()
The Rx done/timeout event handler now checks if the radio is currently
transmitting before putting the radio to sleep. This test returns true in
class A rx window event handlers, so the radio is not not put to sleep.
Now to accurately test if transmitting, a mod ongoing flag is set true on send
and false on tx done/timeout.
Make class function names lower case. Previously, class b's public interface was part of the class and to avoid function name conflicts the static API was being distinguished from instance methods by upper-casing the first letter.
Fixed by moving the public interface to new LoRaMacClassBInterface
As per discussion with Nicolas Sornin, any device time synchronization
value must be handled as is (monotonically increasing GPS epoch time guaranteed to be monotonic with granularity 1 second).
Once we receive a response to DevTimeReq (i.e., DevTimeAns is received)
we immediately set our local gps time stamp and take a snapshot of our
local monotonic (ticker or equivalent) clock. This is achieved by
calling 'set_gps_time(...)' API in the LoRaWANTimer module.
After that an event is generated to let the application know that a
device time has been synched.
LoRaWANTimer class is responsible for providing time base for the
LoRaWAN stack in Mbed OS. It derives its core monotonic clock from the
EventQueue which is essentially a millisecond ticker or equivalent (in
tickless mode). LoRaWAN network can assist the device for device level
time synchronization using ClockSynchronization protocol (for v1.0.2) or
by replying to DevTimeReq MAC command (for v1.0.3 and above). The time
base used for device synchronization using above methods is purely
based on GPS epoch and needs no conversion to UTC or TAI etc (no
adjustment for leap seconds either).
Therefore we have extended the LoRaWANTimer APIs to account for GPS time
base if assisted by the network.
get_gps_time() is the API to use to acquire GPS time base from the
stack. If the network never assisted the device with a time stamp, a
value of zero is returned which means GPS time base is not available.
set_gps_time(time) API is used to set a given GPS time-stamp when the
network sends it.
These APIs are hooked via LoRaMAC to LoRaWANInterface which exposes the
access to the application.
The application can use add_device_time_request() API to attach
DeviceTimeRequest mac command for the next outgoing packet.
It is a non-stick mac command, so if there is no response, the app can
retry. The API indicates if the mac command was queued successfully or
not. The actual indication of successful time and date update will come
through an event 'DEVICE_TIME_SYNCHED'.
* While starting timer for rejoin request type 0, we should multiply max
time with 1000 as the timer APIs take ms values as parameters.
* RJCountX are incremented every time a Rejoin request is sent. For MIC
calculation we need to take the previous RJCnt value in account.
* Rejoin process should start against an event otherwise it will meddle
with state machine and any ongoing traffic.
* If a Type 1 rejoin is ongoing, we should not trigger a Type 0 rejoin.
* Some bug fixes after Triage with Antti.
In 1.1, NbTrans governs both unconfirmed and confirmed traffic.
We cannot set number of retries ourselves. Based upon NbTrans received
in linkADRReq command, we will retry. If NbTrans is 1, we will send only
one message and if ack is not received we will generate TX error event.
Its the NS now which controls how many retransmission a device can do
without incrementing Frame counter. When we fail with TX error after not
receiving an ack, we increment the frame counter. This is necessary as
the NS will drop anything with the previous counter and it can happen
that the NS may have sent an ack but we didn't receive it.
Rejoin requests and presence/absence of CFlist demand different
handling.
If a Rejoin request was sent we shall use RJCountX (0,1) instead of dev
nonce for key derivation.
If a Rejoin request is not of type 2, we reset mac, phy parameters
alongwith frame counters. However, if it is type 2, we reset frame
counters only.
If cflist i present, we shall always apply it as it is.
If it's not and rejoin type is not type 2, we restore default channels.
Otherwise the local channels do not change.
LoRaWAN specification 1.1.0 is incorrect in handling of FOpts encrytpion.
A CR was made by STMicroelectronics which correctly addresses the issue.
We have taken that CR and implemented in our code base.
Although we always add a port field for Uplink traffic, the spec allows
for fport field to be excluded. So there can be network server instances
which would exclude fport field from downlinks. We are now adding
handling for such situations.
BE to LE fixes, missing MLME types added
LoRaWAN 1.1 Features added (Some LoRaPhy impl missing still + some TODOs in code)
- MLME confirm handling refactored
- Rejoin handling missing
- new CF_LIST mechanism missing (+resets involved)
- NVM handling missing
Rejoin logic added
_ongoing_tx_msg was incorrectly initialized before _mlme_confirmation.
Fixes following build warning:
[Warning] LoRaMac.h@691,26: 'LoRaMac::_ongoing_tx_msg' will be initialized after [-Wreorder]
[Warning] LoRaMac.h@689,28: 'loramac_mlme_confirm_t LoRaMac::_mlme_confirmation' [-Wreorder]
[Warning] LoRaMac.cpp@68,1: when initialized here [-Wreorder]
This prevents RX2 window to be enabled at the same time when repeating
transmission, when QoS repeated TX is in effect. Failure to do so
seems to place the LoRaWAN stack in a state where send() always fails
with WOULD_BLOCK error.
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.
Roman Volosatovs
Antti Kauppila
Unknown
Hasnain Virk
Kimmo Vaisanen
Kevin Bracey
Hugues Kamba
Teijo Kinnunen
Cruz Monrreal
itziar
Martin Kojtal