Networking Reference
In-Depth Information
￿
SensorC : this component is deployed in each sensor node to implement the com-
munication based on the interfaces provided by HttpP.
￿
HttpP : this component implements the HTTP protocol API, providing RESTful
interfaces for communication with the gateway node (and also between the sensor
nodes themselves).
￿
DiscoveryP : this is the component responsible for the (internal) publication and
discovery of the capabilities of sensor nodes.
In addition to the components of the sensor node, a component is necessary to
connect the WSN (based on TinyOS/nesC) to the gateway (in Java). This component
is baseC, implemented in nesC, and responsible for making the connection with the
Gateway Web Server through a serial communication interface.
4.2.3.3 Operation
As previously mentioned, a WSN integrated to the WoT works according to three
phases: (i) internal and external service discovery, (ii) submission of sensing tasks,
(iii) data collection and delivery. Except for the external discovery phase, which
is totally the responsibility of the gateway, the other phases are implemented by
the sensor node components previously described. During the internal service dis-
covery phase an HTTP PUT message is used to advertise the sensing capabili-
ties of each node to the gateway, thus respecting the RESTful principles to main-
tain a uniform interface for accessing all data (and metadata) from the connected
sensors.
Phases (ii) and (iii) of the network operation are illustrated in the UML activ-
ity diagram of Fig. 4.6 . In the diagram, the Client swimming lane represents the
client side of an HTTP-based interaction with a Web Server. The Gateway Web
Server remains listening in a well-known port and waiting to receive a request from
client applications, which may be requests for changing some parameters of the sen-
sor (PUT operation) or requests for some monitoring data collected by the sensor
(GET operation). In both cases, the received request messages are sent for analysis
and subsequent forwarding to the destination sensor node(s). Upon arriving at the
gateway, the request message header is analysed, and the following cases are pos-
sible: if the message is addressed to the sink node itself, it examines if it is either
a Get or Put message; otherwise, the error message 405 is returned to the client.
If the message is addressed to the client, it is not forwarded to the WSN, being
processed within the gateway. If the message is directed neither to the client nor to
the Sink node, a 404 error message is returned to the client. Otherwise, the message
is redirected to the specified sensor, group of sensors or broadcasted in the whole
network.
Upon the arrival of a message in a sensor node, the message header is analysed,
and the following options are possible: if the message is addressed to the sensor
itself, it checks whether it is a Get or Put message, if is not either type a 405 error
Search MirCeyron ::




Custom Search