ห้องปฏิบัติการ วิจัยเชิงประยุกต์ระบบสื่อสารและสมองกลฝังตัว

1. Wireless Sensor Network Programming Part I : Programming Concept รศ. ณัฐวุฒิ ขวัญแก้ว natavut.k@ku.ac.th ศูนย์เชี่ยวชาญเฉพาะทาง ระบบสมองกลฝังตัวเพื่อการเกษตร (CEESA : Center of Excellence in Embedded System for Agriculture) ห้องปฏิบัติการวิจัยเชิงประยุกต์ระบบสื่อสารและสมองกลฝังตัว CAESAR Lab : Communication And Embedded System Application Research Lab. ภาควิชาวิศวกรรมไฟฟ้า คณะวิศวกรรมศาสตร์ มหาวิทยาลัยเกษตรศาสตร์ www.caesar-lab.com www.caesar-lab.com

2. Agenda • WSN Operating System • WSN Programming Model • WSN Data Link Layer • Data Link Layer Architecture • Medium Access Control (MAC) Protocol • Energy Awareness & Energy Calculation www.caesar-lab.com

3. WSN Operating System (1/2) • Should be compact and small in size since the sensor nodes have very small memory. • Should provide real-time support, since there are real-time applications, especially when actuators are involved. • Should provide efficient resource management mechanisms in order to allocate microprocessor time and limited memory. www.caesar-lab.com

4. WSN Operating System (1/2) • Should support reliable and efficient code distribution since the functionality performed by the sensor nodes may need to be changed after deployment. • Should support power management, which helps to extend the system lifetime and improve its performance. • Should provide a generic programming interface up to sensor middleware or application software. www.caesar-lab.com

5. WSN Programming Paradigms • Sequential Programming Model • Process-based Concurrency • Event-based Programming www.caesar-lab.com

6. Sequential Programming Model • a simple sequential model would run the risk of missing data while a packet is processed or missing a packet when sensor information is processed • This risk is particularly large if the processing of sensor data or incoming packets takes substantial amounts of time, which can easily be the case. Hence, a simple, sequential programming model is clearly insufficient. www.caesar-lab.com

7. Process-based Model • Equating individual protocol functions or layers with individual processes would entail a high overhead in switching from one process to another • This problem is particularly severe if often tasks have to be executed that are small with respect to the overhead incurred for switching between tasks – which is typically the case in sensor networks. www.caesar-lab.com

8. Event-based Programming Model The idea is to embrace the reactive nature of a WSN node and integrate it into the design of the operating system. • The system essentially waits for any event to happen, where an event typically can be the availability of data from a sensor, the arrival of a packet, or the expiration of a timer. • Such an event is then handled by a short sequence of instructions that only stores the fact that this event has occurred and stores the necessary information. The actual processing of this information is not done in these event handler routines, but separately, decoupled from the actual appearance of events • An event handler can interrupt the processing of any normal code, but as it is very simple and short, it can be required to run to completion in all circumstances without noticeably disturbing other code. • Event handlers cannot interrupt each other (as this would in turn require complicated stack handling procedures) but are simply executed one after each other. www.caesar-lab.com

9. WSN Data Link Layer Architecture www.caesar-lab.com

10. Medium Access Control Protocol for WSN • The assembly of data into a frame for transmission by appending a header field containing addressing information and a trailer field for error detection • The disassembly of a received frame to extract addressing and error control information to perform address recognition and error detection and recovery • The regulation of access to the shared transmission medium in a way commensurate with the performance requirements of the supported application www.caesar-lab.com

11. MAC Protocols • Fixed-Assignment Protocols • Demand Assignment Protocols • Random Assignment Protocols www.caesar-lab.com

12. MAC Protocols : Fixed-Assignment • Each node is allocated a predetermined fixed amount of the channel resources • Each node uses its allocated resources exclusively without competing with other nodes • Example : • frequency-division multiple access (FDMA) • time-division multiple access (TDMA), • code-division multiple access (CDMA) www.caesar-lab.com

