Video services use adaptive bitrate so a 1 second sample will give a very variable estimate. If you can watch the full video and monitor the NIC bandwidth (or, if you don't want to count headers, download the full video and look at the media info average bitrate) you'll get a more consistent number. For 1080p TV type content it's often a lot more than 262 MB/h. Raw should be 192010803*24 = ~149 MB since there are 24 frames in a second, keeping that magic of video compression alive despite the larger base rate.
Netflix actually gives the value of 3 GB/hour directly for high definition content https://help.netflix.com/en/node/87 which is ~833 KB in one second (or about an average 6 mbps plus some delivery overhead) which simplifies things quite a bit though.
Encryption is an interesting thought in that LoRaWAN will have encryption built in and the device would typically expect the gateway to handle producing that to IPv6 with traditional encryption and application headers. CTR is used so the packets don't gain much bloat, the minimum size is ~bytes and the maximum size is ~256 bytes. Temperature reports (4 byte float) typically fit in that 50 byte minimal packet category or 432 KB/day reporting every 10 seconds. So I suppose my estimate of 5x was a bit high after all, maybe 1-2x would have been more apt :). But it does beg the question, back to your point, what would that look like in this WiLo protocol? Standard Wi-Fi has a minimum frame size in the air is going to be closer to 100 bytes (minimum Ethernet length of 64 plus Wi-Fi bits). On top of that Wi-Fi doesn't usually act as the gateway like LoRa - does the IoT device now need to package everything in IPv6 + transport security itself and send it over the air with WiLo or is the expectation APs would be more gateway like for these clients? Dunno, wasn't able to read the actual paper in the link to see what is proposed :).
Netflix actually gives the value of 3 GB/hour directly for high definition content https://help.netflix.com/en/node/87 which is ~833 KB in one second (or about an average 6 mbps plus some delivery overhead) which simplifies things quite a bit though.
Encryption is an interesting thought in that LoRaWAN will have encryption built in and the device would typically expect the gateway to handle producing that to IPv6 with traditional encryption and application headers. CTR is used so the packets don't gain much bloat, the minimum size is ~bytes and the maximum size is ~256 bytes. Temperature reports (4 byte float) typically fit in that 50 byte minimal packet category or 432 KB/day reporting every 10 seconds. So I suppose my estimate of 5x was a bit high after all, maybe 1-2x would have been more apt :). But it does beg the question, back to your point, what would that look like in this WiLo protocol? Standard Wi-Fi has a minimum frame size in the air is going to be closer to 100 bytes (minimum Ethernet length of 64 plus Wi-Fi bits). On top of that Wi-Fi doesn't usually act as the gateway like LoRa - does the IoT device now need to package everything in IPv6 + transport security itself and send it over the air with WiLo or is the expectation APs would be more gateway like for these clients? Dunno, wasn't able to read the actual paper in the link to see what is proposed :).