Tags:
create new tag
, view all tags
f5.png

Figure 5: WiSeNet standardised packet structure WiSeNeT employs the use of a new standardised packet structure (Figure 5) in order to maintain consistency throughout the testbed. It is based off the packet format used in the ECE4024 packet radio project, with elements from the TCP packet structure and encapsulation concepts. However that format was deemed inadequate for multi-hop networking. As such, the following updates were made:

  • Clock and byte synchronisations were removed as that is now handled by symbolisation.
  • The frame start character was removed as packet detection is now handled by symbolisation in conjunction with the link layer.
  • Destination address and source address is now rxnode and txnode respectively, and they relate only to next hop addresses.
  • The reserved bits in the control byte are now used by APP.
  • Added a destination and source field to the payload to aid the network layer in facilitating routing and end-to-end communication.
Details of the standardised packet structure are as per Table 2 below.

Layer Name Length Description
Link Rxnode 1 Byte Address of the next hop (receiver)
Link Txnode 1 Byte Address of the current node (sender)
Link ACK 1 Bit Acknowledgement flag
Link SEQ 3 Bits Sequence number
Link TYPE 2 Bits Type indicator
Link APP 2 Bits Application indicator
Link Payload Length 1 Byte Length of the payload
Network Dest 1 Byte (Final) destination of the packet
Network Source 1 Byte (Initial) source of the packet
Application Data Variable Data to be carried by the packet
Link CRC16 (MSB) 1 Byte MSB of the CRC checksum
Link CRC16 (LSB) 1 Byte LSB of the CRC checksum

Table 2: Standardised packet structure details

There are two predefined types of packets: data packets (which are handled at the application layer) and routing packets (which are handled at the network layer). Both share the same standardised packet structure, regardless of the destined layer. Note that both the TYPE and APP fields are 2 bits in length, hence a limit of 16 different TYPE and APP combinations. Each TYPE and APP indicator combination in turn defines what information should be stored in the data field of the packet. These indicators are currently defined within the global variables as per Table 3 below.

TYPE APP Value Description Data Contents
TYPE_DATA   0 To be handled at the application layer  
  APP_PKGEN 0 Packet generator program packets Packet generator message
  APP_CHAT 1 Chat program packets Chat message
  APP_FILE 2 File send program packets File name or contents
TYPE_ROUTING   1 To be handled at the network layer  
  APP_LL_CHANGE 0 Packets to change the link layer speed New speed
  APP_RT_CHANGE 1 Packets to change the routing table New routing table entry
  APP_BS 2 Backpressure signal packets (LVCC) Count of number of packets received

Table 3: TYPE/APP indicator combinations

Further TYPE and APP indicators can be defined within the global variables in order to expand the scope and functionality of the testbed. This should correlate with the different number of packets definitions and functions of each packet.

The 16-bit CRC checksum is calculated on the entire packet including the headers, but without any symbolisation. This checksum is appended to the end of the packet, and transmitted to the receiver. Upon receiving the packet, the receiver then performs its own CRC calculation on the entire packet (excluding the appended CRC bytes), and compares the result to the appended CRC bytes. On a discrepancy, the packet will be discarded as it indicates an error in transmission. This is a commonly utilised mechanism to maintain the reliability of the network.

In terms of encapsulation, the existing testbed did not employ a standardised method to produce packets. It was a convoluted process which relied on many assumptions and inter-layer dependencies. WiSeNeT rectifies this by introducing a TCP-inspired encapsulation scheme which is standardised at every layer, building on the concept of modularity. The relevant components of the packet at each layer are collectively referred to as that layer’s frame. The application layer frame referred to as the data, the network layer frame is the payload, and the link layer frame is the packet. (Figure 6). Upper layer frames are considered as black boxes from a lower layer perspective – the lower layers can only interpret their respective components of the frame (highlighted as shaded components in Figure 6). Conversely, the upper layers cannot process or encapsulate a frame using a lower layer’s standard. Each layer has unique standardised functions in order to process its relevant components of the testbed, as described in Table 2. All frames are of Python type bytearray.

f6.png

Figure 6: WiSeNet encapsulation process

Topic revision: r6 - 2012-02-09 - 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