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

From Projects
Revision as of 19:31, 4 October 2015 by A1627539 (talk | contribs) (Link Layer)
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

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 (Addressing methodologies). If time permits or for future project groups, multicast can be added.

Layers

When it comes to code organization, we employs the 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 hidden- and 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 ALOHA and FAMA-NCS.

  • Pure ALOHA

Pure ALOHA 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 CC430F5137 (Listen-before-talk), the pure ALOHA 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 (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

- Description

- Significance

Packet Format

- Photo/Table of the packet

- Size and limitation of the packet

- Description of each byte in the packet

Deliverable Test Results

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

Typical Program Flow

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