CMP EMBEDDED.COM

Login | Register     Welcome Guest  
HOME DESIGN PRODUCTS COLUMNS E-LEARNING CONFERENCES CODE FORUMS/BLOGS NEWSLETTERS CONTACT FEATURES RSS RSS

Eeny, Meeny, Miney Moe: choosing a low power wireless network protocol - Part 1
Wireless network protocol basics



Embedded.com

Network basics
Figure 2 below shows a block diagram of a typical low power network node. In general there is a sensor (or sensors) collecting data or status and/or providing a user interface to the system. A microcontroller interfaces the sensor and controls the radio (the CC1100 or CC2500 in this particular case) while the radio transmits and receives status.

Figure 2--a typical low power network block diagram, shown for an automatic meter reading application

All networks on which these nodes communicate, wired or wireless, can be conceptually described by what is referred to as the Network Open Systems Interconnect (OSI) Basic Reference Model, depicted in Figure 3 below.

Developed in the late 1970's by the International Organization for Standardization (the ISO), this model separates the components of a network protocol implementation into software layers. For two applications on separate devices to communicate, a message must travel down from the application layer, across the physical layer, and up the other side. Each layer communicates only with the layers above and below it.

Figure 3--Elements of a network

One way to conceptualize a layered software architecture cold be by describing the mailing of a letter by mail. The letter itself can be considered application data. The individual drops it off to be picked up by the mailman in the post-office box so that it may be transported to the post office.

The post office separates all mail according to its destination before shipping it, by sea, air and land to its final destination. For the letter to arrive to the recipient, it must work its way back up the other side, being dropped off at the post office, sorted by destination, transported to the recipient's mailbox, to be interpreted by the reader.

This is a four-tiered communication protocol where the individual writing the letter represents a single layer, the transport to and from the local post office represents the second layer, the post office sorting the mail represents the third layer, and the shipping methodologies represent the fourth.

Each layer concerns itself only with its own task, and communicates only with its adjacent layers. Only by working its way down one side and up the other will the contents of the letter (or application data ) be successfully communicated between individuals.

The OSI model services seven separate layers. An application layer services the direct interface to the user. The presentation layer formats the message to or from a network format, oftentimes implemented as message encryption and/or encoding.

The session layer creates and manages the logical link between any two devices on the network. The transport layer is responsible for providing reliable end-to-end communication. If the transport layer fails too often, perhaps the channel is too noisy or the link is bad, and it should inform the session layer to create a new link between the failing nodes.

The network layer is responsible for network routing mechanisms, leaving the responsibility of message transmission between individual devices to the data link layer. The data link layer assures peer-to-peer delivery of a message, but leaves the actual transmission of messages across the physical medium to be managed by the physical layer. And so, a message is transmit down one side of the OSI model and up the other.

A designer has the option to select protocols that have different numbers of layers implemented, and can choose to customize the remaining layers to his or her application as needed.

Most networking implementations today do not actually implement these layers wholesale, and may mix the functionality of certain layers according to the requirements of the protocols.

In fact, the OSI model is best to consider as a framework for conceptualizing the complexity and functionality of a protocol's architecture The designer should always be aware of what functionality his or her solution implements and which functionality it is consciously leaving out.

1 | 2 | 3 | 4

Rate this article: Low High
Current rating
  • .
Embedded.com Career Center
Looking for a new job?
SEARCH JOBS

Browse all jobs

SPONSOR
RECENT JOB POSTINGS





 :