Channels ▼


Designing a Network Protocol

Each node spends most of its time in a low-power or sleep mode until it is time to read its sensor data and transmit it to the CPN. This leads to the problem of data collisions. If each node were to attempt to send its data at the same time, the CPN would be unable to receive each node's data. There are several options for solving this problem. The solution I used is to have schedules for each node to send data. In order to have transmission schedules, each node must be synchronized to a central time base.

Figure 2 shows the packet header for the personal area network. Some of the fields in the packet header can be eliminated to reduce the header length if certain functionality is not needed in the network architecture. The length of the various fields can also be extended or reduced based on the overall system requirements. For example, Figure 2 uses an 8-bit field used for the Source and Destination Address fields. This limits the number of nodes to a maximum of 256 (assuming no broadcast address or other reserved addresses). If this supports the future expandability of your network, the 8-bit address field is sufficient. If not, the fields can easily be extended.

network packet construction
Figure 2: Network packet header.

The first field is the Length field, which provides the overall length of the entire packet starting with the Source Address and ending with the Checksum. Next is the Source Address field, which identifies where the data originated followed by the Destination Address. If each node communicates directly with the CPN, it is possible to eliminate the destination field. The destination field is needed if a child node is in the network and sends its data to its parent node for forwarding onto the CPN.

The next field is the Packet Type, which identifies the type of data carried. Next, is the Packet ID, which could be a count to let the destination (CPN) know when a packet has been dropped. The Packet ID could also be used as a time stamp of when the data was originally sent.

The Acknowledgement ID field provides a way for the CPN to notify a node that its data has been received successfully. The Acknowledgement ID contains the original Packet ID to let the sensor node know what data was successfully received. If acknowledging the data is not required, the Acknowledgement ID can be eliminated and the sensor node will simply make a best effort to send its sensor data to the CPN. If the CPN fails to receive the node's data, it waits until the next transmission period. The advantage of this system is that each node is storing its sensor data locally. Therefore, no data is lost and can be eventually retrieved once the node data are downloaded at a later time.

Next comes the Data Payload, which has a length determined as described earlier: it's based on the sensor data and dependent on whether compression is used. Finally, a checksum field is used to ensure the data is received correctly by the CPN. A cyclic redundancy check (CRC) algorithm can be used to provide this functionality.

One area of concern lately that was not discussed is security. For a closed system like this it may not seem security is a major concern, however, it should be considered if the data is sensitive or unauthorized access could wreak havoc on the system. Data encryption could be one method to secure the data within the network.


In this article, I discussed many of the key design considerations when constructing a personal area communication protocol network. I demonstrated a basic network architecture that could be used as a starting point for a simplified personal area network. There are many considerations as described above when developing a network architecture, even as rudimentary as the one presented here.

Anthony Massa is director of software at Nexis Labs where has developed embedded systems for several products such as wireless network radios, satellite and cable modems, set-top boxes, and many other devices currently used today. He has written two books: Programming Embedded Systems: with C and GNU Development Tools (O'Reilly) and Embedded Software Development with eCos (Prentice Hall PTR).

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.