Keywords: Network coding, wireless sensor networks, IEEE 802.15.4, ZigBee

This paper describes CoZi, a new packet scheduling mechanism for large scale ZigBee networks. CoZi aims at enhancing the reliability of the data delivery and the bandwidth utilization of the network. Based on simple network coding, instead of the classic packet forwarding, our algorithm takes advantage of the shared nature of the wireless medium as well as the cluster-tree topology of IEEE 802.15.4 networks to increase the global throughput and to reduce transmissions in end-to-end and dissemination-based communications.

I. INTRODUCTION

The emergence of standardized new communication protocols and network architectures exclusively designed for low-power devices and wireless sensor networks (WSNs) is a significant indicator of the degree of maturity attained by these technologies. ZigBee [START_REF]ZigBee Specifications[END_REF] and the IEEE 802.15.4 [START_REF]IEEE Standard for Information Technology, "Part 15.4: wireless medium access control (MAC) and physical layer (PHY) specifications for low-rate wireless personal area networks (LR-WPANs)[END_REF] represent some of these important standards that have contributed to the development of WSNs and Low-rate Wireless Personal Area Networks (WPANs). Based on the underlying cluster-tree topology of the IEEE 802.15.4 standard, ZigBee allows low data-rate wireless communications for energy-constrained devices to provide a variety of applications for health-care, home automation, energy management, remote monitoring and other domains. Ensuring efficient and reliable communications in such erratic environments as wireless networks is a very challenging issue. Indeed, the inherent properties of radio channels can alter communications in terms of delay, data delivery and energy consumption. Nonetheless, a smart utilization of the wireless medium can also drastically improve the network's performances. [START_REF] Ho | The benefits of coding over routing in a randomized setting[END_REF] has shown the potential benefits of taking advantage of the shared nature characteristic of wireless links in order to enhance data delivery and global throughput of wireless networks.

Throughout this article, we describe CoZi (Coding for ZigBee) a coding scheme capable of improving 802.15.4 communications by exploiting the network coding theory innovative concepts [START_REF] Ho | The benefits of coding over routing in a randomized setting[END_REF]. The topology of ZigBee networks consists on abstractly separated clusters built depending on nodes' profiles. The clusters are often physically overlapped, i.e., nodes may frequently receive packets from nodes that are not in the same cluster, via what we designate as overhearing links. We thus propose to exploit these overheard packets with a distributed one-hop coding system as described in [START_REF] Katti | The importance of being opportunistic: Practical network coding for wireless environments[END_REF] to avoid the channel overhead induced by the brute force replication and to improve the global network throughput for both end-to-end and dissemination data-delivery scenarios.

The key target of our work resides on optimizing the global throughput of ZigBee networks. This can be tackled as a scheduling problem which is known to be hard to solve. Therefore, we propose a network coding scheme based on proactive local topology inferring mixed with the utilization of our distributed packet scheduling system in order to improve end-to-end and dissemination based communications in ZigBee wireless sensor networks. We evaluate our solution through simulations considering different network densities and data traffic scenarios. Our performance study shows an important improvement of the global network throughput under high load and a significant gain in terms of delay for both end-to-end and dissemination-based communications

The reminder of the paper is organized as follows: Section II discusses related work of 802.15.4/ZigBee optimization algorithms and network coding techniques for wireless networks. Section III describes the system's characteristics. In section IV we define CoZi, our coding scheme for ZigBee sensor networks, followed in Section V by a detailed performances evaluation. The paper concludes with a brief discussion in Sections VI.

II. BACKGROUND

The IEEE 802.15.4 is extensively employed in WSNs. It is the underlying standard of several well-known technologies such as ZigBee or 6LoWPAN [START_REF] Kushalnagar | 6LoWPAN: Overview, Assumptions, Problem Statement and Goals[END_REF]. TinyOs [5] and Contiki [6] are two operating systems for sensing devices that provide full or partial implementation of the 802.15.4 MAC and PHY layers. Many researchers have investigated the dissemination and data-delivery in 802.15.4 based networks. Both Deluge [START_REF] Hui | The dynamic behavior of a data dissemination protocol for network programming at scale[END_REF] and Typhoon [START_REF] Liang | Typhoon: A reliable data dissemination protocol for wireless sensor networks[END_REF], for example, consider data dissemination for on-the-air reprogramming of large scale 802.15.4 sensor networks. Kim et al. described in [START_REF] Kim | Shortcut Tree Routing in ZigBee Networks[END_REF] a routing protocol based on the neighbor table originally defined in the ZigBee specifications to cope with the insufficiencies inherent to tree-routing. Also, in [START_REF] Zheng | Will IEEE 802.15.4 Make Ubiquitous Networking a Reality?: A Discussion on a Potential Low Power, Low Bit Rate Standard[END_REF], J. Zheng et al. propose a dissemination-based algorithm to build a mesh network upon a ZigBee topology. More recently, authors of [START_REF] Han | Global Optimization of ZigBee Parameters for End-to-End Deadline Guarantee of Real-Time Data[END_REF] have presented a deterministic algorithm which optimally configures ZigBee parameters (beacon intervals, super-frame durations, and guaranteed time-slots) in order to guarantee end-to-end deadlines for real-time packets delivery. All these works aim at optimizing the throughput and the data delivery reliability in ZigBee. We can however notice that none of them exploits the redundant links created by the broadcast nature of the radio channel and thus the extra bandwidth provided by these links.

Independently, recent advances in the applications of the Network Coding theory introduced by Ahlswede et al. in [START_REF] Ho | The benefits of coding over routing in a randomized setting[END_REF] Ismail Salhi 1 , Yacine Ghamri-Doudane [START_REF] Park | Performance of network coding in ad hoc networks[END_REF] the potential benefits of using coding operations at packet level to increase the performances of wireless networks. Many protocols such as, Avalanche [START_REF] Gkantsidis | Network coding for large scale content distribution[END_REF], CodeTorrent [START_REF] Lee | CodeTorrent: Content Distribution using Network Coding in VANET[END_REF], or CodeCast [START_REF] Park | Codecast: A network coding based ad hoc multicast protocol[END_REF] have used random linear coding or simple XOR operations to improve routing, forwarding and dissemination schemes over MANETs, by dividing streams of data into blocks and encoding them before transmissions. In all these cases, the network coding provides a significant gain in terms of reliability, delay and throughput. Different network coding mechanisms have been proposed since the emergence of the concept. For instance, [START_REF] Gkantsidis | Network coding for large scale content distribution[END_REF] uses linear network coding, in which packets are encoded using randomly selected coefficients. In this case, to decode packets nodes have to solve linearly independent equations, this solution is generally used to ensure better reliability and data-availability in large scale wired and wireless networks. In [START_REF] Katti | The importance of being opportunistic: Practical network coding for wireless environments[END_REF] and [START_REF] Katti | XORs in the air: Practical network coding[END_REF], authors use exclusively XOR operations instead of linear equations to facilitate the decoding operations. This coding technique has shown remarkable performances in the improvement of the global throughput in wireless ad hoc networks. In this paper, we extend the work of Katti al. in [START_REF] Katti | The importance of being opportunistic: Practical network coding for wireless environments[END_REF] by exploiting the unique characteristics of the cluster-tree topology of ZigBee networks and by selecting the best code among the different coding possibilities, in order to allow a maximum number of neighbors to decode the packet.

III. SYSTEM DESCRIPTION

The IEEE 802.15.4 standard defines Medium Access Control (MAC) and Physical Layer (PHY) specifications for Low-rate Wireless Personal Area Networks (WPANs). In a 802.15.4 network, devices can be classified in two categories, namely: full function devices (FFDs) or reduced function devices (RFDs). This distinction resides on the role that the node will play within the network. Indeed, FFDs can operate in three modes: PAN coordinator, coordinator, or end-device, whereas RFDs are used only for basic operations (e.g., scalar sensing or basic actuating) and can thus only be considered as end-devices. Note that 802.15.4 uses the roles and the addresses as defined in the ZigBee standard [START_REF]ZigBee Specifications[END_REF]. As depicted in Figure 1, ZigBee networks include the following roles: 1) The Coordinator: it s a unique node in the network in charge of the connectivity with higher performance networks. ZigBee networks have to include at least one FFD operating as the coordinator. In a real application, the coordinator might represent a sink or a gateway in a WSN for instance.

2) Routers: they provide specific services to end-devices or other routers such as synchronization, data collection, and medium access scheduling. Every FFD in the network is eligible to be a router. The overlay network composed of the routers and the coordinator can be seen as a virtual backbone within the network.

3) End-Devices: they can communicate via unicast links exclusively with their unique associated parent, which allows them to minimize their energy consumption.

The routing algorithms provided in ZigBee are either cluster-tree based or table-driven. The tree-routing mechanism is based on the hierarchical block address allocation mechanism called Cskip [START_REF]ZigBee Specifications[END_REF], so each parent has an address interval to distribute to its children. While, table-driven routing is based on the Ad hoc On-demand Distance Vector (AODV) routing protocol [START_REF] Perkins | Ad-Hoc On-Demand Distance Vector (AODV) Routing[END_REF] for multihop ad hoc network. In this paper, we focus on the cluster-tree topology, and the hierarchical routing, which is the default and economical routing mecnanism used in ZigNee networks. Nevertheless, our solution can be easily extended to a mesh routing scenario.

B. ZigBee Network Formation

In order to build the cluster-tree topology, each device goes through two phases before joining the network and starting to send its data (cf. Figure 2). Depending whether the beacon mode is activated or not, the construction of the hierarchy uses different algorithms, although both make use of signalization 1 .

