Welkom op het

Zakelijk KPN Forum

Recent online
Beantwoord

MAC Commands implementatie.


Reputatie 1
Hallo KPN LoRa,

Stukje over ons project:
Wij hebben een project met een IMST LoRaWAN module verbonden aan een e-bike. Deze LoRaModule stuurt elke 5 minuten datagegevens + GPS locatie door naar de backoffice.
Wij sturen met ADR: OFF, SF11BW125, joinen via OTAA en ons payload is fixed 45 bytes.

Het probleem dat zich voordoet is, dat wij de maximum payload length overschrijden.
Wij weten dat we maxiumum 51 bytes mogen versturen en daar houden we ons ook aan (45 bytes).
Wij weten ook dat er MAC commands gestopt kunnen worden (piggybacked) in onze payload (Fopts) of direct via port 0.
Nu is de vraag waarom we de error toch krijgen. Aangezien we netjes aan de regels houden van LoRaWAN. We willen ook graag onze fixed 45 bytes payload behouden.

Aantal vragen die we hebben zijn:
- Hoe verkomen we dat de we niet de maximum payload length overschrijden?
- Wat is de maximum aantal bytes dat KPN (server) kan opvragen als mac commands? Of daar meer uitleg over willen geven van de vulling vanuit KPN?
- Is het mogelijk om de mac commands altijd via Port 0 te versturen, zodat wij geen last hebben in onze payload?
- Enige tips om toch onze fixed payload te kunnen versturen en geen last te hebben van mac commands in onze payload?

Het probleem doet zich al een tijd voor. Meestal na twee uplinks na registratie in het network, valt de module in de error. Het project is van een Klant van ons, en het project loop als een stuk achter. Ik hoop daarom dat u mij snel informatie kunt geven over dit probleem

Ik hoop dat mijn probleem duidelijk is. Ik hoor graag alle tips of vragen.

Vriendelijke groeten,
Martijn G.
Betronic BV
icon

Beste antwoord door Lennart Nordin 8 januari 2018, 17:23

Below a summary of the questions and answers in this post:

What LoRaWAN specification version is KPN following?
KPN currently had the LoRaWAN1.02 specification implemented in the network.

Why does the network keep sending a DevStatusReq?

There was an issue with the DevStatusReq algorithm, which was fixed some time ago.

ADR (Adaptive Data Rate) is OFF on the End Device, however, the network keeps sending a LinkADRReq. Why is this the case?

Firstly, ADR OFF is only advised for constantly moving devices.
If the device refuses a channel mask, then, the LRC resets this device. This means that the network will later on resend these channels again
Even if ADR=0 in uplink frames, the LRC (networkserver) still needs to send a LinkADRReq command to update the channel mask (ChMask). Other fields of the LinkADRReq command (such as DataRate and TxPower) are not controlled by the LRC, only the ChMask field is. LoRaWAN 1.1 added a clarification about that to allow the network server to send a ChMask to the device (via LinkADRReq) even if it has ADR=0.
In short this is thus a work-around for the shortcomings in the LoRaWAN1.0 specification, thus in order for your device to work properly on the KPN LoRa network, the ChannelMask should be acknowledged.

For the implementation:
The “Data rate ACK” and “Power Ack” can be set to 0. The network server is only retrying the message because the Channel Mask Ack bit is set to 0
So a proper response will be with ADR OFF
Data rate ACK 0
Channel Mask ACK 1
Power ACK 0

If MAC commands are longer than 6 bytes those are sent via port 0 in a separate packet. If MAC commands are shorter/equal 6 bytes those are piggybacked within the next customer payload packet.
With this implementation customer is able to use 45 bytes. Is this compliant with the implementation of the KPN network server?

Yes, this is an implication of the way a device implements this. We do not care about this implementation in the device.

Can KPN guarantee that the application can always send 45 bytes or do situations exists (theoretically), in which the transmit of 45 byte user data is not possible due to special MAC commands?

