Rachida Saroui

Alexandre Guitton

Oana Iova

Fabrice Valois

La rumeur

Les réseaux LoRaWAN font partie des technologies clefs pour la collecte de données dans l'Internet des Objets sur des zones étendues. Le protocole LoRaWAN propose principalement une voie montante pour la remontée des informations issues des capteurs, mais utilise également une voie descendante pour transmettre des commandes de paramétrage ou les acquittements des trames de données quand nécessaire. Dans tous les travaux de la communauté, cette voie descendante est supposée orthogonale à la voie montante, en raison de l'utilisation d'une modulation inversée entre ces deux voies. A l'aide d'expérimentations utilisant des radio-logicielles, nous montrons pour la première fois que cette rumeur disait faux : le taux de livraison de trames peut chuter de 20% lorsque des transmissions concurrentes sur les voies montantes et descendantes se produisent.

Mots-clefs : LoRaWAN, LoRa, chirp orthogonality, GNU radio, experiments.

Introduction

After a decade of research and innovation, the Internet of Things (IoT) became a reality in our everyday life, covering applications like water metering, pollution monitoring, logistics, healthcare, and home automation. To support large coverage for devices with limited energy consumption, low-power wide-area networks (LPWAN) provide a noticeable gain in terms of capacity and deployment cost when compared to classical short-range solutions. For these reasons, the Long Range (LoRa) [START_REF] Seller | Wireless communication method[END_REF] modulation and the Long Range Wide Area Network (LoRaWAN) [START_REF]LoRaWAN 1.1 specification[END_REF] protocol became crucial players in the IoT market.

In LoRaWAN, a large part of the traffic uses the uplink to send data collected from end-devices to a remote application server. The downlink is used to send (i) acknowledgments for the confirmed traffic when it is needed, and (ii) control information from the network server to the end-devices, for instance, in order to update the transmission parameters of the end-devices. Many research works have investigated the capacity and the performance of LoRaWAN [KP18, MCZ20], but they always assumed that the uplink is fully independent of the downlink. This assumption relies on the fact that the LoRa modulation scheme of the uplink uses mainly upchirps, while the downlink uses mainly downchirps.

In this work, we investigate the orthogonality of uplinks and downlinks in LoRaWAN. Using software defined radios (i.e., an USRP software and the GNU radio toolkit) and we show that the packet delivery ratio (PDR) on both uplink and downlink communications decreases by up to 20% when the transmissions are concurrent. We also show that the impact depends on the amount of overlap between the uplink and the downlink frames. To the best of our knowledge, this is the first time that a non-orthogonality result of uplinks and downlinks is shown in LoRa.

The remainder of the paper is organized as follows. In Section 2, we briefly describe the LoRa and LoRaWAN technologies. In Section 3, we present our testbed using GNU radio and USRPs. In Section 4, we show and discuss our results. Finally, we conclude our paper in Section 5.

LoRa and LoRaWAN in a nutshell

LoRa (Long Range) [START_REF] Seller | Wireless communication method[END_REF] is a physical layer using a chirp spread spectrum modulation. Each chirp is a linear frequency sweep over a given bandwidth (BW), and for a given duration. A chirp is called upchirp if the sweep is increasing (see the black chirps in Fig. 2), or downchirp if the sweep is decreasing (see the green chirps in Fig. 2). The duration of the chirp mainly depends on a parameter called spreading factor (SF). The starting frequency of the chirp gives its value, encoded on SF bits. LoRa is able to trade-off the communication range with the throughput through SF: a large SF yields a large communication range, but at the cost of a longer chirp duration, and thus of a smaller throughput. LoRa also uses a forward error correction to detect errors and correct them, denoted coding rate (CR).

A LoRa uplink frame is composed of a preamble and a payload. The preamble contains 8 upchirps of value 0, 2 upchirps encoding the network identification (NI), and 2.25 downchirps of value 0 to indicate the end of the preamble (see Fig. 2). The payload is composed of a varying number of upchirps. It usually contains a header, the actual data, and a cyclic redundancy check. A LoRa downlink frame is also composed of a preamble and a payload. Both the preamble and the payload use an inverse modulation compared to an uplink frame: upchirps are used in place of downchirps, and downchirps in place of upchirps (see Fig. 2).

To standardize the use of LoRa frames, the access to the medium, and the network architecture, LoRa Alliance defined the LoRaWAN protocol [START_REF]LoRaWAN 1.1 specification[END_REF]. In the LoRaWAN topology, end-devices send uplink frames with LoRa. The frames are captured by gateways, which forward them to a network server, which in turn forwards them to the corresponding application server. When an end-device requests a confirmation, called confirmed traffic, the network server chooses one of the gateways to reply to the end-device: the acknowledgment from the gateway is sent using a downlink LoRa frame. The network server can also send control frames to the end-devices via the gateways using downlink LoRa frames.

End-devices in LoRaWAN typically use an ALOHA mechanism. Notably, end-devices belonging to Class A send their frames without sensing the medium. After each transmission, the end-device opens two short reception windows to listen for any incoming downlink frames. Depending on regional parameters, end-devices might have to implement a duty-cycle (i.e., waiting a specified off time between two consecutive transmissions).

Implementation and validation of the testbed