Fig. 2 -CoZi architecture overview 1) Network Initialization Phase: During this phase, the FFD defined as coordinator allocates to itself the network address 0x0000, and if the beacon mode is activated it starts sending beacon-frames to let the neighboring nodes know that they can associate with it. Otherwise, it waits for a beacon-request.

2) Nodes Associations Phase: Whenever a node is turned on, it waits for receiving a beacon from the coordinator or the closest router if the beacon mode is activated. Otherwise, it broadcasts a beacon request and chooses to associate with one 1

We refer to signalization all the exchanged control frames and control packets used to build and to maintain the ZigBee cluster-tree topology (beacons, beacon-requests, association-requests, etc.).

of the responding routers (respectively the coordinator). At the end of the association phase, the node is associated with one unique parent and is given a network address.

3) Data-Delivery Phase: This phase can start if at least two nodes in the network are associated and thus have their network addresses. Since we are interested here in the use a cluster-tree routing algorithm, an RFD node has to transmit its packets to its parent. The latter will then, depending on the destination address, choose a route above the virtual backbone in order to reach the destination.

Our major contribution in this work consists on exploiting the signalization messages exchanged during the ZigBee network construction phase to infer the local network topology of the network at each node. This will allow intermediate nodes to take encoding decisions based on previously received information without any global knowledge of the network topology. To do so, we assume each node has overhearing capabilities i.e., is able to receive from its neighborhood unicast packets that are not directly addressed to him, which is a realistic 2 since the wireless radio channel is by definition a shared medium. We also assume that nodes are capable of performing bit-wise XOR operations at the packet level to use one-hop coding as described in section IV. Note that we use the term "received" for the packets that are received and supposed to be handled by the node according to the routing process, and "overheard" for the packets that were not destined to the node.

IV. COZI OVERVIEW

In this paper, we propose two coding strategies that can be used at each node to maximize the bandwidth utilization of a ZigBee sensor network depending on the nature of its datatraffic. To this end, any ZigBee router can perform network coding operations before data transmissions by combining packets using simple XOR operations. The coding decision takes into account that a maximum number of nodes have to be able to decode the outgoing coded packet.

A. CoZi Queuing System

As depicted in Figure 3 our scheduling system requires an overhearing queue (𝑄 𝑜𝑣ℎ ) in addition to the input queue (𝑄 𝑖𝑛 ). While 𝑄 𝑜𝑣ℎ contains only overheard packets, 𝑄 𝑖𝑛 can include packets in transit from other nodes or new packets from the node itself. Overheard packets are stored within a buffer for a period of time during which they will be used to decode incoming coded packets. Algorithm 1 describes the node functioning when a packet is received or overheard. It shows that whenever an intermediate node 𝐴 receives a new packet 𝑝 from its neighborhood, 𝐴 checks whether 𝑝 is non-coded, in which case 𝐴 acknowledges the reception of 𝑝 if it is destined to him, or stores 𝑝 in its overhearing queue 𝑄 𝑜𝑣ℎ (𝐴) otherwise. In the case where 𝑝 is coded and 𝐴 succeeds to decode it using previously received packets, 𝐴 either sends an ACK packet to the sender or stores 𝑝 in 𝑄 𝑜𝑣ℎ (𝐴) depending on the destination field of the retrieved packet 𝑝 𝑑𝑒𝑐 , as described 2 Overhearing can be easily implemented for 802.15.4 networks by activating the promiscuous mode in every node. We used the same procedure as the one proposed in [START_REF] Katti | XORs in the air: Practical network coding[END_REF] The careful reader might wonder about the potential memory overhead induced by keeping overheard packets at each node and the additional computation delay due to coding operations. In fact, both the delay and the memory requirements for ensuring one-hop coding are negligible. Indeed, to save 117 overheard packets, which is equivalent to a 500ms bufferization period, in an 802.15.4 channel with a capacity of 250 kb/s, the total amount of required memory is less than 15 kilobytes. This is largely available in most ZigBee compliant devices. Concerning the computation overhead, since network coding consists only on atomic bitwise XOR operations, it does not alter the computation time.

B. Topology Inferring

As detailed in [START_REF] Katti | The importance of being opportunistic: Practical network coding for wireless environments[END_REF], in one-hop coding, when a node 𝐴 sends a coded packet 𝑝 to the node 𝐵, 𝐴 has to be sure that 𝐵 will be able to decode it in our case. This can be done only if 𝐴 guesses what 𝐵 has already received and overheard from its neighbors. To do so, as stated in section III, our algorithm goes through a learning phase as the ZigBee network is constructed. During this period, the coordinator and the routers build decoding tables based on packets received from their children that contain the list of the overheard links for every device. For example, consider the device number 18 in Figure 1. At the end of its association with the router 𝑅 8 , 18 knows that he can overhear packets transmitted from the routers 𝑅 1 , 𝑅 7 and from the devices 17, 19 and 23 thanks to the signalization messages that have been exchanged since the initialization of the network. Node 18 will then send to 𝑅 8 a special packet with the addresses of 𝑅 1 , 𝑅 7 , 17, 19 and 23' indicating that it can overhear their packets. Note that this operation takes place only after the nodes' association with their parents, and thus does not imply a large overhead on the network traffic.

C. Packet Encoding

Knowing that intermediate nodes in the network are necessarily routers or the coordinator since ZigBee is based on a cluster-tree topology, we assume that network coding decisions are exclusively performed at intermediate nodes before any transmission.

Let us consider a node 𝐴 that receives 𝑁 packets in 𝑄 𝑖𝑛 𝐴 from its neighborhood and has to forward them to 𝑀 other nodes. Whenever a packet 𝑝 from 𝑄 𝑖𝑛 𝐴 has to be transmitted to its next-hop 𝐵, the node 𝐴 chooses from 𝑄 𝑖𝑛 𝐴 depending on the coding strategy, packets that are supposed to be already overheard or received by 𝐵 (side-packets) and XORs them with 𝑝 into one coded packet that will be encapsulated in a special 802.15.4 CoZi frame (cf. Figure 4). The side-packets' identifiers are then listed into the special MAC footer field to allow packet decoding (c Figure 4). This operation will allow neighboring nodes to receive new packets without any additional transmissions. Note that the size of the coded packets identifiers field is at most equivalent to 𝑀𝐶𝑃 (Maximum Coded Packets) which represents the maximum number of packet that a node can XOR together.

D. Packet Decoding

When a node 𝐴 receives or overhears a coded packet 𝑝, it checks the coded packet IDs field of its containing frame to verify if it has already all the corresponding packets to decode it in 𝑄 ovh 𝐴 and 𝑄 in (𝐴). If it is the case, the node XORs 𝑝 with all the corresponding packets to retrieve the original 𝑝 𝑑𝑒𝑐 .

After this operation, 𝐴 verifies the destination address field of the decoded packet (cf. Figure 5). If it is destined to him, 𝐴 sends an 𝐴𝐶𝐾 message 3 to acknowledge the decoding and the reception of 𝑝 𝑑𝑒𝑐 . If because of a link failure 𝐴 happens not to have overheard a packet necessary to decode 𝑝 and 𝑝 is destined to him, the decoding operation will obviously fail and a retransmission of 𝑝 𝑑𝑒𝑐 might be needed potentially encoded with a new set of packets.

E. Coding Strategies

Data-delivery schemes can notably vary depending on the application, the environment and the characteristics of the network, particularly in wireless sensor networks. In this work, we propose two code selection mechanisms for CoZi in order to take advantage of routing-based and disseminationbased ZigBee sensor network and thus ensure better bandwidth utilization. 3 We make use of the asynchronous ACK mechanism proposed in [START_REF] Katti | XORs in the air: Practical network coding[END_REF]. In a disseminationbased scenario, data packets have to be transmitted from one source node to the entire network. In this case, our code selection mechanism chooses between all the packets in 𝑄 𝑖𝑛 (𝐴) so that a maximum of neighbor nodes can decode the coded packet regardless of the packet order in the queue.

2) CoZi for routing-based WSNs: In a routed WSN, data packets are sent from one source to a destination both designated by their network addresses. In such a scenario, intermediate nodes have to encode a packet so that the nexthop is assured to decode it. The set of coding opportunities in this case is more restricted than in a dissemination scheme.

For the sake of clarity and to illustrate our code selection mechanism, we consider a canonical example of four nodes 𝐴, 𝐵, 𝐶, 𝐷 with the following queues configuration:

Q in 𝐴 = 𝑝 1 , 𝑝 2 , 𝑝 3 , 𝑝 4 Q ovh 𝐵 = 𝑝 1 , 𝑝 4 Q ovh 𝐶 = 𝑝 1 Q ovh 𝐷 = 𝑝 3
In a dissemination based network where the information has to be transmitted from 𝐴 to a maximum number of nodes, it is more efficient to transmit 𝑝, with 𝑝 = 𝑝 3 ⊕ 𝑝 1 , rather than 𝑝′ for instance (with 𝑝′ = 𝑝 1 ⊕ 𝑝 2 ). Indeed, by sending 𝑝, 𝐴 allows 𝐵, 𝐶 and 𝐷 to decode 𝑝 (𝐵, 𝐶 can retrieve 𝑝 3 , and 𝐷 retrieves 𝑝 1 ) while by sending 𝑝′ only 𝐵 and 𝐶 can decode it.

On the other hand, if we consider a routing-based network, our algorithm will be constrained by the fact that the destination has to be able to decode the packet. For example, if 𝐴 has to transmit 𝑝 2 to 𝐶, the CoZi has to guarantee that 𝐶 will be able to retrieve 𝑝 2 . Thus, the selected code will be 𝑝" instead of 𝑝, with 𝑝" = 𝑝 1 ⊕ 𝑝 2 . Note that in this case, only 𝐵 and 𝐶 are able to decode 𝑝", since 𝐷 does not have neither 𝑝 1 nor 𝑝 2 to perform the decoding.

