IDRA [7] was originally developed to support next-generation applications on wireless sensor networks. Wireless sensor networks (WSNs) consist of resource-constrained embedded devices which are wirelessly connected to each other in an ad hoc fashion. Next-generation applications for WSN include topics such as wireless building automation, distributed wireless health monitoring, industrial process monitoring and disaster intervention. Each year, the WSN research community develops new and optimized hardware devices, communication technologies, network protocols and applications. To cope with such a varying environment, IDRA has built-in solutions to support heterogeneous devices (in terms of hardware and communication technologies) and to support evolving services and applications.
There are many similarities between the requirements of WSNs and those of a more general internet of things. This section gives a general overview of the IDRA architecture and discusses which design choices can also be useful in the context of the internet of things.
A Network protocols as services
The OSI reference architecture [38] uses a layered protocol stack whereby all network functionality is assigned to a specific protocol layer. For example, the routing layer includes functionality for providing reliability, for duplicate detection, for retransmissions, etc. In contrast, in IDRA it is possible to implement these different network functions (such as addressing, naming, CRC calculation, routing, etc.) each in a simple, standardized, technology-independent component called a 'network service'. Network services can implement either a full network protocol (such as routing) or a simple function (such as duplicate detection). Each component implements the same interface and functions independent, without direct interaction with other components. New services can be added whenever there is a need for them. For example, a localization service can be added when an application is run that requires location information. This way, more advanced network services can be composed by combining elementary network services according to the needs of the network (Figure 2c). A default 'call sequence' is included that indicates the order in which the network services should be executed. By adding new network services or by changing the call sequence, the network behavior can be changed. Some examples of network services are:
-
a localization service inspects the RSSI of received packets so that it can provide the network with accurate location information;
-
a MAC service is responsible for controlling the timing and sending of packets;
-
a topology service decides from which neighboring devices packets can be received;
-
a synchronization service delivers a network-wide reference clock;
-
a reliability service is responsible for the retransmission of packets;
-
a management service collects and makes available network statistics such as the background noise level and the number of failed transmissions.
Initially, such a network service-oriented approach is compatible with a layered approach: fully implemented network layers can register themselves as network services. A transition toward a network-service-oriented architecture can occur gradually by standardizing a further decomposition of the protocol layer into multiple well-defined network services.
In the context of the internet of things, a network-service-oriented network architecture has the following advantages.
Pervasiveness
Separating network functionality into different services results in a lower memory footprint, since (1) network services are only added on a per-need base and (2) functionality is not duplicated in several protocol layers. As such, this approach is well suited for networks that contain resource-constrained devices.
Extensibility and maintenance
A second advantage of a service-oriented network architecture is the ease with which the network copes with future developments. New applications are supported at a network level by plugging in the appropriate network services (for example: an advanced encryption service can be added to process all packets from an online banking application).
Transparency
Rather than directly interacting with a multitude of different communication technologies, such as IEEE 802.15.4 (Zigbee), IEEE 802.15.1 (Bluetooth), IEEE 802.11 (Wi-Fi), LAN or UMTS, the communication manager from Figure 2a translates the communication capabilities of the underlying communication technology in terms of the services they can provide, such as average reliability, energy cost, etc.
B Information driven network services
To limit the dependence of network services on specific technologies, network services are technology independent. Rather than creating technology-dependent packets to exchange information, network services hand over to the IDRA system any information they wish to send (Figure 2b, interaction 1). Example information exchanges are a route request, a web page request or a packet acknowledgment. IDRA creates the actual packet, encapsulates the information in the payload and stores the resulting packet in a system-wide queue. IDRA can be configured to create or interpret any packet type (see Section VI-C). Thus, instead of packet-based sending, IDRA offers information-based communication.
Similarly, all interactions with the communication interfaces are descriptive. For example, a MAC protocol can describe when and how each packet is allowed to be transmitted (e.g., the maximum tolerated background noise, the scheduled sending time, the radio frequency, etc) and how the communication interfaces should be configured (listening frequency, power state, etc.). A conflict resolution scheme is used to detect conflicting settings and inform the MAC service of undesired behavior. As a result, multiple MAC services can reside on the same node, each with one or more associated communication interfaces.
Delegating all technology-related functions, such as packet creation, packet manipulation, packet sending and buffer provisioning, to the IDRA architecture has the following advantages.
Hardware heterogeneity
Tasks which are typically duplicated in several network layers (ie: packet creation, packet manipulation, packet sending and buffer provisioning) are delegated to the system, thus avoiding code redundancy. As a result, the overall code size is reduced, making it possible to support a large number of services even on resource-constrained devices.
Ease of use
Since network services need to consider only 'information exchanges', the development of network services is simplified.
Transparency
The same information exchange mechanism is used for all network services, independent of which packet type will be created and which communication interface will be used. The complexity of low-level operations (buffer management, packet construction, etc) are thus hidden from the network services. This way, network services are not technology dependent, which promotes reuse of network services in different contexts.
C Decoupling of protocol logic and packet representation
Since the network services do not create the packets, they have no knowledge about the header structure of received packets. To retrieve information about created or received packets, network services interact with packets through a 'packet facade' (Figure 2b, interaction 2). Through this packet facade, standardized packet attributes (metadata) can be added, updated or requested. This metadata can represent header fields such as 'destination', 'quality-of-service' or 'time-to-live', but can also be used to describe extra context information such as the packet origin or destination location, the packet owner or additional descriptive information about the packet.
To interpret the structure of created or received packets, the packet facade uses one or more 'packet descriptors'. These packet descriptors describe at which header offset each packet attributes should be stored (Figure 3). This way, any packet type can be generated or interpreted, as long as the correct packet descriptor is available. Packet attributes that do not have a fixed location in the packet header are stored sequentially in the payload in the form of type-length-value (TLV) elements. Since there is no direct interaction between network services and packet descriptors, the packet type can be changed without any changes to the used network services. Decoupling the protocol logic from the packet structure has several advantages.
Packet heterogeneity
Since any packet type can be interpreted as long as the correct packet descriptor is available, it is possible for multiple packet types to reside on a single node, transparent for the network services.
Legacy support
By providing the packet descriptors of legacy devices, IDRA services can interpret packets from legacy networks and interact with legacy packet types.
Context awareness
Any type of context information can be associated with a packet in the form of a packet attribute. This promotes the development of new network services which rely on advanced packet information such as ownership or visibility rights. Metadata can also be used to facilitate mobility solutions [39].
Hardware heterogeneity
Using a packet facade, network services do not need to strip the protocol headers from received packets to interact with packets. Thus, when non-essential network services are omitted from devices with low resources, the remaining network services can still interpret the received packets. In addition, packet attributes remain associated with a packet even if network protocols are omitted at intermediate nodes. Thus, when lightweight nodes are provided with simpler versions of the network services, these simpler services can inspect the packet attributes that were added by more advanced network services.
Future proof
Network services can be implemented independently from the representation of the packets. As a result, reuse of network services is promoted. To change the packet structure or support new packet structures, only the packet descriptor needs to be updated. All other network services remain unchanged.
D Queue management
Depending on the required network performance, different queuing systems can be used in IDRA. To reduce the memory footprint of the queues, the current implementation of IDRA uses a single, system-wide queue for storing packets. Arriving packets are stored once in the shared queue and remain there until processing is finished. This approach limits the number of copy actions of the packets. Network protocols can interact with any of the packets from the shared queue using the packet facade. Since network services are not responsible for queue management, the complexity and memory footprint of the network services are reduced. The advantages of using a single, system-wide queue are the following.
Simplicity
In layered architectures, each network layer requires overprovisioning of its provided buffers to ensure that all packets can be stored. Using a shared queue approach, this overprovisioning is required only once. As a result, network services are simpler and have a small memory footprint.
Network management
Using a single queue ensures that the system can monitor all available packets. This eases the gathering of real-time network statistics.
QoS management
The shared queue has an associated QoS module. This QoS module has a global view on the number of packets, their current processing state and their expected delay. The QoS module can drop packets and selects which packets are processed or transmitted first. Since the QoS module only interacts with the queue, it can provide basic, protocol-independent QoS which can transparently be combined with any IDRA network service.
E Network service broker
Network services can be dynamically added, removed or updated according to the needs of the network. Rather than having a strict execution order (such as in layered networks), network services are activated only when they are needed. Currently, IDRA implements a simple service broker. Each network service registers itself using 'filters' which describe the function of the network service (e.g., routing, localization, etc). In addition, the filters specify for which types of packets the network services can be used (Figure 2b, interaction 3). For example, a QoS aware routing service can register itself for routing high-priority packets ('QoS attribute higher than 5'), a georouting service can be used for routing when location information is available ('location attribute is available') and a multicast routing service registers itself for routing packets to multicast addresses.
In high-end devices, intelligent service discovery mechanisms can be used to detect the capabilities of the network services, and to automatically select and configure the appropriate network services depending on the application requirements. For example, to support a 'fire alarm' or 'emergency reporting' service, the network broker can disable energy-efficient routing in favor of an optimized low-delay routing service. Or a key-distribution service can be activated before a device is allowed to join an existing network. As such, a dynamic network service broker promotes a more flexible internet of things.
Self-configuration
Devices can change their own behavior by plugging in new network services when required. Intelligent self-configuring networks can use the service broker for self-adaptation and for automatic network upgrades.
Hardware heterogeneity
Devices with less capabilities can be configured to use simplified execution sequences which contain less network services. Alternatively, they can negotiate with neighboring nodes to use simplified versions of the required network services.
Legacy support
When interacting with legacy neighboring devices, the service broker can be configured to execute legacy network services in a typical layered order (e.g., MAC, routing, transport, application). This way, network service-oriented devices can coexist with traditional layered devices.
F System-wide aggregation
Many information exchanges (such as status updates, low-priority monitoring information or delay-tolerant measurements) between different devices do not need to be transmitted immediately. In the IDRA system, network services can include information about the maximum tolerated delay when handing over information exchanges to the IDRA system. Time sensitive parameters are immediately encapsulated in a packet, but all other parameters are temporarily stored in a central repository. Whenever a packet is relayed through the node, all information parameters with the same 'next hop' or 'destination' attribute are added to the packet. Delay-tolerant parameters can remain in the waiting space for up to a per-parameter predefined period of time. If no data have been relayed within the allowed waiting time, the system generates a new packet which combines all parameters that have the same destination. As a result, information exchanges from all network services using IDRA can be combined. To avoid high end-to-end delays, the current implementation only delays the parameters in the waiting space of the initial node: packets are not further delayed in intermediate nodes. Since the aggregation is part of the IDRA architecture, the aggregation approach can be changed or optimized depending on the network requirements, without any changes to the network services. The advantages of aggregation at an architectural level are the following.
Reduced interference
By limiting the number of transmissions, the overall wireless interference decreases, resulting in more optimal use of wireless bandwidth.
Increased throughput
It has been shown that the use of small packets has a negative influence on the maximum throughput of transmission systems, in particular for wireless networks. By combining multiple information exchanges in a larger packet when possible, the overall throughput increases.
Increased energy efficiency
Finally, for devices powered by small batteries or by energy scavenging, the use of a radio for transmitting packets results in a serious decrease in network lifetime. By limiting the number of transmissions, the time before battery replacement increases.