TinyOS component diagram

Some components required by PoRAP have been stated in the previous section. This section aims to describe the TinyOS components which are used in PoRAP. A brief introduction of TinyOS component is also given.

A) Overview of TinyOS components and notation

TinyOS is an operating system which is specifically developed for embedded systems such as wireless sensor networks (WSNs). It is written by the nesC programming language which is a C dialect. TinyOS also provides a programming environment so that new protocols or applications can be developed by adopting and modifying several existing components. The protocol consists of several components which are assembled or wired together. In each component, the names of interfaces along with their implementations are defined.

A nesC component provides and uses an interface. Provided interfaces represent the functionalities of the component and they can be used by the other components. Interfaces are bidirectional. They specify a set of commands which are implemented by those components which provide them. Interfaces also specify a set of events which are implemented by those components which use them. If a component requires to call a command in an interface, this component has to implement the events of that interface. A component may provide or use multiple interfaces or the instances of the same interface.

There are two types of components in nesC which include modules and configurations. Implementations of interfaces are described in the modules. Configurations are used to assemble the components together by means of wiring, which is the mechanism of connecting the interfaces used by a component to the interfaces provided by other components. Every nesC application is described by a top-level configuration where all wirings between the components are included.

Standard notations are provided by the TinyOS community. A single box represents a self- developed module. In PoRAP, SourceC and BaseP are respectively modules of the source and

base station. One of the key interfaces used by the source is CC2420Packet which provides transmission power adaptation. The same interface is also used by the base station for RSSI measurement. A double box represents the configuration, or component, which is generally required by all nesC applications. For example, the MainC is always required as it enables boot processes. A double box with dashed border line indicates that the component is generic. For example, the sources require two instances of a timer component for timing the waiting and sleeping intervals. Wiring between components is indicated by a line with arrow. The arrow head is pointing to the component which provides the interfaces.

B) Structure of source’s components

The structure of a source’s components is depicted in Figure 5.13.

Figure 5.13: TinyOS component diagram for a source

According to Figure 5.13, the source module is represented by SourceC. It uses several interfaces provided from eight components. The interactions between SourceC and these

components are represented by wiring processes which are described as followed:

1. MainC: This component is general and is required in all modules. It provides the Boot interface which is used for booting the module for operation.

2. ActiveMessageC: The message structure in TinyOS 2.x is named “Active Message”. This structure is general so that the sensors can understand each other. This component provides a key interface called “SplitControl” which is useful for starting and

138

stopping the hardware such as the radio. In PoRAP, an instance, RadioControl, can be created to control the CC2420 radio. To start and stop the radio, the start() and stop() commands can be used by respectively calling RadioControl.start() and RadioControl.stop().

3. CC2420TransmitC: Two important interfaces are provided by this interface. The CC2420Transmit enables the modification to the payload especially when the SFD of the packet is transmitted. This feature is crucial when the content is not known until the message has been forwarded to the MAC layer. The other interface is RadioTimeStamping which is used for obtaining the specific time of data transmission and reception at the MAC layer. This is important in the schedule-based protocol as time synchronisation refers to those timestamps at the MAC layer.

4. CC2420ActiveMessageC: This component is important to PoRAP as it provides the CC2420Packet interface which enables the transmission power setting by calling CC2420Packet.setPower(&data_message, power). The setPower() command accepts two arguments; the address of the data message and the required power level. Moreover, the current transmission power level can be obtained by calling the CC2420Packet.getpower(&data_message).

5. AMSenderC: This component is generic and an instance called “AMSenderDataC” is created to facilitate data transmission. Two important interfaces are used by SourceC. Firstly, the Packet interface is used for obtaining the payload part from the whole packet. This is useful for modifying the content in the payload without unintentionally accessing or amending the header and footer parts of the packet. Secondly, the AMSend is required for message sending by calling the AMSend.send(). The source can check if the packet is already transmitted and some processes can be initiated by signaling the AMSend.sendDone() event. For example, the radio is stopped after the whole packet is sent.

