The communication interfaces

The tinyDSM middleware uses radio and serial communication. These are used for different purposes. The radio is the primary communication means and is used for the inter node communication. In contrast, the serial interface is used to connect to and communicate with devices not capable to use the primary channel, like a PC or PDA, allowing these to access the data stored in the network.

The tinyDSM middleware uses the radio interface to exchange its messages between nodes. These messages are extracts of the requests represented by therequest tstructure and contain only the data required to be transmitted. Actually, the content of the message depends on the operation the request represents, but currently, the same format of the packet is defined for all operations. It is defined by theradiodata t structure type presented in Listing4.27. The structure contains all the data required to transfer all the requests possible in the tinyDSM middleware. The fields in the structure contain the same data, as their corresponding fields in the request t structure.

typedef s t r u c t r a d i o d a t a t { u i n t 8 t o p e r a t i o n : 3 ;

u i n t 8 t o p f l a g s : 3 ; v a r i d t v a r i d ; n o d e a d d r t addr ; t s t timestamp ; v a l u e t v a l u e ; e r r o r t r e s u l t ; r e q n o t r e q n o ;

n o d e a d d r t r e q S r c A d d r ; h o p s t hops ;

n o d e n o t noACKS ; n o d e n o t noNACKS ; } r a d i o d a t a t ;

Listing 4.27: Definition of theradiodata t structure type

Having one structure that holds all message types simplifies the handling of the radio packets and unifies the transmission costs for all requests, but is not optimal regarding the amount of data that is transmitted over the medium. In order to limit the size of the data packets to the absolute minimum, an alternativeradiodata t structure like, the one presented in Listing 4.28 can be used. It consists of three parts. The first is the fixed data part consisting of the operation, opflags, reqno and reqSrcAddr fields. These fields are used in all the requests. The second part is thecontentflagsfield that contains flags that indicate the actual content (and the size) of the third part–the byte array containing the data of the required set of fields for the given request. And since the data is put into the byte array one after another and only the required data fields from the originalradiodata t type are used, it is possible to send packets with the most optimum size. Before a packet is sent, the request needs to be analysed, the required fields are inserted into the data field and their corresponding flags are set in thecontentflags field.

This solution allows reducing the amount of sent data, but requires parsing the content of the data array to access the fields of the request stored in it. And, since the data is decomposed into a standard request t structure on reception, it is further possible to

typedef s t r u c t r a d i o d a t a t { u i n t 8 t o p e r a t i o n : 3 ;

u i n t 8 t o p f l a g s : 3 ; r e q n o t r e q n o ;

n o d e a d d r t r e q S r c A d d r ; u i n t 8 t c o n t e n t f l a g s ;

u i n t 8 t d a t a [s i z e o f( v a r i d t ) + s i z e o f( n o d e a d d r t ) + s i z e o f( t s t ) +

s i z e o f( v a l u e t ) + s i z e o f( e r r o r t ) + s i z e o f( h o p s t ) + s i z e o f( n o d e n o t ) + s i z e o f( n o d e n o t ) ] ; } r a d i o d a t a t ;

Listing 4.28: Example definition of an alternative radiodata t structure type

Table 4.5: Message fields required by the tinyDSM requests

Required Request message

fields GET SET UPD ANS SACK UACK ALT FIXED

operation + + + + + + + +

opflags - - O - - - + +

Reqno + + + + + + + +

reqSrcAddr + + + + + + + +

var id + + + - - - O +

Addr O O + O O - O +

timestamp O - + + + - O +

Value - + + + - - O +

Result - - - + + + O +

Hops O O O O O O O +

noACKS - - - O O +

noNACKS - - - O O +

Required: + Not required: -Optional: O

avoid sending fields with value equal to zero.

Measurements were taken, in order to evaluate the advantages and costs of the al-ternativeradiodata t structure, compared to the fixed size version. The different request types require different fields to be transmitted (see Table 4.5). And since none of the requests require the complete set of fields, the size of the transmitted messages can be optimized. TheALT request column represents the fixed and optional fields that can be used in the alternativeradiodata t structure. TheFIXED request column represents the radiodata t with the fixed size, where all the fields are transmitted by default.

As already mentioned, the alternative version of the request t structure was con-structed this way that the data required by all the requests is send in individual fields of

the structure and the optional data is stored in thedatafield with a variable length. This approach requires encoding of the request into aradiodata t structure to be transmitted and decoding in a request from a receivedradiodata tstructure. In case of the fixed size radiodata t structure the encoding and decoding corresponds to the copying ofrequest t fields into the radiodata t structure and vice versa. The final size of the message to be sent and the actual complexity of the encoding and decoding depend on the sizes of the types specified by the current tinyDSM configuration. In order to take the measurements the types were specified as provided in Listing 4.29.