In order to find out if uplink and downlink communications in LoRaWAN are orthogonal or not, we need to be able to study the effects of concurrent transmissions, i.e., we need to send uplink and downlink frames that overlap in time, and see if they are correctly received or not. If the uplink and downlink transmissions are orthogonal, both frames should be correctly received. The tricky part when setting up such an experiment is to be able to control the transmission of a frame with high time precision, so that the effects of overlapping uplink and downlink frames can be studied at the level of a symbol, where the symbol duration is 1.024 ms for the following configuration: f=868 MHz, SF=7, BW=125 kHz.

We hence decided to use Software Defined Radios (SDR). More precisely, we used the Universal Software Radio Peripherals (USRP) from National Instruments † , and the GNU Radio open-source software development toolkit. In order to send and receive LoRa frames, we need a LoRa implementation module on GNU Radio. However, since LoRa is a proprietary technology, its code is not available in open-source. We evaluated several reversed-engineering implementations and chose the implementation from Tapparel et al. [TPA + 20] ‡ that provides a full implementation of LoRa uplink frames, including sampling time offset (STO) and carrier frequency offset (CFO) estimations and corrections. However, the module does not provide the implementation of LoRa downlinks.

We implemented the transmission (resp. reception) of downlink frames by a signal processing technique called I/Q inversion on the output (resp. input) signal modulated for the uplink. This is done mathematically by swapping the I (in-phase) and Q (quadrature) components of the signal, which results into an inversion of the sign of the frequency of the signal, and thus effectively transforms upchirps into downchirps and vice versa. We validated our implementation through the following experiments:

1. Interactions with real hardware. The goal of this experiment was to ensure that the uplink and downlink modulations were correctly implemented in the USRP. We made a setup in which we sent LoRa †. National Instruments USRP-2901 (equivalent to the model USRP-B210 from Ettus Research). ‡. The module can be downloaded at https://github.com/tapparelj/gr-lora_sdr. frames from a commercial LoRa device § to our USRP, and vice versa. We were able to successfully decode the frames, both on the USRP and on the commercial device, proving that our USRP implementation is compatible with the LoRa modulation.

Non-orthogonalité des liens montants et descendants en LoRa

2. Capture effect. The goal of this experiment was to verify that the capture effect of LoRa works correctly in our USRP implementation. We setup two USRPs to send uplink messages with different transmission power to a third USRP, acting as the receiver. We varied the transmission power, but we fixed all the other parameters (frequency band 868 MHz, SF=7, BW=125 kHz and CR=4/5). We observed the packet error rate as a function of the difference of signal power, and observed that when a signal is at least 6 dB stronger than another, the strong signal is captured. These results are consistent with the state of the art, and show that the capture effect works correctly in our implementation.

3. Interference-free environment. The goal of this experiment was to setup a baseline for our tests and verify that our results are not impacted by external interference. We setup one USRP to send 100 uplink frames to another USRP, and observed the packet delivery ratio (PDR). Then, we repeated the same experiment for downlink frames. As we can see in Fig. 1(c), the results showed a PDR of 1, meaning that our experiment was not significantly influenced by external interference.

Considering these three experiments, we assume that our implementation and environment are validated.

4 Results: pseudo-orthogonality of uplink and downlink in LoRa

In this section, we describe our main experiment in order to determine whether uplink communications and downlink communications are orthogonal or not (hint: they are not!). We setup four USRPs as follows: 1 st is transmitting only uplinks, 2 nd is receiving only uplinks, 3 rd is transmitting only downlinks, and 4 th is receiving only downlinks (see Fig. 1(a)). Both transmitters use the same transmission power, and are located at the same distance from the receivers. We use the LoRa parameters for the highest data rate (SF=7, BW=125 kHz, CR=4/5), which gives us the smallest symbol duration possible (1.024 ms). Note that our findings also apply for the other LoRa parameters.

To investigate uplink and downlink orthogonality, we setup concurrent uplink and downlink communications, and we vary the delay between the two transmitters to control the overlap between the two frames. An example of such concurrent transmission is shown on Fig. 1(b). Note that in this example, the two frames are slightly desynchronized. In order to experience all possible overlaps, we configure a periodic transmission for the 40 downlink frames, and we delay the transmission of the uplink frame with a time offset varying from 0 symbol to 40 symbols with a step of one symbol. For each value of the delay, two repetitions are performed. The average PDR for uplink and for downlink are shown in Fig. 1(c). Surprisingly, the PDR decreased by approximately 10% for both transmissions, whereas it was 100% before. This clearly shows that the two communication streams are not orthogonal as initially thought. §. Dragino LoRa Shield https://www.dragino.com/products/lora/item/108-lora-gps-shield.html The red boxes represent collisions between upchirps (in black) and respectively downchirps (in green) from different frames. The PDR is computed as the mean between uplink and downlink PDRs in the specified setup.

We further investigate this result by comparing the signal representations and the PDR of the two signals at different time offsets, as can be seen in Fig. 2. We can notice that as the offset increases from 1 to 4 symbols, the number of chirps that overlap also increases, leading to a decrease in PDR by up to 15%. This is clearly because the uplink downchirps are getting superposed with the downlink downchirps, and the same for the upchirps. For lack of space, we cannot add here the remaining of the figures, but we see a PDR varying from 79% to 99%, depending on the number of symbols that overlap. Furthermore, we also noticed that even when the two transmissions happen exactly at the same time, i.e., the time offset is 0 symbol, there is a slight decrease in PDR (0.97), showing that the uplink and downlink signals are not completely orthogonal. Indeed, for a signal and its spectral inversion to be orthogonal, the components I and Q have to be perfectly orthogonal, which is not always the case because of the IQ imbalance phenomenon [START_REF] Alavi | Orthogonal summing and power combining network in a 65-nm all-digital RF I/Q modulator[END_REF], meaning there is an error on the phase shift and one on the amplitude.

