Oversized message not being rejected

TTN Network and Services The Things Stack v3
1

I am occasionally seeing packets through one of my gateways that seems oversized (according to two airtime calculators I have checked)

The messages in question are sent as SF10BW125 and my assumption until now was there is a 64 byte packet limit (typically 51 bytes plus 13 byte header)

This example is actually 66 bytes, thus exceeding the maximum allowed airtime of 698.4 ms

{
	"name": "gs.up.receive",
	"time": "2022-12-13T09:32:56.920504796Z",
	"identifiers": [{
		"gateway_ids": {
			"gateway_id": "-------------",
			"eui": "-----------------"
		}
	}],
	"data": {
		"@type": "type.googleapis.com/ttn.lorawan.v3.GatewayUplinkMessage",
		"message": {
			"raw_payload": "QJSc8QMAIgABpq8JYpLvcq5eAcPTQdkp7e/7NGzXuwBDfPwr4kKNm18dGvXdBk6skZdmucfm3Ku2KhuWiFvE0z9D",
			"payload": {
				"m_hdr": {
					"m_type": "UNCONFIRMED_UP"
				},
				"mic": "xNM/Qw==",
				"mac_payload": {
					"f_hdr": {
						"dev_addr": "03F19C94",
						"f_ctrl": {},
						"f_cnt": 34
					},
					"f_port": 1,
					"frm_payload": "pq8JYpLvcq5eAcPTQdkp7e/7NGzXuwBDfPwr4kKNm18dGvXdBk6skZdmucfm3Ku2KhuWiFs="
				}
			},
			"settings": {
				"data_rate": {
					"lora": {
						"bandwidth": 125000,
						"spreading_factor": 10,
						"coding_rate": "4/5"
					}
				},
				"frequency": "868300000",
				"timestamp": 2612747780
			},

Do I just assume that this is a non-LoRaWAN message or should it really be rejected as a “gs.up.drop” event rather than a “gs.up.receive” ?

My gateway happily forwards it, as it should do, but I was suprised it was accepted as a valid event with respect to LoRaWAN compliance.

2

Gateways intelligence only runs to CRC checks.

I’d have to check if the legal air time is part of the actual LW spec &/or compliance but I’d suspect that adds yet another layer of complexity as radio waves know no boundaries …

3

Where is this limit defined?

For SF10 the MACpayload for EU868 is 59 bytes according to Regional Parameters 1.0.3a
I don’t recall any gateway code enforcing message size limits (at least not in the UDP protocol version).

4

Think this may only be an issue in e.g. US where there is a 400ms (IIRC) dwell time limit, dont think that applies in Wiltshire! :wink: (Duty cycle limits only - and GW’s dont enforce that it is the nodes/users responsibility…)

5

I was just basing my assumption on https://www.thethingsnetwork.org/airtime-calculator

This complained with: “Max payload size exceeded” when I chose: Input Bytes 53 and SF10, EU868 125 kHz
The table indicates Max payload size (bytes) = 51

It wasn’t a limit in my gateway

6

There are several well proven and tested AT calculators that have been around for a long time - the problem is that most of them refered back to 1.0.2 (IIRC) (e.g. https://avbentem.github.io/airtime-calculator/ttn/eu868/53) and havent necessarily been updated and/or to keep simple have ignored the FOpt fields as Jac points out 1.0.3 (part 2.2.6) allows M=59 (N still 51 or lower), and of course we are now seeing 1.0.4 and indeed 1.1 messages so think of the AT calculators as good practice conservative versions and all then good :slight_smile: Another reason why GW’s play dumb and dont exercise any policing instead just passing the message on = such spec changes over time would force field updates…hummmm! :frowning:

7

What are you sending that you need to send 66 bytes?

How many sensors do you have connected to your node?

8

Don’t think he is….he’s seeing foreign packets on his gw with larger size……

9

:thinking: IIRC at least one of the deployed district lighting control guys send a larger network status message every once in a while…. Think one of the mid wales forumites was seeing something a year or so back…. I need to dig :wink:

10

Looking at that dev addr… it is a foreign network vs TTN/TTI!