Martina Capuzzo
email: capuzzom@dei.unipd.it

Davide Magrin
email: magrinda@dei.unipd.it

Andrea Zanella
email: zanella@dei.unipd.it

Confirmed Traffic in LoRaWAN: Pitfalls and Countermeasures

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

Low Power Wide Area Networks (LPWANs) are gaining momentum as a readily available solution to the demand for Internet of Things (IoT) connectivity, mainly thanks to the low deployment costs and the current absence of cellular-based competitors for low-demand IoT use cases [START_REF] Centenaro | Long-range communications in unlicensed bands: The rising stars in the IoT and smart city scenarios[END_REF]. Backed by the LoRa Alliance, 1 the LoRaWAN standard is an example of such networks which has lately been experiencing a consistent growth, fueled by the good performance of the technology, the ease of deployment and management [START_REF] Vangelista | Long-range IoT technologies: the dawn of LoRa TM[END_REF], and the availability of publicly accessible network servers, like those provided by The Things Network (TTN) [START_REF]The Things Network[END_REF].

One of the most important characteristics that distinguishes Lo-RaWAN networks from competitors like Sigfox is the availability of confirmed data messages. 2 This network feature has not been investigated in the literature yet, except for a few very recent works. In [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF], the authors propose an interesting analytical model of the LoRaWAN system, accounting also for confirmed traffic, while simulative studies are presented in [START_REF] Pop | Does Bidirectional Traffic Do More Harm Than Good in LoRaWAN Based LPWA Networks?[END_REF][START_REF] Van Den Abeele | Scalability Analysis of Large-Scale LoRaWAN Networks in ns-3[END_REF]. All these works, however, consider only simple scenarios and overlook some details of the LoRa system that, based on our study, turn out to have a significant impact on the actual system performance.

In this work, we provide some insights into the behavior of LoRaWAN networks in presence of confirmed traffic, in different scenarios and under realistic traffic patterns and channel propagation models. By setting up a simulator that accounts for some realistic features of the LoRaWAN devices, we are able to estimate the achievable performance for different network sizes and usage of confirmed traffic, and thus provide guidelines for the design of future deployments. The development of such a realistic simulator allowed us to gain insights into the system behavior and spot some design issues, for which we propose some feasible solutions. Our findings show that the use of confirmed traffic may severely affect the capacity of the system and the reliability of unconfirmed uplink traffic, mainly because of the duty-cycle limitations at the Gateway (GW), the uplink/downlink packet collisions, and other practical aspects that will be discussed in detail in the following, together with some possible workarounds and countermeasures. The rest of the paper is structured as follows: in Section II we give an overview of the LoRa and LoRaWAN technologies, and we introduce the ns-3 module that was used throughout this work. Section III describes a simulation campaign aimed at estimating the performance of a LoRaWAN cell in presence of downlink (DL) traffic and in a realistic urban scenario, while in Section IV we give some insights about possible pitfalls in the deployment and parameter settings of LoRaWAN networks. In order to better appreciate the impact of some specific protocol aspects on the system performance, in Section V we compare the network performance predicted by the model in [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF] with those given by our simulator under different settings of the system parameters. Finally, Section VI draws the conclusions of this work.

II. TECHNOLOGY OVERVIEW

This section discusses the most relevant aspects of the LoRa modulation, the LoRaWAN standard and the enhanced lorawan ns-3 module that we used in this study.

A. The LoRa modulation

Long Range (LoRa) is a Chirp Spread Spectrum (CSS) modulation technology patented by Semtech. The modulation is designed to wirelessly transmit information at low data rates and long distances (typically up to 2 km in urban scenarios and 10 km in rural areas). The PHY layer supports different transmission bitrates, which are obtained by changing the Spreading Factor (SF) parameter that takes integer values from 7 to 12. Higher SFs correspond to lower bitrates and longer ranges, thanks to a lower required sensitivity at the receiver. Table I provides a summary of the data rate, sensitivity and typical on-air time for the transmission of a packet of 25 bytes for each available SF. The sensitivity values refer to the GW chip SX1301, manufactured by Semtech, while the transmission time considers the explicit header mode, a code rate equal to 2 and the default values for the remaining parameters.

A major feature of the SFs is that they are almost orthogonal: overlapping transmissions can still be demodulated correctly, provided that their relative powers are sufficiently spread apart, as shown in [START_REF] Goursaud | Dedicated networks for IoT: PHY/MAC state of the art and challenges[END_REF].

B. The LoRaWAN standard

The LoRaWAN standard [START_REF] Alliance | LoRaWAN TM 1.1 Specification[END_REF] is defined by the LoRa Alliance organization. The standard describes three kinds of devices in a LoRaWAN network:

• the Network Server (NS), which is the central network controller; • the End Devices (EDs), which are basic nodes, typically consisting in sensors or actuators, that can transmit data through the LoRa modulation; • the GWs, which receive the radio packets transmitted by the EDs and forward them through a reliable connection to the NS and vice-versa, i.e., receive the NS's acknowledgements (ACK) or MAC commands and forward them to the intended EDs through the LoRa wireless interface. In this study, we consider EDs of Class A, which are by far the most common today. These devices access the shared wireless channel for uplink (UL) transmissions (towards the GW) following an ALOHA scheme. Reception of DL packets is only possible during the two consecutive receive windows that are opened immediately after each UL transmission. We consider networks operating in the 868 MHz band, for which the standard defines four sub-channels with carriers at 868.1 MHz, 868.3 MHz, 868.5 MHz, which can be used for both UL and DL transmissions, and a channel at 869.525 MHz that is reserved for DL-only transmissions. The 868 MHz unlicensed frequency band is regulated through duty cycle limitations, such that the devices can only transmit for a given fraction of the time, with a limited maximum power, as reported in Table II. Note that the duty cycle restrictions are shared by all the three UL frequencies, since they are located in the same sub-band. Therefore, if a transmission is performed in one of these frequencies, the waiting time due to the duty cycle must be respected also on the other two. Instead, the DL channel at 869.525 MHz resides in a different sub-band that allows for a duty cycle of 10% and a larger transmission power.

C. Simulation software