Conclusion

LoRa uplinks and downlinks use an inverse modulation, and are therefore believed to be orthogonal. In this paper, we implemented an experimental setup using SDRs in order to verify this assumption. We showed for the first time that uplinks and downlinks are not orthogonal. The PDR on the uplink decreases in the presence of downlink traffic by up to 20%. This new result may significantly impact all the performance studies on the uplink capacity of LoRaWAN in the presence of downlink traffic. ¶

FIGURE 1 :

 1 FIGURE 1: (a) Testbed setup using four USRPs. (b) Waterfall diagram for two concurrent uplink and downlink frames, with time flowing downwards. (c) PDR for uplink and downlink traffic. The boxes show the median (in red), the first and third quartile (the box), and the 95% confidence interval (the whiskers).

  Uplink starts 1 symbol after the downlink. PDR is 0.94. (B) Uplink starts 2 symbols after downlink. PDR is 0.91. UL DL (C) Uplink starts 3 symbols after the downlink. PDR is 0.90. (D) Uplink starts 4 symbols after the downlink. PDR is 0.85.

FIGURE 2 :

 2 FIGURE 2: Concurrent uplink and downlink transmissions as a function of the time offset between the two frames. The red boxes represent collisions between upchirps (in black) and respectively downchirps (in green) from different frames. The PDR is computed as the mean between uplink and downlink PDRs in the specified setup.


Juan A Fraire

Mehdi Ait Mesbah

Pablo Madoery

Oana Iova

Fa- Brice Valois

FLoRaSat : Le simulateur pour la communication LoRa avec les satellites LEO

Keywords: LoRa, LoRaWAN, Satellite en orbite terrestre basse (LEO), Simulateur, Direct-to-Satellite-IoT, Omnet++

Le nouveau paradigme de communication, Direct-to-Satellite-IoT (DtS-IoT), est une approche très prometteuse pour le transfert de données depuis/vers des appareils IoT dans des zones reculées où le déploiement d'une infrastructure terrestre n'est pas faisable. Dans ce contexte, les satellites en orbite terrestre basse (LEO) peuvent équiper des passerelles IoT comme celles de LoRa, pour faciliter la collecte de données des capteurs situés sur Terre en ligne de vue directe. Cependant, cette communication est soumise à plusieurs défis : grandes distances de transmission (500 à 2000 km), couverture sporadique et de courte durée (environ 7 minutes), liaisons inter-satellites à faible bande passante, et appareils IoT contraints en énergie. Pour permettre à la communauté de mettre en oeuvre et d'étudier des protocoles pour la communication DtS-IoT de façon réaliste, nous proposons un nouvel outil de simulation à événements discrets : FLoRaSat. Le simulateur s'appuie sur Omnet++ et implemente un scénario de communication DtS-IoT de de bout en bout comprenant 16 satellites LEO interconnectés et 1500 noeuds IoT sur Terre qui communiquent à l'aide du protocole LoRaWAN.

Introduction

The recent spur in space projects has revamped the interest in satellite communication. This is especially observed in the Internet of Things (IoT) community that constantly seeks to diversify the application scenarios [CCG + 21], but also, from the telecommunication operators that want to expand the IoT network coverage to offer a promising omnipresent world-wide service.

Satellites in Low Earth Orbit (LEO) are deployed at low altitudes (160-1, 000 km) and move at ∼7 km/s, which results in overflights of <10 min over a given spot on the surface. These characteristics make LEO satellites very appealing to the IoT community, as they can be reached by low-power, long-range technologies such as NB-IoT and LoRa. IoT devices with a clear line-of-sight to the sky can directly access the satellite with an on-board gateway, even with low-cost antennas, and without any other modification to the device. This can be extremely useful to applications in less accessible regions (i.e., oceans, mountains, poles) that might not justify or even hinder the deployment of IoT gateways. However, transmission distance and orbital dynamics, combined with highly constrained devices on the ground make Direct-to-Satellite IoT (DTS-IoT) a very challenging problem. In fact, existing IoT medium access control protocols, negotiations schemes, etc. need to be revised and/or extended to scale up to these challenging conditions.

One of the main challenges with DTS-IoT is the evaluation of all these new protocols and network architectures, as real deployments are extremely costly and rigid. So we need realistic simulators implementing both IoT and satellite technologies as detailed as possible, which currently do not exist. The few papers that started looking into DTS-IoT use custom-made simulators based on Matlab that lack accurate modelling of the network layer. To this end, we propose FLoRaSat, a novel event-driven open-source end-to-end simulation tool that leverages OMNET++ and includes a benchmarking DTS-IoT scenario comprising 16 cross-linked LEO satellites and 1500 IoT end-devices.

In order to realistically represent the environment in which future DTS-IoT systems will operate in, we need (i) an accelerated simulation approach so that we can quickly simulate LEO satellite orbits, (ii) a realistic implementation of the physical, medium access, and network layers, and (iii) an environment that allows running multiple seeds and parametric studies. To this end, we propose FLoRaSat † (Framework for LoRa-based Satellite IoT), an open-source, event-driven simulator that mimics satellite and IoT systems, and their interactions.

