Medium Access Protocol for the EYES sensor nodes

1. Medium Access Protocol for the EYES sensor nodes Lodewijk van Hoesel hoesel@cs.utwente.nl

2. Contents • Current EYES sensor node design • Network structure • MAC protocol • Future work

3. Current sensor node design • Processor: TI MSP-430F149 • 560 μA for 1 Mips • 16 bit • 2 Kb RAM • 60 Kb ROM • Built-in AD converter • Supports power save modes • Transceiver: RFM TR1001 • 115.2 Kbps data rate • Amplitude Shift Keying (ASK) • No mixers are used; SAW filters • Very low standby power consumption • Analog RSSI (AD converter necessary)

4. RFM TR1001 worst case power consumption: Transmit 20.0 mJ/s Receive 14.4 mJ/s Dormant 15.0 µJ/s Battery capacity 3.6 V @ 1Ah12.96 kJ 180 h 250 h 27 y RF power consumption in the current sensor node design

5. Network structure • Wireless network nodes are capable of: • Measuring physical conditions • Relaying messages from other nodes • Routing decides main function: • Sensor node (mainly measuring; passive or event driven) • Relay node (mainly relaying messages; passive)

6. Communication types RARELY • Sensor node Sensor node • Route discovery, clustering, neighborhood discovery, localization • Unicast or Multicast • Relay node Sensor node • Requests for data, signaling messages • Unicast or Multicast • Sensor node  Relay node • Sensor data • Unicast • Relay node Relay node • Backbone traffic • Unicast OFTEN

7. MAC protocol: CSMA, CDMA, FDMA, TDMA,... ?? • Carrier Sense Multiple Access (CSMA) • High collision rate • Transmissions of sensor data occurs in groups due to physical event horizon • Requires constant channel monitoring • Code Division Multiple Access (CDMA) • Requires signal processing of analog received signal • Not supported by current hardware design • Requires constant channel monitoring • Frequency Division Multiple Access (FDMA) • Requires multi-channel receiver • Not supported by current hardware design • Requires constant channel monitoring • Time Division Multiple Access (TDMA) • Does not require constant channel monitoring • Requires synchronization between nodes

8. Overview of the proposed MAC protocol for the EYES sensor nodes • Communication Request (CR) • Claim a timeslot (for nodes that join the network) • Notify the need for data communication to the owner of the timeslot • Traffic Control (TC) • Owner of the timeslot transmits its schedule • Data • Contains a data packet

9. Communication Request Section • Contains requests to timeslot owner • Node Announcement (NA) • Request to listen to TC in specified timeslot • Request to Receive (RTR) • Useful to ask data from passive sensor nodes • Request to Send (RTS) • Useful for event driven nodes and relay nodes • Collisions can occur • Timeslot owner should detect collisions • Retry in data section (CSMA/cd based) • Direct transmission of (abbreviated) request +data • Only useful for RTS

10. Traffic Control Section • TC Schedule • Indicates to which TCs this node is listening • New nodes in the network: “AND” all schedules, a timeslot is free at “zero” • Acks/Nacks of request in CR • Contains a “collision detected” flag • Timeslot owner listens to data section for retries • NA is acknowledged implicitly in TC schedule • Multicast flag • Gives the node the option for multicast transmissions • Request for Any (RFA) • Gives the node the option to request for a reply of any node that has the specified information available • Random node respond in data section (CSMA/cd)

11. Data Section • TC indicates whether Data Section is: • Used • Data transmission as indicated in TC • Free • May be used for transmissions agreed on higher protocol layers • “Slotted” CSMA/cd usage • i.e. 8 possible start times for transmissions • Priority of the data section usage: • Multicast transmissions (discards any requests in CR except NA) • Request to Send (RTS) • Request to Receive (RTR) • Requests for any (RFA) data type • Higher protocol layers (CSMA/cd)

12. Energy consumption (transceiver only) with current MAC design: Overhead • Receive • CR (18 bytes) in own timeslot: 1.25 ms 18 µJ/frame • TC of 4 other nodes: 5.00 ms 72 µJ/frame • Transmit • Own TC (18 bytes): 1.25 ms 25 µJ/frame • Sleep • Remainder of the frame: 992.50 ms 15 µJ/frame 130 µJ/frame Lifetime of a sensor node: 3 y 60 d +

13. Conclusion: MAC protocol power consumption • Minimize the number of transmissions • Do useful transmissions • Each transmission should reach its sink • Do not discard packets • Add own sensor readings to relayed data • Group transmissions to a neighbor • Compress data • Minimize the number of transmitted TCs • Minimize the number of receptions • Minimize the number of received TCs • Use wakeup schemes

14. Timeslot Ownership • Not all nodes need to own a timeslot • Event driven nodes may redeem their right to own a timeslot • Saves energy • Eases scalability of the network • Can participate in: • Do RTS/RTRs in CR sections • Listen to omnicast messages • Receive data on higher layers negotiated times

15. Current state of MAC implementation • Finalizing OS radio control functions • MAC implementation • Work in progress • No higher layer negotiated communication • No CSMA/cd retries of collisions in CR • To do: physical layer • Measurements to determine: • Best DC balancing scheme • Preamble usage for UART synchronization • Transmission power control • “Raw” bit error rate

16. Ideas for MAC protocol communication demonstration • Coffee status • Measure weight of coffee can • Determine coffee machine status; coffee ready?? • Mobility test • Node controls an electric car • Determine direction of a beacon and drive to it • Room temperature and light • Rapport temperature and light in a number of rooms