Rodrigo Teles Hermeto

Antoine Gallais

Fabrice Théoleyre

Is Link-Layer Anycast Scheduling Relevant for IEEE802.15.4-TSCH Networks?

Keywords: IEEE 802.15.4-TSCH, anycast scheduling, experimental evaluation, correlation, packet losses independency

With the wide adoption of low-power wireless transmissions, industrial networks have started to incorporate wireless devices in their communication infrastructure. Specifically, IEEE802.15.4-TSCH enables slow channel hopping to increase the robustness, and relies on a strict schedule of the transmissions to increase the energy efficiency. Anycast is a link-layer technique to improve the reliability when using lossy links. Several receivers are associated to a single transmission. That way, a transmission is considered erroneous when none of the receivers was able to decode and acknowledge it. Appropriately exploited by the routing layer, we can also increase the fault-tolerance. However, most of the anycast schemes have been evaluated by simulations, for a sake of simplicity. Besides, most evaluation models assume that packet drops are independent events, which may not be the case for packet drops due to e.g. external interference. Here, we use a large dataset obtained through an indoor testbed to assess the gain of using anycast in real conditions. We also propose a strategy to select the set of forwarding nodes: they must increase the reliability by providing the most independent packet losses. We demonstrate using our experimental dataset that anycast improves really the performance, but only when respecting a set of rules to select the next hops in the routing layer.

I. INTRODUCTION

Industrial networks target mainly the monitoring of safetyrelated processes with strict guarantees. To reduce the deployment costs, and to make the system more flexible, industrial networks rely more and more on low-power wireless communication. Unfortunately, these technologies are known to be lossy with no delivery guarantee [START_REF] Liu | TALENT: Temporal Adaptive Link Estimator with No Training[END_REF].

To cope with this limitation, standards have been proposed to provide determinism on top of an unreliable link layer, such as IEEE 802.15.4-TSCH [START_REF]IEEE Standard for Low-Rate Wireless Networks. IEEE Std[END_REF]. This standard carefully schedules the transmissions such that each device has enough transmission opportunities to send a packet in a reliable way. In addition, slow-channel hopping allows the nodes to combat the effect of external interference.

IEEE802.15.4-TSCH supports both centralized and distributed scheduling algorithms [START_REF] Hermeto | Scheduling for IEEE802.15.4-TSCH and slow channel hopping MAC in low power industrial wireless networks: A survey[END_REF]. In a centralized approach, a controller knows a priori the radio topology, and the volume of traffic generated by each device. On the other side, the network has to reactively allocate the transmission opportunities (i.e. the cells) to each transmitter when applying a distributed approach.

Anycast has been proposed to authorize several receivers to be active at the same time. Since a transmission is lost only if all receivers fail to receive a packet, the network reliability and the energy efficiency can be significantly improved [START_REF] Huynh | On the interest of opportunistic anycast scheduling for wireless low power lossy networks[END_REF]. Hosni et al. [START_REF] Hosni | Adaptive k-cast Scheduling for highreliability and low-latency in IEEE802.15.4-TSCH[END_REF] investigated the impact on the reliability when choosing the best parents to forward the packets. However, they assume that packet loss probabilities are independent for all the links, which may not hold practically. For instance, external interference may impact all the receivers simultaneously [START_REF] Queiroz | Survey and systematic mapping of industrial wireless sensor networks[END_REF].

In this paper, we conduct a thorough experimental study to assess the relevance of an anycast technique at the link layer to improve the network reliability. We use an indoor largescale platform, mimicking a smart building application, where multipath increases the complexity. Besides, other colocated networks (Wi-Fi, or IEEE802.15.4 compliant networks) may also generate external interference.

The contributions of this paper are as follows: 1) we evaluate the correlation factor among the packet transmissions for a group of receivers. In other words, for each device, does there exist a set of neighbors with (almost) perfectly independent packet losses? 2) we explain a method to schedule several receivers for a packet by exploiting minimal 6TiSCH to schedule, to increase the packet delivery ratio for each transmission; 3) we show that greedily selecting the best parents (i.e.

providing the higher Packet Delivery Ratio) is insufficient since they may exhibit very correlated statistics. We thus propose an heuristic to select a proper set of parents; 4) we assess the performance of our heuristic, evaluating the reliability achieved in a multihop, realistic environment.

II. BACKGROUND & RELATED WORK

We detail how IEEE802.15.4-TSCH and 6TiSCH work together since we rely on these two standards for the performance evaluation. We also detail the related contributions in anycast scheduling, and on the independency characterization of packet losses.

A. IEEE 802.15.4-TSCH & 6TiSCH overview IEEE 802.15.4-2015 has proposed the TSCH mode, largely inspired from the previous ISA100.11a [START_REF]Wireless systems for industrial automation:process control and related applications[END_REF] and WirelessHART [START_REF]Specification 75: TDMA Data-Link Layer[END_REF] standards. It relies on slow channel hopping to external interference: one packet and its retransmissions use different radio channels (frequencies), and make the packet drops less repetitive.

TSCH defines a slotframe, which consists of a matrix of cells (i.e. timeslots and channel offsets). The standard defines two different types of cells : dedicated: cells should be assigned to a group of noninterfering radio links. In that case, the transmitter does not implement any contention resolution algorithm since it considers it has a full access. It just triggers a CCA before the transmission to deal with external interference; shared: cells are assigned to a group of possibly interfering transmitters. When a transmitter has a packet in its queue at the beginning of a shared cell, it transmits the packet immediately. If an acknowledgement (ack) is required but not received, the transmitter considers a collision occurred. In that case, it selects a random backoff value, and skips the corresponding number of shared cells.

Many distributed and centralized scheduling algorithms have been proposed so far for slow channel hopping MAC [START_REF] Hermeto | Scheduling for IEEE802.15.4-TSCH and slow channel hopping MAC in low power industrial wireless networks: A survey[END_REF]. Centralized approaches rely on a controller which computes a schedule, pushed to each device. Inversely, a distributed scheduling relies on an algorithm implemented in each node, so that any pair of nodes can negotiate the cells to use.

In addition, the 6TiSCH IETF working group aims to define protocols to bind IPv6 (i.e. 6LoWPAN) to a reservation based MAC layer (i.e. TSCH). 6TiSCH defines a protocol which is in charge of modifying the schedule (i.e. 6P [START_REF] Wang | 6top Protocol (6P). draft[END_REF]). Typically, a centralized scheduler uses 6P to modify the set of cells, through end-to-end commands. Inversely, distributed scheduling allows a pair of nodes to use 6P to negotiate directly the cells to use.

6TiSCH also defines a minimal configuration (i.e. 6TiSCH-Minimal) where all the devices wake up synchronously during shared cells [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF]. Slotted-Aloha is used to solve the contention. These cells are typically used by default to transmit the broadcast control packets, such as Enhanced Beacons (EB) or DIO (DODAG Information Objects).

