Amar Abane

Mehammed Daoui

Samia Bouzefrane
email: samia.bouzefrane@cnam.fr

Paul Muhlethaler

A lightweight forwarding strategy for Named Data Networking in low-end IoT

Keywords: Named Data Networking, learning, wireless networks, Internet of Things, IEEE802.15.4

published or not. The documents may come

A lightweight forwarding strategy for Named Data

Networking in low-end IoT Amar Abane, Mehammed Daoui, Samia Bouzefrane, Paul Mühlethaler

Introduction

Massive technological innovations towards electronic miniaturization, associated with the deployment of manifold wireless technologies, have fostered the emergence of billions of small devices connected over the Internet, creating the omnipresent Internet of Things (IoT) [START_REF] Yaqoob | Internet of things architecture: Recent advances, taxonomy, requirements, and open challenges[END_REF]. IoT systems are currently deployed on the IP protocol suite. However, the IP architecture shows its limitations to support the IoT needs. For example, security is still focused on communication channels when the data itself needs to be secured. Moreover, IoT systems need efficient support for resource naming and discovery, which is not easy to deploy with IP in constrained infrastructures [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF]. Although dedicated adaptations such as CoAP and 6LoWPAN have been developed, matching the IoT vision without fundamental changes remains difficult for IP.

The Information Centric Networking (ICN) [START_REF] Ahlgren | A Survey of Information-Centric Networking[END_REF] approach can natively support IoT needs including resource identification, access control, content security, and mobility. The most interesting embodiment of the ICN model is Named Data Networking (NDN) [START_REF] Zhang | Named Data Networking[END_REF]. In NDN, pieces of contents are named independently of their location, following a URL-like naming structure. Applications request contents from the network by sending Interest packets that pull back Data packets. Native features come along with this principle such as: communication without establishing end-to-end connections and a name-to-address resolution. In addition, it is not necessary to maintain consumer-provider paths, which provides a native support of connection disruption resulting from node mobility.

So far, the suitability of NDN for the IoT has been investigated to some extent [START_REF] Shang | Named Data Networking of Things[END_REF], but the lightweight aspect of NDN should be improved in order to enable NDN in current IoT systems. It has been observed in [START_REF] Baccelli | Information centric networking in the iot: Experiments with ndn in the wild[END_REF] that an NDN stack implementation in IoT devices (RIOT and Contiki) can save up to 60% of ROM and 80% of RAM compared to the RPL/6LoWPAN stack. Moreover, a simple flooding mechanism in an NDN wireless network generates three times fewer packets than RPL/6LoWPAN routing. Even if the superiority of NDN in terms of performance remains to be demonstrated, the data-centric approach of NDN can be an alternative to the 6LoWAPN stack in future IoT solutions [START_REF] Shang | Challenges in IoT networking via TCP/IP architecture[END_REF].

To deploy NDN in IoT devices, one of the first challenges is to support the NDN forwarding in a low-rate wireless network, such as IEEE802.15.4. NDN wireless forwarding strategies are generally based on a broadcast-and-learn mechanism. For example, such an approach, which can be called Blind Flooding (BF) [START_REF] Amadeo | Forwarding strategies in named data wireless ad hoc networks: Design and evaluation[END_REF] has been proposed for NDN over IEEE802.11. Nodes use timers to defer Interest and Data packet retransmissions, so that a node can cancel its retransmission if another node is sending an Interest/Data with the same name. However, such a solution cannot be used directly over IEEE802. 15.4 due to data-rate and resource limitations.

Although lightweight mechanisms for constrained devices are rare in the literature, a simple one has been proposed in [START_REF] Baccelli | Information centric networking in the iot: Experiments with ndn in the wild[END_REF]. This technique called RONR (detailed in Section 3) uses Interest broadcast (flooding) to discover the requested content. After the Data packet is received, each node keeps a mapping between the name prefix of the content and the source MAC address of the received Data, which will be used as the next hop address to forward subsequent Interests. The flooding phase is triggered again when the mapping expires. However, we show in this paper that unicast is not always the best approach, especially with mobile devices, due to the reusable nature of NDN packets as they are independent from host addresses.

To take advantage of the broadcast while reducing overhead, we design a Reinforcement-based Lightweight Forwarding (R-LF) strategy for NDN over IEEE802. 15.4. The idea of R-LF is to make the broadcast as accurate as the uni-cast, in terms of transmitted frames and retransmission decisions. Instead of targeting optimal performance for one configuration, which can be achieved more efficiently with a proactive mechanism, our objective is to design a lightweight tradeoff technique that can keep satisfactory performance in different communication patterns such as multiple data flows, multi-consumer, multi-source, and dynamic topology changes.

Our contribution through this paper can be summarized as follows:

• We study the importance of the broadcast mechanism and we draw up guidelines for designing a forwarding strategy over IEEE802.15.4.

• We propose the R-LF strategy based only on content names and broadcast communications.

• We show by simulation that our strategy can fit different small-scale IoT scenarios in comparison to all-unicast and all-broadcast forwarding approaches.

• We deploy NDN with R-LF on Arduino devices and we give measures on its lightness aspect.

The rest of this paper is organized as follows: Section 2 gives an overview of NDN, focusing on the forwarding aspect. Section 3 presents relevant forwarding approaches for NDN in wireless networks. In Section 4, we show the importance of the broadcast in wireless NDN forwarding, followed by our guidelines for a lightweight forwarding strategy design. Section 5 details the proposed strategy and its relevant steps, operations and parameters. Section 6 reports the results of the strategy evaluation in different communication scenarios. Section 7 concludes the paper with a brief discussion and future improvements.

Named Data Networking

NDN is an ICN protocol in which the communication is completely based on content names, while the IP protocol uses source and destination addresses to deliver contents.

In NDN, content chunks are decoupled from the producer location, and each data packet must be signed by its producer. Thereby, routers can reuse the same packet to satisfy other consumer requests for the same content, providing NDN with a native caching mechanism. The connectionless communication model of NDN gives it a native mobility support, and relying exclusively on content names to communicate removes the need for middleware to support applications [START_REF] Saxena | Named data networking: A survey[END_REF].

Consequently, NDN can be seen as an evolved network protocol, since it intrinsically includes operations traditionally provided by higher layers in the IP model, such as security and flow control. NDN defines two types of packets: Interest and Data, and each NDN node maintains three data structures to ensure its operations: the Forwarding Information Base (FIB) used by a node to decide which interface(s) to forward the Interest to, the Pending Interest Table (PIT) contains Interest already forwarded waiting for Data, and the Content Store (CS) contains forwarded Data packets cached to satisfy future requests.

NDN contents are identified through hierarchical natural names, formed by a sequence of name components separated by slashes. Each component can be accessed and handled separately. For example, the name /home/room1/temperature may identify the temperature value of room 1, while /home/room1/humidity identifies the humidity value in room 1, and /home/room2/all identifies all sensor values of room 2. Applications are free to design their own naming scheme since the routers do not interpret the whole name. Moreover, a producer can add name components to the initial name in order to provide more information about the content (e.g. timestamp, sequence number, geolocation, etc.).

The communication is consumer driven, that is, a communication is initiated by the consumer who asks for the content. Typically, an NDN exchange operates according to the following steps: (1) The consumer requests a certain content by sending an Interest carrying the name of the requested data (e.g. /room1/temperature). (2) The router that receives an Interest checks if the corresponding Data exists in the CS; if the Data is found it is returned to satisfy the Interest without going further. Otherwise, the router verifies if an Interest requesting the same content is already in the PIT: if so the Interest is dropped and only the incoming interface is added to the existing PIT entry. If there is no Interest waiting in the PIT, the router checks the FIB to find one or multiple interfaces to forward the Interest (i.e. multipath routing supported) and creates a PIT entry containing the forwarded Interest with its incoming interface. (3) When an Interest reaches the node that contains the requested content, this node sends back a Data packet carrying the content, the name that is the same as the Interest name to which suffixes may be added, and security information about the content producer (e.g. signature, key name, etc.). This Data packet takes the reverse path of the Interest following traces left in the PIT of each intermediate node. Each Data packet is a response to one Interest packet.

Figure 1 summarizes the processing steps of an Interest and a Data packet over the NDN data structures. Notice that a matching in the FIB corresponds to the longest prefix match. To forward an Interest named /home/room2/all for example, assuming there are in the FIB two prefixes /home and /home/room2, both prefixes match but the longest one is chosen.

To enable the NDN communication model in wireless networks, some forwarding approaches have been proposed. The next Section reviews the most relevant ones.

Related work

