application running on the host uses the wireless device driver to get data from the peripheral devices. Upon the application request, radio control commands are transmitted to the peripheral devices, requesting to collect sensor reading data. Once collected its data, a peripheral device then sends it in a reply radio transmission to the host. The data is received by the wireless device driver and conveyed to the application. It appears that the wireless device driver model is also applicable to the case when a single peripheral device sends data to several hosts in a time-divided fashion. However, multitasking is not supported by the model. The proposed model distinguishes from other sophisticated computer-to-computer models by the fact that it is interrupt-driven, while others are -driven. It also has less exigent hardware requirements and simpler design. According to the wireless device driver design, the communication protocols between the hosts and the peripheral devices are divided into several levels. stacks of protocols, such as Bluetooth and ZigBee ensure secure and reliable data exchange channel. Higher level protocols are responsible for interpreting information from the received peripheral device stream. The study uses a simple byte-based communication protocol for the wireless device driver, based on commands executed between the wireless device driver and its peripheral devices. The format of these commands is shown in . Each command consists of the following four parts (left to right): a header for storing meta-data, a command type that specifies one of the four types in use, command data for holding the raw data of the command, and, finally, a tail with some more meta-data. The outside parts demarcate the commands, keeping them separate from one another. The four command types are as following: Type I command is information command that instructs the peripheral device on what to and how to display. Type II command is a management command. It enables the host to the peripheral device on demand at run-time. Type III command is a configuration command for adjusting timing parameters at run-time. Finally, type IV command is another timing parameters adjustment configuration command that is Bluetooth-specific.
[3] ShihHeng Cheng and ChingYao Huang, “Power Model for Wireless Body Area Network”, IEEE BioCAS 2008 Biomedical Circuits and Systems Conference, 2008. BioCAS 2008, pp. 1-4, November 2008. [4] Le Yan, Lin Zhong and Niraj K. Jha, “Energy Comparison and Optimization of Wireless Body-Area Network Technologies”, In BodyNets '07 Proceedings of the ICST 2nd international conference on Body area networks, June 2007. [5] Sana Ullah, Xizhi An and Kyung Sup Kwak, “Towards Power Efficient MAC Protocol for and On-Body Sensor Networks”, Springer KES-AMSTA Vol. 5559, pp. 335-345, October 2009. [6] Sai An and Gopalan and Jong-Tae Park, “Energy-Efficient MAC Protocols for Wireless Body Area Networks: Survey”, IEEE International Congress on Ultra Modern Telecommunications and Control Systems, pp. 739-744, December 2010. [7] Okundu Omeni, Alan Chi Wai Wong, Alison J. Burdett and Christofer Toumazou, “Energy Efficient Medium Access Protocol for Wireless Medical Body Area Sensor Networks”, IEEE Transactions on Biomedical Circuits and Systems, Vol. 2, pp. 251-259, November 2008. [8] Hang Su and Xi Zhang, “Battery-Dynamics Driven TDMA MAC Protocols for Wireless Body-Area Monitoring Networks in Healthcare Applications”, IEEE Journal on Selected Areas in Communication, Vol. 27, pp. 424-434, May 2009. [9] Stevan Jovica Marinkovic, Emanuel Mihai Popovici, Christian Spagnol, Stephen Faul and William Peter Marnane, “Energy-Efficient Low Duty Cycle MAC Protocol for Wireless Body Area