In the LoRaWAN specification it is stated that piggybacked MAC commands may not exceed 6 bytes. This indeed leaves 45 bytes.

Bekijk origineel

21 Reacties

Reputatie 5
Badge +5
Goedemiddag @MartijnG,

Welkom bij de IoT Community!
Bedankt voor de uitgebreide omschrijving van het probleem. Ik heb gistermiddag onze specialisten aangestuurd om op onderzoek te gaan en te kijken hoe we de foutmelding kunnen voorkomen. Op dit moment heb ik nog geen terugkoppeling ontvangen, maar ik houd dit strak in de gaten. Zodra ik wat hoor, speel ik dit gelijk naar u door!

Ik hoop dat we vandaag nog tot de oplossing komen, maar ik kan daar niks in toezeggen.
Reputatie 1
Hallo @Rick S.

Bedankt voor de reactie en hulp.
Ik wacht het af.

Vriendelijke groeten,
Martijn
Reputatie 5
Badge +5
Goedemiddag Martijn,

Het heeft wat langer geduurd dan gepland, maar ik heb een reactie gekregen van de specialisten.
Hieronder het antwoord op uw vragen:

- Hoe verkomen we dat de we niet de maximum payload length overschrijden?

Een manier om te voorkomen dat er teveel data wordt verzonden is om b.v. alleen de wijzigingen op te sturen denk aan +10 ipv 26716610.

- Wat is de maximum aantal bytes dat KPN (server) kan opvragen als mac commands? Of daar meer uitleg over willen geven van de vulling vanuit KPN?

Van het netwerk kunnen we b.v de batterij en het onvangen signaal opvragen.
We verwachten we van een device dat de het de Mac commando’s wordt beantwoord.
Indien je de CRC op je device heb aangezet gaat heeft dit impact op de payload size.
Het KPN netwerk ondersteund LORAWAN 1.0 netwerk.
In deze spec staan alle mogelijkheden van berichten en grote in uitgelecht.

- Is het mogelijk om de mac commands altijd via Port 0 te versturen, zodat wij geen last hebben in onze payload?

Nee het is niet mogelijk om deze altijd te scheiden. Vaak wordt er bij het verzenden van een downlink (SERVER – DEVICE) gebruik gemaakt van piggyback om de benodigde downlink tijd te verminderen.

Zijn uw vragen hiermee beantwoord?
Reputatie 1
Hello @Rick S.

I'm writing in English now, because a connected company (IMST) is following this problem also.

First of all what LoRaWAN specification version is KPN following? V1.0.2 or V1.1?
We getting problems with ex. LinkADRReq. The network server (KPN) is trying to set continuously our ADR even when it's off. We are kinda rejecting those requests with a response everytime. And this will later occur in device 'busy' situation. Because KPN is retrying this Mac commands. In version 1.1 this problem is fixed.

Also:
Why does the network server sends so many and even the same MAC commands, see pictures (above the marked violet)?
The Downlink Mac commands starts with:
[lwm] HCI Rx - EndpointID: 0x10 MessageID: 0x10 Data: ....
Here especially "NewChannlesReq". The corresponding answers of the module are consuming duty cycle of the module.

I hope you can give us a quick respone of my questions. Our customer is waiting for our input!

Greetings,
Martijn
Reputatie 5
Badge +5
Goodafternoon @MartijnG,

The reason why the network server is trying to set your ADR is because the ADR command is also used to set the ChannelMask. The network expects the requests to be accepted and when the LinkADRAns are sent, the ADR requests will stopped being sent. What is the DevEUI of the device that you are using?

We have implemented the LoRaWAN1.0 spec in our network. LoRaWAN1.1 has just been released by the LoRa Alliance and this means that the LoRa ecosystem now has time to implement this. When this is fully implemented in our network, I can not say.