The forwarding approaches described in this Section can be defined as "floodand-learn" mechanisms [START_REF] Shi | On broadcast-based self-learning in named data networking[END_REF], in the sense that a flooding phase is used to discover content sources (i.e. producers or caches), and subsequent requests are forwarded more accurately based on the learned information. In the context of this paper, the flooding phase refers to the sequence of Interest broadcast used by the nodes to retrieve a content when no information is available.

Even if most of these solutions are designed for MANETs and do not consider constrained IoT devices, they represent an interesting starting point to design a wireless NDN forwarding strategy.

In [START_REF] Wang | Rapid traffic information dissemination using named data[END_REF], a broadcasting protocol has been designed for data dissemination in vehicular networks. Timers were used to defer packet forwarding. During the waiting time, if a node overhears a packet with the same name, the scheduled packet is dropped, which reduces risks of collisions. However, this blind-flooding mechanism causes a large overhead and does not guarantee that the best path is used to retrieve contents. Therefore, more elaborate solutions have been proposed to move from a blind-flooding to a controlled-flooding.

In the Listen First Broadcast Later strategy (LFBL) [START_REF] Michael | Listen first, broadcast later: Topologyagnostic forwarding under high dynamics[END_REF], each node uses its eligibility value to deduce the delay to wait before retransmitting an Interest. The node's eligibility is based on its distance from the content source that each node maintains: the closer is the node to the source, the shorter is the waiting time. This approach contributes to generate reduced overhead by propagating packets faster. However, LFBL nodes maintain distance tables, and endpoint identification (e.g. MAC addresses) is used for source and destination nodes, which slightly evokes the host-based communication model.

The Neighborhood-Aware Interest Forwarding (NAIF) [START_REF] Yu | Interest propagation in named data manets[END_REF] strategy is based on a forwarding rate adjustment. Each node collects statistics on its neighborhood forwarding and periodically adjusts its forwarding rate (i.e. the ratio of the Interests it should forward). This mechanism makes the nodes collaboratively forward packets without explicit communication, and no additional data structure is needed. Moreover, good performance results have been obtained in terms of completion ratio, but the round-trip time is quite high. As it is based on a purely statistical method, nodes need to first get enough information and reactively adapt to changes in the situation. This makes the approach slow to converge under dynamical communication changes. Thus, it is more suitable for downloading contents (e.g. files) but is not adapted for small content chunks of IoT applications. According to the reported results, it achieves almost the same performance as the blind-flooding strategy under high mobility cases.

One forwarding strategy has been implemented in a network of constrained IoT devices over IEEE802.15.4 in [START_REF] Baccelli | Information centric networking in the iot: Experiments with ndn in the wild[END_REF]. The objective is to reduce the overhead while keeping a satisfactory data retrieval efficiency, all with a minimum state in nodes. This approach called Reactive Optimistic Name-based Routing (RONR) works as follows: after retrieving the first content by Interest broadcast, a node keeps a temporary FIB entry in order to avoid flooding subsequent Interests. The FIB entry binds the content prefix to the content source MAC address. The nodes also use the Interest source MAC address to forward the requested Data packet. This enables a mapping which can be denoted as Interest Unicast Data Unicast (IUDU). When the FIB entry for the requested content does not exist, or it is deleted, the flooding phase is performed again to discover another content source. The RONR approach significantly reduces the network overhead. However, the strategy has no means to select the shortest path to retrieve contents. Moreover, we can intuitively figure out that a unicast mapping hardly supports node mobility and simultaneous data flows in a local network.

Table 1 summarizes the mentioned forwarding approaches with their main pros and cons. In [START_REF] Kietzmann | The Need for a Name to MAC Address Mapping in NDN: Towards Quantifying the Resource Gain[END_REF], the name-to-address mapping is studied in terms of resource consumption in low-end IoT devices. Real-world experiments have shown that forwarding packets with unicast addresses can reduce resource consumption in IoT devices and increase the performance in comparison to the broadcast forwarding. However, the studied mappings are not evaluated in terms of network overhead and content dissemination efficiency with mobile nodes. Therefore, in the next Section, we study the impact of NDN-MAC mapping on the communication performance under mobility conditions.

NDN-MAC mapping and design guidelines

In this section, we simulate a simple IoT scenario to show the impact of NDN-MAC mapping on forwarding performance. Using the unicast approach described above (RONR), we evaluate other mapping combinations. Therefore, instead of using a unicast address to send both Interest and Data packets, nodes can use different mappings for Interest and Data: (i) Interest Broadcast Data Broadcast (IBDB), (ii) Interest Broadcast Data Unicast (IBDU), (iii) Interest Unicast Data Broadcast (IUDB), (iv) Interest Unicast Data Unicast (IUDU).

We evaluated these mappings in a network of 16 relay nodes, with 4 mobile consumers requesting contents from 1 mobile producer. A cache of 20 packets is enabled in relay nodes. Details on parameters and metrics are provided in Section 6.

According to the results reported in Figure 2, mappings with Interest broadcast (i.e. IBDB and IBDU) always transmit the highest number of frames as expected. Indeed, the broadcast generates more Interests in the network, which leads to more retransmissions and more collisions. For the same reason, both IUDU and IUDB generate the lowest number of frames.

IBDB and IUDB achieve, respectively, the first and the second best Interest satisfaction rate. This shows an advantage of Data broadcast, and NDN in general, to satisfy multiple pending Interests with one Data packet transmission. Moreover in IBDB, the exploratory nature of Interest broadcast takes advantages of caching in relay nodes, which gives the best satisfaction rate. This is confirmed by the mean hop count of received Data, which is the smallest in IBDB and the highest in IUDU.

However, a significant difference is observed in the Interest-Data round-trip time. Data broadcast in IUDB as well as in IBDB causes a high mediumaccess competition, which leads to a higher RTT than with Data unicast (i.e. IUDU and IBDU). This raises an important concern about the necessity of using accurate timers to defer packet retransmissions. At the same time, since mappings with Data broadcast provide the highest satisfaction rate, we can not design a forwarding strategy for NDN without considering the Data broadcast.

To sum up, the results suggest to consider Interest and Data broadcast, as it increases content dissemination efficiency and provides a good Interest satisfaction rate. However, the large overhead caused by the Interest broadcast requires a careful design to reduce unnecessary Interest retransmissions. Moreover, the vision of NDN that consists in retrieving contents without using any host address is nicely satisfied with a broadcast strategy.

The simulation results and the study of the related solutions allow to draw up the following guidelines for an adapted forwarding strategy: (i) rely on a minimal state to process packets without maintaining explicit routes, (ii) avoid reverting to a random Interest flooding phase in order to reduce collision risks, network congestion and overhead, (iii) avoid node identification and additional data structures to correctly fit the NDN vision, (iv) distribute decisions and computation tasks over the network, and minimize complexity to meet IoT device capabilities.

Based on these guidelines, we designed an approach inspired from [START_REF] Zhang | Constrained flooding: a robust and efficient routing framework for wireless sensor networks[END_REF] that uses the learned values to compute the delay time to wait before retransmitting a packet. However, the framework has been designed to handle simple sensor-to-sink communications in WSNs, which makes it unsuitable for complexe communication modes. Thus, fundamental improvements and accurate parameter calibration have been made to build an adaptable forwarding strategy for wireless named data networks as detailed in the next Section.

R-LF strategy design

Overview

Routing and forwarding operations are significantly different in NDN and IP. In IP, only the routing operation is smart in the sense that different routing protocols can be envisioned. The forwarding operation always consists in finding the longest match available in the routing table and sending the packet to the corresponding next hop. In NDN however, in addition to the routing operation that can be smart as in IP, multiple approaches are possible to handle packet forwarding with more or less additional information and with or without caching.

Our proposed strategy does not use an explicit routing phase to provide/update forwarding information 1 . R-LF is a learn-broadcast-learn approach that operates according to the following steps: (i) the nodes overhear Data packets and learn a cost value by reinforcement, (ii) the nodes decide to forward an Interest 1 The routing phase is implicit as in the mechanisms presented in the related work.

with a delay according to their cost-based eligibility, (iii) the nodes update their cost from the result, which can be an Interest timeout or a received Data packet.

The following describes the general R-LF approach and the mathematical formalization.

General description

To forward packets, a node traditionally decides in terms of what the next hop is, which can be considered as a spatial forwarding decision. However, as NDN forwarding is based on content names and R-LF runs directly on top on the MAC layer, a node decides in terms of when it should retransmit the Interest, or how long it should wait before retransmitting. Such a process can be seen as a temporal forwarding decision. As reported above, this vision has already been proposed, and its basic principle consists in ensuring that the more eligible node will retransmit the Interest first.

To describe the forwarding approach, the following assumptions are made:

• Interest and Data packets carry the cost value of the sending node, denoted as C-field.

• An Interest flooding with random delays is used to find the producer when the first Interest is issued for an unknown content.

• Nodes are able to overhear Interest and Data packets related to other communications.

R-LF operates according to two phases: (i) a reinforcement learning that consists in maintaining a cost value for each available content prefix, (ii) adjustment of the waiting delay based on the neighborhood activity.

The first learning phase starts after a source node receives a randomly flooded Interest, and acts as follows: (i) the source node responds with a Data packet carrying the initial cost (e.g. 0), (ii) the first forwarder on the sourceconsumer path computes its cost with a reinforcement technique, replaces the C-field with the value obtained, and retransmits back the Data packet, (iii) each node on the path follows the same procedure until the Data packet reaches the consumer, (iv) in the vicinity of the path, the nodes that overhear the Data packet can perform a passive cost update to learn their eligibility relative to the data source.

The random flooding step is then over, and the first learning phase is set up. Each node maintains the cost related to the corresponding content prefix after retrieving (or overhearing) a Data packet with a smaller cost. Let us refer to this phase as the reinforcement phase.

To describe the forwarding process, we define the delay to wait before retransmission as Φ(a). The formal definition of Φ(a) will be detailed later. The forwarding decision in a relay node consists in finding the appropriate value of a that gives a correct delay to wait. Since a is calculated in two steps, let a = ∆ + θ, with ∆ and θ as explained in the following.

Let C x (p) and C y (p) be the current cost for prefix p at nodes x and y respectively. Whenever node x receives an Interest issued (or forwarded) by node y, it computes the value ∆ = C y (p) -C x (p). Here, ∆ quantifies the global eligibility of node x to forward the Interest. If ∆ ≥ 0 then node x can potentially forward the Interest.

The value of θ is locally computed by the forwarder based on its neighborhood activity to refine ∆ before calculating the delay time. Let us refer to this phase as the Delta adjustment phase. With the delta adjustment, the randomdelayed forwarding is used only when the prefix is unknown by the forwarder (x ) and is reset by the sender (y). Thus, even after an Interest timeout in x and y, the value of θ can be used in most cases to distinguish nodes eligibility.

After computing a, the Interest retransmission is delayed for Φ(a) units of time. During the delay-listening time, if node x detects that a forwarder z is transmitting a packet with the same name, it deduces that z is more eligible to handle the Interest and cancels its retransmission.

The next subsection provides the mathematical details.

Details and mathematical formalism

Reinforcement phase: The cost value at node x is updated according to the following reinforcement equation 1:

C x (p) = (1 -α)C x (p) + α (r + min C y (p)) (1)
In this equation used in Q-learning and Q-routing [START_REF] Boyan | Packet routing in dynamically changing networks: A reinforcement learning approach[END_REF], α is the learning rate, r is the reward, C x (p) is the cost at node x for the prefix p, and min C y (p) is the smallest cost heard by node x from node y.

Assuming the hop-count as a metric, the reward is always equal to 1, and the cost of each node increases as the distance to the content source increases. The cost at the content source is 0.

The cost values reflect the distance to the content source, and are used to decide on a forwarder's eligibility. Moreover, the approximate nature of the update formula produces a large number of possible cost values over the network, which helps to avoid obtaining the same waiting delay for different nodes (Section 6.2).

Since the nodes remember only the smallest heard cost, a node may have an obsolete estimation of its cost value. To avoid that, after an Interest timeout, a node resets its cost value (i.e. C x (p)) to 0 and the smallest heard cost (i.e. min C y (p)) to ∆, in order to accept cost updates. Note that in Interest packets, a cost value of 0 indicates that the sender has reset its cost or it has no information about the content prefix. Thus, it does not interfere with the 0 cost value of a Data packet that actually means that the packet has been sent by the producer. The estimation of ∆ is presented further.

Delta adjustment:

The adjustment serves two purposes: it refines ∆ to deal with local uncertainty in real time, and allows each node to handle multiple content prefixes simultaneously as it is shown in the next Section. In fact, using only ∆ to compute delays, even if it is accurate, does not allow different content names cohabitation to be supported.

To compute θ, let N a be the neighborhood activity rate for all data names. From the perspective of a node, N a can be computed by N a = D u /I d , where D u is the number of unsolicited received Data and I d is the number of non-forwarded Interests (dropped Interests).

Then, θ may be simply defined as

θ = T h -N a ( 2
)
where T h ≤ 1 is the activity threshold above which the waiting time should be increased. For simplicity, but without losing accuracy, N a is kept between 0 and 1. Thus, if T h is lower than 1 (e.g. 75% ), θ can be negative. In this case, the value of ∆ is reduced, which will increase the waiting time. When no statistic is available, N a = T h.

Delay function:

After defining the appropriate value of a, the delay time is computed with a function that is inversely proportional to the value of a. Such a function can be intuitively defined by:

Φ(a) = M e a/2 + m (3)
This function ensures that when two nodes can both forward an Interest, the node with the highest value of a will delay its transmission for a shorter time than the node with the lowest value, as depicted in Figure 3. Here, m forces the forwarder to wait for a minimum time to let the transmission of the corresponding Data packet if any. The importance of Φ is capital and a parameter calibration is needed to have an efficient distribution of waiting times. We can observe that lim a→∞ Φ(a) = m. Therefore, we need to ensure that Φ(â) > m, where â is an estimation of the highest value of a.

According to Eq.2, θ is ≤ T h. Given that the lowest cost value that can be received by a node is 0, we can deduce the highest gap between two cost values by estimating the maximum value of ∆. For that, we use the following property of the Q-learning formula:

C x (p) ≤ r + C y (p) ⇒ C x (p) ≤ r + C y (p) (4)
where C x (p) is the updated value of C x (p). This property can be easily verified using the Q-learning update formula and initial conditions.

Assuming that in a network of n nodes, the maximum distance is √ n hops, we use Eq.4 to recursively estimate the maximum expected value of ∆ as ∆ = ( √ n + 1). Then, we deduce an estimation of â to set the parameters of Φ(a). The forwarding decision process for a node x with a cost of C x (p), receiving an Interest from node y with a cost of C y (p) under a prefix p is summarized in Algorithm 1.

Function

(p) == 0 then ∆ = ∆ -C x else ∆ = C y -C x end if ∆ ≥ 0 then θ = T h -N a a = ∆ + θ Broadcast with Φ(a) delay else Drop Interest (node not eligible) end end end
Algorithm 1: Interest forwarding process

Evaluation

For evaluation purpose, we implemented the NDN module in the OMNeT++ simulator [START_REF] Omnet++ | OMNeT++ discrete event simulator[END_REF] including R-LF, BF and RONR forwarding strategies 2 . We first study the impact of the learning rate (α) on R-LF performance, and we fix the values for parameters M, N and Th. After that, we evaluate R-LF in comparison with RONR, a completely unicast approach, and BF which is a broadcast only mechanism that uses delayed retransmissions (Section 3).

The evaluation comparison studies 3 configurations: (i) a variable number of simultaneous data flows, (ii) one data flow with multiple consumers and cache enabled in relay-nodes, (iii) multiple data flows with a variable producer mobility speed. Finally, some experimental measures are reported on the R-LF implementation on the Arduino platform over IEEE802.15.4.

Simulation design

We consider a scenario that reflects a small-scale IoT monitoring application. The network topology is inspired from mobile WSNs: It consists of 16 fixed routers organized in a grid of 200m x 200m, through which producer and consumer nodes move following the Random Way Point mobility model. The MAC layer configuration reflects the IEEE802.15.4 properties (i.e. bit-rate, communication range and CSMA). Figure 4 gives an example of the simulated topology, and Table 2 reports the relevant simulation parameters. In all the simulations, the reported results correspond to the average values obtained with 10 random executions. The following metrics are measured:

• The total number of transmitted packets, to study the accuracy of the forwarding decisions and the generated overhead.

• The mean round-trip time (RTT) for an Interest-Data exchange.

• The Interest satisfaction rate to show the global efficiency of the approach.

• The mean hop count of received Data, to study the ability of the strategy to find the nearest source (producer or cache) for the requested content.

Impact of the learning rate

R-LF involves a set of parameters that need to be calibrated to provide the best performance. Empirical simulation observations give the parameter values as follows: M =5, N =2.5 and Th=0.75. However, the most important parameter to calibrate is the learning rate (α). To study the impact of α on R-LF performance, we simulate a scenario in which two consumers request the same content served by one producer, with 20 packets caching enabled in relays nodes. The results are presented in Figure 5.

Small values of α (i.e. ≤ 0.6) globally give poor performance. This can be explained by the fact that small values of α prevent nodes from learning fast by slowing down the update process. Likewise, when 0.9 < α ≤ 1.0, the nodes overwrite previously learned values, which leads to more similar values and thus to more frequent collisions.

We find that 0.8 ≤ α ≤ 0.9 generally gives the best performance results. Moreover, these values provide stable results through the different executions. For this reason, even if α = 0.9 and α = 1.0 give good performance, α = 0.8 is more likely to keep the same performance through the different executions. We conclude that 0.85 is a good value to obtain a satisfactory performance for the studied metrics. The value of α is fixed to 0.85 for the rest of the simulations.

Figure 6 shows the distribution of the values of a over the time for the 16 relay nodes. Globally, only a few similarities are observed in the values and the range of the possible values is completely exploited by the nodes. This is due to the reinforcement formula and the delta adjustment that helps to reduce similarities in the computed values. More similarities in a-values are observed between -0.5 and 1.5. However, according to the Φ formula (Figure 3), the delays corresponding to this range are high enough to let a node with a higher value of a retransmit first.

Multiple data-flows

The forwarding strategy has to support multiple namespace cohabitations. To create multiple data flows, each pair of consumer-producer exchanges packets under one name prefix. For example, consumer C1 requests content created by producer P1 under the prefix /ndn/home/humidity/*, and consumer C2 requests content created by producer P2 under the prefix /ndn/home/temperature/*. Practically, this case may occur when data is collected according to its type, or when multiple applications run in the same wireless network. Since only one consumer is requesting contents from one producer, caching is disabled in all nodes for this simulation. Figure 7 shows the metric measured according to 2, 4 and 8 simultaneous dataflows, which we believe is reasonable in a local monitoring application. The total number of frames transmitted by R-LF is very low, given that it is a broadcast-only technique. We observe that the number of frames transmitted with R-LF is much more close to RONR (unicast) than BF (broadcast). The low number of frames is the result of the Interest forwarding controlled by the reinforcement learning, followed by the delta adjustment step which can increase the waiting delay if the neighborhood activity is high. Moreover, the same difference between the three approaches is observed for 2, 4 and 8 data flows.

The satisfaction rate is roughly the same for the three approaches. However, the broadcast strategies (i.e. R-LF and BF) seem to be more adapted to support more simultaneous dataflows.

On average, R-LF and BF retrieve contents with almost one hop lower than RONR. Indeed, the unicast forwarding approach needs the expiration of the FIB entry to update the next hop address, while the broadcast forwarding can retrieve contents from any potential source in the vicinity of the forwarder. However, we can observe that this performance is achieved by BF at the cost of a large overhead, while R-LF gives the same efficiency with an overhead close to RONR. R-LF provides an RTT lower than BF as it uses proportional timers instead of random ones. Moreover, R-LF scales better with more nodes/dataflows and becomes closer to RONR in terms of RTT. Obviously, RONR achieves the lowest RTT as forwarders do not use any delays before retransmitting. Having a reduced RTT is the main advantage of using a unicast strategy in this configuration.

Multiple consumers

In this case, only one content prefix (e.g. /ndn/home/* ) is involved in the network. Multiple consumers simultaneously request contents provided by one producer, and/or by relay-node caches. This case is much more close to a manyto-one communication, such as a gateway-devices communication. However, it can also be considered as many-to-many due to caching that allows any relaynode to be a partial source of a content.

Figure 8 shows the results obtained for 2, 4 and 8 consumers.

Broadcast approaches (i.e. BF and R-LF) make better use of caching and achieve the highest satisfaction rate. The difference in the Data hop count is still in advantage of R-LF and BF. However, R-LF keeps its reduced overhead in comparison to BF.

When enabling caches, BF and R-LF are clearly penalized by the RTT in comparison to RONR. This is certainly due to the high competition access to the medium as the number of content sources increases with caching. Here, accurate Interest broadcast and delayed retransmissions of R-LF are not sufficient to provide a low RTT.

Producer speed

This case is the same as the first simulation scenario, with 4 dataflows. To study the forwarding strategies support for higher mobility, we increase the producer speed from 1 mps to 7 mps.

Figure 9 shows the results obtained. As for the first scenario, the R-LF performance is close to the best among RONR and BF for each metric. We observe that when producers move faster, the RTT achieved by R-LF becomes closer to RONR, while it increases in the BF strategy. However, the satisfaction rate with RONR significantly decreases when the speed increases, while it decreases reasonably with R-LF.

Even under producer mobility, BF achieves a good satisfaction rate as broadcast is not much affected by the mobility. However, the high satisfaction rate achieved by BF comes along with a very large overhead, as shown by the total number of transmitted frames. Moreover, we observe that the number of frames transmitted in R-LF is slightly higher than RONR, but very low in comparison to BF. Finally, the shortest path is still ensured by R-LF even with a higher speed.

The unicast mapping shows its limitations to keep a good performance in presence of mobile nodes, while R-LF is able to provide a satisfactory performance.

Implementation on IoT devices

We ported a simple version of the NDN module with R-LF on the Arduino platform3 . We measured the time required to forward Interest and Data for both Arduino UNO (16 Mhz ) and DUE (84 Mhz ). The results are reported in Table 3. The Interest forwarding process for an unknown content name and an empty FIB (i.e. the first Interest) takes approximatively 145µs. The Interest forwarding process for a known content name, with 5 FIB entries, is about 50µs. This difference is mainly due to the random number generation used for the first Interest flooding. A FIB entry update after receiving a Data packet takes 70µs.

On the Arduino DUE, the time required for the first Interest forwarding is 55µs, and 10µs when the content name is known, considering 10 FIB entries.

The FIB entry update time is about 18µs.

Concerning the memory space required by the implementation, only 28% of storage is needed for the UNO and 50% of RAM. The implementation on the Arduino DUE occupies 6% of the total memory. The implementation includes a simple NDN packet definition, the three NDN data structures and the R-LF process over IEEE802. 15.4. Obviously, these values will increase when security algorithms will be added. However, the leeway is still important for security and reliability improvements. As an empirical comparison, some open source implementations of the IPv6 stack over IEEE802.15.4 take about 12% storage and 45% RAM in the Arduino Mega4 , while R-LF takes 3% storage and 12% RAM.

Discussion and conclusion

In the three simulated scenarios, the R-LF performance is always close the best one among RONR and BF for all the metrics. This shows the adaptability of R-LF to different communication scenarios. The only exception to this observation is the RTT in the multi-consumer scenario, which certainly requires more sophisticated techniques for retransmitting cached Data packets.

In our strategy, the random Interest flooding occurs rarely, as the delta adjustment step can be used to compute a waiting delay even if the cost value is reset. This contributes to significantly reduce the network overhead and represents an important improvement regarding the basic flood-and-learn schema.

The reinforcement learning provides a satisfactory performance without requiring an explicit exploration phase. Hence, to forward an Interest, a node needs only a simple FIB look-up as expected in NDN.

The R-LF strategy supports complex communication patterns. The results obtained through different scenarios show that the accuracy of the unicast mapping can be approached by a broadcast-based strategy. Moreover, they show the adaptability of the R-LF approach to support multiple dataflows, multiple consumers and nodes mobility. As a future work, we aim to improve the overhearing efficiency and media access for cached Data retransmission, especially in multi-consumer cases.

Figure 1 :

 1 Figure 1: Interest and Data process in NDN

Figure 2 :

 2 Figure 2: NDN-MAC mapping simulation results

Figure 3 :

 3 Figure 3: Delay function example

Figure 4 :

 4 Figure 4: Topology example

Figure 5 :

 5 Figure 5: Impact of the learning rate

Figure 6 :

 6 Figure 6: a-values example

Figure 7 :

 7 Figure 7: Multiple dataflows scenario results

Figure 8 :

 8 Figure 8: Multiple consumers and caching scenario results

Figure 9 :

 9 Figure 9: Producers speed scenario results

Table 1 :

 1 NDN wireless forwarding approaches

	Name	Approach principle	Pros	Cons	Evaluation
	BF	Interest flooding Random-delayed retransmissions	Satisfaction rate Mobility support	High overhead Packet redundancy	Simulation (IEEE802.11)
	LFBL	Proportional-delay retransmission Content source identification	Low round-trip time Low overhead	Distance table Mobility Node identification	Simulation (IEEE802.11)
	NAIF	Adaptive Forwarding rate	Mobility support Satisfaction rate	High round-trip time High overhead	Simulation/Emulation (IEEE802.11)
	RONR	Interest flooding Prefix to MAC address mapping	Low round-trip time Low overhead	Mobility NDN potential limited by unicast	Real-world (IEEE802.15.4)

Table 2 :

 2 Simulation parameters

	Parameter	Value
	Data packet size	100 B
	Interest packet size	50 B
	Interest send interval	1 s
	Interest lifetime	2 s
	Max Interest retransmissions	1
	Cache size	20 packets
	Cache replacement	FIFO
	Data freshness	10 s
	Wireless bit-rate	250 Kbps
	Wireless MAC potocol	802.15.4 CSMA
	Communication range	35 m

Table 3 :

 3 R-LF measures on Arduino

	Operation	Time (UNO) Time (DUE)
	First Interest forwarding	145 µs	55 µs
	Subsequent Interest forwarding	50 µs	10 µs
	FIB entry update	70 µs	18 µs

Source code available on https://github.com/amar-ox/NDN802.15.4-arduino

https://github.com/telecombretagne/Arduino-IPv6Stack

Acknowledgments

This work is supported by the 17MDU988 project which is a PHC (Partenariat Hubert Curien) Tassili, a French-Algerian cooperation program. This Tassili project is funded by the French ministries (MEAE and MERI) and the Algerian ministry MESRS.


Hajer Chebil
email: chebil@emse.fr

Jean-Jacques Girardot
email: girardot@emse.fr

Christophe Courtin
email: christophe.courtin@univ-savoie.fr

An ontology-based approach for sharing and analyzing learning trace corpora

Researchers wishing to analyze Technology Enhanced

Learning (TEL) situations usually collect interaction traces produced by TEL environments. This paper addresses the issue of sharing, between researchers using TEL environments, of contextualized interaction trace corpora and analysis tools of these corpora. We present a new ontology-based approach called the "proxy approach" to address this issue of sharing.

Proxy model; ontology-based approach; sharing; learning interaction trace corpora; trace analysis tools; interoperability; technology enhanced learning

I.

INTRODUCTION

Technology enhanced learning (TEL) environments represent a promising alternative to traditional learning methods in both face-to-face and distance learning situations. They benefit from technology advances in software developing and the Internet network. In order to analyze the efficiency of these environments, a common practice consists in collecting interaction traces to record learners' activity when using a learning tool. More generally, researchers often use interaction traces collected by TEL environments to study different research questions related to knowledge acquisition processes, pedagogical scenario designing, usability of learning tools, etc. This research study is a part of the "TEL environment customization" project 1 . Research teams of this project collect and analyze interaction traces to study different research questions such as the adequacy of a pedagogical scenario to a real learning situation, the role of the awareness tools in the use of communication tools, and the mechanisms of knowledge acquisition. Collected traces are heterogeneous because they record interactions with different learning assisting tools. They are also of different natures: numeric logs, audio/video records and human observations. We focus our interest on the needs of sharing interaction trace corpora and post-hoc analysis tools of these corpora between researchers using TEL environments within their research studies and analyzing produced interaction traces. In fact, because building an experiment in real learning conditions may be complex and time-consuming 1 http://liris.cnrs.fr/~clu-eiah/?page_id=151 This work is part of the Research Cluster ISLE project (now ARC6), supported by the "Région Rhône-Alpes" in France.

(number of actors, period, technical devices, etc.), it can be interesting for researchers to access shared data related to a previously performed experiment [START_REF] Reffay | Sharing corpora and tools to improve interaction analysis[END_REF]. The availability of experiment data and traces allows researchers to access original data to reproduce published analysis results allowing confirming, refuting or enriching them [START_REF] Corbel | A method for capitalizing upon and synthesizing analyses of human interactions[END_REF]. Sharing analysis tools between different research teams, interested in analyzing interaction traces produced by TEL environments, facilitates the comparison and complementarity between different analytical methods. Our work consists in proposing a model allowing to construct a platform intended for researchers to share contextualized learning interaction trace corpora, and analysis tools. The platform called BEATCORP (Benchmarking platform for Analysis of Trace Corpora) is a kind of a benchmarking platform allowing researchers to perform comparative and cumulative analyses on one or more of the shared corpora and to integrate produced resources to the concerned corpora. The model we propose, entitled "proxy model", is ontology-based and has three principal functions: [START_REF] Chebil | The proxy model: A new approach to sharing and analyzing learning traces corpora[END_REF] modeling the contents of a corpus, (2) operationalizing shared corpora querying, and (3) defining a set of concepts generally found in interaction traces allowing to explicitly align these ontology concepts with those of the implicit ontology (existing in the researcher's mind) defining concepts of new shared corpus traces. The research question we are going to deal with in this paper is: "How can an ontology-based model contribute to sharing interaction trace corpora and analyze them using shared analysis tools without having to impose a new interaction trace representation?". The remainder of this paper is organized in four sections: first, we present existing studies related to the issue of sharing trace corpora and analysis tools; second, we explain the objectives of our research work and enumerate the constraints we face; third, we present our ontology-based proxy approach; fourth, we give an application example; and last, we conclude and describe future work.

II. RELATED WORK

We present in this section related works having dealt with the issue of sharing interaction trace corpora and post-hoc analysis tools. We highlight two issues related to the sharing objective: sharing trace corpora and sharing post-hoc analysis tools. Some existing projects address both of these issues, others deal with either one or the other. Sharing data is generally related to a standard representation format shared by data owners. In fact, following a standard adopted by a community makes it easier for a researcher that doesn't know a corpus to understand its contents. However, such standard doesn't exist. This absence motivated researchers to propose formats for sharing data. Furthermore, sharing analysis tools will be straightforward if they accept the same input data format. This need of sharing a set of analysis tools supports the relevance of the idea of a shared standard representation. If such a standard exists, analysis tools will be adapted to accept input data following that standard. This will increase the usability of analysis tools by facilitating the interoperability between learning environments and analysis tools. Such a consensual standard has, unfortunately, not yet been reached. We will now present some existing work which dealt with sharing trace corpora and trace analysis tools. The Multimodal Learning and teaching Corpora Exchange project (MULCE) [START_REF] Reffay | Sharing corpora and tools to improve interaction analysis[END_REF] focused on the importance of sharing Learning and Teaching Corpora (LETEC) between researchers. Shared corpora contain interaction data collected during collective experimental learning situations. This work puts emphasis on the necessity of contextualizing the shared interaction data. A LETEC structure was thus proposed recommending the use of existent standard formats and decomposing a LETEC into four parts: (1) the context composed of the pedagogical scenario and the research protocol, (2) the interaction data, (3) the license, and (4) the analyses. This project led to a repository [START_REF] Mulce | [END_REF] for the online sharing of LETEC corpora making it possible to (1) perform queries on the repository content based on classification criteria of shared data, (2) browse corpora elements, and (3) download shared corpora. The PSLC Datashop project [START_REF] Koedinger | An open repository and analysis tools for fine-grained, longitudinal learner data[END_REF] [10] offers a web-based platform providing a repository of interaction trace datasets and a suite of tools to perform exploratory analyses and visualizations on those data. In order for the tools to be usable by researchers, interaction data have to be formatted in a particular format proposed within the project and called the "tutor message format" [15]. This format is specific to interactive learning environments such as intelligent tutoring systems (ITS). In addition to interaction data, related publications, files and presentations can be stored in a dataset. To make it possible to store datasets respecting the "tutor message format" and further benefit of the analysis tools, the project developed logging application programming interfaces for ITS developers to directly log interaction data in the proposed format. If a researcher works on an ITS with a different logging format, he has to convert his data in order to analyze them with the shared set of analysis tools. The Interaction Analysis (IA) JEIRP Kaleidoscope [START_REF] Martínez | Library of interaction analysis methods[END_REF] project aimed at offering a shared library of interaction analysis tools for the Technology Enhanced Learning (TEL) community. The project rested on seven interaction analysis tools which were strongly coupled with specific learning environments. The project objective was to share these tools to analyze interactions independently of the learning environments that produced them. An interaction description format called "the common format" has then been proposed, and used to uniformly represent interaction data of different learning environments. The project members emphasize the complexity of proposing a common format. In fact, a trade-off has to be reached between: (1) a very generic format which enables representing a multitude of data but which may cause losses in certain data semantics (which can be useful in automating some processes by the analysis tools), and (2) a more specific format which allows the implementation of automatic features but restrains the multitude of data to be represented. The solution chosen in this project was a sort of trade-off by choosing to represent recurrent elements (which are either required or optional) and giving the possibility to add additional information. Although the initiative of this project was interesting and promising, it has not really led to an available library of shared interaction analysis tools. The CALICO [START_REF] Calico | [END_REF] project deals with sharing and analyzing discussion forum traces collected in professionalizing training sessions which can be either distant or blended (both distant and face to face training). The extended use of discussion forums makes it possible to propose a generic representation format because of the similarity of the data handled. Relatively simple processing can convert data from one specific format to the one chosen by the project. Once the data are expressed in the proposed format, it becomes possible to share and analyze them using the tools shared by the platform developed within the project. In this project, proposing a shared format for representing discussion forums interaction data is realistic because of the specificity of the considered interactions.

We have noticed the difficulty of proposing a standard representation of interaction data, which would facilitate interaction trace corpora and analysis tool sharing, and which covers all trace modeling needs. We propose a new approach to these issues of sharing called the "proxy approach" and based on an ontology-based model. The main idea is to avoid imposing a new model to represent interaction traces. Having introduced this model in [START_REF] Chebil | The proxy model: A new approach to sharing and analyzing learning traces corpora[END_REF], we will focus in this paper on the role of the ontology in the "proxy approach" and give an example of application. Following sections present the objectives of our work, the constraints to which we are confronted, and our new approach that we claim realistic and pragmatic in the absence of a standard representation format adopted by the TEL community.

III. OBJECTIVES AND CONSTRAINTS

This section presents the objectives of our research work and enumerates the constraints that we face.

A. Objectives

This work aims to propose a model which underlies the development of a platform, intended for researchers using TEL environments, allowing to (1) share interaction trace corpora;

(2) share analysis tools allowing to analyze the shared corpora; and (3) integrate and link the performed analytical work to the corresponding corpora. It should be noted that we focus our interest on post-hoc analysis of interaction trace corpora.

B. Constraints

We identified eight constraints we have to deal with in order to achieve our research work objectives.

1) Trace heterogeneity:

Traces record interactions between a human and TEL environment during a learning situation. Data recorded in the traces (called observed elements [START_REF] Settouti | A traceèbased system for technology-enhanced learning systems personnalisation[END_REF]) depend on the used learning environments. Indeed, tracing the use of a communication tool like a chat or a forum follows a model different from that of an ITS. It is also worth noting that tracing is related to observation choices related to researchers' analysis needs. Moreover, traces can sometimes be specific to particular domains when using specialized learning tools (for example ITS for learning mathematics).

2) Different natures of traces: We distinguish, because of their different natures, two types of traces. The first is a log trace (raw or enriched) which records the actions performed on a computer. The second corresponds to a trace non-directly interpretable by a machine and needs a human intervention to understand its content (it is typically an audio/video recording or manually collected observations by a human). The first trace type has an extra property that the second does not have, which is the ability to implement automatic processing of the trace to perform calculations and automatic transformations without needing human intervention. Such automatic processing needs a prior work of transcription when working on a video trace.

3) Traces with different levels of granularity: Traces collected within TEL environments have different levels of granularity. Indeed, traces aren't always collected in a level easily understandable by a human (even a computing expert). They can be of very low and associated with low-level events related to the used hardware device (e.g. mouse clicks, eye movements' coordinates recorded by an eye-tracker, coordinates of a PHANTOM Omni movements, etc.). In our work, the traces that are likely to be analyzed using shared analysis tools have to be in an abstraction level associated to meaningful events of an instrumented learning activity (e.g. send message, reply to message, draw an object, etc.). We can thus imagine that the traces stored in a shared corpus result from previous transformations performed outside the platform on traces having lower abstraction levels.

4) Analysis tools strongly coupled to TEL environments: It is common that a research team working on a particular learning environment develops an analysis tool to meet its analysis needs. An analysis tool development is then often strongly coupled to a learning environment, and is designed to accept the trace format generated by the learning environment. However, some researches provide more generic analysis tools (e.g. visualization tools of messages exchanged in forums [START_REF] Calico | [END_REF]). Defining an input format for the analysis tool remains nevertheless necessary.

5) Lack of a standard representation of interaction traces:

As already mentioned, we noticed the absence of a standard model and format for the representation of learning interaction traces. The existence of such a standard would have solved the problem of sharing a common data formalism for interaction traces produced by learning environments and accepted as input of analysis tools.

6) Necessity of contextualizing interaction traces: It is a complex task for a researcher to understand and use traces resulting from an experiment in which he did not participate especially if the used learning tools are unknown to him. Hence we point out the importance of contextualizing the shared interaction traces as in [START_REF] Reffay | Sharing corpora and tools to improve interaction analysis[END_REF].

7) Necessity of capitalizing upon analyses performed on the shared trace corpora:

In order to allow consulting, reproducing and enriching previous analyses performed on one or more shared corpora, it is necessary to link the resources produced by an analysis work to related corpora and to keep as much information as possible allowing to contextualize, understand and reproduce results (e.g. analysis work description, interpretation model used in the classification of interaction trace events, the data on which the analysis was performed, etc.).

8) Access rights and anonymity: sharing interaction trace corpora can cause the divulgation of personal data of the participants to an experiment having consented to be tracked. It is then important to take into account aspects relative to the anonymity of the shared data and the access rights to it.

IV. THE ONTOLOGY-BASED PROXY APPROACH

The lack of a standard representation model for learning interaction traces motivated projects dealing with the issue of sharing corpora and analysis tools to propose a new trace representation format trying to make it as generic as possible. Noticing that, in addition to the first three constraints we identified in the previous section (trace heterogeneity, different natures of traces and traces with different levels of granularity), we choose to avoid imposing a new model to represent traces which will not necessarily cover all trace-modeling needs. Alternatively, we propose a new approach called "proxy approach" which is based on an ontology. This section presents the proposed ontology and its different functions.

A. Ontology functions

The proposed ontology we call "BeatcorpOnto" is designed using the open source ontology editor Protégé [START_REF] Protégé | [END_REF] and expressed using the ontology web language OWL [START_REF] Owl | [END_REF]. BeatcorpOnto defines three different models with different objectives: the first one models a shared corpus by defining a set of concepts for its description (metadata and contents), we call it "Corpus Model"; the second, we call "Trace Concept Model", defines a set of concepts identified as frequently found in collected interaction traces and used by a researcher to explicitly map a sub-set of these concepts with concepts present in his collected traces; and finally, the third models the operational aspect allowing to query corpora and to achieve interoperability between shared corpora and analysis tools, we call it "Operational Model". The last two models represent the core of the originality of the proposed approach.

1) Corpus Model:

We highlighted in the sixth constraint identified in the previous section and entitled "necessity of contextualizing interaction traces" (cf. III.B.6), the need to contextualize shared interaction traces. This corpus model tries to satisfy this constraint by defining concepts that describe a shared interaction trace corpus. A shared corpus in the BEATCORP platform is composed of physical resources and a description defined by the "Corpus Model" concepts specified by the ontology. These concepts concern: (1) metadata allowing to give general information about the corpus and the studied learning situation; (2) describing physical resources composing the corpus; and (3) describing analytical work performed on the corpus. Our objective being to share learning interaction trace corpora, analyze them and to share analysis results, we differentiate between two classes of corpora: initial corpus and analysis corpus.

a) Corpora types: An initial corpus results from the observation of a TEL experiment, and is constructed in the BEATCORP platform by collecting the resources used and produced during the experiment (e.g. activity description given to the participants, production of a participant, log traces collected, etc) and filling the corpus description (cf. below). An initial corpus constructed in the BEATCORP platform can contain descriptions and resources related to analysis works performed on the corpus outside the platform.

Apart from analyses that are realized by analysis tools outside of the platform and integrated to initial corpora, it is possible to use the analysis tools shared within the platform to perform analysis works on one or more shared corpora. Resources used and produced during such analyses are integrated to analysis corpora. An analysis corpus is constructed in the BEATCORP platform in order to study a particular research question interesting to a researcher or a research team. There is no constraint regarding the number of analysis works to be integrated to an analysis corpus and related to the studied research question. An analysis work can be performed on one or more shared corpora. When describing the analysis work, references to the corpora from which analyzed data are extracted should be kept. Let's note that we consider the possibility that a researcher can be interested in capitalizing on a previous analysis, or to use a resource belonging to a previously-constructed analysis corpus. An analysis corpus can then refer to either initial or analysis shared corpora.

b) Corpus description metadata:

In order to document a shared corpus within the BEATCORP platform, we propose to use a set of metadata. These metadata provide interested researchers with relevant information on the corpus content but can also be used as query characteristics when querying the shared corpora database. A part of this metadata set is inspired from the Dublin Core Metadata Initiative (DCMI) standard [11], which proposes a generic metadata set to describe digital or physical resources and is a domainindependent metadata standard. To the chosen DCMI elements, we propose adding some other elements meaningful to our corpus description issue. The additional metadata elements (except "research question") are exclusively used in describing initial corpora because of their relation with the learning experiment aspect of the described corpus. The ontology defines the "corpus" concept which has two subclasses "initial corpus" and "analysis corpus" corresponding to the corpora types to be dealt with within the BEATCORP platform. Metadata which are common for the two types of copora handled by the platform are defined as OWL properties describing the "corpus" concept. Metadata which are specific to initial corpora are defined as OWL properties describing the "learning corpus" concept. The metadata properties inspired from DCMI elements for the description of a corpus are: (1) "title": name given to the corpus chosen by the researcher and which can correspond to a project name; (2) "description": gives a summary description of the studied TEL experiment in case of initial corpus, or a description of the corpus content in case of analysis corpus; (3) "creator": entity -person or organization-that created the corpus, it is possible to have multiple creators; (4) "contributor": entity -person or organization-that contributed in the corpus (but with less importance than a creator), it is possible to have multiple contributors (5) "subject": significant keywords or expressions describing very briefly the corpus; (6) "publisher": entity responsible of the availability of the corpus; (7) "creation date": creation date of a corpus within the platform; and (8) "licence": licence defining access rights to a corpus. To these general metadata inspired from the DCMI standard, we added another important element in interaction trace corpora description which is "research question". This element is important because our platform is essentially dedicated to researchers which can be interested in checking the research question that motivated the experiment. This element is useful when describing either an initial or analysis corpus. As we mentioned above, the creation of a new analysis corpus is determined by a new research question to study. The above metadata elements describe a corpus, they can then be applied to both types of corpora. We further defined six metadata elements specific to initial corpora: (1) "collection date": corresponds to the first collection of the interaction traces during the experiment. We can imagine the case that a corpus collected ten years ago (collection date) is reconstructed this year (creation date) as an initial corpus in the BEATCORP platform. We consider that this information can be useful to a researcher because it gives him or her an idea about the actual period of the experiment; (2) "learning objective": this element informs a researcher browsing the corpus on the learning objective of the studied experiment (it is possible to have multiple learning objectives), this information can help a researcher choosing an interesting corpus to analyze; (3) "learning type": this element indicates whether the observed learning is individual or collective. In fact a researcher may be interested in studying a particular learning type; (4) "learning mode space": this element gives the researcher an idea of the learning mode with respect to space, which can be face-to-face learning or distance learning; (5) "learning mode time": this element gives an idea of the learning mode with respect to time, which can refer to synchronous activities and asynchronous activities; and (6) "learning tool": this element refers to one or more learning tools used during the experiment described by the corpus.

c) Corpus resource description:

We identified different types of resources that can be shared within a corpus. We insist at this level that we do not impose specific formats for the physical resources shared in a corpus. We distinguished five types of potential shared resources within an initial corpus: (1) pedagogical resources, a pedagogical resource can be either (1.1) teaching-oriented, which means offered by the learning environment to the learner during his learning activity (e.g. a problem statement, a course material), or (1.2) learningoriented, which means produced by the learner (e.g. a dissertation); (2) trace resources, we distinguished two types of trace resources (cf. paragraph III.B.2); (3) analysis resources, which can be: (3.1) imported resource, a complementary resource which is needed by the researcher to analyze the interaction traces (e.g. an interpretation model to annotate interaction events), (3.2) produced resource, a resource produced by an analysis tool used by the researcher during his analysis work, such a resource makes it possible for another researcher to consult the performed work and to eventually enrich it, an analysis tool does not necessarily save the results of analytical work, this is due to the fact that sharing is not necessarily an objective of the researcher, and (3.3) interpretation resource, a resource produced by the researcher during his analysis work to interpret the results; (4) publication resources, any publication presenting results of a research work has to be integrated to the corpus; and (5) documentation resources which document the corpus description (e.g. experimentation description, analysis work description). As far as the resources types to be shared within an analysis corpus are concerned, these can only be (1) analysis resources, (2) publication resources, and (3) documentation resources. Resources are described by metadata giving different information about them (e.g. creator, creation date, format, etc.). We will not detail these metadata in this paper for the sake of space.

d) Analysis work description: It is essential to share the description of the analytical work realized on a corpus. This description represents a kind of tracing of the researcher's activity when performing analytical work, and thus represents a very important support to other researchers to reproduce and compare published results. The concepts defined by BeatcorpOnto depict an analysis work performed outside the BEATCORP platform and integrated to an initial corpus, or an analysis work performed within the platform and integrated to an analysis corpus dealing with the studied research question. An analysis work is described by: (1) its begin date and end date; (2) its description; (3) its analysis objective(s); and (4) reference(s) to the researcher(s) that created and/or contributed to the analysis work. An analysis work can be linked to publication resource(s) that describe it. Assuming that an analysis work can involve more than one tool, analysis is described for every analysis tool used. An analysis by tool is described by (1) the analysis tool used to perform analysis, [START_REF] Corbel | A method for capitalizing upon and synthesizing analyses of human interactions[END_REF] the date of extraction of the interaction traces to be analyzed, this information ensures the reproducibility of the analysis results because it would enable the retrieval of the same interaction trace data even if the corpus were enriched later;

(3) the description of the analysis performed by the tool; (4) the complementary resources imported to be used by the analysis tool in performing analysis; and (5) the resources, if any, produced by the analysis tool as a result of the analysis. A researcher using an analysis tool to perform an analysis can choose to use resources coming from one or more initial or analysis shared corpora. So, when describing an analysis by tool, for each corpus having resources used by the analysis, the performed scripts, (cf. the following paragraph) to extract, filter and format the corpus data to be analyzed, have to be referenced.

2) Trace Concept Model: This part of the model concerns the semantics of data collected within an interaction trace. The approach consists in defining a set of concepts that can be found in learning interaction traces. Each of these concepts is given a textual definition having a semantic level close to that of the researcher. A researcher, wishing to share a corpus in the platform in order to further analyze it using shared analysis tools, checks the concepts we define in the ontology and compares them to those present in his corpus' interaction traces. This can be seen as an explicit mapping that the researcher performs between a sub-set of the concepts of our ontology and the implicit ontology that defines the concepts of his traces. Indeed, we consider that even if the researcher doesn't define an explicit ontology to model his interaction traces, such an ontology exists in his mind and is expressed through the trace format. Thus, the researcher identifies among the concepts defined in the ontology those that exist in his interaction trace corpus. In practice, the mapping is achieved between a specific format of interaction traces and the ontology concepts we define. Identifying an ontology concept as being present in a corpus is related to the trace format produced by the learning tool(s) used to produce the corpus. A particular mapping is then closely related to a particular trace format. Mapping an ontology concept to a particular trace format will be done by writing a script (cf. following paragraph) which extracts the data corresponding to the concept from trace resources having that format and by linking the script to the ontology concept. A script is therefore specific to a couple of a specific trace format and a particular ontology concept. From the analysis point of view, a shared analysis tool accepts an input format which defines the input data it is able to analyze and their formatting. As for the outputs of learning tools, we state that an implicit ontology defines the concepts to be present in the input of an analysis tool, which are defined in the tool input format. The researcher, who wishes to use an analysis tool on the traces of a shared corpus, identifies within the ontology concepts those that are necessary for his analysis work and verifies if a mapping exists between those concepts and the trace format. The following paragraph explains in detail how to query a corpus and use an analysis tool to analyze the extracted data. As already mentioned, interaction traces can contain different information depending on the observer needs which means that it is possible to have more or less information to represent the same kind of interaction traces. Concepts defined within the ontology may be missing and then not cover every information that can be retrieved within interaction traces. Among these information, some can be very specific to a particular domain and others can be relatively generic and related to a category of tools (e.g. communication tools, production tools). We are specifically interested in the second type of concepts (i.e. generic concepts). If a researcher wishing to share a corpus notices that a relatively generic concept is present in his interaction traces but not in the ontology, it will be possible to add that concept to the ontology. We don't claim that the ontology we propose is complete. Therefore, it can be enriched as new corpora and analysis tools are shared within the platform. This enrichment will be straightforward because of the simplicity of the concept class definition within the ontology. A concept is represented as an OWL class and can be classified depending to its specificity. We identified four types of concept classes that could be further developed. Indeed we worked on a "limited" set of concepts as a proof of concept. An application example will be presented in section V. The four concepts categories we identified are: (1) time concepts, which give information about time indicator within an interaction trace (e.g. begin date, duration); (2) generic concepts, identified as frequently found in interaction traces independently of used tools within learning environments (e.g. user, tool); (3) communication concepts, related to communication tools that are frequently used within TEL environments (e.g. message, recipient); and (4) production concepts, related to production tools (e.g. produced object, activity evaluation). These categories will certainly be enriched to be able to represent the concepts that are interesting to researchers. Furthermore, as already mentioned, a researcher may be interested in querying resources produced by analyses. One or more categories can then be added to represent concepts useful for the semantic representation of analyses that enrich interaction traces. We identified two types of concepts that can be defined within the ontology: (1) a simple concept, which is related to simple information extracted from interaction traces (e.g. user performing action); (2) a complex concept, which is composed of other simple or complex concepts (e.g. chat interaction composed of other concepts like "user", "begin date", "message").

3) Operational Model: This model defines the operational mechanisms that allow querying, extracting and formatting shared corpus data to be analyzed within a shared analysis tool. For this purpose, we defined five types of scripts.

a) Concept querying script: this kind of script ensures the mapping between ontology concepts and a particular interaction trace format. It is frequent that TEL environments record interaction traces in an XML format, or in a format which can easily be exported or converted to XML. A concept querying script is then, in our first implementation, an XQuery (the XML querying language) [START_REF]XQuery[END_REF] script that searches within an XML interaction trace document the information which corresponds to a particular concept. If the queried concept is complex, such a script calls querying scripts which correspond to the composing concepts. A concept querying script is performed on a particular trace document and for a particular position within it (e.g. the date of the tenth interaction within the interaction trace document having some path). b) Data type converting script: Data extracted from interaction traces can be expressed in a particular data type that is different from the one expected by an analysis tool. A conversion can then be needed to express extracted data in the convenient data type. A typical example is the data type used to represent date. Indeed some systems represent date as a Unix timestamp expressed as integer value, others represent it as a date/time type. A data type converting script is then defined for a couple of an input data type and an output data type. c) Extracting script: A researcher interested in analyzing interaction traces of one or more corpora chooses an ontology complex concept that he wishes to query. That concept should of course have been mapped with the corpus interaction traces. In other words, querying a concept supposes the existence of a concept querying script associated to that concept. An extracting script calls a complex concept querying script and performs it on a whole trace document (e.g. extracting all chat interactions). A particular extracting script is then related to a particular trace format and a complex concept defined by the ontology. Extracting script extracts all interaction traces corresponding to a complex concept without imposing any constraint. d) Filtering script: Data extracted using an extracting script may need to be filtered in order to meet analyzer needs in terms of the data that have to be extracted in order to be analyzed by a shared analysis tool. A filtering script processes the output of an extracting script to prepare data necessary for the input of an analysis tool. A particular filtering script is then related to a particular couple of formats: a trace format and an analysis tool input format. We identified two types of filters that can be applied within a filtering script. The first filtering type is identifying a set of projection concepts. A filtering script is executed on an extracting script which is in turn related to an ontology complex concept. Projection concepts are chosen among the concepts composing the queried complex concept (e.g. the complex concept chat interaction is composed of "user", "date", "message", projection concepts are "user" and "message"). The second filtering type is the definition of selection conditions that should be verified within the filtering script output. A selection condition is related to a concept that composes the queried complex concept. It is usually defined by a comparison operator (e.g. equal, not equal, greater than) and the expected selection value to which the extracted data will be compared. An example of a selection condition could be: the chat interactions of user "user1" (complex concept: chat interaction; selection condition concept: user; operator : equal; selection value: user1). Furthermore, a filtering script can call, if needed, a data type converting script to completely prepare all extracted data to be analyzed. e) Formatting script: This last script is performed on the output of an extracting script or a filtering script (if filtering is needed) in order to format extracted data to be directly analyzable by a shared analysis tool. A formatting script is then related to a particular couple of formats: a trace format and an analysis tool input format.

B. Specificities of the approach

The proposed approach is different from existing ones because it avoids imposing an interaction trace representation. Instead, it is an open approach which tries to be adaptable to different sharing needs. This approach needs a minimal effort of integration because it allows to accept any interaction trace resources and contextualization resources without having to convert them to a particular format (the only technical constraint, in our first implementation, is that interaction traces have to be expressed in XML to be queried in XQuery). The proposed approach is incremental and needs a minimal integration effort. Indeed, a researcher who shares a corpus and wants to analyze it using a shared analysis tool isn't expected to do all the work of mapping all concepts defined within the interaction trace format, instead, he only needs to map those that have to be extracted for the analysis. Mapping performing and script implementing are then developed in a participatory manner. In fact, TEL environments usually offer a multiple set of functionalities that are not necessarily all used. Mappings and scripts can then be added when needed by a researcher and shared in order to be used by other researchers.

Concerning the shared interaction trace anonymization issue, shared data should have been anonymized before their sharing within the platform. The anonymization feature is out of the scope of our research work. As far as access rights to the platform shared corpora and analysis tools are concerned, we will use a simple access managing system inspired from the Unix operating system. We can define access rights on platform objects differently for (1) owners, (2) authorized users, and (3) other users. We will not further detail this aspect of the platform for sake of space.

V. APPLICATION EXAMPLE

In the very first implementation of the BEATCORP platform, we worked on an application example of the proposed approach. We created a first initial corpus containing interaction traces produced by a TEL environment called DREW (Dialogical Reasoning Educational Web tool) [START_REF] Corbel | Un outil Internet pour créer des situations d'apprentissage coopérant[END_REF] which is dedicated to collaborative learning activities. DREW offers a set of tools including a chat that produced the interaction traces which we are interested in. We then created a second initial corpus produced by the course management system Moodle [17] which offers multiple tools including a chat tool which interaction traces have been collected when creating the corpus. Note that the first corpus contains traces produced during an authentic learning situation corresponding to a students' supervising session for a C language project, while the second corpus contains experimental chat session traces not significant from learning point of view. Although an initial corpus, as we have already stated, may contain contextual resources about the learning situation, the two corpora we created contain only trace resources. This is understandable for the second corpus because it doesn't represent an authentic learning situation. But, for the first corpus, this illustrates the lack of contextualization due to the absence of the sharing intention. We used the eXist-db [18], an open source native XML database management system which offers an embedded XQuery querying engine, as an infrastructure for sharing and querying corpora. For each corpus, we imported available trace resources and filled a little description (metadata like creator, date, used tool, etc.). Each of the TEL environments used in the creation of the corpora is described and their trace format resources had been imported. These resources are useful for understanding interaction trace contents, in particular those relative to chat interaction in our example, and thus for mapping ontology concepts to interaction trace contents. Studying the interaction trace representation formats relative to DREW and Moodle allowed us to identify ontology concepts relative to chat interactions that exist within chat interaction traces of these two learning environments. Fig. 1 illustrates a sub-set of interaction trace concepts defined by the BEATCORP ontology. We can see simple concepts like "Message" and "User", and complex concepts like "ChatInteraction". The "ChatInteraction" concept is defined as being composed of a number of simple concepts. It should be noted that a specific chat interaction trace format can contain data mapped with "ChatInteraction" concept but which is mapped to a subset of the composing simple concepts. The composing simple concepts are defined widely to cover as many chat interaction traces as possible. Fig. 2 and Fig. 3 respectively present examples of different types of scripts necessary in querying shared interaction traces produced by DREW and Moodle in order to analyze them. They present examples of: (1) a simple concept querying script relative to the "Message" concept; (2) a complex concept querying script relative to the "ChatInteraction" concept; (3) an extracting script that returns all chat interactions of a trace resource, this script calls the previous one; and (4) a filtering script allowing to filter the output of chat interactions extracting script by keeping only the traces relative to sending message events. Fig. 4 presents an example of a formatting script that formats the results of a filtering script in order to be analyzed by the Tatiana analysis tool [START_REF] Dyke | A model for managing and capitalising on the analyses of traces of activity in collaborative interaction[END_REF].

VI. CONCLUSION AND FUTURE WORK

This paper presents the "proxy approach", an ontologybased approach for sharing contextualized interaction trace corpora and analysis tools to analyze these corpora. This approach avoids, in contrast to existing approaches, imposing a trace representation. Alternatively, it is based on an ontology that defines three models to support sharing: the corpus model, the trace concept model and the operational model. Finally we presented an application example as a proof of concept for our approach. Next step will be to work on new different examples to test the applicability level of the approach.

Figure 1 .

 1 Figure 1. Sub-set of BEATCORP Ontology concepts relative to interaction traces, examples of simple concepts, and the ChatInteraction complex concept

Figure 2 .Figure 3 .

 23 Figure 2. Examples of (1) simple and complex concept querying script, (2) extracting script, and (3) filtering script, relative to DREW chat interaction traces

Figure 4 .

 4 Figure 4. Example of formatting script for preparing input of the Tatiana analysis tool