Luis Tello-Oquendo

Ian F Akyildiz

Shih-Chun Lin

Vicent Pla

SDN-Based Architecture for Providing Reliable Internet of Things Connectivity in 5G Systems

Sheer number of devices in Internet of Things (IoTs) fundamentally challenge the ubiquitous information transmissions through the backbone networks, such as cellular systems. The heterogeneity of IoT devices and the hardware-based, inflexible cellular architectures impose even greater challenges to enable efficient communication. To address these challenges, this paper introduces the so-called SoftAir architecture on wireless softwaredefined networking and proposes software-defined gateways (SD-GWs) that jointly optimize cross-layer communication functionalities between heterogeneous IoT devices and cellular systems. First, the SoftAir architecture is proposed to support a unified software-defined platform for quality-of-service aware IoT systems and software-defined radio access networks (SD-RANs) with millimeter-wave transmissions. Next, the SD-GWs are designed in SoftAir to explore the interactions between two-types of networks (i.e., IoTs and SD-RANs) and enable cross-layer solutions that simultaneously achieve optimal energy savings and throughput gain in IoTs and maximum sum-rates in SD-RANs. Simulation results validate that our SoftAir solutions surpass classical IoT schemes by jointly optimizing communication functionalities for both IoTs and SD-RANs and bring significant system synergies for reliable 5G IoT communication.

I. INTRODUCTION

The evolution of communication networks, devices, and applications has drawn a new technological age in which everything is connected. Internet of Things (IoTs) has extended the scope of wireless communication services from interpersonal communications to smart interconnection between things and between people and things, allowing wireless communication technologies to penetrate into broader industries and fields. The number of connected IoT devices is expected to increase between 10-and 100-fold beyond 2020 [START_REF] Cisco | Cisco visual networking index (VNI): Global mobile data traffic forecast update[END_REF]; these devices will range from devices with limited resources that require only intermittent connectivity for reporting (e.g., sensors) to devices that require always-on connectivity for monitoring and/or tracking (e.g., security cameras, transport fleet). IoT connectivity drives the development of 5G cellular systems where a combination of advances such as air interface design, millimeter-wave (mmWave), software-defined networking (SDN), signaling optimization, and intelligent clustering and relaying techniques can all contribute to enable efficient communication and support such hyper-connectivity [START_REF] Akyildiz | 5G roadmap: 10 key enabling technologies[END_REF].

Traditional network architectures will not be able to handle both the number of devices and the volume of data they will be draining into the network. Moreover, current IoT solutions rely on low-power wide area (LPWA) networks [START_REF] Raza | Low power wide area networks: An overview[END_REF], which complement traditional cellular and short-range wireless technologies This work was supported by the US National Science Foundation (NSF) under Grant No. 1547353, in part by the Ministry of Economy and Competitiveness of Spain under Grants TIN2013-47272-C2-1-R and TEC2015-71932-REDT.

in addressing IoT applications. Several technologies, such as LoRa, NB-IoT, SIGFOX, have been developed and designed solely for applications with very limited demands on throughput, reliability, or quality-of-service (QoS). However, without a central regulation among these LPWA technologies, existing IoT solutions cannot support highly diverse QoS requirements from increasing 5G IoT applications. Due to currently fixed and hardware-based infrastructure, no existing work has considered the joint architectural design of IoT networks and software-defined radio access networks (SD-RANs), and the provision of reliable and efficient upstream/downstream IoT transmissions. Another challenge is to efficiently manage the load of traffic and the network resources in the 5G era, to avoid a possible collapse of the network, and to allow the coexistence of different services with different QoS requirements in a scalable and efficient manner.

In this paper, to adequately address the above challenges in 5G IoT, we introduce a new architecture proposed for wireless software-defined networks, the so-called SoftAir [START_REF] Akyildiz | SoftAir: A software defined networking architecture for 5G wireless systems[END_REF]; then, software-defined gateways (SD-GWs) are designed in the SoftAir SD-RAN for providing reliable connectivity and services to IoT applications. Our solution overcomes the limitations of existing commercial wireless networks that are inherently hardware-based and rely on closed and inflexible architectural designs by offering five core properties: programmability, cooperativeness, virtualizability, openness, and visibility. These five properties provide functionalities that are essential to enable 5G wireless communication networks and support emerging IoT applications and services. We consider a likely IoT scenario based on several wireless sensor networks (WSNs) that provide IoT services through the SoftAir system. The proposed SD-GW in the SoftAir architecture will manage the sporadic communications from a myriad of the heterogeneous IoT devices and provide local offloading. It aggregates the data from IoT devices clustered geographically and provides them with access to the Internet using SoftAir. It implements the physical, link, and network layers and can support multiple wireless interfaces. For instance, in downstream transmissions, it can connect with the IoT devices using IEEE 802.15.4 or near-field communications (NFC), and in upstream transmissions, it can use the SoftAir protocol stack to communicate with the remote radio heads (RRHs).

Specifically, we develop a cross layer framework and propose a joint optimization of protocols crossing different layers from the IoTs to the SD-RAN according to the devices' QoS requirements and system constraints. Thus, we provide a solution for various performance requirements of applications to handle the heterogeneity of IoT devices. The optimization framework is performed at the SD-GW where a local IoT controller resides; it explores the interactions of these two-types of ISBN 978-3-903176-05-8 c 2018 IFIP networks and enables cross-layer solutions to simultaneously achieve optimal energy savings and throughput gain in IoTs, as well as maximum sum-rate in SD-RANs. Furthermore, with the introduction of IPv6, the vast increase in the number of connected devices is properly addressed and the SD-GW can be used to send IoT data to other devices connected to the Internet. The main contributions of this paper are summarized as follows

• We present the SoftAir architecture to provide IoTs connectivity that exploits the emerging features in wireless communications. A study that explores the interactions of communication functionalities for an IoT scenario based on WSNs is provided. • We design a heterogeneous cross-layer solution for the SD-GW aiming to fulfill a predefined level of QoS, efficient energy consumption, high system performance, and reliable connectivity. • We develop an optimization framework that achieves optimal energy savings and throughput gain concurrently in WSNs while maximizing the SD-GW rate coverage with mmWave RRHs coordination in SoftAir. To the best of our knowledge, this work is the first to provide a unified cross-layer optimization framework for IoT communication within 5G systems. The rest of the paper is organized as follows. Section II describes the SoftAir architecture for IoT communications. Section III presents the heterogeneous cross-layer optimization design in SD-GWs that integrates IoTs and SD-RAN of SoftAir. Section IV gives the performance evaluation, and Section V concludes the paper.

II. SOFTAIR ARCHITECTURE FOR 5G IOTS

SoftAir [START_REF] Akyildiz | SoftAir: A software defined networking architecture for 5G wireless systems[END_REF] is a unified software-defined platform for 5G systems with network management tools and customized applications of service providers or virtual network operators. It would enable IoT applications to access the data and control the devices without the knowledge of the underlying infrastructure. SoftAir follows a distributed RAN architecture composed of three main parts: (i) the centralized base band servers (BBS) pool, which connects to the core network via backhaul links and consists of software-defined base stations (SD-BSs) from real-time virtualization technology for softwareimplemented baseband units (e.g., digital processing tasks); (ii) RRHs plus antennas, which are remotely controlled by SD-BSs and serve SD-GWs' transmissions; and (iii) low-latency high-bandwidth fronthaul links (fiber or microwave) using the common public radio interface (CPRI) for an accurate, highresolution synchronization among RRHs.

Extended from our preliminary study in [START_REF] Akyildiz | SoftAir: A software defined networking architecture for 5G wireless systems[END_REF], Fig. 1 depicts an example of the SoftAir-based architecture for 5G IoTs. It consists of three domains: sensing, network, and application. The sensing domain enables things to interact and communicate with themselves and with the communication infrastructure; it realizes the data collection of physical targets employing technologies such as WSNs, RFID, ZigBee or NFC. The network domain builds on SoftAir; it aims to transfer Notations: Throughout this paper, boldface lower and upper case symbols represent vectors and matrices, respectively; Ix denotes an x by x identity matrix; C x,y denotes the set of x × y complex matrices. The trace, transpose, and Hermitian transpose operators are denoted by tr(•), (•) T , and (•) H , respectively. We use CN (X, Y) to denote the circular symmetric complex Gaussian distribution with mean matrix X and covariance matrix Y; the distribution of a uniform random variable (r.v.) is denoted by U (•), the distribution of a normal r.v. with mean x and variance σ 2 is denoted by N (x, σ), and ∼ stands for "distributed as". Expectation is denoted by

E[•], variance is denoted by V[•].
x denotes the Euclidean norm of complex vector x, and |z| denotes the magnitude of a complex number z. The indicator function is denoted by I[x]; it returns 1 when x is true, and 0 otherwise. the data collected from the sensing domain to the remote destination in the application domain. Finally, the application domain is responsible for data processing and the provision of a wide variety of applications and services.

It is worth noting that a relevant architectural component is the SD-GW, that lies between the sensing and network domain. Besides alleviating the high traffic bursts imposed by sporadic communications from a myriad of heterogeneous IoT devices, the SD-GW aggregates the data from the IoT devices clustered geographically forming several WSNs and provides them access to the Internet using 5G wireless. In that sense, the SD-GW comprises two interfaces: northbound and southbound. The former communicates with the SoftAir system, whereas the latter interconnects the devices inside the cluster, i.e., the SD-GW implements protocols that support co-existence of diverse wireless interfaces, such as intelligent management of interference and distributed management of channel allocation/medium access.

A. System Model

Considering the SoftAir domain of the above architecture, the system consists of a set I = {1, . . . , I} of SD-GWs that provide connectivity to several WSNs clustered geographically. Inside the WSN, the set K = {1, . . . , K} of nodes communicate with neighboring devices by 6LoWPAN; we assume that the ith SD-GW acts as cluster head of the set K of nodes, and relays the data it receives to the SD-RAN. Then, the set I of SD-GWs is served by a set J = {1, . . . , J} of associated RRHs. All the RRHs are connected to the BBS pool B via fronthaul links, where the jth fronthaul link between the j ∈ J RRH and the b ∈ B BBS has a predetermined capacity C fh j . Note that by using low-latency high-bandwidth fronthaul links, the software-defined architecture implements an accurate, high-resolution synchronization among RRHs and enables flexible and tangible RRH coordinations. The associations between the RRHs and SD-GWs can be determined based on the distance or channel gain from RRHs to each SD-GW. The RRHs are equipped with an array of M antennas and communicate with the single antenna SD-GWs through mmWave links. One RRH can serve a number of SD-GWs; the jth RRH that is assigned to serve the ith SD-GW will receive the SD-GW's processed base band signal from the BBS pool.

Then, the RRH converts and transmits the corresponding RF signal using a suitable designed pre-coding vector as detailed in Section III-B.

In the SoftAir domain shown in Fig. 1, the SD-GW incorporates a local controller, and has the key role of being a concentrator of several sensor nodes for both control and user planes. It possesses the necessary knowledge to orchestrate the sensors such as network topology, link qualities, and application requirements. Besides performing conversions to communicate between different standards, the SD-GW performs the optimization framework, and can make decisions such as the choice of network parameters and protocols. The network application can then be modified by simply changing the forwarding rules at the local controller, which then propagates the changes to sensors.

III. HETEROGENEOUS CROSS-LAYER SOLUTION FOR SOFTWARE-DEFINED GATEWAY

In the following, we develop a cross-layer optimization framework that integrates the sensing domain and the SD-RAN of the SoftAir system, allowing coordination, interaction, and joint optimization of protocols crossing different layers. We elaborate the communication functionalities for both the sensing and SD-RAN domain in Section III-A and Section III-B, respectively. Then, a centralized optimization framework to jointly control the parameters is formulated in Section III-C to ultimately reach an optimum configuration according to an application-dependent objective function. Finally, the protocol operation at the SD-GW is detailed in Section III-D.

A. IoT & WSN Network

In this section, we describe the parameters and communication functionalities at the physical layer (channel, modulation), link layer (channel coding, MAC), and network layer (addressing, routing) for the nodes in the sensing domain.

1) Physical layer functionalities: At the physical layer, the nodes follow the frequency spectrum allocation according to the IEEE 802.15.4 standard [START_REF] Association | IEEE Standard for Low-Rate Wireless Networks[END_REF]; they might have different maximum transmission power and can select different modulation schemes. We use the log-normal channel model, which has been experimentally shown to model the low power communication in WSN accurately [START_REF] Vuran | Error control in wireless sensor networks: A cross layer analysis[END_REF]. In this model, the total path-loss in dB is given by WSN

(d i )[dB] = l WSN (d 0 ) + 10n log 10 (d i /d 0 ) + η for d i ≥ d 0 , where d i is the transmitter-receiver distance; d 0 is a reference distance;
n is the path-loss exponent for a particular frequency band or environment; η ∼ N(0, σ) is the large-scale shadow factor in dB; and l WSN (d 0 ) = 10 log 10 ((4πf d 0 )/c) 2 is the pathloss at a reference distance, d 0 = 1 m, for a given center frequency, f ∈ {800, 900, 2400} MHz; c = 3 × 10 8 ms -1 is the speed of light; and n = 2. The signal-to-noise ratio (SNR) at a distance d i in the receiver, ω(d i ), is given by ω

(d i )[dB] = P tx k -l WSN (d i ) -P noise , where P tx k [dBm]
is the output power of the transmitter, and P noise [dBm] denotes the total noise power at the receiver.

The transmission power and modulation have a direct impact on the bit error rate (BER). Given the link i, the BER Ψ i is determined as a function of the adopted modulation technique, mod i ∈ M, and the SNR, ω(d i ), as

Ψ i = Ψ(ω(d i ), mod i ).
Note that Ψ(•) is well-known for standard modulations. In the sensing domain, we consider simple modulation schemes following the IEEE 802.15.4 standard [START_REF] Association | IEEE Standard for Low-Rate Wireless Networks[END_REF], such as BPSK and OQPSK, which are suitable for energy-limited WSNs.

2) Link layer functionalities: Concerning the channel coding scheme, we advocate for the use of a hybrid ARQ error control scheme [START_REF] Vuran | Error control in wireless sensor networks: A cross layer analysis[END_REF], [START_REF] Han | A cross-layer communication module for the internet of things[END_REF] that results from the combination of forward error correction (FEC) codes for poor quality channel conditions (i.e., ω(d i ) low) as well as the merits of automation repeat request (ARQ) when the channel conditions are good (i.e., ω(d i ) high). Initially, an uncoded or lightly coded packet is transmitted; if the received packet has more errors than those that can be corrected by the chosen FEC code, a more robust FEC code is chosen. We consider block codes due to their energy efficiency and lower complexity compared to convolutional codes (CCs). For the link i, cod i ∈ C denotes the adopted coding scheme with coding rate RC i . As far as the BCH(bl; pl; ce) code with rate RC i = pl/bl is concerned, bl, pl, and ce denote block length, payload length, and the error correcting capability of FEC code in bits, respectively, and ce < bl. Given the BER Ψ i (•), the block error rate,

Ψ block i , becomes Ψ block i = bl j=ce+1 bl j Ψ i (•) j (1 -Ψ i (•)) bl-j .
Additionally, with ℘ bits being the packet length, the packet error rate (PER) Φ i is calculated as follows

Φ i = 1 -(1 -Ψ block i ) ℘ pl , ( 1
)
which is approximated as ℘ pl Ψ block i when Ψ block i is small. As a result, in each transmission, the initial packet is either coded with a BCH(128; 106; 3) code or not coded to reduce the Φ i without drastically sacrificing the transmission data rate. If the first transmission fails, i.e., the number of errors is larger than the maximum number of bits that can be corrected, a more robust FEC code is used for the re-transmitted packet [e.g., BCH(128; 78; 7)] until the packet is successfully decoded or the maximum number of transmissions (including re-transmissions), N max i , is reached. Using this hybrid ARQ error control scheme, the overall PER over link i is given by

Φ Rtx i = Υ(Φ uncoded i , N Tx-ub i , ce), ( 2
)
where Υ(•) is a function that relates Φ i after hybrid ARQ error control scheme, Φ Rtx i , with the uncoded PER over link i, Φ uncoded i , which is derived next [see [START_REF] Raza | Low power wide area networks: An overview[END_REF]] considering the data storage capacity of nodes; N Tx-ub i is the upper-bound for the number of transmissions of a packet with correctly decoding over link i computed as

N Tx-ub i = (1 -Φ uncoded i ) -1 .
Additionally, we take into account the data storage capacity of the sensor nodes, mem, that is related to the probability of discarding a packet at link i, P pkt-dropout i , due to the fact that it can not be queued at the transmitter or at receiver. We define this probability as P pkt-dropout i = Γ(mem k , F k ), where Γ(•) is a function that relates the maximum number of packets, mem k , that can be queued at the transmitter or receiver and the total local traffic (own and relayed), F k . For instance, assuming Poisson traffic, the transmitter and receiver can be modeled as a single server queue with mem k buffer size and

(DR i • RC i )/℘ [pkt/s]
service rate, where DR i [kbps] is the data rate transmission of link i. With these parameters, we determine the uncoded PER over link i, Φ uncoded i , as follows

Φ uncoded i = (1 -P pkt-dropout i )[1 -(1 -Ψ i (•)) ℘ )]. (3)
Regarding the MAC functionality, we consider a variation of sleep MAC (SMAC) and carrier sense multiple access with collision avoidance (CSMA/CA) for addressing energy efficiency and scalability. On the one hand, as sensor nodes are likely to be battery powered, we adopt the idea of SMAC in which sensor nodes periodically listen and sleep [START_REF] Ye | Medium access control with coordinated adaptive sleeping for wireless sensor networks[END_REF] so that the network lifetime of these nodes is prolonged. On the other hand, with CSMA/CA, a node attempts to reserve the channel by using request to send/clear to send handshake after it sees the channel idle for an inter-frame space amount of time. If the node fails to reserve the medium, it switches to sleep mode to save energy and waits for the next listening cycle. This medium access method can eliminate the interference drastically if the carrier sensing is properly performed. Note that, if a reservation-based protocol is used, data packet collisions will not occur. Hence, the hybrid of SMAC and CSMA/CA MAC protocol can save energy as well as reduce the interference among the sensor nodes avoiding the degradation of both BER and PER [START_REF] Han | A cross-layer communication module for the internet of things[END_REF]. In our framework, the duration of listen and sleep cycles (T listen , T sleep = 9×T listen for a 10% duty cycle) is adaptive to the QoS requirements and they are set the same for all nodes in one cluster. Note that, the longer the sleep duration is, the lower the idle energy consumption, but the longer the end-to-end delay. We consider this duration parameter in the MAC protocol to interplay with physical layer parameters in the proposed cross-layer framework.

3) Network layer functionality: The IoT is expected to have an incredibly high number of things, and each of them should be retrievable with a unique IP address. Thus, we advocate for the use of IPv6 addressing in our framework, consistently with 6LoWPAN. A packet with fixed size (℘ bits) is selected and used for all the links throughout a given path; the packet size is computed as ℘ = pl + h + ce, where pl is the payload (data) length, h is the header length, and ce is the FEC redundancy length. We use the RPL for selecting the multi-hop paths that data packets follow from the source to reach the destination. RPL is a distance vector routing protocol that leaves the process of route selection to an external mechanism called objective function. RPL is based on the topological concept of destination oriented directed acyclic graph (DODAG). The DODAG refers to a directed acyclic graph with a single root as shown in Fig. 2; the costs associated with each directional link are derived accordingly to be consistent with the objective function (detailed in Section III-C), the constraints, and the hardware capabilities of the things so that the optimal path from the source to destination is provided.

B. 5G Radio Access Network: SoftAir

Following the network model detailed in Section II-A, we formulate the sum-rate optimization in the SoftAir SD-RAN, which jointly optimizes associations between RRHs and SD-GW that use mmWave transmissions, and RRHs' beamforming weights to maximize the SD-GW sum-rate while guaranteeing QoS and system-level constraints. We consider a short frame structure [START_REF] Lähetkangas | Achieving low latency and energy consumption by 5G TDD mode optimization[END_REF], [START_REF] She | Cross-layer transmission design for tactile internet[END_REF] where time is discretized into frames, each frame has duration of T frame symbols. We allocate τ ul symbols for uplink transmission, and τ dl symbols for downlink transmission.

1) Association Scheme: Let J = {1, . . . , J} and I = {1, . . . , I} denote the set of RRHs and SD-GWs in the SoftAir system, respectively. Suppose that each SD-GW is served by a specific group of associated RRHs, and a RRH can serve multiple SD-GWs at the same time. To express the association status between RRHs and SD-GWs, we introduce the following binary variables as the indicators. Concretely, RRHs can be active to serve SD-GWs or shutdown to save the energy consumption, let {a j , j ∈ J } denotes the activity of RRHs as a j = I[the jth RRH is in active mode]; let {g ij , i ∈ I, j ∈ J } denotes the association between RRHs and SD-GW as g ij = I[the ith SD-GW is served by the jth RRH]; furthermore, to characterize the group (cluster) of serving RRHs, let {N ij , i ∈ I, j ∈ J } be the clustering indicator as

N ij = I[(i, j) ∈ L], where I[x] is the indicator function, L = {(i, j) | i ∈ I, j ∈ N i }
denotes the predetermined set of feasible association, and N i denotes the set of near RRHs for the ith SD-GW which can be determined based on the distance or channel gain from RRHs to each SD-GW.

2) Millimeter-Wave Communication: We introduce the link budget for mmWave communication between the ith SD-GW and jth RRH. Particularly we detail the path-loss, l i , channel vector, h i , and beamforming gain, G BF i , for deriving both the achievable uplink and downlink data rates.

Path-Loss: Considering the peculiarities of mmWave propagation, the path-loss for a mmWave communication link i, l i , can be modeled with three link-states: outage (l iO ), LoS (l iL ) or NLoS (l iN ) [START_REF] Akdeniz | Millimeter wave channel modeling and cellular capacity evaluation[END_REF]. We formulate the path-loss with respect to these three states as follows l iO = 0, l iL = (α L d i ) -β L , and l iN = (α N d i ) -β N , where α L (α N ) can be interpreted as the path-loss of the LoS (NoS) link at 1 [m] distance, and β L (β N ) denotes the path-loss exponent of the LoS (NLoS) link. From experimental results [START_REF] Akdeniz | Millimeter wave channel modeling and cellular capacity evaluation[END_REF], β N value (can be up to 4) is normally higher than β L value (i.e., 2). Then, each linkstate is formulated by the channel state probabilities P O , P L , and P N , respectively, as

P O = max(0, 1 -γ O e -δ O di ); P L = (1 -P O )γ L e -δ L di ; P N = (1 -P O )(1 -γ L e -δ L di )
, where d i denotes the transmitter-receiver distance; the parameters γ L (γ O ) and δ L (δ O ) depend on both the propagation scenario and the considered carrier frequency [START_REF] Renzo | Stochastic geometry modeling and analysis of multitier millimeter wave cellular networks[END_REF]. Thus, the corresponding path-loss component of the channel is modeled as

l i = I[U < P L (d i )]l iL + I[P L (d i ) ≤ U < (P L (d i ) + P N (d i ))]l iN + I[(P L (d i ) + P N (d i )) ≤ U ≤ 1]l iO , where U ∼ U[0, 1]
is a uniform random variable. For computing the path-loss model, we use the parameter values at 73 GHz as in [START_REF] Lin | Dynamic base station formation for solving NLOS problem in 5G millimeter-wave communication[END_REF]Table I].

Channel Vector: Given that the blockage information is not entirely feasible, we exploit the stochastic geometry analysis for modeling the mmWave channel vector [START_REF] Lin | Dynamic base station formation for solving NLOS problem in 5G millimeter-wave communication[END_REF]. Specifically, we model the channel vector as

h i = √ l i β i ξ i ∈ C M,1
, where l i is the large-scale path-loss in power of the mmWave communication link i (which might also include log-normal shadowing), β i ∈ C M,M is the co-variance matrix for antenna correlations in small-scale fading, and ξ i ∈ C M,1 is a Gaussian vector with the zero-mean circularly symmetric Gaussian noise distribution CN (0, I M ) for the fast-fading.

Beamforming: To ensure an acceptable range of the communication in the multi-antenna mmWave transmissions, we introduce the precode vectors, i.e., beamforming weights at the RRHs, where the weight vector w i ∈ C M,1 is the linear downlink beamforming vector at the jth RRH corresponding to the ith SD-GW. The beamforming gain is given as

G BF i =
w H i β i w i , with β i being the covariance matrix of the channel response vector h i . In the case where the fading is fully correlated between the antennas, the matched filtering precoding method is exploited as

β i = h H i h i and w i = h i / h i ; therefore, G BF i = h i 2 .
3) Achievable Uplink Rate: Following the above multiantenna mmWave transmission characterization over a link i, the received base-band signal vector y ∈ C M,1 at the BBS at a given instant reads y ul = √ P ul Hx ul +η ul , where each element of the received signal vector corresponds to a BBS antenna, 1 denotes the mmWave channel corresponding to the ith SD-GW, x = [x 1 • • • x I ] T denotes the I×1 vector containing the transmitted signals from all the SD-GWs, P ul is the average transmit power of each SD-GW, and η ul ∼ CN(0, σ) is the zero-mean circularly symmetric Gaussian noise with the noise power σ 2 .

H = [h 1 • • • h I ] ∈ C M,I , h i ∈ C M,
Let A be the M×I linear detection matrix (which depends on the channel matrix H) used by the BBS b ∈ B to separate the received signal into user streams. The BBS processes its received signal vector and obtains the estimated channel matrix (assuming no estimation errors) by multiplying the detection matrix with the Hermitian-transpose of the linear receiver as ỹul = A H y ul = A H Hx + A H η ul . The ith element of ỹul can be written as ỹul i = P ul i a H i Hx + a H i η ul , where a i is the ith column of A. By the elements multiplication, we further get

ỹul j = P ul i a H i h i x i + I k=1,k =i P ul k a H i h i x k + a H i η ul
, where x i denotes the ith element of x and h i is the ith column of H. Then, the signal-to-interference-plus-noise ratio (SINR) achieved by the ith SD-GW, γ ul i , is

γ ul i = P ul i |a H i h i | 2 /( I k=1,k =i P ul k |a H i h k | 2 + a i 2 σ 2 ). (4)
Assuming an ergodic channel [START_REF] Jose | Pilot contamination and precoding in multi-cell TDD systems[END_REF], the achievable uplink rate of the ith SD-GW is given by R ul i = B log 2 (1 + γ ul i ), where B denotes the wireless transmission bandwidth. We define the uplink sum rate [bits/s/Hz] per cell considering the associations between RRHs and SD-GWs as follows

C ul = I i=1 g ij N ij R ul i , ∀j ∈ J .
(5) 4) Achievable Downlink Rate: The received base band signal y dl ∈ C at the ith SD-GW is given as y dl = P dl j h H i s+η dl , where s ∈ C M,1 is the signal vector intended for the ith SD-GW with P dl j average power; η dl ∼ CN (0, σ 2 ) is the receiver noise. We assume channel reciprocity, i.e., the downlink channel h H i is the Hermitian transpose of the uplink channel h i . The transmit vector s is given as s = √ υ

I i=1 w i x dl i = √ υ W x dl , where W = [w 1 • • • w I ] ∈ C M,I
is a pre-coding matrix (i.e. the network beamforming design) and

x dl = [x 1 • • • x I ] T ∈ C I,1
contains the data symbols for the ith SD-GW. The parameter υ normalizes the average transmit power per RRH to E[

P dl j I s H s] = P dl j , i.e., υ = E 1 I tr(W W H ) -1 .
The associated SINR achieved by the ith SD-GW, γ dl i , is

γ dl i = υ|h H i w i | 2 / I k=1,k =i υ |h H i w k | 2 + σ 2 . ( 6
)
Since the SD-GWs do not have any channel estimate, we provide an ergodic achievable rate based on the techniques developed in [START_REF] Jose | Pilot contamination and precoding in multi-cell TDD systems[END_REF]Theorem 1] as

R dl i = B i (1-κ) log 2 (1+γ dl i )
, where B i is the bandwidth allocated to the ith SD-GW, κ accounts for the spectral efficiency loss due to signaling at RRH. The downlink sum rate [bits/s/Hz] per cell considering the associations between RRHs and SD-GWs is

C dl = I i=1 g ij N ij R dl i , ∀j ∈ J . ( 7
)

C. Optimization Framework

In the following, we elaborate the optimization framework for the sensing and SD-RAN domain in Section III-C1 and Section III-C2, respectively.

1) IoT Sensing Domain:

The IoT should provide differentiated services for applications with different QoS requirements, ranging from error-limited applications or minimum energy consumption applications to highly-delay-sensitive applications or any combination of them. Hence, we consider a multiobjective optimization problem which can simultaneously optimize multiple conflicting end-to-end objectives such as PER (Φ e2e ), delay (T e2e ), and energy consumption (E e2e ), subject to certain constraints.

We construct a single aggregate objective function which is defined by the weighted linear combination of each objective; we use w PER , w E , and w T as the three weights for the endto-end PER, energy consumption, and time delay objectives, respectively. As these three objectives differ in the units in which they are measured as well as their order of magnitude, we normalize each term and optimize their deviations with respect to some predefined utopia values (unattainable minimum values which are used to provide the non-dimensional objective functions and can be computed offline [START_REF] Han | A cross-layer communication module for the internet of things[END_REF]). Therefore, the overall objective function for WSN communication becomes

minimize w PER | Φ e2e Φ opt -1| + w E | E e2e E opt -1| + w T | T e2e
T opt -1|, (8) where w PER + w E + w T = 1; Φ opt , E opt , T opt are the endto-end PER, energy consumption, and delay utopia values for normalizing purposes, respectively. Note that ( 8) may target at different degrees of QoS requirements for various IoT applications by adapting the specific weight value (w PER , w E , or w T ) according to the application.

Statistical QoS Guarantee: The higher transmission reliability associated with lower PER is crucial for almost all types of WSN. Also, having a bounded delay is especially important for real-time monitoring and applications with timing constraints. Aiming to support the distributed functionalities among sensors, in the following we form the per-node based constraints (i.e., for transmissions upon link i) of link reliability, delay, and energy.

Given the tolerable maximum end-to-end PER, Φ TH , the corresponding reliability constraint is

Φ e2e = 1 -(1 -Φ Rtx i ) N hops ≤ Φ TH , (9)
where (1 -Φ Rtx i ) N hops represents the PER of multi-hop transmission; Φ Rtx i [see [START_REF] Akyildiz | 5G roadmap: 10 key enabling technologies[END_REF]] is the PER over link i with hybrid ARQ error control, and N hops is the number of traversed hops for an incoming packet to node k.

Regarding the energy consumption, let E k denote the energy consumed on the kth node, it is defined by the product of the packet size and the energy required for one bit as

E k = ℘(2E bit elec + P tx k /F k ), where E bit elec = E bit-Tx elec = E bit-Rx elec
in Joule/bit is the distance-independent energy to transmit one bit; E bit-Tx elec is the energy per bit needed by the transmitter electronics, and E bit-Rx elec is the energy per bit utilized by the receiver electronics; P tx k and F k are the transmission power and the total local traffic at the kth node, respectively. Restricted by the constraint E TH , the overall energy consumption over the entire path is computed by

E e2e = N hops k=1 E k ≤ E TH . ( 10
)
Finally, restricted by the maximum end-to-end delay T TH , the statistical delay guarantee is modeled as the probability that a packet is delivered under the deadline should be at least ϕ as follows

P(T e2e ≤ T TH ) ≥ ϕ. ( 11
)
The end-to-end delay, T e2e , is calculated as

T e2e = N hops i=1 (T queuing i + T i ),
where T queuing i is the queuing delay at link i and T i is the delay at link i excluding the queuing delay. T i is composed of the time for handshake T handshake i , time for data transmission T data i , timeout delay T timeout i , time for acknowledgment T ack i , sleep time T sleep , and the signal processing time T DSP i , and is calculated as

T i ≤ (T handshake i + T data i + T timeout i )(N Tx-ub i -1)+(T handshake i +T data i +T ack i )+T sleep +T DSP i .
Note that the queuing delay is determined by many factors such as current traffic, other nodes' behavior or hardware status. Therefore, the overall end-to-end delay is modeled, by applying the central limit theorem, as a Gaussian random variable T e2e ∼ N

N hops i=1 T i + E[T queuing i ] , N hops i=1 V[(T queuing i )] 1/2 .
Then, the end-to-end delay constraint ( 11) is transformed into [START_REF] Renzo | Stochastic geometry modeling and analysis of multitier millimeter wave cellular networks[END_REF] where φ(•) is the cumulative distribution function of N (0, 1). Finally, the end-to-end throughput, G e2e , is inversely proportional to the end-to-end delay as G e2e = pl/T e2e .

N hops i=1 T i + E[T queuing i ] + φ -1 (ϕ)( N hops i=1 V[(T queuing i )]) 1/2 ≤ T TH ,
2) SoftAir SD-RAN Domain: As IoT applications demand services with different rate requirements, we formulate these requirements in terms of SINR coverage and achieved sumrate per cell at the SD-RAN. Given ϑ as the minimum tolerable SINR over a link i, the SINR constraints of SD-GWs can be formulated as

γ i ≥ ϑ, ∀i ∈ I, (13)
where γ i is computed by either ( 4) or ( 6) in case of uplink or downlink transmission, respectively. From the association scheme, we can obtain the equality a j = 1 -J j=1 (1g ij N ij ), ∀j ∈ J and the following sets of association constraints between RRHs and SD-GW:

a j ≥ g ij N ij , ∀i ∈ I, j ∈ J ; ( 14
) J j=1 g ij N ij ≥ 1, ∀i ∈ I, (15)
where [START_REF] Jose | Pilot contamination and precoding in multi-cell TDD systems[END_REF] implies that a RRH is in active mode if it is associated with at least one SD-GW whereas [START_REF] Ha | Coordinated multipoint transmission design for cloud-rans with limited fronthaul capacity constraints[END_REF] ensures that each SD-GW is served by at least one RRH. On the other hand, given the pre-coding vector at the jth RRH for the ith SD-GW, the transmitter power used by this RRH to serve the ith SD-GW is w H i w i [START_REF] Ha | Coordinated multipoint transmission design for cloud-rans with limited fronthaul capacity constraints[END_REF]. Let P r-max j denote the maximum power of the jth RRH, we impose the constraints on RRHs' downlink beamforming weights as follows

I i=1 w H i w i ≤ a j P r-max j , ∀j ∈ J ; (16)
w H i w i ≤ g ij N ij P r-max j , ∀i ∈ I, j ∈ J , ( 17
)
where (16) limits the total transmit power of RRHs and (17) ensures that the transmit power from the jth RRH to the ith SD-GW is set to zero if there is no association between them. Furthermore, by only allowing the links in L (see Section III-B1) we set the beamforming weights of mmWave communication links as

w H i w i = 0 if N ij = 0, ∀i ∈ I, j ∈ J , ( 18
)
so that we reduce all possible links between J RRHs and I SD-GWs to |L| links (given that |L| JI), which in turns dramatically shrinks the possible solution sets of precoding vectors for lower computation complexity [START_REF] Lin | Dynamic base station formation for solving NLOS problem in 5G millimeter-wave communication[END_REF], [START_REF] Ha | Coordinated multipoint transmission design for cloud-rans with limited fronthaul capacity constraints[END_REF]. Additionally, the per-fronthaul capacity constraints (neglecting the fronthaul capacity consumption for transferring compressed beamforming vector) are formulated as follows

C ≤ C fh j , ∀j ∈ J , ( 19
)
where C is computed by [START_REF] Association | IEEE Standard for Low-Rate Wireless Networks[END_REF] in uplink transmission or by [START_REF] Han | A cross-layer communication module for the internet of things[END_REF] in downlink transmission. This indicates that the total data rate transmitted at the jth RRH should be less or equal to the rate forwarded by the jth fronthaul link. We aim to maximize the total achievable uplink/downlink data rates at SD-GWs; the overall objective function for the SD-RAN becomes

maximize C = I i=1 R i , ( 20
)
where R i depends on the communication direction: uplink (see Section III-B3), downlink (see Section III-B4).

Statistical QoS Guarantee: To ensure low transmission delay, the size of each packet, ℘ bits, is small enough such that it can be transmitted within one uplink phase; the transmission time interval (TTI) is the same as the frame duration, T frame , and T frame T TH . Thus, the uplink (downlink) transmission can be finished within the duration of τ ul (τ dl ). Furthermore, the expected queuing delay for the packets at the SD-GW should be bounded as

E[T queuing i ] ≤ T TH -T frame . ( 21
)
Then, to guarantee the stringent QoS requirements for all SD-GW i ∈ I, our cross-layer design satisfies that: (i) the probability that the queuing delay is larger than (T TH -T frame ) is smaller than a predefined violation probability D TH , i.e., P(T queuing i > (T TH -T frame )) < D TH ; (ii) with finite BCH codes, the transmission of each packet is finished within one frame with a small error probability, i.e., Φ e2e i ≤ Φ TH ; (iii) to guarantee the end-to-end delay and its reliability with finite transmit power, the packet dropout probability, P pkt-dropout i is smaller than a predefined violation probability Q TH ; (iv) the probability that the SINR coverage is smaller than ϑ is smaller than a predefined violation probability ϑ TH , i.e., P(γ i < ϑ) < ϑ TH . Finally, the end-to-end system reliability is controlled by

1 -(1 -D TH )(1 -Φ TH )(1 -Q TH )(1 -ϑ TH ) ≤ Ω, (22)
where Ω dictates the overall reliability requirement. The entire formulation of the joint cross-layer optimization for SD-GWs is summarized in Table I.

D. Protocol Operation

The SD-GWs possess the necessary knowledge (e.g., network topology, link qualities) to orchestrate sensors at the southbound interface and the application requirements at the northbound interface. Therefore, they are able to receive IoT data traffic from the sensing devices and forward this traffic to the SoftAir SD-RAN. Depending on the communication direction, each SD-GW will either perform protocol conversions in such a way it can forward the data to the SoftAir system with the maximum achievable rate or forward the data to the WSN meeting the application QoS requirements by performing the optimization framework. The SD-GW first builds the hierarchical topology (DODAG) that specifies a route from each node to itself using a DODAG Information Object (DIO) message. Once a node receives a DIO, it can first, calculate its rank, then, choose a set of parent nodes

P r-max j , C fh j , ϑ TH , Ω, T frame , ∀j ∈ J Compute (offline): w PER , w E , w T , N Tx-ub k , F k , ∀k ∈ K Find:
Sensor domain: P tx k , mod i , cod i , ℘, T listen , ∀k ∈ K, i ∈ I Cellular domain: P ul i , P dl j , a j , g ij , w i , ∀i ∈ I, j ∈ J Objectives: (candidate nodes where data can be forwarded) and finally, send a new DIO message to inform other neighbors. The rank is an integer that increases linearly from the SD-GW and identifies the position of a node about the SD-GW and other nodes in the network. The parents must have a rank equal or lower than the node. Each node has a default path (i.e., preferred parent) but maintains a list of parents for resilience purposes, overhead reduction in case of link degradation, or increasing performance. Hence, immediately after the reception of a DIO message, a node has an optimal path towards the SD-GW. The optimal path is set according to the optimization framework detailed in Section III-C. The SD-GW translates the application requirements into network QoS requirements and constructs the optimal architecture finding the optimal communication parameters on both the sensor and the SD-RAN domains and forwarding the data through the correspondent interface. The SD-GWs determine the routing paths at the local level, and at the intercluster level, cluster coordinators, who are elected by the transmission algorithm, facilitate the communication.

minimize w PER | Φ e2e Φ opt -1| + w E | E e2e E opt -1| + w T | T e2e T opt -1| (8) maximize C = I i=1 R i . ( 20
IV. PERFORMANCE EVALUATION In this section, we present simulation results to assess and compare the performance of the proposed cross-layer design detailed in Section III with that of conventional layered protocol solutions, i.e., individual communication functionalities that do not share information and operate in separate layers. In all experiments, each point represents the average value of 10 5 samples. The overall reliability requirement is Ω = 10 -5 .

Following the system model (see Section II-A), we design a set J of J = 12 associated RRHs in the SD-RAN, each RRH is equipped with M = 4 antennas; the coverage area of every RRH has a radius of 200 m. The channel vectors are generated according the mmWave communication characterization detailed in Section III-B2, where the three-state path-loss model with log-normal shadowing is considered; the carrier frequency is set at 73 GHz. The transmit power constraint for each RRH is P r-max j = 45 dBm. Moreover, we assume that all the RRHs possess the same fronthaul capacity, i.e., C fh j = 6 bps/Hz, since 64 QAM is the highest constellation supported by the network, and thus the maximum spectrum efficiency per data stream is 6 bps/Hz. The bandwidth of the wireless link is B = 500 MHz. In the sensing domain, the set J of associated RRHs serve a set I of clustered sensor nodes. The ith cluster has one SD-GW as the cluster head. The maximum transmission power of each SD-GW is set at 23 dBm and thermal noise power is assumed to be -101 dBm/Hz. The sensor nodes inside the cluster are randomly deployed; the concerned coverage area of each sensor node has a radius of 50 m. Each node uploads packets with rate 0.02 packets/TTI; the TTI has set to 0.1 ms. We compare the results when the QoS requirements are focused on end-toend delay minimization and energy consumption minimization while the PER is constrained to be below Φ TH = 10 -6 .

The packet sizes that we consider in the simulations are ℘ = {20, 40, 100, 133} bytes. We first examine the interactions between link layer and routing functionalities via end-to-end energy consumption and throughput performance of one IoT cluster at the sensing domain and compare the results of our design with that of a classical IoT communication solution. Then, we examine both the sum-rate and the achievable rate per SD-GW in the SD-RAN as the number of IoT clusters increases. For this, we consider that each cluster has a fixed number of sensor nodes and one SD-GW as cluster head. A layered protocol architecture is built for the comparison with our proposed design; its configuration is the following:

Classical IoT Solution (sensing domain: IEEE 802.15.4 + RPL; SD-RAN domain: conventional association schemes used in mmWave [START_REF] Renzo | Stochastic geometry modeling and analysis of multitier millimeter wave cellular networks[END_REF], [START_REF] Lin | Dynamic base station formation for solving NLOS problem in 5G millimeter-wave communication[END_REF]) In the sensing domain, this protocol configuration follows the frequency spectrum allocation according to the IEEE 802.15.4 standard at 2400 MHz (OQPSK modulation, 250 kbps transmission rate) and Sleep MAC + CSMA/CA for the PHY and link layer, respectively. In the NET layer, this protocol uses RPL and, for a fair comparison, the objective function is similar to that of our design (focused on the minimization of end-to-end delay and energy consumption while the PER is constraint to be below Φ TH = 10 -6 ). In the SD-RAN, the following association

Figure 1 .

 1 Figure 1. SoftAir [4] network architecture for 5G IoT communication.

Figure 2 .

 2 Figure 2. Directed Acyclic Graph (DAG) for a WSN consisting of 25 nodes randomly deployed and the optimal path (red color) from source to destination.

Figure 3 .

 3 Figure 3. IoT performance metrics vs. number of nodes in the network for the proposed design and the classical IoT solution. (a) Energy Consumption. (b) Throughput.

Table I HETEROGENEOUS

 I CROSS-LAYER OPTIMIZATION FRAMEWORKSensor domain:Φ opt , E opt , T opt , Φ TH , E TH , T TH , D TH , Q TH , h, N max k , mem k , ∀k ∈ K Cellular domain:

	Inputs:

schemes used in conventional mmWave communication are configured: (i) highest received power association and (ii) smallest path-loss association. Although the described layered protocol applies previously proposed functionalities more or less, it only considers its related layers without information sharing but with reasonable assumptions for the other layers.

Fig. 3a and Fig. 3b show, in logarithmic scale, the endto-end energy consumption [μJ] and throughput [bits/TTI], respectively, as a function of the number of nodes in the cluster. In Fig. 3a we observe that the energy consumption of the SD-GW design is always lower than that of the classical IoT solution; on average, the energy savings of our solution ranges from 22.6% up to 92.5%. Also, we can observe that the energy consumption increases gradually as the number of nodes in the network increases since the higher node density essentially creates more paths for the data transmission. It is evident that using large packet sizes imply the highest levels in energy consumption. Fig. 3b shows the significant improvement of throughput with the SD-GW cross-layer design. The reason is that our solution selects the optimum path from the source to destination and the best parameter configuration for the device such as power, modulation, coding scheme, packet size.

On the other hand, we analyze the achievable rate per SD-GW in the SD-RAN domain, the set J of associated RRHs serve different densities of IoT clusters; each IoT cluster has 100 nodes and one SD-GW as cluster head. In upstream transmissions, Fig. 4a shows that our design outperforms conventional association schemes used in mmWave transmissions with coordinated multi-point. On average, the spectral efficiency of our design is 40% higher than that of other association schemes and the achieved data-rate is up to 54% higher than that of conventional solutions. Regarding downstream transmissions, Fig. 4b shows that, on average, our design outperforms 26% conventional association schemes in terms of spectral efficiency. Furthermore, the spectral efficiency peaks at 34 bits/s/Hz; then, it slightly declines as the number of SD-GW increases. Although the achievable data rate per SD-GW decreases with the increasing SD-GW density, our architecture can provide high data-rate for each SD-GW by increasing the number of antennas at the RRHs. This fact is shown in Fig. 4c for high densities of SD-GWs (60 and 80); specifically, with an antenna array of 128 elements at the RRHs and 80 SD-GWs deployed in such an area, our design can support each SD-GW with at least 450 [Mbits/s] rate in downlink and 150 [Mbits/s] rate in uplink through mmWave transmissions.

V. CONCLUSION We presented a SoftAir architecture for providing IoT communication by exploiting a set of emerging features such as mmWave and SDN. Our solution brings significant system synergies by jointly optimizing functionalities in different communication layers for both IoTs and SD-RANs; SD-GWs are proposed to (i) explore the interactions of two-type networks, (ii) enable cross-layer solutions, and (iii) render efficient energy consumption and throughput in IoT, while maximizing the sum-rate at the SD-RAN for reliable IoT communication. Simulation results validate the superiority of our solutions that provide performance improvements in terms of energy savings, throughput, and spectral efficiency in comparison with conventional IoT solutions. It allows enormous and reliable IoT connectivity with high data rates at 5G SD-RANs.


Jabier Martinez
email: jabier.martinez@tecnalia.com

Xhevahire Tërnava
email: xhevahire.ternava@lip6.fr

Tewfik Ziadi
email: tewfik.ziadi@lip6.fr

Software Product Line Extraction from Variability-Rich Systems: The Robocode Case Study

Keywords: Software and its engineering → Software reverse engineering, Software product lines, • Social and professional topics → Software engineering education, Software Product Lines, Reverse-engineering, Extractive Software Product Line Adoption, Education, Robocode

The engineering of a Software Product Line (SPL), either by creating it from scratch or through the re-engineering of existing variants, it uses to be a project that spans several years with a high investment. It is often hard to analyse and quantify this investment, especially in the context of extractive SPL adoption when the related software variants are independently created by different developers following different system architectures and implementation conventions. This paper reports an experience on the creation of an SPL by reengineering system variants implemented around an educational game called Robocode. The objective of this game is to program a bot (a battle tank) that battles against the bots of other developers. The world-wide Robocode community creates and maintains a large base of knowledge and implementations that are mainly organized in terms of features, although not presented as an SPL. Therefore, a group of master students analysed this variability-rich domain and extracted a Robocode SPL. We present the results of such extraction augmented with an analysis and a quantification regarding the spent time and effort. We believe that the results and the a-posteriori analysis can provide insights on global challenges on SPL adoption. We also provide all the elements to SPL educators to reproduce the teaching activity, and we make available this SPL to be used for any research purpose.

INTRODUCTION

Software Product Line (SPL) engineering enables a systematic reuse within a family of systems. Its general framework is defined by the dual phases of domain and application engineering [START_REF] Apel | Feature-Oriented Software Product Lines -Concepts and Implementation[END_REF]. During domain engineering, the scope of the SPL is defined, and commonalities and variabilities among software products are explicitly specified. The prime entities in this specification use to be based on the concept of feature, which is defined as a prominent or distinctive characteristic, quality or user-visible aspect of a software system or systems [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF]. Domain engineering also aims at implementing reusable assets and shaping them according to the identified features. Domain engineering can be achieved using an extractive SPL adoption approach [START_REF] Krueger | Easing the Transition to Software Mass Customization[END_REF] where existing legacy artefact variants are analysed and their variability models with reusable assets are extracted. The existence of legacy artefact variants is a usual case in SPL adoption (50% of the cases according to an industrial survey [START_REF] Berger | A Survey of Variability Modeling in Industrial Practice[END_REF]), and re-engineering them into an SPL is still a challenging process requiring a high investment which is often difficult to analyse and quantify. In addition, the problem is exacerbated when the related software variants are not created through the clone-and-own approach but independently created by different developers following different system architectures and implementation conventions.

In this work, we apply the extractive SPL adoption approach to a variability-rich family of systems, the Robocode programming game 1 and, more specifically, the source code-based bots implemented by its community. Robocode has a large body of documentation and available bot implementations, which make it an appealing domain for our study. Moreover, it is not organized as an SPL, as different developers create independently their own bot variants for their different needs. The objectives of our work are threefold: [START_REF] Acher | Teaching Software Product Lines: A Snapshot of Current Practices and Challenges[END_REF] to report an experience on the extraction of an SPL which can help to bring light to SPL extraction issues in a comprehensible scenario, [START_REF] Apel | Feature-Oriented Software Product Lines -Concepts and Implementation[END_REF] to analyse and quantify the investment required to extract the SPL from the existing artefact variants, (3) to contribute pedagogical material on SPL adoption which is a real industrial need [START_REF] Martinez | ESPLA: A Catalog of Extractive SPL Adoption Case Studies[END_REF] not sufficiently covered by current pedagogical material [START_REF] Acher | Teaching Software Product Lines: A Snapshot of Current Practices and Challenges[END_REF]. A group of students had the task to analyse the Robocode domain, formalize the bots commonalities and variabilities using feature modelling [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF] in the FeatureIDE tool [START_REF] Thüm | FeatureIDE: An extensible framework for featureoriented software development[END_REF], and to extract feature-based reusable assets using a compositional approach to implement variability based on the FeatureHouse composer [START_REF] Apel | FEATUREHOUSE: Language-independent, automated software composition[END_REF].

We present in this paper the results of the extracted Robocode SPL in terms of features and their associated reusable assets. We discuss the time and effort spent during the SPL extraction based on the collected answers from a survey that we conducted among the participants. Principally, we present the distribution of time in the different activities and discuss some reflections on the gained knowledge. In addition, we make publicly available the extracted SPL and the teaching material, and we present how the extracted SPL can be used beyond education. The findings are not only interesting for educators but also for a wider audience interested in understanding SPL extraction issues from a practical perspective. These issues appear during the end-to-end extraction of our "academic-scale" family of systems. Moreover, the provided material together with our publicly available extracted Robocode SPL can be used to reproduce the case study and compare with our results. The Robocode SPL including technical information for how to use it, and extra material is available 2 .

In the following, we present background information about Robocode and its existing assets (Section 2). We also present the case study settings including the participants' description and the context and duration of the project (Section 3). We report the results of the domain analysis phase (Section 4) and the results of the domain implementation phase (Section 5). Further, an analysis and discussion of the results are also given (Section 6). We then outline some possible uses of our extracted Robocode SPL (Section 7). Finally, we present related works (Section 8) and we conclude the paper while outlining future work (Section 9).

BACKGROUND ON ROBOCODE

An API of the Robocode game, in Java or .NET, is provided to any participant to develop a virtual battle tank (bot from now onwards) that battles against other bots from other developers in a closed-arena. A battle simulation environment is provided to observe the programmed behavior and debug the bots as shown in the screenshot of Figure 1. Under the motto "Build the best, destroy the rest", the Robocode community is active with a long history which started in 2001. Besides its pedagogical values for teaching programming [START_REF] Kelly | RoboCode & problem-based learning: a non-prescriptive approach to teaching programming[END_REF] or even artificial intelligence approaches [START_REF] Hartness | Robocode: using games to teach artificial intelligence[END_REF], it has been also used as case study for advanced computational intelligence research (e.g., genetic programming [START_REF] Shichel | GP-Robocode: Using Genetic Programming to Evolve Robocode Players[END_REF]). Game rules. A Java API 3 is provided to implement a virtual bot with body, gun, and radar (as shown in Figure 2). We explain some of the most relevant API methods. The body will move with the setAhead method that takes a distance as parameter. Also the desired velocity can be 2 Robocode SPL: https://github.com/but4reuse/RobocodeSPL_teaching 3 Robocode Java API: http://robocode.sourceforge.net/docs/robocode/ defined. The body can be turned with setTurnRight and a desired angle. In a similar way, the gun, which is on top of the body, can be turned with setTurnGunRight. One can also decide when to fire with setFireBullet and defining as parameter which power they want to put in the bullet (bullets with lower power travel faster, and our bot will lose less energy for firing the bullet). The radar, on top of the gun, can be turned with setTurnRadarRight. There are several events that can be listened by the bot, the most important one is the event when the radar detects an enemy bot because its position can be stored (bullets are not detected by the radar). Other examples of events are related to being hit by a bullet, by a wall, or by a bot.

These API primitives for movement, targeting, and radar enable to program very diverse and advanced techniques to face the battle. These techniques are behavioral features which are the more relevant source of diversity in the Robocode family of bots. There are other sources of variability such as the colors of the body, gun, radar and bullets which are not of our interest in this work as they do not have any impact on the behavior. There is also variability in the type of battle such as 1 vs 1 (see Figure 1), melee with several bots fighting among them, or team where several bots communicate among teammates and fight against another team. This variability is not taken into account as we focused on behavioral features of the bots.

Knowledge and assets base. The Robocode community has created a large knowledge base which is centralized in their official wiki called RoboWiki 4 . Beginners and advanced developers can find, share and discuss any topic with a special focus on bots' features. A plethora of bots is publicly available including its source code in common or personal repositories. For example, more than 2900 bots (including variants and versions) are available in a public repository 5 . We automatically checked that, in this repository, more than 1500 made their source code publicly available with an average of 24.38 Java files each. Around one-third of these 1500 are bots with only one or very few number of Java files. The reason is that there are Robocode competitions where the code size is restricted giving rise to the haiku [START_REF] Shichel | GP-Robocode: Using Genetic Programming to Evolve Robocode Players[END_REF], nano, mini or micro categories. For those that do not have code size restrictions, we can find bots with hundreds of Java files.

The Robocode community, as result of their collaborative work, maintains the documentation of known features. This includes a description and, in some cases, some hints or snippets of how to implement them. Apart from the RoboWiki pages dedicated to the features, 300 bots are documented in the RoboWiki by the authors themselves 6 , including information about the features used for movement and targeting. Despite all this Robocode knowledge and assets base, there is an absence of an explicit specification of all the existing variability among these thousands of bots. The Robocode SPL extra material that we make public includes the data we gathered about the bots repository and the RoboWiki bots.

THE ROBOCODE CASE STUDY

This Section explains the Module framework which was used as the reference architecture for the SPL, and the case study settings regarding the task and the involved participants.

An Imposed Reference Architecture: The Module Framework

Robocode bots are development projects requiring a certain design and structure to ease their maintenance and iterative enhancements.

As mentioned in Section 2, several bots are implemented in just one Java class, especially those competing in categories with code size limitations. However, bots without these limitations use to be more carefully structured. To facilitate the reuse of common functionalities and to facilitate the integration of behavioral components, certain members of the community have developed frameworks aiming to ease the development of bots. One example is the Xander framework 7 or the Module framework 8 . In this work, we The Module class takes care of managing all the information about the battle (e.g., listening and processing events, updating enemy positions, keeping the history of fired bullets, sharing information if there are teammates, and executing the behavior by extending the run method from the Robot class). The abstract methods initialize and selectBehavior will be specialized when a bot instance wants to be created. The Module class contains five Parts and it will notify the parts for each event that happens during the battle. Each part has its own responsibility:

• Radar: to scan the enemies by moving the radar.

• Movement: to move the bot by rotating and setting the speed.

• Targeting: to target by turning the gun. This will usually require to use the current enemy position but not necessarily. For example, the AreaTargeting strategy will turn the gun to the area of the battlefield with the greatest number of enemies. • Gun: to set the fire power.

• SelectEnemy: to select the current main enemy among all the enemies. At the bottom of Figure 3, we have an example of a bot named ModuleBot. This bot extends Module and the behavior is defined with the implementation of the different Parts. SpinningRadar is a radar behavior that turns the radar indefinitely without focusing on any specific enemy. HeadOnRamming is a movement that tries to crash the enemy by continuously moving towards the enemy position at the maximum speed. LinearTargeting is a targeting behavior that assumes that the enemy will continue in the same direction and at the same speed to estimate its position and target the gun accordingly. Maximum is a gun behavior to always fire with the maximum of bullet power. Closest is a SelectEnemy behavior that continuously checks which is the nearest enemy to select it as the current enemy.

The Module framework follows the strategy pattern to include the bot behavior so we considered that it was a good candidate to be used as the base for the implementation of an SPL. This imposed framework for the SPL required that features extracted from the RoboWiki or from existing bots will need to conform to the framework. In general, the integration in the framework was not difficult (as stated by the SPL developers), but they were aware of this activity during the re-engineering of the existing code.

Case Study Settings

Participants and duration. The case study included 6 Master students at Sorbonne Université (last year before starting a Ph.D. or starting an industrial professional career) over 3 months to extract the Robocode SPL. The six participants (three men and three women, uniform in age and in their university background) formed a group in the context of a course related to project management. The technical tasks for software development within the course must not be trivial but challenging for the three months of its duration. The Robocode SPL was realized in this time frame, working as a self-organized group, and in parallel with other courses and projects in their master program.

Training activities. The participants had no initial knowledge of SPL theory nor on any tool for SPL implementation. In view of this project, a tutorial was conducted during 4 hours by the last author of this paper, as a senior expert on SPLE. This tutorial included an introduction to SPLs and a hands-on practice on FeatureIDE and FeatureHouse. In a similar way, they had not any knowledge on Robocode. Another 4 hour tutorial was performed to teach Robocode and the Module framework by the first author of this paper. A small example of FeatureIDE usage to derive variants of bots was implemented. This SPL was then used as a base to incrementally develop the final Robocode SPL. Despite that their work was autonomous, we gave support for specific questions about the SPL implementation tooling and Robocode.

DOMAIN ANALYSIS

Formalization of domain variability. Figure 4 shows the resulting feature model [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF]. Feature names are not readable but it serves to get an impression of its size and topology. The feature model includes a total of 115 features from which 7 are part of the mandatory core. 22 are abstract features intended to group alternative or optional features, and the remaining 93 are behavioral features intended to have an implementation counterpart. Features starting from level two of the feature model tree are behavior techniques which are grouped as alternative features (i.e., only one can be selected). For example, for the Radar, there are 9 feature alternatives, or for the Movement, there are 27 alternatives grouped in different movement categories. On the zoomed part of Figure 4, we can see 5 out of these 9 features related to radar, and we can also see a targeting category called BasicTargeting with 7 alternative features. Given the combinatorial explosion of possible configurations, the number of possible variants exceeds several hundred thousands. The Fea-tureIDE tool was not able to compute an exact number after several hours of computation.

There are only two exceptions where the features are not grouped as alternatives but as a set of optional features (i.e., you can select none of them or any of them). One of them are features related to EnergyManagement techniques. When a bot fires a bullet, the bot loses a certain energy amount depending on the power that was established for the bullet. Energy management is a set of optional features to preserve the energy of the bot under certain circumstances. For example, if our bot energy is low, some bots establish the condition that we will never fire with a power value equal or higher than the value that will disable our bot. In those cases where the enemy energy is low, some bots reduce the bullet power to the strictly necessary power to eventually destroy the target. The other set of optional features are related to the GuessFactorTargeting feature that targets based on the histograms of the angles of previously fired bullets. These histograms can be segmented based on some battle information. For example, different histograms based on the enemy distance (e.g., when it is close, when it is far) or based on the enemy velocity or acceleration (e.g., when it is stopped, when it is moving). More than 10 segmentation options are added as optional features. The implementation of concrete examples will be shown in Section 5. Apart from these alternative constraints and groups of optional features, there are no cross-tree constraints.

Representativeness. It is difficult to measure how representative is this feature model to the existing variability in the Robocode domain which is quite vast. Based on our experience, we consider that it is representative of the main topics of the domain but we are aware that several concepts are missing. Examples of non-covered topics are: Droid bots are special bots with no radar, features to perform file-based serialization of data as bots can optionally store data of previous matches (e.g., GuessFactorTargeting histograms), or features to include or exclude debugging graphics of the features.

DOMAIN IMPLEMENTATION

Technical solution. Features in a variability model need its implementation counterpart to derive actual product variants. As variability implementation mechanism, we decided to impose the FeatureHouse [START_REF] Apel | FEATUREHOUSE: Language-independent, automated software composition[END_REF] composer available in FeatureIDE [START_REF] Thüm | FeatureIDE: An extensible framework for featureoriented software development[END_REF] which enables the composition of Java source code. Annotative approaches such as the preprocessor-based Antenna or Munge (Java-based alternatives to the widespread usage of #ifdef pre-processor directives in C source code) were also available in FeatureIDE but we opted for FeatureHouse to force a more clear separation of features.

To present a feature implementation and its composition we used a basic targeting feature called HeadOnTargeting. This technique consists in aiming the gun directly to the enemy position (or at least where we last saw our enemy). We use the notation used by Apel et al. [START_REF] Apel | FEATUREHOUSE: Language-independent, automated software composition[END_REF] where the symbol '•' is used to denote the composition operator of software artefacts. Figure 5 illustrates the composition of the feature structure trees (FSTs) [START_REF] Apel | FEATUREHOUSE: Language-independent, automated software composition[END_REF] of the HeadOnTargeting and Module features. The composition operation results in an FST where 1 package jab . targeting ; The first Java class HeadOnTargeting extends the Targeting class of the Module framework and the target method is implemented to turn the gun. The other Java file below this one is a fragment of source code that just declares the variable selectedTargeting and assigns it an instance of the HeadOnTargeting class. In Listing 2 we show how the HeadOnTargeting is composed using FeatureHouse inside the Module mandatory feature. In line 5 of Listing 2, we can observe how the variable coming from line 4 in the second part of Listing 1 was added. Then, if the HeadOnTargeting feature is selected, the instance of HeadOnTargeting will be the targeting behavior of the derived bot variant.

Size metrics. The extracted Robocode SPL had 80 features with an actual implementation counterpart. Not all the 115 features in the feature model had an implementation, as mentioned in Section 4, 22 of them are abstract features. Also, the students did not have time to implement 13 features identified in the domain analysis given the constrained duration of the project. Figure 6 shows, in the first box-plot on the left, the distribution of the number of lines of code (LoC) 9 for the 80 features. The median is 30 LoC but we can observe several features with higher numbers. The outlier counting 633 LoC, in the upper left of the figure, corresponds to the mandatory Module feature (i.e., the root of the feature model) that, as described in Section 3.1, is responsible to manage all the data of the battle and handle the events before dispatching them to the bot parts. The rest of the box-plots show the distribution of subsets of features corresponding to the six main relevant feature categories: Targeting, Movement, Gun, SelectEnemy, Radar, and EnergyManagement. We can observe that, in general, movement features are the category with a higher number of LoC, followed by targeting features. On the contrary, the features related to energy management, radar, enemy selection or gun are rather small. The other outlier of the "All features" box-plot with more than 400 LoC corresponded to a movement feature. This feature is called WaveSurfing and it is an advanced technique used by many high-competitive bots 10 . There are also tiny feature implementations. Two of the smallest features with an implementation are related to EnergyManagement features such as NoFireHigherThanRequiredToKill and NoFireHigherOwnEnergy, which implementation will be explained and shown in Listing 3.

The Robocode SPL implementation size, measured as the sum of the feature implementations, is 4,403 LoC. The mandatory Module feature represents already the 14.38%. Then, the features under Targeting and Movement constitute the 71.43%, and 14.19% for the rest of the features all together. The size of the SPL is not realistic in industrial SPLs. However, in the Robocode domain, these feature sizes are realistic. Also, we consider that the relatively small size of the features enables to implement a large diversity of features within the time constraints of the project. This characteristic makes Robocode a good candidate for educational purposes.

Feature interactions. A feature interaction is some way in which a feature or features modify or influence another feature in describing or generating the system's overall behavior [START_REF] Zave | Modularity in Distributed Feature Composition[END_REF]. In the Robocode SPL, there are two cases of feature interactions, (1) the EnergyManagement features modifying the result of the Gun features in the assignation of the bullet power, 9 LoC calculated with Google CodePro Analytics 2) the segmentation features influencing the behavior of the default GuessFactorTargeting feature. To implement the EnergyManagement features, the participants evolved the Module framework to support this new concept which is complementary to the Gun strategies. An energyManagement method was added to the abstract Module class where the default behavior is not to perform any kind of energy management and takes directly the power defined by the Gun feature. Then, the optional energy management features, if selected, will chain conditions in this method to preserve energy. Listing 3 shows the implementation of the feature NoFireHigherOwnEnergy. In Line 5 we can see a call to original(), which is a FeatureHouse reserved method to include the original code of the feature where this feature will be composed.

The GuessFactorTargeting feature was designed in a way that optional features can define the segment that applies at each moment in the battle. Listing 4 shows the implementation of DistanceSegmentation that interacts with GuessFactorTargeting by defining the segment that applies according to the distance to the current enemy. In Line [START_REF] Mcgregor | Ten years of the arcade game maker pedagogical product line[END_REF] Listing 4: The implementation of feature DistanceSegmentation see the call to the original() method that will include the original code of GuessFactorTargeting. This advanced technique in the use of FeatureHouse was the solution they found to include segments. In general, different implementation solutions can be found to solve diverse technical problems in SPL implementation.

did not compare their solution with other possibilities but they proposed working solutions which we consider valid.

Duplicated code in feature implementations. The a-posteriori analysis of the implementation revealed several cases of duplicated code among some features. For example, a method goTo(x,y) for moving the bot to a given battlefield position is present in more than ten features. The SPL features were not refactored to include these clones in separated features (that will be included if any of the features were selected). Moreover, this will avoid having source code clones among features but there is the trade-off that features will not be self-contained. There are still discussions about when cloning is considered harmful [START_REF] Kapser | Cloning considered harmful" considered harmful: patterns of cloning in software[END_REF], but in the Robocode SPL, the identified clones can represent issues in maintenance. For example, at least three different ways to implement the same goTo method can be found in the resulting SPL.

RESULTS, DISCUSSIONS AND LIMITATIONS

This section discusses the results from different perspectives, (1) its educational value, (2) the extractive process, and (3) the analysis of the time and effort. The results are based on individual questionnaires (available in the Robocode SPL extra material) and interviews.

Educational Value

The results of the knowledge gained during the project are shown in Figure 7. Concretely, it shows the average of their self-assessment before and after the project on a scale from one to ten. We can observe how their knowledge in the Java programming language remains almost constant while more advanced software engineering concepts such as feature modeling, implementing feature-based systems and SPLs are highly increased. With almost the same increase, we find the understanding of the Robocode domain and the technical skills required to use the FeatureIDE tool. One conclusion that can be obtained from this graph is that this experience has no knowledge pre-requirements for the participants apart from knowing Java (a minimum requirement accessible to anyone with basic knowledge of programming). The result is a dramatic gain of knowledge to design and implement an SPL. Compared to the traditional single-system development, the participants gained hands-on practice on implementing systematic reuse so they can respond to more advanced software engineering challenges in implementing families of systems. before after 0.17 Their high self-assessment after the project needs to be put in perspective with the scope of the project, in the sense that if they will be confronted to an industrial SPL in the future, or they will research on these topics, they will realize how broad SPL engineering is (e.g., economic models, SPL scope, different ways to implement variability, different binding times etc.) and they will probably have to re-evaluate their self-assessments. However, they gained the minimum knowledge required to start using state of the art methods and tools, instead of ad hoc solutions.

Emerging SPL Extraction Process

Given the Robocode SPL extraction task, we wanted to understand how they proceeded to implement features to investigate if their process could be generalized. Figure 8 shows the process followed by the participants to implement a feature. The flow-chart is the result of individual interviews where, quite unanimously, they agree in the presented steps. Therefore, this is the process that emerged for the majority after interviewing them once the project had been completed. Each of them begins by selecting a feature that is not already implemented or assigned to others. Then, they analyse the feature information from the RoboWiki. Whenever there is a corresponding implementation snippet for that feature, they take and adapt it to their extracted core-code assets in the Robocode SPL, while the adaptation includes the integration in the Module framework. When there is no implementation in the RoboWiki, then they have to identify which bots have this feature, so they can take the implementation from one of those bots and adapt it. Otherwise, they implemented that feature from scratch by using only its documentation. Finally, they test and debug the feature. Following this process, the source of the implementation can be either from a source code snippet available in the RoboWiki, from an existing bot, or from the documentation in the RoboWiki. Figure 9 shows the percentage of the source of the implementation. We can observe that more than a half were taken from source code snippets available in the RoboWiki and then adapted to the Robocode SPL. Taking and adapting features from a bot was also the case for around a quarter of the features. As a last option, implementing from scratch based on the documentation also happened for 22.60% of the features.

The high percentage of the use of snippets from the RoboWiki shows that the Robocode community not only explains the principles of a feature, but there is also a will to facilitate its reuse in practice. These snippets, at a smaller scale, can be analogous to the existence of reusable components in industrial settings that can be taken to implement a feature offered by this component (e.g., in-house reusable components or COTS). Taking the source code of a bot is similar to trying to locate and extract a specific feature from a complete system or from a system variant that we 51.37% 26.03%

22.60%

RoboWiki snippet

Bot Documentation

Figure 9: Sources to implement features: Robowiki code reused and adapted for the Robocode SPL, existing bot code reused and adapted for the Robocode SPL, and features implemented from scratch know that contains this feature. Finally, implementing a feature from scratch is the case where there are no available assets to mine the feature and it has to be implemented as per specification. Given that features are documented, this case study lacks a scenario (usual in industrial settings [START_REF] Martinez | ESPLA: A Catalog of Extractive SPL Adoption Case Studies[END_REF]) consisting in the need to perform interviews and workshops with different technical and non-technical stakeholders to identify and understand features. The quality of the extracted SPL artifacts was briefly discussed during the paper. The feature model is representative according to our expert judgment but it is not complete (Section 4) and duplicated code was found in feature implementations (end of Section 5). Further work will be needed to investigate which metrics can be used to evaluate the quality of the extracted SPL and which tools can be used to obtain them. More in-depth analysis of the SPL quality was out of the scope of this work.

Time and Effort During SPL Extraction

Each student was asked regarding the time spent in five main activities: (1) understanding feature modeling (FM), (2) understanding how to use FeatureIDE, (3) understanding the Robocode domain, (4) modeling the Robocode domain variability, and (5) implementing the features of the Robocode SPL. Figure 10 shows the total time of the project and the percentage dedicated to the different activities. Around half of their time was spent in the feature implementation part, which includes the time to understand certain mathematical concepts and algorithms behind the implementation of the bot behaviors. With 17.83% we have the analysis of the Robocode domain. They made a remark about several cases where features with different names were similar and they spent time thinking if they were actually different or the same. The same time was spent to understand FMs and FeatureIDE (8.67%), and a little bit less (5.67%) to actually use FeatureIDE to model the Robocode commonality and variability. Finally, an average of 11.67% of their time was spent in other activities, such as project management and documentation. In the Robocode SPL extra material we add the documentation of each feature.

Features which were well-documented in the RoboWiki and that included a snippet were much faster to extract than using other means, such as taking from an existing bot or implementing from scratch. This also explains why they always began the implementation process of a feature by searching it in the RoboWiki (cf. Figure 8), and most of the features are extracted from there (cf. Figure 9). The case of taking the implementation from existing bots was more complicated. Specially because several bots implement the same feature in different ways and by different developers. Thus, it was not always easy to define a criteria to know which one should be used as base for the extraction.

As the implementation or extraction of features took most of the time, they were asked for the time spent to implement a feature. First, they grouped features into three main categories (1) easy, (2) medium, and (3) difficult to implement. And, depending on these categories, they provide different implementation time for such features. Figure 11 shows in average their evaluated used time for features in each of the three categories. While they spent a quite uniform time to implement the "easy" and "medium" features, there were some features which were more complicated to integrate, understand their functionality, or understand the mathematical concepts and algorithms behind them. The outlier "difficult" feature that took around 9 hours corresponded to the GuessFactorTargeting including its design to interact with segmentation features, as described in Section 5. The last box-plot in Figure 11 shows the average time spent for all features. It indicates that in average a feature took between one hour to four hours and a half to be extracted or implemented.

ROBOCODE SPL AS PLAYGROUND

The Robocode SPL that we make available can be used for different purposes. In this section, we describe some of them that exploit interesting characteristics of the Robocode domain.

Extending it to attributed feature models. The variability resolution in the implemented Robocode SPL is just boolean decisions. Therefore, selected features cannot be parameterized (e.g., through feature attributes). In the current SPL implementation approach, if different feature parameters were really important, different values should have been implemented through different boolean features (e.g., a feature requires to measure if the enemy is far or not, but Automatically finding the optimal bot configuration. Given the combinatorial explosion of possible configurations in an SPL, finding the best configuration for a given context is challenging. Current approaches use to rely on evolutionary algorithms to explore the configuration space [START_REF] Guo | A genetic algorithm for optimized feature selection with resource constraints in software product lines[END_REF]. For the Robocode SPL, it is challenging to know which configuration performs the best against a given enemy bot or against a set of bots. The Robocode community has created the RoboRunner framework that enables to launch battles without the user-visible simulation, so the results (i.e., scores) of a battle are automatically obtained. These scores can be used as fitness functions to explore the Robocode SPL configuration space. The optimization can be also multi-criteria, having to balance not only the scores but also other attributes such as code size. Compared to other domains where the fitness function of a configuration is always the same (e.g., cost), a fitness function based on the battle score presents interesting characteristics as the score is not constant each time you run the battle.

Dynamic change of bot behavior. The current Robocode SPL enables to derive bots with a fixed behavior. For example, if you select one type of movement, this movement cannot be changed to other that might be more appropriate for the status of the battle at a given time. The Robocode SPL can be enriched with customizable process models [START_REF] Marcello | Business Process Variability Modeling: A Survey[END_REF] in a way that the configuration is going to be replaced with other configuration at run-time when a set of predefined events are triggered, or when certain battle conditions are satisfied.

RELATED WORK

We present the related work from the perspective of extractive SPL adoption as well as from an educational perspective.

Extractive SPL Adoption. The extractive SPL adoption (ESPLA) catalog [START_REF] Martinez | ESPLA: A Catalog of Extractive SPL Adoption Case Studies[END_REF] reports more than 125 case studies. However, only a very few of them consider the analysis of variants that are not created with clone-and-own or through automatic approaches. Only three of them consider variants that are created independently by different development teams. The HomeAway online vacation rental marketplace had to deal with the fusion of several companies of the same domain [START_REF] Krueger | HomeAway's Transition to Software Product Line Practice: Engineering and Business Results in 60 Days[END_REF]. 12 variants were implemented independently fitting each company requirements and an SPL wanted to be adopted as part of the fusion. This kind of cases can be hardly managed by tools which are mainly based in structural analysis of the variants, such as BUT4Reuse [START_REF] Martinez | Bottom-up adoption of software product lines: a generic and extensible approach[END_REF] or ECCO [START_REF] Fischer | Enhancing Clone-and-Own with Systematic Reuse for Developing Software Variants[END_REF]. The BSH induction hobs company [START_REF] Manuel Ballarín | Leveraging Feature Location to Extract the Clone-and-Own Relationships of a Family of Software Products[END_REF] also had to deal with the merging of two families counting 112 variants (46 of one family and 66 of another) with cases of features that were implemented independently. The Robocode bots and features are implemented independently by each developer representing a challenging case study for SPL extraction. Also, compared to these industrial cases, the Robocode SPL is made publicly available.

Education on SPL. Some case studies have been prepared to be used in the context of learning and for classroom use. The Arcade Game Maker pedagogical SPL [START_REF] Mcgregor | Ten years of the arcade game maker pedagogical product line[END_REF] concisely explains the scenario of a fictitious company adopting an SPL approach. Other case studies, such as the Graph Product Line (GPL) [START_REF] Roberto | A Standard Problem for Evaluating Product-Line Methodologies[END_REF] or the Expressions Product Lines (EPL) [START_REF] Roberto | Evaluating Support for Features in Advanced Modularization Technologies[END_REF] have been presented as SPL examples where understanding the domain is not complex. However, according to a survey and the summaries from the SPL Teaching (SPLTea) series of workshops by Acher et al. [START_REF] Acher | Teaching Software Product Lines: A Snapshot of Current Practices and Challenges[END_REF], there is still need of suitable case studies for educational purposes. The Robocode case study is proposed as a candidate to reduce the lack of well-documented real-world examples and case studies suitable for teaching in the context of reverse engineering and adoption. As commented is Section 1, this context is not as frequently covered as other topics in SPL pedagogical material [START_REF] Acher | Teaching Software Product Lines: A Snapshot of Current Practices and Challenges[END_REF].

CONCLUSION

We presented the Robocode case study as a way to analyse an endto-end extractive process for SPL adoption. The domain analysis resulted in a feature model of considerable size and in a high diversity of feature implementations that were (1) mined from existing assets and (2) re-engineered to match the SPL architecture. We provided time measures to show the distribution of time dedicated to different activities. Our discussions of this academic-scale extraction of an SPL can provide insights for real industrial settings. The case study is also suitable for educational purposes as it enables to gain knowledge and hands-on practice in SPLs through a motivating project.

As further work, we aim to tackle some of the research directions mentioned in Section 7. Also, we plan to get feedback about the domain analysis and implementation from the Robocode community. The Robocode SPL can be used as a reference point to understand, discuss and evolve their domain variability. Also, we hope to attract the attention of the SPL community as the Robocode SPL can be used for very diverse purposes.

Figure 1 :

 1 Figure 1: Battle of two bots. Screenshot from the RoboWiki

Figure 2 :

 2 Figure 2: Anatomy of a bot. Illustration from the RoboWiki

  used the Module framework (version 1.0.0) which was created and documented by the first author. The UML Class diagram of Figure 3 presents an excerpt of the framework. The abstract class Module extends TeamRobot from the official Robocode API, so a Java class implementing Module can be used in Robocode as a new bot.

Figure 3 :

 3 Figure 3: Excerpt of a UML Class diagram illustrating the Module framework, its relation with the Robocode API, and an example of a bot implementing a Module bot

Figure 4 :

 4 Figure 4: An excerpt of the extracted feature model for Robocode SPL

  . enemy != null ) { 11 double absoluteBearing = bot . getHeadingRadians () + bot . enemy . bearingRadians ; bot . setTurnGunRightRadians ( robocode . util . Utils . normalRelativeAngle ( absoluteBearing -bot . getGunHeadingRadians () ) ) ;

2 3 5 }

 25 public class ModuleBot extends Module { 4 Targeting selectedTargeting = new HeadOnTargeting ( this ) ; Listing 1: The implementation of feature HeadOnTargeting the HeadOnTargeting feature is included in a bot variant. Listing 1 shows the complete source code of the HeadOnTargeting feature.

Figure 5 :Listing 2 :

 52 Figure 5: HeadOnTargeting • Module. The composition of the feature HeadOnTargeting in the Module mandatory feature. (The notation is adapted from Apel et al. [3])

Figure 6 :Listing 3 :

 63 Figure 6: #LoC for all features, and according to the six main compound features

Figure 7 :

 7 Figure 7: Reflection on the gained knowledge: Feature Modeling (FM), SPL, Implementing Feature-Based systems (Impl. FB), FeatureIDE, Robocode domain, and Java

Figure 8 :

 8 Figure 8: Feature implementation process

Figure 10 :

 10 Figure 10: The average distribution of time in different activities by each participant, in percentage (%)

Figure 11 :

 11 Figure 11: The time to implement a feature (easy, medium, difficult), and in average for all of them

  we can

		} else if ( bot . enemy . distance > 300 && bot . enemy .
		distance <= 500) {
		segmentsValues . add ( " far " ) ;
	13	} else {
	14	segmentsValues . add ( " very far " ) ;
	15	}
	16	}
	17	original () ;
	18	}
	19 }

Robocode: http://robocode.sourceforge.net

RoboWiki: http://www.robowiki.net

Robocode archive: http://robocode-archive.strangeautomata.com/robots/

http://robowiki.net/wiki/Category:Bots

http://robowiki.net/wiki/XanderFramework

https://github.com/jabiercoding/ModuleRobocodeFramework

ACKNOWLEDGMENTS

This work was partially supported by the ITEA3 15010 REVaMP 2 project: FUI the Île-de-France region and BPI in France. Special thanks to the students Aram, Hacene, Mariène, Morvan, Sara and Wissem for their active involvement in this work.

SPLC '18, September 10-14, 2018, Gothenburg, Sweden