6. AMReceiverC: Like AMSenderC, this component is generic. Its instance, AMReceiverCtrlC, is created to facilitate data reception in PoRAP. The Receive interface is used and several processes are performed when the Receive.receive() is signaled. Firstly, the Packet interface is used to extract the control payload as the source has to synchronise with the base station and adjust its current transmission power. After the whole control packet has been received, the radio is stopped.

7. Alarm32khz32C: is used for timing the waiting and sleeping intervals. Its commands take and return an unsigned 32-bit integer. Two alarm components are thus required. The returned values from the Alarm component must be used for calculating waiting and sleeping intervals. The 32-bit Alarm must be converted to Timer for such calculations. Another component, AlarmToTimerC, is required.

8. AlarmToTimerC: Two instances of this component, WaitTimer and SleepTimer, are created for the source. They are respectively used for timing the waiting and sleeping intervals. The MoteWaitTimer is an interface of the WaitTimer and the MoteSleepTimer is an interface of SleepTimer. The WaitTimer interface is started by calling MoteWaitTimer.fired() command. It is called after the source has received the control packet whereas the SleepTimer is called after the data packet has been sent.

C) Structure of the base station’s components

The structure of the source’s components is depicted in Figure 5.14. The base station module, BaseP, can be considered as an enhancement of the BaseStation application in the TinyOS 2.x. The BaseStation is a basic TinyOS utility application. It acts as a bridge between the serial port and the radio network. It is developed to forward the data received by the radio to the serial port and then show it on the computer screen. Additional work has been conducted to manage the buffer of the radio unit.

Several enhancements are made to the BaseStation as follows:

 The base station can broadcast its control packet to the fixed set of sources which are located within its communication range.

 The base station is able to measure the Received Signal Strength Indicator (RSSI) during data reception.

 The base station compares the observed RSSI to the bounds and sets the notification bits in order to signal the transmission power adaptation to the source.

 The base station is able to schedule the control packet broadcast to maintain time synchronisation between itself and the sources.

140

Figure 5.14: TinyOS component diagram for the base station

According to Figure 5.14, more components are required by the base station compared to Figure 5.13. The main reason is that some components including LedsC and Radio as an instance of the ActiveMessageC and SerialActiveMessageC are already included in the BaseStation. The Leds is used for debugging the application operation. The Radio is required for controlling the radio especially when it has to communicate with the serial port. The received data is forwarded from the radio to the serial port via uart. The SerialActiveMessageC is used for controlling the uart.

In order to achieve the enhancements stated previously, additional components are required except for the notification bit settings as follows:

1. AMSenderC: An instance of this component called “AMSenderCtrlC” is created to facilitate control packet transmission. Two important interfaces are used by BaseP. Firstly, the Packet interface is used for obtaining the payload part from the control packet for message modifications. Secondly, the AMSend is required for message sending by calling the AMSend.send(). Note that the AMPacket is currently used by the traditional BaseStation application.

2. CC2420ActiveMessageC: This component is important to PoRAP as it provides the CC2420Packet interface which enables RSSI measurement by calling CC2420Packet.getRssi(msg). The getRssi() command accepts an argument

which is the message being received. Note that the transmission power can be set by this interface. In PoRAP, the base station always initially broadcasts its packet at the maximum power level.

3. Alarm32khz32C: is used for timing the control packet broadcast. An alarm component is thus required. The explanations given in the previous part for the source apply to the base station.

4. AlarmToTimerC: An instance of this component, BcastTimer, is created for the base station. The fired() command is called after the control packet is sent.

In summary, several TinyOS components are used in PoRAP. The main components are those which provide transmission power setting, RSSI measurements, scheduling, modification to payload, sending and transmitting. Several instances can be created from a generic component such as an alarm or timer. The source radio is started and stopped by two instances of the SplitControl interface. The base station module is an enhancement of the existing BaseStation utility application in TinyOS 2.x. The main enhancements include data transmission, RSSI measurements and scheduling.