Note: This series of articles is translated from the classic papers of Adam Dunkels, the father of Contiki, and the copyright belongs to the original author.
Contiki is a system developed by Adam Dunkels and his team. Studying his paper is the best source for a deep understanding of the Contiki system.
Contiki Classic Papers Translation - Index Folder
Summary
With the diversified development of sensor networks, more and more link layer, MAC layer protocols and potential transmission mechanisms are produced.
System developers must make their applications and systems adaptable to a wide range of potential protocols and mechanisms. However, because existing sensor communication architectures were not designed with this diversity in mind, system developers must develop their systems again for each potential protocol and mechanism. To remedy such a situation, we propose a communication architecture. The architecture can be applied to potential communication mechanisms widely existing from the MAC layer to the transport layer without changing any application and protocol.
The architecture is expressive enough to fit typical sensor network protocols.
Proven by testing, relative to non-adaptive architectures. The execution time of this architecture has only increased a little.
1 Introduction
With the development of the diversity of sensor networks, the protocol operation of sensor networks is greatly challenged. For example. Assuming an application executes on a multi-link layer technology, the application and the protocol cannot rely on the relevant link layer mechanisms that already exist - such as link layer retransmission.
This makes us have to think again about the communication architecture of the sensor network.
In terms of interoperability and code reuse. A general sensor network architecture can bring many benefits.
The sensor network community has recently registered several different sensor network architectures, such as the SP architecture by Polastre et al. The modular network architecture of Cheng et al. only. Neither the SP nor the modular network architecture can adaptively execute the protocols on top of the architecture.
The SP does not specify any protocol headers. It is therefore possible to adapt the underlying protocol. But it is precisely because the protocol header is not specified that the SP also has problems when the network protocol is adaptive. The modular architecture of Cheng et al. is divided into several modules according to the functions of the network layer, and each module defines its own module header. Assuming that to join additional protocols, the application must clearly define module boundaries and specify package subheaders.
in this paper. We present a communication architecture for sensor networks - Chameleon.
The Chameleon architecture consists of two parts: the Rime communication protocol stack and a series of packet transmission modules. The Chameleon architecture is not only adaptable to existing typical sensor network protocols, but also adaptive to a large number of potential protocols and mechanisms.
The biggest problem in designing a communication architecture with interoperability is finding a common header format.
Such a header format must satisfy two conditions at the same time: be expressive enough for the communication modes supported by the architecture. Sufficient flexibility for future architectural expansion. For a sensor network architecture. This problem is more challenging because the header must be kept small enough.
To find such a generic header, Chameleon takes a radically different approach: Chameleon doesn't define any headers at all, and instead uses header properties—an abstraction of the information in the packet header.
There is a separate header conversion module in Chameleon, which is responsible for converting application data and packet attributes into packet headers, thus being able to form a complete packet with header and payload.
By using different chameleon modules, it is possible to create a packet that obeys whatever the given header says.
There are 3 different protocols in the network in Figure 1: A low power radio, such as the CC1100. A medium power 802.15.4 radio, and TCP/IP in the Internet. This network uses three chameleon models: one responsible for generating link layer packets for low-power radios, one responsible for generating 802.15.4 MAC layer packets, and one responsible for generating UDP/IP transport layer packets. Unlike other communication architectures. Applications running on the Chameleon architecture do not need to be modified according to different communication mechanisms.
However, header conversion alone is not enough to mimic the operation of these protocols.
In some cases, the chameleon conversion module must implement part of the protocol logic of the protocol it emulates.
For example. The chameleon conversion module responsible for generating UDP/IP packets must implement the ARP protocol to solve the problem of converting IP addresses to Internet MAC addresses.
The second part of the Chameleon Architecture is the Rime Communication Architecture. Rime provides a series of basic communication elements (ranging from the best single-hop broadcast and the best one-hop unicast, to the best network flood and hop-by-hop reliable multi-hop unicast). We have chosen the Rime element based on the communication needs of a typical sensor network protocol.
We have implemented the Chameleon architecture in Contiki OS and evaluated it on Tmote Sky motes.
We have three contributions in this paper. First, by separating the protocol logic from the specific header information. It provides a solution to the cross-layer processing problem in the layered communication stack. We demonstrate the use of package attributes for alternative headers, which allow applications to access underlying information without violating the principle of layering, and whose execution time performance meets the criteria of traditional header-based implementations. second. We present a lightweight layered communication architecture for sensor networks, the Rime protocol stack, which reduces the complexity of implementing network protocols. We show the mapping of communication elements in the protocol stack to typical sensor networks: data dissemination, data collection, and mesh routing protocols. third. We demonstrate the use of packets, which makes it possible to adapt between this protocol stack and other communication stacks (link layer, MAC layer protocols and TCP/IP).
The remainder of this paper is organized, for example, as follows: Chapter 2 introduces the background of the communication architecture, Chapter 3 introduces the top-level design of the Chameleon architecture, Chapter 4 introduces the Rime protocol stack, and Chapter 5 introduces the Chameleon packet conversion module. Chapter 6 describes the implementation of the architecture, Chapter 7 introduces a series of implemented sensor network protocols, Chapter 8 introduces the Chameleon module, and Chapter 9 evaluates the architecture. Chapter 10 recalls related work. Chapter 11 concludes.
2 Background
An adaptive communication architecture for a sensor network must support both the typical sensor network protocols implemented on top of the communication architecture, as well as the MAC layer and link layer protocols where the architecture resides.
In this section, we will recall the issues of the communication stack under the top-level architecture, the requirements of the sensor network protocol. Requirements regarding potential MAC layer, link layer protocols and standards.
2.1 The Narrow Waist
ps: I don't understand what this section is talking about at all, I will add it in the future
The initial challenge of designing a network architecture is where to put the narrow waist of the architecture and where to put the fixed points around other network architectures. Narrow waists need to agree to different protocols to execute on top of it, and to agree to different technologies to execute under it.
In the former sensor network communication architecture. Put the waist of the sensor network protocol stack below the network layer. above the link layer. Because the narrow waist is placed in this position, the basic communication element is a single-hop broadcast. This agrees that other mechanisms, such as congestion control, can be effectively implemented under this architecture.
Our architecture has been proven. The narrow waist of the sensor network architecture should be single-hop best-effort broadcast.
2.2 Address-free Protocols
An important feature of sensor networks is the address freedom protocol. Address Freedom Protocol is a protocol that does not use node addresses. One of the most common examples of address freedom protocols is the data dissemination protocol. In a data distribution protocol, data is sent from a source node to all nodes in the network it covers.
Neither the source node nor all other nodes in the network need to know the address of the receiving node.
on the contrary. Nodes can use broadcasts to send data to all of their one-hop neighbors. The neighbor node can in turn broadcast data to all its one-hop neighbor nodes again.
2.3 Name-Based Protocols
Although address freedom protocols play a fundamental role in sensor networks, there are always name-based protocols.
For name-based protocols, each node is named exactly (usually using their node identification address).
The most well-known name-based protocol is unicast multi-hop routing, which requires that data packets in the network must be sent from a specified node to another specified node, and the sender knows the address of the receiver, the sender and the Routing intermediate nodes between recipients also know the recipient's address.
The Data Acquisition Protocol is a hybrid of the Address Freedom Protocol and the Name-Based Protocol. In a data collection protocol, nodes participating in data collection send data to one or more sink nodes in the network (don't know what that translates to). The data is forwarded to any sink node in a multi-hop form. Participating nodes do not need to know the address of the sink node that finally accepts the data. Just generally need to know the address of the one-hop neighbor. In order for a node to send data to a sink node, it must send data to one-hop neighbors.
Therefore, the data acquisition protocol is an address-free protocol in multi-hop perception, and a name-based protocol in single-hop perception.
2.4 Neighbor abstraction
Many sensor network algorithms study nodes that are physically or logically close to each other, thus giving rise to the programming abstractions for developing these algorithms.
Although the neighbor abstraction usually hides the communication at the abstraction layer. However, nodes participating in the neighbor abstraction usually exchange messages with other nodes. Some messages are sent directly to designated neighbors. Also some messages are broadcast to all neighbors.
Others need scoped flooding to reach all n-hop neighbors [18]. Similarly, some messages are of higher importance than others and may therefore need to be sent using a reliable communication channel, while others can be sent using best-effort messages. A communication architecture for sensor networks must handle such communication patterns.
2.5 MAC Protocol
The most basic goal of the sensor network MAC protocol is to reduce the power consumption of sensor nodes. Wireless communication is generally one of the most energy-intensive modules, and it consumes as much energy to receive messages as to send them. Therefore, the MAC protocol must turn off the radio as often as possible, but the turn-on event of the radio must be long enough to communicate with other nodes.
There are many MAC protocols in sensor networks, including slotted TDMA protocol and contention-based CSMA protocol.
In a TDMA-based protocol, each node is assigned a time slot, and only in this time slot can messages be sent. The CSMA-based protocol ensures that only one sender occupies the channel at any time by evaluating the channel's vacancy. through these mechanisms. Packets are generally not transmitted right away, but are instead queued in a queue before the actual transmission.
The sensor network MAC protocol always treats unicast and broadcast transmission differently. Unicast transmission only needs to send the packet to the receiver. Therefore all other nodes can turn off the wireless switch during this packet transmission.
Many link-layer and MAC-layer protocols support self-active acknowledgment of unicast packets. By marking the packet with a special bit. Indicates that it has been made available for transmission.
Assuming that the sender does not receive the acknowledgment frame, it will retransmit the message.
Different link layer and MAC layer protocols use different addressing modes. Even a single protocol supports multiple addressing modes. Taking link layer 802.15.4 as an example, its packets can use 16-bit short address mode. It is also possible to use the 64-bit extended address mode. in the header. There's even an option to turn off addresses entirely.
An adaptive sensor network communication architecture must be able to support all of the above mechanisms: packet queuing. Broadcast packets and unicast packets are processed separately, and unicast packets are actively confirmed and retransmitted by themselves. different addressing modes.
2.6 Related Standards
The ZigBee specification is an industry standard for short-range, low-data-rate control, sensing applications. The ZigBee protocol stack adopts a layered architecture and provides end-to-end reliable data transmission through the network layer and application support sub-layer of IEEE 802.15.4.
ZigBee further specifies how applications can be constructed by requiring a pre-defined application profile along with associated commands, called clusters, for all nodes in the network. ZigBee supports mesh routing protocol based on AODV [28].
It is generally felt that traditional Internet protocols The family TCP/IP is not suitable for sensor networks. In order to allow TCP/IP to be applied to wireless sensor networks. We have previously suggested using a simplified TCP/IP protocol suite with certain optimization techniques, such as header compression.
Recently, the standards body 6lowpan IETF working group and industry have agreed on the idea.
For example, in order to meet the strict energy consumption constraints of sensor networks, 6lowpan does not fully follow the IPv6 standard and compresses the IPv6 header before transmission.
Ideally, an adaptive sensor network architecture should make the protocols implemented on top of the architecture compatible with these standard protocols.
3 Chameleon Architecture
The chameleon architecture is an adaptive architecture for sensor networks, and the purpose of this architecture is mainly three-fold. First, simplify the implementation of the sensor network communication protocol stack.
This has been achieved through the Rime stack. Second, it is agreed that the protocols implemented on top of the architecture take advantage of the underlying link layer and MAC layer protocol properties.
This has been achieved through package attributes instead of headers. Third, do not care about the protocols and applications executed on the architecture, and can independently form the packet header to be transmitted. This has been achieved with a separate packet transport module.
The Chameleon Architecture draws on previous experience with sensor network architectures, distributed programming, and general network architectures.
Figure 2 shows the architecture of Chameleon.
The architecture consists of three parts: the Rime protocol stack, which provides a series of communication primitives for applications executed on top of the protocol stack. Execute a series of network protocols on top of Rime; the chameleon header transmission module creates packets and headers according to the data at the output of the Rime protocol stack. Applications can be executed directly on the Rime protocol stack or on the network protocol on top of the Rime protocol stack.
The chameleon header transmission module can generate packet headers that are tightly combined bitwise, and can also generate packet headers that conform to specific link layer, MAC layer protocols or other communication protocols. Some header transport modules even implement part of the protocol logic of the protocol they emulate.
Applications and network protocols transfer data down the Rime stack. The Rime protocol stack will add packet attributes to the data, and then pass the data and packet attributes to the lower chameleon header transmission module. The header transmission module establishes the packet header through the packet attribute, and sends the final packet to the bottom layer driver or the MAC layer. The MAC layer examines packet attributes to decide how to transmit the packet. For example, when the MAC layer sends a unicast packet, the sending method is different from that of sending a broadcast packet, and the link layer acknowledgment mechanism needs to be turned on when sending.
3.1 Separation of protocol logic and protocol header
The protocol logic in Rime doesn't deal with the low-level details of the header. These low-level packet header details are managed by the header conversion module.
The Chameleon architecture does not use headers, but rather package attributes.
The information included in the packet header can be found in the packet properties. Packet attribute information is an abstraction of packet header information.
Table 3.1 lists the package attributes that are pre-defined in the Chameleon architecture.
Both the application and the underlying protocol can define additional package properties themselves.
The pre-defined packet attributes include sender address, receiver address, packet ID, packet type, the number of times it has been forwarded, and some feedback information from the bottom layer. For example, the estimation results of link quality and wireless channel congestion information.
Every package property has a scope. The scope of a package property specifies how far the property can trail the package. Assuming the attribute range is 0, surface attributes can only trail packets within this node. Suppose the attribute range is 1, indicating that the attribute in the packet header can be forwarded to at most one node. Suppose the property has a range of 2. Attributes can then be passed to the final recipient even with a trailing packet.
3.1.1 Header field alignment
Common communication protocol. For example, the TCP/IP protocol stack. All require byte alignment of all header fields. The reason for this is that many microprocessors cannot access unaligned data.
The designer of the protocol must ensure that all header fields are properly aligned, so padding bytes must sometimes be inserted in the header.
However. Low-power wireless protocols cannot afford to align all header fields because they must keep their header sizes as small as possible.
Through the chameleon package property, because the header conversion module includes all the details of the underlying header alignment. Therefore, it is not necessary to perform low-level alignment processing on the header field when implementing the protocol.
3.1.2 Endianness
When designing the protocol header. It is usually necessary to ensure that hosts with different endiannesses can communicate with each other.
In communication protocols, the most common endian is network endian (unlike that of most microprocessors). therefore. When implementing the protocol, you must first explicitly convert all multibyte fields of the header to network byte order. Then write the header. when a packet is received. Do the opposite conversion.
By using packet attributes, the protocol is implemented without regard to the endianness of the packets being transmitted. Packet attributes can be accessed directly in host byte order. Chameleon's header conversion module will be responsible for endian conversion.
3.1.3 Cross-layer combination of header fields
Many fields of the protocol header only require one or a few bits, such as the flag field and the field specifying the packet type.
In order to reduce the overall size of the packet header, many single-byte fields are usually put into one byte.
in sensor networks. The overall size of the packet is very small (for example, Tomte Sky's wireless transceiver chip limits the packet size to 128 bytes). In order to transmit as much data as possible in a packet, reducing the size of the header becomes a very important task.
Manually padding single-bit header fields has many disadvantages.
First. The exact number of single-bit fields must be known when implementing the protocol, and these header fields must be accessed via shift operations and Boolean expressions. Second, the memory location of the single-bit fields must be known when implementing the protocol.
Third, protocols at different layers cannot combine their single-byte fields into a single byte.
in a traditional layered communication architecture. It is not possible to pack less than one byte fields at different layers into one byte. Instead, these fields need to occupy entire bytes.
Figure 3 is an example.
The package attribute of the Chameleon architecture simplifies the implementation of header field bit-combination, enabling bit-combination of header fields within this layer and between different layers.
Because the header transport module has access to all packet attributes of each packet. So it effectively packs bit attributes into a single byte, as seen in Figure 4.
3.1.4 Header compression
Header compression is a mechanism to reduce the transmission header. Header compression can not only increase network throughput, but also reduce power consumption and packet loss in wireless networks. In wireless sensor networks, header compression has been used to reduce the IPv6 header size of 6lowpan.
In traditional header compression, the header compression module not only parses the original header format, but also performs bit combination. Header compression is included into the schema through package attributes.
3.2 Logical channel channel
in chameleon architecture. Use different logical channels for communication.
Each channel has its own protocol and packet properties.
##3.3 Buffer management
##3.4 Lightweight layering
##3.5 Header transmission
##3.6 Header transmission is not enough
##3.7 Bottom layer feedback
#4 Rime protocol stack
##4.1 Rime communication primitives