The network sends the same MAC messages because they are not accepted by the device.
Reputatie 1
IMST:
We see this situation (loop between network server sending the same MAC CMDs and end device answering the same MAC RSPs) also with other MAC CMDs (CID 0x06).
1) LinkADrReq: ADR is switched off on the enddevice (recommandatoiion for mobile devices from KPN ?). This (ADR Off) is signalled to the server after Joining the end device. Does a LinkADRReq CMD from the server still makes sense?
2) LoRaWAN spec. is not very accurate in this spoint (V1.0.2 page 25). But it says "if one of those three bits (ChMask, DataRate,TXPower) equals 0, the command did not succeed and the node has to kept the previos state. Some interpret this, that when ADR is OFF this CMD is rekected (all bits =0 iwithin the LinkAdrAns).
3) Generally: how useful is it, to ask always the same question when always getting the same answer?
This consumes unnecessarly Duty Cycle.
Reputatie 1
We have same situation with the MAC CMD DevStatus Req.
EndDevice has set ADR ON but send MAC responses immediately via port 0.
You can see device received a MAC CMD 03 01 DF 00 01 06
which is a LinkADRReq (03 01 DF 00 01) and a DevStatusReq (06). Due to the fact that ADR is switched ON at the end device this answer the LinkADRAns is responded (I assume with an answer that the srever accepts). But after this the DevStatusReq (06) is repeated several times. The module alsways answers with 06 FF 12
06: CID
FF: end device was not able to measure the battery level
yy: signal to noise ratio, a variable value e.g. 12 or 11, or 0D

Wha does the server repeats this DevStatusReq. alsways?
What must the end device answer to stop this?
Reputatie 5
Badge +5
Hi @Heinz,

Thanks for your questions!
I've discussed the questions from your first reaction with our specialists. You find the answers below:

1) LinkADrReq: ADR is switched off on the enddevice (recommandatoiion for mobile devices from KPN ?). This (ADR Off) is signalled to the server after Joining the end device. Does a LinkADRReq CMD from the server still makes sense?

As was mentioned in the above post, the LinkADRReq command is also used to set the Channel Mask, so yes, this is a logical network command.

2) LoRaWAN spec. is not very accurate in this spoint (V1.0.2 page 25). But it says "if one of those three bits (ChMask, DataRate,TXPower) equals 0, the command did not succeed and the node has to kept the previos state. Some interpret this, that when ADR is OFF this CMD is rekected (all bits =0 iwithin the LinkAdrAns).

We don't completely understand what your question is?

3) Generally: how useful is it, to ask always the same question when always getting the same answer?

As was also mentioned in the earlier post: “The network expects the requests to be accepted and when the LinkADRAns are sent, the ADR requests will stopped being sent.”

At this moment i am discussing your other questions with the specialists. When i have the answers to these questions, i'll get back to you
Reputatie 1
Hi Rick,

Thanks for your fast reply. Maybe I have to explain in more detailed what was meant. Sorry!
Concering
1) ADR (Adaptive Data Rate) is OFF on EndDevice. Server asked with LinkADRReq to Adapt the Data Rate (ADR) ? I now that this command also includes the ChMask.
End Device Aative Data Rate is OFF Server sends Command to Adapt Data Rate?

2) From the LoraWAN specification V1.0 page 25 below table 6.
"If any of those three bits (Channel mask ACK/Datarate ACK/Power ACK) equals 0, the command did not succeed and the node has kept the previos state." Some (as far as I know IBM LMic implementation, Semtech GitHub implementation) interpret this, that when ADR is OFF this CMD is rejected (all bits =0 within the LinkAdrAns).
Note has to kept previos state means: nothing should be accepted from this LinkADRReq ?

3) Although one can certainly discuss point 2) (intepretation of the LoraWAN specification) my question was: When the Severer always asks e.g. DevStatusReq and the end device always replies with 0x06 0xFF 0x12 (which is a valid answer) when does the server stops to ask this question?
I would expect something like a cancellation counter.
Reputatie 5
Badge +5
Hi @Heinz,