FLoRaSat leverages (i) the well-known OMNET++ framework ‡ with its INET extension for the classical Internet stack, and (ii) the open-source LoRa-based simulator FLoRa § with its basic implementation of the LoRaWAN [START_REF] Slabicki | Adaptive configuration of lora networks for dense iot deployments[END_REF] protocol. We adapted, extended, and ported the physical layer (LoRa) and the link layer (LoRaWAN) from FLoRa to the DTS-IoT configuration, to which we added a set of new ground-braking features related to the satellite IoT context. We propose a scenario in which end-devices communicate directly with one or more LoRaWAN gateways situated on LEO satellites, which are organised in a constellation. Gateways send beacons at regular time intervals to announce their presence using Class B mode of LoRaWAN, and end-devices buffer data until a satellite is in sight. Satellites also communicate among each other using inter-satellite links. The current version of FLoRaSat includes a constellation of 16 LEO satellites and up to 1500 devices distributed uniformly in a circular region with a 2000 km radius (in South America) ¶ . To simulate this scenario in FLoRaSat, we used a modular approach that allows us to easily modify and plug-in different approaches.

Orbital mechanics. The orbital dynamics elements are in charge of propagating satellites along realistic trajectories. We created an orbital processing pipeline in which the scenarios can be designed using the state-of-the-art Systems Toolkit (STK), from AGI || . Then, we implemented an export script in C# to obtain the position of each satellite in 𝑋, 𝑌 , 𝑍 coordinates in the Earth-centred inertial frame (ECI), as well in Latitude, Longitude and Altitude (LLA) on a second-by-second granularity. Due to the ECI coordinate reference system, IoT devices are seen as fixed points (satellites are the only element with a time-evolving position in ECI), so they do not need to be created in STK. During simulation time, these files are consulted by the satellite mobility module, the inter-satellite distance computation module, and by the visual module.

Inter-satellite routing. Since satellite IoT services need to be deployed in networked constellations to cover large geographical areas, we include an inter-satellite link (ISL) model with a basic LEO-to-LEO routing solution. We propose a grid-shaped LEO constellation, in which a single satellite implements a contact with a ground station (e.g., satellite [15] in Figure 1), and we implement a simple right-up and down-left routing approach for the uplink and downlink traffic flows respectively. More sophisticated routing approaches (e.g., topology-aware Contact-Graph routing) can be easily added in the future.

LoRaWAN Class B. As discussed by Vogelgesang et al. [START_REF] Vogelgesang | Uplink transmission probability functions for lora-based direct-to-satellite iot: A case study[END_REF], a beacon can play an important role in announcing satellite presence and synchronising DTS-IoT devices on ground. In LoRaWAN, this can be achieved leveraging the Class B mode of communication where the gateway periodically sends a beacon to synchronise and ping end-devices. Class A is also supported from the legacy version of FLoRa.

Application model. In the DTS-IoT scenario, IoT devices can not always assume an IoT gateway will be present in the sky. Therefore, the application model was extended to also include a delay-tolerant scheme, where data is buffered until a satellite is present.

All these features are integrated into the FLoRaSat modular architecture depicted in Figure 1. Each of the illustrated elements corresponds to an OMNET++ compound module. LoRaNic and LoRaGWNic implement the LoRa and LoRaWAN layers in the device and in the gateway situated inside the satellite. The packetForwarder and ISLpacketForwarder modules take care of multiplexing and relaying LoRaWAN frames to and from the LoRa radio and the ground station link (available in satellite [15]), and the ISLs links (up to 4 depending on the satellite position on the grid), respectively. When forwarded to the ground station, the LoRaWAN frame is encapsulated in an UDP datagram, which is then forwarded to the Internet, to be finally delivered to LoRaWAN network server. Other modules like mobility, interfaces, and routingTable elements leveraged from INET are illustrated in Figure 1. Finally, a visualizer module takes care of the world-map graphics and a LoRaMedium component affects LoRa frames with channel impairments (free space loss channel model in this first release).

Metrics. FLoRaSat disposes of a plethora of metrics, such as transmission/reception frame count, collision tracking, or end-to-end latency. We also present LoRaWAN-based DTS-IoT specific metrics in the following section.

Preliminary Results

In this section we present preliminary results of the 16-satellite scenario (ISL data rate set to 100 Kbps) for varying device count. Traffic model is set to generate one LoRa frame of 20 B, (spreading factor 12) every 40-120 seconds with a uniform distribution (quite close to the 1% duty cycle limit). The simulation runs for 1 hour, enough for the satellite fleet to pass-by the circular region with up to 1500 devices.

While analysing the first FLoRaSat simulations, we found that LoRaWAN technology operates on tight latency constraint between the server and gateway, when downlink messages are sent to the device (i.e., ACKs). As per LoRaWAN specification, devices will open two one-second reception windows precisely one and two seconds after the uplink attempt concluded. But LoRaWAN gateways are not expected to buffer data, instead, it is the network server who should timely send the downlink data so that it properly fits in the device's reception windows. Because the DTS-IoT scenario involves multiple LEO satellites, and multi-hop ISL routing, accomplishing such a precise timing proved to be challenging. To keep track of this phenomena, we define and study a Downlink Packet Arrival Delay Since Beginning of the Rx Window (DPAD) metric.

