Probleme durch Node mit rücksichtslosem Verhalten

TTN Köln
#1

Hallo Allerseits,

ich habe im Kölner Osten seit einigen Tagen ein Problem mit einem Node, welcher sich in keinsterweise an irgendwelche Vorschriften (Duty Cycle 1%) geschweige denn an FUP des TTN hält. Hierbei konnte ich nachweisen, dass dieser Node sogar dazu führt, dass Gateways ihren zulässigen Duty Cycle für die Downlinks deutlich überschreiten könnten.

image
image1166×399 66.5 KB

Ich gehe davon aus, dass sich dieser Node mit der Dev Addr: 260B3023 im Großraum Köln befindet. Er sendet nahezu minütlich (SF7 - SF12) Confirmed Uplinks, welche einen 12 Bytes Downlink zur Folge haben. Im TTN-Forum habe ich bereits einen entsprechenden Thread (Misbehaving Nodes) gestartet.

Ich schreibe dies aber nochmals hier, in der Hoffnung, dass der Betreiber des Nodes dies liest und seinen Node abschaltet.
Allen Gateway-Betreibern im Raum Köln würde ich empfehlen im Log ihrer Gateways die Downlink-Zeiten im Bezug auf den Duty-Cycle (36sek/Stunde) zu überprüfen.

Wolfgang

1 „Gefällt mir“
#2

Hallo Wolfgang,

auf unserem Gateway auf dem Kraftwerk in Niehl sehe ich das Device nicht. Es scheint sich also weiter östlich bzw. südlich zu befinden. Habe auch vorsichtshalber mal nachgesehen - von meinen Nodes ist das keine.

Viele Grüße
Uwe

2 „Gefällt mir“
#3

Gibt es dazu ein Feedback von TTN in deren Forum?

Aktuell sanktioniert TTN Verstöße gegen die Fair Use Policy nicht, sie hätten jedoch die Möglichkeit den Betreiber auf sein Verhalten hinzuweisen.

Sollte das nicht klappen hat man noch die Option Beschwerde bei der BNetzA.

Wir haben hier bei uns glücklicher Weise nicht solche Probleme.
Das einzige was ich aus der Richtung kenne war ein schlecht gemachter LoRa-Adapter (kommerziell) der einem die Gateways voll Spalte wenn der Join-Request nicht funktionierte und er dann damit auf Dauerfeuer umstellt.

Das ist j doch inzwischen gefixt.

S.

#4

Ja, das Team von TTN hat sich eingeschaltet. Was die genau gemacht haben weiss ich nicht, aber am 31.03. gegen 10:00 haben sie wohl angefangen, diesen Node auszubremsen. Das war aber wohl nur eine Einzelaktion des Teams.
Die Zuständige Behörde (BNetzA) möchte ich nicht einschalten, es sollte dem TTN- Team gelingen dieses Problem zu lösen. Man arbeitet schon dran.
Leider hat mein Gateway (LIG16) keine Blacklist, sonst hätte ich diesen Node zumindest für die Downlinks gesperrt.
Das eigentliche Problem sehe ich aber darin, dass der Betreiber eines Gateways dafür verantwortlich ist, was dieses macht. Er hat aber - bis auf Ziehen des Netzsteckers- keine Möglichkeit auf die Aussendungen des GW Einfluss zu nehmen und ggf. eine Überschreitung des Duty Cycles zu verhindern.

#5

Öhm… Der Betreiber von Straßen ist dafür verantwortlich, wenn es zu Unfällen in seinen Straßennetzen kommt? Und nicht der Führer eine Fahrzeuges?

Gruß und frohe Ostern

#6

Im Recht des Straßenbaus kenne ich mich leider nicht aus. Aber im Bereich des Telekommunikationsgesetzes ist es so, daß nicht nur die Wirtschaftsakteure sondern auch der Nutzer verantwortlich ist.
„Der Frequenznutzer ist für die Einhaltung der Zuteilungsbestimmungen und für die Folgen von Verstößen, z. B. Abhilfemaßnahmen und Ordnungswidrigkeiten verantwortlich“. (VFG 133/2019)