I am back again!
I have an answer to the following questions:

We have same situation with the MAC CMD DevStatus Req.
EndDevice has set ADR ON but send MAC responses immediately via port 0.
You can see device received a MAC CMD 03 01 DF 00 01 06
which is a LinkADRReq (03 01 DF 00 01) and a DevStatusReq (06). Due to the fact that ADR is switched ON at the end device this answer the LinkADRAns is responded (I assume with an answer that the srever accepts). But after this the DevStatusReq (06) is repeated several times. The module alsways answers with 06 FF 12
06: CID
FF: end device was not able to measure the battery level
yy: signal to noise ratio, a variable value e.g. 12 or 11, or 0D

Wha does the server repeats this DevStatusReq. alsways?
What must the end device answer to stop this?


After the last update this issue came up. After some research i found out that this is an overall issue. The specialists found a way to solve this problem. As we speak they are working to fix it.
Reputatie 1
Dear Rick,

Thanks for the reply and good to know that this issue is fixed now.

What is about the other issue with ADR OFF and LinkADRReq?
Martijn has generated some log files on the end device side.
1) ADR ON: we see in 75 minutes log file only one MAC CMD from the server LinkADRReq
Everthing works fine!
2) ADR OFF: We see several the following MAC CMDs in a loop
- LinkADRReq + DevStatusReq
- LinkADRReq + 3 times NewChannelReq
- 2 times NewChannelReq
....
- LinkADRReq + DevStatusReq
- LinkADRReq + 3 times NewChannelReq
- 2 times NewChannelReq
....

Now, there are two options:
2a) end device responses on the MAC CMDs directly via port zero-> this leads to an non ending loop of MAC CMDs and MAC RSPs consuming the duty cycle of the end device
2b) end device tries to answer with the packet header of the next payload uplink. Then this loop is discontinued because is not resopnding directly on MAC CMDs. It waits for the next payload uplink packet.
This is not satisfying. Can you please provide any advise?

Please find this thread
https://github.com/Lora-net/LoRaMac-node/issues/109
Reputatie 1
Hello @Ricardo NewBusinessIoT

Thanks for replying on the questions.
I hope you can get any answers or information on the post above from Heinz.
We are busy with our project and has a little haste, because the project is really delayed of the errors and issue we got, including this one.
I hope you will help us out quick, so we can deliver our final release to our customer (end December).
You said, KPN is fixing about the current issue with DevStatusReq. Can you also let us know when this issue is fixed and updated in the KPN network?
So we can test it in our user case.

Thanks!

Greetings,
Martijn
Reputatie 2
Badge
@Rick S. volgens mij moet jij hier getagt zijn en niet ik 🙂
Reputatie 5
Badge +5
Hi @Heinz & @MartijnG,

The issue with the DevStatusReq. should be fixed!
It took some time to implement the fix, but it is done. So you can test this in your case.
Can you please let us know when you tested it?

For the issue with ADR OFF and LinkADRReq I still owe you our advise. I've discussed this issue with the specialists and they are searching (and testing) to give you the best advise in this situation. I'll get back to you!
Reputatie 1
Dear Rick,

Thanks for your reply.
We discussed the issue of ADR OFF and LinkADRReq and the need of the KPN server to use LinkADRReq to set the ChMask internally, with the customer and also with Semtech.
We could implement the solution from LoRaWAN V1.1 with 0xF for DataRate and TX Power.
So the module is allowed to send back a LinkADRAns with ChannelmaskACK set to 1. This is a workaround that could help you.
Reputatie 1
Hello @Rick S.,

Thanks for the information. I'm glad the DevStatusReq issue is fixed by KPN.
I tested it today and it looks good! I see no DevStatusReq loops.
Hopefully the LinkADRReq issue will be fixed soon or get more information about it.
If you looking for a DEVEUI we using, its is : 70B3D58FF0032D6E
This module is sending every 5 minutes uplinks, almost every day,