V. PERFORMANCE EVALUATION

In this section, we evaluate the performance of CoZi in different data-delivery scenarios with two different network densities to quantify the network throughput, the data transmission reliability and the end-to-end delay. Then, we compare the results with the classical ZigBee routing.

A. Simulation environment

We use the Qualnet 4.5 simulation environment [7] to assess our solution, where the ZigBee and 802.15.4 protocols are fully implemented. We consider 50 and 100 nodes uniformly placed in a 100𝑚 × 100𝑚 square area. The coordinator is placed in the center of the network and the rest of the nodes are either routers or end-devices. To implement CoZi, we modified the packet scheduling module of ZigBee and added our specific control and data frames to the 802.15.4 MAC of the simulation platform. Moreover, we developed an extension feature for Qualnet that picks randomly sources and destinations for end-to-end CBR (constant bit-rate) communications. The complete simulation attributes are presented in Table 1.

B. Throughput

First, we compute the throughput versus the traffic load for the network with 50 and 100 nodes. Figure 6 shows that the achieved throughput remains stable (80-95%) using CoZi, while it drastically decreases when ZigBee routing is used, confirming that CoZi enhances significantly the network throughput in a routed data-delivery scenario, especially at high traffic loads where coding opportunities are more frequent.

C. Convergence Time

The throughput is also improved in the dissemination-based scenario, reducing considerably the convergence time of the data-propagation. In fact, we can see from Figure 7 that the throughput in this case is slightly higher than in the routing scenario due to the larger coding possibilities inherent to dissemination-based networks as discussed in section IV.E. Moreover, we notice that the coding efficiency increases as the density of the network grows in both scenarios, i.e., when nodes overhears more packets within their neighborhood.

D. Delay

To assess the end-to-end delay of communications, a constant traffic load of 8 packets per second is applied to routes between randomly selected end-devices across the network. We assume each router has to forward packets to their destinations using routes with a definite path length. Then, we compute the average latency of each end-to-end communications. The result of the experiment is plotted in Figure 8 (the number of nodes in this case is 100) and confirms the benefit of using CoZi for delay constrained applications. Indeed, thanks to overhearing and one-hop coding, nodes can receive packets sooner than in a ZigBee classical routing, which shortens certain routes and thus provides a substantial reduction of the latency within the network. We can conclude from these experiments that CoZi can be very efficient and convenient for large scale, relatively dense and delay constrained ZigBee-based sensor networks.

VI. CONCLUSION & FUTURE WORK

Nodes in ZigBee sensor networks do not exploit the shared nature of the wireless medium, whether for routing or dissemination data-delivery schemes. This paper presents CoZi, a distributed packet scheduling based on simple network coding at intermediate nodes to offer better bandwidth utilization and more reliable communications with extremely negligible network overhead. Using clever topology inferring from ZigBee signalization messages, our solution helps to perform more optimized coding decisions in order to allow a larger range of decoding nodes whether for routed or dissemination based ZigBee sensor networks. Simulation results show that by using our enhancements, the network throughput and reliability are improved and the end-to-end delay reduced.

Other issues of interest have emerged while working on this solution. In fact, our future work will extend CoZi to include sleep-awake mechanisms for better energy efficiency and will focus on the implementation of our extension in an experimental ZigBee-based WSN platform.

Fig. 1 -

 1 Fig. 1 -ZigBee network topology illustration

Fig. 3 -

 3 Fig. 3 -CoZi queuing system illustration

Fig. 4 -

 4 Fig. 4 -CoZi data-frame and coded ZigBee packet scheme

Fig. 6 -

 6 Fig. 6 -Throughput versus traffic load with various nodes densities

Fig. 7 -

 7 Fig. 7 -Data-delivery completion ratio versus time

Fig. 8 -

 8 Fig. 8 -Latency versus path-length

  by Katti et al. for the IEEE 802.11 MAC.from line 9 to 15 in Algorithm 1. Finally, if 𝐴 is not able to decode 𝑝, it simply drops it from 𝑄 𝑖𝑛 (𝐴).

		Algorithm 1 Packet Reception at an Intermediate Node 𝐴
	1: for each incoming packet 𝑝 in 𝑄 𝑖𝑛 (𝐴) do
	2:	if 𝑝 is non-coded then
	3:	if 𝑝 is destined to 𝐴 then
	4:	𝐴 sends an 𝐴𝐶𝐾 to the sender
	5:	else /* 𝐴 overheard 𝑝 */
	6:	𝑝 is stored in 𝑄 𝑜𝑣ℎ (𝐴)
	7:	end if
	8:	else /* 𝑝 is coded */
	9:	if 𝑝 is decodable then
	10:	𝑝 𝑑𝑒𝑐 = 𝐷𝑒𝑐𝑜𝑑𝑒(𝑝)
	11:	if 𝑝 𝑑𝑒𝑐 is destined to 𝐴 then
	12:	𝐴 sends an 𝐴𝐶𝐾 to the sender
	13:	else /* 𝐴 overheard 𝑝 */
	14:	𝑝 𝑑𝑒𝑐 is stored in 𝑄 𝑜𝑣ℎ (𝐴)
	15:	end if
	16:	else /* 𝑝 is not decodable */
	17:	𝑝 is dropped from 𝑄 𝑖𝑛 (𝐴)
	18:	end if
	19:	end if
	20: end for

TABLE I

 I

	-SIMULATION SETTINGS
	Simulation time	600 𝑠
	Mobility model	𝑁𝑜𝑛𝑒
	Routing protocol	ZigBee cluster-tree
	MAC protocol	802.15.4
	Reflection model	Two-ray ground
	Propagation model	Lognormal shadowing
	Capacityy	250 𝑘𝑏𝑝𝑠
	Trans. rang.	~35 𝑚
	MCP (Maximum number of coded packets)	5
	Overhearing buffering period	500𝑚𝑠
	Packet size	116 Bytes
	Promiscuous mode	Activated
	Traffic nature	Constant Bit-Rate
	Beacon Order (BO)	15
	Super Frame Order (SO)	15
	Number of router	80%
	Number of end-devices	19%
	Beacon mode	Disabled


Zaher Mahfouz
email: zaher.mahfouz@orange-ftgroup.com

Azeddine Gati
email: azeddine.gati@orange-ftgroup.com

David Lautru
email: david.lautru@upmc.fr

Joe Wiart
email: joe.wiart@orange-ftgroup.com

Victor Fouad Hanna
email: victor.fouad_hanna@upmc.fr

Assessment of the Real Life Exposure to 2G and 3G Base Stations Over a Day from Instantaneous Measurement

In this paper, the general public daily exposure to mobile telephony is investigated. The considered signals are GSM900, GSM1800, UMTS and HSDPA. The study focus on the assessment of the maximal real electric field received over the day from an instantaneous measurement performed any time during the day. An extrapolation factor is presented to extrapolate an instantaneous measurement for any signal to the maximal possible value received by this signal over the day. This factor is also given to extrapolate the total electric field received to his possible maximum value over the day.

Introduction

The effect mobile phone radiation has on human health is the subject of recent interest and study due to the enormous increase in mobile phone usage throughout the world. Limits of electromagnetic field exposure are defined by the International Commission on Non ionizing Radiation Protection (ICNIRP) [START_REF]Guidelines for limiting exposure to timevarying electric, magnetic, and electromagnetic fields (up 300 GHz)[END_REF] and standards are available to check the compliance to these limits such as those given by the Institute of Electronics and Electrical Engineers (IEEE) [START_REF]for Safety Levels with Respect to Human Exposure to Radiofrequency Electromagnetic Fields, 3 KHz to 300 GHz[END_REF], FCC [START_REF]Evaluating compliance with FCC guidelines for human exposure to radiofrequency electromagnetic fields[END_REF] and CENELEC [START_REF]European Committee for Electrotechnical Standardisation TC 106x WG1 EN 50492[END_REF]. International standards used to check the compliance of radio communications equipments to the exposure limits are based on a worst case approach to guaranty a conservative assessment. This approach takes the worst case of a base station transmission that mean a full traffic situation is achieved in this case, it doesn't take also into consideration the fluctuation induced by the different services especially the temporal variation of the different signals. In [START_REF] Joseph | In-situ measurement procedures for temporal RF electromagnetic field exposure of the general public[END_REF][START_REF] Mahfouz | Statistical Analysis of Real Radiofrequencies Exposure in a Realistic Environment[END_REF] the real exposure facing the time variation of emissions has been investigated, it was shown that a full traffic situation is never reached in reality and that the FM signal remains constant over the day contrariwise to GSM and UMTS signals where the field variation are higher during daytime than at night because of the traffic demand. HSDPA (High Speed Downlink Packet Access) provides an evolutionary path for Universal Mobile Telecommunications System (UMTS) networks allowing for higher data capacity. It is an evolution of the W-CDMA standard designed to increase the available data rate by a factor of 5 or more. Therefore, a new channel called the high speed downlink shared channel is used for downlink communication to the mobile. The temporal variation of the different carriers over one day for UMTS and HSDPA is representing in this paper. The purpose of this paper is to characterize statically the maximum and daily exposures in real conditions induced by GSM900, GSM1800, UMTS and HSDPA networks. An extrapolation factor is presented to extrapolate an instantaneous measurement to the maximal possible value over the day. This factor is given to extrapolate the electric field received from a single system and also from all the systems together.

Assessment of the Maximal Electric Field

Measurements

Automatic measurements of all bands (GSM900 and GSM1800) and all operators (three operators in France) have been performed using special software developed in FT Orange Labs. Twenty measurements in nine different sites in urban areas have been performed every 10s (time sampling) for GSM900 and GSM1800 over a day.

