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

From Projects
Revision as of 08:34, 30 September 2015 by A1627539 (talk | contribs) (High Level Implementation)
Jump to: navigation, search

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
    • 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

- Description

- Significance

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

Detailed Design

- Describe the inner working of each layer, include flowcharts and global/important variables

Physical Layer

Link Layer

Network Layer

Development Tools

Hardware

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

Related documentation

Application Development Guide

Main Program Design Guide

Code Convention

Code Explanation

Code walk-through for various layers

Predefined Definitions

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

Usage Scenarios

Migration Advice

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

Reflection and Improvement

Reference