The ns-3 simulator is a popular discrete-event network simulator written in C++. The ns-3 module used in this analysis3 is based on that described in [START_REF] Magrin | Performance evaluation of LoRa networks in a smart city scenario[END_REF], which we extended to add support for downlink traffic. The rest of this section highlights the main features of the lorawan module, and discusses its differences with respect to other LoRaWAN simulators such as those used in [START_REF] Pop | Does Bidirectional Traffic Do More Harm Than Good in LoRaWAN Based LPWA Networks?[END_REF][START_REF] Van Den Abeele | Scalability Analysis of Large-Scale LoRaWAN Networks in ns-3[END_REF]. transmissions, instead, packets are retransmitted by the EDs until successfully acknowledged by the GW, or the maximum number m of allowed transmission attempts is reached. Therefore, the incorrect reception of ACK packets may trigger the retransmission of packets that had actually been successfully delivered to the GW. We consider the traffic source model described in the Mobile Autonomous Reporting (MAR) periodic reports [START_REF] Gpp | Cellular system support for ultra-low complexity and low throughput Internet of Things (CIoT)[END_REF].

In our simulations, we have considered different combinations of the following parameters:

• N : number of EDs in the network;

• m: maximum number of allowed packet transmissions;4 • c: percentage of EDs using confirmed traffic. The exact values used in the different cases are reported in Table III, with some other details on the employed simulation methodology.

The scenario with only unconfirmed traffic (c = 0%) provides the baseline for our performance analysis.

Fig. 2 contains the contour lines of the packet success rate when varying N and c, while the three plots are obtained for different values of m. In these plots, we mark unconfirmed packets as successful when they are correctly received by the GW, while confirmed packets are considered successful when an ACK is received by the ED.

Fig. 2a, obtained with m = 2 (i.e., allowing a single retransmission), shows that the packet success rate decreases quickly when the majority of nodes generate confirmed traffic. It is indeed interesting to observe that, for a given N , the performance degrades quite rapidly by increasing c, i.e., the percentage of nodes that require confirmedtraffic, while the loss is smoother when increasing N for a fixed c. For example, for N = 1000 and c = 20%, the packet delivery ratio is slightly less than 0.94. Doubling N for the same c, the packet delivery ratio drops to slightly less than 0.93. Instead, doubling c for the same N the performance index becomes lower than 0.91.

From Fig. 2b and Fig. 2c we note that by increasing the maximum number of allowed transmission attempts the packet delivery ratio progressively improves. This means that, even if retransmissions increase the network load, the overall offered traffic is still small enough for the GW to process all the packet arrivals and the corresponding replies. For example, we can see that in a network of 500 devices, the baseline case with only unconfirmed traffic (c = 0%) achieves a packet success rate of 0.95, which is basically maintained as c increases up to 10% with m = 2, up to 40% when m = 4, and up to 70% when m = 8. Therefore, in this scenario, packet losses are mainly due to repeated collisions of UL packets with either UL or DL (ACK) transmissions, so that increasing the number of allowed attempts enhances the success probability.

This holds true for scenarios in which the network is not very crowded. However, for a large number of nodes, allowing a greater number of transmission attempts can become detrimental. For example, considering the scenario with N = 2000 devices and c = 20%, we can see that the packet delivery ratio is indeed the same for m = 4 and m = 8, which means that the benefit of increasing the transmission persistence is actually balanced by a higher collision probability due to the increased network traffic.

IV. DISCUSSION

The results presented in the previous section have revealed some peculiar network behavior in the presence of confirmed traffic that is worth further investigation. In order to better understand the causes 0 .9 0 . 9 0 . 9 0 .9 1 0 . 9 1 0 . 9 1 0 .9 2 0 . 9 2 0 . 9 2 0 .9 3 0 . 9 3 0 . 9 3 0. 94 0 . 9 4 0 . 9 4 0.94 0.9 5 0 .9 5 0 . of such a behavior, in this section we focus on more specific and homogeneous scenarios. We hence consider only the log-distance path loss model (neglecting the shadowing component in the signal propagation), and we assume all devices to generate confirmed traffic (c = 100%), with a maximum number of transmission attempts equal to m = 8, and a traffic rate per ED of 1 packet every 30 minutes.

A. Factors causing packet losses

We start our discussion from the factors that determine packet losses, namely channel impairments (received signal power below the required sensitivity), interference (packet collisions), and receiver saturation (no available receive path at the GW).

In Fig. 3 we report the packet loss probability due to the three aforementioned factors, and the overall aggregate value, when increasing the number of EDs in the cell. We can observe that, with a static channel and suitably selected transmission rates, the packet losses due to channel impairments are negligible. Instead, it is interesting to observe that the interference is initially the dominant cause of packet losses, but after a certain traffic load the main limiting factor becomes the saturation of the receive paths at the GW. Note that, when all the receive paths are engaged, the receiver cannot lock any other signal (collided or not), which explains the smooth decrease of the loss probability due to interference for high traffic loads.

One possible way to mitigate the problem of the receiver saturation is to increase the number of parallel receive paths at the GW. However, such receive paths need to be coordinated in order to avoid that an incoming signal is locked onto multiple paths. Therefore, the simple co-location of multiple out-of-the-shelf receiver chips on the same GW or of multiple GWs on the same geographical position, would not bring any significant advantage in this respect. Instead, a uniform deployment of multiple GWs in the coverage area may reduce the distance to the EDs, thus enabling the use of higher bitrates and, hence, a contraction of the packet transmission times that, in turn, will yield a reduction of the collision probability and of the engagement time of the receive paths. More generally, a possible way to reduce the packet loss probability is to re-balance the SF distribution in the network, in order to maximize the probability of parallel reception.

The bar plot in Fig. 4 shows the percentage of uplink packets that are dropped because of channel impairments, receiver saturation, and interference, and the remaining fraction of correctly received packets, when varying the number m of allowed transmission attempts, in a congested scenario (N = 5000 EDs). The two right-most bars, furthermore, report the results obtained when the Adaptive Data Rate (ADR) algorithm recommended in the LoRaWAN specifications is enabled, and will be discussed later on.

It is apparent that, in a congested scenario, larger values of m would just increase the number of retransmissions, further exacerbating the channel contention without bringing any performance improvement, but rather worsening the packet loss rate. Conversely, for light traffic conditions, larger value of m may improve the packet delivery ratio. Therefore, in order to effectively support confirmed traffic, it would be important to devise mechanisms that can adapt this parameter based on the traffic load.

