# LoRaWAN duty cycle abuse **URL:** \ **Category:** LoRaWAN Discussions\ **Created:** [March 9, 2017, 9:47am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945 "2017-03-09T09:47:28Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![cambierr](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cambierr/32/3078_2.png) [@cambierr](https://www.thethingsnetwork.org/forum/u/cambierr)\ **Post date:** [March 9, 2017, 9:47am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/1 "2017-03-09T09:47:28Z")
Hi! From what I can see on my gateway data, some devices uses much more than the DC they should respect. About a message of 26 bytes every 3 seconds using SF11… giving an airtime of 823ms/message and giving a total airtime per day of more than 23 k seconds per day. Is there any way to report this kind of abuse ? ---
**Author:** ![andrewl](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/andrewl/32/37697_2.png) [@andrewl](https://www.thethingsnetwork.org/forum/u/andrewl)\ **Post date:** [March 10, 2017, 4:58pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/2 "2017-03-10T16:58:25Z")
Just block the device. You’ve obviously identified it and know its DevEUI otherwise how would you know it is a single device. Andrew ---
**Author:** ![cambierr](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cambierr/32/3078_2.png) [@cambierr](https://www.thethingsnetwork.org/forum/u/cambierr)\ **Post date:** [March 11, 2017, 9:22am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/3 "2017-03-11T09:22:01Z")
I don’t have the devEUI because they seems to use ABP (no joins and counter going back to 0 every 24 hours). I know they are the same from devAddr + SNR/RSSI 😉 ---
**Author:** ![Mirmit](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mirmit/32/11119_2.png) [@Mirmit](https://www.thethingsnetwork.org/forum/u/Mirmit)\ **Post date:** [March 11, 2017, 11:12am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/4 "2017-03-11T11:12:17Z")
Implement a black list in the poly packet forwarder? ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [March 11, 2017, 12:23pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/5 "2017-03-11T12:23:23Z")
I don’t see why blocking/blacklisting would help (unless the gateway is on some metered connection). If the DevAddr is a TTN address ([starting with the hexadecimal `0x26` or `0x27`](https://www.thethingsnetwork.org/wiki/LoRaWAN/Address-Space)) then it would be nice if TTN can block this; this would be a good use case for the Fair Access policy. If the DevAddr is not TTN, then assuming the gateway forwards to TTN, then the packet will be dropped anyway. So filtering in the gateway has no effect. The most significant 7 bits of a DevAddr are known as the NwkID, and match the _least_ significant 7 bits of the NetID (network identifier). TTN currently uses NetID `0x000013`, hence its NwkID is the binary `%0010011`.† I assume there is some overview of assigned NetIDs or NwkIDs, so we might be able to match the 7 MSB of the abusive DevAddr to one or more specific LoRaWAN networks, and complain there. So, to repeat the question: > [@cambierr](#): > > Is there any way to report this kind of abuse ? (As an aside: a hardcoded SF11 [is not allowed either](https://www.thethingsnetwork.org/forum/t/can-i-register-an-abp-device-that-has-fixed-devaddr-nwkskey-and-appskey/3831/16), so their provider should take some action…) * * * † Just to verify: hexadecimal `0x26` is binary `%00100110`, and `0x27` is `%00100111`, so both indeed start with the 7 bits NwkID. ---
**Author:** ![Mirmit](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/mirmit/32/11119_2.png) [@Mirmit](https://www.thethingsnetwork.org/forum/u/Mirmit)\ **Post date:** [March 11, 2017, 3:23pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/6 "2017-03-11T15:23:08Z")
> [@arjanvanb](#): > > I don’t see why blocking/blacklisting would help (unless the gateway is on some metered connection). If the sender rely on specific GW, preventing its data flow might help him realise there is an issue somewhere. Probably useless but might work. ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [March 11, 2017, 5:33pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/7 "2017-03-11T17:33:58Z")
> [@Mirmit](#): > > If the sender rely on specific GW, preventing its data flow might help him realise there is an issue somewhere. I disagree. Like I wrote before, assuming the gateway is only forwarding to TTN: if the sender uses a TTN DevAddr, then I’d prefer TTN takes some action instead. If not a TTN user, blocking adds nothing. And like you’re suggesting yourself: if the sender happens to be in reach of multiple TTN gateways, then blocking on one is certainly not useful. ---
**Author:** ![cambierr](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cambierr/32/3078_2.png) [@cambierr](https://www.thethingsnetwork.org/forum/u/cambierr)\ **Post date:** [March 11, 2017, 6:02pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/8 "2017-03-11T18:02:22Z")
My idea is not to avoid having my gateway using a lot of bandwidth or anything. It’s just that it goes against LoraWan “laws” and I was wondering if there was any king of organization or something that we could contact to report this. I guess I’ll try with [http://www.ibpt.be/](http://www.ibpt.be/) - The Belgian institution for telecom. The fact is that the company running those nodes (about 25) is operating their own single chan, uplink-only gateway and when I contacted them, they clearly told be that they don’t care about limitations, norms, and everything related to best practices. So to keep a good network quality and sustainability in this region, I’m looking how to report this to have them changing their config. ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [March 11, 2017, 6:08pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/9 "2017-03-11T18:08:26Z")
> [@cambierr](#): > > they clearly told be that they don’t care about limitations, norms, and everything related to best practices. That’s a bold statement for devices that can easily be located. Go harvest some hardware 😉 ---
**Author:** ![Petzl](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/petzl/32/20484_2.png) [@Petzl](https://www.thethingsnetwork.org/forum/u/Petzl)\ **Post date:** [March 14, 2017, 12:27am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/11 "2017-03-14T00:27:10Z")
And How do you know to who this device belongs to ? I have 3 gateways and one of them in Antwerp is getting data from a device every 10 seconds. (Device ending with 30001) ---
**Author:** ![Petzl](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/petzl/32/20484_2.png) [@Petzl](https://www.thethingsnetwork.org/forum/u/Petzl)\ **Post date:** [March 14, 2017, 7:38am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/12 "2017-03-14T07:38:37Z")
If it is the same devAddres, it is not always the same device, when i’m testing production samples they all have the same ID. before i go to final programming. I do have many contacts with the BIPT, and they will not spend time on ISM bands unless there are many complaints, they are to busy wit GSM and 5 ghz radar problems at this time. ---
**Author:** ![cambierr](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/cambierr/32/3078_2.png) [@cambierr](https://www.thethingsnetwork.org/forum/u/cambierr)\ **Post date:** [March 14, 2017, 9:16am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/13 "2017-03-14T09:16:55Z")
> [@Petzl](#): > > I do have many contacts with the BIPT, and they will not spend time on ISM bands unless there are many complaints, they are to busy wit GSM and 5 ghz radar problems at this time. This is interesting to know… ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [March 14, 2017, 6:58pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/14 "2017-03-14T18:58:11Z")
> [@Petzl](#): > > And How do you know to who this device belongs to ? Only [the LoRaWAN network operator can](https://www.thethingsnetwork.org/wiki/LoRaWAN/Address-Space) (emphasis mine): > ### Device Address Assignment > The Things Network Foundation has received a 7-bit device address prefix from the LoRa Alliance. This means that all TTN device addresses will start with `0x26` or `0x27` (although addresses that start with these might also belong to other networks with the same prefix). Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the `eu` region start with `0x2601`). Within a region, the NetworkServer is responsible for assigning device addresses. We are using prefixes here too for different device classes (for example, ABP devices in the `eu` region start with `0x26011`) or to shard devices over different servers. > […] > It’s good to keep in mind that device addresses are not unique. We can (and probably will) give hundreds of devices the same address. **Finding the actual device that belongs to that address is done by matching the cryptographic signature (MIC) of the message to a device in the database.** You’d need a list of NetIDs (or simply a list of LoRaWAN operators in your region) to find the LoRaWAN provider(s) that might be handling a given DevAddr. If it’s not a private network to start with. ---
**Author:** ![hobo](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/hobo/32/25844_2.png) [@hobo](https://www.thethingsnetwork.org/forum/u/hobo)\ **Post date:** [March 14, 2017, 9:12pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/15 "2017-03-14T21:12:38Z")
> [@cambierr](#): > > About a message of 26 bytes every 3 seconds using SF11… giving an airtime of 823ms/message and giving a total airtime per day of more than 23 k seconds per day. > [@cambierr](#): > > The fact is that the company running those nodes (about 25) is operating their own single chan, uplink-only gatewa So, there are 25 nodes on the same channel, with 25+% duty cycle each? 🙂 BTW, which exactly frequency do they use? ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [April 14, 2017, 6:05pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/16 "2017-04-14T18:05:57Z")
> [@arjanvanb](#): > > The most significant 7 bits of a DevAddr are known as the NwkID, and match the least significant 7 bits of the NetID (network identifier). And to find the DevAddr: you can see that in the gateway’s “Traffic” page in TTN Console, or get it from a raw packet [using an online decoder](https://runkit.io/avbentem/lorawan-packet-decoder/branches/master). ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [April 15, 2017, 8:17am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/17 "2017-04-15T08:17:13Z")
For future reference, in reference to @affoltep seeing a node _“which sends almost every 5 second with an airtime of 1.6. second (29bytes, SF12)”_, Johan wrote about the Fair Access Policy in Slack yesterday: > @johan [9:26 PM] > > > Nothing regarding FAP is implemented yet > > We’ll starting monitoring soon though ---
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [April 23, 2017, 10:23pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/18 "2017-04-23T22:23:01Z")
> [@arjanvanb](#): > > The most significant 7 bits of a DevAddr are known as the NwkID, and match the least significant 7 bits of the NetID (network identifier). And here is a list of NetIDs @johan [posted on Slack](https://thethingsnetwork.slack.com/archives/C1D8GQMU5/p1492981081822330), enhanced with the two possible prefixes for the DevAddr, which match the 7 bits NwkID: > _NetID, DevAddr MSB, location(s): name_ > > - `0x00`, `0x00/01`, Local: Experimental nodes > - `0x01`, `0x02/03`, Local: Experimental nodes > - `0x02`, `0x04/05`, World: Actility > - `0x03`, `0x06/07`, Europe: Proximus > - `0x04`, `0x08/09`, Europe: Swisscom > - `0x05`, `0x0a/0b`, Singapore, indonesia , Australia, Africa , India: SingTel > - `0x06`, `0x0c/0d`, Europe: La Poste > - `0x07`, `0x0e/0f`, Europe: Bouygues Telecom > - `0x08`, `0x10/11`, World: Orbiwise > - `0x09`, `0x12/13`, U.S: SENET > - `0x0a`, `0x14/15`, Europe: KPN > - `0x0b`, `0x16/17`, Russia: EveryNet > - `0x0c`, `0x18/19`, Africa: FastNet > - `0x0d`, `0x1a/1b`, World: SK Telecom > - `0x0e`, `0x1c/1d`, World: SagemCom > - `0x0f`, `0x1e/1f`, Europe: Orange France > - `0x10`, `0x20/21`, Italy: A2A Smart City > - `0x11`, `0x22/23`, India, Sri Lanka, Nepal, Bangladesh and the Maldives Islands: TATA Communication > - `0x12`, `0x24/25`, World: Kerlink > - `0x13`, `0x26/27`, World: The Things Network > - `0x14`, `0x28/29`, Germany, Switzerland, China: DIGIMONDO GmbH > - `0x15`, `0x2a/2b`, World: Cisco Systems > - `0x16`, `0x2c/2d`, China: Computer Network Information Center & Chinese of Sciences Guangzhou Sub-center (CNIC) > - `0x17`, `0x2e/2f`, World: MultiTech Systems > - `0x18`, `0x30/31`, World: Loriot > - `0x19`, `0x32/33`, World: NNNCo > - `0x1a`, `0x34/35`, World: Flashnet > - `0x1b`, `0x36/37`, World: TrackNet > - `0x1c`, `0x38/39`, World: Lar.Tech > - `0x1d`, `0x3a/3b`, World: Swiss Led > - `0x1e`, `0x3c/3d`, CIS, Europe: Net868 > - `0x1f`, `0x3e/3f`, Italy: Axatel > - `0x20`, `0x40/41`, Germany: Telent (Netzikon) > - `0x21`, `0x42/43`, World: Patavina Technologies > - `0x22`, `0x44/45`, North America: Comcast > - `0x23`, `0x46/47`, Australia, New Zealand: Ventia > - `0x24`, `0x48/49`, World: Gimasi > - `0x25`, `0x4a/4b`, World: Talkpool > - `0x26`, `0x4c/4d`, Italy: Telemar > - `0x27`, `0x4e/4f`, World: MCF88 SRL > - `0x28`, `0x50/51`, Malaysia: VADSLYFE > - `0x29`, `0x52/53`, World: GIoT > - `0x2a`, `0x54/55`, World: M2B Communications > - `0x2b`, `0x56/57`, China: ZTE > - `0x2c`, `0x58/59`, Australia: Airlora > - `0x2d`, `0x5a/5b`, World: Rai Way > - `0x2e`, `0x5c/5d`, World: Levikom > - `0x2f`, `0x5e/5f`, South Africa: Comsol Networks > - `0x30`, `0x60/61`, World: SoftBank > - `0x31`, `0x62/63`, World: Inmarsat > - `0x32`, `0x64/65`, World: Gemalto > - `0x33`, `0x66/67`, China: Alibaba Iot BU > - `0x34`, `0x68/69`, Russian Federation: ER-Telecom Holding Remember that when the list grows, multiple networks might use `DevAddr` starting with the same `NwkID`. And @htdvisser also wrote [on Slack](https://thethingsnetwork.slack.com/archives/C1D8GQMU5/p1493012693065514): > Unfortunately many networks still allow registration of DevAddrs that belong to other networks, so it’s not 100% accurate > > But I’m sure they’ll stop doing that soon enough when the LoRa Alliance starts threatening to take away their allocations entirely > **(Click to see the JavaScript used to generate the above list)** > > ``` > let items = [ > [0, 'Local', 'Experimental nodes'], > [1, 'Local', 'Experimental nodes'], > [2, 'World', 'Actility'], > [3, 'Europe', 'Proximus'], > [4, 'Europe', 'Swisscom'], > [5, 'Singapore, indonesia , Australia, Africa , India', 'SingTel'], > [6, 'Europe', 'La Poste'], > [7, 'Europe', 'Bouygues Telecom'], > [8, 'World', 'Orbiwise'], > [9, 'U.S', 'SENET'], > [10, 'Europe', 'KPN'], > [11, 'Russia', 'EveryNet'], > [12, 'Africa', 'FastNet'], > [13, 'World', 'SK Telecom'], > [14, 'World', 'SagemCom'], > [15, 'Europe', 'Orange France'], > [16, 'Italy', 'A2A Smart City'], > [17, 'India, Sri Lanka, Nepal, Bangladesh and the Maldives Islands', 'TATA Communication'], > [18, 'World', 'Kerlink'], > [19, 'World', 'The Things Network'], > [20, 'Germany, Switzerland, China', 'DIGIMONDO GmbH'], > [21, 'World', 'Cisco Systems'], > [22, 'China', 'Computer Network Information Center & Chinese of Sciences Guangzhou Sub-center (CNIC)'], > [23, 'World', 'MultiTech Systems'], > [24, 'World', 'Loriot'], > [25, 'World', 'NNNCo'], > [26, 'World', 'Flashnet'], > [27, 'World', 'TrackNet'], > [28, 'World', 'Lar.Tech'], > [29, 'World', 'Swiss Led'], > [30, 'CIS, Europe', 'Net868'], > [31, 'Italy', 'Axatel'], > [32, 'Germany', 'Telent (Netzikon)'], > [33, 'World', 'Patavina Technologies'], > [34, 'North America', 'Comcast'], > [35, 'Australia, New Zealand', 'Ventia'], > [36, 'World', 'Gimasi'], > [37, 'World', 'Talkpool'], > [38, 'Italy', 'Telemar'], > [39, 'World', 'MCF88 SRL'], > [40, 'Malaysia', 'VADSLYFE'], > [41, 'World', 'GIoT'], > [42, 'World', 'M2B Communications'], > [43, 'China', 'ZTE'], > [44, 'Australia', 'Airlora'], > [45, 'World', 'Rai Way'], > [46, 'World', 'Levikom'], > [47, 'South Africa', 'Comsol Networks'], > [48, 'World', 'SoftBank'], > [49, 'World', 'Inmarsat'] > ]; > > function hex(val, len=2) { > return ('0'.repeat(len) + val.toString(16)).substr(-len); > } > > console.info('> _NetID, DevAddr MSB, location(s): name_'); > console.info('>'); > for (let [netId, location, name] of items) { > // nwkId = 7 LSB of NetID: > let nwkId = netId & 0b01111111; > // ...and nwkId = 7 MSB of DevAddr: > let devAddr = nwkId << 1; > console.info(`> - \`0x${hex(netId)}\`, \`0x${hex(devAddr)}/${hex(devAddr+1)}\`, ${location}: ${name}`); > } > > ``` ---
**Author:** ![johan](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/johan/32/45177_2.png) [@johan](https://www.thethingsnetwork.org/forum/u/johan)\ **Post date:** [April 24, 2017, 10:45pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/19 "2017-04-24T22:45:04Z")
Thanks for the overview @arjanvanb ; this is way more useful than my copy paste. The LoRa Alliance aims not to issue NwkIds that are overlapping in a region. The world allocations, including ours, should be unique globally. Note that parties need to be a Contributor member to get world allocations - we still need to upgrade - otherwise uniqueness is not guaranteed. The idea is that when the NwkId rolls over, from 128, the NwkId skips as long as there’s overlap in the region. Trashcans activated on a nationa Combian network can share address space with a national German network, but device adresses starting with `26` or `27` will be The Things Network’s as our allocation is global. Note that there’s no such thing as a LoRa Police enforcing things like addressing and duty cycle, but it’s good to follow standards for the sake of the community, the LoRa ecosystem and certification. ---
**Author:** ![htdvisser](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/htdvisser/32/45312_2.png) [@htdvisser](https://www.thethingsnetwork.org/forum/u/htdvisser)\ **Post date:** [April 25, 2017, 6:10am UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/20 "2017-04-25T06:10:25Z")
I added @arjanvanb’s list to the wiki: [https://www.thethingsnetwork.org/wiki/LoRaWAN/Address-Space#address-space-in-lorawan\_devices\_prefix-assignments](https://www.thethingsnetwork.org/wiki/LoRaWAN/Address-Space#address-space-in-lorawan_devices_prefix-assignments) ---
**Author:** ![ursm](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/ursm/32/46475_2.png) [@ursm](https://www.thethingsnetwork.org/forum/u/ursm)\ **Post date:** [September 28, 2017, 5:08pm UTC](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945/21 "2017-09-28T17:08:13Z")
another one to report (ID assigned as “experimental”). seen at GW zh-affoltern (B827EBFFFED390B0) ![ABUSE](https://www.thethingsnetwork.org/forum/uploads/default/original/2X/9/952d704278a3e2e3ac34b0696ca380eb4c04c2a4.jpg) I suggest again instantiating a help-line (not called ttn police ;)) to **take care of such reported issues**. [Next page](https://www.thethingsnetwork.org/forum/t/lorawan-duty-cycle-abuse/5945.md?page=2)