An Embedded System Dedicated to Intervehicle Communication Applications
© Xunxing Diao et al. 2010
Received: 1 December 2009
Accepted: 7 July 2010
Published: 27 July 2010
To overcome system latency and network delay is essential for intervehicle communication (IVC) applications such as hazard alarming and cooperative driving. This paper proposes a low-cost embedded software system dedicated to such applications. It consists of two basic component layers: an operating system, named HEROS (hybrid event-driven and real-time multitasking operating system), and a communication protocol, named CIVIC (Communication Inter Véhicule Intelligente et Coopérative). HEROS is originally designed for wireless sensor networks (WSNs). It contains a component-based resource-aware kernel and a low-latency tuple-based communication system. Moreover, it provides a configurable event-driven and/or real-time multitasking mechanism for various embedded applications. The CIVIC is an autoconfiguration cooperative IVC protocol. It merges proactive and reactive approaches to speed up and optimize location-based routing discovery with high-mobility nodes. Currently, this embedded system has been implemented and tested. The experiment results show that the new embedded system has low system latency and network delay under the principle of small resource consumption.
Each year in Europe, 1,300,000 vehicle accidents result in 1,700,000 personal injuries. The financial cost of vehicle accidents is evaluated at 160 billion Euros (approximately the same cost in the USA ). Many IVC projects were investigated [2–4] but the implementation aspects were not detailed. To improve the highway safety, a low-cost and a more reliable embedded IVC is needed especially for applications like hazard alarming and cooperative driving (e.g., collision avoiding). As one can imagine, such applications require extra effort to deal with real-time event and network delay under the dynamic topology caused by highly mobile network nodes; thus, we have proposed an autoconfiguration location-based IVC protocol named CIVIC in [5, 6].
General purpose proactive (e.g., OLSR ) and reactive protocols (e.g., AODV ) are not adapted to IVC application due to high dynamic topology change. The CIVIC protocol includes both proactive and reactive approaches to make it suitable for IVC. The proactive approach is the one-hop neighbour knowledge exploration. In order to avoid network traffic overhead, the proactive intervals are autoconfigured depending on the positions and speeds of network nodes. Based on previous neighbour information, CIVIC can then speed up and optimise the routing discovery. The routing approach can be reactive or proactive depending on application layer requiring. Either way, if destination node is not in one-hop distance, CIVIC will select the best effective node to forward routing requests by a directional resource-aware broadcast mechanism.
The last experiment result of CIVIC protocol is shown in . Until this experiment, the tasks in CIVIC are implemented as infinite loops. Tasks are driven by events (e.g., timer interrupt) and run in a nonpreemptive scheduling mechanism. Such mechanism cannot assure the event-driven tasks run in time when system is busy, and it is difficult to achieve the intranode resource-aware.
To overcome these shortcomings, this paper proposes a new low-memory footprint IVC design integrated an operating system named HEROS. HEROS merges the advantages from both event-driven and real-time multitasking mechanisms into a hybrid configurable component-based mechanism. This hybrid mechanism can be adopted in various applications driven by events but also required to have real-time operations. For example, in the intervehicle hazard alarming applications, when a vehicle detects the hazard triggered by events, it may need to maintain real-time communications to inform other vehicles for example to avoid collision (in case of bad weather: smog, snow, etc.).
A fundamental requirement for practical embedded system is resource-aware, HEROS provides the new IVC embedded system with intranode resource-aware mechanism. Although the embedded system on vehicles may gain better hardware supports, the characteristics of embedded hardware still have to cope with resource constraints in terms of CPU, memory, energy, and transmission distance. The HEROS originally designed for WSNs with stringent resource constraints. Its microkernel architecture allows hybrid tasks to be run with low memory consumption. Moreover, it provides a tuple-based intranode communication and synchronization system based on the parallel programming language LINDA [9, 10]. It is the key technology to enable the lightweight resource-aware design on our embedded IVC system.
Summarizing, in the new IVC embedded system, HEROS provides CIVIC with intranode mechanisms to run hybrid tasks and manage hardware, while CIVIC constitutes a quick-response internode communication stack on HEROS. The designs have been implemented in LiveNode sensor board , and experimented with a small network grouped by nine nodes. The experiment results show the new design embedded system has low system latency and network delay. Thus it is adapted to IVC application such as collision avoidance.
The remainder of the paper is organized as following. The related works of HEROS and CIVIC will be summarized in the next section. Section 3 introduces the HEROS system microkernel. Section 4 presents the CIVIC protocol. Section 5 explains how these two component layers work together. Section 6 describes the evaluations of system performance. In the last section, we present the conclusion and the ongoing work.
2. Related Works
2.1. Embedded Operating System
In the existing embedded OSs, there are two common operation mechanisms: multitasking and event-driven.
The real-time multitasking mechanism provides a solution for rapidly developing the time-sensitive applications and it gives the full control over tasks . However, this mechanism consumes high resources in terms of energy, CPU and memory. The existing embedded RTOSs such as SDREAM , C/OS-II , VxWorks, QNX, pSOS, WinCE.NET, RTLinux, Lynxos, RTX, and HyperKernel are not suitable for the embedded IVC system because they only operate as this mechanism and it is resource consuming (CPU and memory) comparing with our proposed solution one.
To minimize resource consuming, many embedded OSs were developed for WSN fields (called WSNOS: WSN Operating System) such as TinyOS , MagnetOS , Contiki , MantisOS , EYEOS , and SOS  (sensor operating system). These WSNOSs meet the requirement of resource constraint. TinyOS adopts the event-driven component-based structure and has a tiny memory footprint. The rest of WSNOSs except Contiki adopt multitasking concept. Similar to TinyOS, Contiki is based on event-driven, but it may be configured to run in hybrid mode: event-driven and multitasking. Contiki is not a native hybrid WSNOS.
Note that, on one hand, a single task event-driven system does not fit for hard real-time constraint. On the other hand, in an event-driven mechanism (e.g., TinyOS), the task switches is normally based on a nonpreemptive event-loop. This mechanism has the advantage in low resource consumption, so it is suitable for WSNs. However, the existing event-driven embedded WSNOSs are essentially implemented by a single processing mechanism; thus, they may not be suitable for IVC applications, which require complex real-time operations.
In HEROS, we merge these two operation mechanisms into a configurable modular mechanism. This design is able to adapt to more various WSN and IVC applications include intelligent transportation, health care, military, and so forth.
2.2. IVC Protocol
The major features of CIVIC protocol are to discover and maintain the routing path in high-mobility embedded networks. The current routing protocols can be classified into three classes: proactive, reactive, and hybrid.
The proactive routing protocols maintain up-to-date routing tables for partial or entire network. It keeps the message delay low because data can be sent to a destination node without an immediate routing request. However, in order to have correct routing paths, each node needs to explore network routing periodically, thus network traffic could be increased significantly. The main proactive protocols are OLSR (optimized link state routing) , DSDV (destination-sequenced distance-vector) , and TBRPF (topology dissemination based on reverse-path forwarding) . Moreover, the proactive routing protocols are not suitable for IVC because the network topology changes quickly due to the vehicle mobility.
The reactive routing protocols do not maintain routing tables. They discover routing paths only when a demand is received. Therefore, they are more efficient in terms of bandwidth utilisation but along with additional message delay. The main reactive protocols are DSR (dynamic source routing) , AODV (ad hoc on demand distance vector) , TORA (temporally-ordered routing algorithm) , ABR (associativity-based routing) , and SSR (Signal Stability Routing) .
The hybrid routing protocol combines the advantages of the proactive and reactive protocols. An example is ZRP (zone routing protocol) . It includes two routing components: a proactive intrazone routing component and a reactive interzone routing component. The CIVIC protocol has some similarities like ZRP. However, none of previous mentioned routing protocols have considered the particularity of the IVC such as direction, location, and road traffic, which will be explained in detail in Section 4.
3. HEROS Microkernel
The cost and the efficiency of the embedded IVC system are an important factor for car manufacturers and high-way infrastructure management. To minimize the cost it is essential to implement appropriate embedded hardware and software (real-time operating system and communication protocol) meeting the real-time IVC application.
In this section, the system architecture, the scheduling mechanism, and the communication and synchronization mechanism of HEROS microkernel are introduced, respectively.
3.1. System Architecture
HEROS adopts the component-based system architecture to perform the event-driven and/or real-time operations. It contains two main system components: thread and etask (event task).
Thread is the essential system component that performs a single action in HEROS. A series of threads can be engaged in complex real-time task under the control of a master etask. Threads belong to an etask run parallel and corporately; hence, they must be interruptible and preemptive. Each etask must contain at least the general daemon thread, which enables the related hardware to be switched into low-power mode. For example, in an application with low wireless data rate, most of time, the daemon thread can disable the wireless access medium module (idle mode). Etask is a packing widget that encapsulates a group of threads to complete a task. Etasks are performed in sequence according to the priority of etasks; hence, etasks are interruptible but not preemptive. Within an etask, threads share tuple space (buffer resources) and allocate private context stacks. After an etask is completed, its tuple and stack will be released. This design allows the embedded application to be scheduled for various tasks with less memory footprint.
Structure of component control block.
Numeric ID of this component
Current state of this component
Priority of this component
Maximal lifetime of this component
Current runtime of this component
Pointer of next component in the ready list
Numeric ID of the thread's tuple
Start buffer pointer of the thread's stack
Current buffer pointer of the thread's stack
3.2. System Scheduling
HEROS adopts the two-level priority-based scheduling mechanism to merge event-driven and real-time tasks at one system. This mechanism can provide a predictable scheduling with an invariable scheduling time.
3.2.1. Priority Scheduling Mechanism
Due to the interruptible and nonpreemptive characterises, etasks are performed in a typical event-driven mode. An active etask runs to completion until all threads of this etask has been terminated. In view of the interruptible and preemptive characteristics, threads are performed in a typical multitasking mode. The elected thread can preempt any other lower priority threads at any execution point outside of system critical section.
where at time , which means that the component elapses its time-slice and then will be terminated.
System scheduling functions.
System Primitive, read data from tuple
System Primitive, write data into tuple
Perform etask scheduling mechanism
Perform thread scheduling mechanism
Insert a thread to TCB and resort TCB items
Delete a thread in TCB and resort TCB items
Insert a etask to ECB and resort ECB items
Delete a etask in ECB and resort ECB items
Perform etask-to-thread conversions
3.2.2. Etask-to-Thread Conversion
Considering a specific case where a higher priority etask is ready and at the same time the current activated etask has the lower priority comparing with one, then can only be elected to run after has been terminated. Consequently, the above-mentioned scheduling mechanism cannot meet the real-time requirement.
One solution is to adopt the etask-to-thread conversion scheme: can be treated as the thread with highest priority in , so that can preempt any other active thread of in view of the thread scheduling mechanism. The scheme breaks down the obstacle between threads and etasks, allowing the threads of an urgent etask to preempt the CPU resource in real-time.
where and are the initial priorities of after and before conversion of , and and are the initial priority of and the current priority of .
3.3. System Communication
To simplify the system implementation, HEROS provides a uniform interface and a tuple-based communication mechanism for the interactions of system components. Basing upon the concept of parallel language LINDA, HEROS adopts the tuple space and the IN/OUT primitives for the message exchange and interprocess communication (IPC).
3.3.1. Tuple Space
The tuple space consists of a set of tuples (buffers), which are used to exchange data or manage signals between components. In HEROS, each thread is allocated a unique tuple, through which other components can send data to activate this thread. Two kinds of interactions are allowed for the system communication and synchronization: the interior interaction between threads and the exterior interaction between threads and peripherals.
Structure of tuple_table.
Numeric identifier: key of tuple
Current tuple state: Free or Full
Current writing buffer pointer
Current reading buffer pointer
Count of current message in tuple
Length of the ring buffer (constant)
The start address of ring buffer (constant)
The end address of ring buffer (constant)
3.3.2. System Primitive
IN/OUT is the pair of system primitives that is responsible for the communication and data exchange between system components and peripherals. The IN primitive is called when a thread needs to read data from its related tuple. Defining is the tuple and τ s is the source thread, the functional description of the IN primitive is shown in Figure 3.
(1)If (Data is ready in ), then Read data from of , and Update the state of ;
(2)Else, update the state of , and then call thread_scheduler to suspend and start a new scheduling.
The OUT primitive is called when an ISR (interrupt service routine) or a thread needs to communicate with one another. Defining is the tuple, is the object thread and is the owner etask, the functional description of the OUT primitive is shown in Figure 4.
(1)Write data into of ;
(2)Update the states of ;
(3)CallInsertThreadList to insert into TCB of , and then resort the threads of this TCB;
(4)If ( is not in ECB), then call InsertEtaskList to insert into ECB and then resort the etasks of this ECB;
(5)If ( is current_etask and is the highest one in TCB), then call thread_scheduler to start a new scheduling;
(6)If ( is not current_etask and is the highest one in ECB), then call etask-to-thread to perform etask-to-thread conversion.
4. CIVIC Protocol
The second assumption of CIVIC protocol is that the location and direction of network nodes could be obtained by GPS (global positioning system) on vehicles or from roadside MMRS.
4.1. Routing Mechanisms
Based on these two assumptions, CIVIC protocol is run with the following two mechanisms.
4.1.1. One-Hop Link Stability
A common way to ensure quick routing response is to keep stable connections. In a high-mobility scenario like vehicular network, the survival time of stable connections has great impact to QoS.
where is the radio range in the worst case; is the location of source node, and is its average speed; is the location of one of its neighbour nodes, and is the speed of this neighbour node. Both and are adjusted by the worst case of GPS error. The equation set (1) means that the interval of sending "Hello" messages depends on the distances and the relative speeds between the source node and its neighbour nodes.
After neighbour knowledge explorations, each node stores its neighbour information for the further multihop routing algorithm.
4.1.2. Multihop DANKAB
Due to resource constraints of embedded system and negative effects from radio irregularity , broadcast is a suitable transmitting scheme for IVC routing algorithm. However, it is well known that broadcast could cause serious redundancy, contention, and collision . Therefore, it is important to determine a correct broadcasting technique. DANKAB (directional area neighbour knowledge adaptive broadcast) is therefore proposed.
In an infrastructure network, the roadside MMRS can provide the location of destination node D. In an ad hoc network, a location request will be performed by simple flooding to all directions. Other nodes in the same network can store the location responded from destination node to avoid resending such requests. The location of destination node may change during this process, but the DANKAB is based on broadcast, so there is no need for a very accurate location of destination node.
When there is more than one node in the direction area, two energy-aware methods can be adopted for selecting the next candidate node. The first method is competitive broadcast. When a node in area α forwards (rebroadcasts) a routing message, it sends with a delay based on the remaining energy, thus the node with more energy will forward a message more quickly. Other nodes with less energy will discard the same routing message when they receive the first forward one. The second method is to let the source node S selecting the node for next hop. It requires the additional information about remaining energy in neighbour knowledge explorations, but it generates much less routing data. We use the second approach for the implementation in this paper.
After defining the next hop of source node S, the processes of DANKAB repeat hop-by-hop until the routing message attains the destination node or reaches the preset limitation of hop number.
If the routing path has been obtained, the data from application layer will be transmitted. If the data rate is low, DANKAB can also be integrated to the data sending, and the routing request can be ignored. For the implementation in this paper, the two mechanisms are separated.
4.2. Message Delivery Mechanisms
Max Size (Byte)
The first group is for one-hop neighbour knowledge exploration, which includes HELLO_REQ (hello request) and HELLO_RPY (hello reply) messages. The second group is for multihop routing request and reply preformed by DANKAB. The ROUTE_REQ_SF is sent when the location of destination node is unknown. This message is normally reply by ROUTE_RPY_CIVIC. The ROUTE_REQ_CIVIC message is sent when the location of destination node is known, and it is normally replied by ROUTE_RPY_BY_PATH. More details of routing message will be described in the next part.
The data from application layer is contained by a DATA_SEND_BY_PATH message. To assure such message reaches the destination node, a node can ask the destination node to send back a acknowledge message, which is named DATA_ACK_BY_PATH.
5. System Design
Our hardware platform is LiveNode , a versatile wireless sensor platform that enables to implement rapidly a prototype for different application domains. The LiveNode hardware platform has been successfully used in applications including telemedicine (wireless cardiac arrhythmias detection), intervehicle communication , and environmental data collection (FP6 EU project NeT-ADDED).
The new embedded system can provide adaptive task mechanisms for different IVC application requirements. This section describes an event-driven software design that has been tested. In this design, the flow of computing process is driven by OS events such as packet arriving, location updating, and timer noticing, thus it can complement protocol stack works and leave low memory footprint .
The US1_TX_RDY etask handles the message outputs. To avoid the sending intervals becoming too short, other etasks should not directly send out messages. Instead, they push messages into a buffer list called MsgOutList as the step one shown in Figure 9. It will activate the US1_TX_RDY etask to check whether the last transmission has been finished. If it has been finished, a message will be sent out by the "Message Out" thread (Step ); if not, the etask is end, and a PIT timer will be activated to run the etask after a waiting period (Step ). In addition, for the time-sensitive designs, the TIMER_RDY etask can take control of the output related to send message at a fix interval.
6. System Evaluation
6.1. HEROS Evaluation
6.1.1. Memory Consumption
Memory consumption of HEROS.
Memory consumption (BYTE)
6.1.2. Execution Time of IN/OUT Primitives
Execution time of IN/OUT primitives.
Time ( s) (48 MHz)
In the IN primitive, the maximal value is the execution time of reading bytes from the thread tuple when a message is ready; the minimal value is the execution time of calling thread_scheduler when no data is available. In the OUT primitive, the execution time is the time interval of writing n bytes into the thread tuple and then calling InsertThreadList. The message length n is limited between 0 and the length of the tuple buffer , thus the execution time of IN/OUT primitives are also predictable.
6.1.3. System Latencies
The mechanisms of system scheduling and interrupt handling are critical for the designs of RTOSs, which should promise the predictable and deterministic system behaviours. System latencies are the key metrics to evaluate the real-time performance of RTOSs. In HEROS, the etask-to-etask switch latency andthread-to-thread switch latency are used to evaluate the system scheduling mechanism, and the interrupt response latency and interrupt dispatch latency are used to rate the interrupt handling mechanism.
(i)etask-to-etask switch latency: the time elapsed for system switching from one etask to another. The etask_manager is called to run the next ready etask. The belonging thread of this etask is activated in the "cold" mode.
(ii)thread-to-thread switch latency: the time elapsed for system switching from the current thread to another. The thread_scheduler is called to run the next ready thread. Note that the thread can be activated in the "code" or "warm" mode.
(iii)Interrupt response latency: the time elapsed from the last instruction of the interrupted components and the first instruction in ISRs, which indicates the rapidity of the system reaction to an external interrupts.
(iv)Interrupt dispatch latency: the time interval to go from the last instruction in the interrupt service routine to the next thread scheduled to run, which indicates the time needed to switch from interrupt mode to user mode.
Performance evaluation of system latencies.
Time ( s) (48 MHz)
Call etask_manager to run the nextetask. The ready thread of this etask is performed in "cold'' mode;
Call thread_scheduler to run the next thread1: thread is performed in "cold'' mode; 2: thread is performed in "warm'' mode.
6.1.4. Comparison with TinyOS
Performance evaluation between HEROS and TinyOS.
Time ( s)
Time ( s)
Scheduling a task
Hardware Interrupt (hw)
Hardware Interrupt (sw)
OS Size (byte)
6.2. CIVIC Evaluation
The first experiment is done in a network with nine static sensors. A sensor is set as the destination node. The other sensors keep sending routing requests and application data to this destination sensor. We implement all mechanisms of CIVIC protocol on HEROS for the experiment. The maximum interval of US1_TX_RDY for message sending is set to be in 100 ms.
Since the sensors are static, we replace the GPS location with a random location in a parking (about meter squares) of our campus, and sensors only response to messages sent from the distance less than 50 meters. Because each sensor actually receives all messages from the network, it requires more operations by both CIVIC and HEROS. This experiment focuses on testing the overall network performance.
Individual sensor status.
The message loss rate in this experiment should be caused by network traffic overhead, interferences, shading, and message collisions. As previous mention, all nine nodes are actually receiving message from the whole network, so they have the same conditions of the incoming network traffic. Moreover, we can assume that the message rate in Table 9 indicates the intranode performance of single node. If a node cannot handle such incoming network traffic and cause output message loss, the loss rate should be increased with the message rate.
Memory consumption of this system.
The next experiment is to test the message delay and bandwidth capability by excluding the network related efforts. The experiment is done with two static sensors. One sensor acts as a message sender. It keeps sending new messages with growing size and interval. The other sensor acts as a receiver, and it acknowledges the incoming message. The size of acknowledge is 5 bytes. If the sender does not receive the acknowledgment of last message, the same message will be resent three times. The size of message increases from 5 bytes to 245 bytes. The interval of sending message increases from 10 ms to 100 ms. All subtests perform 10 times and get average values. This experiment only enables etasks for sending and receiving. The message delay and resending count are used to evaluate network performances. The "delay" in this paper means the timing between sending a new message and receiving its acknowledgment.
Firstly, the results on message delay may not reflect on the results of loss rate. It only indicates the US1_RX_RDY etask cannot get access to its processing thread because the US1_TX_RDY etask is too busy on sending message. The design of etasks does not allow preemptive, thus it is normal.
Secondly, the increase rate of message delay is slow down after the message size reaches about 100 bytes. The reason is from the transmitting mechanism of Xbee clip and the sequence of delay factors. The Xbee clip has an internal 100 bytes output buffer. When the message size is lower than 100 bytes, the packet will not be sent immediately. Thus, the delay factors in a transmitting happen separately and in succession. There are three major delay factors from the transmissions in sender, over-the-air, and in receiver. When the size of messages is more than 100 bytes, these three factors happen simultaneously and the overall delay decreases. Since the maximum message size of CIVIC protocol is less than 64 bytes (at 100 ms sending intervals), the result between 5 to 65 bytes is more important for evaluating the system.
7. Conclusion and Ongoing Work
Embedded communication systems normally contain two basic component layers: a protocol stacks to manage network communications and an operating system to interface with hardware and schedule tasks or events. Based on such structure, this paper presents a new low-cost and low-memory footprint design and its implementation for embedded IVC applications with CIVIC as protocol stack, and HEROS as embedded OS.
HEROS proposes an Etask/Thread modular architecture and adopts a tuple-based IN/OUT primitive communication mechanism to provide both event-driven and real-time multitasking operation modes. CIVIC adopts the DANKAB mechanisms to provide a resource-awareness and rapid convergence routing algorithm. By these designs, this system can adapt to a wider range of IVC applications. At present, the CIVIC protocol has been ported on HEROS to perform the real-time multitasking and event-driven WSN applications. The experiment results in Section 5 show that this embedded system has small resource consumption and is adaptable to different applications. Moreover, thanks to low message-sending delay, the present design may be used to implement low cost embedded collision avoidance device by combining GPS receiver and IVC data.
Currently, this low-cost embedded system is still under development and evaluation, the result of network performances is not so perfect, but it shows the adaptability of this system to high-mobility scenarios.
The ongoing works of CIVIC are to reduce memory consumption and continue improving its communication QoS. For HEROS, its programming models are not completed, thus a hardware abstract layer or interface will be provided in future. Moreover, the current implementation will be carried out on the intelligent multimodal transportation system in Clermont-Ferrand city (France).
The authors would like to thank all colleagues who contributed to the study. The authors would also like to thank the reviewers for their remarks, which enable to improve this paper. The authors are grateful for the EU (NeT-ADDED FP6 EU project) and the French EGIDE international cooperation plan (PHC PFCC No. 20974WG) for their supports to this project.
- Fitzgibbons B, Fujimoto R, Guensler R, Hunter M, Park A, Wu H: Simulation-based operations planning for regional transportation systems. Proceedings of the 5th Annual National Conference on Digital Government Research: New Challenges and Opportunities, May 2004, Seattle, Wash, USA Google Scholar
- Shiraki Y, et al.: Development of an inter-vehicle communications system. OKI Technical Review 187 2001, 68: 11-13.Google Scholar
- Käsemann M, et al.: A Simulation Study of a Location Service for Position-Based Routing in Mobile Ad Hoc Networks. 2002, http://www.et2.tu-harburg.de Google Scholar
- Wurpts M, Logan R: HLA inside and out: intra- and inter-vehicle communications. Proceedings of the Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC '03), 2003 9.Google Scholar
- Diao X, Kara M, Li J, Hou K-M, Zhou H, Jacquot A, Amamra A: Experiments on PAVIN platform for cooperative inter-vehicle communication protocol (CIVIC). Proceedings of the IEEE Africon Conference, September 2009, Nairobi, Kenya Google Scholar
- Diao XX, et al.: Cooperative inter-vehicle communication protocol with low cost differential GPS. Journal of Networks 2009,4(6):445-457.View ArticleGoogle Scholar
- Clausen T, Jacquet P: Optimized Link State Routing Protocol. IETF RFC 3626, October 2003View ArticleGoogle Scholar
- Kosch T, Schwingenschlögl Ch, Ai L: Information dissemination in multihop inter-vehicle networks—adapting the ad-hoc on-demand distance vector routing protocol (AODV). Proceedings of the 5th IEEE International Conference on Intelligent Transportation Systems, 2002, Singapore Google Scholar
- Ahuja S, Carriero N, Gelernter D: Linda and friends. Computer 1986,19(8):26-34.View ArticleGoogle Scholar
- Gelernter D: Generative communication in LINDA. ACM Transactions on Programming Languages and Systems 1985,7(1):80-112. 10.1145/2363.2433View ArticleMATHGoogle Scholar
- Hou KM, De Sousa G, Chanet JP, et al.: LiveNode: LIMOS versatile embedded wireless sensor node. Proceedings of the 7th International Conference on New Technologies of Distributed Systems (NOTERE '07), June 2007, Marrakech, Morocco 65-69.Google Scholar
- Raatikainen K: Operating system issues in wireless ad-hoc networks. Proceedings of the Keynote Speech in International Workshop on Wireless Ad-Hoc Networks, May 2005 Google Scholar
- Zhou HY, Hou KM, De Vaulx C: SDREAM: a super-small distributed REAl-time Microkernel dedicated to wireless sensors. International Journal of Pervasive Computing and Communications 2006,12(4):398-410.Google Scholar
- Labrosse JJ: MicroC/OS-II: The Real-Time Kernel. 2nd edition. CMP Books; 2002.Google Scholar
- Levis P, Madden S, Polastre J, et al.: TinyOS: an operating system for sensor networks. In Ambient Intelligence: Part II. Springer, Berlin, Germany; 2005:115-148.View ArticleGoogle Scholar
- Barr R, Bicket JC, Dantas DS, Du B, Kim TWD, Zhou B, Sirer EG: On the need for system-level support for ad hoc and sensor networks. ACM Operating System Review 2002,36(2):1-5. 10.1145/509526.509528View ArticleGoogle Scholar
- Dunkels A, Grönvall B, Voigt T: Contiki—a lightweight and flexible operating system for tiny networked sensors. Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks (LCN '04), November 2004 455-462.View ArticleGoogle Scholar
- Bhatti S, Carlson J, Dai H, Deng J, Rose J, Sheth A, Shucker B, Gruenwald C, Torgerson A, Han R: MANTIS OS: an embedded multithreaded operating system for wireless micro sensor platforms. Mobile Networks and Applications 2005,10(4):563-579. 10.1007/s11036-005-1567-8View ArticleGoogle Scholar
- Dulman S, Havinga P: Operating system fundamentals for the EYES distributed sensor network. In Progress Report. , Utrecht, The Netherlands; 2002.Google Scholar
- Han C-C, Kumar R, Shea R, Kohler E, Srivastava M: A dynamic operating system for sensor nodes. Proceedings of the 3rd International Conference on Mobile Systems, Applications, and Services (MobiSys '05), 2005 163-176.View ArticleGoogle Scholar
- Perkins CE, Bhagwat P: Highly Dynamic Destination Sequence-Vector Routing (DSDV) for mobile computers. Computer Communication Review 1994,24(4):234-244. 10.1145/190809.190336View ArticleGoogle Scholar
- Ogier R, Templi F, Lewis M: Topology dissemination based on reverse-path forwarding (TBRPF). IETF RFC 3684, February 2004View ArticleGoogle Scholar
- Johnson DB, Maltz DA, Broch J: DSR: the dynamic source routing protocol for multi-hop wireless ad hoc networks. In Ad-Hoc Networking. Edited by: Perkins CE. Addison-Wesley, New York, NY, USA; 2001:139-172.Google Scholar
- Park VD, Corson MS: Highly adaptive distributed routing algorithm for mobile wireless networks. Proceedings of the 16th IEEE Annual Conference on Computer Communications (INFOCOM '97), April 1997 1405-1413.Google Scholar
- Toh CK: Long-lived ad-hoc routing based on the concept of associativity. IETF MANET Working Group, Internet Draft, March 1999Google Scholar
- Dube R, Rais CD, Wang K-Y, Tripathi SK: Signal stability-based adaptive routing (SSA) for ad hoc mobile networks. IEEE Personal Communications 1997,4(1):36-45. 10.1109/98.575990View ArticleGoogle Scholar
- Schaumann J: Analysis of the Zone Routing Protocol. December 2002, http://www.netmeister.org/misc/zrp/zrp.pdf Google Scholar
- Zhou G, He T, Krishnamurthy S, Stankovic JA: Impact of radio irregularity on wireless sensor networks. Proceedings of the 2nd International Conference on Mobile Systems, Applications and Services (MobiSys '04) 2004, 125-138.View ArticleGoogle Scholar
- Tseng Y-C, Ni S-Y, Shih E-Y: Adaptive approaches to relieving broadcast storms in a wireless multihop mobile ad hoc network. IEEE Transactions on Computers 2003,52(5):545-557. 10.1109/TC.2003.1197122View ArticleGoogle Scholar
- Zhou HY, De Sousa G, Chanet J-P, Hou KM, Li JJ, De Vaulx C, Kara M: An intelligent wireless bus-station system dedicated to disabled, wheelchair and blind passengers. Proceedings of the IET International Conference on Wireless Mobile and Multimedia Networks (ICWMMN '06), November 2006 434.View ArticleGoogle Scholar
- Moubarak M, Watfa MK: Embedded operating systems in wireless sensor networks. In Guide to Wireless Sensor Networks. Edited by: Misra S, Woungang I, Misra SC. Springer, New York, NY, USA; 2009:323-346.View ArticleGoogle Scholar
- Maurer W: The Scientist and Engineer's Guide to TinyOS Programming. 2004, http://ttdp.org/tpg/html Google Scholar
This article is published under license to BioMed Central Ltd. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.