Mohamad Ali

Hassine Moungla

Mohamed Younis
email: younis@umbc.edu

Ahmed Mehaoua
email: ahmed.mehaoua@parisdescartes.fr

IoT-enabled Channel Selection Approach for WBANs

Keywords: IoT, Channel allocation, WBAN interference mitigation, Bluetooth low energy, Cognitive radio

Recent advances in microelectronics have enabled the realization of Wireless Body Area Networks (WBANs). However, the massive growth in wireless devices and the push for interconnecting these devices to form an Internet of Things (IoT) can be challenging for WBANs; hence robust communication is necessary through careful medium access arbitration. In this paper, we propose a new protocol to enable WBAN operation within an IoT. Basically, we leverage the emerging Bluetooth Low Energy technology (BLE) and promote the integration of a BLE transceiver and a Cognitive Radio module (CR) within the WBAN coordinator. Accordingly, a BLE informs WBANs through announcements about the frequency channels that are being used in their vicinity. To mitigate interference, the superframe's active period is extended to involve not only a Time Division Multiple Access (TDMA) frame, but also a Flexible Channel Selection (FCS) and a Flexible Backup TDMA (FBTDMA) frames. The WBAN sensors that experience interference on the default channel within the TDMA frame will eventually switch to another Interference Mitigation Channel (IMC). With the help of CR, an IMC is selected for a WBAN and each interfering sensor will be allocated a time-slot within the (FBTDMA) frame to retransmit using such IMC.

I. INTRODUCTION

An IoT is a short-range wireless network of interconnected devices, e.g.,WBANs, Wi-Fi, IEEE 802.15.4 (ZigBee), RFIDs, Tags, Sensors, PDAs, Smartphones, etc., that could sense, process and communicate information. Example applications of IoT are smart homes, health monitoring, wearables, environment monitoring, transportation and industrial automation. Within an IoT, various types of wireless networks are required to facilitate the exchange of application-dependant data among their heterogeneous wireless devices. However, such diversity could give rise to coexistence issues among these networks, a challenge that limits the large-scale deployment of the IoT. Therefore, new protocols are required for communication compatibility among its heterogeneous devices.

Basically, the IEEE 802.15.6 standard [START_REF]IEEE Standard for Local and metropolitan area networks -Part 15.6: Wireless Body Area Networks: IEEE Std[END_REF], e.g., WBANs, utilizes a narrower bandwidth than other wireless networks, e.g., IEEE 802.11. However, the IEEE 802.11 based wireless devices may use multiple channels that cover the whole international license-free 2.4 GHz Industrial, Scientific and Medical Radio, denoted by ISM, band, so there could be overlapping channel covering an IEEE 802.15.6 based network and thus create collisions between IEEE 802.15.6 and these devices. In addition, IEEE 802.11 based wireless devices may transmit at a high power level and thus relatively distant coexisting IEEE 802.15.6 devices may still suffer interference. Thus, the pervasive growth in wireless devices and the push for interconnecting them can be challenging for WBANs due to their simple and energy-constrained nature. Basically, a WBAN may suffer interference not only because of the presence of other WBANs but also from wireless devices within the general IoT simultaneously operating on the same channel. Thus, co-channel interference may arise due to the collisions amongst the concurrent transmissions made by sensors in different WBANs collocated in an IoT and hence such potential interference can be detrimental to the operation of WBANs. Therefore, robust communication is necessary among the individual devices of the collocated networks in an IoT.

In this paper, we propose a protocol to enable WBAN operation within an IoT and leverage the emerging BLE technology to facilitate interference detection and mitigation. Motivated by the reduced power consumption and low cost of BLE devices, we integrate a BLE transceiver and a CR module within each WBAN's coordinator node, denoted by Crd, where the role of BLE is to inform the Crd about the frequency channels that are being used in its vicinity. In addition, the superframe's active period is further extended to involve not only a TDMA frame, but also a FCS and FBTDMA frames, for interference mitigation. When experiencing high interference, the WBAN's Crd will be notified by the BLE device to use the CR module for selecting a different channel. When engaged, the CR assigns a stable channel for interfering sensors that will be used later within the FBTDMA frame for data transmission. The simulation results show that our proposed approach can efficiently improve the spectrum utilization and significantly lower the medium access collisions among the collocated wireless devices in the general IoT.

The rest of the paper is organized as follows. Section II sets our work apart from other approaches in the literature. Section III summarizes the system model and provides a brief overview of the BLE and the CR. Section IV describes CSIM in detail. Section V presents the simulation results. Finally, the paper is concluded in Section VI.

II. RELATED WORK

Avoidance and mitigation of channel interference have been extensively researched in the wireless communication literature. To the best of our knowledge, the published techniques in the realm of IoT are very few and can be categorized as resource sharing and allocation, power control, scheduling techniques and medium access schemes. Example schemes that pursued the resource sharing and allocation include [START_REF] Bakshi | EMIT An efficient MAC paradigm for the Internet of Things[END_REF], [START_REF] Torabi | A robust coexistence scheme for IEEE 802.15.4 wireless personal area networks[END_REF], [START_REF] Shigueta | A strategy for opportunistic cognitive channel allocation in wireless Internet of Things[END_REF], [START_REF] Ali | Distributed Scheme for Interference Mitigation of WBANs Using Predictable[END_REF]. Bakshi et al., [START_REF] Bakshi | EMIT An efficient MAC paradigm for the Internet of Things[END_REF] proposed a completely asynchronous and distributed solution for data communication across IoT, called EMIT. EMIT avoids the high overhead and coordination costs of existing solutions through employing an interference-averaging strategy that allows users to share their resources simultaneously. Furthermore, EMIT develops power-rate allocation strategies to guarantee low-delay highreliability performance. Torabi et al., [START_REF] Torabi | A robust coexistence scheme for IEEE 802.15.4 wireless personal area networks[END_REF] proposed a rapidresponse and robust scheme to mitigate the effect of interfering systems, e.g., IEEE 802.11, on WBAN performance. They proposed dynamic frequency allocation method to mitigate bi-link interferences that affect either the WBAN's Crd or WBAN sensors and hence impose them to switch to the same frequency. Shigueta et al., [START_REF] Shigueta | A strategy for opportunistic cognitive channel allocation in wireless Internet of Things[END_REF] presented a strategy for channel assignment in an IoT. The proposed strategy uses opportunistic spectrum access via cognitive radio. The originality of this work resides in the use of traffic history to guide the channel allocation in a distributed manner. Ali et al., [START_REF] Ali | Distributed Scheme for Interference Mitigation of WBANs Using Predictable[END_REF] proposed a distributed scheme that avoids interference amongst coexisting WBANs through predictable channel hopping. Based on the Latin rectangle of the individual WBAN, each sensor is allocated a backup time-slot and a channel to use if it experiences interference such that collisions among different transmissions of coexisting WBANs are minimized.

Xiao et al., [START_REF] Xiao | DaSilva: Full-duplex machine-to-machine communication for wireless-powered Internet-of-Things[END_REF] adopted the approach of power control and considered machine-to-machine, denoted by M2M, communication for an IoT network. The authors proposed a framework of full-duplex M2M communication in which the energy transfer, i.e., surplus energy, from the receiver to the transmitter and the data transmission from the transmitter to the receiver take place at the same time over the same frequency. Furthermore, the authors established a stochastic game-based model to characterize the interaction between autonomous M2M transmitter and receiver. Meanwhile, Chen et al., [START_REF] Chen | An area packet scheduler to mitigate coexistence issues in a WPAN/WLAN based heterogeneous network[END_REF] A number of approaches pursued the medium access scheduling methodology include [START_REF] Wang | Mouftah: ACK with Interference Detection Technique for ZigBee Network under Wi-Fi Interference[END_REF], [START_REF] Inoue | Novel coexistence scheme between wireless sensor network and wireless LAN for HEMS[END_REF], [START_REF] Zhang | Shin: Cooperative Carrier Signaling: Harmonizing Coexisting WPAN and WLAN Devices[END_REF] to mitigate interference among the IEEE 802.11 and IEEE 802.15.4 [START_REF] Movassaghi | Smith: Smart spectrum allocation for interference mitigation in Wireless Body Area Networks[END_REF], i.e., ZigBee, based devices. Wang et al., [START_REF] Wang | Mouftah: ACK with Interference Detection Technique for ZigBee Network under Wi-Fi Interference[END_REF] proposed a new technique, namely, the Acknowledgement, denoted by ACK, with Interference Detection (ACK-ID), that reduces the ACK losses and consequently reduces ZigBee packet retransmissions due to the presence of collocated IEEE 802.11 wireless networks. Basically, in ACK-ID, a novel interference detection process is performed before the transmission of each ZigBee ACK packet in order to decide whether the channel is experiencing interference or not. Inoue et.al., [START_REF] Inoue | Novel coexistence scheme between wireless sensor network and wireless LAN for HEMS[END_REF] proposed a novel distributed active channel reservation scheme for coexistence, called DACROS, to solve the problem of WBAN and IEEE 802.11 wireless networks coexistence. DACROS uses the request-to-send and clear-to-send frames to reserve the channel for a superframe time of WBAN. Along the whole beacon time, i.e., the whole superframe of the WBAN, all IEEE 802.11 wireless devices remain silent and do not transmit to avoid collisions. Zhang et al., [START_REF] Zhang | Shin: Cooperative Carrier Signaling: Harmonizing Coexisting WPAN and WLAN Devices[END_REF] proposed cooperative carrier signaling, namely, CCS, to harmonize the coexistence of ZigBee WBANs with IEEE 802.11 wireless networks. CCS allows ZigBee WBANs to avoid IEEE 802.11 wireless network-caused collisions and employs a separate ZigBee device to emit a busy tone signal concurrently with the ZigBee data transmission.

As pointed out, none of the predominant approaches can be directly applied to IoT because they do not consider the heterogeneity of the individual networks forming an IoT in their design. Motivated by the emergence of BLE technology and compared to the previous predominant approaches for interference mitigation, our approach lowers the power and communication overheads introduced on the coordinator-and sensor-levels within each WBAN.

Unlike prior work, in this paper, we propose a distributed protocol to enable WBAN operation and interaction within an existing IoT. We integrate a BLE transceiver to inform the WBAN about the frequency channels that are being used in its vicinity and a CR module within the WBAN's Crd. Our approach relies on both BLE transceiver and the CR module for stable channel selection and allocation for interference mitigation. The CR module, when engaged determines a set of usable channels for the Crd to pick from. Each interfering sensor will then switch to the new channel to retransmit data to the Crd in its allocated backup time-slot.

III. SYSTEM MODEL AND PRELIMINARIES

A. Bluetooth Low Energy

Bluetooth Low Energy (BLE) is one of the promising technologies for IoT services because of its low energy consumption and cost. BLE is a wireless technology used for transmitting data over short distances and broadcasting advertisements at a regular interval via radio waves. The BLE advertisement is a one-way communication method. BLE devices, e.g., iBeacons, that want to be discovered can periodically broadcast self-contained packets of data. These packets are collected by devices like smartphones, where they can be used for a variety of applications to trigger prompt actions. We envision that each collocated set (cluster) of wireless devices of such IoT will have to include a BLE transceiver that periodically broadcasts the channel that is being used by the IoT devices in the vicinity. In fact, with the increased popularity of BLE, it is conceivable that every IoT device will be equipped with a BLE transceiver to announce its services and frequency channel. Standard BLE has a broadcast range of up to 100 meters, which makes BLE broadcasts an effective means for mitigating interference between WBANs and other IoT devices.

B. System Model and Assumptions

The IoT environment consists of different wireless networks, each uses some set of common channels in the international license-free 2.4 GHz ISM band. In addition, we assume that each network transmits using different levels of transmission power, bandwidth, data rates and modulation schemes. Meanwhile, WBANs are getting pervasive and thus form a building block for the ever-evolving future IoT. We consider N TDMA-based WBANs that coexist within the general IoT. Each WBAN consists of a single Crd and up to K sensors, each transmits its data on a channel within the international license-free 2.4 GHz ISM band [START_REF]IEEE Standard for Local and metropolitan area networks -Part 15.6: Wireless Body Area Networks: IEEE Std[END_REF]. Basically, we assume all Crds are equipped with richer energy supply than sensors and all sensors have access to all ZigBee channels at any time. In addition, each Crd is integrated with BLE to enable effective coordination in channel assignment and to allow the interaction with the existing IoT devices. Furthermore, each Crd has a CR module to decide the usability and the stability of a channel.

IV. CHANNEL SELECTION APPROACH FOR INTERFERENCE MITIGATION -CSIM

A co-channel interference takes place if the simultaneous transmissions of sensors and the Crd in a WBAN collide with those of other IoT coexisting devices. The potential for such a collision problem grows with the increase in the communication range and the density of sensors in the individual WBANs as well as the number of collocated IoT devices. To address this problem, our approach assigns each WBAN a default channel and in case of interference it allows the individual sensors to switch to a different channel to be picked by the Crd in consultation with the CR module to mitigate the interference. The use of BLE enables the Crd to be aware of interference conditions faster and more efficiently. To achieve that, our approach extends the size of the superframe through the addition of flexible number of backup time-slots to lower the collision probability of transmissions. At the network setup time, each Crd randomly picks a default channel from the set of ZigBee channels and informs all sensors within its WBAN through a beacon to use that channel along the TDMA frame of the superframe, as will be explained below.

A. Network Operation under CSIM

CSIM depends on acknowledgements (Acks) and time-outs to detect the collision at sensorand coordinatorlevels. In the TDMA frame shown in Fig. 1, each sensor transmits its packet in its assigned time-slot to the Crd using the default channel and then sets a time-out timer. If it successfully receives an Ack from its corresponding Crd, it considers the transmission successful, and hence it sleeps until the TDMA frame of the next superframe. However, if that sensor does not receive an Ack during the time-out period, it assumes failed transmission due to interference. Basically, all sensors experienced interference within the TDMA frame wait until the FCS frame completes, and then each switches to the common interference mitigation channel. Afterwards, each sensor retransmits its packet in its allocated time-slot within the FBTDMA frame to the Crd. Algorithm 1 provides high level summary of CSIM. Table I shows notations and their corresponding meanings.

B. Channel Selection

Along the TDMA frame, each Crd's BLE collects information based on broadcast announcements made by other nearby BLE transceivers about the set of channels being used by wireless devices in the vicinity of a designated WBAN ({LCH}), and then reports this information to its associated CR. The CR uses the following sets of channels which are defined as follows:

• {G} : is a set of 16 channels available in the international license-free 2.4 GHz ISM band of ZigBee standard. • {LCH} : is a set of channels that are being used in the vicinity of a designated WBAN. • {defaultChannel} : is a singleton set that involves the default channel that is being used by a designated WBAN. • {US} : is a set that consists of the remaining ZigBee channels that are not being used in the vicinity of a designated WBAN, where {US} = {G} -{{LCH} ∪ {defaultChannel}}. In low or moderate conditions of interference, where there are some available channels, i.e., {US} is not empty, or the size of the set {LCH} is smaller than the size of the set {G}, the Crd will not exploit the service of the CR when notified by the BLE about a channel conflict; instead, the Crd selects one available channel from {US} for efficient data transmission. However, in high interference conditions, the set {US} will be empty. Therefore, once notified by the BLE, the Crd can not select one available channel from {US}, and hence the CR should scan the set {LCH} to eventually select the most stable channel to be used within the FBTDMA frame for interference mitigation. Basically, the designated CR looks for a usable channel from the set {LCH}, if the first channel is not, then it starts sequentially sensing channels until a usable channel will be found. If it finds a usable channel and satisfies the stability condition, then it reports its index to the associated Crd to be eventually used for interference mitigation [START_REF] Ala | Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications[END_REF].

C. Channel Stability

Our approach relies on CR to decide the usability and stability of a channel using the received noise power as an indicator (Y i ) [START_REF] Moungla | Distributed interference management in medical wireless sensor networks[END_REF]. Y i during time-slot i is given by Eq. 1.

Y i = 1 2u 2u j=1 n j × n j (1)
Where, u is the time-bandwidth product and n j is a Gaussian noise signal with zero mean and unit variance. The probability density function, denoted by f, of Y i is given by Eq. 2.

f Y i (y) = U Γ(.) ke -uy (2)
Where, Γ(.) is the gamma function, k = y u-1 and U = u u . Based on Y i , the CR decision criterion can be expressed as follows:

1) A channel C i is usable, if Y i < λ 1 2) C i requires power boost (usable), if λ 1 < Y i < λ 2 .
In this case, we can use the theorem of Shannon (1948) [START_REF] Coulon | Systemes de telecommunications[END_REF] of the maximum transmission capacity (P) given in bit/s in Eq. 3

3) C i cannot be used in time-slot i (unusable), if Y i > λ 2 ,
where λ 1 and λ 2 are thresholds depend on the receiver sensitivity and the channel model in use.

P = Blog 2 (1 + SN R) (3)
Thus, the range of Y i is divided into three regions, and is given by Eq. 4.

R j = {Y i : λ j-1 ≤ Y i ≤ λ j }, j = 1, 2, 3 (4)
Where λ 0 is equal to 0 and λ 3 is equal to ∞. We mean by, a stable channel, if the probability of channel quality can not be decreased before the end of the transmission on that channel. The probability to being in a stable state j is given by Eq. 5.

π j = P r{Y i ∈ R j } = P r{λ j-1 ≤ Y i < λ j }, j = 1, 2, 3 (5)
The integration is done between λ j-1 and λ j . When the CR is engaged, it looks for a usable and stable channel which is done in the steps below.

Step 1: Crd looks for n usable channels. If the first channel is not, then the CR starts sequentially sensing channels until a usable channel is found. If the CR module finds a usable channel, then Step 2 is executed to test the stability of the selected channel. Otherwise, the CR module informs Crd that no usable channel is available, Crd stays silent during a predetermined time-slot.

Step 2: If the selected usable channel satisfies the stability condition, then CR reports the index of this stable channel back to Crd.

D. Proposed Superframe Structure

In WBANs, sensors sleep and wake up dynamically and hence, the number of sensors being active during a period of time is unexpected. Therefore, a flexible way of scheduling different transmissions is required to avoid interference. We consider each WBAN's superframe delimited by two beacons and composed of two successive frames: (i) active, that is dedicated for sensors, and (ii) inactive, that is designated for Crds. The superframe structure is shown in Fig. 1. During the inactive frame, Crds transmit collected data to a command center. In addition, the inactive frame directly follows the active frame and whose length depends on the underlying duty cycle being used. However, the active frame is further divided into three successive frames.

1) Traditional TDMA Data Collection Frame -TDMA

The traditional TDMA frame consists of up to K time-slots that are allocated to sensors. Each WBAN's sensor transmits its packet to its associated Crd in its allocated time-slot using the default channel.

2) Channel Selection Frame -FCS

During the FCS which is of a fixed size, each WBAN's Crd selects a stable interference mitigation channel and instructs all interfering sensors within its WBAN to use that channel during the FBTDMA frame. Based on the number of interfering sensors, each Crd determines the size of the FBTDMA frame and reports this information through a short beacon broadcast using the default channel to the designated sensors within its WBAN. In addition, the Crd allocates a time-slot within the FBTDMA frame for each interfering sensor to eventually retransmit its packet. Although, the beacon could be lost due to the interference, our approach enables early mitigation. Basically, the BLE alert limits the probability of collision on the default channel since the Crd will get a hint earlier than typical.

3) Flexible Backup TDMA frame -FBTDMA

The FBTDMA frame consists of a flexible number of backup time-slots that depends on the number of sensors experiencing interference in the TDMA frame. Basically, each Crd knows about these sensors through using the expected number of acknowledgement and data packets received in an allocated time-slot for each sensor. In FBTDMA frame, each interfering sensor retransmits in its allocated backup time-slot to the Crd using the selected stable channel.

V. PERFORMANCE EVALUATION

In this section, we have conducted simulation experiments to evaluate the performance of the proposed CSIM scheme. We compare the performance of CSIM with smart spectrum allocation scheme [START_REF] Movassaghi | Smith: Smart spectrum allocation for interference mitigation in Wireless Body Area Networks[END_REF], denoted by SSA, which assigns orthogonal channels to sensors belonging to the interference set, denoted by IS, formed between each pair of the interfering WBANs. Furthermore, we compare the energy consumption of the WBAN's coordinator with and without switching the BLE transceiver on [START_REF] Lindhh | Measuring Bluetooth Low Energy Power Consumption[END_REF]. We define the probability of channel's availability, denoted by P r AvChs , at each Crd as the frequency Crd i picks one def aultChannel i from {G}; 5:

for J = 1 to K do 6: S i,j transmits P kt i,j in T S i,j to Crd i on def aultChannel i ; 7:

if S i,j receives Ack i,j on def aultChannel i then 8:

S i,j sleeps until next superframe; S i,j waits its IM T S i,j within F BT DM A i frame; that a channel is not being used by any of the nearby IoT devices. An IoT cluster is defined as a collection of WBANs, Wi-Fi and other wireless devices collocated in the same space. The simulation network is deployed in three dimensional space (10 × 10 × 4m 3 ) and the locations of the individual WBANs change to mimic uniform random mobility and consequently, the interference pattern varies. The channel interference between any two wireless devices is evaluated on probabilistic interference thresholds. The simulation parameters are provided in Table II.

A. Probability of channel's availability 1) Probability of channel's availability vs. number of WBANs

In experiment 1, the probability of channel's availability, denoted by P r AvChs , versus the cluster size, denoted by Ω, for CSIM and SSA are compared, and results are shown in Fig. 2. As seen in the figure, CSIM always provides a higher P r AvChs than SSA because of the channel selection is done at the WBANrather than sensor-level. For CSIM, the P r AvChs significantly decreases from 0.79 to 0.27, when 5 ≤ Ω < 40 because of the larger number of ZigBee channels that are being used by IoT devices than the number of channels available at each Crd. When Ω ≥ 40, P r AvChs decreases very slightly and eventually stabilizes at 0.215 because all ZigBee channels are used by the IoT devices which makes it very hard for Crds to select stable channels. However, for SSA, it is also observed from this figure that P r AvChs decreases significantly from 0.51 to 0.08 when 5 ≤ Ω < 35 because of the larger number of ZigBee channels that are being assigned to the sensors in the interfering set (IS) for any pair of WBANs. When Ω ≥ 35, P r AvChs decreases very slightly and eventually stabilizes at 0.07 because of the maximal number of ZigBee channels being assigned to sensors coexisting within the interference range of a designated WBAN, i.e., the number of these sensors exceeds the 16 channels of ZigBee.

2) Probability of channel's availability vs. signal-to-noise ratio threshold Experiment 2 studies the effect of signal-to-noise ratio threshold denoted by SN R T hr on P r AvChs . The results in Fig. 3 shows that CSIM always achieves higher P r AvChs than SSA for all SN R T hr values. In CSIM, the P r AvChs significantly increases as SN R T hr increases from -50 to -35; similarly increasing SN R T hr in CSIM diminishes the interference range of each WBAN, i.e., lowers the number of interfering IoT devices. Therefore, limiting the frequency of channel assignments prevents distinct WBANs to pick the same channel, which decreases the probability of collisions among them. When SN R T hr ≥ -35, the P r AvChs increases very slightly and eventually stabilizes at 0.92 because of the minimal number of interfering IoT devices and hence, a high P r AvChs is expected due to the larger number of ZigBee channels than the number of those interfering devices. However, SSA always achieves lower P r AvChs than CSIM for all SN R T hr values. The P r AvChs significantly decreases from 0.6 to 0.2 as SN R T hr increases from -50 to -25.

Basically, increasing SN R T hr in SSA is similar to increasing the interference range of each WBAN, and hence putting more sensors in the WBAN interference set. Therefore, more channels are needed to be assigned to those sensors and that P r AvChs is reduced. When SN R T hr ≥ -25, the P r AvChs eventually stabilizes at 0.21 because of the maximal number of sensors in the interference set is attained by each WBAN.

3) Probability of channel's availability vs. number of sensors Experiment 3 studies the effect of the number (#) of sensors per a WBAN, denoted by δ, on P r AvChs . As can be seen in Fig. 4, CSIM always achieves higher P r AvChs than SSA for all values of δ. It is also observed from this figure that P r AvChs decreases very slightly and from 0.905 to 0.8 when 2 ≤ δ ≤ 10 and eventually stabilizes at 0.8 when δ ≥ 10. In both cases, the P r AvChs is high due to two reasons, 1) the number of WBANs is fixed to 10 which is smaller than the number of ZigBee channels, which makes it possible for two or more distinct WBANs to not pick simultaneously the same channel and, 2) CSIM selects a stable channel based on the number of interfering WBANs rather than the number of interfering sensors. However, the P r AvChs decreases significantly from 0.9 to 0.1 when 2 ≤ δ ≤ 14 because adding more sensors into WBANs increases the probability of interference and consequently requires more channels to be assigned to those sensors; consequently P r AvChs is reduced. Furthermore, SSA assigns channels to interfering sensors rather than to interfering WBANs, which justifies the decrease of P r AvChs when δ grows. When δ ≥ 14, the P r AvChs eventually stabilizes at 0.1 because of the maximal number of sensors in the interference set is attained by each WBAN. 4) Average reuse factor vs. interference threshold Fig. 5 shows the average reuse factor, denoted by avgRF, versus the interference threshold, denoted by ρ, for all WBANs. As seen in this figure, CSIM achieves a higher avgRF for all ρ values. However, increasing the interference threshold puts more interfering sensors in the interference range of any specific WBAN than the corresponding WBANs of these sensors, i.e., SSA requires more channels to be assigned to sensors than to WBANs in CSIM.

5) Energy consumption vs. interference threshold

The average energy consumption of the WBAN coordinator, denoted by avgEC, versus the interference threshold (ρ) for CSIM with (CSIM-W) and without switching the BLE transceiver on (CSIM-WO) are compared, and results are shown in Fig. 6. As seen in the figure, CSIM-W always provides a lower avgEC than CSIM-WO because of the earlier BLE alerts of interference to the coordinator, i.e., the coordi-nator scans the channels only upon receiving of these alerts. For CSIM-W, the avgEC increases slightly as the interference threshold grows, which increases the number of interfering sensors, hence the frequency of BLE alerts of interference increases, and consequently, the energy consumption increases due to the additional scanning. When ρ exceeds -20, the avgEC increases very slightly and eventually stabilizes at 0.46 × 10 -3 mW; this reflects the case where all channels are used by nearby IoT devices forcing the Crd to engage the CR for finding a stable channel. For CSIM-WO, the avgEC increases significantly with all values of ρ because of the continuous scanning of all ZigBee channels all the time, i.e., the coordinator periodically scans all the channels to find out which channels are not noisy. It is worth saying that the BLE alerts reduces the frequency of channel scanning and hence saves the coordinator's energy.

VI. CONCLUSIONS

In this paper, we have presented CSIM, a distributed protocol to enable WBAN operation and interaction within an existing IoT. CSIM leverages the emerging BLE technology to enable channel selection and allocation for interference mitigation. In addition, the superframe's active period is further extended to involve not only a TDMA frame, but also a FCS and FBTDMA frames, for interference mitigation. We integrate a BLE transceiver and a CR within the WBAN's coordinator, where the role of the BLE transceiver is to inform the WBAN about the frequency channels that are being used in its vicinity. When experiencing high interference, the BLE device notifies the WBAN's Crd to call the CR which determines a different channel for interfering sensors that will be used later within the FBTDMA frame for interference mitigation. The simulation results show that CSIM outperforms sample competing schemes.

Figure 1 .

 1 Figure 1. Proposed superframe structure

Algorithm 1

 1 Proposed CSIM Scheme Require: N WBANs, K Sensors/WBAN, G ZIGBEE Channels/WBAN 1: Stage 1: Network Setup & TDMA Data Collection 2: Sensor-level collision: 3: for i = 1 to N do 4:

Figure 2 .Figure 3 .Figure 4 .

 234 Figure 2. Probability of channel's availability (P r AvChs ) versus cluster size (Ω)

Figure 5 .Figure 6 .

 56 Figure 5. Average reuse factor (avgRF versus interference threshold (ρ)

  th sensor of i th WBAN def aultChannel i default channel of i th WBAN stableChannel i stable channel of i th WBAN Crd i coordinator of i th WBAN BLE i bluetooth low power device of i th coordinator CR i cognitive radio module of i th coordinator P kt i,j j th packet of i th sensor Ack i,ji th acknowledgement transmitted to j th sensor T S i,j j th time-slot of i th TDMA frame IM T S i,j j th time-slot of i th FBTDMA frame LCH i i th set of channels used by nearby IoT devices LIS i i th list of interfering sensors in T DM A i

		Table I
		NOTATIONS AND MEANINGS
	Notation	Meaning
	W BAN i	i th WBAN
	S i,j j FCS Flexible Channel Selection
	FBTDMA	Flexible Backup TDMA

  Crd i transmits Ack i,j in T S i,j to S i,j on def aultChannel i ; Crd i will tune to stableChannel i,j within F BT DM A i frame; BLE i forms the set {LCH i }; 26: Crd i forms the set {LIS i }; 27: Stage 2: Channel Selection 28: for i = 1 to N do Crd i forms F BT DM A i frame from {LIS i }; CR i selects stableChannel i from {U S i }; Crd i informs LIS i sensors by stableChannel i & F BT DM A i frame; 32: end for 33: Stage 3: Interference Mitigation 34: for i = 1 to N do S i,s retransmits P kt i,s in IM T S i,s on stableChannel i ; 37: if Ack i,s received by S i,s on stableChannel i then Crd i receives an earlier BLE i alert of interference;

	11:	end if
	12:	end for
	13: end for
	14: Coordinator-level collision:
	15: for i = 1 to N do
	16:	for j = 1 to K do
	17:	if Crd i	receives P kt i,j	in T S i,j	on
		def aultChannel i then
	18:
	19:	else
	20:
	21:	end if
	22:	end for
	23: end for
	24: Channel Selection Setup:
	25: 29:
	30:
	31:
	35:	for s = 1 to size-of({LIS i }) do
	36:
	38:	S i,s sleeps until next superframe;
	39:	else
	40:
	41:	end if
	42:	end for
	43: end for


Florent Fourcot

Laurent Toutain

Stefan Köpsell
email: stefan.koepsell@tu-dresden.de

Frédéric Cuppens

Nora Cuppens-Boulahia

IPv6 address obfuscation by intermediate middlebox in coordination with connected devices

Keywords: IPv6, Privacy, Security, Address Management

 are not optimal, still only one address is in use for several communications over time. And it does not offer control of the network by the administrator (end devices use randomly generated addresses). Our IPv6 privacy proposal uses ephemeral addresses outside the trusted network but stable addresses inside the local network, allowing the control of the local network security by the administrator. Our solution is based on new opportunities of IPv6: a large address space and a new flow label field. In combination with Cryptographically Generated Addresses, we can provide protection against spoofing on the local network and enhanced privacy for Internet communication.

Introduction

If IPv4 is still the most popular IP stack, IPv6 leaves the laboratory to be deployed on the Internet. For example, a lot of popular websites activated IPv6 on 6th June 2012 [START_REF]World IPv6 launch[END_REF], and the French Internet provider "Free" offers IPv6 connectivity for new clients by default. This activation of IPv6 is not without privacy issues like the possibility to trace a device, thanks to the interface identifier stability [START_REF] Lindqvist | IPv6 is bad for your privacy[END_REF]. Indeed, an IPv6 address is made of two parts. The first one is the routing information, read by routers across the Internet. The second part is the interface identifier, locally generated but worldwide readable. The default stateless configuration uses the MAC address to generate this interface identifier, without other parameters [START_REF] Hinden | IP Version 6 Addressing Architecture, RFC 4291[END_REF]. This means that initially the interface identifier of a device is always the same, regardless of the connected network; the device is traceable across the whole world.

To obfuscate this interface identifier, there exist full fledge anonymous communication solutions, e.g. based on the ideas of mixes [START_REF] David | Untraceable electronic mail, return addresses, and digital pseudonyms[END_REF] like AN.ON [START_REF] Berthold | Web mixes: A system for anonymous and unobservable internet access, Designing Privacy Enhancing Technologies[END_REF] or Tor [START_REF] Dingledine | Tor: The secondgeneration onion router[END_REF]; DC networks [START_REF] Chaum | The dining cryptographers problem: Unconditional sender and recipient untraceability[END_REF] and many similar proposals. This class of solutions offers high grade of protection even against powerful attackers but at the price of complex design and deployment. In our paper we focus on a light weight construction which offers protection only against weaker attackers. More specific we assume an attacker outside of the trusted network. A prominent example would be a web service which tries to reidentify its users.

One existing light weight solution called Privacy Extensions is defined in RFC 4941 [START_REF] Narten | Privacy Extensions for Stateless Address Autoconfiguration in IPv6, RFC 4941[END_REF]. Privacy extensions are compatible with the stateless autoconfiguration, but this solution is not really satisfactory. Usually the same address is used over a long period of time, because changing the address implies disconnection of all active connections. Thus there is a trade off between relatively stable connections versus a real privacy gain. Second, by using only one address, Privacy Extensions do not take advantage of the large IPv6 space. All applications of the connected device will use the same address, therefore an eavesdropper can easily link different communications of the same device, e.g. Instant messaging communication and the Web traffic.

From a network administrator perspective, Privacy Extensions might be unacceptable because it makes logging user's connections more cumbersome. This logging is mandated by law in some countries, i.e. administrators have to reveal who was using a given address in case of court order or police investigations. One solution is to deploy the complex DHCPv6 protocol with distribution of temporary addresses, standardized in RFC 3315 [START_REF] Droms | Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3315[END_REF]. With this stateful protocol, assignments of temporary addresses can be stored and are accessible to future requests. Nevertheless, it does not solve the disconnection problem in case of address switching and still does not utilize the large address space.

Another way to manage IPv6 addresses is to use Cryptographically Generated Addresses (CGA) [START_REF] Aura | Cryptographically Generated Addresses (CGA), RFC 3972[END_REF]. CGA addresses are generated by the host itself, and can be used to improve the security of communications. One example is the use of CGA in conjunction with SEcure Neighbor Discovery [START_REF] Arkko | SEcure Neighbor Discovery (SEND), RFC 3971[END_REF] to prevent address spoofing on the local network. The interface identifier of a CGA address is based on a cryptographic hash function, and looks like a random address for an outsider. But the computational cost of CGA generation with an adequate security level is high [START_REF] Alsa'deh | Stopping time condition for practical IPv6 Cryptographically Generated Addresses[END_REF] and prevents to use it as a privacy solution with high frequency of CGA calculation.

Our solution does not change the management of IPv6 assignment, and is compatible with stateless autoconfiguration, DHCPv6 and CGA. To improve the privacy of users, we introduce a middlebox, traditionally the border router of the network or the local firewall. On an IPv4 network, the middlebox is frequently a Network Address Translator (NAT) [START_REF] Srisuresh | IP Network Address Translator (NAT) Terminology and Considerations[END_REF], and is already more "intelligent" than a simple router. An example of middlebox on the IPv6 network is a Network Prefix Translation (NPTv6) device [START_REF] Wasserman | IPv6-to-IPv6 Network Prefix Translation[END_REF]. NPTv6 is an experimental solution to change the prefix of addresses, using a one-to-one mapping. In contrast, our middlebox is in charge of spreading addresses across all locally available addresses, typi-cally a /64 network, this means more than 10 20 addresses. To accomplish this spreading, the middlebox assigns a random address for each flow sent by local devices and rewrites the source address accordingly. This spreading divides the network in one trusted space with stable addresses and one untrusted network (the Internet) with ephemeral addresses. Moreover, this rewriting can be easily activated or deactivated for each flow.

This paper is organized as follow: we describe the architecture of our solution in Section 2, we describe our implementation in Section 3, we discuss impacts and consequences in Section 4. We continue in Section 5 with a solution for assigning flow labels by application. Section 6 presents a performance measurement. Finally, Section 7 and 8 conclude the paper.

2 Proposal of Architecture

Overview of new IPv6 opportunities

Our solution is based on two new opportunities offered by IPv6, namely a large address space and flow labels.

Large address space: IPv6 addresses are encoded in a 128 bits field, it means that 2 128 addresses are available, more than 10 28 addresses for each people alive today. As shown in the introduction, each address is split into two main parts and the first part is used for the routing and identifies a network. This main part of network identifier is assigned by an Internet provider to a company or home network. The second part of the address is the interface identifier. It can be locally managed and identifies the connected device on the network. The size of the locally manageable part is not always the same, but the recommendation is to give not less than 64 bits to the end network [START_REF] Van De Velde | IPv6 Unicast Address Assignment Considerations[END_REF]. This means that with thousands of connected computers, each with one address in use, less than 0.00000000000001% of the address space is used. Therefore, if the IPv4 address management has to minimize the number of addresses in use, we can build new paradigms based on abundance of addresses in IPv6.

The flow label is a new 20 bits field in IPv6. The usage has been experimental for a long time, but after extensive discussions [START_REF] Amante | Rationale for Update to the IPv6 Flow Label Specification[END_REF][START_REF] Hu | Survey of Proposed Use Cases for the IPv6 Flow Label, RFC 6294[END_REF], it has been standardized in 2011 [START_REF] Amante | IPv6 Flow Label Specification[END_REF]. The purpose of the field is to simplify the flow classification in order to apply some policies without complex packet inspection (like the well known 5-tuple in IPv4). The flow label is added by connected devices, which are easily able to discriminate flows without additional computational overhead. The recommended usage of this field is Quality of Service oriented (for example to prioritize real time communications), but this classification can have other use cases, summarized in RFC 6294 [START_REF] Hu | Survey of Proposed Use Cases for the IPv6 Flow Label, RFC 6294[END_REF].

Overview of the solution

To increase the user's privacy, we propose to assign one external address per flow. For each independent flow of packets, the connected device assigns a new flow label 3 . Then, the middlebox assigns a new external address to each pair of (internal IP address, flow label ) and rewrites the source addresses of the outgoing packets and the destination addresses of the incoming packets (cf. Figure 1). Because the middlebox is in position of a border router, it receives all the packets from the local network. Therefore, it does not need to send extra neighbor discovery packets. In contrast, if the rewriting happens on the end devices, this solution implies some active neighbor discovery. Since some applications can be incompatible with address rewriting (similar to the implications of NAT in IPv4 [START_REF] Hain | Architectural Implications of NAT, RFC 2993[END_REF]), a flow label set to zero is a signal to forbid rewriting. This special label can be used if a temporary address is undesirable, for example in case of IP source address filtering on the destination device or an incompatible application layer.

To summarize, the intelligence to discriminate flows and optimize privacy is based on the end device, and all rewritings are based on the middlebox, i.e. under control of the network administrator. There is no need to change local address assignment policy. The middlebox should be located between the local firewall and the Internet; it prevents to rewrite firewall policies.

Computation on the middlebox

Since the "intelligence" of flow classification is with in in the connected devices, the middlebox does not need to do a complex parsing of packets' headers, and to follow a TCP stream in a stateful way. But it has to maintain a context to perform rewriting (cf. Table 1). For each outgoing packet with an unknown pair (internal IP address, flow label ) (short (IP int , label)) the middlebox creates a context and generates a random interface identifier, which creates an address by concatenation with the prefix, named external IP address (short IP ext ). The stored context is a 3-tuple (IP int , label, IP ext ), and all following packets matching the pair (IP int , label) will be rewritten with the IP ext . For all incoming packets, the middlebox rewrite the destination address with IP int if a context exists, or applies standard routing and firewall policies.

Note that a flow (defined by all packets sharing the same source IP and the same flow label) can be made of more than one TCP connection (or other transport protocols). For example, we recommend to use the same flow for all the elements of a given Web page. The middlebox itself does not care about upper protocol layers, because the flow assignment is done on the end device.

Flow label assignment by application

The connected device is in the best place to discriminate flows and to assign flow labels. For example, a peer-to-peer application probably needs to use the same address for more than one TCP connection, a Web browser knows if one connection is related to another, etc. In our case, the best way is to patch the application to assign flow labels efficiently.

To help a fast deployment of our solution, we propose an assignment of a flow label per application in Section 5.2.

Implementation of the middlebox

To test our solution, we implemented and deployed the middlebox in a real network environment. The middlebox is based on a standard Linux Kernel, and we added a Netfilter module to spread addresses. The middlebox has to rewrite addresses for outgoing and incoming packets. The limitation of our current implementation is that it can only be load on one interface connected to the Internet and does not yet support multihoming.

Packets processing

Outgoing packets: for each outgoing packet, we read the flow label information. If this label is zero, we stop the work of the module and the standard policy of the kernel is applied. Otherwise, we check if a context with the pair of source address and flow label already exists.

If we do not have a context, we have to create one. The first step is to generate a random address, and to check if the address is not in collision as explained in Section 4.2. The prefix part is static and can not be rewritten, but it is possible to configure the length of the prefix (routing information), to maximize the size of the rewritable address part. We added the new external address to the pair (source IP address, flow label ), and happen this context to the context table.

If a context exists, or after the initialization of a context, we rewrite the source address with the value stored in the fetched context. Afterwards we have to adjust the transport layer checksum. There is no standard way to rewrite this checksum, therefore we have to write code for each protocol. Currently, our implementation supports the three most popular protocols: TCP, UDP and ICMP (cf. Section 4.1). After this rewriting, we return the packet to apply standard kernel policy.

The flow label is no longer useful after the middlebox, and is set to zero.

Incoming packets: for incoming packets, we only read the destination address.

We check if a context exists for this address. If not, the packet is transmitted in the standard kernel way. Otherwise, we rewrite the destination address with the value stored in the context and we adjust the transport layer checksum.

Identification of a context

The identification of a context has to be efficient on both directions. The identification of outgoing flows is done by matching the source address and the flow label with all existing contexts. For incoming packet, the identifier of the context is the destination address. We implement these searches with two hash tables, one for outgoing packets using "source IP address + label" as key value, and the second one for incoming packet using destination address as key value. This double hash table allows fast matching between packets and contexts.

Cleanup of old context

At the termination of a flow, the middlebox should remove the corresponding context to potentially reassign the address and to free the memory used. But in the IP network, there is no concept of connection and there are no communication messages to signal the end of a flow. In IPv4 networks, RFC 4787 and 5382 [START_REF] Audet | Network Address Translation (NAT) Behavioral Requirements for Unicast UDP[END_REF][START_REF] Guha | NAT Behavioral Requirements for TCP[END_REF] give some recommendations to maintain a connection context for a NAT. But in your case, it is not possible (and desirable) to trace the state of a TCP connection. On the one hand, a flow can span more than a single TCP connection, on the other hand additional transport protocols can be in use. The only available solution is to introduce a timeout after an inactivity period. It should not be less than 120 seconds, according to recommendation for IPv4. A large timeout period will help to avoid breaking established connections, at cost of resource consumption. Based on our empirical tests, we recommend a value of 30 minutes, which give a good trade-off between resource consumption and connection stability. But the local administrator could overwrite this standard configuration in case of particular needs like long inactive TCP connections.

Impacts and consequences

Checksum computation

In IPv6, there is no checksum contained in the IP header but the transport layer protocols like TCP and UDP are in charge of error detections and therefore utilize a checksum. This checksum needs to be adapted if a rewriting happens. Fortunately, the flow label is not part of the checksum calculation and can be overwritten without implication. Nevertheless, the source address rewriting has an impact on the transport layer protocol checksum.

The large IPv6 address space supports some checksum neutral modifications, like in NPTv6 [START_REF] Wasserman | IPv6-to-IPv6 Network Prefix Translation[END_REF]. But in our case this solution is unacceptable. A checksum neutral modification gives a way to group all rewritten addresses of a device, with a simple checksum calculation of the source address. This removes the unlinkability between several random addresses.

But thanks to good properties of the standard Internet checksum, the cost of checksum computation is low, and an incremental update is possible [START_REF] Rijsinghani | Computation of the Internet Checksum via Incremental Update[END_REF]. We do not need to completly recompute new checksum C new of a packet, since we can easily add the difference C D between the 16-bit checksum C int of the internal IP address and the 16-bit checksum C ext of the external IP address to the already computed checksum C old : C new = C old + C D . During the initialization of the context, the middlebox will calculate C D = C int -C ext once, and caches this value.

Risk of collision

Each generated address has to be unique behond the all local subnet, in order to not disturb the network. As a consequence, the new address should not be already used by the middlebox nor should it be assigned to any local device by any other means. The first condition can be checked easily by looking at the context table. The verification of the second condition is more complex, especially if the rewriting use the same prefix for IP int and IP ext . Here, there is a risk of collisions between the randomly generated addresses and addresses already assigned to end devices. One solution could be to check if the address is not already in use, using a neighbour discovery (NDP). But this is unacceptable for at least two reasons. First, it increases the latency for all connection initializations, because the middlebox has to wait until the NDP timed out before making a decision. Second, no response to a NDP request does not mean that this address is not in use, e.g. the device can currently be down. To mitigate the problem, we propose the following:

-The middlebox can be configured to not use the autoconfiguration space derived from the MAC address (this means removing results with 4th byte and 5th byte set to 0xFF and 0xFE respectively). This configuration should be enabled by default to prevent a conflict with the standard configuration; -In case of DHCPv6 address distribution, the DHCP address space should not be included in the rewriting space configured on the middlebox;

-In case of CGA or static configured addresses, the administrator can manually forbid addresses; -In any case, the middlebox should maintain a list of devices currently in communication. Clearly this is not exhaustive, since devices can be connected without established connections.

These four rules eliminate the risk of collisions in most networks, and minimize it for some special cases. Additionally, it is important to notice that the risk of collision is actually very low -even without applying the rules mentioned above. The evaluation of the probability of a collision is a variant of the "birthday paradox". Given a pool of n addresses and already j addresses assigned, the probability p(n, j) to choose the j + 1 address without collision is:

p(n, j) = 1 - j n = n -j n (1)
This means that if we assign J addresses in a free space, we have a probability to not have any collision of:

P (n, J) = p(n, 0).p(n, 1) . . . p(n, J -1) = n • (n -1) . . . (n -J + 1) n J (2)
Then, the probability to have at least one collosion is:

P (n, J) = 1 -P (n, J) = 1 - n • (n -1) . . . (n -J + 1) n J (3)
That we can write:

P (n, J) = 1 -1 - 1 n • 1 - 2 n . . . 1 - J -1 n (4)
Since for all i in 1 . . . J: i ≤ J, we can give an upper bound for the probability with:

P (n, J) ≤ 1 -1 - J -1 n J-1 (5)
We can now perform an evaluation of this probability. In a network with only one prefix of the minimal size for auto-configuration, the interface identifier uses 64 bits. Two bits are reserved for special purpose, so only 62 bits are actually free. We can calculate n = 2 62 . On a big network with one thousand computers, where each of them maintains one thousand flows, we need to allocate J = 1000•1000 = 10 6 addresses. A simple computation informs us than the probability of collision is less than 2.2 • 10 -7 .

Compatibility analysis

In order to support wide spread deployment it is essential that our solution integrates smoothly into existing networks. In our case, we only need to deploy the middlebox at the border of the network and an adaptation of the end devices to enable address rewriting. More specific the necessary changes are as follows:

Remote routers and servers: since our solution is based on standard IPv6 packets, it is compatible with the standard IPv6 network. There is no need to upgrade intermediate routers or remote servers. We can deploy it locally without cooperation or impact on other networks, the real source address is obfuscated but the packet is still valid.

Local devices: for local devices, packets without flow label are not rewritten and therefore there are no compatibily implications. But to use the benefits of our solution, upgrades are usually necessary. First, not all Operating Systems (OSes) provide means to set flow labels. Second, on compatible OSes, there applications have to actually use the flow label option. We discuss assignment of flow labels in Section 5.2.

Common address translation issues: Address rewriting is a kind of address translation and can have some consequences. First, some applications send the IP address to the peer within the application layer protocols, for example File Transfer Protocol (FTP) and Session Initiation Protocol (SIP). If transmitting the address at the application layer is mandatory for a given protocol, we can not easily rewrite the address.

For IMCP packets, we have to rewrite the internals addresses in quoted ICMP packet too. It makes parsing a little bit complexer but it does not break ICMP messages.

In case of IPSec, we are in the same case than NPTv6 and the conclusion is the same: peers should detect an address translator, so IPSec should work.

In all cases, our solution is better than standard address translation since it can be easily disabled. For all connections that are not compatible, the applications can set the flow label to zero, the default value.

5 Flow label assignment at end devices 5.1 Link between applications and operating system: flow label management API

Unfortunately, there is no standard Application Program Interface (API) between a software package and an operating system to set or request a flow label. RFC 3542 [START_REF] Stevens | Advanced Sockets Application Program Interface (API) for IPv6, RFC 3542[END_REF] is the last standardized API for IPv6, and we can read "This API does not define access to the flow label field, because today there is no standard usage of the field". Without standardized API, each operating system has a specific approach to set and configure flow labels, and it is not easy to write portable software. This is why our work focuses only on the Linux kernel. The Linux Flow Label API is 13 years old, and part of the Kernel since the version 2.2.7, released in April 1999. Design decisions of the implementation are explained in [START_REF] Alexey | IPv6 flow labels in Linux-2.2[END_REF], and there is nothing really new since this time. This document is still the reference documentation for this API.

How to patch applications on Linux

Our proposition is simple: each application discriminates flows and sets flow labels for outgoing sockets, and if it is not done, the operating system has to set a flow label for all sockets of an application. The user can deactivate this kernel behavior (for example with the help of an environment variable).

Thanks to the GNU linker ld, it is possible to preload some libraries for dynamically linked software (the kind of linkage used by nearly all Linux distributions). We can intercept the call to the connect() function. Here we check if a flow label is already set, in this case we continue with the standard connect() function. Otherwise, we enable the flow label and set its value (derived from the process identifier PID) via the setsockopt() function.

Using this approach, we do not have to patch every application to use the spreading. At the same time, it does not interfere with a patched application since it does not overwrite an existing flow label value. Even if this is not an optimal solution, the gain is high in comparison with using just one address for all applications running on a given computer.

Performance evaluation

In the following sections, we discuss various performance aspects of our solution.

Memory consumption on the middlebox

Within a context, we have to store:

the real source address IP int of the computer (128 bits); the randomized source address IP ext (128 bits); the flow label (20 bits), stored in an integer (32 bits); the cached checksum difference C D (16 bits); the "last seen" value, to remove old entries (same size as jiffies 64 kernel variable, i.e 64 bits); two node structures in the hash tables (128 bits each);

The total size is about 80 octets for each context. With the current hypothesis of 1000 computers with 1000 flows each, we need about 80MB to store all contexts. On a home network with 5 computers and 100 flows each, less than 100KB of memory is necessary.

Moroever, each context needs less space than a usual entry of the conntrack table used for NAT in IPv4. Therefore, the memory consumption of our solution will not be a problem for modern routers with NAT capacities.

Latency

Overhead of rewriting on the middlebox Our implementation adds extra computation on the middlebox, before the routing of a packet. This adds some latency for packet treatment. But this computation is simple and it does not show any impact on the latency in our test networks. On a test bed with a standard latency of 300ms, it was not possible to see any impact on the latency. Overhead of the library preload A second potential latency cost comes from the library preload, to assign a flow label to each application. Our tests were done on a virtual machine with a 2.4Ghz CPU allocated. We run 20.000 times four different tests:

open and read a short file. The library preload is not enabled; the same command, but with library preload enabled; a short netcat command, this sends an UDP datagram to localhost and quits, without library preload; the same netcat command, with library preload enabled.

Figure 2 shows the measured times for the 20.000 iterations. The difference between the two file readings comes from the load of the library at the startup, even if the library does nothing. For each run, it introduces a latency of 5.10 -5 seconds, but only at the startup of the software (we need to load the library only once). The difference between the two netcat tests reveals the total overhead of the library, with the time to set up the flow label included. If we subtract the time to load the library, we get a latency overhead of 9.10 -6 seconds for each connection, Kernel time included.

As expected, our preload library does not have significant influence on the overall latency.

CPU consumption on the middlebox

To evaluate the CPU consumption of our solution, we made a profiling of the Kernel. We used the OProfile software, part of the standard tools of the Linux Kernel package. Our results show that our module needs about 10% of the time needed by the network card driver itself. With a bandwidth of 2.2Gb/s our module uses less than 2.5% of the CPU time of the 2.4Ghz CPU used.

Additionnaly, we install our solution in a home network on a standard router (Asus-rt16) and we do not see any CPU consumption overhead4 .

Future works

Currently our solution allows only to activate or deactivate the address rewriting (encoded by setting the flow label to zero). One of our ideas is to encode more data in the 20 bits of flow labels. The first bit could be used as a flag for a stateful firewall, to allow or deny incoming connections on the ephemeral address. This can be very useful in case of peer-to-peer connections.

Another possibility is to signal to disable the rewriting of the flow label to zero. This can be relevant if an upstream router uses the flow label for Quality of Service. Finally, a configuration of the timeout before erasing a context could be added too. All this flags improve the possibility of the client to adapt to specific communication context. We have enough space to provide five flags, since 32768 flows (15 bits left) should be enough to numbering all flows of a device.

Another improvement can be done in case of multihoming of the middlebox. The flow label tagging allows us to assign one outgoing interface for each flow, thus it allows us to make some load balancing on the middlebox.

Conclusion

Our solution provides a privacy gain, since an attacker cannot easily link differents connections of a single computer. It is compatible with all address assignment policies, and is very easy to deploy on a network. The administrator does not need to change the actual configuration and still can use CGA to prevent IP address spoofing on the local network. Our middlebox divides the network in one trusted zone under the control of an administrator and one untrusted zone, where privacy of users is protected.

The intelligence stays on the end devices, able to determine if a flow should be spread or not. On the middlebox, the resource consumption is lower than a typical IPv4 NAT setting and should not be a problem for the deployment. As for a IPv4 NAT, there is a risk of deny of service attacks from local network, by opening a lot of connections with random flow label values. It can be mitigated by limiting the number of allowed connections per devices.

Today, privacy is a hot topic for IPv6. For example, Deutsche Telekom Internet Provider uses privacy as a marketing argument for their IPv6 architecture. A patched middlebox with our solution is relevant in this context.

Fig. 1 :

 1 Fig. 1: Architecture of the solution: spreading by the middlebox

Fig. 2 :

 2 Fig. 2: Average time to run 20.000 times tests with library preload enabled/disabled

Table 1 :

 1 Example of context on the middlebox

	Internal IP Flow label	External IP
	α::1/64	120137 α:ece9:f330:fe60:188d/64
	α::1/64	4162	α:19f8:83b3:af5a:2511/64
	α::2/64	647513 α:6c40:9951:605f:8e03/64

The maximal bandwidth of the Internet connection is about 30Mb/s


Iyas Alloush

Yvon Kermarrec

Siegfried Rouvrais

A Transversal Alignment between Measurements and Enterprise Architecture for Early Verification of Telecom Service Design

Keywords: Telecommunication Service, Enterprise Architecture, Model Driven Engineering, Tool Chains, Simulators, Measurements, NS-3, OP-NET, Early Verification, Model Transformation, Code Generation

Early verification of Telecom Services (TS) at the design time helps an enterprise to avoid wasting of implementation cost and time. Simulation provides the designer with helpful feedbacks on TS design leaving the implementation and installation costs behind. Our objective in this paper is to present our approach to obtain valuable feedbacks from network simulators and relate them to the information from high abstract scenario of a TS. Relying on Model Driven Engineering discipline and Enterprise Architecture standard, we propose to associate measurement elements with the design ones of different abstraction levels. We implement a model transformation to generate automatically the configurations for NS-3 simulator as a test-bed for our case studies. We illustrate our approach with a video conference example, presenting the different abstract levels and their relationship with measurements.

Introduction

The production of Telecommunication Services (TS) is a long term process and consumes many resources. A mistake in the TS design may result in serious consequences to the rest of the life cycle activities. It is difficult and cost expensive to fix errors and flaws in the design after the implementation activity, especially if there are hardware elements to be installed. Therefore, we will take into consideration two points: the TS characteristics, and the TS creation activity.

The TS have several characteristics that make them different from other software systems. The platforms that a TS relies on are large scaled [START_REF] Nicol | Advanced concepts in large-scale network simulation[END_REF] and used by enormous number of customers. The TSs themselves are pervasive [START_REF] Achilleos | Pervasive service creation using a model driven petri net based approach[END_REF] and context aware [START_REF] Achilleos | Context modelling and a context-aware framework for pervasive service creation: A model-driven approach[END_REF] in many cases. A TS may rely on software and hardware elements to perform its tasks. Normally, the TS is composed of numerous number of applications that interact with each other, this results in a complex TS design [START_REF] Bowen | The feature interaction problem in telecommunications systems[END_REF]. Describing TS designs using Enterprise Architecture (EA) helps in managing the complexity problem [START_REF] Greefhorst | Architecture Principles[END_REF].

The contribution of this paper is in the scope of TS creation activity (TSC) [START_REF] Combes | Service validation[END_REF] and relies on a recent dissertation [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF]. We address the early verification activity right after the design one, and before the implementation phase. The aim of the verification activity is to "check that the software meets its stated functional and non-functional requirements" [START_REF] Sommerville | Software Engineering[END_REF]. The Service Creation Environment (SCE) [START_REF] Adamopoulos | Advanced service creation using distributed object technology[END_REF] is a collection of software tools that rely on reuse infrastructure used according to the service development methodology, to assist the service developer(s) by automating and simplifying the Service Creation process.

In our research we face the challenges: [START_REF]Eclipse IDE[END_REF] improving Quality of Service (QoS) that meets the customer satisfaction, and some performance non-functional requirements (NFRs) that concern the service and network providers such as CPU and memory loads; [START_REF]Eclipse modeling[END_REF] the time to market that should be as short as possible;

(3) improving the cost efficiency.

Our aim is to assist the different stakeholders that are involved in the TS specification activity, taking into consideration the three factors mentioned recently. In this paper, we will answer to the following research question: How to enable the estimation of the Quality of Service (QoS) violations and other possible performance non-functional requirements in the TS design using network simulators, and relying on the different abstraction levels of a TS architecture?

Our objective in this paper is to propose a centric solution that enables the TS designer and developer to obtain valuable feedbacks on the design. This will help the TS designer/developer to improve the quality and to detect the errors or flaws of the design.

Our approach is to bring the measurement element from the operation activity and insert it into the design activity, so to enable the observation of the TS virtual execution through network simulators. Our first contribution is to propose a transversal alignment between the measurement and design elements by extending the design meta-model that was proposed in [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF] to include measurement and probe elements. The second contribution is to map between the design and both of simulation Technical SPace (TSP) and Java Virtual Machine (JVM) taking a case study of NS-3 as a network simulator, where we intend to aggregate the measurements from the different architectural elements related to the upper layers of ArchiMate [START_REF]The Open Group: ArchiMate 1.0 Specification[END_REF].

We illustrate our approach with an example of a TS: video conference, presenting the generated code according to the design and measurement configurations. This example relies on a previous work done in [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF][START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF].

In section 2, we highlight the Enterprise Architecture (EA) with its architecture, and show the benefits from applying its structure to our approach. In section 3, we will provide an explanation about Model Driven Engineering (MDE) and its role in our approach, and we explain model transformations as we rely on code generations to generate the code. Section 4 presents in details our ap-proach to answer to the mentioned research question. In Section 5, we present a short explanation about network simulators, and show how do we map between design and simulation technical spaces. Thus, we show our work to create a reliable test bed for our current and future experiments. In Section 6, we present an example of obtaining data that are related to different layers of EA using to different technical spaces (simulation and JVM). In section 7,we present some of the related work, highlighting the points of interest to our objective. Then we conclude in section 8 and discuss our future work.

Enterprise Architecture and ArchiMate

An Enterprise Architecture (EA) [START_REF] Greefhorst | Architecture Principles[END_REF] "is an instrument to articulate an enterprise's future direction, while also serving as a coordination and steering mechanism toward the actual transformation of the enterprise".

EA framework facilitates dealing with complex architectures, as it applies the different viewpoints of the different stakeholders [START_REF] Simonin | An enterprise architecture alignment measure for telecom service development[END_REF] (e.g. service designer, service developer, customer, etc) in order to capture all the aspects of the enterprise objectives.

Thus, we are interested in the underlying platform and business viewpoints. When the TS design is to be implemented, there are two types of models that compose the TS: Platform Independent Model (PIM) and the Platform Specific Model (PSM). PIM contains the components that are independent from the execution platform, while the PSM contains elements of the execution platform and their functions.

We apply ArchiMate [START_REF]The Open Group: ArchiMate 1.0 Specification[END_REF] which is an EA modeling language. It decomposes the system as the EA does according to different viewpoints. Additionally, its profile contains means that help the TS designer, as they are suitable for the IT domain. They define behavioral and structural elements connected to each other by wide range of relationships. This layered architecture allows changes on the design to be independent from other layers [START_REF] Sommerville | Software Engineering[END_REF], and makes finding an error or design flaw much more easier.

In [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF][START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF], ArchiMate profile is extended to define the Domain Specific Modeling Language (DSML), where different elements that are related to TS domain are included in the extended profile. For the verification activity (Fig. 3), we extend ArchiMate abstract syntax to include measurements, simulation and analysis tools with their relationships that are inherited from ArchiMate definition [START_REF]The Open Group: ArchiMate 1.0 Specification[END_REF].

A TS designer should verify the TS through its architecture that is composed of layers of different levels of abstraction (PIMs and PSMs). In this paper, we present our approach to connect measurement elements to these different layers.

Model Driven Engineering and Model Transformations

System modeling [START_REF] Issariyakul | Introduction to Network Simulator NS[END_REF]: "refers to an act of representing an actual system in a simple way". With modeling, the parameters of the system can be modified, experimented, and analyzed. In our approach (Fig. 3), models plays a central role Model transformation (MT) is one of the key concepts in MDE, and in our approach. MTs offer automated way to create new models from given ones according to the mapping rules that controls them.

XPAND [START_REF]Eclipse modeling[END_REF] is a model-to-text transformation language that makes it possible to iterate over input model instances to generate text files. This enables us to generate executable and simulation codes for Platform Independent Models (PIMs) [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF] and Platform Specific Models (PSMs) [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF].

Measurement and Design Transversal Alignment Approach

The TS designer needs to get feedbacks for his design related to errors/flaws or quality violations. We have recently associated the measurement model to the elements of the technology layer that represents the underlying platform in our approach, and its model is a PSM. We have selected the IMS core network platform to be represented in this layer [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF][START_REF] Chiprianov | Extending enterprise architecture modeling languages: Application to telecommunications service creation[END_REF]. Such association will provide a TS designer feedbacks that are related to the network level, which is very low in abstraction. This leads us to a question: How can we perform measurements on elements of higher level of abstraction?

We use ArchiMate language (section 2). It contains the business layer that provides the ability to relate the business actors from an enterprise (e.g. user) with the different types of behavioral elements (such as business interactions, events, functions, etc) in the system and in high level of abstraction [START_REF]The Open Group: ArchiMate 1.0 Specification[END_REF]. Thus, ArchiMate business layer can cover both of the (Use Case and Scenario [START_REF] Sommerville | Software Engineering[END_REF]) representation fundamentals. ArchiMate language provides relationship between every two neighboring layers [START_REF]The Open Group: ArchiMate 1.0 Specification[END_REF] in abstraction (e.g. Business and Application layers), which makes it possible to exchange events and interactions between the 3 layers of ArchiMate.

We propose to enable the association between the measurement element (the Probe) and all behavioral and structural elements (Fig. 2) of ArchiMate on the Meta-Model. The measurements are aligned transversally with ArchiMate layers and their probes are following the layering concept of ArchiMate (Fig. 2), thanks to the one-to-many aggregation relationship between the Measurement Fig. 3. Verification of Telecom Services relying on tool chains and Probe(s) in the Meta-Model (Fig. 4). Respecting the ISO-Square standard [START_REF] Azuma | Iso/iec cd 25000.2 -software and systems engineering -software product quality requirements and evaluation (square)[END_REF], we propose the measurement meta-model as composed in the following structure (Fig. 4): (1) Measure: Represents the output value of the measurement; (2) Probe: Represents an entity that captures the data when an event is triggered (e.g. a packet is dropped), an action is performed, or during all of the simulation time. The probe concept is inspired from OPNET1 structure [START_REF] Chang | Network simulations with opnet[END_REF]. The probe element is associated with structural and behavioral entities from ArchiMate profile. This provides the ability of collecting measurements from elements of the different layers of EA. Probes have different types due to the nature of the data type that they can obtain (e.g. numerical, time). In the verification activity, one may use all the probes that are related to one measurement in one layer of EA, or distribute them between different layers. In this paper, we will consider the probes per layer case, leaving the other one to future work; (3) Probe Function: The probe function defines the procedure (how) to capture the data; (4) Measurement Function: Represents the function (how) to aggregate the data collected by the different probes.

The measurement meta-model (MM) that we propose (Fig. 4) makes it possible to use the measurement per layer or as a multi-layer measurement, where the probes may be associated with the elements of one layer or distributed between the different layers. In this MM, the layer and data type attributes are clear in the probe element. Thus, the probes are aligned with the design elements in the same layers, while the measurement elements are aligned with the EA architecture transversally (Fig. 2) as they collect the data from the different probes thanks to the aggregation relationship between them (Fig. 4).

This meta-model (Fig. 4): (1) Makes it possible to tune the granularity level of the data collection during the verification of the TS design; (2) Classifies the measurements according to the viewpoint of the stakeholder and to the different domains that are used in an enterprise. So we can have business, application, and technology classes of measurements. This can help in managing the classifica-tion of QoS requirements [START_REF] Lee | A scalable solution to the multi-resource qos problem[END_REF]; (3) Enables earlier selection of the measurements knowing the requirements from the business layer. Knowing the set of measurements needed for the technology layer, enables us to select the proper network simulator.

Network Simulators

We need to find a proper approach to execute virtually and analyze the design models. There are different approaches for modeling a system for experimentation purposes: (1) Simulation Approach: In the network simulation domain, Discrete-Event Simulation (DES) is a powerful research technique to investigate protocol designs, interactions, and large-scale performance issues [START_REF] Henderson | ns-3 project goals[END_REF]. Simulation allows researchers to experiment their prototypes with low cost and implementation time than dealing directly with real network elements. Simulators provide a TS designer with valuable observations and measures that helps in detecting design errors/flaws and quality violations; (2) Analytic Approach: Analytical modeling approach is to model the system mathematically using applied mathematical theories (e.g. Queuing and Probability theories).

In our approach, we rely on simulation approach. Modeling using EMF in eclipse (section 3) differs from modeling the same design using the simulation program language. We can map each element from the design TSP to the corresponding one in the simulation TSP using model transformations (section 3).

The objective from any network DES program is to run a scenario that contains structural (e.g. nodes) and behavioral (e.g. send message function) elements for a previously-set simulation period, in order to obtain traces and logs at the end of the simulation run. These logs can be then analyzed later to find the possible errors/flaws or quality violations in the design. Our approach takes into consideration the structural and behavioral elements of the TS design. The challenge here is to find the simulator elements that correspond correctly to the design elements, and to implement the simulation program in the right way. Every element from the design model should be mapped to the simulation program. Such a mapping needs experience in both areas: TS design, and simulator specifications, this can be considered as a limitation in our approach. Because implementing the mapping rules in the model transformation template (e.g. XPAND template, section 3) needs the mentioned expertise and a considerable time to be sure that no design elements were missed, also to insure that the language rules of the simulation program were respected.

NS-3 Simulator: A test bed for experiments

Network simulators help to estimate the TS performance and QoS metrics. But they differ from each other in their capabilities, certificate level, graphical interfaces, granularity levels, and built-in integrated tools (e.g. animators, report generators, analyzers, etc).

Regarding to the capabilities, we are interested in the measurement capability to differentiate between the different network simulators. There is an important point in NS-3 [3] is that the whole simulation program can be implemented in one C++ file in NS-3, where all of the simulation parameters can be configured including generation of traces and logs [3]. This feature in NS-3 enables us to generate code automatically (according to section 3) for measurements aggregation in addition to the scenario implementation and its underlying platform (e.g. IP Multimedia Subsystem (IMS)). C++ has different functions that assist plain-text output, thus we can include information from the design combined with the measurement results in the output files.

Additionally, NS-3 supports different types of easy-configured applications [3] (e.g. Socket using TCP or UDP). Unfortunately, NS-3 does not support IMS core network model yet. Taking advantage from the advanced models of the application layer provided in NS-3 [START_REF] Henderson | ns-3 project goals[END_REF]3], we call the functions of IMS in a high abstract level. There is a function called (SendTo) in our technology layer MM [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF] that represents the message sending procedure. Thus, we generate the SIP messages as UDP or TCP packets using socket application that is already deployed in the application layer of NS-3 model. More details about the models of NS-3 one may refer to [START_REF] Henderson | ns-3 project goals[END_REF].

In relation to the structural entities of IMS platform that is presented in [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF], a mapping between these entities (e.g. Nodes, CommunicationPaths, NodeInterfaces, etc) was performed to create the underlying platform where the scenario is going to run. Our mapping activities start with collecting data from the design model and then map them to the target simulator. The collection procedures start from the CommunicationPath as there is only one CommunicationPath links between every two linked nodes, this constraint is defined in the metamodel of the technology layer of [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF]. Then we iterate to query for the interfaces that are involved in this communication until we reach the node pairs. . . (Fig. 5). The steps to implement code in NS-3 appears in the same figure. Figure 6 presents the architecture of both technical spaces: Design and NS-3 simulator. The activities in (Fig. 5) show that we rely on collections and iterations without any exceptions and respecting the types and constraints of the meta-model. This should confirm that every design element is covered when mapping to the simulation TSP.

Example on Measurements associated with Video Conference TS: NS-3 and JVM case study

There is a major difference between the technical spaces of network simulation such as NS-3/OPNET and general purpose languages (GPLs) such as Java. Our example in this paper illustrates the measurement correspondence to the different layers of the design architecture described in ArchiMate language. We will give an example of two layers: the business and technology. We generate Java code from the business layer, and simulation code from the technology one following the description in section 5. The Java code generation relies on the model transformation rules that were defined in our previous work in [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF]. We rely on a scenario (Fig. 7) for video conference which is modeled using a Domain Specific Modeling Language (DSML) [START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF]. This scenario is represented in the business layer of ArchiMate, and shows the correspondence of business actors with the different activities that compose it. 6.1 Associating probes with the elements of the Business Layer

Associating probes with the business layer elements gives the ability of obtaining data from the business domain such as user-related information. Figure [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF] shows that when the user enters to the conference system joining the group, a function in the application layer called join conference is triggered (called) by the (Enter Conference) activity. This application function triggers a registration procedure in the technology layer, to register the user into the conference service in the simulation technical space. Figure [START_REF] Bowen | The feature interaction problem in telecommunications systems[END_REF] presents the Java code that is generated by the MT rules for the business layer elements. It shows how the probe function (getName) is called inside the method (enterconference), where this function is not modeled to be triggered by the activity (Enter Conference) in (Fig. 7). This illustrates an example for our method in obtaining the data from different elements of Business Layer relying on our approach. One can also find in (Fig. 9) that there is a method named (setName) which is used to set the name of the customer during the runtime execution, and it should be called by the running system such as a mobile device.

Associating probes to the elements of the Technology Layer

Associating the probes with elements from technology layer gives the ability to obtain different type of measurement data from the elements of the underlying platform (IMS in our research [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF]). For the example (Fig. 7), we generate the simulation code that is used to configure NS-3 as a case study. We rely on the video conference example presented in [START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF] to generate the configuration script. The association relationship between the probe (named (RegistrationTime) of type (Time) and layer (technology)) is used to capture the registration time of the user when he joins the conference system. We set the ProbeFunction method value to (Simulator::Now()) (Fig. 8), which is a command used to obtain the current time during the NS-3 simulation runtime.

There is still a question that needs to be answered from the previous example about the aggregation between the results of the probes, which are attached to different TSPs (e.g. Simulation and JVM). We consider this problematic as a future work.

Related work

We consider the following aspects during the review: (1) The ability of collecting measurements from structural elements as well as the behavioral ones; (2) Linking automatically the design modeling and Simulation or other execution software technical spaces; (3) Domain Specificity of the approach; (4) The ability to obtain data after executing the design and on high level of abstraction including the scenarios.

-In [START_REF] Hartman | Model-based design and generation of telecom services[END_REF], the paper describes a model-based approach to create telecom services. They implement the service relying on IP Multimedia Subsystem (IMS) infrastructure and using code generation techniques from the MDE discipline. Using Eclipse software, they could close the abstraction gap between the design and the execution environment, by hiding the low level protocol and architecture details. Although their approach considers the domain specificity and high abstraction level of the design models, but no measurement capture method appears in their approach; -The paper [START_REF] Touraille | A model-driven software environment for modeling, simulation and analysis of complex systems[END_REF] presents work that is very close to the formalism we use.

The authors apply MDE and rely on DEVS (Discrete EVent Systems Specification) formalism to smooth the modeling and simulation cycle and facilitate the coupling of models using heterogeneous formalisms. They provide the SimStudio software which aims at providing modeling and simulation tool chain. Their approach and ours depend on meta-models that contains different views to the different activities of the tool chain (modeling, simulation). Their approach doesn't have support for structural elements representation while limited to the behavioral ones. Their approach seems to depend on one abstraction level of measuring capability, while we use probes to obtain data from different layers of EA; -The work presented in [START_REF] Adamopoulos | Advanced service creation using distributed object technology[END_REF] addresses the same scope of service creation activity. They propose a methodology that takes into consideration the customer and service provider requirements. They apply code generation to produce Java and C++ codes directly from these PIMs, with no mention to simulation tools; -In [START_REF] Achilleos | Context modelling and a context-aware framework for pervasive service creation: A model-driven approach[END_REF], the authors work on context aware services creation process. Not far from our approach, they link between the knowledge modeling and implementation activities, relying on model transformations. Their approach doesn't seem to rely on simulators but on runtime environments such as JVM. Their approach takes the end-user only into consideration, where we take service designer and user models into account thanks to the EA standard. Their approach respects domain specificity and data capturing during and after the execution, but it is only from high abstract models.

Conclusion and Future work

In this paper, we have presented our work in the activity of TS verification, by defining a new meta-model that links measurements to the design. We have implemented a test-bed based on NS-3 network simulator to rely on for case studies. Our approach is to link the measurements to the different elements of the TS design as aligned transversally with the EA framework. We have illustrated our approach with example on the video conference service, presenting the code that is generated from models of different abstraction levels. This provides a centric solution that enables the TS designer to obtain valuable feedbacks on the design so to improve the qualities and detect possible design errors or flaws.

Our approach, as presented, assists the different stakeholders during the design activity thanks to EA and ArchiMate. It is capable to implement structural and behavioral entities of the design in the simulation technical space, while implementing the required measurements automatically as well. Raising the measurements' association to the layers higher than technology (PSM) one in the abstraction level makes it possible to obtain data from the PIMs directly. This enables us to link goals, design, and verification elements together.

On the other side, the number of inputs of the measurement function is limited to two in our implementation. The implementation of code generation templates is a time consuming activity and needs experience in both simulation and modeling domains.

For the future, we intend to answer to the problematic that we raise in section 6, where aggregating the data obtained from different design layers is important but still challenging. Additionally, we intend to analyze automatically the measurements resulted from the simulation activity to check the goals' satisfaction.

Fig. 1 .

 1 Fig. 1. Applying MDE to bridge between Design and Simulation modeling Fig. 2. A transversal Alignment Approach between Measurements and Design to represent systems of different technical spaces: Design, and Simulation. MDE is well supported by Eclipse IDE [1]. Eclipse contains powerful tools for MDE such Eclipse Modeling Framework (EMF) which forms the core of our modeling environment in the design Technical SPace (TSP).Model transformation (MT) is one of the key concepts in MDE, and in our approach. MTs offer automated way to create new models from given ones according to the mapping rules that controls them.XPAND[START_REF]Eclipse modeling[END_REF] is a model-to-text transformation language that makes it possible to iterate over input model instances to generate text files. This enables us to generate executable and simulation codes for Platform Independent Models (PIMs)[START_REF] Chiprianov | Collaborative Construction of Telecommunications Services. An Enterprise Architecture and Model Driven Engineering Method[END_REF] and Platform Specific Models (PSMs)[START_REF] Alloush | Linking telecom service high-level abstract models to simulators based on model transformations: The ims case study[END_REF].

Fig. 4 .Fig. 5 .Fig. 6 .

 456 Fig. 4. Measurement view of the meta-model

Fig. 8 .Fig. 9 .

 89 Fig. 8. Probe function implemented in NS-3 to capture the registration time of a user Fig. 9. User Class Java code-Business Layer

OPNET is a wide-used network simulator, it can handle different network elements of both hardware and software nature. www.opnet.com