We also mailed the issues to Simpoint/KPN (no response yet). We also asked in the mail if there is any change to arrange a meeting or telecom with a KPN LoRaWAN technician(s), us and IMST. Maybe you can give us contacts or more information if it can be arrange? I will help us a lot! So we can get quicker answers.

Greetings,
Martijn
Reputatie 2
Badge
Hi Martijn, Heinz,

My appologies for the delay in the reply to your message.
I have received the e-mail with your questions as well and I will reply to that e-mail instead of here on the forum.

Kind regards,
Lennart
Reputatie 1
Hello @Lennart Nordin,

Thanks for the reply.
We are waiting for your response through e-mail.

Greetings,
Martijn
Reputatie 2
Badge
In order to also have the information available here on the forum for other users, I would like to add the following general remark with respect to the use of ADR here:

Even if ADR=0 in uplink frames, the LRC (networkserver) still needs to send a LinkADRReq command to update the channel mask. Other fields of the LinkADRReq command (such as DataRate and TxPower) are not controlled by the LRC, only the ChMask field is. LoRaWAN 1.1 added a clarification about that to allow the network server to send a ChMask to the device (via LinkADRReq) even if it has ADR=0
Reputatie 1
Dear Lennart,
That's right, LoRaWAN 1.1 clarifies this (therefore my comment above).
But currently KPN LRC is LoRaWAN 1.0 and our radio module has implemented 1.0.2
If LRC needs LinkAdrReq to set the ChMask it should be documented somewhere by KPN how end devices
which have implemented LoRaWAN 1.0 or 1.0.2 should behave, because as you wrote "LRC still needs to send LinkADRReq..."

Best Regards,
Heinz
Reputatie 2
Badge
Below a summary of the questions and answers in this post:

What LoRaWAN specification version is KPN following?
KPN currently had the LoRaWAN1.02 specification implemented in the network.

Why does the network keep sending a DevStatusReq?

There was an issue with the DevStatusReq algorithm, which was fixed some time ago.

ADR (Adaptive Data Rate) is OFF on the End Device, however, the network keeps sending a LinkADRReq. Why is this the case?

Firstly, ADR OFF is only advised for constantly moving devices.
If the device refuses a channel mask, then, the LRC resets this device. This means that the network will later on resend these channels again
Even if ADR=0 in uplink frames, the LRC (networkserver) still needs to send a LinkADRReq command to update the channel mask (ChMask). Other fields of the LinkADRReq command (such as DataRate and TxPower) are not controlled by the LRC, only the ChMask field is. LoRaWAN 1.1 added a clarification about that to allow the network server to send a ChMask to the device (via LinkADRReq) even if it has ADR=0.
In short this is thus a work-around for the shortcomings in the LoRaWAN1.0 specification, thus in order for your device to work properly on the KPN LoRa network, the ChannelMask should be acknowledged.

For the implementation:
The “Data rate ACK” and “Power Ack” can be set to 0. The network server is only retrying the message because the Channel Mask Ack bit is set to 0
So a proper response will be with ADR OFF
Data rate ACK 0
Channel Mask ACK 1
Power ACK 0

If MAC commands are longer than 6 bytes those are sent via port 0 in a separate packet. If MAC commands are shorter/equal 6 bytes those are piggybacked within the next customer payload packet.
With this implementation customer is able to use 45 bytes. Is this compliant with the implementation of the KPN network server?

Yes, this is an implication of the way a device implements this. We do not care about this implementation in the device.

Can KPN guarantee that the application can always send 45 bytes or do situations exists (theoretically), in which the transmit of 45 byte user data is not possible due to special MAC commands?

In the LoRaWAN specification it is stated that piggybacked MAC commands may not exceed 6 bytes. This indeed leaves 45 bytes.

Reageer