B. Anycast transmissions

Wireless transmissions are broadcast by nature and any neighbor of the transmitter may overhear outgoing transmissions. Several works have proposed to use such feature, for both synchronous and asynchronous approaches. With preamble sampling approaches, the transmitter sends some short preambles: the first node waking-up acknowledges the preamble and starts receiving the packet [START_REF] Duquennoy | Let the tree Bloom: scalable opportunistic routing with ORPL[END_REF]. This concept is quite old and has already been proposed when considering opportunistically the routing and MAC layers together [START_REF] Kulkarni | An address-light, integrated mac and routing protocol for wireless sensor networks[END_REF], or to allow fast neighbor discovery by mobile nodes with anycast [START_REF] Papadopoulos | Low-power neighbor discovery for mobility-aware wireless sensor networks[END_REF]. Unfortunately, this approach does not increase the reliability in synchronized protocols: only one receiver would be awake at a time.

We focus here rather on synchronous MAC approaches. For instance, ISA-100.11a-2011 implements the concept of duocast where two receivers are assigned to the same transmission. The receiver with the highest priority, acknowledges first the packet when it decodes correctly the packet. When the primary receiver fails, the secondary node has the opportunity to acknowledge the packet, and to place it in its forwarding queue. Thus, we have immediately a fallback solution to reduce the transmission delay, and the required number of retransmissions.

In a general manner, Huynh et al. [START_REF] Huynh | On the interest of opportunistic anycast scheduling for wireless low power lossy networks[END_REF] investigate the interest of anycast when considering ideal conditions (the channel state information is known by the receiver and transmitter). They demonstrate that an optimal scheduling policy exists, where the same reliability is achieved with a lower energy consumption and delay when using anycast at the link layer.

In synchronized networks such as IEEE 802.15.4-TSCH, the transmitter replaces the link-layer destination by an anycast link-layer address. A set of receivers is then subscribing to this anycast address, waking-up simultaneously. Hosni et al. [START_REF] Hosni | Adaptive k-cast Scheduling for highreliability and low-latency in IEEE802.15.4-TSCH[END_REF] demonstrate that picking the best parents (higher PDR) represents an optimal strategy when neglecting the overhead for notifying the transmitter the packet was correctly decoded. However, they assume that packet loss probabilities are independent for all the links, which may not hold practically.

C. Packet Losses Correlation

While ideal radio propagation models provide very stable characteristics, experimental evaluations prove reality is much more complex [START_REF] Pavkovic | Experimental Analysis and Characterization of a Wireless Sensor Network Environment[END_REF]. The link burstiness measures the timevariant packet losses for a given link [START_REF] Srinivasan | The κ factor: Inferring protocol performance using inter-link reception correlation[END_REF]. A receiver may succeed to decode a sequence of packets, and then stop receiving for a long time. In other words, the packet losses are not independent, because of e.g. external interference. Identifying long-term stable links may help to avoid oscillations, but reduces also the routing diversity [START_REF] Hamad Alizai | Bursty Traffic over Bursty Links[END_REF].

The anycast mechanism presented previously works ideally only when the packet losses are uncorrelated. Unfortunately, the literature has proved so far that packet losses exhibit a high spatial correlation [START_REF] Baccour | Radio link quality estimation in wireless sensor networks: A survey[END_REF]. In particular, the κ metric tries to estimate the correlation of packet losses among different links [START_REF] Srinivasan | The κ factor: Inferring protocol performance using inter-link reception correlation[END_REF]. This metric is used to decide which anycast path to choose, and how to implement network coding to improve the reliability. We rather consider only non cross-layer features, and focus on the anycast feature at the link layer, with synchronized MAC protocols. We also investigate the impact of slow channel hopping on this independency.

III. ANYCAST IN A 6TISCH STACK

6TiSCH has been initially designed for unicast transmissions: in the schedule, a cell is assigned to a pair of receiver / transmitter. We here describe how to modify this stack to enable anycast transmissions.

A. Limits of Unicast Communications

Because radio links are lossy, over-provisioning must be implemented, i.e. additional cells to retransmit the packets [START_REF] Dobslaw | End-to-End Reliability-aware Scheduling for Wireless Sensor Networks[END_REF]. Unfortunately, these additional cells impact negatively: the delay: the device has to wait for the next transmission opportunities. Since we implement a low duty cycle ratio, we may in the worst case wait for the next slotframe, which increases the delay and the jitter; the network capacity: we expect a huge utilization of the same unlicensed band. Thus, we must use scarcely the radio resources: provisioning additional cells means also reducing the network capacity for the rest of the network, or the other co-located deployments. In particular, IEEE 802.15.4-TSCH has been proved to generate a large number of collisions in dense deployments [START_REF] Ben Yaala | Cooperative resynchronization to improve the reliability of colocated IEEE 802.15.4-TSCH networks in dense deployments[END_REF]. Using a single path is also not fault-tolerant. A single faulty node is sufficient to break the route, and no packet is finally received by the controller. Some may argue that the routing protocol (aka RPL [START_REF] Winter | RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks[END_REF]) is in charge of finding another route after having detecting the fault. However, such reconfiguration is particularly expensive in synchronized networks: the bandwidth has to be re-allocated along the novel path. Since this reservation requires a large number of control packets, the convergence may be quite long, i.e. a few minutes in some cases, with possibly oscillations [START_REF] Teles Hermeto | On the (over)-Reactions and the Stability of a 6TiSCH Network in an Indoor Environment[END_REF]. We are convinced that multiple anycast paths would make the routes much more robust and fault tolerant, while avoiding heavy reconfiguration costs (i.e. bandwidth, energy, time).

B. Implementing anycast

Anycast transmissions would reduce the number of transmissions by assigning several receivers for one single transmitter. We aim to provide the same level of reliability with less retransmissions. Let us consider the scenario illustrated in Figure 1. The node S has two parents A and B. When it transmits a data packet, A has the highest priority and sends its ack first. The second parent B triggers a CCA after a fixed interval, and detects in the first timeslot an ack is on-going: it drops the packet from S. Then, A forwards the packet to D. For the second packet of S (timeslot 4), the node A is unable to decode the packet, and does not detect anything when triggering its CCA: it sends its ack to S and finally relays the packet to D.

We can note that anycast is only efficient for the nodes more than 2 hops away from the border router. However, longer routes tend to be less reliable, because more relay nodes have to forward the packets. Thus, anycast may improve the reliability and would in the worst case fallback to the unicast scenario.