The left plot in Figure 2 presents the drop rate in the uplink and the downlink (due to collisions), and the resulting transmission failure (when any of the two fails). Results show that 80% drop rate can be expected with 200 nodes under the most demanding traffic load. DPAD for decoded downlink ACKs destined to the local node (i.e., local traffic) ** are presented in the right plot of Figure 2. Results show that 100 kbps in the ISL (and the custom right-up-down-left routing) are enough to accommodate a multi-hop delivery of the downlink message without exceeding 0.12 seconds (which fits the 1-second reception window). Figure 3 presents two example parametric studies with FLoRaSat. The right plot study the varation of DPAD for different ISL data rates. It confirms that DPAD approximates 0.5 seconds for data rates below ** . Given the multi-gateway condition of the scenario, we found that under the most demanding traffic load, multiple nodes might open the reception window simultaneously, while hooking into a downlink message preamble destined to another node. This is peculiar observation possibly affecting terrestrial LoRaWAN we plan to study in further detail in future research.

Outlook

Even though the preliminary nature of the results presented for this first version of FLoRaSat, this promising satellite IoT simulator already enabled non-intuitive observations such as 1) the effect of DPAD and 2) the issue of detecting preambles from frames destined to other nodes (in a multi-gateway case). While we keep deepening on these end-to-end satellite IoT aspects, we envision a fruitful development path towards a feature-rich FLoRaSat including the new LoRa modulation (long-range frequency hopping spread spectrum, LR-FHSS) along side with the NB-IoT protocol stack. Furthermore, interesting analysis are already undergoing by the authors, such as LoRaWAN Class-A and Class-B comparison in the DTS-IoT context, the consideration of a GEO relay satellite, and the development of novel scheduling and learning techniques that profit from the predictable and repetitive characteristics of satellite IoT. ‡ ‡

FIGURE 1 :

 1 FIGURE 1: FLoRaSat user interface (left) and architecture (right).

FIGURE 2 :

 2 FIGURE 2: Drop Rate (left) and mean DPAD for frames destined to the local node (right) (shadow: 95% CI)


Bertrand David
email: bertrand.david@ec-lyon.fr

René Chalon
email: rene.chalon@ec-lyon.fr

Chuantao Yin
email: chuantao.yin@buaa.edu.cn

Design methodology for "Smartification" of Cities: Principles and case study

Keywords: Smart city, Collaborative design process, Design methodology, Assistive system, Coastal City, Smartification

The Smart City is a possible evolution of each City. With the rapid development of information technologies applied everywhere in city life, cities are becoming smarter and smarter. However, this context has multiple orientations, supported by an architecture of the assistive system and the associated implementation process. In this paper, we propose a design methodology with different approaches and illustrate them by a case study that attempts to transform a coastal city into a Smart Coastal City. All the design methodologies and technologies can be referred in other smart city applications.

I. INTRODUCTION

The Smart City is a very ongoing and important application field of ICT (Information and Communication Technologies), which is able to receive a wide variety of contributions, using multiple declinations of ICT aspects (data management, data processing, Human Computer Interaction, information accessibility in mobility, automated or on demand information access, etc.). This area is so large that it is not easy or possible to find a commonly accepted definition. However, to clarify our view we decided to consider the following definition: "The Concept of <<Smart Cities>> describes how investments in human and social capital and modern Information and Communication Technologies (ICT) infrastructure and e-services fuel sustainable growth and quality of life, enabled by a wise management of natural resources and through participative government" [START_REF] Caragliu | Smart cities in Europe[END_REF]. Another definition is: "a Smart City should use smart computing technologies and infrastructures to make city services more intelligent, interconnected, and efficient, including city administration, education, healthcare, public safety, real estate, transportation, and utilities [START_REF] Yin | A literature survey on smart cities[END_REF].

The next view is technology-oriented. We identified 7 main techniques needed in order to implement a Smart City approach, namely: context-aware middleware for ambient intelligence; appropriate user interface in relation with the users' situations (mobile, nomadic or static), and the relationship with an appropriate set of rules related to the privacy of information exchanged between smart city applications by their users: Web 2.0 use i.e. collaborative (wiki-based) surfing, Internet of Things (IoT), allowing object to object communication without human implication, Location-Based Services (LBS) with multiple exchange configurations related to environment context; Open Data use in order to share available data collected by other applications in ours, thus avoiding installation of new devices in the field; and Machine and Deep Learning in order to benefit from available data and confront them with new ones and obtain an automated adaptation to new working or living conditions and behaviors.

To establish the context of a "Smartification" of a city, two basic questions must be answered:  Smart City to whom: there are many answers, from a generic one "to all", to more specialized and precise ones (by age: kids, teenagers, adults, seniors), by city status, by implication in the city (citizen, neighbor, student, worker, administrator, governor); and also, "to all" from the deficiencies' point of view.

 Smart City for what: better common well-being and neighborhood, energy, transportation of goods and passengers, information dissemination on culture, sports, social services, etc.

The Smart City is an area of use for all ICT possibilities: data accessibility, data processing, information access exchange and manipulation in static and mobility situations, using wired or wireless networks, in appropriate applications considering contextual situations.

The remaining sections are organized as follows. The next very short Section two is devoted to a brief state-of-theart presentation. Section three discusses the conceptual view of a smart city management system from three viewpoints: assistive system role and functions, intermediation platform, and its architecture. The fourth section describes the design methodology of city "smartification". The fifth section gives an example applied to the Coastal City. The last section proposes main conclusions and future work.

II. STATE-OF-THE-ART

To carry out a complete state-of-the-art for the Smart City seems to be a totally impossible goal as the amount of work is large and diversified. Just to establish a common definition and classification is hard and not yet successful, while to list all approaches and contributions seems very difficult [START_REF] Yin | A literature survey on smart cities[END_REF]. We can split it into two viewpoints: the users' one and the technological one.