Two operating systems, UMTS (3GPP R99) and HSDPA are considered that are operating in the 2.2 GHz band. They are very similar in terms of signal characteristics and radio access interface. In HSDPA, a new channel is integrated for downlink communication to the mobile to increase the available date rate. The main difference between them is the power allocation. In fact, in HSDPA systems, all the power is affected to a single User Equipment (UE) at each time. We should use a W-CDMA decoder to perform measurements for these two systems to extract the total power and also the allocated power to each channel which is not possible with a spectrum analyzer. Eight measurements for UMTS and twelve measurements for HSDPA in five different sites in urban zones in France have been performed every 6s. Each of these measurements results in a total of 15000 measured samples per carrier per day.

Traffic Variation in 3G Technology

In practice, the extrapolation to a worst case induced by the International Standards is based on the measurement of the P CPICH (pilot power) which corresponds to the signalization and on the value of N CPICH (number of traffic) which corresponds to a maximum theoretical value deployed by operators. In [7-8] it has assumed for N CPICH the value of 10 in UMTS Network, it is the maximum possible value (full traffic) that UMTS can have. There is no value yet assumed for HSDPA Network. So far, no one assumed the N CPICH in HSDPA Network, because when the study for UMTS has done (2005), the HSDPA network was not yet deployed. Therefore, today the value of 10 has taken for both systems (UMTS and HSDPA). The real exposure which is quantify by the real equivalent N CPICH active over one day for UMTS and HSDPA is compared to the maximum theoretical value. Fig. 1 shows the temporal variation of the different carriers over one day for UMTS and HSDPA of one operator, it represents the N CPICH which is defined as the ratio between the total powers received (called P r ) and the allocated power (called P CPICH ). We observe that the variation of HSDPA is very high compared to UMTS. In fact, in HSDPA systems, all the power is affected to a single User Equipment (UE) at each time. UMTS represents most of time the voice while HSDPA represents the data. This Fig. 1 shows that in the night there is communications only for HSDPA Networks contrary to UMTS where we can find a very low traffic, same behaviors as GSM and DCS Networks where the traffic is very low during the night. Therefore, in the night, people use data more than voice especially around 1am. The different measurements proof that the maximal N CPICH (at 99%) in a realistic environment is about 5 for UMTS and 14 for HSDPA. These results show that a full traffic situation is never reached in UMTS systems contrary to HSDPA where a full traffic situation is possible especially during the rush hours and the realistic maximal value in HSDPA system exceeds the theoretical value. We mention here that the theoretical value for HSDPA has never been assumed so that we took the same theoretical value as UMTS. As for GSM900 and GSM1800 [START_REF] Mahfouz | Traffic Analysis for Exposure Assessment in Mobile Telephony[END_REF], the theoretical value (NTRX=8 in case of GSM) overestimates also the maximal real value (NTRX=4 in case of GSM) for UMTS systems. The results confirm that the temporal variation and the power received in HSDPA system are very high compared to UMTS. Moreover, the power received with the use of data is higher than the power received with the use of voice because in case of data, all the power is affected to the user at each time. The results show that the equivalent TRX maximal in GSM system is equal to 2.70 [START_REF] Mahfouz | Traffic Analysis for Exposure Assessment in Mobile Telephony[END_REF] and the equivalent CPICH maximal is 4.80 for UMTS and 10.2 for HSDPA with a sliding time average of 6min applied on the measurements.

Assessment of the Maximal from an Instantaneous Measurement

We can now extrapolate an instantaneous measurement to the maximal real value by performing a measurement only for BCCH/CPICH and use the values of equivalent TRX/CPICH for the different systems. However, in practice, the measurement is not performed only for BCCH/CPICH, but also for the entire GSM/UMTS band. Therefore, we are interested to extrapolate an instantaneous measurement E(t) for all the band performed during the day to the maximal value. Fig. 2 shows the cumulative distribution function (CDF) for GSM900, GSM1800, UMTS, HSDPA systems and the sum of these signals (total) in urban areas, it represents the CDF for an extrapolation factor which is defined as E max /E(t) with a sliding time average of 6min applied on the measurements. We observe that the extrapolation factor 1.5 is conservative for a measurement of GSM900, GSM1800 or UMTS while the factor 1.9 is conservative for a measurement of HSDPA. Therefore, the factor 1.9 is conservative for all the systems. The extrapolation factor for the electric field total received is 1.7 for the entire band with all the signals. The extrapolation factor is given for different period of the day in Fig. 3 for the different systems. The extrapolation factor 1.2 is conservative for a measurement of GSM900, GSM1800 or UMTS performing any time during the working day (10am-10pm) while the factor 1.5 is conservative for a measurement of HSDPA.

Conclusion

Real life exposure to 3G base stations of the general public in environment during a period of one day is investigated in this paper. The field variation in UMTS and HSDPA systems are higher during daytime than at night due to the traffic demand. Moreover, the temporal variation of HSDPA is very high compared to UMTS and a full traffic situation can be achieved in HSDPA systems contrary to UMTS systems where a full traffic situation is never reached in reality.

The instantaneous measurement E(t) with a sliding time average of 6min for GSM900, GSM1800, UMTS and HSDPA should be multiplied by 1.9 and the total electric field received Etotal(t) with a sliding time average of 6min should be multiplied by 1.7 to be conservative. This work is of interest for elaborating standards of exposure based on measurements in operating systems to assess the real exposure to cellular networks.

Figure 1 .

 1 Figure 1. Temporal variation over 24h of the Pr/CPICHs for UMTS and HSDPA (dotted line)

Figure 2 .

 2 Figure 2. Extrapolation factor of the electric field E of the different signals and the Etotal (dotted line) with a sliding time average of 6min

Figure 3 .

 3 Figure 3. Extrapolation factor for GSM900, GSM1800, UMTS and HSDPA measurement performed any time during the day

Acknowledgments

This research is supported by the ANR MULTIPASS PROJECT.


Zaher Mahfouz
email: zaher.mahfouz@orange-ftgroup.com

Azeddine Gati
email: azeddine.gati@orange-ftgroup.com

Member IEEE David Lautru
email: david.lautru@upmc.fr

Member IEEE Joe Wiart
email: joe.wiart@orange-ftgroup.com

Senior Member IEEE Victor Fouad Hanna
email: victor.fouad_hanna@upmc.fr

SAR Assessment and Analysis of Cumulative Body Exposure to Multi Transmitters from a Mobile Phone

Keywords: SAR, Multiple exposure, Radiofrequency

This paper presents results for the Specific Absorption Rate (SAR) when using a mobile phone equipped with a multiple antenna system. The SAR is evaluated using the Finite Difference Time Domain (FDTD) method for different configurations taking into account all possible simultaneous transmission from a mobile phone. The considered signals are GSM900, GSM1800, UMTS2100 and WiFi2400. The results show that the calculated local SAR for the different configurations never exceeds the limit of 2 W/Kg recommended by ICNIRP. It was demonstrated also that the maximum of the sum of the SAR evaluated from two different transmitters is always less than the sum of the maximum evaluated ones from each transmitter separately.

I. INTRODUCTION

Increasing use of wireless devices continues to generate concern about potential health effects on humans. Basic restrictions of electromagnetic field exposure have been established by the International Commission on Non Ionizing Radiation Protection (ICNIRP) [START_REF]Guidelines for limiting exposure to timevarying electric, magnetic, and electromagnetic fields (up 300 GHz)[END_REF] and the Institute of Electronics and Electrical Engineers (IEEE) [START_REF]for Safety Levels with Respect to Human Exposure to Radiofrequency Electromagnetic Fields, 3 KHz to 300 GHz[END_REF] and followed by technical standardization bodies like CENELEC [START_REF]European Committee for Electrotechnical Standardisation TC 106x WG1 EN 50492[END_REF] to protect the public against possible negative health effects of radiofrequency electromagnetic radiation. Basic restriction is verified by performing specific absorptions rate (SAR) evaluation. The basic restriction was set by ICNIRP to a maximum value of 2 W/Kg for the SAR averaged over 10g (SAR10g). Not all standards and guidelines throughout the world have recommended the same limits for exposure. However, published exposure limits by ICNIRP are the same in North America and in some parts of Europe (for example in France). Exposure from multiple EM sources is quite common, particularly in the case of simultaneous exposure from multiple broadcast and cellular infrastructure transmitters. In fact, the body exposure to RF depends on the characteristics of the signal and on the environment. The different systems operate with different protocols in different frequency bands. Therefore, humans are exposed to various types of radio emissions. Each signal has its proper behavior (transmitted power, power control, data rate, bandwidth, modulations, duty cycle, transmission…) and its access mode like Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA) and Code Division Multiple Access (CDMA). Over the last few years combined data and voice communication systems have been deployed. There is also a growing number of personal communication devices that allow simultaneous transmission over multiple air-interfaces while being operated near the user's body. The smart phones can be used to transmit voice and data at the same time. They contain multiple transmitters operating at widely spaced frequencies. The emissions from these uncorrelated sources with a wide frequency separation have to be combined. A mobile phone equipped with a multiple antenna system has been investigated in [START_REF] Baldauf | Mobile MIMO Phones and Their Human Exposure to Electromagnetic Fields[END_REF]. It was demonstrated that using MIMO techniques at the transmitter allows a reduction of the exposure by some 95%. This technique uses multiple antennas emitted at the same frequency band. In this case the sources are correlated. In this paper, the SAR is evaluated for different configurations taking into account all possible uncorrelated simultaneous transmission operating at widely spaced frequencies from a mobile phone using the Finite Difference Time Domain (FDTD) techniques.

II. SAR CALCULATIONS

A. Source Model