13. MAC Protocols : Demand Assignment • To improve channel utilization by allocating the capacity of the channel to contending nodes in an optimum or near-optimum fashion. • Demand assignment protocols ignore idle nodes and consider only nodes that are ready to transmit • Unlike fixed-assignment schemes, where channel capacity is assigned exclusively to the network nodes in a predetermined fashion regardless of their current communication needs www.caesar-lab.com

14. MAC Protocols : Random Assignment • In fixed-assignment schemes, • each communicating node is assigned a frequency band in FDMA systems or a time slot in TDMA systems. • This assignment is static, however, regardless of whether or not the node has data to transmit. • These schemes may therefore be inefficient if the traffic source is bursty. In the absence of data to be transmitted, the node remains idle, thereby resulting in the allocated bandwidth to be wasted. • Random assignment strategies attempt to address this shortcoming by eliminating preallocation of bandwidth to communicating nodes. • CSMA (Carrier Sense Multiple Access) • CSMA/CD – CSMA with Collision Detection • CSMA/CA – CSMA with Collision Avoidance www.caesar-lab.com

15. MAC Protocol for WSN (1/2) • Balance of requirements • For the case of WSNs, the balance of requirements is different from traditional (wireless) networks. • Additional requirements come up, first and foremost, the need to conserve energy. The importance of energy efficiency for the design of MAC protocols is relatively new and many of the “classical” protocols like CSMA contain no provisions toward this goal. www.caesar-lab.com

16. MAC Protocol for WSN (2/2) • Energy Problems on the MAC layer • Collisions: collisions incur useless receive costs at the destination node, useless transmit costs at the source node, and the prospect to expend further energy upon packet retransmission. • Overhearing : Unicast frames have one source and one destination node. However, the wireless medium is a broadcast medium and all the source’s neighbors that are in receive state hear a packet and drop it when it is not destined to them. • Protocol Overhead : Protocol overhead is induced by MAC-related control frames like, for example, RTS and CTS packets or request packets in demand assignment protocols, and furthermore by per-packet overhead like packet headers and trailers. • Idle Listening : A node being in idle state is ready to receive a packet but is not currently receiving anything. This readiness is costly and useless in case of low network loads; for many radio modems, the idle state still consumes significant energy. www.caesar-lab.com

17. Low duty cycle protocols and wakeup concepts • By choosing a small duty cycle, the transceiver is in sleep mode most of the time, avoiding idle listening and conserving energy. • By choosing a small duty cycle, the traffic directed from neighboring nodes to a given node concentrates on a small time window (the listen period) and in heavy load situations significant competition can occur. • Choosing a long sleep period induces a significant per-hop latency, since a prospective transmitter node has to wait an average of half a sleep period before the receiver can accept packets. In the multihop case, the per-hop latencies add up and create significant end-to-end latencies. • Sleep phases should not be too short lest the start-up costs outweigh the benefits. www.caesar-lab.com

18. Energy Awareness • Low Power Design • Extended Ultra-low Power standby mode • Minimum active duty cycle • Interrupt driven performance on-demand • Low Power Microcontroller • Low Power Consumption Active Mode • Many Low Power Modes • Fast wake-up time www.caesar-lab.com

19. Current Consumption Profile A Simple Glass Breakage Detector Using the MSP430 (SLAA351) www.caesar-lab.com

20. Energy Calculation Example : Smart Roadbeds A Wireless Sensor Network for Smart Roadbeds and Intelligent Transportation Systems http://www.media.mit.edu/resenv/pubs/theses/AraKnaian-Thesis.pdfใ www.caesar-lab.com

21. Energy Calculation • To determine number of ns-A used by a task, multiply its current draw in mA by its duration is milliseconds. • To determine the average current drawn in nA by the system due to a task, multiply the number of ns-A amps used by the task by its frequency is Hz Energy used by node operations www.caesar-lab.com

22. Node Power Consumption Breakdown • The maximum average node current drain is • (11.3mA + 1.5mA + 1.5mA + 2.8mA) = 17.1mA. • The Tadiran TL-4935 lithium thionyl-chloride battery can supply 20mA at 3.6V for 90,000 hours, which is more than 10 years. www.caesar-lab.com