create new tag
, view all tags
The link layer is responsible for handling point-to-point connections with the node’s neighbours, as well as providing a means for error-control and medium access control through an ALOHA-inspired implementation with exponential backoff to provide some reliability. It also interfaces to the packet radios through the serial port, and at the same time provides pseudo physical layer capability through symbolisation. It is easily the largest and most complex component of WiSeNeT. As of revision 1.1 (to accommodate the use of Smart Packet Radios), the Link Layer is now made up of two seperate sub-layers, the Logical Link Control Sub-layer and the Convergence Sub-layer. The Logical Link Control Sub-layer handles the intepretation of Network Layer packets into Link Layer frames for transmission, as well as retransmissions and ACKs in the event that a Packet Radio (not a Smart Packet Radio) is used. The Convergence Sub-layer now handles the hardware specific elements of the Link Layer packet; that is the addition or removal of prologues and epilogues, as well as handling any symbolisation which is desired. The separation of the Link Layer into these two Sub-layers allows for greater modularity and decreases the difficulty of interfacing new hardare to the WiSeNeT framework.


Figure 7: Link layer landscape:

There are six main threads to manage the six main queues within the link layer (Figure 7):

  • 1. Link Send manages the N2L_queue from the network layer, and passes the data to the relevant outbound queue based on the proposed packet’s characteristics. The outbound queue then feeds into the L2C_queue.
  • 2. Link Data manages the outbound_data_buffer, and therefore obtains the relevant information, encapsulates a packet, sends it, waits for an ACK, and retries again if no ACK is received.
  • 3. Link Priority manages the outbound_priority_buffer, and therefore obtains the relevant information, encapsulates a packet and sends it without requiring an ACK.
  • 4. Link Receive manages the C2L_queue from the Convergence Sub-layer, processes it and passes the relevant data up to the network layer through the L2N_queue.
  • 5. Convergence Send manages the L2C_queue from the Logical Link Sub-layer, and passes the data to the outbound queue for transmission after modifying the packet for the designated hardware.
  • 6. Convergence Receive monitors the bytes of data arriving on the inbound_buffer, and when a complete packet is detected, decodes it and passes up to the Logical Link Sub-layer through the C2L_queue for further processing
Note that symbolisation is implemented when the packet is sent and when the packet is received at the radio. See below for further explanation on symbolisation.

There are two different types of packets defined at the link layer based on the packet requirements (and hence two different types of buffers):

  • 1. Priority packets – these are currently defined as ACKs, TYPE_ROUTING packets (that is, routing and control packets), broadcast packets and test packets. Due to the nature of these packets, they do not require ACKs to be received, and therefore do not count towards the statistics of the node. There are no retries for priority packets.
  • 2. Data packets – these are defined as any other type of packet that requires an ACK to be received, or in other words, requires the receiver to actually receive them successfully. This necessitates the use of retransmissions to achieve this purpose in an unreliable communications channel. Reliability has been improved by combining these retransmissions with an exponential backoff algorithm. However, as soon as a node reaches a predefined maximum number of retries, the node will drop the packet, and flag it in the log as a failed send. It will then resume transmission with the next packet in the queue. The node does not abort the complete transmission if one packet fails. This obviously will cause issues with file transfers (or other applications which depend on reliable data transfer); however it must be noted that wireless sensor network traffic does not inherently place a high priority on reliable streaming traffic such as file transfer.
A decision was made to split a single outbound buffer (as per the existing testbed) into two outbound buffers in order to tackle the problem where a data packet being resent multiple times can cause priority packets (notably ACKs) to be delayed. The nature of these priority packets necessitate their immediate transmission as soon as they arrive at the relevant outbound buffer, as long as there is nothing currently being written to the radio. The risk of “ACK flooding” (where the number of ACK packets exceeds the number of data packets, therefore clogging up useful traffic in the network) is minimal as there should never be successful transmission of too many packets due to collision leading to backoff at the sender – this means that there won’t be a need to send more ACKs than the receiver can handle. In addition, because two threads are now competing to write to the same resource, a token is defined within the link layer to manage the access to the packet radio. As of revision 1.1, these two queues now feed into a single queue which communicates between the Logical Link Control and Convergence Sub-layers. While this does present a possible bottle-necking issue, this is no different to the possibility that the radio currently has a packet written to it and thus any new packet must wait. Another aspect of packet transmission considered was when the next send should be for data packets (note that priority packet transmissions are immediate and are not constrained by a rate). In essence, there are two ways to calculate the time that the next transmission begins (Figure 8):

  • 1. “True send” in the link layer refers to the use of a timer to determine when then next packet should be sent. This maintains the consistency between transmissions, especially when packet loss (and therefore retries) is involved. That is, transmissions are scheduled at each period T.
  • 2. “Moving send” in the link layer refers to determining the time of the next transmission on an event-driven basis. In other words, the time for the next transmission is period T from the time of the last successful (re)transmission.

Figure 8: Timing of true send vs moving send:

Preliminary analysis and testing have shown that selecting one method over another lead to varied results. Notably, the moving send is able to adapt to packet loss by readjusting its next transmission time accordingly (and somewhat randomly) – in other words, synchronisation causes packet loss. The user is able to switch between the two send methods in this testbed by modifying the TRUE_SHOULD_RUN variable in the global variables.

SEQ number handling is done through the last_seq_num variable. This contains a counter of the number of packets transferred to a neighbouring node, which, when the first bit of that variable is extracted, represents the SEQ to use for the next packet to send to a specific receiver (at a sender), or the SEQ last received from a specific sender (at a receiver). The protocol for sequence numbers is that when a sender sends a packet with a particular SEQ, the receiver will ACK with the value of SEQ incremented by 1 (Figure 9).


Figure 9: SEQ handling

The receiving algorithm at receiver nodes checks that a meaningful number of bytes have arrived in the inbound_buffer before decoding it into the link layer frame components (packet). Then, if the rxnode of the packet is the node’s address, it passes the payload and other relevant information up to the network layer, and ACKs accordingly. Broadcasts are assumed to be from a one-hop-away node, and are passed directly up to the network layer without ACKing. All other packets are discarded. In addition to the basic send/receive structure, several additional components have been programmed into the link layer based on forecasted requirements for congestion control algorithms:

  • The ability for the network layer to change the data transmission rate of the link layer.
  • A child manager, which collects information on all the node’s active children on a periodic basis.
  • Instantaneous send and receive rate capture, which is logged periodically.
Topic revision: r7 - 2012-02-05 - BenjaminFoo
This site is powered by the TWiki collaboration platformCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback