View source for Projects:2015s1-40 Flexible ad-hoc Network A: Physical Layer


== Introduction ==

=== Overview ===

==== Project Team ====

Cong Nguyen

Duncan Lawry

==== Supervisors ====

Michael Liebelt

Braden Phillips

=== Significance ===

Ad-hoc wireless networks are self-configurable networks with high node mobility, allowing them to function without reliance on any fixed infrastructure. This makes wireless ad-hoc networks useful for quick communication channel deployment suitable for all applications.

While there are already many existing commercial solutions with ad-hoc capability such as [http://www.zigbee.org/ ZigBee], [https://developer.bluetooth.org/TechnologyOverview/Pages/PAN.aspx Bluetooth Personal Area Network (PAN)] and Wi-Fi based ad-hoc configurations ([http://windows.microsoft.com/en-au/windows/set-computer-to-computer-adhoc-network Windows], [https://support.apple.com/kb/PH13796?locale=en_US MacOS], [https://wiki.debian.org/WiFi/AdHoc Linux (Debian)]) these solutions are generally costly in terms of processing power, memory requirement due to reliance on existing protocol stack or costly in terms of royalty. Furthermore, they are commonly reliant on the ISM 2.4GHz band, making them unsuitable for high-range applications without having to invest on a larger antenna which can increase power requirement and a product's physical size. 

This project aims to develop an ad-hoc network stack with low processing power and low memory requirement by developing customized protocol layers operating in ISM sub-1GHz frequency for long communication distance and free usage, while provide high reliability and robustness. 

=== Objectives and Deliverables ===

This project involves the development of the hardware abstraction layer (HAL), physical layer, link layer and network layer of a wireless ad-hoc network. In usage, data can be provided to the protocols via systems attaching to the protocol stacks or through an application on the microcontroller running the network stack itself.

At the end of this project, the developed ad-network will be flexible in configuration, providing reliable and modest data transfer rate over 100 metres. This means:

1. The network will be self-configuring, independent of external networking infrastructure

2. The network must scale efficiently from 2 to 50 or more nodes

3. The network must work well in both dense and sparse clusters

4. Packet delay should be as low as possible

5. There must be error-checking on multiple levels at the node

6. Node antennas must have a range of over 100 metres.

7. The network must support unicast and if time permits, multicast operation.

8. Each node should consume as little power as possible

== High Level Overview ==

=== Background ===

'''Ad-hoc Topology'''

An ad-hoc network can be classified into various classifications based on the communication type, topology and node configurations. Depending on the communication type, a network can be classified as single-hop or multi-hop ad-hoc network. In a single-hop network, all nodes are in range of each other and can communicate directly. In a multi-hop network, not all nodes are in reach of each others and need to communicate via a node in between - thus hops. 

An ad-hoc network can also be classified by topology. The two major classifications are flat and hierarchical. In a flat ad-hoc nework, all nodes carry the same responsibilities. This means there are no admin nodes and that each nodes performs the same functionality. On the contrary, hierarchical ad-hoc networks consist of clusters of nodes representing individual networks but are all linked together.  In a hierarchical network, master nodes exists and area responsible for passing data between clusters.

Lastly, an ad-hoc network can be classified based on its node configuration: homogeneous or heterogeneous. In homogeneous newtorks, all nodes have the same hardware and characteristics (processor, memory, peripheral devices, etc.). Wireless sensor network is a typical example of a homogeneous network. In a heterogeneous network, nodes differ in hardware configurations and thus cannot provide the same services.

This project is focused on implementing a flat, multi-hop and homogeneous network.

'''Addressing schemes'''

The focus of this project is to provide a robust and reliable unicast and broadcast routing ([https://en.wikipedia.org/wiki/Unicast#Addressing_methodologies Addressing methodologies]). If time permits or for future project groups, multicast can be added.

=== Layers ===

When it comes to code organization, we employs the [https://en.wikipedia.org/wiki/OSI_model OSI model]. In this project, the lower three layers are implemented: physical layer, link layer and network layer. 

While implementing individual layers may lead to increased memory use due to duplicated buffers on various layers, it was chosen to specifically not to use cross-layer implementation as we wanted to:

* Use abstraction to simplify the development process
* Allow higher layers to be ported to other platforms as technology improves
* Allow lower layers to be used easily without higher layers as to customized to use in smaller microcontrollers, projects that does not require extra complexity of higher layers, etc.

====Hardware Abstraction Layer====

The hardware abstraction layer (HAL) implements functions that set up the MSP430 core hardware such as clocks, GPIO, UART, etc. This layer allows higher layers in the stack to have access to the hardware through a simple and portable abstraction API regardless of the underlying hardware. By default, the HAL initializes the MSP430 modules to the following settings:

* GPIO - All pins defaults to outputs with an output value of 0, with the exception of:
** P1.0: red LED on-board
** P1.1: input button with internal pull-up resistor (active low)
** P1.5, P1.6: UART Tx and Rx
** P5.0, P5.1: low-frequency watch crystal ACLK source

* Clocks
** MCLK: 25 MHz
** SMCLK: 25 MHz
** ACLK: 32768 Hz (external watch crystal frequency)

* UART
** Baud: 115200 (configurable with predefined symbols, ranging from 115200 to 921600)
** Data: 8 bits
** Parity: none
** Stop: 1 bit
** Flow control: none
** Hardware Rx interrupt disabled by default

* Timers
** Timer0_A0 is reserved for Link Layer operation

The HAL layer also includes ''fputs()'' and ''fputc()'' functions that overrides default ''stdio.h'' functions, allowing developers to use ''printf()'' seamlessly through UART in their applications.

====Physical Layer====

The Physical Layer deals with the physical connectivity between nodes. It set up the CC430 RF module's configuration registers, PA table, node address, as well as include some abstraction functions used in transmitting and enabling/disabling various settings of the RF module.

Various RF configurations are included with Olimex's examples that could be used readily with the physical layer implemented, allowing the physical layer's transfer rate to vary between 38.4k baud and 250k baud, as well as being able to transmit with output power settings from -30dBm to +8dBm.

These settings are configurable using predefined symbols.

====Link Layer====

With the wireless medium being tightly controlled, most wireless ad-hoc network applications operates in the ISM band, which is free from licensing. This means that there is limited channel bandwidth, much less than that of a wired network. Additionally, being wireless, there are many factors that can degrade the quality of the signal, such as noise and interference from other sources.

The Link Layer, sometimes referred to as a MAC layer, involves the functions and procedures to transfer data between two or more nodes in-range of the network. Its primary responsibility is to ensure that data is correct before the user application has access to them and discard incorrect data as it receives. 

Furthermore, for data transmission utilizing multi-hop, a link layer must also facilitates safe-guards against [https://en.wikipedia.org/wiki/Hidden_node_problem hidden-] and [https://en.wikipedia.org/wiki/Exposed_node_problem exposed-] terminal problems.

Link Layer protocols commonly used in embedded systems belongs to the ''contention-based'' classification. This means that they are aware of the risks of collisions of transmitted data, while ''contention-free'' protocols commonly used in mobile phone networks, are more applicable to static networks with centralized control.

Utilizing a single channel with limited hardware processing power and aimed to be low power, two implementations of the link layer exists in the project: pure CSMA and FAMA-NCS.

* '''CSMA'''

CSMA protocol is classified as a contention-based protocol categorized in the ''random-access'' scheme. In this protocol, a node may transmit as soon as it is ready. It is suitable for low-load systems with a large number of potential senders. 

As the CC430 chip used supporting Automatic Clear Channel Assessment on-chip [http://www.ti.com/product/cc430f5137 CC430F5137] (Listen-before-talk), the pure CSMA implementation is basically the physical layer implementation with extra address checking and buffers, ensuring that it conforms with the Link Layer interface.

* '''FAMA-NCS'''

FAMA-NCS stands for ''Floor Acquisition Multiple Access'' with ''Non-persistent carrier sensing'' ([http://link.springer.com/article/10.1023%2FA%3A1019146831447 Specification]), where ''floor'' stands for ''channel''. It is a MACA-based scheme that makes announcements before it sends data to inform other nodes to be silent. Unlike MACA protocols, FAMA protocols require collision avoidance to be performed at both the sender and receiver nodes. 

To acquire the floor (channel), the sending node sends out a ''Request-to-Send (RTS)''. The receiver responds with a ''Clear-to-Send (CTS)'' back to the transmitter. Any nodes overhearing this CTS packet knows the station has acquired the floor. CTS packets are repeated long enough for the benefit of any hidden sender did not register another node's RTS.

With CC430 chip including Automatic Clear Channel Assessment that uses carrier sensing, it is arbitrary that the non-persistent carrier sensing should be used.

====Network Layer====

We investigated numerous routing protocols in the research phase of the project. We were surprised at how much bandwidth use was required by some protocols just to find a route and began to worry about that these kinds of requests may not be suitable for our low power network. The three-way handshake implemented in the Link Layer meant that we would not be able to flood the network to look for routes every time.

The Zone Routing Protocol (ZRP) was chosen because it would be simple to debug and test with our limited hardware and would maintain the flexibility of reactive routing protocols by including the option to specify longer multi hop routes. The ZRP works by localizing network administration traffic into 'zones'. A node's zone is every node within a certain hop count. For our project the hop count is 1. Every node in direct radio range (1 hop) has its RSSI recorded into a routing table so that route for this node is known. This create a low packet delay time in between nodes in the zone. For nodes outside of the zone, a route must be discovered on request. Route discovery for multi-hop paths is done with the Dynamic Source Routing (DSR). The DSR will flood the network with search requests until a complete multi hop path is found. The routing information is the returned to the requester and the packet can be sent on a multi-hop path.

=== Packet Format ===

[[File:Packet_Format.png]]

== Results ==

'''Maximum stable transfer speed''' 

* Physical Layer: 215 packets/second
* CSMA-based Link Layer: 169 packets/second
* FAMA-based Link Layer: 22 packets/second

== Development Tools ==

=== Hardware ===

* CC430 development boards from Olimex were used as development targets throughout this project ([http://au.element14.com/olimex/msp430-ccrf/cc430f5137-transceiver-dev-board/dp/2061336 MSP430-CCRF])
* Various MSP430 LaunchPads were utilized as debugger and programmer, including:
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430g2.html#tabs MSP430G2553 LaunchPad]: hardware not recognized in Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430fr4133.html#tabs MSP430FR4133 LaunchPad]: added feature of power measurement, compatible with both Windows and Mac OS.
** [http://www.ti.com/ww/en/launchpad/launchpads-msp430-msp-exp430f5529lp.html#tabs MSP430F5529 LaunchPad]: compatible with both Windows and Mac OS.

=== Software ===

==== Code Composer Studio ====

* Version: 6.1.1
* Compiler version: 4.4.4

==== SmartRF Studio ====

* Used in RX/TX dBM measurement and RF configuration register generation
* Provide a quick description of how to use this tool for readers