Typically, anycast implies the following consequences: Receivers ordering: because several receivers can decode the packet, the receivers have to be prioritized. A receiver will forward a packet only if all the other receivers with a larger priority failed to decode the packet; ACK: the transmitter must be sure its packet has been received by at least one receiver. For this purpose, anycast often advocates the usage of contention resolution for ack. More precisely, a receiver waits for a backoff inversely proportional to its priority: if the CCA triggered before transmitting its ack is positive, this means that a receiver with a larger priority is currently transmitting its ack; it stops the process; False negative: with high external interference, the nodes may conclude erroneously with a CCA that a ack is already in transmission. They would stop the process, and the transmitter will not receive an ack for its transmission, even if one of the receivers was able to decode it. However, the transmitter would in that case retransmit the packet. Thus, the reliability with anycast would be at least as good as the unicast case; Duplicates: if the acks collide (false negative for the CCA), the transmitter will retransmit its packet, generating duplicates. Thus, the set of forwarding nodes has to be properly constructed to avoid hidden terminals. Typically, each node has to report the list of its neighbors in its beacons, so that a node can select parents with a sufficient link quality from one to the others.

C. Shared Cells Scheduling

Anycast requires to let several receivers to wake-up synchronously, spending more energy. We want to show experimentally that such mechanism is really efficient to improve the reliability. We aim to prove that the packet losses may be sufficiently independent to provide a significant gain in endto-end Packet Delivery Ratio (PDR). Anycast is energetically relevant when the gain is higher than the energy spent for overhearing.

Anycast scheduling imposes that a transmitter negotiates a common cell with all the receivers. Thus, several handshakes are required to pre-reserve a cell in each receiver (first step) and then start using it when all the receivers confirm it was available. Practically, this increases both the number of 6P packets and the convergence time. Our objective is here to rather quantify the gain of anycast, before modifying the protocols to support anycast. Thus, we propose here to use the 6TiSCH-minimal (Section II-A) schedule. A collection of shared cells are reserved for all the nodes. Thus, a transmitter can safely use shared cells: all its neighbors will be awake, and will be able to decode the packet if they have to forward it.

We focus here on quantifying the gain of using anycast scheduling. By generating a sufficiently low amount of data packets, we can reduce the probability that the same shared cell is used by different transmissions (i.e. collisions). Thus, we can focus uniquely on the anycast mechanism. In a future work, we will investigate the reservation of multi-receivers dedicated cells to make the 6TiSCH stack fully anycast compliant.

D. Preliminary Results

To assess the degree of correlated losses, we collect a large dataset of packet transmissions / receptions on a large-scale testbed. Our objective here is to characterize the wireless links to verify the feasibility of using anycast communication in an indoor environment. We use the FIT IoT-LAB testbed in Lille. In this testbed, all nodes are disposed across 3 floors at the Inria building. Additionally, we can expect external interference originated from other wireless devices, such as Wi-Fi devices and/or concurrent experiments.

We employ M3 nodes, based on a STMicroelectronics 32-bit ARM Cortex-M3 micro-controller (ST2M32F103REY) that embeds an AT86RF231 radio chip, providing an IEEE 802.15.4 compliant PHY layer. We configure a static schedule where each node takes a turn to broadcast a burst of 20 packets, every 30 seconds, during 15 minutes. We select randomly 15 nodes on the second floor of the testbed. Each node records the success / failure of each packet of the burst.

We compute the Pearson (φ) [START_REF] Gray | An Introduction to Statistical Signal Processing[END_REF] correlation for every pair of links that received at least one packet from a transmitter in a given burst. This correlation factor is particularly relevant to measure the correlation among two stochastic variables which do not present the same average value. Indeed, we aim to compare the correlation between two links, whatever their average PDR is.

We consider all links with correlation factor below 0.4 as low correlated [START_REF] Evans | Straightforward Statistics for the Behavioral Sciences[END_REF]. Figure 2a depicts the Empirical Cumulative Distribution Function (ECDF) of the number of low correlated parents by transmitter. We observe that all nodes had at least two independent parents, i.e. their packet losses are very loosely correlated. Thus, selecting these two parents would increase the Packet Delivery Ratio for the link: when the first parent fails to decode the packet, the secondary parent will independently try to decode it.

We also measure the impact of the distance on the inter-link correlation. Figure 2b presents a linear regression using the least squares method between the two variables considering 95 % of confidence level. As expected, longer links tend to present weaker correlation: when two receivers are farther than 25 meters, the average correlation is below our threshold value of 0.40. Thus, nodes geographically close to each other tend to present strong correlation and may not provide a significant gain in terms of diversity.

IV. PARENT SELECTION FOR ANYCAST ROUTING

Inserting too many parents would waste energy: some of them would have to stay awake while never forwarding any packet (the other parents are sufficient). Inversely, we increase the number of retransmissions when too few parents are selected. Thus, we have to construct the right set of parents.

We consider here a convergecast traffic pattern. Each device selects multiple parents, and forwards all its packets in anycast to these parents.

A. Reliable Parent Set Notification

All the nodes have to wake-up during the shared cells. However, only the authorized receivers have the right to acknowledge and to forward a packet. In particular, the receivers have to know their priority for a given transmitter.

Since we consider industrial networks, the set of parents has to be stable to provide long-term performances. Each device has to notify its parent it has been selected, with its priority. This notification has to be reliable, to avoid deafness.

The ordered list of receivers (a short address with 16 bits) is transmitted in an Information Element, and piggybacked in the Enhanced Beacons and routing control packets. To the list is also associated a timestamp (Absolute Sequence Number), at which the transmitter will switch to the novel list.

The timestamp has to be sufficiently distant in the future to handle packet losses. For instance, with a 60% Packet Error Rate, the transmitter has to transmit on average 3 packets before switching to the novel list. Since we consider stable conditions [START_REF] Teles Hermeto | On the (over)-Reactions and the Stability of a 6TiSCH Network in an Indoor Environment[END_REF], this list is seldom changed, limiting the overhead.

B. Greedy PDR Parent Selection Limitation

Usually, we compute the Packet Delivery Ratio (PDR) to assess the reliability of a given transmission. In unicast communication, a node computes the PDR per link, i.e. the ratio of the number of ACKs and the number of packets transmitted to a specific neighbor.

If we assume independent packet losses, we can apply the optimal method described in [START_REF] Hosni | Adaptive k-cast Scheduling for highreliability and low-latency in IEEE802.15.4-TSCH[END_REF]. Each node prioritizes its possible parents based on their RPL rank and their individual PDR. By using the RPL rank as condition, we ensure a loopfree route. We assume that nodes compute their respective ranks based on link quality metrics, such as Expected Transmission Count (ETX), to exploit reliable paths. Finally, a node selects greedily high-priority neighbors in its parent set until the Packet Delivery Ratio reaches a maximum value.

Let P DR(i, p) denote the Packet Delivery Ratio from the node i to its parent p, and P(i) denotes the set of parents for i. A packet is considered lost if none of its parents received it. If we consider independent packet losses, we obtain:

P DR (i → P (i)) = 1 - p∈P (1 -P DR(i, p)) (1)
However, this equation does not hold anymore if packet losses are correlated among the different parents. To show the limitation of this approach, let us consider the Figure 3 illustrating the success / failure of 10 packets for two parents. In Figure 3a, we have two intermediate links with a PDR of 60 and 50% for parents 1 and 2 respectively. When we look at each individual transmissions, we observe that all packets received by Parent 2 were also received by Parent 1, exhibiting a strong correlation. The anycast delivery rate is in that case bounded by the highest PDR of the two links (60%). Formulated differently, anycast would not provide any gain, since the diversity is insufficient to decrease the packet losses.

Anycast scheduling can achieve higher reliability only if the receivers have weak or no correlation in terms of packet losses. This situation with the same PDR as in the previous example is highlighted in Figure 3b. In that case, anycast would achieve a PDR of 80%, as only the 4 th and 5 th packets are not received by any of the two parents.

C. Joint-Packet Delivery Ratio for anycast links

In realistic conditions, a packet may be lost because of e.g. external interference, which impacts all the receivers. In that case, we cannot anymore assume the packet losses are independent, and the equation 1 does not hold anymore.

Let us consider the Figure 3 illustrating the success / failure of 10 packets for two parents. Independent packet losses mean the conditional probability is nothing else but the product of the success probabilities. If the packet toward the parent P1 has been lost, the probability that P2 decodes the packet remains unchanged.

On the contrary, when packet losses exhibit a strong correlation, the conditional probability is significantly modified. Typically, if the packet toward P1 has been lost, this is highly probable that it has also been lost for P2. Inserting P2 in the forwarding set has no positive effect on the reliability: if P1 was unable to decode the packet, it is highly probable that P2 will never succeed to receive it either.

Since the parents are ordered by their PDR in the greedy-PDR strategy, the parents with a lower PDR have to be integrated in the parent set only if they provide independent results. Else, their reliability gain can be neglected.

Thus, we propose here the Joint Packet Delivery Ratio (J-PDR) metric to consider anycast transmissions with any packet losses correlation. J-PDR takes into account the fact that multiple receivers are listening for each transmission. Thus, we have to compute the multi-neighbor delivery ratio.

We use the concept of transmission success sequences. Each receiver stores independently the transmission success for the last k packets. This sequence of bits is reported regularly to the transmitter (within an Information Element as in [START_REF] Gaillard | Monitoring KPIs in synchronized FTDMA multi-hop wireless networks[END_REF]) so that it can compute the J-PDR.

More formally, let us denote by s ij (k) the binary variable equal to 1 iif j has received the k th packet from the node i. Thus < s ij > denotes the transmission success sequence from i to j. The node i computes J-PDR to its set of parents P as follows:

J-PDR(i → P ) = 1 - |{k|∀j, s ij (k) = 0}| z k=1 |z| (2)
with z the number of packets in the sequence.

In other words, a packet is considered lost if none of the receivers received it properly.

D. Greedy J-PDR Parent Selection

We propose here a greedy J-PDR Parent Selection that inserts k neighbors in the parents set while they increase the J-PDR for the link. More precisely, each receiver reports its reception sequence to the transmitter, i.e. a bitmap, with one bit per packet transmission. Since the transmitter uses a sequence number incremented at each packet transmission, a receiver knows a packet has not been received by identifying the voids in the sequence numbers.

The transmitter re-aligns all the sequences to update its parent set. The strategy considering greedily the parent according to their PDR is not anymore optimal. Thus, constructing the optimal set is computationally intensive: we have to test all the possible combinations.

We propose rather to implement a greedy approach using the J-PDR metric. We rank first the neighbors with a lower RPL rank according to a given metric (e.g. ETX, etc.). We select first the neighbor with the highest PDR, since it has a larger probability to increase the reliability for anycast. Next, we check for an additional neighbor that, when combined with the first selected neighbor, the J-PDR increases. Typically, neighbors with weak packet losses correlation have complementary transmissions: when one fails the other succeeds. We insert new neighbors in the parents set while the final J-PDR (selected parents and the candidate) for the link increases.

We aim here to demonstrate experimentally that anycast improves the reliability. Specific scheduling and routing strategies will be proposed in a future work.

V. EXPERIMENTAL EVALUATION

We base all our experiments on data traces obtained from a real deployment on the Lille testbed. In details, we deploy randomly 100 nodes across the building, and collect statistics for all transmitted packets and their respective sender/receivers. We use the same approach as in Section III-D, where a node takes a turn to broadcast a burst of packets periodically. The number of packets per burst and the broadcast periods are the same, 20 and 15 minutes respectively. The network operated for 25 hours during a regular working day, collecting approximately 7 million measurements. The complete dataset is freely available on Github * .

Our objective is here to investigate the interest of using anycast at the link layer, apart from any specific protocol mechanism. Before spending some time to implement anycast on prototypes, we are convinced we need to prove anycast is efficient when exploiting real links, where packet losses may not be independent. Thus, we emulate a multihop topology using a custom IEEE 802.15.4-TSCH network simulator, exploiting directly the dataset. Indeed, we use directly the transmission successes / failures to determine if a packet is received by at least one receiver. By making our evaluation independent from any implementation, we aim to first prove this anycast mechanism needs to be investigated further. The code used in our experiments is also freely available on Github † .