B. Side effects of ADR

We implemented the ADR mechanism as suggested in [START_REF] Alliance | LoRaWAN TM 1.0.2 Specification[END_REF], where EDs automatically increment by one their SF (basically halving the transmission rate) after two consecutive transmission failures. The underlying assumption is that failures are due to channel impairments, so that reducing the transmission rate and, consequently, increasing the coverage distance, may get the device in range of the GW. Clearly, this mechanism fails when packet losses are due to interference or receiver saturation, as shown by the results in the two right-most bars of Fig. 4. In this case, a reduction of the transmission rate would further exacerbate the congestion, yielding an increase of the packet loss rate. In addition, the ADR mechanism tends to increase the number of users that adopt the same (low) transmission rates, thus losing the advantage of orthogonality between different SFs. Interestingly, even if a NS could observe this pathological behavior of the ADR, it would not be able to correct it because the transmission of MAC commands to an ED is subject to the successful reception of an UL transmission from the same device, which may be difficult with high packet loss rate.

Once again, the countermeasure to this problem may consist in the development of an ADR algorithm that adapts its behavior according to the traffic load of the network. Furthermore, to avoid the risk that an occasional upsurge of traffic triggers an avalanche effect that bring all EDs to transmit at the lowest rate, it may be clever to adopt an exponential backoff mechanism that progressively increases the time between consecutive transmission attempts, temporarily reducing the offered traffic rate. This mechanism, furthermore, may also be beneficial to alleviate another problem, which is discussed in the next subsection.

C. Random backoff intervals

When confirmed traffic is employed, EDs must wait ACK TIMEOUT seconds before performing a retransmission, as defined in the LoRaWAN standard [START_REF] Alliance | LoRaWAN TM 1.1 Specification[END_REF]. The value of ACK TIMEOUT is a random delay, from one to three seconds, which is intended to prevent further collisions between the same packets [START_REF] Alliance | LoRaWAN TM 1.1 Regional Parameters[END_REF]. However, our simulation results did not show any clear benefit of such a random delay. The reason is that collisions usually occur among nodes that use the same high SF (because of lack of orthogonality and longer transmission times). In this case, the transmission time of a packet may easily be comparable to the backoff delay. Therefore, the retransmissions will overlap again in time, likely causing a new collision. For example, the on-air time of a packet with 51 bytes of payload, transmitted with SF 12, code rate 4, and explicit header mode, turns out to be equal to 3.15 s, which is larger than the whole time interval in which the delay is picked. Therefore, it is likely that the packets will collide again if the EDs select the same transmission frequency to retransmit their packets.

This problem can be avoided by increasing the backoff time intervals for larger SFs or longer transmissions. Clearly, the drawback of such a strategy is an increase of the transmission latency that, however, is usually not much of a concern for LPWA-based services.

D. EDs locking on uplink packets

In LoRaWAN, direct ED to ED transmissions are not allowed. Nonetheless, in our simulations we have observed that, when the receive window of an ED is open, the device can actually lock onto an UL message sent by another ED. This incorrect behavior has also been confirmed experimentally, using real LoRa devices.

The reason is that both UL and DL transmissions use the same preamble, which consists of a variable number of up-chirp modulation symbols, so that a receiver cannot discriminate the source of the transmission until the packet is completely received and inspected.

Additionally, an ED can also lock on a DL packet intended for another receiver. The reception of undesired transmissions represents a waste of energy and time.

While locking on other DL messages can not be easily avoided, the useless reception of UL messages may be avoided by using different preambles for UL and DL transmissions, so as to allow the receiver to completely avoid the reception of UL messages and return to sleep mode for the remaining duration of the receive window.

E. Sensitivities asymmetry

As shown in Table IV, the sensitivity requirements for EDs are more relaxed than those for the GW, mainly to reduce the manufacturing cost. The sensitivity gap between ED and GW yields an asymmetric coverage range between UL and DL transmissions, so that it may happen that an ED can reach the GW with a certain SF, while the same SF is not sufficient to correctly deliver the return packet to the ED because of its worse sensitivity. While such an asymmetry is not a problem when all nodes send non-confirmed UL traffic, it instead may become an issue in case of confirmed traffic, preventing some devices from receiving in the first receive window (in which the NS uses the same SF and carrier frequency of the UL message) and forcing the systematic opening of the second receive window.

One possible way to alleviate this problem is to exploit the LinkCheck MAC commands that can be used by an ED to request information about its received power to the NS. Using this information, the ED can avoid opening the first receive window altogether when the received power reported by the GW would be lower than the ED sensitivity. Alternatively, the NS can use the command RX1DRoffset to inform the ED that the GW will reply on the first receive window using a lower rate than that used in UL.

F. Sub-band prioritization

One final consideration regards the current specification of the receive window allocations. The standard prescribes the first receive window (RX1) to be opened on the same channel that was used in the UL, while the second window is opened in the dedicated DL channel, centered at 869.525 MHz. However, a better strategy may consist in reversing this setup, i.e., opening the first receive window on the channel at 869.525 MHz and the second receive opportunity in the same channel used for UL transmission. The motivations behind this claim are the following.

• Availability: the duty cycle restriction is 1% for the shared UL/DL channels, while it is relaxed to 10% for the dedicated DL channel, thus making its capacity larger than the aggregate (DL) capacity of the other channels. Therefore, opening the first receive window on the DL-only channel will decrease the probability that an ACK transmission gets delayed to the second window because of the duty cycle restriction on the first window, thus reducing the energy wasted by the ED in idle reception.

• Interference: transmissions on the DL-only channel do not interfere with UL transmissions, but only with DL packets sent by the GWs of other cells. On the contrary, DL transmissions in any other channel can collide with UL transmissions in the same cell, or both UL and DL transmissions in other cells, increasing the packet loss probability and, in turn, the congestion. • Settings: typically, ACK transmitted on the second receive window (i.e., on the DL-only channel) are modulated with SF 12, even when the intended receiver can actually decode transmissions with much lower SF values. This greatly increases both the duty cycle consumption and the energy expenditure of the EDs, which are required to remain in reception for a longer period. Additionally, transmissions with SF 12 can be received at further distances and, hence, can engage receivers of other cells, wasting their time and energy. Conversely, by moving the first window on the DL-only channel, the ACK will be transmitted with the same SF used for the UL transmission (or, possibly, the immediately lower SF, to counteract channel asymmetries), thus increasing the system capacity.