From the users' viewpoint, the list of applications is unbounded, as we mentioned earlier. From the technological one, i.e. from the implementation one, the list is also over abounded, but shorter to explain: software architecture, Internet, Cloud computing, Internet of Things (IoT), Location-Based Services (LBS), Open Data (OD), and Machine and Deep Learning (ML & DL).

III. CONCEPTUAL VIEW

A. Assistive system role and functions

To provide appropriate services organized in an assistive system, it is important to identify the main aspects of this system. Globally, ITS (Information & Communication Systems) are responsible for considering data collection, storage and management, appropriate manipulations in different working situations, providing communication over short and large distances by wireless and wired networks, in mobility, and interacting with the environment in which active and passive things are organized in IoT (Internet of Things). Two important aspects are HCI (Human-Computer Interaction), and new services based on AI (Artificial Intelligence). The main HCI objectives are related to multimodal and multi-channel communication with various devices and interaction styles such as touch-based and speech-based interactions, as well as AR (Augmented Reality) approaches. These interactions can occur either on a desktop computer or with mobile devices (smartphones, connected watches, tablets), allowing individual and collaborative situations, and large, in-the-field, screens or in infrastructure integrated HCI devices, as in the vehicle dashboard.

From the AI point of view, Big Data, Open Data, and Machine and Deep Learning are mainly used to procure appropriate information from the huge amount of data available and to synthetize observed behaviors issued from typical data. An interesting summarization is proposed in Fig. 1 [3].

B. Intermediation platforms

To organize all these aspects, it is appropriate to create an Intermediation platform, the aim of which is to connect people, services and even things in ways that have been unthinkable until now. Search engines provide relevant references for people searching for information. Social networks connect users in their environment.

Users' activities on the platform collect the data coming from the field either from specific sensors or from Open Data, and generate secondary data. The latter mainly consist of traces that the platform is able to use and transform for specifically created secondary services.

C. Intermediation architecture

A generic intermediation platform needs to be adapted to different working situations (as for our case study described later on). The objective is to provide appropriate collection of data, services, and acquisition sensors and valuators, which are able to work together in a vitalization approach and create adapted User Interfaces allowing appropriate interactions. The Mashup approach is an interesting way to support these adaptations. Mashups are defined as "the software engineering approach, which is able to construct by assembling and combination of several existing functions new applications" [START_REF] David | Orchestration modeling of interactive systems[END_REF].

The Mashup architecture is made up of three elements according to Merrill cited by [START_REF] Atrouche | A mashup-based application for the smart city problematic[END_REF]: Data, Services, and User Interface. Mashup aims at the composition of a three-tier application: (1) Data (data integration), (2) Application logic (process integration), and (3) User Interface (presentation integration). Integration of heterogeneous data sources uses two main technologies: web services and Mashup. Application mashuping in the context of intermediation platforms is a much-appreciated approach for creating appropriate applications based on reuse of existing ones. It is based on a four-layer architecture (Fig. 2a). To update or adapt data and services, a particular User Interface is used called "Supportive UI", the aim of which is to introduce appropriate adaptations concerning data, services, IoT exchanges, and HCI. This supportive User Interface, which is also Mashup application creation-or evolution-oriented, proposes a programming interface for experienced developers, and a visual programming-oriented approach for experienced users (Fig. 2b).

D. Open data

One of the possible sources of information is the access to open data published by different operators, such as municipalities, road operators, etc. These data can be either historical data synthetized and giving general tendencies or real-time data, indicating what is happening now or a few minutes ago.

Open Data [START_REF] Auer | DBpedia: A Nucleus for a Web of Open Data[END_REF] is the idea that some data should be freely available to everyone to use and republish as they wish, without restrictions from copyright, patents or other mechanisms of control [START_REF] Kitchin | The Data Revolution[END_REF] ) is an EU initiative to establish an infrastructure for spatial information in Europe, which is geared to help make spatial or geographical information more accessible and interoperable for a wide range of purposes supporting sustainable development.

E. Machine Learning and Deep Learning

Deep Learning is hugely popular today. The past few decades have witnessed its tremendous success in many applications. Academia and industry alike have competed to apply deep learning to a wider range of applications due to its capability to solve many complex tasks while providing state-of-the-art results [START_REF] Paul | Deep neural networks for youtube recommendations[END_REF]. In some situations, Deep Learning can be used to analyze existing data, leading to interesting solutions. We can take intelligent navigation and travel planning as examples. For intelligent navigation, the intermediation platform considers the starting position and the destination position, combines the time information, meteorological information and other interfering factors, before providing the most appropriate one or more recommended paths. As for travel planning, the focus is to intelligently analyze the user's intention of their behavior and finally make travel recommendations based on the tags they are interested in and their browsing history.

In practice, we can use the RNN structure in path planning, including intelligent navigation, travel for the disabled, Parcel post and so on, while the CNN model can be used for vehicle recognition to assist smart parking. For some scenarios with recommendation tasks, such as goods transportation and travel planning, we can use multi-layer perceptron, LSTM, and other models [START_REF] Huang | Learning deep structured semantic models for web search using click through data[END_REF].

IV. DESIGN METHODOLOGY

To design a Smart City, it is possible to proceed in several ways. The easiest is to create from scratch an application and deploy it. When several applications are proposed, a more system-oriented approach is suggested, which either can be proposed or must be elaborated.

