## 5 Signal Oriented--Event Driven Approach  
We will consider a WBAN as a one-hop star network, built around a Master Node (MN). We use this network topology rather than multi-hop, since idle listening is reduced, and thus the power consumption is lower. The MN uses WUR enabled protocols for intra-BAN communication and some other wireless communication methods for the data transport to the monitoring stations. The MN usually has less power constraints and is equipped with a larger battery. The nodes can be dedicated gateways for the transmission over longer distances, or they can be a PDA/smartphone device which can provide data analysis/DSP, and some basic monitoring as well as acting as a data relay. If the protocol is to be used in medical settings for patient monitoring, or in home based monitoring systems, it should be signal-oriented instead of sensor-oriented. In such cases, the time slots are assigned to physiological signal information, and then to the sensors that can provide them. This is to accommodate possible smart sensors that can extract multiple information from the signals, to provide a complete m-Health system, as summarised in [1]. Each wireless sensor in a WBAN should have a set of services it can provide. During the formation of a WBAN network for a patient, the list of these services for each sensor should be sent to the network coordinator. The network coordinator then assigns the wireless resources to each sensor, specifies then information that sensor needs to provide and the rate at which this information is to be updated. This would vary depending on scenario, and the type of patient monitoring needed. Looking from the TDMA perspective, every time slot has a physiological quantity assigned to it, and the preferred sensor from which this quantity is obtained. For example, if pulse is needed, the MN assigns a time slot for all communications regarding this parameter. Then it sends a wake up signal and a command to the address that is used by the SPO2 sensor, to measure the pulse. If the sensor does not respond, the MN addresses an alternate sensor (such as a DSP enabled ECG), asking for the same value, before eventually concluding that the required signal is unavailable. Also, if streaming of the data is necessary, the MN addresses the sensor, and assigns a number of timeslots, depending on data rate and required latency (generally, it would give the number of time slots required for streaming, and some reserve timeslots). From the sensors perspective, there can be four modes of operation for a sensor:  
1. _Disconnected_--The sensor state after reset. It is in a deep sleep mode, waiting to be assigned to a WBAN. 2. _Stand-by_--The sensor is in a deep sleep mode, but is paired with a MN, waiting for a wake-up signal to change its state, to get assigned to a channel. 3. _Monitoring_--The sensor is in a stand-by mode, but it wakes up once or periodically, with a period assigned by the MN (the measurement period), to send a measured or computed value. Depending on the signal, it might be necessary to switch on the sensor earlier. 4. _Stream_--This might be available for some sensors. The sensor is on, collecting data, packaging the raw samples and sending data to the MN. While the sensor is in a stream mode, data is exchanged frequently, and the sensor is responsive to sudden changes or requests from the MN (since it is online). For the other modes, the sensor will be off most of the time, with infrequent data transmission, waking up only to transmit measured data. In order to be responsive, it must monitor a channel, and keep the communication with some predefined time interval between the beacons. The wake up radio has great potential in these modes of operation. The Master Node can change the state of the sensor, using a wake up packet and a command packet, or alternatively using an ACK packet, if the sensor is active during the time slot. The standby mode is useful when the data only needs to be gathered infrequently by medical staff.