V. MODELING ISSUES

In order to show how the duty cycle restrictions at the GW affect the system performance in presence of confirmed traffic, we propose a comparison between the results of our simulator and the model presented in [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF]. For these comparisons, we consider a confirmed packet to be successfully received when the ACK is received by the device, as done in [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF].

Fig. 5 illustrates the success probability for different values of the network load, as estimated by our simulator and by [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF]. It is apparent that the theoretical model overestimates the network performance. The reasons of this mismatch are the following:

• The model in [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF] assumes perfect orthogonality among different SFs, while in the simulator we consider a frame to be successfully delivered if the equalized interfering power is below the channel rejection parameter defined in [START_REF] Goursaud | Dedicated networks for IoT: PHY/MAC state of the art and challenges[END_REF]. • The model assumes that "packets transmitted in different channels and at different rates do not collide." Considering the three default channels in EU region and the six possible SFs, the model assumes that the GW is capable of receiving up to 18 packets simultaneously. No other assumptions or considerations are done about packets arriving at the GW. In the simulation, instead, we consider the 8 receive paths of the LoRa GW's chip. • The model in [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF] always considers the transmission of two ACKs for each data packet received at the GW: one in the first receive window (RX1) and one in second receive window (RX2). We think that even if this choice increments the probability that one of the two ACKs is correctly received by the ED, the second transmission could be useless if the first one is successful, and would only "consume" a transmission possibility in RX2. As the policy that should be adopted is not explicitly indicated in the LoRaWAN specification [START_REF] Alliance | LoRaWAN TM 1.1 Specification[END_REF], we chose to make the GW transmit only once: either in RX1 or in RX2 according to the duty cycle restrictions, giving priority to RX1. • The authors of [START_REF] Bankov | Mathematical model of LoRaWAN channel access with capture effect[END_REF] consider that "the GW cancels ACK transmission if it is receiving a data frame." Following the indications in [13], we instead assume that a DL transmission preempts any ongoing UL reception at the GW. Therefore, the transmission of ACKs is prioritized over any other operation of the GW. can be returned is limited by the duty cycle constraint. If the delay exceeds the total duration of the receive windows of the ED, the ACK transmission is aborted and the UL transmission is considered failed, causing packet retransmissions. As shown in Fig. 5, the packet delivery ratio increases significantly when the GW's duty cycle restriction is disabled, though it still remains lower than that predicted by the theoretical model. Some possible solutions to the issues caused by Duty Cycle (DC) restrictions are listed below.

1) GWs co-location: leveraging the fact that downlink transmissions are scheduled by a centralized controller (i.e., the NS), the presence of multiple GWs at the same location can allow the NS to balance the time on air among the co-located GWs, thus better exploiting the duty cycle allocated to each GW. 2) Listen before talk: since the regulation does not enforce duty cycle on devices implementing a listen-before-talk mechanism, it is possible to give GW chips this capability, thus allowing them to transmit as often as needed in downlink channels.

VI. CONCLUSIONS

In this work we presented a simulation analysis of a LoRaWAN network.

We showed that the performance of a single LoRaWAN cell can significantly degrade when the fraction of nodes that require confirmed traffic grows excessively. Furthermore, our results showed that, to reach the best performance, it is necessary to carefully choose the maximum number of transmission attempts for confirmed packets, based on the node density and traffic load.

After these initial results, we discussed some insights into the system behavior that should be considered in the network setup, such as the potentially harmful effect of the ADR mechanisms at the device-side in the presence of confirmed traffic, the ill-designed random backoff intervals, the risk of receivers locking on undesired uplink transmissions, and the impact of the asymmetry in the sensitivities of the GW and ED chips. Furthermore, we discussed possible approaches to alleviate some of the revealed issues, e.g., introducing adaptation strategies for some system parameters or changing the priority of the sub-bands used for the receiving windows.

Finally, we showed how the introduction of the features of real LoRa chips, such as the limitation of the GW's receive paths and the duty cycle restriction, have a profound impact on the network performance, and ought to be thoughtfully considered both in simulation and model design.

As possible developments of this work, we envisage simulations with multiple GWs, in which the suggested solutions are tested realistically via the MAC commands, which are currently defined by the standard. Moreover, the simulator can be used to verify the effectiveness of different ADR schemes in realistic scenarios, where the distribution of SFs is heavily impacted by the presence of buildings. Finally, a mathematical model considering confirmed traffic and realistic features could be formulated to predict LoRaWAN network performance.

Fig. 1 :

 1 Fig. 1: LoRaWAN network topology.

9 5

 9 Number of devices % of devices using confirmed traffic (b) m = 4.

  Number of devices % of devices using confirmed traffic (c) m = 8.

Fig. 2 :

 2 Fig. 2: Packet success rate for different values of m.

Fig. 3 :

 3 Fig. 3: Causes of packet losses with confirmed traffic.

Fig. 4 :

 4 Fig. 4: Packet loss probability when increasing the number m of transmission attempts and enabling ADR, with N = 5000 EDs.

Fig. 5 :

 5 Fig. 5: Comparison of lorawan simulator with analytical model taken from [4].

TABLE I :

 I Main transmission features for the different SFs.

	SF Data rate [kbit/s] Sensitivity [dBm] Transmission time [s]
	7	5.470	-130.0	0.074
	8	3.125	-132.5	0.136
	9	1.760	-135.0	0.247
	10	0.980	-137.5	0.493
	11	0.440	-140.0	0.888
	12	0.250	-142.5	1.777

TABLE II :

 II LoRaWAN default channels and duty cycle limitations.

	Frequency (MHz) Direction Duty cycle Power limit (dBm)
	868.1	DL, UL	1%	14
	868.3	DL, UL	1%	14
	868.5	DL, UL	1%	14
	869.525	DL	10%	27

TABLE III :

 III Simulation parameters

	(a) Network parameters
	Variable		Interval
	N : Number of EDs	100 -2100
	m: Maximum number of transmissions	1, 2, 4, 8
	c: Percentage of devices using confirmed traffic 0 -100 %
	(b) Path loss model
	Component Variable	Value
	Path loss	path loss model	as in [9]
	Shadowing	de-correlation distance	110 m
		variance	6 dB
	Buildings	wall losses	as in [10]
	(c) Traffic model
	Packet Interarrival time (λ)	Percentage of devices
	1 day		40 %
	2 hours		40 %
	1 hour		15 %
	30 minutes		5 %

