we are interested to know EU band restrictions on operating HaLow and how we should prepare for this. From the spec, it says we have 1-2 Mhz channels and also the duty cycle is low (1%)
For our use case, we are streaming data once every 10 seconds. The duration of this transmission is ~400ms. Would this ON time need to be reduced to match duty cycle restrictions for EU?
@venkatr you are correct that the EU does only have 1 and 2MHz channels. The duty cycle restrictions are 10% for an AP, and 2.8% for a STA and that’s measured over an hour. That means you can transmit for 360 seconds every hour as an AP, and roughly 100 seconds as a STA.
If you’re needing to transmit 400ms every 10 seconds, that is roughly 144 seconds, which is below the AP duty cycle, but exceeds the maximum allowable amount for STA. Note - those times also need to account for MAC layer acknowledgements, management frames, and on the AP - beacon frames.
Our firmware will automatically try to spread your transmissions out across the hour. We do also support a burst mode that lets you send at full throughput up to the duty cycle, but note on the AP side we do reduce the allowable time to ensure that beacons can be transmitted across the whole hour.
Depending on which ETSI standard you certify against, it may be possible to certify a device slightly differently using adaptive frequency agility and avoid the duty cycles, but that is not something we currently offer support for
hi..@swadsworth - thank you for the response. This duty cycle limitations are too restrictive for EU bands. Can you share more details on adaptive freq agility? is this something you will support in future
Adaptive frequency agility requires us to change the operating channel under certain conditions and is driven from the AP. Our STAs will automatically follow. This will be available in an upcoming major release but I can’t provide a firm date for that.
I’ve been combing through ETSI EN 300 220 on this and it’s not actually clear that channel switching is required for single-channel operation or avoiding the duty cycle. It’s one possible mode of achieving AFA equivalence but not by any means the only way to achieve compliance.
The requirements are:
Polite spectrum access: already satisfied by 802.11ah with CSMA/CA and CCA;
Random deferral: already satisfied by 802.11ah with the binary exponential backoff;
CCA threshold: configurable in 802.11ah via the energy detect threshold;
Minimum transmitter off time & listening time: already satisfied by 802.11ah with the mandatory idle time after transmission;
Maximum transmitter on time: already satisfied by 802.11ah with the TXOP limits, further improved by limiting PPDU aggregation.
With that, equivalent coexistence behaviour to AFA is already demonstrated and there’s no reason that the duty cycle can’t be avoided or that 802.11s shouldn’t be usable within ETSI regions?
Would AFA allow for continuous video streaming on EU bands? Can we get an idea on sustained bandwidth between a single AP and client in ideal conditions?
I have the same question. It’s not clear to me whether 100% duty cycle is possible in EU (for low bit-rate audio in my case). I saw a screenshot in another thread that suggested that enabling LBT and AFA would bypass duty cycle restrictions, but is that true?
So for this, I’ll be using Wikipedia’s video bitrates[1] 240p@H.264 needs 400Kbps, and 360p@H.264 needs 750Kbps. Alternate encoding schemes are definitely worth consideration.
From my current reading on the ETSI EN 300 220-2[2]:
Polite spectrum access means that you’re beholden to the polite spectral use requirements stipulated in Section 4.6.3, Table 18[2]. So it doesn’t seem like DC bypass is possible @zlp.
That table requires a 100s/h cumulative on time per 200KHz of spectrum. The lowest we can slice the spectrum is into 1 MHz channels, which thankfully is a multiple of the 200KHz slicing. This means that if you’re able to use all 5 1MHz channels with AFA you have 500s/h of cumulative on time.
If you plug in the max data rate at MCS9 of 4.4Mbps[3], that equates to 2200Mbits/h, or approximately 610Kbps. @DaveNol this’ll be the max possible bitrate going by my reading of the regs.
The minimum viable of MCS6 comes in at 3.0Mbps[3], or 1500Mbits/h or approximately 416Kbps.
That means that if you’re theoretically able to get 240p@H.264 with some caveats:
MCS6 minimum
Frames have to be sent in bursts… stretching the definition of streaming
You’re actually able to use all 5 channels, no interference. You may be able to eek by with 4 channels with a minimum of MCS8
This is of course going off my interpretation of the regulations, we may need to do some statistical analysis on everyone’s conclusions on what they actually mean
Definitely run it by your local compliance house if it comes down to it, they’ll have a better grasp of the situation.
Just following up on this, as I am wondering to what extent this has been considered by Morse Micro. It is not at all clear that the channel switching is even required for compliance. Thanks!
With that, equivalent coexistence behavior to AFA is already demonstrated and there’s no reason that the duty cycle can’t be avoided or that 802.11s shouldn’t be usable within ETSI regions?
The way I’m reading it, rows K & L of Section 4.2.4 Table 4, when you’re not duty cycle bound, you’re bound to Section 4.6.3.2 Table 18, which denotes polite access timing limits and stipulates a maximum cumulative on time of 100/s per hour per 200KHz of spectrum. Single channel this would essentially be a ~2.8% duty cycle.
As far as compliance goes, we try to take in account the strictest interpretations of the regulations that compliance houses may arrive at, and as such our recommendations and default implementations strive to follow that. Based on the guidance from your local compliance house, these default implementations are free to be adapted and modified.