Downlink frame sent feature

  • 1 december 2016
  • 17 reacties
  • 1369 keer bekeken

  • Productmanager LoRa for Developers
  • 9 reacties
A feature has been added that lets the LRR notify the LRC if a downlink frame has been sent or not. When the downlink frame can’t be sent, the reason is reported to the LRC. The LRC reports this report indication to the AS which sent the downlink frame (if this feature is activated). The LRC also sets this indication in the downlink frame report to Thingpark.

- Reported to third party AS in a new HTTP request
- Downlink sent indication is displayed over the Wireless Logger GUI by displaying a cross instead of arrow
- Distribution reports of downlink delivery status is displayed in the Device Manager GUI

Follow this link to find an example of a message with an indication of the delivery status.

The LRR reports a downlink sent indication to the LRC as soon as the downlink frame is effectively transmitted or cancelled. The downlink sent indication report contains following parameters:

 DevEUI_downlink_Sent/DeliveryStatus (MANDATORY enumerate)
Sent // the frame has been provided to the RF component
Failed // the frame has not been provided to the RF component
 DevEUI_downlink_Sent/DeliveryFailedCause1 (OPTIONAL hex byte) - Default value: 00
//This gives the status of transmission over Rx1
// 0x: Success
00: "Success"
 // Ax: Class A: Transmission slot busy on RX1
A0: "Radio stopped"
A1: "Downlink radio stopped"
A2: "RX1 not available" // theoretically impossible
A3: "Radio busy"
A4: "Listen before talk (LBT): channel busy"
 // Bx: Class A: Too late for RX1
B0: "Frame received too late for RX1"
 // Cx: Class A: LRC selects RX2
C0: "LRC selected RX2"
 // Dx: Class A: Duty Cycle constraint on RX1
D0: "Duty cycle constraint detected by LRR"
DA: "Duty cycle constraint detected by LRC" (generated by LRC in ThingPark version 3.2)

 // Ax: Class A: Transmission slot busy on RX2
A0: "Radio stopped"
A1: "Downlink radio stopped"
A2: "RX2 not available"
A3: "Radio busy"
A4: "Listen before talk(LBT): channel busy"
 // Bx: Class A: Too late for RX2
B0: "Frame received too late for RX2"
 // Dx: Class A: DC constraint on RX2
D0: "Duty cycle constraint detected by LRR"
DA: "Duty cycle constraint detected by LRC" (generated by LRC in ThingPark version 3.2)

17 reacties

Wordt die deliverystatus altijd teruggegeven aan de AS bij alle Downlink messages? Waar kan ik vinden wat die deliveryfailedcause foutcodes betekenen? En, betekent een waarde "00" bij deliveryfailedstatus1 en deliveryfailedstatus2 dat 't device het Downlink bericht zonder foutmeldingen ontvangen heeft?
Hallo x62,

De delivery status wordt inderdaad altijd terug gegeven door de Network Server. Ik heb in de post de mogelijke responses toegevoegd.
"00" betekent inderdaad een succesvolle transmissie.
Hallo Timme, Hoe verloopt het proces rondom downlink message? Is dit nu enkel iets tussen LRC en AS (zie 2) of is dit iets tussen node en AS (zie 1)?

1. De node geeft een Acknowledgement of Confirmed Data Messages door aan de LRR, dat resulteert in een downlink message naar de AS (meer jouw verhaal hierboven).

