Mumbai University > Electronics and Telecommunication > Sem8 > Wireless Networks

Marks: 10 M

Year: May 2016

Feasibility of Using TCP or UDP for WSNs:

Following are problems that make either TCP or UDP unsuitable for implementation in WSNs:

• TCP is a connection-oriented protocol. However, in WSNs, the number of sensed data for event-based applications is usually very small. The three-way handshake process required for TCP is a large overhead for such a small volume of data.

• In TCP, segment loss can potentially trigger window-based flow and congestion control. This will reduce the transmission rate unnecessarily when, in fact, packet loss may have occurred as a result of link error and there may be no congestion. This behavior will lead to low throughput, especially under multiple wireless hops, which are prevalent in WSNs.

• TCP uses an end-to-end process for congestion control. Generally, this results in longer response to congestion, and in turn, will result in a large amount of segment loss. The segment loss, in turn, results in energy waste in the retransmission. Furthermore, a long response time to congestion results in low throughput and utilization of wireless channels.

• TCP uses end-to-end ACK and retransmission when necessary. This will result in much lower throughput and longer transmission time when RTT is long, as is the case in most WSNs.

• Sensor nodes may be within a different hop count and RTT from the sink. The TCP operates unfairly in such environments. The sensor nodes near the sink may receive more opportunities to transmit (which results in them depleting their energy sooner). This may also result in a disconnect between more distant nodes and the sink. As a connectionless transport control protocol, UDP is also not suitable for WSNs. Here are some reasons:

• Because of the lack of flow and congestion control mechanisms in UDP, datagram loss can result in congestion. From this point of view, UDP is also not energy efficient for WSNs.

• UDP contains no ACK mechanism; therefore, the lost datagrams can be recovered only by lower or upper layers, including the application layer.

The examples of TCPs can be grouped in one of the four group:

i. Upstream Congestion Control,(CODA, RMST)

ii. Downstream Congestion Control,

iii. Upstream Reliability Guarantee, (ESRT)

iv. Downstream Reliability Guarantee. (PSFQ GARUDA)

Pump Slowly, Fetch Quickly (PSFQ):

• PSFQ distributes data from sink to sensors by pacing data at a relatively slow speed.

• It allowing sensor nodes that experience data loss to recover any missing segments from immediate neighbors.

• This approach belongs to the group downstream reliability guarantee.

• The motivation is to achieve loose delay bounds while minimizing loss recovery by localizing data recovery among immediate neighbors.

• PSFQ consists of three operations: pump, fetch, and report

Working:

• Sink broadcasts a packet to its neighbors every T time units until all the data fragments have been sent out.

• Once a sequence number gap is detected, the sensor node goes into fetch mode and issues a NACK in the reverse path to recover the missing fragment.

• The NACK is not relayed by the neighbor nodes unless the number of times that the NACK is sent, exceeds a predefined threshold.

• Finally, the sink can ask sensors to provide it with the data delivery status information through a simple and scalable hop-by-hop report mechanism.