Several design methods can be used, depending on the context in which they evolve (Fig. 3). In the case of Smart City system design from scratch, the top-down approach (1) seems appropriate. In this case, the study starts with identification of potential users and corresponding services by a discussion with them in order to identify their wishes and expectations. Naturally, the next steps are identification of data on which these selected services can work and, finally, the sensors and actuators needed to obtain an appropriate relationship with the field. These different aspects are implemented progressively place in the Assistive System Platform described earlier ( § III.A).

Conversely, the bottom-up approach (2), could be appropriate if the objective or main question is which services can be provided to potential users on the bases of available data. In this case, the working process starts with identification of in-the-field devices and corresponding data provided by them. Also, services and potential users are determined later. This environment-based approach is appropriate if the starting point is composed of a large scope of problems, and if the set of potential users (and services) is open-ended.

Naturally, between these "extreme" approaches an extension-oriented approach is also possible, and may probably be most commonly used. Its characteristic is its adaptation to extension-oriented situations, i.e. to consider new users, new services, and/or new data integration to an existing Smart City Assistive System (3). In this case, two sub-approaches can be distinguished, in the same way as for the "from scratch" approach: top-down or bottom-up with integration of different starting points: either from users and services or from data, sensors, and actuators needed. In these two cases, the objective of this integration process is to identify the new set of actors and homogenize services, data, sensors, and actuators to avoid redundancy and incoherence that are difficult to manage during platform life.

Another approach is based on integration and reuse of on-the-shelf applications, constituting patterns (4), which have been created earlier and proposed as pattern solutions. In this case, the integration process could also contain homogenization considering all the pattern characteristics: User + Services + Data + Sensors & Actuators to reach a homogeneous system. The last t approach but not the least is based on Open Data as starting point (5), and integration or elaboration of appropriate services using them.

V. CASE STUDY: TRANSFORMATION OF A COASTAL CITY INTO A SMART CITY

In order to propose the evolution of a city to a Smart City, and specifically for the Coastal City, we need first to characterize what the Coastal City is, before applying the approaches presented above to the "smartification" of a Coastal City. We limit it to the dimension of management of mobility, and its integration into the corresponding assistive system. We characterize a Coastal City as a city which is located by the sea or the ocean (Fig. 4). Its activities are related to the sea, i.e. fishing, boat transportation, boat and ship repairing, and also possibly boat and ship construction. A large majority of coastal cities also have major tourist activities related to the proximity of more or less large beaches with swimming, diving, snorkeling, yachting, kitesurfing, fishing as current practices.

This tourist reception aspect dominates the organization of City life. It introduces the notion of high and low season, mainly by the number of its inhabitants, which can vary considerably between these two seasons (multiply their number by 10 or more in summer). This means that the demand of life organization is totally different. In the low season, few inhabitants can live quietly without stress, noise or traffic jams. However, economically speaking, this period is a waiting period for a large majority of inhabitants oriented towards business, excluding retired people, in different forms (restaurants, shops, accommodation, and recreation activities).

It seems natural to study the evolution of this kind of city to a Smart City in the context of high season city life, and only later ensure that in the low season it is possible to propose appropriate limited behaviors and the city services adapted to the low season and its inhabitants.

A. Top-down approach

An example of the Top-down approach in the Coastal City is the objective to work with all concerned persons and determine main orientations of "smartification" from their viewpoints in the context of mobility. To respond to this, we identified the objective of creating park-and-ride systems outside the city with automatic public transportation to the town and the beaches, to optimize traffic organization on the ground, in the harbor and the sea, as well as management of beach activities. Special solutions such as traffic lane management [START_REF] Wang | Dynamic Road Lane Management Study: A Smart City Application[END_REF] or delivery parking reservation [START_REF] Patier | A new concept for urban logistics: Delivery area Booking[END_REF] can constitute concrete examples.

B. Bottom-up approach

Concerning the Bottom-up approach, an interesting example is to provide an efficient warning system based on in-the-field devices (sea, water, air, lighthouse, stormy and howling wind, etc.), propagating emergency and rescue information at all levels (global, individual, visual, sound, digital, etc.).

C. Add extension: boat management

The list of possible extensions is open-ended. We can mention the management of circulation in the harbor, which can be either limited to the local area, or generalized to the overall management and supervision of boats in the harbor and on the sea. The ecosystems for fishing and cruising boats are schematized in Fig. 5 & Fig. 6. The principle is to identify all concerned actors and situations and indicate their behaviors, their interrelations, and contributions to appropriate trip and work conditions. In the past, we studied this kind of ecosystem for buses (e-bus) and trucks (e-truck) [START_REF] David | User-oriented System for Smart City approaches[END_REF] and adapted them to these situations.

D. Add extension: beach and sea mobilities

A very important "smartification" is related to beach and sea mobilities. This can be either the main aspect of the overall study or added separately. On the beach several activities can take place, more or less active in nature: from sunbathing, walking along the seashore, practicing different sports or family activities. In all cases, it is important to take into account other beach users, in order to avoid accidents and disturbing them. During the recent COVID period, for many French beaches, city mayors at local level or, more globally, government authorities decided on several levels of rules: prohibit access to the beaches, authorize only "dynamic use of the beach" (no sitting or sunbathing, only walking and running). This also included respect of distances between groups of users, either natural or physically materialized zones with possibility of reserving them (Fig. 7).

