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 ZigBee, Bluetooth Personal Area Network (PAN) and Wi-Fi based ad-hoc configurations (Windows, MacOS, 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

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.

Layers

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

- Description

- Significance

Network Layer

- Description

- Significance

Packet Format

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

Development Tools

Software

Code Composer Studio

- TI Compiler version

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

Application Development Guide

Code Explanation

Code walk-through for various layers

Predefined Definitions

What they are for, why they exist, when to use them

Migration Advice

- How to port code from this project to other MCU architectures