ThingsLocate: A ThingSpeak-Based Indoor Positioning Platform for Academic Research on Location-Aware Internet of Things
- Ease of use and ease of deployment—IoT is expected to pervade and integrate seamlessly in both consumer and industrial applications. This goal can however only be achieved if IoT devices and systems are easy to deploy and setup, not requiring extensive calibration phases and/or complex setup procedures;
- Hardware limitations—IoT devices range from very simple devices, with a single wireless interface and minimal computing/processing power, to powerful processing stations equipped with multiple Radio Access Technologies (RATs) and accessory sensors;
- Cloud computing—IoT is inherently relying on Internet connectivity and on the availability of processing power in the cloud, allowing simple IoT devices to operate by just collecting and transferring data, without local processing.
2. Indoor Positioning Platforms
- limited device support - although all platforms support smartphones, albeit in some cases only Android ones, only a few support other devices. A notable exception is the FIND platform , which supports several devices by dedicated interfaces and provides passive positioning of all active WiFi devices within the coverage area;
- lack of integration with IoT platforms - each indoor positioning platform provides its own apps, user interfaces and Application Programming Interfaces (APIs), making the integration in a IoT system rather challenging. Even in flexible platforms, such as FIND, the extension or improvement of positioning algorithms requires significant work on both the positioning server code and on the software interfaces for the supported platforms, often written in different programming languages.
3. Internet of Things Platforms and ThingSpeak
- The Kaa platform  provides a standalone server installation for local execution, and supports remote execution for a fee on the AWS platform. Kaa supports currently about 15 hardware platforms by means of endpoint SDKs written in C, C++, Objective-C, or Java, depending on the hardware. The platform also provides an advanced User Interface (UI) for the management of clients and applications, and supports popular client/server communication protocols, including Hyper Text Transfer Protocol (HTTP), Extensible Messaging and Presence Protocol (XMPP) and MQTT. Furthermore, Kaa supports the transfer of data collected at the central server to a wide range of back-ends and databases, including Oracle, Apache, and MongoDB, where processing of data can be later carried out. Kaa does not offer however data processing capabilities on the platform itself, beyond the transformation of raw data into time series. The platform also provides a set of widgets that can be used to visualize data and to send commands to connected devices.
- Lelylan  is a platform composed by a set of micro-services that provide key functionalities, including connectivity between clients and server. Lelylan is particularly suited to connect a user with remote-controlled devices (e.g., light switches or actuators) using HTTP and MQTT protocols, and supports a wide range of hardware platforms (about 20) by means of so-called physical APIs. The platform does not provide however built-in data processing capabilities. Lelylan is in fact based on an event bus that registers user requests sent from a Web app over HTTP and makes them available to a Physical Proxy. The Physical Proxy forwards then the requests to the interested hardware devices for the execution of the actions correlated with the request itself. The platform also provides real time feedback and notifications to inform the user and/or other entities of the outcome of the actions.
- OpenMTC  is a reference implementation of the oneM2M standard for M2M communications, and provides APIs to connect hardware through HTTP, HTTPS, MQTT, and feed collected data to a middleware aggregator in charge of sending such data to external applications. Although interesting, the OpenMTC does not provide any built-in processing and visualization capabilities, relying on external apps to carry out these tasks.
- SiteWhere  is a platform available in both Community (free) and Enterprise (paid) editions, and similarly to Lelylan is organized in micro-services that provide connectivity with devices, integration with external services, and command delivery to devices. SiteWhere supports MQTT, Advanced Message Queuing Protocol (AMQP) and Streaming Text Oriented Messaging Protocol (STOMP) protocols for communications with devices, using JSON or Protocol Buffers data formats. No specific provisions are given regarding data processing and visualization, mainly relying on the integration with external databases for offline data processing in Azure, Apache SoIr, and other services.
- The ThingBox  is a Raspberry Pi-based IoT platform that takes advantage of the Node-Red visual editor  by IBM to develop IoT applications. Device support and processing capabilities are based on “nodes” made available in the Node-Red editor, each node corresponding to a specific feature (e.g., support for a specific hardware or software platform). The UI for management is however less developed than those provided by Kaa and Lelylan. Furthermore, The ThingBox is defined to be a “local” IoT implementation, with no cloud support. Although multiple Raspberry Pis can operate simultaneously, they will not interact.
- ThingSpeak  is an open-source IoT platform composed by a central server that provides data collection, processing and analysis, and libraries/APIs to support IoT devices. The open-source central server can be installed locally or run in the cloud, with both free and paid pricing schemes. ThingSpeak stands out for its extremely easy interface for data processing and presentation, thanks to the support of the Matlab language in the cloud deployment, including graphic output and several Matlab toolboxes. Access to such toolboxes is granted based on a paid MathWorks license in addition to basic, free Matlab support provided by ThingSpeak. The platform provides web APIs using both the HTTP and MQTT communication protocols, allowing the support of a wide range of devices, including smartphones as well as all major IoT hardware platforms, such as Arduino, Raspberry Pi, Electric Imp, Particle Photon, and ESP8266. Integration with external services is possible by exporting data in JSON, Comma Separated Values (CSV) and eXtensible Markup Language (XML) formats, or by adopting the ThingHTTP protocol.
- A channel is a data structure identified by a unique id, and by keys for writing to and reading from it, and is the basic structure for data storage in ThingSpeak, under the form of timestamped data entries. As an example, a channel could be used to store temperature readings by a sensor in time. Each entry in the channel would then include a reading with the corresponding timestamp. A channel can contain up to 8 fields of data, and an entry in a channel is defined as the combination of the 8 fields of data and of a timestamp.
- A message is the base information transfer unit, and is defined as the information transferred when an entry is written to a ThingSpeak channel by a device using the ThingSpeak write API.
4. The ThingsLocate Platform
- RSSI channels—A set of TS channels used by target devices to upload RSSI data. is a system parameter to be selected at platform deployment time, as explained later;
- Locate App—A TS Matlab Analysis app implementing the positioning algorithm, with execution triggered by the upload of data on the RSSI channels by a device;
- Location channel—A TS channel used to publish the estimated location.
4.1. RSSI Channels
4.2. Location Channel
4.3. Locate App
- a bidimensional matrix of size , where is the total number of RPs defined in the area covered by the positioning system, and is the total number of different APs detected in the area. Please note that in areas of large dimensions only a subset of the APs will be detected in each RP, and will be thus the size of the union of all APs detected in at least a single RP. For a generic AP i not detected at a generic RP j, the entry will be set to a reference value lower than the receiver sensitivity threshold;
- a bidimensional matrix of size , containing in j-th row the 3D coordinates of the j-th RP;
- a vector of length , storing the MAC address of each detected AP in the same order adopted to fill in each row of the matrix;
- The pairs loaded by the target device on the RSSI channels are mapped on a vector of length , using the information contained in the vector as follows: the generic j-th element of , , is set either to the RSSI value measured for , if this was uploaded by the target device, or to , otherwise;
- The position of the target device is estimated from and using either the combination of positioning algorithm and positioning metric requested by the device in the or the default one, if no requests are expressed;
- the estimated position is published on the Location channel, following the structure described in Section 4.2.
- In kNN, the k RPs with RSSI values most similar to the ones recorded by the target device are selected, according to a similarity metric . The estimated position is then obtained as the average of the positions of the selected RPs:
- WkNN is an extension of kNN in which the positions of the k selected RPs are weighted according to a weighting function evaluated on the similarity metric :
- EWkNN, introduced in , as mentioned before, determines k dynamically for each positioning request, as a result of a two-step pruning procedure of the set of RPs. Two strategies can be adopted in the selection of the thresholds to be used in the pruning steps: a static strategy in which the thresholds are predetermined, and a dynamic one, in which they depend on the content of .
- FI-WkNN, proposed in , relies on frequentist theory of inference combined with a measure of similarity given by the Pearson’s correlation statistical index. The algorithm uses the p-value probabilities associated with a test statistic defined over , as defined in frequentist inference, to determine the relevance of each RP: RPs characterized by a low p-value are deemed more relevant than those with a high p-value. FI-WkNN can work with either a fixed or a dynamic k selection strategy. In the former case the k RPs with the smaller p-values are considered in the estimation of the position of the target device using Equation (2), while in the latter case a RP j is included if it passes an hypothesis test defined as , where is a tunable threshold.
- the inverse Minkowski distance, with order p, defined as follows:
- the squared value of the Pearson correlation coefficient , defined as:
4.4. ThingsLocate Setup Procedure
- Environment scan, corresponding to the offline phase of WiFi fingerprinting introduced in Section 1, focuses on the acquisition of the data required to create the , and data structures. This step starts with the definition of the set of Reference Points and the recording of the corresponding coordinates in the matrix, as well as of the corresponding value. Next, RSSI data are collected at each RP. Once all measurements have been carried out, the union of AP IDs detected in each of the RPs is used to create the vector, and determine thus the dimensions of the matrix. Finally, RSSI data are recorded in the following for the rows the same order adopted for , and within each row the same order adopted for the vector. The time required for this step is directly related to the number of RPs to be analyzed that, in turn, depends on the size of the area to be served by the positioning system and on the selected spatial density of RPs. In the case of large areas and/or high densities of RPs, the Environment scan step can require hours or days of work, and is by far the most time-consuming step in the setup procedure. This issue is inherent to the WiFi fingerprinting approach and not to its implementation in ThingsLocate. A possible solution will be discussed in Section 6.
- Server-side configuration focuses on the preparation of the cloud elements of the ThingsLocate platform. It includes the creation of the RSSI and Locate channels and the configuration of the Locate App, based on the information collected during the Environment scan step and on the channel IDs of the RSSI and Locate channels just created. The number of RSSI channels to be created is also determined in this step, based on the data collected in the Environment scan step. Since each channel can contain the data for three APs, the number of RSSI channels to be created is approximately equal to one third of the maximum number of APs detected in a single RP.
- Device-side configuration deals with the configuration of client code in each device. It consists of writing the IDs of the RSSI and Location channels and the value of , needed by the device to determine how many RSSI values can be reported when submitting a positioning request.
4.5. Positioning Procedure
- Upload—the target device collects RSSI data as pairs , and uploads them on the RSSI channels, jointly with control information as previously described;
- Locate—the information upload at Step 1 triggers the execution of the Locate Analysis app that reads data from the RSSI channels, estimates the position of the IoT device using the selected algorithm, and writes the estimate on the Location TS channel.
4.6. Client Code
- collection of RSSI data during the offline phase (Environment scan step);
- collection of RSSI data and submission of positioning requests during the online phase.
- configurable number of measurements to be averaged, to increase reliability of the RSSI data;
- configurable filename for offline storing (for the offline phase);
- automatic ordering of collected data in decreasing order of RSSI value, so that if more than values are collected the less important ones are discarded;
- configurable positioning algorithm, positioning metric and corresponding settings to be uploaded on the channel (for the online phase).
5. Proof of Concept: Indoor Positioning of Android and Raspberry Pi Devices
5.2. Impact of Devices on Positioning Accuracy
5.3. Impact of Algorithms on Positioning Accuracy
6. Current Limitations and Future Developments
- limited update frequency and total messages—in its free pricing tier, ThingSpeak limits the frequency of updates on a channel to 1/15 s, and the total number of messages for an account to 3 million/year. The former limitation can in particular become a serious concern when many devices report their RSSI readings simultaneously, leading to an aggregate update frequency above the threshold. This issue can however be addressed in at least two ways: (1) subscribe to a different pricing tier that allows removal of this limitation by paying a monthly fee; (2) duplicate the set of RSSI channels by replicating their structure and distribute the devices over the different sets, in order to guarantee that the aggregate update frequency for each set is below the threshold.
- limited number of fields per channel—the channel structure in ThingSpeak foresees 8 fields, typically insufficient to upload all data required for a positioning request. The solution adopted in the TL platform, consisting of splitting the data over N RSSI channels, overcomes the issue, at the price however of a loss of efficiency in the use of the channels, since the repetition of the on each channel limits the number of AP readings that can be reported on each channel to 3. Although programming approaches have been proposed to force more than 8 fields in association with each channel, there is currently no straightforward solution to this issue.
- definition of new fingerprinting positioning algorithms and similarity metrics—new algorithms and metrics can be added in a straightforward manner, by adding them to the Locate app code without requiring any change to the client software. Any variation of WkNN, in particular, can be added with almost no coding effort.
- optimization of offline phase RSSI data collection—it was pointed out in Section 4.4 that the RSSI data collection carried out during the offline phase in the Environment scan step accounts for most of the time required for the setup procedure, and that this issue is inherent to the way WiFi fingerprinting works. Recently, however, a promising technique to solve this issue was proposed by the authors of the present work . The technique, named virtual fingerprinting, allows reduction of the number of RPs to be processed (and the corresponding time) by at least one order of magnitude by generating synthetically the remaining ones using a deterministic channel model . The integration of the technique would not require any change to the ThingsLocate platform, and would dramatically speed up the deployment of the platform.
- extension to WiFi positioning algorithms beyond fingerprinting—algorithms that rely on RSSI levels (e.g., trilateration algorithms based on power, as in ) can be added again by modifying accordingly the Locate app, without changing the structure of RSSI channels or the client code. The addition of algorithms that rely instead on different information, such as Time-Of-Arrival (TOA), Time-Difference-Of-Arrival (TDOA) or Direction-Of-Arrival (DOA), will typically require changes to both client code and Locate App. Note however that TOA, TDOA, and DOA require specific hardware support in client devices, making them typically less suitable for off-the-shelf IoT devices .
- adoption of other wireless technologies—the ThingSpeak platform can be easily adapted for the use of a wireless technology different from WiFi. The Locate App and the TS channels need no modifications, and the client code can be easily tweaked to collect RSSI data for the selected technology instead of WiFi. The use of another technology in place of WiFi is appealing mainly for energy consumption reasons. WiFi is in fact a relatively energy-hungry technology, and frequent scans could quickly drain energy reserves in IoT devices not equipped with high capacity batteries. This issue could be addressed by adopting low-consumption RATs proposed for IoT devices, such as Bluetooth Low Energy, LoRa, and SigFox, at the price however of additional efforts to set up the wireless environment so that enough wireless signals are available for RSSI positioning. A rich wireless environment is in fact a key requirement for accurate RSSI-based positioning, and no other technology can currently match the spatial signal density of WiFi, typically guaranteeing tens or even hundreds of signals in an urban location.
Conflicts of Interest
|AMQP||Advanced Message Queuing Protocol|
|API||Application Programming Interface|
|AWS||Amazon Web Services|
|CIR||Channel Impulse Response|
|CMX||Connected Mobile Experiences|
|CSV||Comma Separated Value|
|GNSS||Global Navigation Satellite Systems|
|HTTP||Hyper Text Transfer Protocol|
|HTTPS||Hyper Text Transfer Protocol - Secure|
|IoT||Internet of Things|
|M2M||Machine To Machine|
|MQTT||Message Queuing Telemetry Transport|
|NGSI||Next Generation Sensors Initiative|
|OPC-UA||Open Platform Communications-Unified Architecture|
|Probability Density Function|
|RAT||Radio Access Technology|
|REST||REpresentational State Transfer|
|R&D||Research and Development|
|RSSI||Received Signal Strength Indicator|
|SDK||Software Development Kit|
|STOMP||Streaming Text Oriented Messaging Protocol|
|XML||eXtensible Markup Language|
|XMPP||Extensible Messaging and Presence Protocol|
|WkNN||Weighted k-Nearest Neighbor|
- Nester, R. Internet of Things (IoT) Market: Global Demand, Growth Analysis and Opportunity Outlook 2023. Available online: https://goo.gl/XxRSd1 (accessed on 15 July 2019).
- Markets and Markets. Internet of Things Technology Market by Hardware (Processor, Sensor, Connectivity Technology), Platform (Device Management Platform, Application Management Platform, Network Management Platform) Software Solutions, and Services, Application, and Geography-Forecast to 2022. Available online: http://www.marketsandmarkets.com/Market-Reports/iot-application-technology-market-258239167.html (accessed on 15 July 2019).
- Juniper Research. THE INTERNET OF THINGS The Internet of Things—Consumer, Industrial and Public Services 2016–2021. Available online: https://www.juniperresearch.com/researchstore/key-vertical-markets/internet-of-things/consumer-industrial-public-services (accessed on 15 July 2019).
- Perera, C.; Zaslavsky, A.; Christen, P.; Georgakopoulos, D. Context Aware Computing for The Internet of Things: A Survey. IEEE Commun. Surv. Tutor. 2014, 16, 414–454. [Google Scholar] [CrossRef]
- Al-Turjman, F.; Alturjman, S. Context-Sensitive Access in Industrial Internet of Things (IIoT) Healthcare Applications. IEEE Trans. Ind. Inform. 2018, 14, 2736–2744. [Google Scholar] [CrossRef]
- Guerrero-ibanez, J.A.; Zeadally, S.; Contreras-Castillo, J. Integration challenges of intelligent transportation systems with connected vehicle, cloud computing, and internet of things technologies. IEEE Wirel. Commun. 2015, 22, 122–128. [Google Scholar] [CrossRef]
- Rong, W.; Vanan, G.T.; Phillips, M. The internet of things (IoT) and transformation of the smart factory. In Proceedings of the 2016 International Electronics Symposium (IES), Denpasar, Indonesia, 29–30 September 2016; pp. 399–402. [Google Scholar] [CrossRef]
- Li, D.; Zhang, B.; Li, C. A Feature-Scaling-Based k-Nearest Neighbor Algorithm for Indoor Positioning Systems. IEEE Internet Things J. 2016, 3, 590–597. [Google Scholar] [CrossRef]
- Chen, C.; Chen, Y.; Han, Y.; Lai, H.Q.; Zhang, F.; Liu, K.J.R. Achieving Centimeter-Accuracy Indoor Localization on WiFi Platforms: A Multi-Antenna Approach. IEEE Internet Things J. 2017, 4, 122–134. [Google Scholar] [CrossRef]
- Chen, C.; Chen, Y.; Han, Y.; Lai, H.Q.; Zhang, F.; Liu, K.J.R. Achieving Centimeter-Accuracy Indoor Localization on WiFi Platforms: A Frequency Hopping Approach. IEEE Internet Things J. 2017, 4, 111–121. [Google Scholar] [CrossRef]
- Lee, C.H. Location-Aware Speakers for the Virtual Reality Environments. IEEE Access 2017, 5, 2636–2640. [Google Scholar] [CrossRef]
- Vasilateanu, A.; Goga, N.; Guta, L.; Mihailescu, M.N.; Pavaloiu, B. Testing Wi-Fi and bluetooth low energy technologies for a hybrid indoor positioning system. In Proceedings of the IEEE International Symposium on Systems Engineering (ISSE), Edinburgh, UK, 3–5 October 2016; pp. 1–5. [Google Scholar]
- Ciftler, B.S.; Kadri, A.; Guvenc, I. IoT Localization for Bistatic Passive UHF RFID Systems With 3-D Radiation Pattern. IEEE Internet Things J. 2017, 4, 905–916. [Google Scholar] [CrossRef]
- Figueiredo e Silva, P.; Kaseva, V.; Lohan, E.S. Wireless Positioning in IoT: A Look at Current and Future Trends. Sensors 2018, 18. [Google Scholar] [CrossRef]
- De Angelis, G.; De Angelis, A.; Pasku, V.; Moschitta, A.; Carbone, P. A hybrid outdoor/indoor Positioning System for IoT applications. In Proceedings of the IEEE International Symposium on Systems Engineering, Rome, Italy, 28–30 September 2015; pp. 1–6. [Google Scholar]
- Wi-Fi Device Shipments to Surpass 15 Billion by End of 2016. Wi-Fi Alliance. Available online: https://www.wi-fi.org/news-events/newsroom/wi-fi-device-shipments-to-surpass-15-billion-by-end-of-2016 (accessed on 15 July 2019).
- Honkavirta, V.; Perala, T.; Ali-Loytty, S.; Piche, R. A comparative survey of WLAN location fingerprinting methods. In Proceedings of the 6th Workshop on Positioning, Navigation and Communication (WPNC), Hannover, Germany, 19 March 2009; pp. 234–251. [Google Scholar]
- Bahl, P.; Padmanabhan, V.N. RADAR: an in-building RF-based user location and tracking system. In Proceedings of the 19th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM), Tel Aviv, Israel, 26–30 March 2000; Volume 2, pp. 775–784. [Google Scholar]
- Caso, G.; De Nardis, L.; Di Benedetto, M.G. A Mixed Approach to Similarity Metric Selection in Affinity Propagation-Based WiFi Fingerprinting Indoor Positioning. Sensors 2015, 15, 27692–27720. [Google Scholar] [CrossRef] [PubMed]
- Hossain, M.S. Cloud-Supported Cyber–Physical Localization Framework for Patients Monitoring. IEEE Syst. J. 2017, 11, 118–127. [Google Scholar] [CrossRef]
- MazeMap. MazeMap—Indoor Maps & WayFinding. Available online: https://www.mazemap.com (accessed on 15 July 2019).
- MeridianApps BluDot. Available online: http://meridianapps.com (accessed on 15 July 2019).
- Georgiou, K.; Constambeys, T.; Laoudias, C.; Petrou, L.; Chatzimilioudis, G.; Zeinalipour-Yazti, D. Anyplace: A Crowdsourced Indoor Information Service. In Proceedings of the 16th IEEE International Conference on Mobile Data Management (MDM ’15), Pittsburgh, PA, USA, 15–18 June 2015; Volume 2, pp. 291–294. [Google Scholar]
- InfSoft—Smart Onnected Locations. Available online: https://www.infsoft.com (accessed on 15 July 2019).
- FIND. FIND—The Framework for Internal Navigation and Discovery. Available online: https://www.internalpositioning.com (accessed on 15 July 2019).
- Available online: https://www.arubanetworks.com (accessed on 15 July 2019).
- Cisco Connected Mobile Experiences (CMX). Now Part of Cisco DNA Spaces. Available online: https://www.cisco.com/c/en/us/solutions/enterprise-networks/dna-spaces/index.html (accessed on 15 July 2019).
- GoIndoor Navigation Technology. Available online: https://www.goindoor.co (accessed on 15 July 2019).
- Singh, K.J.; Kapoor, D.S. Create Your Own Internet of Things: A survey of IoT platforms. IEEE Consum. Electron. Mag. 2017, 6, 57–68. [Google Scholar] [CrossRef]
- Amazon Web Services. Available online: https://aws.amazon.com (accessed on 15 July 2019).
- Google IoT Core. Available online: https://cloud.google.com/solutions/iot-overview (accessed on 15 July 2019).
- FIWARE. Available online: https://www.fiware.org (accessed on 15 July 2019).
- Kaa Project. Available online: http://www.kaaproject.org (accessed on 15 July 2019).
- Lelylan. Available online: http://www.lelylan.com (accessed on 15 July 2019).
- OpenMTC. Available online: http://www.open-mtc.org (accessed on 15 July 2019).
- SiteWhere. Available online: http://www.sitewhere.io/ (accessed on 15 July 2019).
- Thingbox. Available online: http://thethingbox.io/ (accessed on 15 July 2019).
- Node-Red Visual Editor. Available online: https://nodered.org (accessed on 15 July 2019).
- ThingSpeak. Available online: http://www.thingspeak.com (accessed on 15 July 2019).
- Microsoft Azure IoT Accelerators. Available online: https://azure.microsoft.com/en-us/features/iot-accelerators/ (accessed on 15 July 2019).
- Loftsgaarden, D.O.; Quesenberry, P.C. A nonparametric estimate of a multivariate density function. Ann. Math. Stat. 1965, 36, 1049–1051. [Google Scholar] [CrossRef]
- Li, B.; Salter, J.; Dempster, A.G.; Rizos, C. Indoor positioning techniques based on wireless LAN. In Proceedings of the 1st IEEE International Conference on Wireless Broadband and Ultra Wideband Communications, Waltham, MA, USA, 13–16 March 2006; pp. 13–16. [Google Scholar]
- Yu, F.; Jiang, M.; Liang, J.; Qin, X.; Hu, M.; Peng, T.; Hu, X. 5G WiFi Signal-Based Indoor Localization System Using Cluster k-Nearest Neighbor Algorithm. Int. J. Distrib. Sens. Netw. 2014, 10, 1–12. [Google Scholar] [CrossRef]
- Shin, B.; Lee, J.H.; Lee, T.; Seok, K.H. Enhanced weighted K-nearest neighbor algorithm for indoor Wi-Fi positioning systems. In Proceedings of the 8th International Conference on Computing Technology and Information Management (NCM and ICNIT), Seoul, South Korea, 24–26 April 2012; pp. 574–577. [Google Scholar]
- Philipp, M.; Kessel, M.; Werner, M. Dynamic nearest neighbors and online error estimation for SMARTPOS. Int. J. Adv. Internet Technol. 2013, 6, 1–11. [Google Scholar]
- Caso, G.; De Nardis, L.; Di Benedetto, M.G. Frequentist inference for WiFi fingerprinting 3D indoor positioning. In Proceedings of the IEEE International Conference on Communication Workshops, London, UK, 8–12 June 2015; pp. 809–814. [Google Scholar]
- Dudani, S.A. The Distance-Weighted K-Nearest- Neighbor Rule. IEEE Trans. Syst. Man Cybern. 1976, SMC-6, 325–327. [Google Scholar] [CrossRef]
- Caso, G.; De Nardis, L.; Lemic, F.; Handziski, V.; Wolisz, A.; Di Benedetto, M.G. ViFi: Virtual Fingerprinting WiFi-based Indoor Positioning via Multi-Wall Multi-Floor Propagation Model. IEEE Trans. Mob. Comput. 2019. [Google Scholar] [CrossRef]
- Caso, G.; De Nardis, L. Virtual and Oriented WiFi Fingerprinting Indoor Positioning based on Multi-Wall Multi-Floor Propagation Models. Mob. Netw. Appl. 2017, 22, 825–833. [Google Scholar] [CrossRef]
- Rusli, M.E.; Ali, M.; Jamil, N.; Din, M.M. An Improved Indoor Positioning Algorithm Based on RSSI-Trilateration Technique for Internet of Things (IOT). In Proceedings of the 2016 International Conference on Computer and Communication Engineering (ICCCE), Kuala Lumpur, Malaysia, 26–27 July 2016; pp. 72–77. [Google Scholar] [CrossRef]
|Platform||Communication Protocols||Data Processing||Data Visualization||Integration with External Services|
|Channel||Field 1||Field 2||Field 3||Field 4||Field 5||Field 6||Field 7||Field 8|
|EWkNN||Metric||p order/N/A||Threshold strategy||Threshold 1/N/A||Threshold 2/N/A|
|FI-WkNN||k strategy||k /||N/A||N/A||N/A|
|k||Number of neighbors used in estimation||Any positive integer number|
|p order||p order used in the Minkowski distance||Any positive integer number|
|Threshold strategy||Strategy for threshold definition in the EWkNN algorithm|
|Threshold 1||Value of first threshold in the EWkNN algorithm when ‘StaticThreshold’ strategy is adopted||Any positive real number|
|Threshold 2||Value of second threshold in the EWkNN algorithm when ‘StaticThreshold’ strategy is adopted||Any positive real number|
|k strategy||Strategy for selection of k in the FI-WkNN algorithm|
|Hypothesis test threshold used in the FI-WkNN algorithm when ‘DynamicK’ strategy is adopted||Any positive real number|
|Device||RSSI Average Value (dBm)||RSSI Variance ()|
© 2019 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).
De Nardis, L.; Caso, G.; Di Benedetto, M.G. ThingsLocate: A ThingSpeak-Based Indoor Positioning Platform for Academic Research on Location-Aware Internet of Things. Technologies 2019, 7, 50. https://doi.org/10.3390/technologies7030050
De Nardis L, Caso G, Di Benedetto MG. ThingsLocate: A ThingSpeak-Based Indoor Positioning Platform for Academic Research on Location-Aware Internet of Things. Technologies. 2019; 7(3):50. https://doi.org/10.3390/technologies7030050Chicago/Turabian Style
De Nardis, Luca, Giuseppe Caso, and Maria Gabriella Di Benedetto. 2019. "ThingsLocate: A ThingSpeak-Based Indoor Positioning Platform for Academic Research on Location-Aware Internet of Things" Technologies 7, no. 3: 50. https://doi.org/10.3390/technologies7030050