Design

Designing a Network Protocol

By Anthony Massa, July 09, 2013

When requirements are tight and unforgiving, it's sometimes easier to design your own protocol.

In this article, I look at constructing the communication protocol for a personal area network. The network consists of low-power nodes that capture physiological data from sensors and condition it before sending it to a central node for processing. In this system, each node is connected to different sensors, which collect various physiological data. The collected data depends on where the sensor node is located on the body. Some of the information collected in this system includes electroencephalography (EEG), electrocardiogram (EKG/ECG), and body temperature. Each node retrieves the sensor data at a specific rate, stores the data locally, and then transmits its data to a central processing node (CPN). The CPN has the responsibility of storing the node's data, performing algorithmic processing on it, if necessary, and then transmitting the results to a remote device.

One of the key concerns for the individual sensor nodes is to keep power requirements to an absolute minimum. This requirement decreases the battery size, thereby reducing node size, and it extends the battery life. Having local data storage at the node level ensures integrity of the data if a node is temporarily unable to communicate its data to the CPN.

Standard TCP/IP vs. Proprietary Protocol

One of the first design decisions for our communication protocol was to determine whether an off-the-shelf or open-source, TCP/IP network stack could be used for each node. There are several options available for TCP/IP network stacks that are specifically tailored for embedded systems.

In this design case, the main determining factor in deciding whether to use a TCP/IP stack was the packet overhead. The transmission of data off the node is the most costly operation in terms of power consumption, therefore, it is important to limit the time it takes to send the data as well as the power consumed to send that data. In our network sensor system, optimizing battery life is a key to extending the operational life of the system.

Other design considerations we examined:

How often does the data need to be communicated with the CPN, are there real-time data constraints?

Are there deadlines for the data  does the data need to be received by the CPN at a certain time or else the data is irrelevant?

Does each node need to communicate outside of the closed system? If not, a standard protocol widely supported by external devices is not necessary.

What happens if the communication link for a node is down?

Does the network need the other supported features of a TCP/IP stack, such as fragmentation, ARP, among others?

Is each data unit important, is it catastrophic if a single data sample is lost or is it alright to rely on the latest data sample taken?

Along with data integrity, does the data reception need to be acknowledged by the receiver?

The PHY Layer

In addition to the packet size consideration, the physical layer is a design consideration that can significantly affect the battery life of the individual sensor nodes. In considering the physical layer, our team needed to determine what was best to carry the network traffic, as well as where the sensor nodes needed to be located to route the different packets to the CPN. In this system, the distance the packets had to travel was not very far, a matter of feet at the most. Bluetooth and near field communication (NFC) were considered. NFC operates at a lower rate than Bluetooth, and it consumes less power. NFC also has the advantage of quickly setting up and being able to communicate, whereas Bluetooth requires identification of devices prior to establishing communications. As a result, NFC was chosen for the physical layer.

The Central Processing Node (CPN)

The CPN acts as a data collector, algorithm processor, and the interface to the outside world. The system needs a way to provide near real-time (when the communication link permits) data to an external wireless device. Because of the external communication requirements, the CPN includes the proprietary network stack as well as a TCP/IP network stack. A more widely used wireless communication physical layer is included, which increases the battery requirements for that one central system node. A Bluetooth module is used for external communications. The CPN is a single, more-capable node that is designed with more resources to accommodate larger data storage, processing, and network communication requirements; and it uses a larger battery for supporting those functions.

Personal Area Network (PAN) Design

One key goal was to keep the network to as basic as simple as possible, while still meeting all the requirements for communicating each node's data packets to the CPN. The system needs to support self-configuration, meaning each node needs to join the network and know where to send its packets without user intervention. In the case where each node can communicate directly with the CPN, no routing of packets is necessary.

Building the network protocols using a layered approach, as with the Open Systems Interconnection (OSI) model, allows for the different layers to be replaced when new and better technology becomes available.

As each node joins the network, it needs to know where to send its packets. A registration period could be used in a system where nodes were not able to directly communicate with the CPN. During this registration, a parent-child relationship is established where the child node would register with the parent node and send its packets to the parent in order to get its data to the CPN. The protocol accommodates these types of registration packets if necessary.

Figure 1 shows the construction of the network packet at the different layers of the stack. Each higher layer is encapsulated by the lower layers in the network stack and eventually sent out the physical (PHY) layer. The packet starts with the raw data acquired from the sensor node. In cases where the data is large enough, a compression algorithm is applied to the data to further reduce the data size. On the receive end, the network stack reverses the process, stripping away the packet headers, in order to get back to the original sensor node data.

One popular library is zlib for compression. The trade-off with using a compression algorithm on the sensor node data for transmission is that the algorithm needs to be run for each packet prior to transmission. Running the compression algorithm keeps the node powered longer, but it reduces the transmit power required because less data is transmitted. Experimentation needs to be conducted to determine if the power consumption is best reduced by compressing the packet size or maximizing the processor sleep time.

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.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!