In this study, a phone model (Fig. 1) having two antennas is used. Some representative phone mobile models are proposed in [START_REF] Pinto | Numerical Mobile phone models validated by SAR measurements[END_REF]. The models were validated in presence of the body by SAR distribution experimental measurements. One of the mobile phone models [START_REF] Pinto | Numerical Mobile phone models validated by SAR measurements[END_REF] proposed with an antenna on the top of the mobile is selected for this study. This top antenna is adapted for different frequency bands, GSM bands (900 MHz and 1800 MHz) and UMTS band (2100 MHz). A second antenna on the bottom is adapted for Wi-Fi frequency band (2400 MHz). The cell phone is modeled using patch antennas. The representative model consists of the casing, the frame, the screen, the Printed Circuit Board (PCB), the two patch antennas and the battery (Fig ( 1.b)). The casing, the frame and the screen are modeled as a plastic material. The PCB is implemented as a metallic plaque having standard PCB dimensions. The screen is considered as a plastic material with a back metal plaque, and the battery is considered as a metallic box with a plastic cover.

B. FDTD and SAR

The SAR is evaluated in a liquid tissue (Fig. 2) (plane phantom). The permittivity and conductivity of simulated liquid representing human tissues and prepared for SAR evaluation are appropriate for the device operating frequencies [6]. A liquid tissue is used and not a head model in simulations to simplify and to easy compares the different configurations. For each transmitter, the permittivity and conductivity of simulated liquid tissue are selected according to the frequency of the source. The Finite Difference the Time Domain (FDTD) method is used to evaluate the SAR. A rectangular computational grid, based on the Yee cell has been employed, using the well known leap frog scheme, with a spatial resolution of 1 mm and the PML absorbing boundary conditions to avoid spurious reflections at the boundary of the limited computational domain. The SAR is defined as:

III. SAR EVALUATION

A. One transmitter

The GSM is based on the TDMA technique. This technique allows eight users to share the same frequency band. By this way, a mobile emits (or receives) only for one eighths of the communication time. With a constant peak output power of 2 W, the mean power is equal to 0.250 W. Updated standard coming from the European Telecommunication Standard Institute (ETSI) [START_REF]ETSI Document, GSM 5.05 version 5.10[END_REF] defines 15 levels of PWC for GSM900 handsets (from 33 to 5 dBm) and GSM1800 (from 30 to 2 dBm). The different peak power values used for the different services are given in Table I. The maximum SAR averaged over 10g of tissue for the different services are also given in Table I, while Fig. 3 shows the distribution of the SAR for the different transmitters. The values of the maximum SAR averaged over 10g of tissue depend strongly on the peak power. Therefore, the maximum obtained value is for GSM900 which is high compared to values for other services. The distribution of the SAR depends on the frequency, i.e., firstly that the distributions are different for the different services utilizing separate frequencies, and secondly that the calculated maximum SAR averaged over 10g of tissue depend also on the frequency and on the placement of the antenna.

TABLE I SAR10G MAXIMUM AND PEAK POWER FOR THE DIFFERENT TRANSMITTERS

B. Two transmitters

The smart phones contain multiple transmitters operating at widely spaced frequencies. User can use Wi-Fi or send a Multimedia Message Service (MMS) while making a call. In this case, user is exposed to electromagnetic field emitted by different services at the same time. In this section, the SAR is evaluated for different configurations taking all possible real combinations of the transmitters. Note that the two different antennas are located at the top and at the bottom of the mobile as in the real case. The top antenna is used for GSM900 and UMTS2100, it can be noticed that if it is possible in the real case to use GSM900 and UMTS2100 at the same time, the maximum SAR averaged over 10g of tissue for each service will be localized very close to each other and the combined SAR value will be very high.

The results show that the calculated local SAR10g for the different combinations for the considered mobile never exceeds the limit of 2 W/Kg given by ICNIRP. The SAR10g is given for the different configurations in Table II. Moreover, it was confirmed that the maximum of the sum of the SAR10g evaluated from two different transmitters never reaches the sum of the maximum values evaluated from each transmitter separately.

∑ ∑