We base our implementation on the 6TiSCH-minimal [START_REF] Vilajosana | Minimal IPv6 over the TSCH Mode of IEEE 802[END_REF] to schedule multiple receivers for a given transmitter. To avoid collisions, we schedule different shared cells for each transmitter. Thus, each node has only one opportunity to transmit per slotframe repetition. We assume here that the schedule is pre-installed at the compilation time. We focus specifically on links with intermediate quality (e.g. < 75% of

A. Multi-neighbor efficiency

We first consider a scenario where a node has to build its parents set among multiple candidate neighbors. In this scenario, each one of the 100 deployed nodes transmits 1,000 packets in a row, while the others register all receptions. We use the first 12 bursts (240 transmissions) for training: a node computes the individual PDR and the transmissions success sequences for each neighbor. These metrics are used to select the parents. Finally, the remaining 51 bursts (1,020 packets) are used to assess the long-term performance when using this static parent set. All the experiments parameters are depicted in the Table I. We compare the performance of the two heuristics described in Section IV. Figure 4a reports the Packet Delivery Ratio obtained with the two heuristics (greedy PDR vs. j-PDR). Using a single parent (no anycast), allows the network to exploit links with a PDR of 75% on average. The two strategies perform exactly the same with one parent because they select as primary parent the neighbor with a lower rank, and with the highest PDR.

With 2 parents or more, anycast improves the PDR: the greedy PDR strategy achieves a PDR of 85%. Those results confirm that greedy J-PDR provides the highest reliability, since it selects the most independent set of parents. Greedy PDR tends to select neighbors that are geographically close to each other, since it considers only the PDR, and not the correlations. We can note that exploiting more than 3 parents has no benefit on the reliability, since only the firsts are effectively used.

To measure the ability of the strategies to select independent parents, Figure 4b reports the correlation factors of the different parents for a given node. In approximately 75% of the cases, all the selected parents have a weak correlation average among themselves (below 0.4). This low correlation highlights that our algorithm improves the spatial diversity and consequently reduces the number of retransmissions. On the contrary, the greedy PDR strategy may select non-independent parents in some cases, leading to a poor diversity (and thus, a lower reliability gain).

B. End-to-end performance

We now consider a multi-hop network to focus on end-toend performance. We place the sink at the extreme corner of the testbed to allow multi-hop transmissions. We rely here on RPL to construct the routes and to assign ranks to each node. We obtain typically the topology illustrated in Figure 5. To measure more precisely the gain of using anycast in multihop networks, we report only the end-to-end results for the devices which are 3 hops away from the sink (i.e. S1, S2 and S3).

Figure 6a illustrates the end-to-end reliability achieved with anycast. Because anycast exploits multiple receivers, we increase significantly the end-to-end PDR when compared to the traditional unicast communication. Still, having more than Fig. 6: End-to-end performance on a multi-hop network for 30 simulations repetitions and 95% of confidence interval.

3 parents does only increase slightly the reliability. Greedy J-PDR keeps on providing the highest reliability, by selecting carefully independent parents, i.e. with independent packet losses. Here, anycast is efficient, and provides an end-to-end reliability of 96% when each device is authorized to retransmit at most 4 times the same packet.

Figure 6b reports the end-to-end delay. In particular, with only one parent, a packet is delivered after a large number of retransmissions, increasing mechanically the end-to-end delay. Indeed, with multiple parents, the nodes can exploit different links with variable conditions. Thus, a packet progresses on average farther with the same number of transmissions. With 2 parents, we reduce significantly the number of retransmissions and the delay. The difference between both heuristics becomes more evident now: the higher spatial diversity added by the J-PDR heuristic reduces the number of retransmissions and consequently the end-to-end delay.

Finally, we measure the energy cost of using anycast, reported in Figure 6c. We use the energy model proposed in [START_REF] Daneels | Accurate energy consumption modeling of ieee 802.15. 4e tsch using dual-band openmote hardware[END_REF], which also targets IEEE 802.15.4-TSCH networks. This model computes the charge drawn per slot taking into account the amount of time that the CPU and radio are used. We assume that the radio is the main source of energy consumption and we consider only the energy spent in transmissions/receptions in our results. Additionally, we adjust the current values accordingly to our hardware (AT86RF231 radio). We use the timers from OpenWSN (http://openwsn.org) as reference to compute how long the radio is used in each timeslot.

Using anycast reduces the number of retransmissions and consequently the network saves energy. A retransmission impacts heavily the energy consumption, since in a shared cell all nodes wake-up simultaneously for a short time to listen for incoming packets, even if they are not scheduled. Thus a retransmission impacts not only the sender and the receiver(s), but all nodes in the network. Additionally, we can remark that the energy consumption is higher for the greedy PDR strategy: the parents are not independent, and some of them stay awake uselessly.

VI. CONCLUSION & FUTURE WORK

We quantified here the interest of anycast to improve the reliability of IEEE 802.15.4-TSCH in a realistic indoor environment. In particular, we use experimental data to study in depth the correlation between packet losses. We proposed a heuristic to select a proper set of independent parents, able to improve the reliability. This greedy heuristic relies on the Joint Packet Delivery Ratio (J-PDR), denoting the actual PDR a link can provide, when considering non independent packet losses. This way, we reduce both the number of retransmissions, and the delay, when the source of the flow is several hops away from the destination. Our experimental results highlight that each device in our indoor environment has at least 2 parents with independent packet losses, i.e. with a φ-factor inferior than 0.4.

After having proved here that anycast is efficient, we aim to propose in the future a novel anycast scheduling algorithm able to work with dedicated cells in 6TiSCH. Obviously, we can adapt any centralized scheduling algorithm, so that several receivers can be associated to a given cell (with the same transmitter). In distributed, we will propose to modify a Scheduling Function to take benefit from anycast. In particular, we will propose heuristics to obtain an accurate estimation of the packet losses, using a combination of passive measurements and probes, such as [START_REF] Teles Hermeto | Passive Link Quality Estimation for Accurate and Stable Parent Selection in Dense 6TiSCH Networks[END_REF]. Finally, we expect also to implement the acknowledgements in the IEEE 802.15.4-TSCH stack, so that several (ordered) receivers can be associated with a single transmission.

Fig. 1 :

 1 Fig. 1: Anycast Transmissions.

  Linear regression between distance and Phi (φ) coefficient.

Fig. 2 :

 2 Fig. 2: (a) Maximum number of parents with low correlation by transmitter and (b) linear regression between distance andPhi with 95% of confidence level.

Fig. 3 :

 3 Fig. 3: Two links with different correlation values.

  (a) Multi-neighbor delivery ratio. (b) Average correlation.

Fig. 4 :

 4 Fig.4: Multi-delivery ratio and the average correlation for the two evaluated heuristics.

Fig. 5 :

 5 Fig. 5: Multi-hop topology composed of 100 nodes across the 3 floors of the testbed. The leaves generate 1000 packets destined to the sink.

TABLE I :

 I Experiments parameters.

		Traffic load	1000 packets
	Experiment	# of nodes # Testbed	100 FIT-IoT Lab (Lille)
		Traffic pattern	Convergecast
		Slotframe length	101
		Timeslot duration	15 ms
	TSCH	Transmissions attempts	4
		Schedule policy	6TiSCH minimal based
	Radio	802.15.4 channels Transmission power	11-26 +3 dBm
	PDR) to demonstrate how anycast transmissions can improve
	the network reliability.

https://github.com/rodrigoth/anycast † https://github.com/rodrigoth/anycast/tree/master/simulator


Julien Mazuet
email: julien.mazuet@univ-ubs.fr

Ill-Ham Atchadam

Dominique Heller

Catherine Dezan

Michel Narozny

J-Ph Diguet

QoS Driven Dynamic Partial Reconfiguration: Tracking Case Study

Abstract-In hybrid systems on chip (SoC) the algorithms must share limited resources classified as hardware (FPGA logic, memory and DSP blocks) and software (CPU cycle budget). Embedded applications are implemented with concurrent processes, which have to coexist. Therefore, the algorithm performance or precision is often downgraded to fit on a FPGA or to meet timing constraints. One of the solutions to relax these constraints is to reconfigure the SoC according to application requirements observed at runtime. Hardware (HW) reconfiguration can be performed by means of dynamic partial reconfiguration (DPR). Beyond the intrinsic DPR complexity, the most critical aspect is the implementation of the reconfiguration decision. Academic adaptive architectures are usually based on power / performance rules. Nevertheless such solutions are usually application agnostic and so cannot fully exploit the possible adaptation to the environment. So real-life systems require solutions to capture the knowledge of algorithm experts that can be leveraged at runtime to drive the reconfiguration decision according to application scenarios. In this paper we propose a methodology to design a reconfiguration controller based on quality of service (QoS) indicators to be specified by experts. This controller monitors the reconfigurable partitions (RP) and can make DPR decisions to optimize the global QoS. We illustrate our methodology in the Radar domain with a tracking system based on Kalman filters implemented on a Zynq Ultrascale+. This study highlights expected gains and obstacles, it presents the different strategies to cope with the issues and draws perspectives.

Index Terms-QoS, FPGA, DPR, Kalman filter

I. INTRODUCTION

This work is motivated by the highly challenging requirements of future radar applications that are designed by signal processing experts. In this domain, processing tasks provide a high degree of data parallelism and can take full benefit from FPGA implementation. For instance, an active electronically scan array (AESA) radar exhibits multiple channels that can be processed independently and so provide tremendous opportunities for HW accelerations [START_REF] Diguet | Digital beam former architecture for sixteen elements planar phased array radar[END_REF]. Besides, it is truly relevant to have different versions of the processing algorithm in order to adapt to the operational context which is changing with the number and types of detected objects as well as their environment. For example, in a target detection setting, in presence of clutter, one can imagine to get two different implementations of a space-time adaptive processing (STAP) algorithm. One implementation would perform very well at the expense of a higher computational complexity, and hence a greater usage of the available hardware resources. The other implementation would not be as efficient as the first one, but would require less computational resources, and therefore could coexist within the available hardware resources with one or many other algorithms like, for instance, a Kalman Filter for tracking. In most of the current implementations, all the possible configurations are specified together in the processing logic (PL), and the system switches between them. This entails limitations on the performances of each algorithm implementation since resources are reserved for nonactive alternative algorithms. A naive solution could be to just use a bigger FPGA, but this is a costly option where unused resources will still exist, which means that the best performances will not be reached. In this case, dynamic partial reconfiguration (DPR) appears as a viable alternative solution. DPR actually allows to dynamically allocate HW resources to the algorithms so that a global performance metric is maximized. However, this approach is possible only if a clear methodology allows signal processing experts, working with Matlab, to efficiently cooperate with reconfigurable SoC designers.

Section II presents a state of the art of DPR controllers which use diverse reconfiguration strategies. In section III we present a methodology to create an adaptive reconfigurable system to reconfigure regarding application QoS feedback. The case study of Tracking method, based on Kalman filters and implemented with the proposed QoS driven reconfigurable architecture, is described in section IV. Section V concludes the paper and draws directions for future work.

II. STATE OF THE ART

Self-adaptive systems based on HW architectures can be modelled as a feedback control loop, as stated by the MAPE-K model [START_REF]An architectural blueprint for autonomic computing[END_REF]. The MAPE-K model has been introduced by IBM for autonomic computing and is described in Figure 1. With this control model, the reconfiguration manager behaviour is based on the application knowledge, which must be abstracted from the low-level software (SW) or HW implementation.

DPR allows runtime adaptation while exploiting FPGA features, such as speedup and energy efficiency [START_REF] Tessier | Reconfigurable Computing Architectures[END_REF]. If the target domain is well suited for FPGA and can benefit from parallel computation, bit-wise operations and fixed-point arithmetic, reconfigurable FPGA give a more efficient solution than GPU and multi-CPU while ensuring flexibility. Several reconfiguration systems are described in the literature. In [START_REF] Seguin | A Dynamically-Reconfigurable Phased Array Radar Processing System[END_REF], authors propose to use DPR to switch between radar modes. This is a good example of how to use DPR to adapt to different situations. However, the reconfiguration control is external and not based on any QoS indicator. Authors in [START_REF] Seguin | A Dynamically-Reconfigurable Phased Array Radar Processing System[END_REF] also highlight the cost advantage of a reconfigurable FPGA system against a multi-board equivalent solution. Some examples manage reconfigurable modules (RM) like tasks. In [START_REF] Fons | Real-time embedded systems powered by FPGA dynamic partial selfreconfiguration: A case study oriented to biometric recognition applications[END_REF], the authors use DPR to implement the tasks on the FPGA, in a sequential order given by the application. This kind of application is meant to reduce the global power cost and increase performance using FPGA, but the reconfiguration decision only depends on the system current state. In [START_REF] Zhang | Scalable Network Function Virtualization for Heterogeneous Middleboxes[END_REF], authors describe a reconfigurable architecture that replaces HW accelerators to provide required functions to the system. This architecture uses a list of functions to be implemented and FPGA available space to decide to reconfigure. Some applications use DPR to enable self-repairing. To do so, they use either scrubbing or duplication / triplication to observe faults [START_REF] Montealegre | In-flight reconfigurable FPGA-based space systems[END_REF]. This can be considered a QoS indicator, but the system only uses DPR to rewrite the faulty configuration to recover. By contrast, our reconfigurable system aims to find the most suitable configuration. An approach that considers application QoS is described in [START_REF] Diguet | Closedloop-based self-adaptive Hardware/Software-Embedded systems: Design methodology and smart cam case study[END_REF]. Nevertheless, the reconfiguration decision assumes that the system knows the value of the QoS for a given configuration. In real-life applications this assumption is not always true, besides in this work DPR was not fully implemented. In [START_REF] Hireche | Context/Resource-Aware Mission Planning Based on BNs and Concurrent MDPs for Autonomous UAVs[END_REF], authors have designed a system which can decide whether to reconfigure a system according to diagnostic indicators that include application QoS values. The decision method is based on Markov decision process and Bayesian networks, and consider available QoS criteria. However, once again, this work doesn't fully demonstrate the full DPR implementation.

Tools have been proposed to support the implementation of DPR-based methodologies, for instance [START_REF] Kalb | Enabling dynamic and partial reconfiguration in Xilinx SDSoC[END_REF] shows how to use DPR in SDSOC. However it is strongly dependent on tools versions and vendors engineering choices. It also implies a complete re-synthesis for each specification modification. Therefore, it is intractable in practice. On the contrary, it underlines the lack of consistent-in-time technical details from FPGA vendors about DPR and CAD tools versions.

Our objective is to optimize performances (QoS, response time, etc.) of a radar-based system according to the context obtained by sensors data. It means that the proposed method must results in configuration control based on a relation between a QoS observed online and the HW configuration. Such an approach is complex since it involves signal processing experts and HW/SW designers who have different concerns and tools.

III. METHODOLOGY

A. Separation of concerns

To take advantage of a QoS driven reconfiguration, the signal processing experts must be DPR aware so that they can have in mind the possibility to switch between different algorithm modes or configurations. However, these experts should not have to care about the implementation details. Thus, the design of a QoS driven DPR needs to be based on the separation of concerns scheme depicted in Figure 2. Once the signal processing experts know they can use several HW configurations in one mission, they can explore more ambitious strategies. First, they need to specify the algorithms to implement and the different versions they need, in terms of performances and resources cost. Secondly, they have to define the QoS indicators they need to implement such decisions. The SoC designers then can provide the required feedback in the same way as in a classic development process. After a few cycles, the reconfigurable SoC experts have to bring to the signal processing experts a library of the different configurations (RM i in Figure 2). They must also provide simple API for the experts to implement the reconfiguration decision system.

B. Reconfigurable architecture model

The architectures considered in this paper target SoC FPGA devices. They are composed of a FPGA (PL) and a processing system (PS). Several partitions are defined to be reconfigurable. The reconfigurable partitions (RP) communicate with one another and with the PS through buses. The more generic the buses are, the more heterogeneous the RM can be. The reconfiguration can be triggered either by the PS or by the PL part. The reconfiguration controller must also access the partial configuration bitstreams that can be stored in the main shared DDR memory or in dedicated one. However, a QoS driven methodology must be accessible to algorithm experts who are not familiar with FPGA. So, if the configuration delay is compliant with the application time constraints, a SW implementation is the best solution. As a SW program, the configuration decision and the configuration control can simply be tested and modified by algorithm experts. Figure 3 illustrates an example of such an architecture with six RPs implemented on a SoC FPGA.

SoC

C. Reconfiguration control system

Besides the execution flow, the QoS-based controller can be decomposed into four parts: 1) Monitor, 2) Analyze, 3) Plan and 4) Execute. The monitor function is in charge of collecting data and computing at least one QoS indicator per RM. These indicators can be computed directly by the algorithm, for example the error in an automation process. If it requires additional computation (e.g. estimation of the next state), the designer can choose to implement it in either the PL or the PS part. The analyze function must determine if a reconfiguration is needed, with regard to the QoS indicators. The plan function decides when to trigger a reconfiguration, and which configurations must be replaced. Finally, the execute function is in charge of loading the right bitstream at the right time according to application execution flows and architecture constraints. In all cases the decision-making based on the indicator is co-designed with application experts and so is preferably implemented in SW. This allows experts to evaluate different strategies. Figure 4 We are interested in optimizing the tracking of a target by selecting the best Kalman Filter (KF) chosen in a library of KFs which differ from each other by their process models, i.e., the way they model the trajectory of the target. Ideally we could execute all the models in parallel and select the best one after each iteration according to QoS indicators. However, our major constraint is that all the KFs available in the library cannot be executed simultaneously because of real-time constraints and hardware resource availability. So, only a subset of the library must be implemented. In our study we consider that two KFs can run simultaneously. KFs can be implemented either in the PS or the PL part. The advantage of the HW version is twofold. First, it improves the execution time and so the response time of the system. Secondly, it allows the execution of multiple KFs in parallel while having the PS available for running other application and system tasks. We choose a model with different KFs running in parallel in separate RPs.

In real tracking systems, such Kalman filters can be very large (more than 10 states in the aircraft dynamic navigation filter in [START_REF] Cork | Aircraft Dynamic Navigation for Unmanned Aerial Vehicles[END_REF]). Hardware optimization based on constant matrix elements is then required. Reconfiguration based only on parameter changes is, therefore, inefficient. Moreover, DPR allows to implement Kalman filters with completely different behaviours (e.g., EKF, UKF and IEKF). In this study, we use simpler Kalman filters to illustrate the method without loss of generality.

A. Reconfigurable architecture model

The architecture used for the study is based on the one defined in III-B. In this example, two RP are defined. These RP can host a KF implementation. Each RP can be configured with seven different state models, each model corresponding to a different trajectory assumption. This means that they do different computations and use different matrix sizes. The KF gets the measurements from the PS through a direct memory access (DMA) interface. This DMA is included into the RP. The buses use a generic AXI4 interface for PL to PS communications. In this example, there is no communication between both RP.

B. QoS estimation and DPR decision

The QoS estimator at time k is chosen as the log likelihood of the measurements collected at time k. This criterion can be used as an efficient estimator of the KF model correctness [START_REF] Tandeo | Joint Estimation of Model and Observation Error Covariance Matrices in Data Assimilation: A Review[END_REF]. It can be computed using the innovation and the innovation covariance computed by each KF under test:

f QoS (k) = (i T k Σ -1 i i k ) (1)
where: f QoS = QoS function i = innovation vector Σ i = innovation covariance We observe that this function requires matrix multiplication, so it can benefit from a parallel HW implementation. This is a typical point of useful discussion that authorize the proposed methodology. The QoS indicator is specified by the application designers and the reconfigurable SoC designers can work on the best implementation. In this case, they can reuse the inverse of the innovation covariance matrix which needs to be computed to get the optimal Kalman gain (equation 2). Therefore, we chose to implement f QoS in hardware, using Newton division to increase performance while reducing PL footprint.

K k = (P k|k-1 H T k Σ -1 i ) (2)
where: K = optimal Kalman gain P k|k-1 = predicted error covariance H = observation model Σ i = innovation covariance Once this indicator is computed, the IP sends it back to the PS. The application then has access to a QoS value for each of the KF modules. This allows the program to identify which filter is the most adapted to the current situation. In this way, the PS can replace the worst one and implement another IP to test another trajectory hypothesis.

Figure 5 shows an illustrative example of the control principle while considering 2 DPR partitions that can implement different Kalman models. The first and second lines draw the evolution of the configurations implemented on the RP1 and RP2 over time.

The method we chose to control the reconfiguration from the QoS values relies on 4 phases: 1) Initialization: Two configurations are chosen at the beginning of the tracking. This choice can rely on mission indicators. For example, in radar systems, the target trajectory can be classified with the help of a priori knowledge.

2) Observation and decision: QoS-driven adaptation is strongly specific to the application and must therefore be flexible, as a software it can be easily modified according to test results. In our case study different strategies are possible. We have implemented a solution that combines long-term observations and reactivity. The QoS estimator gives a new value at each Kalman call. However, we cannot reconfigure each time we get a new QoS value. Nevertheless, a very bad QoS value means that we need to change the configuration as soon as possible. Therefore, we need to have two kinds of reconfiguration: The first one computes the average QoS over an observation window (shown in Figure 5), the KF with the worst QoS score is replaced by a new one according to a round-robin mechanism (Reconf. decision n in Figure 5). The second one is based on thresholds, when both KF QoS exceed the maximum values then KF are interrupted before the end of the window and replaced by two new ones (triggered-based reconfiguration decision in Figure 5).

3) Reconfiguration: The reconfiguration takes time to perform. In some radar applications, there can be no down time. In our system, the reconfiguration time can be hidden since there are two RP running concurrently and only one will be stopped on reconfiguration. The only situation where a timeout occurs is when the threshold-based reconfiguration is triggered for both RP. In such case, none of the Kalman filters can achieve a good tracking so a HW reconfiguration is required.

4) Convergence: When using a Kalman filter, there is a convergence time. This happens because the starting point of the algorithm is not perfect. This time causes the filter to output inaccurate points and can cause the QoS estimator to output bad scores during the convergence interval. In this experiment, we consider this training phase as an additional reconfiguration time. We don't observe the QoS during this phase to avoid penalizing new implemented filters.

C. Experience setup 1) HW/SW platform: The reconfiguration strategy as well as the KFs are implemented in a Zynq Ultrascale+, a SoC made up of a multi-core ARM and a FPGA that supports DPR. Figure 6 presents the layout of the FPGA, with the two reconfigurable partitions delimited by the purple areas. With values. The output of the best KF is first stored into DDR4, and then saved to the SD card to be plotted and analyzed.

In our test bed we consider three different scenarios. In the first one, the two initial configurations are the KF-1 and the EKF-3. Since these systems have strongly different behaviours, the system should easily find the best KF. The second scenario starts with EKF-1 and EKF-3. None of these configurations is a good model at the beginning of the tracking. This scenario can show if the system is able to react fast to a situation where none of the configurations is good and there is a risk to lose the target. The third and last scenario begins with KF-3 and KF-4. As these configurations are close to each other, it will make the configuration choice more challenging.

D. Results and analysis

These tests involve a reconfigurable architecture with active QoS-driven DPR and the best Kalman without reconfiguration (model described in equations of KF-4). The results obtained with the benchmarks are given in Table I. To compare the different approaches, we measure the likelihood and compute its median. We also collect the maximum and more importantly the minimum measurement of the likelihood, as a small value could cause the system to lose the target. We can observe that for the third scenario, the likelihood median is only slightly better when using DPR. However, for the second scenario where the system starts with bad configurations, the QoS value is much better with the reconfiguration system. Hence, the DPR system is better at tracking a target with an a priori unknown trajectory. We also notice that the minimum likelihood measurement is higher with reconfiguration. This implies that the DPR system has less risk of losing the target than the one without DPR. All three scenarios show the same minimum and median values of the likelihood. This shows that our system is robust against its initial condition.

Figure 7 shows the third scenario case of a tracking using DPR. The green curve represents the real trajectory, while the red one shows the outputs of the reconfigurable Kalman system. In this example the Triggered-based reconfiguration (namely when the distance to the model exceed the threshold value) occurs once at x = 6314 when the trajectory radically changes. All other reconfigurations occur periodically at the end of each time-window and can provide the best KF that will be eventually selected according to the QoS comparisons, this is for instance what happens at x = 3715. Figure 8 shows the output trajectories for the three scenarios and without DPR. The differences between Figures 7 and8 highlight the influence of reconfiguration on the Kalman filtering.

These improvements are allowed by the knowledge of the QoS value throughout the process. Thanks to this value, the system can choose the best model at a given time. Moreover, the likelihood also allows to know when the models are not adapted and the system can adapt early. This method requires good knowledge about the application, and extracting a QoS indicator may not always be straightforward.

V. CONCLUSION

The paper first demonstrates the opportunity of using DPR to virtually extend available HW resource of an embedded system in the domain of Radar. The embedded system can dynamically implement HW accelerators according to application requirements in order to speed-up the application execution while saving CPU time.

The study also shows the importance of considering the QoS to drive the configuration. This point is rarely considered in the DPR literature since it requires transdisciplinarity. However, it is crucial to fully benefit from the expert knowledge (radar, signal processing in our case study). This knowledge can be captured and efficiently used only with a methodology that clearly separates concerns. Based on this methodology, the next steps will address the design of an architecture pattern for the domain of Radar including complex task such as Detection based on Range-Doppler maps and realistic Kalman filters with large state space. This new application context will also require to explore different adaptation strategies.

Finally, we intend to define API to collect QoS and API to select configuration. This interface must be generic for application experts. Nevertheless, the implementation will be specific to the target architecture and, therefore, handled by HW designers.

Fig. 1 .

 1 Fig. 1. MAPE-K loop

Fig. 3 .

 3 Fig. 3. Example of a SoC reconfigurable architecture.

Fig. 4 .

 4 Fig. 4. Diagram of the DPR control system

Fig. 7 .

 7 Fig. 7. positions with DPR (scenario 3)

Fig. 8 .

 8 Fig. 8. Tracking positions without DPR (scenarios 1 to 3)

this layout, the reconfiguration of a RP takes 8.7ms using PCAP. This time depends on the size of the partial bitstream as well as the bandwidth of the configuration method. The configuration remains static outside these two boxes. In this experiment, we use only one processor core as well as the PL part. In real-life tracking systems, the other cores would likely be running other tasks such as detection.

RP1 RP2

Fig. 6. Layout of the FPGA with the two reconfigurable partitions (RP1 and RP2).

The different Kalman filters are generated using Vivado HLS, a high-level synthesis tool. This allows to generate different configuration quickly, while ensuring that the different configurations are compatible. Indeed, the RM needs to have the same inputs, outputs and operating frequency. In our tracking example, the target lies on a plane whose axis are x and y, x ⊥ y (Figure 7). The observation vector is z = [x, y, sx, sy], with sx and sy the speeds respectively along the x and y axis.

2) KF / EKF models: The generated Kalman filters are listed below. They correspond to different trajectories assumptions. Note that a state is considered constant when it is not to be seen in the list. Linear Kalman filters: KF-1 : State vector X n = [x n , y n , sx n , sy n ] State transition equations :

KF-2 : State vector X n = [x n , y n , sx n , sy n , ax n ] State transition equations :

KF-3 : State vector X n = [x n , y n , sx n , sy n , ay n ] State transition equations :

KF-4 : State vector X n = [x n , y n , sx n , sy n , ax n , ay n ] State transition equations :

Extended Kalman filters: EKF-1 : State vector X n = [x n , y n , sx n , sy n ] State transition equations :

EKF-2 : State vector X n = [x n , y n , sx n , sy n ] State transition equations : 3) Benchmark trajectory: The trajectory used for the tests is based on a combination of sub-trajectories that follow different Kalman models. In this paper, we use a trajectory where the first part corresponds to the equation y n = x 2 n . In the second sub-trajectory, both x and y have constant speed. In the third part, x and y have constant accelerations. The fourth and last part follows the equation of EKF-3. The green curve in Figure 7 shows the complete composed trajectory. Finally, the observed values, which are the blue crosses in Figure 7, result from the addition of the target trajectory and a proportional Gaussian noise. These data are processed by the implemented Kalman filters used for the experiments.

4) Experience procedure: When the designs are synthesized and implemented, the partial bitstreams are loaded in a flash memory. At power-up, the PS loads all the bitstreams in DDR RAM. When a reconfiguration is triggered, the PS feeds the processor configuration access port (PCAP) with the corresponding bitstream. On power-up, the PS starts a benchmark to test our design. First, the input data is extracted from the SD card and stored in DDR4. Then, the application reconfigures the two RP to set the system into a known state. Depending on the scenario, the two initial configurations may differ. Finally, the processor transmits the data samples and gets the results along with QoS