On the sea, the development of activity zones is the usual approach leading to creation of specific zones with supervised swimming, diving, snorkeling activities, as well as sailing, yachting, surfing, kitesurfing, with either visual supervision or more instrumented electronic monitoring. In this case, each actor (swimmer, sailor, kite surfer has at their disposal a connected watch or more sophisticated device able to communicate their position and related situation (OK, emergency call, etc.). On the beach, lifeguards are equipped with a receiver capturing the observed situation and able to trigger rescue actions.

E. Based on open data: shelter

As an example of the service based on open data, we choose a shelter. We initially proposed a bus shelter [START_REF] David | Hotspot based mobile web communication and cooperation: ABRI+ Bus Shelter as a hotspot for mobile contextual transportation and social collaboration[END_REF], but its adaptation to other situations, such as beach shelter, harbor shelter, public market shelter is not difficult. The shelter can be located downtown, near the carpark, on the harbor and near the beaches. Its objective is to provide potential passengers and visitors with appropriate information on transportation lines and their schedules, using appropriate screens, as well as providing local, cultural and sports programs, commercial advertising, etc., together with, if needed, physical services (shower or changing cabin). The information part is mainly based on presentation of generally available information issued from open data (Fig. 8).

F. Pattern-based approach: Pedestrian Drive

As an example of a pattern-based approach, we can present what we call the Pedestrian Drive, the aim of which is to provide fresh food distribution based on box-lockers [16]. The idea is to convey fresh food on the beach instead of asking clients to go to a supermarket. The Pedestrian Drive is a variant of the concept of the supermarket drive, specially designed for pedestrians. Located as near as possible to the client locations (beaches, sports arenas, etc.) and accessible 24 hours a day, it allows ordered goods to be collected at any time. Equally, it is able to store not only ambient temperature products but also fresh and frozen goods (Fig. 9). This fresh product box-locker can be either owned by a supermarket firm and totally integrated into the ordering, management and logistic process of the firm, or can be managed independently. This case is an interesting support system for the shared economy, as the role of the pedestrian drive manager is to manage such use for multiple providers. His/her role is to ensure Internet access for all provider offers and to organize the global supply chain with consumer information on availability of ordered goods in the boxlocker. In this way, the circular economy as a short circuit of agricultural goods can be supported. Its characteristic, in which we are interested, is its independence from the implementation location. That is why we present it as a pattern of autonomous equipment completely characterized by what we call Pattern: User + Services + Data + Sensors & Actuators, which are easy to position at the chosen location.

G. Machine and Deep Learning use

We would also like to briefly present a possible use of Machine and Deep Learning technics. Our case study is sea behavior-oriented. Its objective is to study evolution in sea behavior over the season and, in particular, weather conditions as the wing and tide coefficient changes to inform swimmers and/or kiters of the organization of the supervised zone. By accumulating the data of different periods, it would seem possible to indicate foreseeable sea behavior (Fig. 10).

VI. CONCLUSIONS

Of course, this case study is not complete. Its objective is only to illustrate proposed approaches of the design methodology of "smartification" of cities in a particular context of the Coastal City. We voluntarily limited our study to mobility aspects and avoided two very important problems, namely adaptation of cities during "smartification" to the elderly and, in particular, to disabled people. We partially studied this last aspect in the following publications [START_REF] Yin | Assistive systems for special needs in mobility in the Smart City[END_REF], [START_REF] Li | Assistive Systems for Mobility in Smart City: Humans and Goods[END_REF]. We did not have room to present an important aspect, namely dynamicity in all presented (re)organizations, which can be permanent (available all the time) or evolving according to the time scale (each month, week, day, weekdays, weekend, morning, afternoon, evening, night, per hour or in unpredictable exceptions). Naturally, signaling must be appropriate (static or with appropriate dynamicity), with propagation of applicable rules to different users using suitable HCI devices. In the future, other aspects of "smartification" of mobility will be studied, as well as refinement of proposed support aspects.

Fig. 1 .

 1 Fig. 1. Smart city architecture summarized by Liu and Peng [3].

Fig. 2 .

 2 Fig. 2. a/ Architecture of an Intermediation platform with Data Vitalization [5], b/ Supportive User Interface [6].

  . The goals of the open-source data movement are similar to those of other "open(-source)" movements such as open-source software, hardware, open content, open specifications, open education, open educational resources, open government, open knowledge, open access, open science, and the open web. Paradoxically, the growth of the open data movement is paralleled by a rise in intellectual property rights [9]. INSPIRE (Infrastructure for Spatial Information in the European Community

Fig. 3 .

 3 Fig. 3. Design and deployment approaches

Fig. 4 .

 4 Fig. 4. Coastal city with downtown, harbor, beaches, and boating industrial zone.

Fig. 5 .

 5 Fig. 5. Fishing Boat information ecosystem.

Fig. 6 .

 6 Fig. 6. Cruising Boat information ecosystem.

Fig. 7 .

 7 Fig. 7. COVID location beach management, sea zone supervision and rescue organization.

Fig. 8 .

 8 Fig. 8. Bus or Boat shelter

Fig. 9 .

 9 Fig. 9. Box-Lockers for fresh and frozen foods [16].

Fig. 10 .

 10 Fig.10. Surf safety panel issued from history observation[START_REF] Yin | Assistive systems for special needs in mobility in the Smart City[END_REF].

ACKNOWLEDGMENT

This work is a collaboration between one French team located in Lyon and one Chinese team located in Beijing. We thank our partners and their students and researchers for their contributions. This work is partially supported for the Chinese part by the National Key R&D Program of China (No. 2019YFB2102200) and the National Natural Science Foundation of China (No. 61977003).