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.
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%3Aph...
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.
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."
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.