≤ n i n i SAR Max SAR Max 1 1 ) ( ) ( (3)
This result was expected as the exposure from a transmitter depends on the frequency i.e. depend on the thickness of the tissue. The two antennas are not located in the same place. Therefore the distribution of the SAR and the location of the maximal value obtained for a service is not the same like that for another service which emits at different frequency. Fig. 4 shows the distribution of the SAR for different combinations (GSM900 Wi-Fi2400, GSM1800 Wi-Fi and UMTS2100 Wi-Fi2400). All the values of the SAR for each combination are normalized to their maximum. The maximum SAR averaged over 10g of tissue for the different studied combinations are given in Table II. The sums of the maximum of SAR10g (given in Table I) for the different combinations are presented also in Table II.

IV. CONCLUSION SAR evaluation for different simultaneous transmission from a mobile phone using the Finite Difference Time Domain (FDTD) techniques is investigated in this paper. The main conclusion is that the calculated local SAR for the different configurations never exceeds the limit of 2 W/Kg given by ICNIRP. It worths mentioning that our results have been obtained with the two antennas located at the top and at the bottom of the mobile as in the real case. It was confirmed also that the maximum of the sum of the SAR evaluated from two different transmitters never reaches the sum of the maximum evaluated for each transmitter separately as the exposure depends on the frequency and hence on the thickness of the tissue layers and on the location of the antenna. This study will be continued to evaluate the SAR for correlated sources (MIMO) with a mobile phone using multiple antennas which emit at the same frequency band.

Service

Peak power (mw)

Fig. 1 .

 1 Fig. 1. Phone Model: commercial model (1.a), representative phone cross sections(1.b)

Fig. 2 .

 2 Fig. 2. Mobile phone with the liquid (plan phantom) where the SAR should be evaluated Where σ, ρ and E represent the conductivity of body tissue (S/m), the mass density of the tissue (kg/m 3 ) and the peak electric field in tissues (V/m) respectively. A mobile phone equipped with Wi-Fi connection allows simultaneous GSM and Wi-Fi transmission. GSM and Wi-Fi operate on different frequency bands, i.e., the two signals are uncorrelated, and hence the SAR distributions can be summed. This is not true for correlated signals which emit at the same frequency as in the case of MIMO systems. In most cases, multiple transmitters in portable wireless communicators operate in distinct frequency bands so the overall exposure can be determined by summing the corresponding SAR distributions. Technical report IEC 62630 [7] provides generic guidance on how to assess the exposure to multiple RF sources. The SAR evaluated for n uncorrelated sources (named SAR total ) is the sum of the SAR for each of the n sources: ∑ =

Fig. 3 .

 3 Fig. 3. Distribution of the SAR : GSM900(top left), GSM1800 (top right), UMTS2100 (bottom left), Wi-Fi (bottom right). All the values of the SAR for each figure are normalized to their maximum.

Fig. 4 .

 4 Fig. 4. SAR Distribution for two services : GSM900 + Wi-Fi (top left), GSM1800 + Wi-Fi (top right), UMTS2100 + Wi-Fi2400 (bottom), All the values of the SAR for each figure are normalized to its maximum.


Sylvain Cherrier

Yacine M Ghamri-Doudane

Stéphane Lohier

Gilles Roussel

D-LITe : Distributed Logic for Internet of Things sErvices

Keywords: Web of Things, Services Choreography Architecture, Distributed logic

Smartphones, PDA, Sensors, Actuators, Phidgets and Smart Objects (i.e. objects with processing and networking capabilities) are more and more present in everyday's life. Merging all these technologies with the Internet is often described as 'Internet of Things' (IoT). In the IoT vision, Things around us provide a pervasive network of interacting and interconnected devices. However building IoT applications is a long and arduous work, reserved for specialists, requiring specific knowledges in terms of network protocols and programming languages. The lack of widespread and easy-to-configure solutions is an obstacle for the development of this area. A universal framework, offering simplification and standardization, could facilitate the emergence of this promising field in terms of applications and business. IoT needs a solid foundation for rapid, simple development and deployment of new services. In this paper, we present D-LITe, a universal framework for building IoT applications over heterogeneous sets of small devices. D-LITe offers solutions for deploying application's logic, and executing it on Smart Objects despite their heterogeneity. An implementation of D-LITe on tiny devices, such as TelosB motes, allows to show that our framework is realistic even with the constraints of such devices.

I. INTRODUCTION

Objects become more and more clever and interacting devices. Manufacturers introduce processing power and networking technologies in common objects leading to the concept of Smart Objects and to IoT or Web of Things (WoT is the web version of IoT, easier to use for end-users). In this paradigm, Things offer a digital environment, sensing and acting on real world. Users are able to deal with their digital environment. "Home automation" is an example of IoT, in which people organize services offered by things present in their living environment. But there is a main issue that still prevents the raise and wide deployment of IoT: The multitude of Smart Objects (such as Sensors) uses different languages (C, NesC, Java...), different Application Programming Interfaces (Arduino, ZigBee Application...), different Operating Systems (TinyOS, Contiki...) through different network protocol stacks (IEEE 802.15.4, Zigbee, 6LowPAN) that may be mutually incompatible unlike the widely spread IP Network used by more powerful objects. Creating an application dealing with each kind of smart objects becomes a specific work, performed for a specific type of hardware (Operating System, Network technology) and with specific programming tools (languages, API). It involves the need of a gateway to be accessed from the Internet and to communicate with other objects. Another issue is the deployment of applications, mainly consisting of ROM flashing on each smart object, that requires human intervention and manipulation. This leads to important time and cost overhead. Creating IoT applications is complex and time-consuming, hardware dependant, and hardly scalable. In this paper we intend to solve these problems by proposing a universal framework and architecture: D-LITe, a new Distributed Logic for Internet of Things sErvices creation and deployment. D-LITe allows to design simple, scalable and easy-to-maintain applications and deploys them over heterogeneous platforms. The reminder of this paper is organized as follows: First, we present the related works (Section II) and the background (Section III) attached to our solution. The overall design of D-LITe is described in Section IV, while Section V focuses on the protocols and languages used by D-LITe. Section VI deals with the Implementation and Validation of D-LITe. Finally, concluding remarks and future research directions are given.

II. RELATED WORKS

Internet of Things has many definitions [START_REF] Atzori | The internet of things: A survey[END_REF]. The IoT paradigm incorporates other technologies such as pervasive or ubiquitous computing as well as ambient intelligence (AmI) [START_REF] Augusto | Ambient intelligence: The confluence of ubiquitous/pervasive computing and artificial intelligence[END_REF], [START_REF] Cook | Ambient intelligence: Technologies, applications, and opportunities[END_REF]. To realize IoT applications, programmers or users have to deal with multiple devices that are not interoperable. There are many approaches on how to program such network applications. We consider macro programming as described in [START_REF] Hadim | Middleware: Middleware challenges and approaches for wireless sensor networks[END_REF] "programming the sensor network as a whole, rather than writing low-level software to drive individual nodes". Many objects that think come with processing capabilities, but no code to use it. "for years, closed networks" were "deployed for a specific application... we argue that the next generation WSN require customizable architecture" [START_REF] Rezgui | Service-oriented sensoractuator networks: Promises, challenges, and the road ahead[END_REF]. Giving every node the ability to interact with any other seems to be a solid basis for building distributed applications. Authors in [START_REF] Rezgui | Service-oriented sensoractuator networks: Promises, challenges, and the road ahead[END_REF] propose to give standard access to nodes to offer such a customizable architecture. Every node in IoT applications should be reachable and usable. However no common architecture is provided. ZigBee Alliance [START_REF]Zigbee alliance[END_REF] has developed adequate protocols for Sensors. ZigBee is a complete solution, based on the use of the IEEE 802.15.4 at the lower layer. It defines the reminder of the network architecture up to services (called ZigBee Profiles). For example, ZigBee Home Automation is one of those Profiles "enabling smart homes that can control appliances, lighting, environment, energy management, and security as well as expand to connect with other ZigBee network" [START_REF]Zigbee profiles[END_REF]. Nevertheless many technologies (SmartPhone, PC, sensors, actuators...) are involved in Home Automation so that a gateway is mandatory to connect to other networks (Internet). An end-to-end communication could be degraded by such a gateway. Protocol's conduct, exchanges between nodes, the size of exchanged messages can be so different that their translation may be particularly difficult. The specialized protocol's dynamics on one side may be unsuitable for the other side. All these differences can be difficult to solve, or just very penalizing in terms of adaptation, effectiveness, and response time. Dynamicity, scalability and reconfiguration are also issues. Users may want to use the computing capabilities of smart objects and take advantage of the versatility of programmable devices. Changing the interactions of household objects when integrating a new device, or simply changing the behaviour of the total application is an expected asset of the IoT. Until now human interventions are still required to set and update nodes. Reprogramming "over the air" (OAP, Over the Air Protocol) answers that issue [START_REF] Wang | Reprogramming wireless sensor networks: challenges and approaches[END_REF]. OAP is proposed in SYNAPSE [START_REF] Rossi | SYNAPSE: A network reprogramming protocol for wireless sensor networks using fountain codes[END_REF], Deluge [START_REF] Hagedorn | Rateless deluge: Over-the-air programming of wireless sensor networks using random linear codes[END_REF] or Dynamic TinyOS [START_REF] Munawar | Dynamic TinyOS: Modular and Transparent Incremental Code-Updates for Sensor Networks[END_REF]. SYNAPSE and DELUGE mainly focus on how to organize a reliable transfer on a non-reliable wireless network, while Dynamic TinyOS deals with efficient software updating, but is strongly coupled with TinyOS Operating System. Our aim is to provide a solution loosely coupled to network protocol stack, operating system, language and hardware.

III. BACKGROUND AND VISION

Such as Generic Virtual Machine for a high-level programming language 1 , D-LITe constitutes a basic framework for building simple and universal applications. Many concepts of quite distant areas are melt in D-LITe to give the end-user a simple way to design and deploy logical applications on nodes. 1 JVM for Java, for example, or Parrot for Perl A. From Internet to Smart Objects D-LITe nodes need to be accessed from the Internet. IPv6 Protocol seems to be a good candidate for that purpose, because this standard is most likely to be used to deal with billions of nodes. By using header compression mechanisms, 6LowPAN [START_REF] Shelby | 6LoWPAN: The Wireless Embedded Internet[END_REF] proposes a solution for IPv6 compatibility over IEEE 802.15.4 networks. It gives universal access to data collected by sensors and actions done by actuators. Even if 6LowPAN is restricted to support only UDP, nodes are able to offer all kind of Web's well-known services because it uses IP. 6LowPAN turns motes from connected data collectors into real small data servers.

B. Accessing services : SOAP, REST and CoAP

In an end-to-end communication, motes can be considered as service providers. To access the provided services, Service Oriented Architecture (SOA) is a well-known solution [START_REF] Erl | Service-oriented architecture: concepts, technology, and design[END_REF]. The idea of using such paradigm for Sensor Network is presented in TinySOA [START_REF] Rezgui | Service-oriented sensoractuator networks: Promises, challenges, and the road ahead[END_REF]. SOA introduces loose coupling between services and applications as well as hardware independence. Many protocols realize SOA. One of them is SOAP [START_REF][END_REF], but it is a very verbose protocol (i.e. consuming bandwidth and requiring important processing). Sensors Networks have a very limited bandwidth, that is why D-LITe is organized according to REST approach. REST architecture [START_REF] Fielding | Principled design of the modern web architecture[END_REF] is an alternative to SOAP for distributed applications, and has many advantages. Using standard HTTP methods, REST is lightweight and simple to adapt to our purpose. However a major issue remains: because of smart objects' memory size, TCP and moreover HTTP (needed by REST architecture) are very hard to fit [START_REF] Atzori | The internet of things: A survey[END_REF] in constrained devices. To address this issue, CoAP [START_REF] Shelby | Embedded web services[END_REF] offers the same characteristics as REST: CoAP "extends the REST architecture to a suitable form for the most constrained nodes" of Sensors Network [START_REF] Shelby | Constrained application protocol (coap). An online version is[END_REF]. Furthermore, CoAP is build over 6LowPAN, and already exists in Contiki operating system [START_REF] Castellani | Architecture and protocols for the Internet of Things: A case study[END_REF] for Wireless Sensor Networks. By implementing HTTP over UDP, and using compression of HTTP methods, CoAP is designed to simply permit translations between standard and universal REST commands from the Internet and a 6LowPAN Network, while being particularly suitable to the limited payload of smart objects.

C. Services : Choreography and Orchestration

We consider that an important part of IoT applications can be designed as a collaboration between nodes. The whole application's logic can be spread into small autonomous part on each node. To combine services offered by motes (data collected or possible actions), SOA is divided in two approaches : Services Orchestration or Services Choreography [START_REF] Peltz | Web services orchestration and choreography[END_REF], [START_REF] Barros | Standards for web service choreography and orchestration: Status and perspectives[END_REF]. They mainly differ in the centralized approach of orchestration compared to the collaborative form of choreography. D-LITe uses the Choreography concept. In our Choreography, there is no central controller, each node is autonomous. The node knows what to do, and reacts to context's change. In D-LITe's choreography, each node is like a dancer. Each dancer knows his steps, and reacts on events of the very near environment. There is no centralized control of any supervisor ; decisions are mainly made at the lowest level. On the contrary, in the usual definition of services orchestration, a central point would control all exchanges. The central point would call the services offered by nodes and compute results. No nodes would act on its own. Because it uses choreography, D-LITe delegates small parts of the global application to each participant, using processing capacities closer to the needs, saving bandwith and therefore energy.

D. Designs Patterns used in D-LITe

D-LITe uses Gang of Four (GoF) [START_REF] Gamma | Design patterns[END_REF] Design Pattern (DP) Observer and Strategy. Some protocols propose Observer DP in Sensor Networks. Using such protocols, nodes can subscribe to others that publish data as in mqtt [START_REF] Hunkeler | Mqtts-a publish/subscribe protocol for wireless sensor networks[END_REF] or in TinyCops [START_REF] Hauer | A component framework for content-based publish/subscribe in sensor networks[END_REF]. However mqtt is not based on 6LowPAN but on Zigbee, and TinyCops is a TinyOS module. Consequently they are not usable in a heterogeneous environment. D-LITe implements this DP on its own. Strategy DP dynamically changes an object's behaviour. Basically, Strategy delegates one object's logic to another object, chosen inside a set of objects each implementing a different version of the same command. This can be managed and changed "on the fly". D-LITe is inspired by Strategy. D-LITe installs a static piece of code on each node. That code offers an access to a dynamic part of the application that can be configured or changed. This dynamic part is under the control of a rule analyzer. The rule analyzer can execute a logical description of node's expected behaviour depicted by a "set of rules". This logical description is variable, can be set through the network and dynamically changed.

E. Finite State Transducers (FST)

To describe our choreography, a tool to program each node is required. As presented in Section IV-C, we chose to use macro-programming approach shown for example in [START_REF] Sugihara | Programming models for sensor networks: A survey[END_REF], [START_REF] Mottola | Programming wireless sensor networks: Fundamental concepts and state of the art[END_REF]. D-LITe uses Finite State Transducers (FSTs) to describe the application's logic. Describing this logic with an Automaton rather than a programming language is somewhat limited, but has absolute advantages: universality, very low memory footprint for the parser, and very concise expression of the description. Automata are hardware independent, text-based, and easy to learn. FST are Finite State Machines (FSM) with an additional output Alphabet. They are often used in Natural Language Processing. In D-LITe, input and output alphabets are the messages exchanged by nodes through the network. States are the node's reaction to received messages. The idea of using a Transducer to program a sensor, and the rule's approach, were inspired by J. Baliosian and al papers [START_REF] Baliosian | Finite state transducers for policy evaluation and conflict resolution[END_REF], [START_REF] Baliosian | A rule-based distributed system for self-optimization of constrained devices[END_REF].

IV. D-LITE : AN ARCHITECTURE TO DEPLOY APPLICATION'S LOGIC

D-LITE is organized to enable the writing of small cooperating units realizing an application, like the cells of a spreadsheet are used in end-user development.

A. Overview of D-LITe Distributed Framework

D-LITe is a distributed framework for realizing IoT applications. It consists in building applications as a collaboration of smaller logical units. A mote2 is more than a simple sensor or actuator. Because of its small computing capabilities, this kind of node can do additional processing. For this purpose, D-LITe is installed on each node. As it uses standard protocols (IPv6 and REST), D-LITe offers a universal access, hiding specificity of the different hardwares used. The REST access given by D-LITe is used to deploy orders (configuration, FST) on each node. As shown in Figure 1: 1) An end-user collects information about nodes capabilities. 2) He expresses his need : he describes a sequence of interactions between elements. 3) This sequence is then transformed as a set of FSTs (one FST per node). 4) Each node will receive its own FST and other configuration information. The D-LITe architecture allows an end-user to transmit rules and configuration to each node. Each D-LITe enabled node contains a rules analyzer to execute the FST. D-LITe nodes also have a messaging service to interact with each other (Figure 2). 2. Each D-LITe node received its rules ; from now it is ready to execute them. A node obeys the FST's rules according to messages it receives from other nodes or from its own hardware (sensors). It changes state (that may impact the real world if it's an actuator) and sends messages to its observers. These will react to that message.