The minimum and maximum size of the message for these defined types on the IHPN-ode hardware platform, are provided in Table4.6, for each kind of request. This range is caused by the fact, that some of the fields are optional in the request, e.g., while issuing a read request, it is possible to specify the desired timestamp of the instance to be read, but it is optional. Additionally, if a field is required but its value is zero then it is not transmitted and is decoded as zero.

The absolute minimum and maximum size of the alternativeradiodata t is given in the ALT column. None of the requests can go below this minimum and it can also be seen that none of them requires the maximum. The fixed sizeradiodata t structure requires always the same amount of data to be sent. Due to the combination of the type sizes the maximum alternative radiodata t is equal to the size of the fixed version, even that it has an additional field–thecontentflags.

typedef u i n t 1 6 t n o d e a d d r t ; typedef u i n t 1 6 t n o d e n o t ; typedef u i n t 3 2 t t s t ; typedef u i n t 3 2 t v a l u e t ; typedef u i n t 8 t v a r i d t ; typedef u i n t 1 6 t r e q n o t ; typedef u i n t 1 6 t t i m e o u t t ; typedef u i n t 8 t h o p s t ; typedef u i n t 8 t b u f s i z e t ; typedef u i n t 8 t e r r o r t ;

Listing 4.29: Example type definitions for the message size related measurements

The measurements show that the size of the fixed size message can be reduced to less than one third, i.e., only 7 bytes compared to 24 bytes. However, this reduction causes higher processing costs. Table4.6 provides also the minimum and maximum number of clock cycles needed for encoding and decoding. Copying the fields fromrequest tstructure to the fixed sizeradiodata t (encoding) requires 178 clock cycles; decoding requires 183 clock cycles. For the alternative radiodata t structure the maximum encoding cost is equal to 474 cycles, which is less than three times of the cost for the fixed size structure.

In case of the maximum decoding cost, for the alternative structure, this ratio is even smaller–it is slightly above two. For the UACK requests, the minimum encoding and decoding costs are even below these for the fixed size structure.

These measurements, combined with the computation and data transmission costs for the IHPNode hardware platform, show that for a real world application the alterna-tive radiodata t structure is the only choice. The additional costs for the encoding and decoding are fully covered by the savings due to the reduction of the message sizes.

Table 4.6: Measured size of request messages and the complexity of request encoding and decoding

Measured Request message

parameter GET SET UPD ANS SACK UACK ALT FIXED Size [Bytes]

minimum 8 12 18 15 11 7 7 24

maximum 15 15 19 19 15 13 24 24

Encoding (request t −>radiodata t) [clock cycles]

minimum 218 299 426 321 240 167 167 178

maximum 393 401 474 471 390 374 633 178

Decoding (radiodata t −>request t) [clock cycles]

minimum 198 261 371 285 222 159 159 183

maximum 348 348 411 412 349 334 546 183

The serial interface is used to allow devices, not able to communicate with the nodes in the radio communication channel, to access the data stored in the network. This interface is a kind of extension to the functional interface provided to the application layer on the node, i.e., it allows issuing requests and receiving replies to these. The device connected to the node constructs the requests using the fields in theserialdata t structure presented in Listing4.30. This structure type is also used to store the replies.

The complete handling of the request happens on the node that plays the role of a gateway. All the requests are sent to the network on behalf of the gateway node. After the request is handled and a reply is available, the reply is provided back to the requester device, using the serial interface.

typedef s t r u c t s e r i a l d a t a t{ u i n t 8 t o p e r a t i o n ;

v a r i d t v a r i d ; n o d e a d d r t addr ; t s t timestamp ; v a l u e t v a l u e ; e r r o r t r e s u l t ; } s e r i a l d a t a t ;

Listing 4.30: The definition of the serialdata t structure type

The serial interface allows partial moving of the application logic to the device con-nected to the gateway node. However, the interface does not provide all the features of the functional interface of the tinyDSM middleware.

Currently, it is only possible to process the requests issued via the serial interface one after another. It is not possible to handle a new request, until the current request is processed and a reply is issued. In order to support parallel processing of requests, the request number should be transmitted back to the device and the number should be included in the reply.

The serial interface is currently a pure pull interface, i.e., it is not possible to receive notifications on event detection via the serial interface. The states of the event variables

can be queried. A push service in the middleware on the gateway node also requires identification of requests to avoid misinterpreting the pushed data on the external device.

It also requires a mechanism to enable and disable the pushing of the data. All these mechanisms are possible extensions to the current tinyDSM implementation.