3 ms·

The electricity required is precisely the problem why we don’t do it. And it’s not so much the power that it requires but that the extremely low energy density

The electricity required is precisely the problem why we don’t do it. And it’s not so much the power that it requires but that the extremely low energy density of lithium batteries means we have to minimize power usage as much as possible.

contingencies 5y ago
I see no reason why mesh networking should need a huge amount more power than traditional mobile data. If we take the assumption that the vast majority of potential mesh members are unwanted (ie. you are not running a 'fully open' mesh network) then you can trivially ignore data that does not match an originator to which you have pre-approved listening. Similar to ethernet MAC filtering, I believe this is how implementation works in silicon. And indeed this seems to be the case. https://docs.kernel.org/driver-api/80211/mac80211.html?highlight=mesh https://docs.kernel.org/driver-api/80211/mac80211.html?highl... If you were relaying a lot of traffic for approved peers, then sure you are going to have a higher power profile. However, if you are doing this on an ongoing basis you are probably not battery-constrained (eg. you are connected to a larger power supply such as a vehicle, etc.) and you are potentially talking lower signal strength and closer peers. So it's really an application-specific concern.
- teraflop 5y ago
  If you read datasheets for radio transceivers, one of the first things that will jump out at you is that simply keeping the analog radio front-end powered on -- either in listening or receiving mode -- is by far the biggest source of power consumption. (At least, this is true for all of the microcontrollers and relatively low-power embedded devices I've looked at. I can't guarantee how true it is for things like phones.) For instance, the popular ESP8266 chip uses roughly 1mA in sleep mode, 15mA when the CPU is awake but the radio is off, 50mA when receiving, and 100-200mA when transmitting. Nordic Semi's comparable nRF52810 uses less power, but follows a similar pattern: <1mA sleeping, 2mA with CPU active, 6mA receiving, 8mA transmitting. So if you tell the radio hardware to discard packets that aren't addressed to you, you may be able to save a small amount of power by avoiding unnecessary CPU activity, but you will still be using dramatically more power than a non-mesh network in which your node could go to sleep when not in use. In order to have any chance of getting reasonable battery life from a small mobile device, you need a protocol that establishes short time slots for devices to wake up and find out if they have any incoming data, so that they can spend as much time as possible with their radios turned off. This is difficult to achieve in a decentralized mesh.
  - contingencies 5y ago
    While I don't doubt your line of reasoning, one would assume these factors were taken in to account by the specialists who designed the protocols and they would have used obvious strategies like reducing the time domain for new peer associations and added predictive schedules for ongoing transfers. These must be common building blocks in radio protocol engineering. Also, relatively speaking, modern wireless transfer rates are very fast and therefore transmissions will only be sporadic, and 200mA is not a lot of power. Ignoring other factors, napkin says you would have to hold 200mA consumption solidly for 15 hours to deplete a modern smartphone's 3000mAh battery. Most mobile mesh networking use cases will have long since concluded by that point. According to a 2017 PhD dissertation[0] on a sample device cellular eats way more than wifi in the normal idle mode (p56). Therefore, if we ditch cellular there may actually be power budget savings when idle. However, all radio communications are totally dwarfed by display power (p58, p67, p72), especially at high brightness levels (p59). [0] https://trustworthy.systems/publications/papers/Carroll%3Aphd.pdf https://trustworthy.systems/publications/papers/Carroll%3Aph...
    - roeles 5y ago
      > While I don't doubt your line of reasoning, one would assume these factors were taken in to account by the specialists who designed the protocols and they would have used obvious strategies like reducing the time domain for new peer associations and added predictive schedules for ongoing transfers. These must be common building blocks in radio protocol engineering. In wifi, this is handled by the base station if I'm correct. It assigns slots for the associated receivers. Assigning slots in a mesh network without coordination is effectively a graph coloring problem and difficult to solve. My professor for my master thesis was the author of LMAC, which attempted to assign slots to each node. It worked great in theory, but not so much in practice.
      - contingencies 5y ago
        LMAC (2003) @ https://research.utwente.nl/files/5427399/VanHoesel_INSS04_048.pdf https://research.utwente.nl/files/5427399/VanHoesel_INSS04_0... seemed to target energy efficiency on bursty, short messages on fixed topology wireless networks, whereas we were discussing the potential for ad-hoc mesh for a general use case using existing wireless chipsets. To take up the tangent, it seems to me that the graph coloring problem can either be (1) solved universally (any local mesh will have distinct boundaries which make absolute coordination feasible) by adding some sort of explicitly negotiated or progressively developed shared state to act as a coordination layer (2) solved temporarily, for example by implementing a best-effort failover/fallback (CSMA/CD feeds back to "color") (3) Ignored. Solution class 1 is obviously challenging to apply to for mobile and ad-hoc mesh networks. Solution class 2 seems more realistic for this category of use case. Solution class 3 works well if you have full control of the application layer (eg. wireless sensor network is push-only with short packets with high temporal tolerance for retransmissions). Feels a bit like "Energy optimization / throughput / ad-hoc topology / traffic generality. Choose any three."