TABLE IV :

 IV Sensitivity comparison

	SF GW Sensitivity (dBm) ED Sensitivity (dBm)
	7	-130.0	-124.0
	8	-132.5	-127.0
	9	-135.0	-130.0
	10	-137.5	-133.0
	11	-140.0	-135.0
	12	-142.5	-137.0

•

  The last feature in which our simulator differs from the model is the presence of the duty cycle at the GW. Even if the GW can receive up to 8 packets simultaneously, the rate at which ACKs

		1
		0.8
	Packet success ratio	0.4 0.6
		0.2	Simulator, Duty Cycle on
			Simulator, Duty Cycle off
			Model
		10 -2 0	10 -1	10 0	10 1
			Network packet arrival rate

https://www.lora-alliance.org/

Sigfox plans only support a limited number of acknowledgments per day.

Available at https://github.com/signetlabdei/lorawanThe lorawan module consists in a collection of C++ classes, each representing a component of the network. Additionally, these classes leverage "helper" objects to keep track of interference, correctly manage the state of the duty cycle, update the list of available channels, compute the path loss between two locations and perform other similar tasks. The interference between multiple LoRa packets is modeled according to[START_REF] Goursaud | Dedicated networks for IoT: PHY/MAC state of the art and challenges[END_REF], in order to account for the quasiorthogonality of different SFs. The amount of overlap between two packets is also taken into account in the interference model, which is described in detail in[START_REF] Magrin | Performance evaluation of LoRa networks in a smart city scenario[END_REF].The Gateway PHY layer module class, which simulates the GW behavior, features a realistic modeling of the parallel decoding capabilities available in Semtech's SX1301 chip (which is currently employed in GWs). More specifically, the module considers that commercial GWs feature 8 parallel receive paths, which can be singularly allocated to the different channel frequencies. A receive path can lock on one signal at a time, irrespective of its SF, provided that it is sent on the associated frequency band. For example, assuming that the number of receive paths allocated to the three uplink frequency bands are three, three, and two, respectively, then the GW may be able to simultaneously decode up to three signals sent on the first frequency band, three on the second frequency band, and two on the last frequency band, irrespective of their SF. However, the SFs of the received signals do have an impact on the probability of successful decoding, as discussed in[START_REF] Goursaud | Dedicated networks for IoT: PHY/MAC state of the art and challenges[END_REF]. These features are correctly modeled in the lorawan ns-3 module described in[START_REF] Magrin | Performance evaluation of LoRa networks in a smart city scenario[END_REF]. Incidentally, we observe that the simulators used in[START_REF] Pop | Does Bidirectional Traffic Do More Harm Than Good in LoRaWAN Based LPWA Networks?[END_REF][START_REF] Van Den Abeele | Scalability Analysis of Large-Scale LoRaWAN Networks in ns-3[END_REF] model the GW reception capabilities in a different way, considering one receiver for each SF on each uplink frequency band, for a total of 18 parallel receivers, each one capable of locking on one signal transmitted on a specific frequency with a specific SF. In this way, however, the GW will not be able to receive two or more signals sent with the same SF on the same frequency, irrespective of their relative received power, thus being more conservative than a real GW. On the contrary, the simulated GW may be able to successfully decode up to 18 signals, provided that the SFs of the signals in the same band are different, while a practical GW can only decode up to 8 signals.With respect to the previous version of the lorawan module, in this work we expanded the LoraMac classes to handle confirmed traffic. MAC layers of EDs which use confirmed uplink packets retransmit the packet until an Acknowledgment (ACK) is received from the GW, or a (configurable) maximum number of attempts is reached. We remark that retransmissions are also subject to duty cycle limitations, as any other transmission.III. SIMULATION RESULTSIn this section we report the results of our simulation analysis of a simple LoRaWAN cell in a realistic urban scenario, which reveals how the presence of confirmed traffic can affect the performance of the system.For this analysis, we consider an elementary LoRAWAN cell, consisting of a single GW, surrounded by N EDs uniformly distributed in a circular area of radius 1200 m. The EDs are configured to use the highest bitrate that guarantee good reception probabilities, i.e., such that the mean received power at the GW is above the sensitivity associated to that rate (see Tab. I). Besides the log distance path loss model, we add spatially correlated shadowing and losses due to the presence of buildings, as described in[START_REF] Magrin | Performance evaluation of LoRa networks in a smart city scenario[END_REF].We consider both confirmed and unconfirmed traffic. In the case of unconfirmed traffic, the EDs will transmit each packet only once, irrespective of its correct reception by the GW. For confirmed

Note that, for m = 1, a packet can be transmitted only once, but in case of confirmed traffic, the GW is required to send back an ACK.

ACKNOWLEDGMENT

This work was partially supported by the project POR FESR 2014-2020 "Sistema Domotico IoT Integrato ad Elevata Sicurezza Informatica per Smart Buildings".


Fabrice Jumel

Jacques Saraydaryan

Raphael Leber

Laëtitia Matignon

Eric Lombardi

Christian Wolf

Olivier Simonin

Laetitia Matignon

Context Aware Robot Architecture, Application to the RoboCup@Home Challenge

Keywords:

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Most of robotic architectures focus on a specific ability: autonomous navigation, grasping, human-robot interaction, etc. Today, more and more applications and professional or public contexts require a robot to be able to perform several tasks with a high level of abstraction (help a human, execute a human order, serve humans). While AI 1 methods and technologies progress, expectations about service robotics are growing. This is particularly true in complex human-populated environments [START_REF] Iocchi | COACHES Cooperative Autonomous Robots in Complex and Human Populated Environments[END_REF]. In this context we aim to define software architectures that orchestrate and combine different high level abilities and their sub-functions.

Each high-level ability is generally built on sub-functions, that we call also low level tasks or controls. We can mention for instance path-planning computation, SLAM 2 function, object and human detection, or speech output. In this paper we present an architecture which is able to perform high level tasks that require several skills: navigation in dynamic -human-populated -environments, object detection, people detection and recognition, speech recognition, and task planning. Interacting with humans and answering to their orders is a very large and challenging problem. In this paper, as a first step, we limit our study to the high-level tasks proposed in the RoboCup@Home competition, by focusing on social navigation. These tasks are presented in the next section.

Our approach distinguishes two main levels. The first one is the "decision" level which selects the main high level task to do, and potentially in parallel.

The second level is defined as a set of general tasks which are required in several high level tasks. We organize this level in a limited set of generic tasks, which are themselves built on sub-functions that can be shared.

The paper is organized as follows. Section 2 presents the context of the RoboCup@Home challenge and its relative tasks. We also discuss existing works on robot software architectures. Then in Section 3 we give an overview of the proposed architecture, before to detail in Section 4 how the General Behavior Manager orchestrates the execution and selection of tasks. Section 5 details the navigation strategy selection and Section 6 gives on overview of methodologies used for human detection and interaction. Section 7 illustrates in details the approach on a complex scenario, then Section 8 presents first results in the RoboCup@Home challenge. Finally Section 9 concludes the paper.

Service robots and software architectures

We aim at developping software architectures and AI modules allowing mobile/humanoid robots to navigate in human-populated environments and to carry out high-level tasks. In this context, we focus on tasks proposed in the RoboCup@Home challenge3 , which requires to develop and to connect different modules providing image analysis, decision making and learning, human-robot interaction, and autonomous navigation. These modules must be orchestrated in a whole architecture.

The scenarios driving our research concern mainly tour guide robots [START_REF] Burgard | The interactive museum tour-guide robot[END_REF] and waiter robots [START_REF] Saraydaryan | Robots delivering services to moving people : Individual vs. group patrolling strategies[END_REF] which are variants of tasks proposed in the Robucup@Home competition. For example, the cocktail party challenge of the RoboCup@Home [START_REF] Van Beek | Robocup@home 2018: Rules and regulations[END_REF] consists for a robot to take orders during a private party in a flat. In order to score, the robot has to find the room, ask guests about orders and give them to the bartender located in another room. In order to fulfill this scenario, navigation skill and human-robot interaction skill (principally speech interaction) are required. Other tasks are aimed, that are optional part of the challenge:

-Navigate inside the cocktail party room to find calling guests to take order -Find a more discreet guest to take order -Find a missing order (drink) on a table or equivalent (object recognition) -Find back the guest concerned by the missing order (person recognition) -Be able to describe the guests to the bartender, so that it can correctly distribute the orders in the cocktail party room (person description).

A major issue in the design of a robot architecture is to allow the robot to fulfill high level objectives while dealing with a complex and dynamic environment. More precisely, the robot has to simultaneously sense the environment, navigate and detect people to interact, and so on. This requires to define dedicated architectures able to orchestrate several tasks, mostly in parallel. Such an issue requires to build behaviors over a middleware embedded in the robot. In Calisi et al. [START_REF] Calisi | Design choices for modular and flexible robotic software development: the openrdk viewpoint[END_REF] authors showed that a lot of frameworks have been proposed for robotics software development. More recently, Chitic et al. [START_REF] Chitic | Are middlewares ready for multi-robots systems[END_REF] have underlined that ROS has become a classic middleware to support such a development, with a rich library of functions. Other middlewares, as [START_REF] Lutkebohle | Generic middleware support for coordinating robot software components: The taskstate-pattern[END_REF], focus on tasks description language and life cycles. To build a generic architecture, we have chosen ROS as middleware: we inherit the publish-subscribe way of communication, as well as services and actions, and the manager of concurrent processes (or nodes). Our objective is to propose a generic architecture, able to deal with high level tasks, ie. not focusing on a specific task, scenario, or robot. Concerning software architectures dedicated to humanoids, there are, up to now, few generic solutions to manage service tasks. We can mention the work of Natale et al. [START_REF] Natale | The icub software architecture: Evolution and lessons learned[END_REF] dedicated to the iCub, where the architecture is turned towards code generation, motor control, and interfaces.

3 Overview of the LyonTech architecture In this section we present the embedded AI software architecture of LyonTech's team, aiming at managing both high level decisions and low level tasks of Pepper. Figure 1 gives a general view of the proposal. It contains modules which have been developed in different research work of the consortium, completed by off-the-shelf modules which tackle standard tasks, as well as engineering bricks interconnecting these modules.

On top, the General Behavior Manager works like an orchestrator and gives orders to other blocks. Their combination allows to achieve high level tasks, as detailed later. The architecture is organized in four principal functionality blocks (cf. Figure 1), that we detail below.

The Robot Navigation Manager is in charge of localizing the robot and allowing dynamic navigation (obstacles avoidance). It uses two sub-functions which are the ROS Navigation layer and the ROS Mapping layer (ie. provided by ROS).

Perception of the environment is performed by the Object Detection and learning module, based on deep neural networks [START_REF] Moysset | Learning to detect and localize many objects from few examples[END_REF] and off-the-shelf modules like YOLO-2 [START_REF] Redmon | Yolo9000: Better, faster, stronger[END_REF], which have been retrained and fine-tuned on additional data which we collected specifically for the targeted tasks. Labeled object positions are provided to other blocks. In addition, detailed human information such as human activity, posture, and identity is provided by the complementary People Detection Learning module.

All human-robot interactions are managed by the Robot Human Interaction block embedded in the robot. The robot also maintains a knowledge database about its environment (humans, objects, and points of interest positions).

The last module, called the World Mapping, is in charge of mapping the environment, including also semantic information, and relies on the ROS Mapping layer shared with the Robot Navigation Manager.

