View
1
Download
0
Category
Preview:
Citation preview
CPS summer schoolThe Internet of Things Energy
Consumption Issues
Bernard Tourancheau
UJF, Grenoble-Alpes Université, UMR LIG Drakkar,
1
Why is Energy important (from IEA)
Oil reserves
2014
Cheap&easy energy is not even a possibility !→ bounded energy systems ...
Internet of Things (IoT)
● SoC● Computing● IP Networking● Sensor(s)● Actuator
→ for any object !
NB : related to WSN, M2M, ...
IoT nodes constraints
Low Power Networks Very limited resources
Energy Processing Memory
4
UbiMob 2013 – B. Tourancheau – Watteco – LIG, France.
But VAX11=TelosB ! ● 1978, computer room, DEC VAX 11/780 mainframe, 8kB RAM, 5MHz 32-bit
processor + Ethernet+main power● 2004, matchbox, Telos Berkeley mote, 10kB RAM, 8 MHz 16b MCU + radio
+ AA battery● 2010, watch, TI ez430 chrono, 8kB RAM, 32kB Flash, 16 MHz 16b-Bit
MCU + radio + LCD +button battery● 2012, thick credit card, STM Greennet, 32kB RAM, 256kB Flash, 32 MHz
32b ARM + radio + PV power supply.
Internet of Things : Privacy
(→ The end of intimacy ?) → IoT everywhere ?
IoT growth
> 50 Billion smart devices connected to the Internet by 2020 ! (Ericson)
Energy issue in the IoT
●SoC lifetime● Battery● Scavenging● mW
● Probe power● uW to 10W
● IoT power scale● mWx10^12=GW
9
IoT's powerBattery
Capacitor
Scavenging: PV, Peltier, ...
Mains (cf CPL)
However Billions of IoT devices → Billions of Watts ! There is No Moore’s law for battery technologyNiCd efficiency in J per volume improved by only x2 over the last 30 years…
Chemical ions breakthrough against electrons lithography ...
This is a major pollution source :-((
IoT Energy trends ?
CPS summer schoolThe Internet of Things Energy
Consumption Issues
Bernard Tourancheau
UJF, Grenoble-Alpes Université, UMR LIG Drakkar,
10
11
Architecture
→ Sinks placement
→ Reduced routing
Hardware Energy Consumptions
→ MCU
→ Transceiver
→ Probes
Software Impacts
→ Routing, # of packets
→ OS Optimizations
→ Address compression, coding
Energy in IoT Outline● Cross-layer routing protoco ls
→ energy savings
→ performance● Security
→ the real cost
→ OSCAR● Conclusion & Perspectives
IoT Stub Network Architecture
See L. Ben Saad PhD thesis in references [1].
13
Energy Hole Problem with batteries
Sink
Sink Sensor
14
Energy Hole Problem
SinkSensor
15
Energy Hole Problem
SinkSensor
Nonunifrom node distributionTransmission power control
Clustering approachesStatic sinks
Nodes mobility...
Sinks mobility
Solutions
16
Sinks placement optimization
Moving sinks (really/virtually) Updating the routing accordingly
Instance X
Sensor
Sink
How to choose Sinks positions to improve network lifetime ?
→ ILP optimization
17
Sink placement optimization
We compute for leaf nodes in the routing DODAG
Number of hops between node and the DAGROOT at position k
Residual energy of node Number of neighbors of node Normalization parameters Sinks move towards the leaf node with highest
→ ILP and heuristics solutions iw
iikiii
kii behbehfw )(
kih
ie
ib
,
18
ILP Formulation
Z ( s )
m..kkkl 21
Variables
Parameters
Wireless Network : G(V,E) S the set of IoT nodes F the set of feasible sites E represents the set of wireless links.
FSV E ⊆V × V
m Number of sinks
T Minimum duration of sinks sojourn time in s
e0
Initial energy of each sensor in J
eT
Energy consumption coefficient for transmitting one bit in J/bit
eR
Energy consumption coefficient for receiving one bit in j/bit
gr
Data packets generation rate in bit/s
rk
ijData transmission rate from node i to node j where the nearest sink stays at node k in bit/s
Nk
iSet of i’s neighbors whose their nearest sink is at node k.
Pk1k2...kn
iPower consumed in sending and receiving data by sensor node i when the first sink is located at node k1, the second sink is located at node k2 etc. and the m-th sink is located at node km in J/s
Pk
iPower consumed in sending and receiving data by sensor node i when the nearest sink is located at node k in J/s
Introduction Related Works Network Model Sinks positioning Simulation Results Discussion Conclusion
Network lifetime in s
Integer variables
19
, , integer, is ,0
, ..
..
21 .. ..
0 . .
..
..
2121
21
21
21
21
21
FkFkFkll
SieplT
lTZMax
mkkkkkk
Fk
kkkikkk
FkFk
Fkkkk
FkFk
mm
m
m
m
m
m
Integer Linear Program
(1)
(2)
(3)
FkFkFkFkSi
ikkkknearestSinkpp
m
mki
kkki
m
,..,,,
),( ,
21
21..21
kF, iS, kigep
kiFkSigrerep
rTki
Nijr
kT
Nij
kR
ki
kj
jikj
ji
,
,, )(::
(4)
(5)
(6)
Introduction Related Works Network Model Sinks positioning Simulation Results Discussion Conclusion
20
10x10 sensors and 3 sinks, minhop = 9
Example of Sinks locations pattern
t = 0 t = T
t = 2T t = 3 T
Sink location
SensorId
Id
Id : node identifier
Introduction Related Works Network Model Sinks positioning Simulation Results Discussion Conclusion
21
Static: S inks p laced in optima l locations Periphery: Sinks moving in the network periphery Random: Sinks moving randomly Hop: Sinks moving according to Hop heuristic OPT: Sinks moving according to ILP solution
Comparative sink placement study
Introduction Related Works Network Model Sinks positioning Simulation Results Discussion Conclusion
22
Residual Energy per nodeAt the end of network Lifetime, 10x10 sensors and 3 sinks :
Static Periphery Random OptHop
1 Static Periphery Random Hop Opt
Unused energy 71% 45% 31% 17% 3%
Nb sensors with more 50% e0
80 60 20 4 4
Introduction Related Works Network Model Sinks positioning Simulation Results Discussion Conclusion
23
10x10 sensors T=30 days
Lifetime against # of sinks
0
0,5
1
1,5
2
2,5
Static
Periphery
Random
Hop
Opt
Number of sinks
Lifetime
(E+10
seconds)
Introduction Related Works Network Model Sinks positioning Simulation Results Discussion Conclusion
Best number of sinks
Simulations with RF-CPL parameters on monitoring app. 25 nodes on batteries 1-10 sinks optimaly positionned
App : node send 46B payload packet / minute to sink(s)
Lifetime x7
With 10 sinks
27
Architecture Autonomous battery powered RF “leaf” nodes Main powered RF-PLC router nodes
Networking and Stack Architecture 802.15.4 RF&CPL + 6LoWPAN IPv6 adaptation RPL routing + CoAP + ZCL RPL → DODAG Tree-base convergecast
Avoiding battery powered routing
Always ON Link
Energy constrained Link
Router Node (Always ON)
Leaf Node (Energy constrained)
Router Node (Always ON + Manage data delivery to leaves)
28
PLC nodes
• Standard Homeplug:– AV: OFDM / 20 - 200Mbps– GP: OFDM / 4 - 10 MbpsBUT :– Cost: a dozen $ – Power consumption : a few Watts– Size: Big
• The WPC™ Watteco Transceiver :– Specific Transceiver – 50Hz Pulses : 10 kbpsBUT :– <1$– 10 mW – 25 mm²
29
Architecture Wrap-up
Optim ized : – S inks p lacement– Sinks number
Routing tree with :– Battery powered
leaf nodes– Sinks routers
Energy efficiency with :
30
IoT Nodes Hardware
See C. Chauvenet PhD. Thesis in references [2].
Recal RF nodes
Low Power Wireless Networks Very limited resources
Energy Processing Memory
32
33
MCU Low power SoC → PC of the early 80's A few kB RAM, 100kB flash A few MHz
Transceiver Low Power RF Dozens kb/s High PER
Power source Probe(s) and ADC logic
Typical wireless nodes
WeC - 1999 Tmote SKY – 2004 [1] STM Greennet - 2012
IoT RF node schematic
34
Typical testbed node
38
2 MCU considered:- TI MSP430 (16 bit RISC – 16k RAM – 256k Flash)- SIM3CIxx (32 bit Cortex M3 – 32k RAM – 256k Flash ) :
4 different RF Transceivers considered: - 2.4 GHz : ATRF230- 868 MHz : ATRF212 / SI4461 / CC1120
6 Probes considered: • CO2 / Temperature / Temperature-Humidity / Presence / Door
Opening / Light
Nodes studied
→ Seeking for the lowest power consumption configuration
39
Bidirectional frame exchange power profile (NS/NA pkt) :
Typical Node Power Consumption
The RF Transceiver is clearly the Highest Power consumer.
But what about its Energy Budget when integrated over time ?
1 2 3 4 5 6 7 8 1 : Sleep mode2 : MCU Wakes Up3 : Transceiver Wakes Up4 : Radio Tx (NS packet)5 : Waiting for Ack6 : Radio Rx (NA packet)7 : Radio Tx (ACK)8 : Back to Sleep Mode
40
Measured MCU Wake up power through a 10.1 Ohms Load over 3V :
Energy is Lower at 16 MHz for our application, compared to 8 MHz Activity time divided by 2 Power multiplied by less than 2
MCU Energy Consumption
41
Power consumptions extracted from datasheets → Radio Links considered ideal Propagation Model Based on the Friis formula :
Prcv
= 22dB + 20 ∗ log(d/λ)
Transceivers Energy Consumption
ATRF230 (2.4 GHz) is much better for short range SI4461 (868 MHz) is the best for long range
For a given d radius, λ has a great impact on power consumption (and collisions and PER and router reachability and throughput ...).
Hardware wrap-up
For the target monitoring application :● Transceiver power > MCU power but may be used less
● MCU better at high frequency● Transceiver choice depends on inter-nodes distances and context
→ application dependant compromises
Software
See Ben Saad and Chauvenet PhD. Thesis in references [1] and [2].
44
• Contiki OS Based • IPv6 Stack following IETF and industry “standards” :
• 802.15.4-2006 (IEEE) • 6LoWPAN (IETF)• IPv6 (IETF)• RPL (IETF)• ZCL (Zigbee alliance)
→ The aim of the operating software is to turn the node componants in « sleep mode » as long as possible:
Low MCU activity through such duty cycling
Typical IoT software stack
45
• Resources are constrained thus : Low Radio activity through duty cycling MAC Protocol
→ a lot of ongoing research on that subject with beacons, slots, ... Reduce number of packet transmitted for network control Reduce Frame size:
→ Compression (6LoWPAN – CoAP)→ Aggregation→ Adresse Coding
Typical IoT networking stack
47
Routing is ensured on main powered nodes RPL proactive routing storing mod.
→ high values for periodic timers: trickle, DTSN, ... NS/NA periodic exchanges
→ trickle doubling delay timer with high max value Upward data anytime thanks to routers' availability Downward data packets triggered by piggybacked flag on NA Typical numbers of packets for a day in a monitoring app. :
Reduced # of control packets
48
SIM3C1 MCU better than MSP430 4xx→ test bed is MSP430+ATRF212 → but best seems: CortexM3 MCU + SI4461 RF
Must avoid LDO (DC/DC) energy cost Largest relative part of active energy in Radio TX and MCU Wake Up Years of theoritical lifetime
AAA battery lifetime
49
Increase periods of (or suppress) tasks that are not or seldom used Wake Up period set to 1 Hz / Fast wake-up
→ estimated lifetime rised up form 7,16 to 12,55 years for 1 000 mAh AAA Low Power mode + LP Internal Oscillator → estimated lifetime reaches 20,23 years for 1 000 mAh AAA
OS Optimizations
50
Total Bytes Sent/Received (over a day) → 28892B / 17128B Radio Activity ratio : only 0,021% of time
Platform Consumption Overview
After All Optimizations
Lifetime → >20 yearsBattery leakage 1 % / year → >16 years
51
Depends on precision Depends on internal sampling period May also affect battery depletion profile.
Probes Consumption Impact
Software optimization wrap-upThanks to arch itecture choice and application driven optim izations
→ >10 years lifetime on battery seems possible
→ Mandatory software duty cycling technics in network and OS
Nb: No RDC overhead with our architecture → research space in this domain is active
Address compression
Address compression
See L. Ben Saad PhD thesis in references [1].
Control information is big
Typical MTU Packet 127 bytes in IEEE 802.15.4 low power wireless IPv6 Header : 40B with 2x16B addresses
Header Payload
Packet
56
Motivation
Minimize energy consumption of sensors by reducing the amount of transfered control bits
Reducing header size by reducing addresses' size Exploiting RF overhearing and addresses correlation
57
Overhearing
Sinky
s
zyA
58
S overhears → Slepian-Wolf source coding S overhears → Slepian-Wolf source coding
yA
Transmission range
Example
Sinky
s
zyy AB
FAAB syy 7)(
59
Example
Linear Code [128,120,4] (8 bits)
Sinky
sz
yy AB
FAAB syy 7)(
1),( syH AAd
407:1::8000:92
406:1::8000:92
DDA
DDA
s
y
(128 bits)
(128 bits)
60
3),( syH AAd
Adresses allocation
Allocation scheme :- Assign unique address of X bits for 1-hop neighbors- m bits of X are reserved- (X-m) bits remaining used to allocate
addresses to children of 1-hop neighbors- Hamming distance increases with the depth of the tree
Allocation scheme :- Assign unique address of X bits for 1-hop neighbors- m bits of X are reserved- (X-m) bits remaining used to allocate
addresses to children of 1-hop neighbors- Hamming distance increases with the depth of the tree
61
Multi-hop networks
Cluster based overearing
Cluster purpose Optimize sinks' placement Exploit overhearing and addresses correlation Reduce the size of transmitted addresses of battery-powered nodes
62
Sink Battery-poweredsensor
Line-powered sensor
Cluster
Optimization
Max-Min problemMax-Min problem
)()(
, ,
][minmax
0
izampel
izcrerili
li
li
liSiLl
dEErEgEgp
SiLlp
et
tT
else
det 0 If m iniz
r
lirl
ig
dNgr
else 0
0 If 1 li
i
N
1
min )1(
amp
ce
E
EEd
Condition
63
Addresses compression wrapup
Overhearing and addresses Set-up during network initialisation Reduction of addresses size by applying Slepian-Wolf coding Assumes a communication schedule May provides very small adresses
Overhearing and addresses Set-up during network initialisation Reduction of addresses size by applying Slepian-Wolf coding Assumes a communication schedule May provides very small adresses
65
72
→ Several research domains make IoT possible→ Application dependencies for optimizations→ Protocols optimizations necessary→ Very long lifetime seems possible
Still, the way to power the 10^12 devices of the future IoT may be a difficult path.
Next Steps: - Use scavenging nodes with µW average power ! - Expand software stack improvements to upper layer protocols such as CoAP and the IPSO Application Framework- Include object security architecture in the IoT
IoT Conclusion & Perspectives
73
Some bibliography Bibliography[1] Leila Ben Saad, Stratégies pour améliorer la durée de vie des réseaux de capteurs sans fil,
Thèse de doctorat, ENS-Lyon, 2011.
[2] Cédric Chauvenet, Protocoles de support IPv6 pour réseaux de capteurs sur courant porteur en
ligne, Thèse de doctorat, Grenoble Université, 2013.
[3] Malisa Vucinic, Protocoles pour la sécurité des réseaux de capteurs ; Thèse de doctorat, Grenoble
Université, 2016.
Vucinic et al., "OSCAR: Object Security Architecture for the Internet of Things", WoWMoM, IEEE, 2014. [4] Vucinic et al., "OSCAR: Object Security Architecture for the Internet of Things", WoWMoM, IEEE, 2014.
74
Thanks ! Questions ?
Recommended