Viele bunte Ostereier auch für Dich!

#7

Hmmmm…

Aus meiner Sicht bist du Nutzer/Besitzer des GW`s. Kannst du Einfluss nehmen auf das Verhalten deiner Hardware? Hast du die Software/Hardware entwickelt?

Was, wenn du das nicht entdeckt hättest? Unwissenheit schützt vor Strafe nicht, oder wie?

Meiner Meinung nach ist der Nodebetreiber verantwortlich, oder eben der Hersteller desselben. Du leitest die Daten, die geliefert werden halt durch, nicht mehr.

Gruß

#8

Warum erinnert mich das nur an den FreiFunk?!?!?!

#9

Ja, das hat eine gewisse Ähnlichkeit mit der „Störerhaftung“. Nur geht es jetzt um das Verhalten eines Geräts, welches die Schutzanforderung der RED-Richtlinie einhalten muss.
Ich halte es für wichtig, dass wir diese Thematik untereinander diskutieren und technische Lösungsmöglichkeiten suchen ehe dies ein anderer macht.
Bezüglich des Arbeitszyklus kann ich tatsächlich keinen Einfluss auf die Hardware des GW nehmen und Du hast recht: Unwissenheit schützt nicht vor Strafe.

Auch was die Verantwortung des Node-Betreibers angeht hast Du imho recht: Dieser ist aber nur für seinen Node verantwortlich, welcher sich selbstverständlich an die Anforderungen der Vfg 133/2019 halten muss. Wenn er dies nicht tut ist mir das als Gateway-Betreiber erst mal egal im Bezug auf Uplinks (Durchleiten von Daten).

Haben diese Uplinks aber Downlinks zur Folge ist es m.E. Aufgabe des jeweiligen Gateways (seines Nutzers) dafür zu sorgen, dass es die Anforderungen bezüglich Arbeitszyklus einhält. Ich bezweifle, das man sich damit herausreden kann, dass es Aufgabe vom TTN ist, die Einhaltung des Arbeitszyklus sicher zu stellen.
Aber es gäbe ja technische Lösungen, diese müssten nur vom Gateway-Hersteller implementiert werden. Das Gateway weiß, wieviel Airtime es beansprucht hat und ein gleitendes 1h-Fenster mitlaufen zu lassen, in welchem diese Zeiten aufsummiert werden, ist keine Raketen-Wissenschaft.

Viele Grüße aus dem Rheinland
Wolfgang

#10

@wolfp

Moin Wolfgang

Und Wort!

Eigentlich bin ich da bei Dir, aber wie will man das aus der Sicht eines GW-Betreibers lösen?
Auf Netzbetreiberseite könnte man die Weiterleitung von Paketen des Nodes unterbinden und evenzuell auch schon auf DIY-GW, in dem man die Pakete blockt.

Aber was, wenn der Node weiterhin sendet? Die Airtime wird dadurch ja nicht mehr. Sprich die verfügbare Bandbreite weniger genutzt.

Ich weis nicht… . Letztendlich regeln wir das selber, durch entsprechende Aufklärung und Schulung was das Thema angeht (ähnlich wie bei den Funkamateuren), oder es bedarf dann wirklich eines staatlichen Eingreifens, was ich allerdings eher weniger möchte.
Habt ihr denn in eurer Gemeinschaft schon versucht den Nodebetreiber ausfindig zu machen?

Gruß aus dem hohen Norden und frohe Ostern für den Rest

Nordrunner

#11

TTN könnte den Node blocken, dann hat man im Whorst Case halt die Tausende Join Requests…

Mehr können die auch nicht tun.

#12

Mittlerweile erscheint dieser Node etwas gezähmt. Bei SF7, SF8 schickt er noch jede Minute einen Confirmed Uplink, mit steigendem SF erhöht sich die Zeit zwischen den Aussendungen bis auf 7 Minuten (bei SF12) damit hat mein Gateway entsprechend weniger Downlinks.
Aber abgesehen davon: Das Verhalten des Nodes ist weitab der Fair Use Policy (FUP) des TTN.
Was könnte man tun?

Von TTN-Seite: Eine Art Ampelsystem auf der Console für das End Device.

  1. Grün: FUP und Regulation eingehalten
  2. Gelb: FUP nicht eingehalten, Regulation eingehalten
  3. Rot: FUP und Regulation nicht eingehalten.
    Damit könnte dem Nutzer des Nodes sichtbar gemacht werden, dass der Node ein Problem fürs TTN (und evtl. auch für den Nutzer) darstellt

Von Seiten der Gateway-Hersteller:
Implementierung eines gleitenden 1h-Fensters für die Aussendungen des Gateways (für jedes der Frequenzbänder), Anzeige des Werts im Log, Einstellung des Sendebetriebs im jeweiligen Band wenn der Duty Cycle dieses Bandes überschritten ist.

Aber ich weiß auch: NIchts ist unmöglich für den, der es nicht selber tun muss.

In diesem Sinne - noch einen fröhlichen Ostermontag:
Wolfgang

1 „Gefällt mir“
#13

Das Thema ist eigentlich eine alte Kamelle:

#14

Und da haben wir den Salat:

Bleibt nur zu hoffen, dass die zu erwartenden Einschränkungen nur den Sendeteil hinsichtlich der Einhaltung regulativer Anforderungen (Sendeleistung, Nebenaussendungen, Duty Cycle, Frequenzstabilität…) umfasst.

Wer mehr wissen möchte:
https://ec.europa.eu/docsroom/documents/40822/attachments/1/translations/de/renditions/native

1 „Gefällt mir“
#15

Äußerst unschön!

Wenn man da ein wenig drauf rumdenkt und deren Vorstellungen umgesetzt werden, können wir wohl unseren Kram einpacken.

#16

Meinst Du?

Ich sehe es so, das dies das Ende für RFM95 & Co. sein wird. Du musst dann halt einen Murata-Chip nehmen den man als Modem anspricht, alles was den Funkstack angeht regelt die ganz nebenbei auch gleich noch LoRa-Alliance-konforme Firmware des Chips. Aber den Node, wenn das auch nicht mehr gehen würde dürfte es auch keine Linux-Laptops mit 5G- Modem mehr geben!
Ja, es wird teurer und weniger flexibel, aber ganz einpacken sehe ich noch nicht!

S.

#17

Nodes wie dieser hier sind mit die Ursache für die kommenden Restriktionen:

07/16-14:16:30 Join Request LoRa 868.3 SF12 BW125 0 DevEui: 0018B20000022B3C,AppEUI: 0018B24441524632
{„Size“:23, „Rssi“:-120, „snr“:-10, „AppEUI“:„0018B24441524632“, „DevEUI“:„0018B20000022B3C“}|003246524144B218003C2B020000B2180064F6458F9E5D
Gateway: eu-de-cologne-east

Heute zwischen etwa 10:30 und 14:16 sendete dieser Node über 1300 !! Join Requests im Abstand von etwa 8 Sekunden.

#18

Äußerst unschön!

Hmmmm… Ist der TTN? Kann man das herausfinden?

#19

Bei dem Node könnte es sich um einen Adeunis Field-Tester handeln. Jedenfalls findet man die AppEUI im Zusammenhang mit diesen Testern. Aber er erhält keinen Join Accept vom TTN, also lässt sich vermuten, dass er dort nicht angemeldet ist.

1 „Gefällt mir“
#20

Ob man mit ein paar Usern etwas bauen könnte, womit man eine Triangulation machen könnte, um solche Störer ausfindig zu machen?

Ähnlich den Peilwagen der Telekomiker.

Wäre vielleicht ein Projekt für die Gemeinschaften, weil es betrifft ja nicht nur ausschließlich die Gegend bei Dir.
Das gute an der Sache, wenn der in Betrieb ist, dann hat man relativ häufig ein Signal.

Nur eine Überlegung von mir.

Gruß