These modules are built on previous team's work, which can be summarized in four topics: Perception: Our computer vision module brings knowledge in gesture recognition [START_REF] Neverova | Moddrop: adaptive multimodal gesture recognition[END_REF] and activity recognition [START_REF] Baradel | Glimpse clouds: Human activity recognition from unstructured feature points[END_REF], see illustrations in Fig. 2. These methods are capable of running on real time and have been integrated in our platforms of mobile robots. Combined with object detection [START_REF] Redmon | Yolo9000: Better, faster, stronger[END_REF], this allows us to be aware of the objects present in a room, their locations, as well as the ongoing activities in this room (see illustration in Figure 3). Motion planning and Decision making: This module aims to deal with motion planning in dynamic and uncertain environments, 2D mapping, and 2D localization. We combine our work on autonomous navigation in crowded environments (human-aware navigation) [START_REF] Jumel | Mapping likelihood of encountering humans: application to path planning in crowded environment[END_REF] with service delivery strategies [START_REF] Saraydaryan | Robots delivering services to moving people : Individual vs. group patrolling strategies[END_REF]. Human-Robot Interactions: We have been working for years on different interactions with robots (from teleoperation to multi-robot orchestration [START_REF] Sevrin | Preliminary results on algorithms for multi-kinect trajectory fusion in a living lab[END_REF][START_REF] Nauer | Man-machine collaboration to acquire adaptation knowledge for a case-based reasoning system[END_REF]). The Naoqi SDK, provided by Softbank Robotics with the Pepper robot, gives a set of API that are mainly used for Robot and Human interactions (speech recognition, text to speech, robot behavior feedbacks).

In order to highlight the robot activity, the Pepper tablet gives visual feedbacks (javascript framework). In the context of the RoboCup@Home we use these different functionalities to give a user friendly interaction with robots including Animations, Tablet, and Dialogues. Integration: All components are integrated using the ROS middleware, which is the base system of our robot. ROS offers the ability to connect a set of programs through synchronous and asynchronous communication. Moreover, by allowing a set of heterogeneous components (probes, actuators, services) to communicate in a normalized way, processing program can be reused. Figure 3 illustrates this work and its implementation with a Pepper robot.

General Behavior Manager

The General Behavior Manager acts as an orchestrator of high level tasks. Four main tasks are executed in parallel : Perception Task, Navigation Task, HRI Task, and General Manager Task.

The General Manager task is in charge of loading a scenario description and managing high level call of Perception, Navigation, and HRI tasks. Each task call could interact synchronously or asynchronously with the General Manager Task. This interaction is based on action as defined in ROS Architecture and leads to a task state (pending, success, failure). The scenario description defines the sequence and conditions of task calls including task timeout, multi-conditional success, and target of the task (navigation point, dialogues, object to find, . . . ).

With the help of given ontologies, when a task failure occurs, the general manager attempts to change the task target before retrying. As mentioned in [START_REF] Sommaruga | Domoml-env: an ontology for human home interaction[END_REF], ontologies can be used to select objects sharing same properties/usages. As example, if the robot was asked to find a coke bottle, and if no one was found, the general manager could provide the alternative target "fizzy drink" (considered as parent class of coke) to the perception task. The main objectives of a social aware robot navigation is first to be safe for people around him, to be safe for itself, and then to navigate as quickly as possible while respecting social conventions. The targeted environment can be composed of dynamic obstacles, populated and congested areas. To deal with such constraints, we provide our robot with the ability to select a navigation strategy compliant with the current environment. To optimize robot navigation, we propose to maintain a context of the robot environment. To do so we distinguish two main dynamic parameters, the human density in the environment and the environment complexity (level of congestion). On one hand, with the help of the built map, we are able to compute the obstacle density of an area.

Once the area delimitation is done, a percentage of obstacle pixel in this area is computed. With the combination of the color distribution entropy [START_REF] Sun | Image retrieval based on color distribution entropy[END_REF] we can determine if an area contains a lot of obstacles and how they are distributed in the targeted area. The higher the obstacle density and dispersion is, the higher the probability to freeze the robot during navigation is. On the other hand, the world mapping function helps to maintain the observed human locations into a map. The area delimitation is then provided by segmentation following the approach of [START_REF] Mielle | A method to segment maps from different modalities using free space layout -MAORIS : Map of ripples segmentation[END_REF].

As shown in Figure 4, maintaining different contexts into a map allows the general manager to ask the navigation manager to select a navigation strategy according to the goal to achieve and the context of the environment. The Navigation manager holds a set of navigation strategies. Each navigation strategy is focused on different objectives:

optimize the robot navigation to go as quickly as possible to the objective, while being adapted to the environment. ensure a safe navigation including recovery mode in case of freezing (eg.

replay last command before robot freeze). optimize the robot navigation into populated environment (eg. by following the human flow [START_REF] Jumel | Mapping likelihood of encountering humans: application to path planning in crowded environment[END_REF]).

When the General Behavior Manager needs a Navigation Task, a first path is computed from the robot actual position A to the goal G. This path, A → G is computed by the ROS navigation task service (make plan service). Once the path is computed, the General Behavior Management get Context information and associated areas. Regarding to the path A → G, crossed areas are considered and become sub navigation goals S i . Then the General Behavior Management ask for a navigation task according to the appropriated navigation strategy π i for each sub goal until the goal is reached: A → S 0 ,. . . ,S i-1 → S i ,. . . , S n-1 → G.

Human Detection and Interaction

The interaction of the robot with close people requires that the robot can collect information about humans. To do so we build interaction abilities on different functionalities which are finally integrated (see Figure 5 Human Detection/Learning block):

-Human Detection: with the huge increase of the efficiency of Deep learning based tools, detection of objects and people is quickly carried out using standard RGB camera. For this purpose, we integrate the well known Yolo-2 model [START_REF] Redmon | Yolo9000: Better, faster, stronger[END_REF] (in its original C++ "darknet" implementation) in order to get estimates of bounding boxes centered on humans in the visual field. -Human Identification (face detection): to allow interaction with human, it is also required to recognize already met people. To tackle this problem, we adapt a module of face recognition to our system. We use the method provided by Adam Geitgey's library4 . -Human activities: we recognize complex human activities with our own method, recently introduced, and which obtains state of the art performance on standard datasets [START_REF] Baradel | Glimpse clouds: Human activity recognition from unstructured feature points[END_REF]. This method was specifically designed for robot applications: it is capable of running in near time and requires only standard sensors, i.e. a single RGB camera, while at the same time outperforming other methods, which use multiple modalities.

An additional process is required to track all these data/encountered humans. To do so we customize the world state estimator of detected object wire 6 . Wire provides a toolset to track various object attributes during the time. Object location, color and label can be tracked through various models including Kalman Filter (e.g for position attribute), uniform distribution. All these tools include a model of uncertainty to be robust in real situation. For this purpose, we customize world object model of wire to track human position according to a defined Kalman filter and all additional labels (such as id, pose, activity, and dominant color) through uniform distribution models.

With the help of this information, the General Manager updates the context map. The people density of a given area could be computed and the navigation strategies change according this update.

