Vraag

RxParamSetupReq - Ans gaat fout bij KNP en zorgt voor problemen

  • 22 June 2018
  • 6 reacties
  • 393 keer bekeken

Hallo,

Wij hebben de afgelopen tijd een aantal problemen gehad met onze nodes waarbij de downlinks van KPN niet ontvangen worden. Na verder onderzoek met behulp van de wireless-logger bleek dat KPN downlinks blijft zenden op SF9 en de downlink ook iedere keer dezelfde data heeft namelijk een RxParamSetupReq waarmee het RX2 window wordt ingesteld op SF12.


Het MAC command wordt verzonden in een confirmed downlink op SF9. De RX2DataRate wordt hier ingesteld op 0 dat staat voor SF12.

Echter de uplink nadat de node het MAC commando ontvangen heeft ontbreekt. Het bereik was waarschijnlijk te slecht op dit moment.



In de eerstvolgende uplink (#4087) is te zien dat de node met MAC data reageert, in de payload van de MAC data is het RxParamSetupAns commando te zien waarmee de node aangeeft dat de instellingen geaccepteerd zijn. Alleen het antwoord op dit MAC commando is te zien omdat volgens de specificatie dit commando herhaald moet worden totdat de node een downlink ontvangen heeft.



Na het bevestigen van de instellingen in de uplink (#4089) stuurt KPN echter nog steeds een downlink met SF9 waarvan de data hetzelfde is als de vorige downlink. Zo is te zien dat KPN dus downlinks blijft zenden met een data rate waar de node niet meer naar luistert. Deze heeft namelijk zijn instellingen veranderd en dit bevestigd de node ook in de uplink.

Wat wij zien misgaan is het feit dat KPN een confirmed data downlink stuurt en pas de instellingen bevestigt wanneer het ack bit in de uplink ontvangen is waarmee het downlink frame bevestigd wordt. Echter hoort KPN voor het RxParamSetupReq commando te kijken naar de MAC payload waarin de instellingen bevestigd worden. De ack bit waarmee het frame bevestigd wordt moet namelijk volgens de LoRaWAN specificatie alleen in de eerstvolgende uplink verzonden worden na het ontvangen van de confirmed downlink. Dus wanneer deze niet ontvangen wordt denkt het netwerk dat de instellingen niet ontvangen heeft en worden deze instellingen opnieuw verzonden, zonder dat KPN de wijziging toepast voor de downlink. Omdat de node echter de instellingen wel bevestigd in de MAC payload luistert de node dus alleen naar een downlink met de nieuwe instellingen. KPN en de node gebruiken nu allebei andere instellingen en de node is nu niet meer in staat om een downlink op RX2 te ontvangen. Omdat de downlink niet ontvangen wordt, wordt er door de node dus ook geen bevestingen van het frame meer verstuurd waarop KPN dus niet de instellingen erkend als toegepast.

Doordat KPN niet de MAC data controleert van de uplink waarin de instellingen bevestigd wordt maar meer uitgaat van de bevestingen van het downlink frame wordt er dus een deadlock veroorzaakt op RX2. We zien ook dat dit probleem zichzelf kan oplossen wanneer KPN de downlink stuurt op RX1, de node is dan in staat om deze te ontvangen waarna het downlinkframe bevestigd wordt door de ACK te zetten in het FCtrl veld bij de volgende uplink. Als deze nu wel ontvangen wordt door het netwerk worden de instellingen van KPN geaccepteerd en worden de downlinks op RX2 met SF12 verzonden.


Hierin is dl#996 op RX2 met SF9, deze wordt niet door de node ontvangen. Bij de volgende uplink #4910 wordt er een downlink op RX1 met SF12 verzonden #997. Deze wordt ontvangen door de node en antwoord met uplink #4911, waarin de FCtrl ACK gezet wordt gezet. Bij de volgende downlink #998 wordt er een downlink met SF12 op RX2 verzonden.

We hebben geprobeerd de instellingen van het netwerk te resetten met de security context reset knop, hiermee gaat KPN terug naar de standaard instellingen van de LoRaWAN spec. Alleen dit gaf problemen met de downlinkcounter. Zie https://zakelijkforum.kpn.com/lora-forum-16/reset-security-context-11103.

Wat het probleem zou oplossen is dat KPN eerst kijkt naar de MAC payload van een uplink waarin settings bevestigd wordt voordat het netwerk een retry uitvoert. Als er in deze payload settings bevestigd worden moet het KPN netwerk zijn netwerk configuratie aanpassen naar de settings verzonden in de laatste downlink waar een request is gedaan om deze settings te veranderen. Het is dan wel belangrijk dat deze settings niet mogen veranderen totdat de bevestiging van de setting ontvangen is in de MAC payload.

6 reacties

Hey @Rick S.,

Is er nog een update over dit topic? Ik heb nog steeds geen contact gehad met de KPN specialisten.

In mijn post heb ik gezegd dat het probleem waarbij het RxParamSetup commando niet goed wordt afgehandeld als de uplink na de downlink met het MAC commando niet wordt ontvangen. Hier was mijn theorie dat er niet wordt gekeken naar de ack van het commando in de payload maar naar de ack van het frame. Ik zie nu echter ook dat het ook mis lijkt te gaan als deze uplink WEL door het netwerk wordt ontvangen.

Ik zie dat bij een node die in een downlink heeft ontvangen met het commando om zijn RX2 window te configureren naar data rate 3 (SF9). De eerstvolgende uplink daarna wordt door het netwerk ontvangen, ik zie hier de ack van het confirmde downlink en de bevestiging van de instellingen behorend bij de ontvangen MAC commando's. In het antwoord van de node worden alle instellingen bevestigd. Echter hoewel de node zijn RX2 datarate nu op SF9 heeft ingesteld zie ik dat het netwerk een downlink blijft versturen in RX2 op SF12. Het netwerk stopt ook vervolgens met het sturen van de MAC commando's t.b.v. de RX windows.

Het netwerk heeft dus instructies gegeven om op SF9 te gaan luisteren en heeft daarbij ook het antwoord daarvan ontvangen. Het bericht is te zien op de WLogger er zit geen gat in de uplinkcounter tijdens het verzenden en ontvangen van de MAC commando's. Maar toch blijft het netwerk downlinks versturen op SF12 terwijl er SF9 wordt ingesteld. De node is hierdoor niet meer in staat om de downlinks van de server te ontvangen.

Ik hoop spoedig een antwoord te hebben met ook een mogelijke oplossing.
Reputatie 7
Badge +6
Goedemiddag @Xkottelaar,

Ik ben wederom achter mijn collega's aangegaan, want ik vind het persoonlijk ook lang duren.
Wij hebben het vermoeden dat dit gedrag van de devices geïnitieerd wordt vanwege het gebruik van een oud (verkeerd) device profile. Heel toevallig zijn we bezig met een Device Profile opschoning om deze verouderde en verkeerde profielen te verwijderen. Ik adviseer u daarom om het profiel van de devices te checken en eventueel om te zetten.

Hieronder een overzicht van de oude device profielen:

En hieronder dan een overzicht van de nieuwe device profielen:


Gistermiddag zijn er automatisch informatie mails hierover verstuurd. Heeft u deze ontvangen? Eventueel kan ik deze mail nogmaals naar u versturen.
Hey @Rick S.,

Bedankt voor de update!
Er wordt inderdaad nog gebruik gemaakt van een van de oude device profielen. Is er nog de mogelijkheid om in de device manager het device profiel van alle/meerdere nodes in een keer te veranderen?

Hoe zit het met nodes die niet meer in staat zijn om downlinks te ontvangen? Voor ons lijkt de enige oplossing om de datarate van de KPN downlinks handmatig aan te passen naar de datarate waarop de node ingesteld is door het MAC commando. Is dit mogelijk?

Ik heb de mail inderdaad niet ontvangen. Zou u deze nog kunnen sturen naar mijn mail adres (zie uw persoonlijke inbox).
Reputatie 7
Badge +6
Goedemorgen @Xkottelaar,

Op dit moment is er nog niet de mogelijkheid om het profiel voor meerdere devices tegelijk te wijzigen. We hebben bij de leverancier het verzoek uitstaan om deze functionaliteit toe te voegen.

Daarnaast heb ik van een van de specialisten begrepen dat er een ticket bij de Servicedesk is aangemaakt. In de Service portal kunt u alle informatie toevoegen, zodat mijn collega's op onderzoek kunnen. Ik wil u niet van het forum wegsturen, maar in dit geval is de Servicedesk het beste kanaal om dit uit te laten zoeken. De mail stuur ik u zo direct nogmaals door 😉
Hallo @Rick S.,

Oke ik ben benieuwd!

Ik zou het geen probleem vinden om op de servicedesk verder te gaan over dit topic, we hebben hier echter geen account voor. Is er de mogelijkheid dat wij hiervoor een account kunnen krijgen of kunnen maken? Het onderzoek is gedaan in naam van een klant van ons, deze heeft wel toegang tot de service portal maar wij niet direct.
Reputatie 7
Badge +6
Hi @Xkottelaar,

Ohja, dat is ook zo! Ik was even vergeten dat het in naam van een klant van u ging.
Ik heb zelf niet de mogelijkheid om ook voor jullie een account aan te maken. Is dit niet in samenwerking met de klant te regelen?

Het lijkt me namelijk ook niet handig als er een situatie ontstaat waarbij zowel de klant zelf als u een ticket in schieten bij de Servicedesk. Dat is een beetje dubbelop natuurlijk. Maar het advies is dus om via het ticket (dat de klant zelf heeft aangemaakt) verder te gaan.

Reageer