Networking Reference
In-Depth Information
requirements as, for instance, the minimum data accuracy provided by the node, the
maximum delay delivered by the network, the maximum lifetime of the node, among
others. Upon determining which sensor nodes are used to execute the required sens-
ing task, the Manager class is able to know the respective sensor platform(s) to be
used to meet the request. Thus, the request message is forwarded to the respective
Driver class to be translated to the proper data format. After the required sensing
task is performed by the WSN and the required sensing data is collected by the
nodes, the respective Driver class sends to the Manager class the translated reply
messages directly received from the tasked sensor nodes. TheManager then forwards
the message to the Web Interface component so that the results of the HTTP request
are presented/delivered to the user/client application. The other functionality of the
Manager class is to determine the type of communication to be used (synchronous
or asynchronous) in the message exchange between the gateway and the WSN. Such
type is defined from the data delivery model required by the client application.
According to the data delivery model, WSNs can be typically classified in three
types: periodic, event-driven and initiated-by-the-observer (or simply request-reply
model). In the periodic model, sensor nodes sense and send their collected data
continuously, at a predefined rate. In the event-driven model, sensors continuously
sense the monitored environment but report information only if an event of interest
for the application occurs. In the request-reply model, sensor nodes report their data
in response to a synchronous query issued by the application. In this last case, the
application is interested in getting a snapshot of values of themonitored phenomenon.
For event-based applications, asynchronous communication is required, for
instance, based on the Publish-Subscribe model. The current architecture of Smart-
Sensor does not support this model. With suchmodel, a client application registers for
events of interest only once and receives new sensor measurements upon the occur-
rence of an event. The HTTP protocol typically operates in the pull mode, where
clients send a request message whenever they need a resource from a Web server.
HTTP does not natively provide an event notification mechanism (push mode). A
usual way of implementing the push mode would be to repeatedly send an HTTP
request message (for instance containing a conditional GET operation) describing the
event of interest; whenever the event occurs the reply message body will include the
event description; otherwise the message body will be empty. This implementation
based on sending repeated requests makes costly the communication for this type
of data delivery model. To overcome such drawback, a possible solution would be
to modify the original HTTP protocol implementation. One example of such a solu-
tion is the TinyREST protocol [ 5 ], proposed as part of a joint R&D project between
Samsung Advanced Institute of Technology and Fraunhofer FOKUS. TinyREST is
a protocol specific to the TinyOS sensor platform that was built based on the REST
architecture and principles. The TinyREST implementation provides the clients with
the ability to issue HTTP-like messages to accessing MICA [ 3 ] motes in a WSN.
Besides the standard POST and GET HTTP operations, TinyREST includes a SUB-
SCRIBE request message. By issuing a SUBSCRIBE message, clients are able
to register their interest to specific services provided by sensors/actuators, besides
defining personalized parameters depending on the clients needs. Each subscribed
Search MirCeyron ::




Custom Search