Step by Step Scenario Execution

In order to illustrate the behavior of our architecture, let's see the execution of an example of a general purpose robot scenario. The following scenario is aimed: after the operator is found by the robot, the operator asks the robot to go to the kitchen, to find Tom, and to say him a joke. First of all, with the existing map, the World Mapping block provides to the General Behavior Manager a Context including different room polygons with associated congestion level and people density (0.5 by default). The General Behavior Manager starts the 4 main tasks: Perception (using the Object Detection/learning and People Detection/Learning blocks), Navigation, HRI, and General Manager Task (GMT). The GMT loads the targeted scenario, including sequences of executions and task controls. The execution of this scenario is presented in table 1. In this table, gray rows refer to actions executed by the GMT itself and other rows to task calls. Concerning the columns, the id refers to the sequence number of the operation, the operation column to the type of general manager execution, the task type column gives the name of the task called, the mode column can take two values synchronous (Sync.) or asynchronous (ASync.). In the target column, the inputs of the task call is set. Finally, The success conditions are defined by the column of the same name. After waiting the door is opened (1), the GMT computes sub goals and get associated strategy to go to the living room [START_REF] Burgard | The interactive museum tour-guide robot[END_REF]. For each sub goal (3), the Navigation Task is called to go to the current sub-goal S i applying the associated navigation strategy π i . When all Navigation Task succeeded, a Perception Task is called to find a people (4). The GMT waits until a people is detected. After that, it is asked to the operator to explain the mission to do [START_REF] Calisi | Design choices for modular and flexible robotic software development: the openrdk viewpoint[END_REF]. When achieved, the GMT transforms the given information into a set of actions [START_REF] Chitic | Are middlewares ready for multi-robots systems[END_REF]. After recomputing sub goals [START_REF] Lutkebohle | Generic middleware support for coordinating robot software components: The taskstate-pattern[END_REF], the robot is asked to detect human around [START_REF] Natale | The icub software architecture: Evolution and lessons learned[END_REF] and to go to the kitchen [START_REF] Moysset | Learning to detect and localize many objects from few examples[END_REF]. Note that during the robot navigation, human information is collected and transmitted to the World Management Block. When the destination is reached, the GMT calls the World Management database to see if there is a human in the kitchen [START_REF] Redmon | Yolo9000: Better, faster, stronger[END_REF]. The robot asks to the human confirmation about it's identity [START_REF] Neverova | Moddrop: adaptive multimodal gesture recognition[END_REF]. However, it is not Tom. The GMT tries to find a new valid target by changing the level of abstract of Tom resulting into "Human" [START_REF] Baradel | Pose-conditioned spatio-temporal attention for human action recognition[END_REF]. After checking again if a human is still there [START_REF] Baradel | Glimpse clouds: Human activity recognition from unstructured feature points[END_REF], the robot tells a joke [START_REF] Jumel | Mapping likelihood of encountering humans: application to path planning in crowded environment[END_REF]. Interaction between ROS and Naoqi Dialogue System has been made allowing to test a simple general purpose robot service scenario: detect a people, ask for a task, understand task "Find Maria", navigate to search people, and identify the targeted people.

Preliminary results with these tasks can be shown in the video 7 . In this video, after introducing our research work on perception and navigation, a first experimental result with this scenario is shown. On the left side, the Robot navigation is presented including map representation and simple object detection from the robot side view. On the right side, results of object and people detection are shown thanks to the Darknet framework and Yolo 2 model. Finally, in the last part of the video, a simple general purpose robot service is presented.

Conclusion

In this paper, we offered an overview of the architecture developped by the Ly-onTech team to target the SSPL RoboCup@Home competition with a Pepper humanoid. After introducing the different AI modules we developed, we presented the architecture which allows to organize them. Then we detailed the navigation strategy selection and the human detection blocks. Finally, we introduced experimental results in a robot service scenario, including detection of people, navigation and search for a person. The video presented in Section 8 illustrates the ability of the Pepper to manage such high level tasks. The next step of this work is the evaluation of the architecture during the Social Standard Platform League (SSPL) competitions in Montreal, June 2018. This will be helpful to analyze and improve the general orchestration and each sub-function.

Fig. 1 .Fig. 2 .

 12 Fig. 1. LyonTech Software Architecture Overview

Fig. 3 .

 3 Fig. 3. Example of integration scenario including navigation and object recognition.

Fig. 4 .

 4 Fig. 4. Navigation Strategy selection

Fig. 5 .

 5 Fig. 5. People Perception processing organization

Table 1 .

 1 Operation list of the General Manager (gray rows are GMT actions, others are task calls)In order to experiment our architecture with a Pepper humanoid, we prepared Pepper to be controlled by a PC with ROS. The gateway between ROS and the Pepper robot has been customized and allow to gather Pepper sensor information (RGBD data, laser information, odometry,..). The ROS Pepper navigation task has been done with the ability to map the environment and avoid obstacles. After comparing two object/people detection techniques (tensorflow Single Shot Multibox Detector SSD and MobileNet, Darknet Yolo 2), the Darknet framework with the Yolo 2 model gives currently better results concerning object detection.

	id. Operation	Task Type Mode Target	Success Condition
	1 Loop until Success	Perception Sync. Opened Door State=success
	2 Make Path to living Room, Compute sub. goals Si, get navigation strategy πi
	3 For all Si	Navigation Sync. Si, πi	State=success
	4 Loop until Success	Perception Sync. Human	State=success
	5 Wait Success	HRI	Sync. Ask for Goal State=success
	6 Compute task list from results of task.id=5
	7 Make Path to Kitchen, Compute sub. goal Si, get Navigation strategy πi
	8 Loop until Success of task.id=9 Perception ASync. Human	State=success
	9 For all Si	Navigation Sync. Si, πi	State=success
	10 Call world management and check if human is in the kitchen
	11 Wait Task End	HRI	Sync. Ask for Name Result=Tom
	12 In case of Failure get new HRI Task Target = Human
	13 Call world management and check if human is in the kitchen
	14 Wait Task End	HRI	Sync. Tell a joke	State=Success
	8 Experimental Evaluation

http://www.robocupathome.org/

https://github.com/ageitgey/face recognition

https://github.com/CMU-Perceptual-Computing-Lab/openpose

http://wiki.ros.org/wire