[ Pobierz całość w formacie PDF ]
.In addition, newhardware developments will lead to new classes of sensors, networking capabilities, and improvedbasic sensor platforms (memory, storage, CPU clock rates, etc.).The following are some issues thatshould be addressed to arrive at a mature, modern OS for wireless sensor nodes in future research.10.1.Support for Real-Time ApplicationsThere are many real-time application areas for WSN, e.g., in industry automation, chemical processmonitoring, and multimedia data processing and transmission.Schedulers have been designed tosupport soft as well as hard real-time operations in some operating systems, but the effort is far fromcomplete.In future, there is a need for scheduling algorithms that can accommodate both soft and hardreal-time requirements of applications.Furthermore, with the emergence of WMSNs, a networkingprotocol stack is required that provides implementation of protocols that support some kind ofdifferentiated services.10.2.Secondary Storage ManagementWith the passage of time, new application areas for WSN are emerging and applications arerequiring more and more memory.A typical databases application requires a secondary storage withsensor nodes.There are only few OSs that provide a file system to manage secondary storage.If weconsider Moore s Law, then in the not-to-distant future we can expect to have powerful sensor nodeswith large secondary storage, therefore more research effort is required to build a scalable (distributed)file system for WSNs.10.3.Virtual Memory SupportA sensor node has very limited RAM and applications are requiring more and more RAM.Therefore, in the future we need to introduce virtual memory concepts in OSs for WSNs.We need todevise virtual memory management techniques that are energy and memory-efficient.10.4.Memory Management and SecurityLittle work has been done on memory management for WSN OSs.The primary reason behind thisis that it has been assumed that only a single application runs on a WSN OS.In many contemporaryOSs, like TinyOS and Contiki, the application program and kernel compiles together, thus sharing thesame address space.This can be harmful, therefore an OS like LiteOS provides separate address spacesfor different applications and the kernel.Such techniques need to mature further to support a multitudeof (concurrent) applications on wireless sensor nodes. Sensors 2011, 11 592710.5.Support for Multiple ApplicationsContemporary OSs for WSNs have been developed with the assumption that only a singleapplication will run on the mote.But with the emergence of new application areas of sensor networksthis base assumption is being questioned.Let us consider the case of WMSN, in which sensor motesare equipped with a voice sensors (microphones), video sensors such as cameras, and scalar sensors.Hence on a single sensor node we may have an application that is using the video sensor, i.e.,recording video, applying some image processing techniques on it and sending the compressed videoto the base station.Similarly, we can have other applications that are making use of voices sensors andscalar sensors.Therefore, OSs need to accommodate multiple applications at the same time.10.6.Robust Communication Protocol StackMany WSN OSs provide a communication API that allows applications to send and receive data.Underneath, these APIs use the communication protocol stack provided by the OS.There is noagreement on a unified protocol stack for sensor networks, hence almost each OS provides its owncustom implementation of a communication protocol stack.As a consequence, no communication canoccur between two motes using different OSs.In the recent past, Contiki has provided animplementation of a micro IPv6 stack for sensor networks.This enables sensors nodes to use IPaddresses and communicate with other IP-enabled devices.Following the Contiki approach, TinyOS inits new version has provided support for IP that conforms to the 6LowPan standard.Providing animplementation of the micro IP protocol stack allows two motes using different OSs to communicate.However, this approach may lack the capabilities to adequately handle multimedia streams.There is a need for research effort that designs and implemenst a suitable cross layer protocol forsensor networks.The protocol design needs to consider constraints on sensor nodes as well as newemerging application areas for sensor networks.10.7.SecurityThe deployment of WSNs in battlefield requires stringent security features, therefore, OSs for WSNshould provide mechanisms so that a user at base station can authenticate valid nodes in the network.Similarly, in case of queries and updates, nodes must be able to authenticate the originator.10.8.Database Management System ImplementationThe task of a sensor node is to sense, perform computations, transmit, and store data.In somesensor networks data is only send to the base station in response to a query, therefore a sensor nodemust be able to store data and understand the query language [ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl przylepto3.keep.pl
.In addition, newhardware developments will lead to new classes of sensors, networking capabilities, and improvedbasic sensor platforms (memory, storage, CPU clock rates, etc.).The following are some issues thatshould be addressed to arrive at a mature, modern OS for wireless sensor nodes in future research.10.1.Support for Real-Time ApplicationsThere are many real-time application areas for WSN, e.g., in industry automation, chemical processmonitoring, and multimedia data processing and transmission.Schedulers have been designed tosupport soft as well as hard real-time operations in some operating systems, but the effort is far fromcomplete.In future, there is a need for scheduling algorithms that can accommodate both soft and hardreal-time requirements of applications.Furthermore, with the emergence of WMSNs, a networkingprotocol stack is required that provides implementation of protocols that support some kind ofdifferentiated services.10.2.Secondary Storage ManagementWith the passage of time, new application areas for WSN are emerging and applications arerequiring more and more memory.A typical databases application requires a secondary storage withsensor nodes.There are only few OSs that provide a file system to manage secondary storage.If weconsider Moore s Law, then in the not-to-distant future we can expect to have powerful sensor nodeswith large secondary storage, therefore more research effort is required to build a scalable (distributed)file system for WSNs.10.3.Virtual Memory SupportA sensor node has very limited RAM and applications are requiring more and more RAM.Therefore, in the future we need to introduce virtual memory concepts in OSs for WSNs.We need todevise virtual memory management techniques that are energy and memory-efficient.10.4.Memory Management and SecurityLittle work has been done on memory management for WSN OSs.The primary reason behind thisis that it has been assumed that only a single application runs on a WSN OS.In many contemporaryOSs, like TinyOS and Contiki, the application program and kernel compiles together, thus sharing thesame address space.This can be harmful, therefore an OS like LiteOS provides separate address spacesfor different applications and the kernel.Such techniques need to mature further to support a multitudeof (concurrent) applications on wireless sensor nodes. Sensors 2011, 11 592710.5.Support for Multiple ApplicationsContemporary OSs for WSNs have been developed with the assumption that only a singleapplication will run on the mote.But with the emergence of new application areas of sensor networksthis base assumption is being questioned.Let us consider the case of WMSN, in which sensor motesare equipped with a voice sensors (microphones), video sensors such as cameras, and scalar sensors.Hence on a single sensor node we may have an application that is using the video sensor, i.e.,recording video, applying some image processing techniques on it and sending the compressed videoto the base station.Similarly, we can have other applications that are making use of voices sensors andscalar sensors.Therefore, OSs need to accommodate multiple applications at the same time.10.6.Robust Communication Protocol StackMany WSN OSs provide a communication API that allows applications to send and receive data.Underneath, these APIs use the communication protocol stack provided by the OS.There is noagreement on a unified protocol stack for sensor networks, hence almost each OS provides its owncustom implementation of a communication protocol stack.As a consequence, no communication canoccur between two motes using different OSs.In the recent past, Contiki has provided animplementation of a micro IPv6 stack for sensor networks.This enables sensors nodes to use IPaddresses and communicate with other IP-enabled devices.Following the Contiki approach, TinyOS inits new version has provided support for IP that conforms to the 6LowPan standard.Providing animplementation of the micro IP protocol stack allows two motes using different OSs to communicate.However, this approach may lack the capabilities to adequately handle multimedia streams.There is a need for research effort that designs and implemenst a suitable cross layer protocol forsensor networks.The protocol design needs to consider constraints on sensor nodes as well as newemerging application areas for sensor networks.10.7.SecurityThe deployment of WSNs in battlefield requires stringent security features, therefore, OSs for WSNshould provide mechanisms so that a user at base station can authenticate valid nodes in the network.Similarly, in case of queries and updates, nodes must be able to authenticate the originator.10.8.Database Management System ImplementationThe task of a sensor node is to sense, perform computations, transmit, and store data.In somesensor networks data is only send to the base station in response to a query, therefore a sensor nodemust be able to store data and understand the query language [ Pobierz całość w formacie PDF ]