B. Distributed Application Choreography

D-LITe is based on the idea that Internet of Things applications can often be seen as a Finite State Machines choreography. D-LITe enables to depict each part of the application's logic as FSTs which will be executed in several nodes. Each FST (a set of rules) can be dynamically and quickly send to the proper node. An end-user has to organize his thoughts to describe his application as a choreography of Transducers, just like he organizes his formulas in each cell of a spreadsheet (Figure 1). When a node receives a message or changes state, it affects other nodes, just like cells in a spreadsheet react to changes in other cells; Updating their content results in a chain reaction on depending cells (Figure 2). As choreography starts, every node may receive a message, because something has happened. That message is inspected by the algorithm in charge of the FST's execution. If a rule matches the current state and this received message, the node's state changes, and the output message defined in the rule is sent to Observers.

C. Node's Logic Representation using Transducers

A Finite State Transducer has a formal representation as a 6-tuple T (Q, Σ, Γ, I, F, δ). D-LITe defines the meaning of each element as follow:

• Q represents all States for a particular node, • Σ are Input Messages handled by a particular node, • Γ are Output Messages a particular node can send, • I is the Initial State (only one in D-LITe),

• F stands for Final States, • δ contains transitions (which are our "set of rules"). ǫ element stands for empty. The main adaptation introduced in D-LITe is Input Messages and Output Messages in place 1) Example 1: a switch and a light: In the very simple example given in Figure 3, a switch (sensor) and a light (actuator) can be set this way: When the light receives a "up" message, it moves to "ON" state. When it receives a "down" message, it sets its state to "OFF". When somebody presses the switch button, its state moves to "Pressed", and it sends an "up" message. Similarly when somebody presses it again, it moves to "Released" state , and it sends a "down" message. The two FST representing this two nodes are:

• for the switch: Q = ("P ressed ′′ , "Released ′′ ), Σ = ("P ress ′′ , "Release ′′ ), Γ = ("up ′′ , "down ′′ ), I = ("Released ′′ ), F = (ǫ) and δ is described in Figure 3.

• For the light: Q = ("on ′′ , "of f ′′ ), Σ = ("up ′′ , "down ′′ ), Γ = (ǫ), I = ("of f ′′ ), F = (ǫ) and δ is described in Figure 3. This is the way an end-user can simply program a standard switch/light pair.

2) Example 2: Introducing a new state: Figure 4 introduces a new behaviour not planned in the process of light switching : a delay. Our application offers a Time service (a time message is send every 10 seconds). When receiving the "down" message, the light stays on, and waits for a "time" message from the Time service. On receiving this "time" message, the light switches off. To realize this feature, we introduce a logical state on the on/off light process : a Wait State. This state has no physical action but represents the fact that the light is now waiting for another message. This is a logical state. After receiving this time event, the light moves to the "Off" state, and really switches off. To implement this example, the switch FST remains unchanged. However, the light FST becomes : Q = ("on ′′ , "of f ′′ , "W aitState ′′ ), Σ = ("up ′′ , "down ′′ , "time ′′ ), Γ = (ǫ), I = ("of f ′′ ), F = (ǫ) and δ is described in Figure 4. We also add the light as an observer of Time service. 3) Example 3: a semantic loss: Figure 5 represents a 3-way (or more) switching. The user merely needs to define a single message (for example "action") to be sent by each switch when the button is used (vs. two messages in previous examples). No matter how the button is now (pressed or released), the light's state has to change. For this purpose, the user explains that "Press" or "Release" events on the switch send a unique message : "action" (a poor semantic message). There is no other state needed on the switch. The light subscribes to all switches, and each switch sends only "action" message when pressed or released. By receiving the "action" message, the light changes state from "on" to "off" and vice versa. The corresponding two FSTs are:

• For each switch: Q = ("N op ′′ ), Σ = ("P ress ′′ , "Release ′′ ), Γ = ("action ′′ ), I = ("N op ′′ ), F = (ǫ) and δ is described in Figure 5.

• For the light: Q = ("on ′′ , "of f ′′ ), Σ = ("action ′′ ), Γ = (ǫ), I = ("of f ′′ ), F = (ǫ) and δ is described in Figure 5.

D. Specific States and Messages

6LowPAN and CoAP make our node able to communicate with others, and to be dynamically configured. The use of FST is a simple way to express a sequence of logical actions. But in spite of these capabilities, our architecture is not really sensing and acting on the real world. This is only logic. To make a link between D-LITe and the real environment, we propose two Types of Messages and States : Real or Logical (Figure 2) Logical messages or states are useful for reasoning. For example, if we want a light not to switch off immediately when we push a button, we can introduce a logical state : "waiting" (see Figure 4). This state has no impact on the real world but merely means that someone starts the process of switching off. Then a Real State is used. "on" and "off" are such states. When the FST moves to them, the light really switches "on" or "off". In Figure 4, rules explain that on receiving the time message while being in "waiting" state, the light really switches off by going in "off" state. Messages are treated the same way. Many of them are logical messages defined by the user to describe his logical steps in the sequence of actions. The others are real messages sent by the hardware (i.e. the sensing part of the sensor). For example, "Press" and "Release" (cf.

A. SALT description

On each D-LITe node, rule analyzer and communication features are installed. To describe his application's logic, a user needs a language to:

• Delete all settings, i.e. start a new application.

• Set the Initial State, i.e. set FST's starting state.

• Express each Rule, i.e. describe the node's FST.

• Attach Observers, i.e. allow a node to send messages to a specific list of other nodes. There is also other needs. A node must be able to:

• Describe itself, i.e. give its real messages/states during discovery phase. • Communicate with others, i.e. send messages to its observers, and receive messages from other nodes.

B. SALT Messages format

SALT uses a very simple textual form to express and fulfill all the above mentioned tasks. The use of this format instead of other standardised ones, such as JSON for instance, is motivated by the fact that the parser for standardised ones are usually heavy and could not fit the node's memory limitation. Hence, we use a name=value form to limit bandwidth and memory consumption. Names and values should not be more than 6 characters long (on our Contiki implementation). The format used by SALT messages is described in table I. DLITe's FST is fully described by its initial state (order is set to init) and the set of rules (order is set to rule). Observers list is given by order link. As the choreography starts, messages are exchanged between nodes using input message. Rule's Message is a one-liner (see table II) that gives a description of each FST's transition. All states, input and output alphabets are deduced from the complete set of rules.

C. SALT Usage

SALT messages are exchanged between the end-user or a node and other nodes (Figure 2). We use CoAP [START_REF] Shelby | Embedded web services[END_REF], complying Internet standards, to have a small overhead and to be accessible from everywhere. Therefore, the Capillary Internet 3 can be reached through CoAP. Table III shows a complete list of SALT messages that are sent to a node, using CoAP's PUT method.

D. CoAP Methods

CoAP methods are used in D-LITe for following purposes:

• DELETE : Clean FST, current state, and observers list.

• GET : Obtain node's description (i.e. the Real states/messages supported by hardware). • PUT : Give configuration's orders to the node (i.e.

Initial state, observers list, and the FST's rules) (using SALT's "order" messages). • POST : Messages service, to be managed by FST (using SALT's "input" message). E. An Example : Simple Configuration of a Node

Let us take the simple example of a switch controlling another device. In this case, the following SALT messages are exchanged with the switch's node: First an end-user uses the GET CoAP's method to retrieve information about the node, especially its real states and messages. After designing the choreography, the end-user broadcasts the logic to each node. He uses DELETE to clear all rules and current state on each node. Then, he sends (cf. Table III) initial state, all rules representing the FST, and Observers' list using the PUT method. The switch is initialised in state "rlsd". The two rules explain that on receiving the "push" message, the switch will alternately be "rlsd" or "prsd" (in this case, "push" is a real message, generated by hardware. "rlsd" and "prsd" are logical states, defined by the user). The latest order links the switch to node fe80::f0:1:303, which is the IPv6 address of the light controlled by this switch. This light (fe80::f0:1:303) must then be configured to react to messages sent by our node (not shown in this example). Each node is now ready, and the choreography can start. Nodes communicate with others using the POST method, receiving and sending messages following FST instructions, as shown in Figure 6.

VI. IMPLEMENTATION AND VALIDATION

A. Implementation on Netkit, Contiki, Cooja, and Telos B To test our architecture, we realized a simulation using Coapy [START_REF]Coapy, a python implementation of coap[END_REF] to implement the services offered by a D-LITe node. Nodes were simulated on a virtual network with Netkit4 . Our objective was to test our language. Once virtual nodes were collaborating under Netkit with Coapy, we decided to implement our code on Contiki [START_REF] Dunkels | Contiki-a lightweight and flexible operating system for tiny networked sensors. local computer networks[END_REF]. Contiki offers 6LowPAN, CoAP and REST implementations, and runs on real nodes like TelosB or MicaZ. It comes with Cooja, a network simulator of emulated motes. Our D-LITe implementation (Figure 7) has been tested in the Cooja emulator and on real Nodes (TelosB). Coapy is used as a client to send commands from a PC. We wrote Scripts sending initial state, rules and observers list for each example presented in Section IV-C. We also use a Firefox's plugin handling CoAP called Copper 5 to get values or send commands to nodes directly from a PC. D-LITe's code uses 6LowPAN and CoAP API provided by Contiki (Figure 7). SALT messages decoding and FST rule's analyzer is implemented in our D-LITe's code. The binary size of D-LITe for a TelosB is 47KB. TelosB has 48KB program flash memory for storing programs and 10KB RAM for data. Programming TelosB is done by flashing the ROM through a USB connector. In our architecture, the software is divided in two parts. One is D-LITe framework (the fixed part) and the other is the FST's description (the variable part written by users). We flash D-LITe once on a node, and store it in ROM. No more physical contact with the node will be required. Then, each user's program (i.e. the FST's description) is sent through the network, at any time, and stored in RAM. The FST is then executed by the D-LITe framework. All manipulated data are 6 characters long. A rule's length is 24 Bytes (4 words of 6 characters, 2 states and 2 messages). Our implementation can handle up to 50 rules. Each Observer is stored in 16 Bytes (IPv6 address's size). We planned a maximum of 20 Observers. These data describing FST's behaviour represent 1526 Bytes of the 10KB RAM available [START_REF]D-lite website, with codes, documentations[END_REF].

B. Validation use case 1 : a simple example

This is the classical way to control an on/off device (Figure 3). We just want the switch to control light. FST's details were shown before (cf. Section IV-C). 5 orders are used to configure the switch. The first one is a call to the DELETE CoAP method. The following 4 orders are sent with the PUT method (Table III) : One to define the initial state, then the 2 rules, and finally the observer (the light). 4 orders are sent to the light device: the DELETE CoAP method to clean the FST, then the initial state (dark), and finally 2 rules (when receiving "on", go to "light" state (which is a real state), and when receiving "off", go to "dark" state (which is also a real state)). The whole code is sent in 9 CoAP packets. SALT messages total size is 309 bytes, which is far less than the 10KB available RAM memory. Those messages represent the whole application code. 2 rules are stored in light's RAM (48 Bytes used). 2 rules and 1 observer's address are stored in switch's RAM (64 Bytes used).

C. Validation use case 2 : Introducing a logical state

Figure 4 shows a simple example of the use of a logical state. With D-LITe, it is possible to deploy a new program that supersedes the one shown above. The switch doesn't need to be updated, so we keep it unchanged. A DELETE method is used to clean the light's FST. Initial state is set to "dark". The light needs 3 rules: One for "off" to "on", one for "on" to "Wait", and the last when receiving the "time" event to really switch "off". And finally, we send the IPv6 address of the light to the time service, as light becomes an observer of this service. In this example, 10 CoAP packets are send on the network. Switch's RAM usage is still 64 Bytes on the switch, and 88 Bytes are used on the light.

D. Validation use case 3 : using loss of semantic

Dealing with more than two switches to control a light can be done with D-LITe. In that case, each node has just to send a signal to make the light change its state. If the light is on and someone presses the button, the light's state needs to be changed. Switch's former state and message's type do not matter. Figure 5. After deleting FSTs in each node, each switch is initiated to state "nop". 2 rules are sent to explain that "press" and "released" messages generate the same "action" output and go to "nop" state. Each node receives an order to register the light as listener. Setting the light is as simple. FST is deleted, then initial state is set to "dark", and 2 rules describe a flip-flop : "action" message changes state from "dark" to "light" and vice versa. This application uses 4 CoAP packets to configure the light. Each switch needs 5 packets to be set. 2 rules and 1 observer's address for each switch represent 64 Bytes of node's RAM. VII. CONCLUSION D-LITe splits the application in two parts. A fixed part is installed once on each node physically (flashed on ROM for example). That part offers generic services and access. The second part is dynamically uploaded through the network. This one allows to describe the application's logic using very simple textual form (i.e. SALT). This architecture gives D-LITe some advantages. Any changes is simple and fast to deploy. No physical access to a node is needed to completely re-adapt its behaviour. The logic is not very hard to describe. It uses a textual form. It is hardware independent. Programming is based on nodes cooperation, each participating node supporting a small part of the overall application. The vision of the application is a choreography of FSTs, exchanging messages and reacting to received ones. Even if the possibilities of FSTs are restricted, our architecture covers many usual IoT's use cases. Our implementation on TelosB shows that D-LITe can run on constrained devices (48KB) (TelosB RAM's size (10KB) can store up to 50 rules and 20 observers). The D-LITe framework is easy to access and operate by standard and well-known tools as it is based on IPv6 and REST. We are already using D-LITe to test applications, and see where it can be adapted. The main contribution of this paper was to show that it is possible to quickly and easily develop IoT applications in a standardized way, and quickly and easily spread them over any kind of hardware through the Capillary Internet. In the future, we will mainly work on how to improve the architecture, offer reliability, and give it some configuration automation.

Figure 1 .

 1 Figure 1. D-LITE overall architecture : User can discover all nodes capabilities then describe his needs by creating rules. D-LITe deploys these rules that each node follows.

Figure

  Figure2. Each D-LITe node received its rules ; from now it is ready to execute them. A node obeys the FST's rules according to messages it receives from other nodes or from its own hardware (sensors). It changes state (that may impact the real world if it's an actuator) and sends messages to its observers. These will react to that message.

Figure 3 .

 3 Figure 3. Example 1: a simple node for lighting. Press and Release are real Messages. On and Off are real States.

Figure 4 .

 4 Figure 4. Example 2, introducing a logical state : Wait State (On and Off are real states of light actuator).

Figure 5 .

 5 Figure 5. Example 3, losing semantic on switches to solve a 3-way switching problem.

Figure 3 ,

 3 4 and 5) are Real Message sent by hardware to its FST each time someone uses the switch's button. The only interaction between D-LITe and hardware comes from the notion of Real Messages and Real States. That is why D-LITe is loosely coupled to hardware. Thus, in our FST T (Q, Σ, Γ, I, F, δ), few elements of Q and Σ are in contact with the real world. All Real Messages and Real States are detected during the discovery phase. In Figure 3, 4 and 5, Real States and Real Messages are written in green and bold.

Figure 6 .

 6 Figure 6. D-LITe Node's services. Each node has its FST sent by the user, and receives and sends messages through standard network protocols.

Figure 7 .

 7 Figure 7. DLITe implementation on TelosB.

Table I SALT

 I ORDERS : SALT HAS 2 MAIN PURPOSES. THE FIRST (ORDER) DESCRIBES NODE'S LOGIC. THE SECOND (INPUT) ANNOUNCES A

			MESSAGE.
	variable	value	with	description
	order	init	state=xxx	must initialize state to
				'xxx'
	order	rule	Rule Message	A rule the transducer must
				obey: see details below
	order	link	uri=[aa:bb::cccc]	uri contains the IPv6 ad-
				dress of one observer
	input	xxx		Message service : a node
				(or the hardware) sends
				'xxx' to this node
		V. D-LITE LANGUAGE (SALT)
	D-LITe is organized to allow the design and the deploy-
	ment of applications depicted as a choreography of logical
	Finite State Transducers. D-LITe proposes a description
	language ( SALT : Simple Application Logic description
	using Transducers) to configure nodes and allow them to
	communicate.

Table II SALT

 II RULES : FST (TRANSITIONS, STATES, INPUT AND OUTPUT MESSAGES) ARE DESCRIBED IN A ONE-LINER.

	in order=rule&state=xxx&msg=yyy&Nstate=zzz&Smsg=aaaa
	variable	description
	state=xxx	if current state is "xxx"...
	msg=yyy	... if "yyy" message is received...
	Nstate=zzz	...then the node moves to "zzz" new state...
	Smsg=aaa	...and sends "aaa" message to Observers.

Table III SALT

 III MESSAGES FOR A D-LITE NODE : AFTER RESETTING THE NODE, THE USER SETS ITS INITIAL STATE, ITS FST, AND ITS OBSERVER

	order=init&state=rlsd
	order=rule&state=rlsd&msg=push&Nstate=prsd&Smsg=up
	order=rule&state=prsd&msg=push&Nstate=rlsd&Smsg=down
	order=link&uri=[fe80::f0:1:303]

Like Crossbow TelosB or Imote, Oracle SunSpot, or Aduino Uno. D-LITe is mainly design for motes, even if some more powerful hardwares are supported

end-to-end Internet, from everywhere to nodes

a Network Simulator (http://wiki.netkit.org)

https://addons.mozilla.org/en-US/firefox/addon/copper-270430/