contingencies 5y ago

I see no reason why mesh networking should need a huge amount more power than traditional mobile data. If we take the assumption that the vast majority of potential mesh members are unwanted (ie. you are not running a 'fully open' mesh network) then you can trivially ignore data that does not match an originator to which you have pre-approved listening. Similar to ethernet MAC filtering, I believe this is how implementation works in silicon. And indeed this seems to be the case. https://docs.kernel.org/driver-api/80211/mac80211.html?highlight=mesh https://docs.kernel.org/driver-api/80211/mac80211.html?highl... If you were relaying a lot of traffic for approved peers, then sure you are going to have a higher power profile. However, if you are doing this on an ongoing basis you are probably not battery-constrained (eg. you are connected to a larger power supply such as a vehicle, etc.) and you are potentially talking lower signal strength and closer peers. So it's really an application-specific concern.

teraflop 5y ago
If you read datasheets for radio transceivers, one of the first things that will jump out at you is that simply keeping the analog radio front-end powered on -- either in listening or receiving mode -- is by far the biggest source of power consumption. (At least, this is true for all of the microcontrollers and relatively low-power embedded devices I've looked at. I can't guarantee how true it is for things like phones.) For instance, the popular ESP8266 chip uses roughly 1mA in sleep mode, 15mA when the CPU is awake but the radio is off, 50mA when receiving, and 100-200mA when transmitting. Nordic Semi's comparable nRF52810 uses less power, but follows a similar pattern: <1mA sleeping, 2mA with CPU active, 6mA receiving, 8mA transmitting. So if you tell the radio hardware to discard packets that aren't addressed to you, you may be able to save a small amount of power by avoiding unnecessary CPU activity, but you will still be using dramatically more power than a non-mesh network in which your node could go to sleep when not in use. In order to have any chance of getting reasonable battery life from a small mobile device, you need a protocol that establishes short time slots for devices to wake up and find out if they have any incoming data, so that they can spend as much time as possible with their radios turned off. This is difficult to achieve in a decentralized mesh.
- contingencies 5y ago
  While I don't doubt your line of reasoning, one would assume these factors were taken in to account by the specialists who designed the protocols and they would have used obvious strategies like reducing the time domain for new peer associations and added predictive schedules for ongoing transfers. These must be common building blocks in radio protocol engineering. Also, relatively speaking, modern wireless transfer rates are very fast and therefore transmissions will only be sporadic, and 200mA is not a lot of power. Ignoring other factors, napkin says you would have to hold 200mA consumption solidly for 15 hours to deplete a modern smartphone's 3000mAh battery. Most mobile mesh networking use cases will have long since concluded by that point. According to a 2017 PhD dissertation[0] on a sample device cellular eats way more than wifi in the normal idle mode (p56). Therefore, if we ditch cellular there may actually be power budget savings when idle. However, all radio communications are totally dwarfed by display power (p58, p67, p72), especially at high brightness levels (p59). [0] https://trustworthy.systems/publications/papers/Carroll%3Aphd.pdf https://trustworthy.systems/publications/papers/Carroll%3Aph...
  - roeles 5y ago
    > While I don't doubt your line of reasoning, one would assume these factors were taken in to account by the specialists who designed the protocols and they would have used obvious strategies like reducing the time domain for new peer associations and added predictive schedules for ongoing transfers. These must be common building blocks in radio protocol engineering. In wifi, this is handled by the base station if I'm correct. It assigns slots for the associated receivers. Assigning slots in a mesh network without coordination is effectively a graph coloring problem and difficult to solve. My professor for my master thesis was the author of LMAC, which attempted to assign slots to each node. It worked great in theory, but not so much in practice.
    - contingencies 5y ago
      LMAC (2003) @ https://research.utwente.nl/files/5427399/VanHoesel_INSS04_048.pdf https://research.utwente.nl/files/5427399/VanHoesel_INSS04_0... seemed to target energy efficiency on bursty, short messages on fixed topology wireless networks, whereas we were discussing the potential for ad-hoc mesh for a general use case using existing wireless chipsets. To take up the tangent, it seems to me that the graph coloring problem can either be (1) solved universally (any local mesh will have distinct boundaries which make absolute coordination feasible) by adding some sort of explicitly negotiated or progressively developed shared state to act as a coordination layer (2) solved temporarily, for example by implementing a best-effort failover/fallback (CSMA/CD feeds back to "color") (3) Ignored. Solution class 1 is obviously challenging to apply to for mobile and ad-hoc mesh networks. Solution class 2 seems more realistic for this category of use case. Solution class 3 works well if you have full control of the application layer (eg. wireless sensor network is push-only with short packets with high temporal tolerance for retransmissions). Feels a bit like "Energy optimization / throughput / ad-hoc topology / traffic generality. Choose any three."