2. michieljol Productmanager LoRa for Developers meldt: "When a downlink message is received succesfully, a HTTP response will tell you that the LRC queued your request." (https://zakelijkforum.kpn.com/lora-forum-16/sending-downlink-messages-8332)
Hallo Peter,

Het is een combinatie van beide antwoorden:

1. De node geeft een Acknowledgement of Data Messages door aan de LRR, dat resulteert in een uplink message naar de AS

En een aanvulling op punt 2
2. michieljol Productmanager LoRa for Developers meldt: "When a downlink message is received succesfully, a HTTP response will tell you that the LRC queued your request." (https://zakelijkforum.kpn.com/lora-forum-16/sending-downlink-messages-8332)

When a downlink message is sent from AS to LRC it confirms the message being queued (LRC queued your request), if you give confirmed=1 on the URL you will get a “downlink sent” message when the device is received (and acknowledged).


Geeft dat een antwoord op je vraag?
Hallo Timme, Bedankt voor je reactie. Ik begrijp van jouw antwoord dat de LRC een bevestiging stuurt naar de AS als een downlink message succesvol in de queue is geplaatst. Later ontvangt de AS een uplink message, die veroorzaakt wordt door een acknowledge message van de node. Kan jij bevestigen dat het onderstaande bericht het bericht is van de acknowledge? En is de node verplicht de attributen DeliveryFailedCause(x) te vullen en volgens afspraak?

message: {"DevEUI_downlink_Sent": {"Time": "2017-05-23T10:17:09.96+02:00", "DevEUI": "0059AC00001503DA","FPort": "1","FCntDn": "28","FCntUp": "526","Lrcid": "0059AC02","SpFact": "12","SubBand": "G0","Channel": "LC255","Lrrid": "FF0107BA","DeliveryStatus": "1","DeliveryFailedCause1": "C0","DeliveryFailedCause2": "00","DeliveryFailedCause3": "00","CustomerID": "100006334","CustomerData": {"alr":{"pro":"Fast moving","ver":"1"}}}} - created:23-5-2017 10:17:11
Hallo Peter,

Zie onderstaand:

When a downlink message is sent from AS to LRC it confirms the message being queued (LRC queued your request), you will get a “downlink sent” message when the message is sent (nothing about if it is received).
if you give confirmed=1 on the URL a confirmed downlink will be send and on the next uplink the ACK flag is set by the device.


DeliveryStatus The over the air delivery status:
- 0: Downlink frame was sent over the air (either on RX1 or RX2). This means that the downlink frame was transmitted, over the air, by the LRR. But the downlink frame may not have been received by the device.
- 1: Downlink frame was not sent over the air (neither on RX1 nor RX2). The downlink frame is not retransmitted by the network server. Accordingly the downlink frame will have to be reinitiated by the application server.

DeliveryFailedCause1 The over the air delivery error cause for RX1.
Class A device: Transmission slot busy on RX1: - A0: "Radio stopped" - A1: "Downlink radio stopped" - A3: "Radio busy" - A4: "Listen before talk"
Class A device: Received too late for RX1: - B0: "Too late for RX1"
Class A device: LRC selects RX2: - C0: "LRC chooses RX2"
Class A device: DC constraint on RX1: - D0: "Duty cycle constraint detected by LRR" - DA: "Duty cycle constraint detected by LRC"
NOTE: DeliveryFailedCause1 is set to 00 (or is not filled) when no error occurs on RX1.

DeliveryFailedCause2 The over the air delivery error cause for RX2.
Class A device: Transmission slot busy on RX2: - A0: "Radio stopped" - A1: "Downlink radio stopped" - A3: "Radio busy" - A4: "Listen before talk"
Class A device: Received too late for RX2: - B0: "Too late for RX2"
Class A device: DC constraint on RX2: - D0: "Duty cycle constraint detected by LRR" - DA: "Duty cycle constraint detected by LRC"
Class C device: DC constraint on RX2: - E0: "Max delay for Class C" (60 seconds)
NOTE: DeliveryFailedCause2 is set to 00 (or is not filled) when no error occurs on RX2.
Reputatie 1
Badge

When a downlink message is sent from AS to LRC it confirms the message being queued (LRC queued your request), if you give confirmed=1 on the URL you will get a “downlink sent” message when the device is received (and acknowledged).


Als ik een unconfirmed downlink stuur ontvangt de applicatie server een "downlink sent" bericht, als ik een confirmed downlink stuur ontvang de applicatie server niks.

Bijv. downlink request:


Response:
DevEUI_downlink_Sent:
Time: "2018-01-03T17:18:23.669+01:00"
DevEUI: "DEADBEEF"
FPort: "1"
DeliveryStatus: "1"

etc.

Bug in ThinkPark?
Reputatie 1
Badge
@Timme?
Reputatie 7
Badge +11
Hi @IAS, dat is een hele interessante melding!

- Bij een unconfirmed downlink, ontvangt u wel een confirmation
- Bij een confirmed downlink, ontvangt u geen confirmation

Het lijkt dus eigenlijk verkeerd om te gaan nu begrijp ik? 🤔
Reputatie 1
Badge
@TimDat klopt.
Zoals je in mijn reactie hierboven kunt zien stuur ik een bericht met parameter confirmed=0 en ontvang vervolgens kort daarop een bericht 'downlink_Sent'. Bij confirmed=1 ontvang ik geen 'downlink_Sent' bericht.

Is dit een bug of onbegrip van mij?
Reputatie 7
Badge +11
@TimIs dit een bug of onbegrip van mij?
Hele goede vraag, dit gaan we uitzoeken! U ontvangt een inhoudelijke reactie zodra we meer weten.
Reputatie 3
Badge
Hi @IAS,

Excuus voor de late respons, wij moesten een en ander zelf testen alvorens we antwoord op je vraag konden geven.

Als je een bericht queued hebt met een post naar de LRC (netwerk server) dan krijg je een antwoord of het queuen gelukt is in de volgende vorm:
code:
< html>< body>Request queued by LRC< / body>< / html>


Als het netwerk daadwerkelijk het bericht verstuurd naar het device (bij een klasse A device na de eerstvolgende uplink) dan krijg je via je Applicatie Server een DevEUI_downlink_Sent bericht met daarin de informatie of het bericht de ether is in gestuurd. (dit vertelt niks over of het bericht is aangekomen bij het device). Dit bericht krijgen wij bij onze tests zowel bij confirmed als bij unconfirmed downlink berichten.

Bij een confirmed bericht zal het device ook nog moeten reageren met een uplink bericht waarin het ACK bit op 1 is gezet. Dit zou dan ook weer naar de Applicatie Server gestuurd moeten worden en dit is dan het bewijs dat het bericht echt is aangekomen op het device.

Op dit moment zit er nog een bug in het netwerk op het moment dat het device het ACK bericht terug stuurt op Fport 0, namelijk dat dit niet wordt doorgestuurd naar de Applicatie Server, maar alleen in de Wlogger te zien is. Er wordt nog gewerkt aan het verhelpen van deze bug.

Dus het statement
- Bij een unconfirmed downlink, ontvangt u wel een confirmation
- Bij een confirmed downlink, ontvangt u geen confirmation
is mijns inziens niet correct, want je ontvangt bij beide de berichten een DevEUI_downlink_Sent.

Met vriendelijke groet,
Lennart
Reputatie 1
Badge
@Lennart NordinBedankt voor je uitgebreide antwoord. Ik ga verder testen of ik de ACK terugzie in wlogger en of ik bij een confirmed bericht ook een downlink_Sent bericht krijg (bij mijn eerdere testen kreeg ik namelijk bij een confirmed bericht geen downlink_Sent). Ik meld me hier weer met mijn bevindingen.

Weet je toevallig of een stock RN2483 1.0.3. standaard op Fport 0 antwoordt?
Reputatie 3
Badge
Hi IAS,

Succes met het testen. Als je er niet uitkomt en je hebt een vraag over een specifiek device, meld dan ook het DevEUI even, dan kunnen we ook naar dat specifieke device kijken.

- Weet je toevallig of een stock RN2483 1.0.3. standaard op Fport 0 antwoordt?
Ja, dit is inderdaad het geval. Elke acknowledgement door het device (op een confirmed downlink vanuit de Applicatie Server) wordt verstuurd op FPort 0, mits deze confirmation direct wordt verstuurd.
Als de confirmation wordt meegestuurd met het volgende uplink bericht, dan komt deze confirmation wel in de Applicatie Server aan omdat het bericht wordt meegestuurd op de poort waarop het uplink bericht wordt verstuurd.
Reputatie 1
Badge
@Lennart NordinAls de confirmation wordt meegestuurd met het volgende uplink bericht, dan komt deze confirmation wel in de Applicatie Server aan omdat het bericht wordt meegestuurd op de poort waarop het uplink bericht wordt verstuurd.
Gezien het gebruik van stock RN's heb ik geen invloed op de manier waarop de module de ACK stuurt en ben ik voor een confirmed download afhankelijk van het verhelpen van de netwerk bug. Klopt dat? En is er een ETA waarop deze bug opgelost wordt?
Reputatie 3
Badge
Hi IAS,

Ik ben bang dat ik geen verwachting kan geven wanneer deze bug verholpen is, omdat dit door onze software leverancier opgelost moet worden. Desalniettemin ga ik voor je navragen of er een verwachting gegeven kan worden.
Wat betreft je andere vraag, m.b.t. de invloed die je hebt op de poort van de stock RN module weet ik niet direct het antwoord, maar ook daar ga ik achteraan.

Met vriendelijke groet,
Lennart
Reputatie 3
Badge
Hi IAS,

Hieronder antwoord op de laatste vragen die nog resteerden. Gezien het gebruik van stock RN's heb ik geen invloed op de manier waarop de module de ACK stuurt en ben ik voor een confirmed download afhankelijk van het verhelpen van de netwerk bug. Klopt dat? Een leeg bericht wordt altijd op poort 0 gestuurd, daar heb je geen invloed op. Op welke poort een data-bericht gestuurd wordt kan je aansturen vanuit de applicatie. Misschien dat er nog een instelling is die je kan doen van de module die voorschrijft dat met de ACK gewacht moet worden op het volgende data-bericht, maar dat weet ik niet, dat zou in de datasheet opgezocht moeten worden.
Bijvoorbeeld de imst-module heeft dat volgens mij wel. En is er een ETA waarop deze bug opgelost wordt? Zoals ik al dacht kunnen wij hier vanuit onze software leverancier helaas geen verwachting voor geven.

Reageer