Dec 2, 2013 - The database is based on Microsoft SQL Server format. .... INTEGER. TX ... It is the first non-commented l
ICT- 248894 WHERE2 D4.6 Cooperative Location Algorithm Implementation and Evaluation Contractual Date of Delivery to the CEC:
M39
Actual Date of Delivery to the CEC: 02.12.13 Editor:
Diogo Condeço
Author(s):
Participant(s):
Diogo Condeço, Telma Mota, Roberto Vieira, Hugo Marques, Jorge Ribeiro, Shahid Mumtaz, Joaquim Bastos, Jonathan Rodriguez, Julien Stéphan, Thomas Colleu, Yoann Corre, Miguel Angel García Izquierdo, Roi Arapoglou, Nansy Alonistioti, George Agapiou, Ioanna Papafili, Igor Arambasic, Ivana Arambasic, Santiago Zazo Bello, Mariano García, Javier Casajus, Benoît Denis, Soumaya Zirari, Nicolas Amiot, Mohamed Laaraiedh DLR, ACO, CEA, IT, EUR, SIG, PTIN, UPM, NKUA, OTE
Workpackage:
WP4 – Heterogeneous Test Bed for Location and Communications
Estimated person months: (resources spent on the deliverable) Security:
PU
Nature:
R
Version:
D4.6
Total number of pages:
73
Abstract: This report presents the tests and evaluation of the exploited algorithms from the various partners using real measured data obtained from PTIN’s environment. A measurement campaign was carried out with the different platforms of the project under the same conditions to provide real and reliable data so that the presented algorithms could be tested and evaluated. The different systems (UWB, LTE, ZigBee, WiFi) within the project were used in the measurement campaign to allow providing the different required types of data. For the WiFi measurement campaign using mobile phones, a secure cluster communication protocol was used to ensure the data integrity between devices. During the evaluation stage the main focus was the evaluation of the algorithms from the WP2. Other systems were evaluated with specific data unable to be collected during the described measurement campaign, like was the case of the evaluation of the building opening detection algorithm related with T2.3 on environment characterization or mapping, which required specific measurements to collect the necessary data for their evaluation. Finally, this document also addresses the different scenarios where the location information is integrated in different systems to allow their performance enhancement, whether in location aided communication services, context applications using location information, or heterogeneous location systems.
WHERE2
D4.6
Keyword list: WHERE2 Database, Demonstration, Test, laboratory conditions, trials, evaluation, Interoperability Framework, heterogeneous platforms, measurement campaigns, ZigBee, UWB, LTE, RTD, WiFi, Common Framework.
Page 2 (73)
WHERE2
D4.6
Executive Summary Indoor location is an open field where many research groups employ their means searching for solutions capable of providing accurate location estimations, which would allow it to be adopted as a standard, like it happens in the outdoor environments with the Global Positioning System (GPS). There is still some ground to cover as each scenario presents its particular challenges and problems, and where some techniques may present some benefits over the others depending on the conditions environments. It is also necessary to address the hardware requirements, not only the fixed infrastructures inside the buildings, but also the requirements for the user terminal, as some techniques may require specific hardware no commonly available in devices carried by the users on a daily basis, like: smartphones, tablets, laptops, etc. A first section of this document addresses the implementation and evaluation of two different systems: one related with the measurement campaign and how the communication between nodes during that campaign were established; and another relates with the evaluation of an algorithm to detect openings on buildings from three-dimensional scans of those same buildings. A secure cluster communication protocol is evaluated on Android Mobile phones, used during the measurement campaign of WiFi signals, which communicate between them to report the data to a central node. Such work was developed under WP3 and further implemented and tested on WP4. Regarding the opening detection algorithm, such system allows for a computer to automatically map openings, like windows and doors, from an existing 3D model representation of the building. The presented evaluation addresses the work from T2.3 regarding the environment characterisation and mapping. Under the scope of the WHERE2 project several research works were carried out addressing different solutions and techniques, in other to obtain more accurate location estimations in indoor environments, brought from WP2 to the implementation and evaluation scenarios of WP4. The developed research work was based on the development and refinement of solutions covering the most common systems used for indoor location estimation, like: WLAN, LTE, ZigBee, UWB. Furthermore, different techniques were applied to these systems during the project, like: ToA, RTD, RSS, TDoA, etc, in order to develop solutions able to extract those location estimations, from the available information on the devices. Furthermore, while some works were based on existing devices, others were carried out on dedicated hardware. The work presented on this report demonstrates the tests carried out on those platforms (mainly developed on WP2 and WP3), under real conditions, to evaluate their performance in such conditions, aiming to decide for their viability in a future self-contained solution. The variety of the tests conducted were made using generic data available to all platforms and obtained under the same conditions during the PTIN’s measurement campaign (T4.5), where the various partners collected the necessary data for these tests. Furthermore, other tests were carried out using specific sets of data, due to particular conditions on this data collection conditions. Thus, the building opening detection due to its special hardware requirements and the infeasibility of bringing them to the measurement campaign was developed with a specific set of data, as well as the FUNEMS’13 demonstration, which relied on the environment conditions, unable to be predicted or obtained on a different scenario. The context platform, also developed under the scope of WP4 is also evaluated at the end of this document.
Page 3 (73)
WHERE2
D4.6
Authors
Partner PTIN PTIN PTIN CEA CEA IT IT IT IT IT OTE OTE NKUA NKUA SIR SIR SIR UPM UPM UPM UPM UPM UPM UR1 UR1
Name Diogo Condeço Telma Mota Roberto Vieira Benoît Denis Soumaya Zirari Hugo Marques Jorge Ribeiro Shahid Mumtaz Joaquim Bastos Jonathan Rodriguez George Agapiou Ioanna Papafili Roi Arapoglou Nansy Alonistioti Julien Stéphan Thomas Colleu Yoann Corre Miguel Izquierdo Igor Arambasic Ivana Arambasic Santiago Zazo Bello Mariano García Javier Casajus Nicolas Amiot Mohamed Laaraiedh
Phone / Fax / e-mail
[email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected] [email protected]
Page 4 (73)
WHERE2
D4.6
Table of Contents 1 Introduction ............................................................................................... 12 2 System Implementation ............................................................................ 13 2.1 Android WiFi platform ................................................................................................ 13 2.2 Building’s openings detection ..................................................................................... 17
3 System Evaluation .................................................................................... 26 3.1 Localization algorithm evaluation using PTIN measurements .................................... 26 3.1.1 Description of the used model parameters and scenario ...................................... 26 3.1.2 Performances Evaluation of RGPA ..................................................................... 27 3.1.3 Performances Evaluation of the Hypothesis Testing method. ............................. 29 3.2 Performance of message passing algorithm with PTIN measurements ....................... 31 3.2.1 UWB system – CEA measurements .................................................................... 32 3.2.1.1 Connectivity with trolley on specific route ................................................ 32 3.2.1.2 UWB distance error model ........................................................................ 33 3.2.2 ZigBee system – ACORDE measurements.......................................................... 35 3.2.2.1 Connectivity with trolley on specific route ................................................ 35 3.2.2.2 ZigBee distance error model ...................................................................... 35 3.2.3 Simulation results ................................................................................................. 38 3.2.3.1 UWB .......................................................................................................... 38 3.2.3.2 ZigBee........................................................................................................ 39 3.3 Heterogeneous and Cooperative Positioning with Links Selection Applied to PTIN Measurements .............................................................................................................. 39 3.3.1 Tested Algorithms ................................................................................................ 40 3.3.1.1 Weighted Least Squares Positioning Algorithm ........................................ 40 3.3.1.2 Decentralized Extended Kalman Tracking Filter ...................................... 40 3.3.1.3 Links Selection Algorithm ......................................................................... 41 3.3.2 Measurement Post-processing.............................................................................. 42 3.3.2.1 Scenario and Mobility Description ............................................................ 42 3.3.2.2 Zigbee/RSS Measurement ......................................................................... 43 3.3.2.3 UWB/TOA Measurement .......................................................................... 45 Page 5 (73)
WHERE2
D4.6 3.3.2.4 Heterogeneous Positioning ........................................................................ 46
4 Realisation ................................................................................................. 47 4.1 Scenarios ...................................................................................................................... 47 4.1.1 Indoor positioning and horizontal handover employing RSSI fingerprinting in OTE Labs ............................................................................................................. 47 4.1.2 PTIN Scenario ...................................................................................................... 54 4.1.2.1 Context location based ............................................................................... 55 4.1.2.2 Android application ................................................................................... 56 4.1.3 UPM Scenario ...................................................................................................... 59 4.1.3.1 Heterogeneous Multi-standard Environment ............................................. 59 4.1.3.2 User’s Guide .............................................................................................. 64 4.2 Demonstrations ............................................................................................................ 67 4.2.1 FUNEMS ............................................................................................................. 67
5 Conclusions .............................................................................................. 71 6 References................................................................................................. 72
Page 6 (73)
WHERE2
D4.6
List of tables Table 1: A subset of the most relevant Packages/Classes and APIs used in the android WHERE2 application. ........................................................................................................................... 13 Table 2: ZigBee path loss models extracted for scenario 2.1. ..................................................... 26 Table 3: UWB ToA ranging model extracted for scenario 2.1. .................................................. 26 Table 4: Statistical positioning error for scenario 4.1 ................................................................. 29 Table 5 Statistical positioning error RGPA vs RGPA HT .......................................................... 31 Table 6: Existing links and number of measurements per link at trolley position 28. ................ 32 Table 7: Existing links and number of measurements per link at trolley position 40. ................ 33 Table 8: Existing links and number of measurements per link at trolley position 104. .............. 33 Table 9: Median RSSI values per fixed node links. .................................................................... 36 Table 10 The uncertainties in the distributed EKF...................................................................... 41 Table 11: Zigbee path loss and shadowing global model parameters ......................................... 44 Table 12: Zigbee RSS ranging model using only one RSS sample for each neighbour. ............ 44 Table 13: Ranging model for UWB based on one distance sample per neighbour. .................... 45 Table 14: Ranging model for UWB based on mean distances per neighbour............................. 46 Table 15: UPM_RAYTRACINGTABLE. .................................................................................. 63
Page 7 (73)
WHERE2
D4.6
List of figures Figure 1: SDL diagram for the android WHERE2 application. .................................................. 14 Figure 2: Android WHERE2 application GUI ............................................................................ 16 Figure 3 – WHERE2 homepage at the Google Play repository .................................................. 17 Figure 4: SIRADEL’s mobile mapping vehicle. ......................................................................... 18 Figure 5: Overview of the methodology. .................................................................................... 18 Figure 6: Input data (left part) and street view image from Google Earth (right part). ............... 19 Figure 7: Extraction of Ground Points (grey points). ................................................................. 19 Figure 8: Extraction of Building Points(orange points). ............................................................. 20 Figure 9: Extraction of Wall Points (blue points). ..................................................................... 20 Figure 10: Detection of Opening Clusters (red points). .............................................................. 21 Figure 11: Organization of Opening Clusters into a grid. ........................................................... 22 Figure 12: Opening Clusters for non-homogenous floors (basically ground and upper floors). 22 Figure 13: Extraction of Opening Contours (green rectangles). ................................................. 23 Figure 14: Result from extraction of Opening Contours on the SIRADEL building.................. 23 Figure 15: Automatic post-processing adjustments. ................................................................... 24 Figure 16: Scenario 4.1: Red dots are the IR-UWB ToA node positions and the red numbers are their corresponding ID. Green triangles are Zigbee node positions and the green numbers are their corresponding ID. Blue dots are different Trolley positions. ................................ 27 Figure 17: Histograms representing the number of ToA used per evaluated position ............... 28 Figure 18: Histograms representing the number of RSS used per evaluated position ................ 28 Figure 19: Histograms representing the number of ToA and RSS used per evaluated position. 28 Figure 20: CDFs of positioning error comparison between ML and RGPA algorithms using IRUWB ToA. ........................................................................................................................... 28 Figure 21: CDFs of positioning error comparison between ML and RGPA algorithms using ZigBee RSS.......................................................................................................................... 28 Figure 22: CDFs of positioning error comparison between ML and RGPA algorithms using fusion of ToA and RSS LDPs. ............................................................................................. 29 Figure 23: Comparison of position estimation between ML, RGPA and RGPA with the hypothesis testing for 2 ToAs and 1 RSS. Both the ML and RGPA use the same 3 observables to perform the position estimation. RGPA with the hypothesis testing uses the RSS observable to choose between the 2 multi modal solutions that might appear. ........... 30 Figure 24: Error of positioning using RGPA with or without the hypothesis testing as a function of the measurement point. .................................................................................................... 31 Page 8 (73)
WHERE2
D4.6
Figure 25: Trolley route specified for algorithms. ...................................................................... 31 Figure 26: Original network and connectivity between nodes. ................................................... 32 Figure 27: Artificially formed fixed network with good connectivity. ....................................... 33 Figure 28: Approximation of the real distance from measured values. ...................................... 34 Figure 29: Values of standard deviation of distance error. ......................................................... 34 Figure 30: Analysis of fixed nodes links. .................................................................................... 35 Figure 31: ZigBee nodes connectivity. ....................................................................................... 35 Figure 32: RSSI values between node 30 and other nodes it is connected. ................................ 36 Figure 33: Median RSSI measurements values for fixed nodes links (Leith) and the deviation of RSSI values per link (Leith). ............................................................................................... 37 Figure 34: Errors of all per link measurements (left) and averaging over close distance values (right). .................................................................................................................................. 38 Figure 35: Error of the trolley localization with UWB technology............................................. 39 Figure 36: Error of the trolley localization with ZigBee technology. ......................................... 39 Figure 37: Cooperative Weighted Least Squares positioning algorithm at each MTu, u = 1…m.40 Figure 38: Distributed-EKF. ....................................................................................................... 41 Figure 39: Overall synopsis of the links selection algorithm performed by MT u at time stamp t based on CRLB indicators, where Ne(t) and Ns(t) stand for the sets of available and selected neighbours respectively. ......................................................................................... 42 Figure 40: Scenario 4.1 from PTIN. ............................................................................................ 43 Figure 41: In the first sub-scenario we use the mean measurement value per neighbour for each tested position (scenario 4.1). .............................................................................................. 43 Figure 42: In the second sub-scenario we use only one measurement value sample per neighbour for each tested position (scenario 4.1). ................................................................................ 44 Figure 43: Full cooperative location error using only ZigBee/RSS nodes. ................................. 45 Figure 44: Full cooperative location error using only UWB/TOA nodes. .................................. 45 Figure 45: Heterogeneous full cooperative vs links selection location error using both distributed EKF and WLS.................................................................................................... 46 Figure 46: Indoor environment of OTE Labs (1st floor).............................................................. 47 Figure 47: Home screen of the Where2 application for indoor positioning. ............................... 48 Figure 48: Instantiation of rssi_positioning2 database – successful insertion of RSSI fingerprinting information. .................................................................................................. 48 Figure 49: Instantiation of the Where2 application for indoor positioning. ................................ 49 Figure 50: Fingerprinting procedure. .......................................................................................... 50 Figure 51: PHP source code for identifying the “closest” record w.r.t. RSSI. ............................ 50 Page 9 (73)
WHERE2
D4.6
Figure 52: PHP source code for returning the estimated indoor position to the mobile terminal. ............................................................................................................................................. 51 Figure 53: Estimated indoor position vs. actual position. ........................................................... 51 Figure 54: Indoor topology. ........................................................................................................ 52 Figure 55: NDCM dashboard. ..................................................................................................... 53 Figure 56: Terminal2 logs before handover event ...................................................................... 53 Figure 57: Terminal2 is communicated the handover decision and associates to soekris3. ....... 54 Figure 58: “Meeting room” scenario. .......................................................................................... 54 Figure 59: PTIN Test bed. ........................................................................................................... 55 Figure 60: XML data example of one AP (APInfo). ................................................................... 55 Figure 61: List with the result of a scan for APs (Strength: RSSI in dBm; Network: SSID). .... 56 Figure 62: Map and floor plan displayed in outdoor and indoor environment, respectively. ..... 56 Figure 63: Example of POIs available. ....................................................................................... 57 Figure 64: Navigation with distance data and GPS-like arrow. .................................................. 58 Figure 65: Upcoming event. ........................................................................................................ 58 Figure 69: Impulse response. ...................................................................................................... 66 Figure 70: Individual Rays. ......................................................................................................... 67 Figure 71: FUNEMS 2013 - floor plan. ...................................................................................... 67 Figure 72: Application start – user’s position is obtained and mapped. ..................................... 68 Figure 73: POIs available. ........................................................................................................... 69 Figure 74: Information associated with an upcoming event. ...................................................... 69 Figure 75: Navigation towards the event location....................................................................... 70 Figure 76: Event information updated with an attendee’s location. ............................................ 70
Page 10 (73)
WHERE2
D4.6
List of Acronyms and Abbreviations
Term
Description
API
Application Programming Interface
CFO
Carrier Frequency Offset
COTS
Commercial Off The Shelf
ECDH
Elliptic Curve Diffie-Hellman
GT
Ground Truth
GTP
Ground Truth Points
GUI
Graphical User Interface
ICI
Inter Carrier Interference
ID
Identifier
LOS
Line Of Sight
MAC
Medium Access Control
MSK
Master Session Key
NDCM
Network Domain Cognitive Manager
NLOS
No Line Of Sight
OFDM
Orthogonal frequency division multiplex
P2P
Peer-to-Peer
PC
Personal Computer
PF
Particle Filter
PSS
Primary Synchronization Signal
RAT
Radio Access Technology
RF-FE
RF Front End
RSS
Receive Signal Strength
RSSI
Receive Signal Strength Indication
RTD
Round Trip Delay/ Round Trip Distance
SDL
Specification and Description Language
SNR
Signal to Noise Ratio
SSS
Secondary Synchronization Signal
UWB
Ultra Wide Band
VNA
Vector Network Analyser
Page 11 (73)
WHERE2
1
D4.6
Introduction
A measurement campaign was carried out during the WHERE2 project using the various platforms with the aim of obtaining reliable and consistent data to all evaluate test and integrate the various algorithms from the WP2. More information about this measurement campaign is detailed in D4.5 [1]. Section 2 of this report starts by presenting IT work on their WiFi Mobile platform which allows to establish secure cluster communications between nodes. Running on Android mobile phones, this protocol allows the platform to interchange the measurement data between nodes in a secure manner, which allows demonstrating is potential use on new services to establish secure communications on P2P connections. More details about its use in the measurement campaign can be found on the report about the measurement campaign - D4.5 [1]. Furthermore, it is also on this report’s scope the evaluation of the building’s opening detection system, which is able to extract the information from the 3D model representation of the building. The work developed on this stage contemplates its own set of data, as the measurement equipment was not possible to use in the PTIN’s environment due to travelling constrains. For this reason, the necessary data was collected by SIRADEL in France. Section 3 evaluates the various location algorithms, which come from WP2 and use the data provided by the measurement data within the PTIN’s environment detailed in D4.5 [1]. The algorithms integrate various technologies by using the different datasets available from the different platforms. The last section corresponds of the integration of the extracted location information with other systems to take benefit of the location information, either for communication purposes like OTE and UPM contributions or to use as a context provider like in the context platform from PTIN. At the end of the report, it is also introduced the work presented at FUNEMS’13, where the location information extraction is integrated with the context platform, to demonstrate the added value of the knowledge of the location information in one of the use cases of the project. The use of location as context information, allows enhancing the platform in terms of services, which it is able to provide to the users.
Page 12 (73)
WHERE2
D4.6
2 System Implementation 2.1
Android WiFi platform
This section describes the WHERE2 mobile application developed for the proof-of-concept of the WHERE2 Security Architecture for trustworthy cluster communications. The implementation followed the design guidelines achieved in WP3 and described in Deliverables 3.2 [2] and 3.5 [3]. Both Apple IOS and Windows Phone operating systems were initially considered for the application development mainly for their recognized support and documentation; unfortunately both operating systems were highly restrictive when considering the implementation of the clustering functionality. Peer-to-peer (P2P) support was only allowed via Bluetooth, which is equipment, distance and bandwidth restrictive (Apple IOS supports this via Game Kit framework). Devices were not allowed to create ad hoc networks (only the joining operation is possible) and the Personal Hotspot functionality only works when sharing a cellular connection - selected device will act as a hub, which was somewhat restrictive. With these limitations in mind the application was developed for Android phones since Android supports ad hoc networks and, more importantly, added support for P2P communications through the use of the Wi-Fi direct technology. This application programming interface (API) allows Android devices to connect directly to each other via IEEE 802.11 without an intermediate access point and with the full advantages of using IEEE 802.11 (transmission range and throughput). The API also allows applications to be written in Java and executed within a custom Java virtual machine, which presented an ideal develop/troubleshoot environment. The main Android packages, classes and APIs used by the application are listed in Table 1. Packages/Classes/APIs android.net.wifi.p2p android.content
android.net.NetworkInfo org.spongycastle
java.security
javax.crypto
java.net.Socket javax.crypto.spec android.location com.google.android.maps
Description Provides classes to create P2P connections with Wi-Fi Direct. Contains classes for accessing and publishing data on a device. It includes three main categories of APIs: Content sharing, Package management, Resource management A class that describes the status of a network interface. Provides a collection of APIs used in cryptography. Of main interest is the support for the Elliptic Curve Diffie-Hellman (ECDH) key agreement protocol. Provides an extensible cryptographic service provider infrastructure for using and defining services such as Certificates, Keys, KeyStores, MessageDigests, and Signatures. Provides the classes and interfaces for cryptographic applications implementing algorithms for key generation, encryption, decryption, or key agreement A class that provides a client-side TCP socket. Provides the classes and interfaces needed to specify keys and parameter for encryption Provides classes that define Android location-based and related services A package the provides interfaces and classes that allow applications to display and control a Google Map interface
Table 1: A subset of the most relevant Packages/Classes and APIs used in the android WHERE2 application. The Specification and Description Language (SDL) diagram for the Android WHERE2 application is given in Figure 1. The description follows. Page 13 (73)
WHERE2
D4.6 CLUSTERHEAD
PEER/CLUSTER MEMBER
1
1 Start Local WHERE2 service
every t seconds
Start Local WHERE2 service
android.net.wifi.p2p
2
every t seconds
Send and listen for WHERE2 beacons
3
No
New peers detected ?
android.net.wifi.p2p
2
Send and listen for WHERE2 beacons
3
No
Clusterhead detected ?
Yes
Yes
4
4 Connection to peer
Connection to clusterhead
android.net.wifi.p2p android.content android.net.NetworkInfo
WHERE2 Service Authentication
5
android.net.wifi.p2p android.content android.net.NetworkInfo
Fail
WHERE2 Service Authentication
5
Success
Fail
Success
6
6 Start ECDH procedure Computes Master Session Key (MSKCH-Ti)
Negotiate ECDH Computes Master Session Key (MSKCH-Ti)
(authenticated) org.spongycastle java.security
7
org.spongycastle java.security
7
Computes/derives shared/session key (KCH-Ti)
Computes/derives shared/session key (KCH-Ti)
javax.crypto
javax.crypto
8
8 Receive each cluster member’s data [Decrypt with KCH-Ti]
WHERE 2 positioning database
(secured)
Send location related data [Protect with KCH-Ti]
java.net.Socket java.security
9
re (secu
d)
java.net.Socket java.security
Compute location based on WHERE2 location algorithms WHERE2 specific
10
(secured)
Update/Query WHERE2 location database java.net.Socket java.security
11
11 Aggregate, disseminate and store cluster members position [Protect with KCH-Ti]
(secured)
Receive cluster member’s list and location [Decrypt with KCH-Ti]
java.net.Socket java.security
12
java.net.Socket java.security
12 Display/Update map with location of all cluster members
Display/Update map with location of all cluster members
com.google.android.maps
com.google.android.maps
Figure 1: SDL diagram for the android WHERE2 application.
1. The application (WHERE2 secure process) starts and advertises the WHERE2 service. At this point the user must choose a name for the terminal and optionally configure the map refreshing period and whether the terminal will act as a normal peer or as a clusterhead (see Figure 2.a and c). If the clusterhead role is not manually set in any of the peers, clusterhead functionality will be assigned automatically by the application; 2. WHERE2 terminals periodically broadcast and listen for beacons. The broadcasted beacon includes information of the owner and the WHERE2 service; 3. When WHERE2 beacons are received, the terminal updates and displays the list of discovered neighbouring peers to the user (see Figure 2.b). 4. Both the clusterhead and peer users can decide to whom to connect and both ends must agree for the connection to start. 5. A pre-shared key, hardcoded in the WHERE2 secure process, is used to perform terminal authentication during the first stage of the connection negotiation. If authentication fails the connection resets. Page 14 (73)
WHERE2
D4.6
6. At the second stage of the connection negotiation, a Master Session Key (MSK) is computed by both the clusterhead and the peer by using the Elliptic Curve DiffieHellman (ECDH) key agreement protocol. After the ECDH negotiation both the clusterhead and the terminal have the same key, known only to themselves. The use of ECDH allows the use of shorter keys (160 bit), hence less CPU expensive for equivalent security protection when compared to the original Diffie-Hellman exchange (768, 1024, 2048 bit key sizes) proposed in deliverables D3.2 [2] and D3.5 [3]. 7. To avoid unnecessary exposition of the MSK, both the clusterhead and peer derive a shared (or session) key from the MSK using the javax.crypto Android package. 8. After connection establishment and successful key computations, the peer (now a cluster member) sends location related data to the clusterhead. The data can reflect collected Received Signal Strength (RSS) measurements or any other information collected by the terminal. For proof-of-concept, the data used for the application evaluation consisted on the terminal’s GPS location information. The use of the session key enables data protection with authentication, integrity and confidentiality security services. 9. This step is used when the collected data does not directly reflect the cluster members’ location. In such scenario the clusterhead forwards the data to the WHERE2 location database for additional processing. 10. If the previous step has taken place, the clusterhead queries the database for the location results of a previous submission. If on the other hand the collected information reflects the cluster member’s location, the clusterhead updates/refreshes the database. 11. After collecting location information, the clusterhead sends the list of cluster members and correspondent location to each cluster member. Even though the application does not implement it, this last step could be optimized by broadcasting this information to all cluster members at the same time. However since each cluster member shares a different key with the clusterhead, the broadcast message could not use any of the computed keys and a new key to protect broadcast communications needs to be computed and distributed. Deliverable D3.5, section 3.3 [4], explains how this could be achieved. Each cluster member receives the update from the clusterhead and validates it using the shared session key. If the information is authentic and original, each cluster member stores it in its local database, or rejects it if otherwise. 12. Both clusterhead and cluster members use their local databases to overlay each cluster member position on a Google map (see Figure 2.d). This information is refreshed according to the timer defined in step 1. The application graphical user interface (GUI) is given in Figure 2. One additional functionality of this application is the capability to search and retrieve, from the database, the location of peers belonging to different clusters (see Figure 2.d). In order to make a cluster location public, the ‘Set Cluster Visible’ option (see Figure 2.c) must be set on the clusterhead. This will flag the WHERE2 database that this cluster location is public. Figure 2e) shows the location of a local and a remote cluster; Figure 2.f shows the details on the local cluster whilst Figure 2.g refers to the remote cluster.
Page 15 (73)
WHERE2
D4.6
a
b
c
d
e
f
g) Figure 2: Android WHERE2 application GUI
The WHERE2 application is publicly available from Google Play, at the following link: Page 16 (73)
WHERE2
D4.6
https://play.google.com/store/apps/details?id=com.app.where2 Figure 3 depicts WHERE2 homepage at the Google Play repository.
Figure 3 – WHERE2 homepage at the Google Play repository
2.2 Building’s openings detection An innovative methodology is proposed to automatically refine an outdoor 3D digital geo map data with digital representation of opening contours for facades fronting onto streets (e.g. windows, doors, etc.). The methodology is based on the processing of field measurements collected with a specific mobile mapping vehicle, which combines an advanced GPS, three lasers and five cameras installed on a platform mounted above its rooftop as illustrated in Figure 4. The detection of façade openings has many applications; one of them, when coupled with analysis of outdoor-indoor radio measurements, is the localization of terminals placed inside the buildings.
Page 17 (73)
WHERE2
D4.6
Figure 4: SIRADEL’s mobile mapping vehicle. The overall methodology is shown in Figure 5. Two input data are basically used: (1) a reference 3D digital geo map data including a 3D representation of building contours (so-called 3D building models) and (2) 3D laser points collected from field measurements with the specific mobile mapping vehicle. The first input is mainly constructed from a stereo-photogrammetry processing based on aerial images, through a proprietary process not available to the public.
3D building models 3D laser points (from field measurements)
Geo-referencing and alignment of input data
Laser points First classification
Laser points Second classification
(ground, building, wall)
(opening interior and frame points)
Clustering and opening contour computation
Integration of opening in3D building models
Figure 5: Overview of the methodology.
In the first step, both input data are geo-referenced in the same coordinate system. Figure 6 shows an example of such resulting alignment based on the facade of a house. The green line represents the 3D boundary of the house extracted from the reference digital geo map data. The dark points represent the aligned 3D laser data. These points only result from the field measurements collected with the mobile mapping vehicle at the successive positions illustrated by the red points. Google Earth’s street view images (not used in the methodology) are also depicted to illustrate the original façade’s structure, see Figure 6. Note that this example is used as reference in the remainder of this document in order to illustrate each step of the methodology.
Page 18 (73)
WHERE2
D4.6
Figure 6: Input data (left part) and street view image from Google Earth (right part).
Second step consists in classifying 3D laser points in three classes, i.e. ground, building and wall. Ground points typically lie on horizontal surfaces: the height and the orientation of the normal of each laser point are used to quickly classify them. Figure 7 shows the points classified as Ground Points in the sample data. Note that the computation of the normal of each laser point is done by a two-step process: (1) The covariance matrix of each laser point is computed considering neighbour points (within a certain radius that depends to the local density of collected points). (2) The normal is derived from the eigenvector of the smallest eigenvalue get from the covariance matrix.
Figure 7: Extraction of Ground Points (grey points).
Building points are identified using the 3D building models provided as input. For each non ground point, a 2D inclusion test is performed between the horizontal coordinates of laser points and the horizontal ground contour of each 3D building model. Points lying inside a contour are thereby classified as Building points and linked to the corresponding building by a specific ID. Page 19 (73)
WHERE2
D4.6
In order to take into account possible misalignments between laser points and 3D building models, the ground contour is dilated before the inclusion test. The amount of dilation is 1.5 m, which corresponds to the maximum misalignment. Figure 8 shows the points classified as Building Points in the sample data.
Figure 8: Extraction of Building Points(orange points).
Wall points basically lie in the vertical plane of the wall. Initial alignment between 3D building models and laser points is not sufficient, that is why it is used only as initialization in this step. We first create a set of points supposed to lie in the initial vertical planes of the 3D building models. These points are selected depending on the distance to walls and the comparison between both normal angles (walls and laser points). From this first set of points, an estimation of the plane parameters is then computed using a robust estimation method (RANSAC: RANdom Sample Consensus [5]). Lastly, laser points classified as Building points and lying in the computed planes are classified as Wall points. Remark that a distance threshold is defined to consider that laser points belong to the computed planes. This parameter (typically set at 0.15 m) is crucial to be able to detect an opening (like window) or a micro-structure (like a balcony) in the next step. Figure 9 shows the points classified as Wall Points in the sample data.
Figure 9: Extraction of Wall Points (blue points).
The detection of openings (or micro-structure) then consists in first making a further classification of the remaining Building points (orange points in Figure 9). In this document, only the detection of openings is addressed. An opening is basically composed of laser points that either passed through the wall (i.e. Interior Points) or lie on the opening frame (i.e. Frame Points). The detection of the Interior Points are based on the computation of the intersection points between the direct ray (from the laser and each reflecting point) and the vertical planes of walls computed in the previous step. If the intersection points are inside the building contour, then the laser points are classified as an Interior Points. The detection of the Frame Points is based on both local neighbourhood analysis of the density (laser points that have much fewer neighbours on one side may be linked to the presence of an edge, corner or an irregularity in the wall) and the comparison between the normal of laser points and the normal of the vertical Page 20 (73)
WHERE2
D4.6
planes of walls. Indeed, openings are often located slightly inside the wall and therefore their borders are orthogonal to the wall. A frame can be thus detected if the normal of the laser points are orthogonal to the normal of the walls. Figure 10 shows the laser points classified as either Interior Points or Frame Points in the sample data.
Figure 10: Detection of Opening Clusters (red points).
The obtained Interior Points and Frame Points are then organized into a grid by analysing their accumulation in vertical and horizontal axis on each façade. All points included in the same cell of the grid are then gather into the same Cluster. A cluster, in this context, is a set of close laser points. The objective is to identify the subsets of laser points that represent the same physical/real opening. As an example, Figure 11 shows the histograms of accumulation in vertical and horizontal axis from the sample data. Remark that these histograms have been filtered out to remove noise and keep only significant local maximums and minimums. The grid is then computed by detection of local minimum and maximum intervals. The Figure 11 illustrates respectively the vertical (1) and horizontal (2) separation lines obtained as well as the combined results.
Page 21 (73)
WHERE2
D4.6
(1) Vertical accumulation and derived line
(2) Horizontal accumulation and derived line
Combined result
Figure 11: Organization of Opening Clusters into a grid.
Openings often differ (in size and number) between the ground floor and upper floors due to the presence of doors, entrances or storefronts. Therefore, after the computation of horizontal accumulations, we identify the ground floor as the first local maxima and use it to separate the computation of vertical accumulations for the ground floor and upper floors. Figure 13 shows an example where the ground floor and the upper floor have different opening structure.
Figure 12: Opening Clusters for non-homogenous floors (basically ground and upper floors).
Page 22 (73)
WHERE2
D4.6
In a final step, the vertical bounding box of each Cluster is computed and related to an individual opening as illustrated in Figure 13. Another result obtained from the SIRADEL building is illustrated in Figure 14.
Figure 13: Extraction of Opening Contours (green rectangles).
(a) Picture of the facade
(b) Extraction of Opening Contour
Figure 14: Result from extraction of Opening Contours on the SIRADEL building.
It has been observed that most of the openings may be detected with good accuracy with this methodology. However, it remains sensitive to quality of input data and notably to the density of the laser points. Moreover, the presence of occlusions between the street and the façade during field measurements (such as trees, balconies, etc.) or closed shutters may lead to masking effects of openings and thus to the impossibility to accurately detect them with the classical methodology. One investigated approach to overcome this limitation is to further analysis the accumulation of opening in order to detect possible symmetry or repetition along the façade. The methodology consists in post-processing the data in order to automatically add possible missing openings or to equalize their estimate dimensions. The creation of missing openings basically assumes that all cells of the computed grid must contain an opening. An a priori missing opening is thus created inside each empty cell. The position and size of the added opening is derived from the openings detected in the same row of the grid. In a similar way, an equalization process may be performed to correct size of openings wrongly estimated. Figure 15 shows the result of these two post-processing steps. Another complementary approach to solve this issue would be to combine laser data and image processing (indeed images of the façades are collected by the same mobile mapping vehicle during measurements). This second approach will be investigated in a near future.
Page 23 (73)
WHERE2
D4.6
(a) Creation of missing openings
(b) Equalization of openings size.
Figure 15: Automatic post-processing adjustments.
This complete methodology has been applied on the SIRADEL building; the result was used in WP2 T2.3 investigations for a localization method based on analysis of the indoor-outdoor radio environment [6]. The principles of the proposed localization method are as follows. First, we consider a fixed indoor terminal (an Access Point or a static User Equipment) to be localized. We measured then the signal emitted by this indoor terminal with a multi-antenna terminal along an outdoor trajectory to estimate the indoor/outdoor channel. During this step, we assume an exact knowledge of the outdoor terminal location along the trajectory (i.e. using a terminal equipped with a precise GPS system). In a third step, we extract and track the radio channel clusters along the whole trajectory in order to detect the “bright spots”, which are related to specific elements of the environment and, in particular, to window frames. Finally, we use the “bright spots” location and their related cluster properties (mean delay and mean angle-ofdeparture statistics) to get an estimate location of the indoor terminal. We obtained a good accuracy in the localization of bright points, window frames and indoor terminal by simulation using this technique. We expect that combining such cluster/“bright spots” detection method with an enriched geo map data (already including openings) will compensate for errors in delay and angle estimates. Full demonstration of this innovative technique is not yet achieved, but major elements have been elaborated. We can nevertheless already claim that Simultaneous Localization And Mapping (SLAM) technique based on both radio and laser data extraction seems really promising. It allows for the localization of indoor terminals from only outdoor sounding and without any a priori knowledge of the building interior and WLAN/femto-cell installation. One envisaged perspective of this work is to equip the mobile mapping vehicle with a wideband multi-antenna system, which is able to scan cellular and indoor networks (e.g. 4G plus WiFi) and estimate the indoor/outdoor radio channel. This system will be coupled with the advanced GPS that is already installed on the mobile mapping vehicle. A jointly processing of the collected radio, image and laser data with a SLAM algorithm might lead to (1) further refine the geo map data and (2) localize indoor fixed terminals (and APs in particular) together. A map of indoor APs could be thus derived, which could help in the global localization of the indoor terminals attached to them.
Page 24 (73)
WHERE2
D4.6
Another direct application of the opening detection is to automatically refine the 3D geographical map data commonly used by deterministic propagation models. Accuracy of the channel realizations, in particular for outdoor/indoor radio links, will be greatly improved accordingly. Remark that we already started the investigations on this application thanks to the novel site-specific indoor-to-outdoor model we elaborated in WP1 D1.8 [7].
Page 25 (73)
WHERE2
3
D4.6
System Evaluation
In the following subsections different evaluations of the data acquired in PTIN measurement campaign described in D4.5 [1] are presented.
3.1
Localization algorithm evaluation using PTIN measurements
This section focuses on the evaluation of two heterogeneous localization approaches developed by UR1 and described in deliverable D2.4: The robust geometric positioning algorithm (RGPA) and a method based on a hypothesis testing [8]. Both methods are evaluated on the scenario 4.1, where a moving Trolley collects observables from fixed nodes using Ultra Wide Band (UWB) and/or ZigBee technologies. A first section reminds the used parameters models and the considered scenario. The two following sections are dedicated to the evaluation of the algorithms. The proposed RGPA algorithm provides quite satisfying performances using UWB observables alone or in addition of RSSI observables. Those performances are slightly inferior when RGPA is feed only with RSSI observables. The hypothesis method has been applied on a situation where 2 ToA observables and a single RSS was available. In that situation, the method has shown its interest against a ML approach, by reducing the positioning RMSE. 3.1.1 Description of the used model parameters and scenario In order to be able to feed the localization algorithms, the parameters of the pathloss model for the ZigBee RSS nodes and the error distance model for the IR-UWB ToA nodes have to be estimated. The data acquired during scenario 2.1 described in described in D4.5 [1] has been chosen for that extraction. The model chosen for the Zigbee nodes is a log-normal shadowing model : (1) From the aggregation of all the RSS values between all the static ZigBee nodes and the ZigBee coordinator on the Trolley, the path loss model parameters presented in Table 2 have been extracted.
-50.21
2.21
5.73
Table 2: ZigBee path loss models extracted for scenario 2.1.
Using a similar procedure on the IR-UWB, matching the measured distances to the true distances, and assuming a Gaussian model for the error distribution, it is possible to derive a ranging error model. The obtained values of the model are presented in Table 3 [9]. mean ranging error (m)
Standard deviation (m)
0.46
2.52
Table 3: UWB ToA ranging model extracted for scenario 2.1.
represents the positions of IR-UWB and ZigBee nodes of scenario 4.1. In addition, the different positions of the Trolley (a.k.a measurement points) are representedby the blue dots. A more detail description of all scenarios, data acquired and location information is described in of D4.5 [1]. The algorithms are evaluated for all those positions. Figure 16
Page 26 (73)
WHERE2
D4.6
Figure 16: Scenario 4.1: Red dots are the IR-UWB ToA node positions and the red numbers are their corresponding ID. Green triangles are Zigbee node positions and the green numbers are their corresponding ID. Blue dots are different Trolley positions.
3.1.2 Performances Evaluation of RGPA In this section, the RGPA localization algorithm is applied on the measured data and compared to an heterogeneous maximum likelihood (ML) approximation algorithm initialized with a random value [10]. For that purpose, the models extracted in section 3.1.1 and the dataset from scenario 4.1 are considered. Both ML and RGPA algorithms are compared with the help of cumulative density functions (CDF) of positioning error using 3 different configurations: • IR-UWB ToA observables (Figure 20) • Zigbee RSS observables (Figure 21) • Heterogeneous configuration using Zigbee RSS and IR-UWB ToA observables (Figure 22) For each of this 3 configurations, the number of observable depends on the position of the trolley. However, each available observable of a given LDP at a given position is used to perform the position estimation. Figure 17, Figure 18 and Figure 19 show the percentage of measures involving a given number of LDP. For instance, it can be observed in Figure 17 that 30% of the estimated position have been estimated using only 4 ToAs, or in Figure 18 that % of estimated position have been realized with RSS.
Page 27 (73)
WHERE2
Figure 17: Histograms representing the number of ToA used per evaluated position
D4.6
Figure 18: Histograms representing the number of RSS used per evaluated position
Figure 19: Histograms representing the number of ToA and RSS used per evaluated position.
Figure 20: CDFs of positioning error comparison between ML and RGPA algorithms using IR-UWB ToA.
Figure 21: CDFs of positioning error comparison between ML and RGPA algorithms using ZigBee RSS.
Page 28 (73)
WHERE2
D4.6
Figure 22: CDFs of positioning error comparison between ML and RGPA algorithms using fusion of ToA and RSS LDPs. Figure 20, represents the CDFs of positioning error for both RGPA and ML using only ToA observables. It can be observed that RGPA outperforms the ML in the regime of low errors. Thus, 90% of the positions are estimated with an error less than 3 meters using RGPA whereas the ML achieves an error less than meters in that situation. However, for few estimated positions with a large error, the ML prevails on the RGPA.
On contrary, considering the comparison of CDFs of positioning error using only RSS observables on Figure 21, the ML outperforms the RGPA approach. This result can be partly explained by the difficulties of RGPA to bound a RSS constraint. Indeed the RSS constraint is built with the help of a model. That model converts a received power information into a distance which helps to limit a space region. Typically, when several RSS constraints are used, the box resulting of the merge of all RSS geometric boxes, bounds a large area. As a consequence, the estimation of the position can be less accurate than with a ML solution. That trend is also confirmed in heterogeneous case where RSS are used in addition to ToA observable, as it can be observed in Figure 22. If the RGPA globally outperforms the ML algorithm, it seems that it don’t really take advantage of the extra RSS information. That result is confirmed by considering the summarized performances in terms of RMSE and standard deviation presented in Table 4. It can be observed that the RGPA algorithm performs as well with or without RSS LDPs in terms of RMSE. That behavior can be explained by difficulties of RGPA to box the RSS constraints. Hence, the constraint box of the RSS observables don’t help to restrict the area where the position is estimated. mean positioning error (m) std of positioning error (m) Algorithm ML LDP RSS 3.27 ToA 2.13 RSS + ToA 1.93
RGPA
ML
RGPA
4.01 1.64 1.64
2.63 1.31 1.56
2.96 1.43 1.52
Table 4: Statistical positioning error for scenario 4.1
3.1.3 Performances Evaluation of the Hypothesis Testing method. In this section, the localization based on the hypothesis testing method described in deliverable D2.4 is applied on the scenario 4.1 described in D4.5 [1]. One of the difficulties encountered in this method rely on the questionable reliability of the path loss shadowing model used for the Page 29 (73)
WHERE2
D4.6
RSS. Indeed, it has been seen, that the power information is used to decide between multi modal solutions. The quality of this decision is directly related to the quality of the model used for the power information. As mentioned before in section 3.1.1, obtaining the parameters of a pathloss shadowing model is not an easy task due to different kind of observable variability. In those conditions, the method based on hypothesis testing has shown their limits, and has performed worst that the classic RGPA. Hence, in this section, the parameters of the path loss shadowing model have been extracted on the same scenario 4.1 instead of scenario 2.1. Assuming that point that we are now relying on a very specific and thus favorable model, the concept of the method is proven in the following. shows a comparison between the ML method, the RGPA method and the RGPA used with the hypothesis testing method (RGPA HT). The simulation has been run on the 150 measurement points of scenario 4 using 2 ToA observables with the best GDOP and choosing the RSS observable with the highest value. All algorithms are fed with the same observables’ parameters. First of all, it is noticeable that both RGPA and RGPA HT prevail on ML for positioning errors under 2 m. In that region, the RGPA HT method starts to differentiate to the RGPA from 1m of positioning error. Indeed, it is very likely that estimated positions obtained with a precision of 1m are obtained with the help of 2 very precise ToAs in situations where no multi modal solutions appear. For positioning error above 3 m, ML prevail or performs as well that RGPA or RGPA HT. However, RGPA HT reduces the amount of large errors compared to RGPA. That limitation of large error is also observable on Figure 24 comparing the positioning errors of RGPA and RGPA HT for each measurement points. The cases where the positioning errors of RGPA HT are higher than those of RGPA correspond to a false decision on the ToA area. As it can be observed in Table 5, the RGPA HT benefits of the ToA accuracy, providing the lower mean error of positioning compared to both RGPA and ML. It is noticeable that RGPA HT has a higher standard deviation than the positioning error than ML. This can be explained by the method itself. An error using RGPA HT corresponds to a false detection which is equivalent to select the wrong region. That wrong region can be distant from the ground truth positions and thus cause a relative high error. Figure 23
Figure 23: Comparison of position estimation between ML, RGPA and RGPA with the hypothesis testing for 2 ToAs and 1 RSS. Both the ML and RGPA use the same 3 observables to perform the position estimation. RGPA with the hypothesis testing uses the RSS observable to choose between the 2 multi modal solutions that might appear.
Page 30 (73)
WHERE2
D4.6
Figure 24: Error of positioning using RGPA with or without the hypothesis testing as a function of the measurement point.
Method
RMSE (m)
Standard deviation of positioning error (m)
ML RGPA RGPA HT
2.10 1.85 1.70
1.98 3.14 2.36
Table 5 Statistical positioning error RGPA vs RGPA HT
3.2
Performance of message passing algorithm with PTIN measurements
The performance of message passing algorithm is tested with the data obtained from Scenario 4.1 of PTIN measurement campaign described in D4.5 [1] by estimating the trolley positions along the route shown in Figure 25 with green crosses. The positions of UWB reference nodes are also shown in this figure.
Figure 25: Trolley route specified for algorithms.
In order to obtain the distance estimations all link measurements gathered by the trolley obtained in Scenario 4.1 are considered. As it was observed that the statistics of links with trolley and with only fixed nodes might differ, the averaged value is used as representative for algorithm testing. UPM analysed two systems: UWB and ZigBee and their analysis will be performed, together with simulation results.
Page 31 (73)
WHERE2 3.2.1
D4.6
UWB system – CEA measurements
3.2.1.1 Connectivity with trolley on specific route The information about fixed nodes links collected by trolley on the specified route results on the connectivity graph between fixed nodes, shown in Figure 26. The existing links are written on the right of the figure. It should be recalled that algorithms can estimate their positions if the number of links per node is at least 3. Node-by–node analysis shows that -
-
Node 43 is connected only to node 41. Trolley is not connected to it in the whole route and this node will not be considered being part of the network Nodes that have 3 or more neighbours: 15, 41, 45 and 54 can be located with localization algorithms Nodes that have 2 neighbours need at least one trolley position to be added as part of the fixed network in order to be able to localize them. These nodes are: 58, 60, 61 and 62. Nodes 40, 42 and 55 form a “closed network”, and although all of them have 3 neighbours, the fact that node 45 and 55 are aligned makes the localization task hard. Therefore, and additional position with good connectivity to these nodes should be added (not aligned with the 45 and 55).
Figure 26: Original network and connectivity between nodes.
The analysis of candidates for “new” fixed nodes (positions of the trolley on a specific route) that could be incorporated into the network consisted in a search for positions that is well connected (with sufficient number of measurements) with nodes 58, 60, 61, 62 and an additional node connected to 40, 42 and 55. In Table 6, Table 7 and Table 8 are resumed the links between trolley at positions 28, 40 and 104 (the positions that are chosen as part of the fixed network) and fixed nodes as well as the number of measurements available for a given link. Node1
15
20
20
20
20
20
20
Node2
20
40
41
45
58
60
61
Nb of measurements
70
1
101
105
111
105
119
Table 6: Existing links and number of measurements per link at trolley position 28.
Page 32 (73)
WHERE2
D4.6 Node1
20
20
20
Node2
45
54
62
Nb of measurements
87
85
89
Table 7: Existing links and number of measurements per link at trolley position 40.
Node1
20
20
20
20
Node2
40
41
42
55
Nb of measurements
83
90
86
89
Table 8: Existing links and number of measurements per link at trolley position 104.
The newly formed “fixed” network with good connectivity is shown in Figure 27.
Figure 27: Artificially formed fixed network with good connectivity.
The algorithms will be tested in the new network scenario with positions of the trolley in the specific route (expect on positions already included in newly formed fixed network). 3.2.1.2 UWB distance error model UWB distance approximation from all data from scenario 4.1 (to be applied on algorithms on the specified route). Only links with 50 or more measurements were included. The estimated distances, together with the approximation fit are shown in the Figure 28. The trolley to fixed and vice versa measurements were used as there are more links for this analysis (in the case of fixed to fixed links, there would be more measurements). The approximation that is extracted form data is that the distance estimation, dˆ r can be obtained from measurements d est according to the linear approximation:
dˆr .9401dest 0.1441
Page 33 (73)
WHERE2
D4.6
Figure 28: Approximation of the real distance from measured values.
If the error is modelled with Gaussian distribution, its deviation is shown in Figure 29. Both mean and median values are shown. Those values, corrected by the factor .9401 are 0.3631m (mean) and 0.2302m (median) and could be considered independent of the distance between nodes.
Figure 29: Values of standard deviation of distance error.
It should be noted that this analysis is done with trolley to fixed nodes links. If fixed to fixed node links are analysed, the correction equation would be
dˆr .9159dest 0.286 And the mean and median values of standard deviation 0.8385m (mean) and 0.4864m (median). The figures showing approximation and deviation values are shown in Figure 30.
Page 34 (73)
WHERE2
D4.6
Figure 30: Analysis of fixed nodes links.
3.2.2 ZigBee system – ACORDE measurements The first pre-processing that was done with ZigBee measurements consisted in elimination of links with RSSI value equal to -81dB, as it is the sensitivity level and the dispersion of distances associated with it is very large. 3.2.2.1 Connectivity with trolley on specific route Nodes that are connected in ZigBee network when trolley is in the specified route are shown in Figure 31.
Figure 31: ZigBee nodes connectivity.
It can be observed that the network is well connected as all nodes, except node 48 have at least 3 neighbours, meaning it can be located with message passing algorithm. 3.2.2.2
ZigBee distance error model
Per Link RSSI analysis If the RSSI values between pair of nodes are grouped, the important dispersion of measured RSSI can be observed, as shown in Figure where RSSI measurements in all links with node 30 are shown.
Page 35 (73)
WHERE2
D4.6
Figure 32: RSSI values between node 30 and other nodes it is connected.
Median RSSI values per link are resumed in Table. In bold are the values with RSSI at bound level, -81dB. These nodes are not considered to be connected. Link
30 38
30 39
30 46
30 47
30 48
30 49
38 39
38 47
38 49
39 46
39 47
39 49
46 38
46 47
46 48
46 49
47 48
47 49
48 39
48 49
RSSI -62 -60 -72 -78 -76 -61 -78 -81 -62 -81 -77 -62 -81 -81 -67 -63 -81 -63 -81 -81 Table 9: Median RSSI values per fixed node links.
Page 36 (73)
WHERE2
D4.6
It can be observed that the variations of RSSI values per link are very large (for example, between nodes 30 and 38 the variation is even 20dB), and some processing of these values is needed in order to intend to obtain single value per link that could be used for distance estimation and message passing algorithm. Parameter extraction For RSSI parameters estimation the global parameters are obtained by averaging all links, as we will assume that none of the nodes knows its position and therefore cannot take into account its specific propagation parameters. As was shown, there are important fluctuations of RSSI level per link; therefore, the preprocessing was performed, eliminating 10% of worst RSSI levels, as we assume those degradations appeared when people were walking or some other temporal interference source appeared. Afterwards, the median value per link is considered as the reference for parameters estimation. Beside, the value that are separated more than 3 times standard deviation of data with respect to the fitting curve, were discarded and the second estimation, without those values, was taken for the valid. With this analysis, the lognormal approximation value was PL0=-43.7 and np=2.46. The standard deviation of valid RSSI values per link (excluding the worst RSSI levels) is 5.65dB. Its distribution can be observed on the right side of the Figure 33. It can be observed that deviation can be up to 11dB, that is very high value.
Figure 33: Median RSSI measurements values for fixed nodes links (Leith) and the deviation of RSSI values per link (Leith).
In Scenario 2.1, the estimation of this case obtained by Mohamed (IETR) is PL 0=-49.31 and np=2.25, similar to the ones extracted by UPM. Error model is obtained by finding the relation between true and estimated distance and making a linear approximation of distance estimation per link (eliminating 10% of highest and lowest RSSI values)
Page 37 (73)
WHERE2
D4.6
Figure 34: Errors of all per link measurements (left) and averaging over close distance values (right).
The error model is proportional to real distance (d) and can be approximated with
0.7597 d 0.4679 This curve fit is obtained by minimizing the error for distances lower than 4m (red line). If the error is minimized for distances below 10m, the error model is shown with black line and described by equation:
0.6533d 1.0824 3.2.3 Simulation results Localization with UWB is possible as walls and obstacles result in no connection between links, and only LOS links are possible. With ZigBee, connection is established even in non-LOS conditions, but the estimated distance between nodes has high error. Besides, with ZigBee, the large RSSI fluctuations appear (for unknown reasons). 3.2.3.1 UWB The CDF of the localization error of the trolley positions is shown in Figure 35. It can be observed that the best estimation is obtained with model with higher error variance (1.19), and using the approximation of the distance from the measured
dˆr .9401dest 0.1441 The error in this case is below 2m in 80% of the trolley positions, meaning that the correct localization can be achieved.
Page 38 (73)
WHERE2
D4.6
Figure 35: Error of the trolley localization with UWB technology.
3.2.3.2 ZigBee In the case of ZigBee, RSSI values lead to important errors in the distance estimations and the localization cannot be performed viably (the error can reach unacceptable values of 20m). This can be observed in CDF curve of the trolley position estimation error, showed in Figure 36.
Figure 36: Error of the trolley localization with ZigBee technology.
3.3
Heterogeneous and Cooperative Positioning with Links Selection Applied to PTIN Measurements
In this report, real field indoor measurements collected in a jointly cooperative and heterogeneous wireless context are post-processed to evaluate different localization algorithms and to verify the efficiency of the links selection algorithm inspired by the initial proposal made in [11] and [12], and already presented in details in [13]. We consider extracting the data related to scenario 4.1, according to the WP4 nomenclature reported in D4.5 [9]. More particularly, we base our results on RSSI measurements issued by ACO's Zigbee platforms on the one hand and RT-TOF measurements issued by CEA's IR-UWB platforms on the other hand. Both platforms have been developed in the frame of WP4. In sections 3.2 and 3.3 we verify first the positioning performance under full cooperation for each kind of technology in a stand-alone way. In section 3.4, we analyse heterogeneous positioning both in fully cooperative configurations or under links selection (i.e. applying selective CRLB-based cooperation). Page 39 (73)
WHERE2 3.3.1 3.3.1.1
D4.6
Tested Algorithms Weighted Least Squares Positioning Algorithm
The cooperative Weighted Least Squares (WLS) positioning algorithm already presented in [14] and [13] is represented in Figure 37 where j N e (u ) denotes that j belongs to u's neighbourhood, j being either a MT or an AN (i.e. with xˆ j x j and yˆ j y j in the latter case, where x j , y j are the true coordinates and xˆ j , yˆ j are the
estimated coordinates). In the cooperative WLS, each MT estimates its own current position relying on all the available range measurements (i.e. MT-to-ANs and MT-toMTs) and on the 1-hop neighbours’ estimated locations around through optimization (i.e. viewing already positioned neighbouring MTs as virtual anchors). The weights applied to the quadratic cost function to be optimized are set as w u, j 1 / d u, j if d u , j is the estimated distance between MT u and its neighbour j. In the initial step, each MT is preliminarily positioned with respect to real anchors through non-cooperative WLS, whenever its connectivity allows it.
Figure 37: Cooperative Weighted Least Squares positioning algorithm at each MTu, u = 1…m.
3.3.1.2
Decentralized Extended Kalman Tracking Filter
The distributed and asynchronous EKF proposed in [15] takes into account the reliability of the estimated positions of neighbouring MTs (through the broadcast of estimated states covariance matrices). Figure 38 shows the detailed synopsis of the tracking EKF solution as a function of the time step t = 1…Time. Each mobile terminal MTu, u = 1…m locally updates its own estimated 2D location and speed as follows:
Sˆ ut -1 xˆ ut -1 , yˆ ut -1 , vˆ tx-u1 , vˆ tyu1
~d j 1...N , the set of successful cooperative range measurements t u, j
, the estimated state vector at t-1;
t s
with respect to neighbouring mobiles serving as virtual anchors;
The set of N st estimated locations and speeds associated with neighbouring mobiles serving as virtual anchors (e.g. transmitted in the ranging packets issued from MTj), i.e. Sˆ tj1 j 1...N st along with the related covariance
matrices C tj1 j 1...N st
~ The set d u,t i i 1...n / i N e (u) of successful non-cooperative range measurements with respect to neighbouring anchors.
Page 40 (73)
WHERE2
D4.6
Figure 38: Distributed-EKF.
Based on empirical observations while emulating plausible mobile trajectories out of the grid of static tested positions during the WP4 measurement campaign, we assume the following uncertainties concerning the diagonal terms of the state noise covariance matrix. 2 v (m.s 1 ) v (m.s 1 ) a (m.s 2 ) a (m.s ) x
y
0.8828
0.6702
x
0.2207
y
0.1675
Table 10 The uncertainties in the distributed EKF
The adopted mobility model is Position-Velocity-Acceleration mobility model and the t is equal to 500ms. The parameters are computed out of adjacent tested MT positions of the WP4 measurement grid. Now, we assume that SIZEx and SIZEy represent the dimensions of the scene, respectively along the x and y axes, and that Vmax and amax represent respectively the maximum tolerated absolute 2D velocity and acceleration of the MT. Then, so as to account for the uncertainty from scratch, the initial filter state is randomly drawn as follows: SIZE x SIZE x c* 2 6 SIZE y SIZE y y u0 c* 2 6 V V x0 c * max 3 (1) Vmax 0 Vy c * 3 a a x0 c * max 3 a a 0y c * max 3 ,where c is a centred Gaussian random variable with unitary variance. xu0
3.3.1.3
Links Selection Algorithm
The core selection algorithm, which relies on a CRLB-based indicator (see described in [11].
Figure 39),
is
Page 41 (73)
WHERE2
D4.6
For the results obtained in this report concerning the links selection algorithm, we select 4 neighbours among all available (UWB + ZigBee) neighbors.
Figure 39: Overall synopsis of the links selection algorithm performed by MT u at time stamp t based on CRLB indicators, where Ne(t) and Ns(t) stand for the sets of available and selected neighbours respectively.
3.3.2
Measurement Post-processing
In this section, based on the realistic range measurements and real connectivity profiles given from the WP4 measurement campaign carried out at PTIN premises described in D4.5 [1], the previous positioning, tracking and selection algorithms have been applied and evaluated, along with a basic ranging intermediary step. 3.3.2.1
Scenario and Mobility Description
Aiming to evaluate the P2P cooperation with real measurements we used scenario 4.1, where a multi-standard mobile MT endowed with ZigBee and IR-UWB devices, moves in the different areas of the PTIN environment where 6 ZigBee fixed nodes and 11 UWB fixed nodes (anchors) and 2 other mobile nodes (one is a UWB node only and one is multi-Rat) are disseminated (see Figure 41). The measurements are performed at stationary positions. For each position several time-stamped measurements have been collected. Based on this WP4 measurement scenario, we consider two different ways to emulate mobility and/or measurement processing. In the first scenario (see Figure 41), for each tested MT position, we consider using the mean of the available measurement values for each connected neighbour (computed over the whole set of consecutive measurements collected in this position) for all the links with respect to 1-hop neighbours. In other words we consider favourable quasi-static positioning with redundant measurements and averaging. The second one (see Figure 42) uses one single time-stamped measurement value per link per occupied position, hence emulating Page 42 (73)
WHERE2
D4.6
realistic mobility. 3.3.2.2
Zigbee/RSS Measurement
In this section, scenario 4.1 is post-processed in order to evaluate the performances of the cooperative WLS and the distributed EKF algorithms using only Zigbee measurements, see Figure 40, Figure 41 and Figure 42.
Figure 40: Scenario 4.1 from PTIN.
Figure 41: In the first sub-scenario we use the mean measurement value per neighbour for each tested position (scenario 4.1).
Page 43 (73)
WHERE2
D4.6
Figure 42: In the second sub-scenario we use only one measurement value sample per neighbour for each tested position (scenario 4.1).
The used global parameters extracted from [1] are reported in Table 11. p sh (dB) RSS0 (dB) -49.13
2.25
7.71
Table 11: Zigbee path loss and shadowing global model parameters
By matching the estimated distances to the true distances, the derived ranging error model with the RSSI-base range estimator [16] for sub-scenario 1 is reported in Table 12. Mean ranging error (m) 1.0580
Standard deviation (m) 4.9512
Table 12: Zigbee RSS ranging model using only one RSS sample for each neighbour.
It has been observed that the RSSI measurements remain adversely constant over timestamps for a rather large number of the MTs' neighbours in each occupied position. Thus only the second sub-scenario is considered within the RSSI ZigBee homogeneous case, that is to say, we use only one single RSSI measurement per position per connected neighbour but we do not apply the averaging procedure of sub-scenario 1. In the following, considering that the mean ranging error can not be neglected, we consider compensating systematically the average bias (by 1m, according to Table 12) out of all the obtained range estimates before applying positioning. In Figure 43, we present the Cumulative Density Function (CDF) of the location error obtained with both the distributed EKF and the cooperative WLS. RSSI values lead to important errors in the localisation, which make it hardly reliable for standard navigation applications in particular when using the WLS algorithm. It seems obvious also, that the distributed EKF outperforms the WLS algorithm.
Page 44 (73)
WHERE2
D4.6
(a) Based on WLS
(b) Based on distributed EKF
Figure 43: Full cooperative location error using only ZigBee/RSS nodes.
3.3.2.3
UWB/TOA Measurement
In this section, scenario 4.1 is post-processed in order to evaluate WLS and EKF localization algorithms using only UWB measurements. By matching the estimated distances with the true distances, we derive the ranging error model for the two sub-scenarios (see Table 13 and Table 14). Mean ranging error (m) 0.80
Standard deviation (m) 1.69
Table 13: Ranging model for UWB based on one distance sample per neighbour.
Similarly to the ZigBee, we consider compensating systematically the average bias out of all the obtained range estimates before applying positioning. In Figure 44, we present the CDF of the location error obtained with both the distributed EKF and the cooperative WLS. For the UWB nodes we used the mean of the estimated distances and one distance sample for each neighbour to compute the MT position. We can notice that there is some refinement when using the distributed EKF instead of the WLS. Furthermore, the gain from averaging the measurements per occupied position is noticeable mostly with WLS, or even purely neglected in the EKF case, likely due to the fact that the gain on ranging (i.e. before applying tracking/positioning) is also limited, and uncertainties on the assumed mobility model may tend to dominate in the EKF case.
(a) Based on WLS
(b) Based on distributed EKF
Figure 44: Full cooperative location error using only UWB/TOA nodes.
Page 45 (73)
WHERE2 3.3.2.4
D4.6
Heterogeneous Positioning
In this section, scenario 4.1 is post-processed in order to evaluate WLS and EKF localization algorithms using both ZigBee and UWB measurements under full cooperation or links selection. In Figure 45, we present the CDF of the location error. Leaving aside the comparison between the performances of different algorithms WLS or distributed EKF, if we compare the links selection to the full cooperation, the difference between both approaches remains minimum in the most favourable location error regime, or even beneficial after link selection in the worst case error regime, especially with the WLS algorithm (likely due to the fact that EKF naturally filters out measurement outliers, making the full cooperative scheme less sensitive than WLS to the most penalizing input measurements).
(a) Based on WLS
(b) Based on distributed EKF
Figure 45: Heterogeneous full cooperative vs links selection location error using both distributed EKF and WLS.
Now if the performances are almost equivalent, it remains to put in balance the pros and cons of the links selection over the proposed algorithm. Indeed, if the number of neighbours participating in positioning is reduced, this is not the case of the number of neighbours’ combination tested that is up to 10. And also we have to keep in mind that for each combination the equivalent heterogeneous CRLB have to be computed. Obviously by reducing the number of neighbours participating in positioning, we are reducing energy consumption but not the computational complexity. Mean ranging error (m) 0.69
Standard deviation (m) 1.25
Table 14: Ranging model for UWB based on mean distances per neighbour.
Finally, it is worth noting that heterogeneous schemes (even under links selection) are mostly valuable and competitive in comparison with a homogeneous Zigbee case, though outperformed by the fully cooperative homogeneous UWB case. This is due to the much larger imprecision of the additional RSSI measurements integrated in the heterogeneous problem. Thus one recommendation would be to rely primarily on UWB links and TOA measurements whenever present/sufficient in a given environment, and possibly to timely complement with additional NB RSSI measurements whenever needed, following a heterogeneous approach uniquely under links selection.
Page 46 (73)
WHERE2
4 4.1
D4.6
Realisation Scenarios
Additional scenarios that the ones described in D4.5 [1] have been tested in order to evaluate different algorithms defined and implemented during the Where2 project. Amongst the following work is the integration of the extracted location information with different systems to provide new and enhanced solutions using location information. Such use can be manifest in mobile communications, like for example the location aided handover decision process from OTE, or in context aware applications using the location information as another context provider, which allows providing more accurate information and better targeted taking into account the users location. Furthermore, in this section it is also addressed the work related with communications throughput evaluation from UPM, which to be tested in a realistic environment requires the use of a ray-tracing tool presented in the report. Its necessary configuration steps are detailed for future use, either from other partners or third parties not necessary related with the project itself.
4.1.1 Indoor positioning and horizontal handover employing RSSI fingerprinting in OTE Labs In this section, we present a use case of indoor positioning based on RSSI fingerprinting methods in the indoor office environment of the OTE Labs building (1st floor), which is depicted in Figure 46. In this environment, we installed three commercial Cisco Access Points (APs) in order to offer WiFi coverage (2.4 GHz) to the corridors of the floor, as illustrated in Figure 46. The common SSID of all three APs was “WHERE2”, while each of them was set to use a different frequency channel, i.e. AP1 used channel 1, AP2 channel 11, and AP3 channel 6.
Figure 46: Indoor environment of OTE Labs (1st floor).
In order to implement the indoor positioning, we developed an application for the Android OS, which interacts with a MySQL database, which has been deployed to stores RSSI Page 47 (73)
WHERE2
D4.6
measurements, position and other related information. Concerning the implementation details, we used 2 ZTE Light Tab 2 terminals the Eclipse IDE with the Android SDK 4.2 compiler, while we created a MySQL database using XAMPP 1.8.1 to store the measured RSSI values. The Android application, which is titled “Where2”, employs the following features: 1. Finger: scans the transmitted RSSIs from the 3 Where2 APs including related channels and frequencies, MAC addresses, etc., and records them in the MySQL database, 2. Change: scans the transmitted RSSIs from the 3 Where2 APs and enforces the connection of the terminal to the AP with the highest RSSI value (i.e. best signal) (horizontal handover) 3. Status: presents in the screen information about the current connection, 4. Find: runs the RSSI fingerprinting algorithm, identifies the position of the mobile terminal and displays it onto the map (see Figure 47). Figure 47 depicts
the home screen of the Where2 application.
Figure 47: Home screen of the Where2 application for indoor positioning.
Status and Finger operations: An instantiation of the Where2 application for indoor positioning can be seen in Figure 48, while the successful insertion of the RSSI information is demonstrated in Figure 48. Specifically, after the initialization of the application, the mobile user taps the Status button to derive information about his current connection. Then, the mobile user taps twice the “Finger” button to identify RSSIs from neighbouring APs and to record the received RSSI values in the MySQL database, which is named rssi_positioning2.
Figure 48: Instantiation of rssi_positioning2 database – successful insertion of RSSI fingerprinting information.
Page 48 (73)
WHERE2
D4.6
Figure 49: Instantiation of the Where2 application for indoor positioning.
Find operation: In order to accommodate the successful indoor positioning of the mobile terminal, we initially deployed a database called rssi_finger, where a multitude of RSSI 3-tuples along with related (x,y,z)-coordinates were stored. These values were derived by measurements taken throughout the entire WiFi coverage area, i.e. pointed out with blue dots in Figure 46. Then, the RSSI fingerprinting algorithm for the indoor positioning performed the following steps: i. ii.
iii.
scan the current RSSI values and store them in the rssi_positioning2 database, calculate the mean least squares error between the current RSSI values and each of the recorded RSSI 3-tuples in the rssi_finger database (also called training database), and return as current_position the (x,y,z)-coordinates of the recorded RSSI 3tuples with the minimum “distance” to the currently measured RSSI values.
The “distance” metric employed to calculate the difference of two RSSI 3-tuples is: m
min
i 1,...,m
SS i, j SS i 1
RM
MEAS
i 2 ,
j 1,..., n ,
where SS RM i, j is the SignalStrength value of the signal transmitted from access point i at SS MEAS i radiomap point j , and is the measured SignalStrength of the signal transmitted from access point i . The radiomap point j having the minimum norm is considered to be the most probable location. A logical diagram of the fingerprinting algorithm is shown in Figure 50.
Page 49 (73)
WHERE2
D4.6
Figure 50: Fingerprinting procedure.
Finally, Figure 51, Figure 52 Figure 52 present the PHP code running in the XAMPP server side in order to calculate the indoor position and return it to the mobile terminal, respectively.
Figure 51: PHP source code for identifying the “closest” record w.r.t. RSSI.
Page 50 (73)
WHERE2
D4.6
Figure 52: PHP source code for returning the estimated indoor position to the mobile terminal.
Finally, the outcome of a Find operation is then presented to the screen of the mobile terminal. Such an example from the indoor environment of OTE Labs is depicted in Figure 53, where the small dark blue dot represents the actual position and the large red dot the estimated one. This is an online procedure In general, we have found that the error of the RSSI fingerprinting method varies from 0.5 to 2.5 meters depending on the circumstances, e.g. glass and metallic surfaces, thick walls, etc.
Figure 53: Estimated indoor position vs. actual position.
The Where2 application is modular, and can be easily extended to employ alternative metrics for the calculation of the indoor position. Moreover, the estimated indoor position can be employed to perform horizontal handover, e.g. consider also geographical distance, when deciding which AP to connect to. Mobile UE behaviour in Horizontal Handover Decisions The scope of this section is to present a use case scenario in indoor office environments, regarding classification of mobile users and network access environment based on mobile terminal moving attitude. Towards this direction, a wireless topology has been considered (see Figure 54) where several soekris based WiFi access points constitute the access part of the network. Network Domain Cognitive Manager (NDCM) is responsible for controlling the underlay topology. In Deliverable D4.3 [1] an extensive description of NDCM and its monitoring metrics is available. Also, a Position Database has been deployed and stores Page 51 (73)
WHERE2
D4.6
measurements from the Fingerprinting position estimation method. A Video Server is available in order to stream video service that mobile users consume. Cognitive platform is enabled with monitoring of WiMax traffic.
Figure 54: Indoor topology.
Several mobile terminals exist in the topology, presenting varying moving behaviour. Mobile Teminals’ behaviour can be extracted through consecutive fingerprints. More specifically, Mobile Terminals are aware of their exact position (as this is computed by fingerprinting algorithm). Their position is communicated to the NDCM as well as the monitoring information they report. As a consequence, we categorize our users either as idle or as moving. In case of indoor office environments, which our scenario examines, a plethora of base stations are deployed in order to provide connectivity to demanding roaming users. Usually, a mobile terminal associates to an access point with the strongest RSSI. RSSI and other signal related metrics are not reliable indicators in case of indoor environments, where different path loss models exist. Conventional load balancing techniques focus mainly on load distribution. In our case, a combination of signal and load related metrics produces a handoff report. Dedicated access points have been deployed on an “OFFICE ENVIRONMENT” mode and only serve users whose position changes are almost insignificant. Moving users are associated only to specific GUEST access points, dedicated for bursts of small time scale associations. In our case, soekris5 soekris7 serve idle users, while soekris3 moving ones. Handoff events are generated when Network Cognitive Manager identifies “violations” of the before mentioned scenario. A list of candidate base stations is calculated and communicated to the mobile terminal which is associated to the wrong base station. In Figure 55, NDCM dashboard is available, where a list of soekris devices with their load status and transmission characteristics is available. As can be seen, four mobile terminals, two moving and two idle are associated to the nearest soekris device, based on instant RSSI value indicator.
Page 52 (73)
WHERE2
D4.6
Figure 55: NDCM dashboard.
Terminal2 is considered as moving one and is associated to soekris7. As can be seen from Figure 56, Terminal2 logs report that Terminal2 periodically sends its monitoring data, through soekris7 to the NDCM. Also, it requests whether a handover decision has been computed
Figure 56: Terminal2 logs before handover event
A handover event is calculated by NDCM and communicated to the victim user Terminal2, as the latter is not associated to the proper soekris device. Handoff decision execution takes place, as can be seen from Figure 57. Page 53 (73)
WHERE2
D4.6
Figure 57: Terminal2 is communicated the handover decision and associates to soekris3.
4.1.2 PTIN Scenario In this section we present the meeting room scenario and the Android application that was developed to address such scenario.
Figure 58: “Meeting room” scenario.
In the “Meeting Room” scenario, the application considers the user’s location and schedule - in this case provided by Google Calendar. Combining the schedule information with the user’s location at the time, the application can check the location where an upcoming appointment is taking place and present the user the direction to there.
Page 54 (73)
WHERE2 4.1.2.1
D4.6
Context location based
Figure 59: PTIN Test bed.
In order to address the indoor location scenario, a test bed was developed. This test bed relies on a Context Broker to store relevant context information (user location, etc) and interact with context data sources, providers and consumers, i.e. the entities that originate and/or use the context data – entities which, along with the Context Broker, constitute PTIN’s Context Framework. In this scenario, such entities are mobile terminals that push information about the APs surrounding the user into the broker and receive the user’s location in return, communicating in a publish-subscribe way – communication held in XMPP protocol, based on XML, The information about the APs is composed of 4 (four) fields: BSSID, SSID, frequency and RSSI.
Figure 60: XML data example of one AP (APInfo).
With the APs’ data, gathered with a mobile terminal, the user’s position is calculated using the fingerprint principle, by matching the APs’ data with (online data) and the radio pattern for the building obtained from measurement campaigns (offline data). The broker communicates with the database through RESTful webservices developed for this purpose.
Page 55 (73)
WHERE2
D4.6
Figure 61: List with the result of a scan for APs (Strength: RSSI in dBm; Network: SSID).
Towards providing indoor positioning, by the means mentioned above, an application was developed to be used in mobile devices running Android OS. 4.1.2.2 Android application The application is based on a map, supporting Google Maps and custom maps/floor plans of concerned buildings. The Google Map is presented when the user is located outdoor (i.e. user has GPS/Wi-Fi signal) whilst the custom map/floor plan is presented when he’s inside the correspondent building (with Wi-Fi coverage).
Figure 62: Map and floor plan displayed in outdoor and indoor environment, respectively.
Page 56 (73)
WHERE2
D4.6
Depending on GPS and Wi-Fi signals availability, the application switches between outdoor (Google Maps) and indoor map. The following features are provided:
Scan: when the application is launched, it starts to scan for Wi-Fi APs. When the scan results are made available, they are written to an XML file which is published to the broker. Later, the broker will return the user’s estimated position through a location provider that has been subscribed by the application; the user’s current position is pointed with a green marker ( ) in the map. Trace: allows the user to save the current location in application and “Find” it later. Find o My Location: centers the map in the current location marker (if available). o POI: Presents a list with the points of interest available in the (map) area. Navigation: When navigating to a certain position, a GPS-like arrow indicates the direction to follow towards the destination. Clear: clears the destination marker of the map, leaving only the marker of the current location (option available during navigation only). Events: lists the events for the current day, if any. o Title o Description o Location o Attendees Link to Facebook profile, if the attendee is a friend of the user on Facebook
The POIs and events have a known location. When a POI or event is chosen, its location is pointed with a red marker ( ) in the map and the application starts to navigate towards that destination.
Figure 63: Example of POIs available.
Page 57 (73)
WHERE2
D4.6
Figure 64: Navigation with distance data and GPS-like arrow.
The application loads the events for the current day from Google Calendar, which is associated with a user’s account. If that account shares the same email as the user’s Facebook account, the application will subscribe the social provider present in the Context Broker to obtain the user’s Facebook friends and match them with the attendees of an event. If there’s a match, the attendee entry in the attendees’ list is marked with a Facebook icon ( ) that displays the attendee’s profile when clicked.
Figure 65: Upcoming event.
Page 58 (73)
WHERE2
D4.6
4.1.3 UPM Scenario The main objective of the UPM contribution to the WP3-T33 has been to quantify the enhancement of the communications throughput, considering the location of all the nodes in a network. In order to do this study in a realistic environment, which provides transmission information of a large number of peer-to-peer connections, a UPM ray-tracing database is generated. The database uses CINDOOR ray tracing simulator of multipath behavior (all the rays) inside an indoor scenario. UPM database contains all possible pairs (Tx-Rx) corresponding to a plant of 36x19 m2, where the Tx and Rx are positioned in an 1mx1m square grid ( (37x20)2 = 547.600 different configurations). For each pair of TxRx positions a list of the rays is given (direct, diffracted, reflected etc) with the information including time of arrival, magnitude and phase of the complex envelope, and the angle of arrival. This way the simulator can be regarded as the one with infinite bandwidth, and we are able to simulate the transmission results of any wireless standard based on this output results. Furthermore, since angle of arrival of each ray is also provided, the receiver antenna can also be configured as a focalized antenna. The database is based on Microsoft SQL Server format. Additionally, several Matlab functions are provided in order to facilitate the database population. This contribution could be exploited in several ways: -
-
4.1.3.1
As a multi-standard database. Since individual rays are stored the data may be easily processed in order to obtain the impulse responses, transfer functions, … with a given bandwidth. As an heterogeneous scenario. The design of this scenario has considered the possibility of combining indoor and outdoor positions of the transmitters and receivers. Due to the huge number of node positions that have been simulated, this database may aid to other members to test and compare their algorithms in cases where the experimental measurements were not enough for a complete testing Heterogeneous Multi-standard Environment
About the ray tracing simulator tool (CINDOOR) CINDOOR is a ray tracing software that simulate the behaviour of a signal, travelling from transmitter to receiver based on optical rules. This commercial software has been developed by the Communication Engineering Department of the University of Cantabria (Spain). CINDOOR is based on windows environment. Like other similar programs, it has an horizontal menu containing the commands needed to perform a simulation that will show the obtained results directly on the screen. These commands are arranged in four groups: Geometry, Inputs, Run and Outputs. However, although the user can perform all the tasks using the horizontal menu, some of the most usual commands are located sequentially in a vertical menu indicating the process that should generally be followed to start a simulation and show the obtained results. These commands are presented as buttons that are activated by a click with the left button of the mouse.
Page 59 (73)
WHERE2
D4.6
Figure 66: Main window of the CINDOOR program.
Next, we describe the characteristics of each of the four groups. This description gives a very precise idea of the CINDOOR software capabilities. Geometry.Geometrical and electromagnetic Model. The application of a high frequency or ray approach to analyse the radio propagation process is based on the assumption of a geometrical and electromagnetic model of the environment. This software considers models constructed with flat facets or plates to represent urban and indoor scenarios. The model also must contain the electrical characteristics of the environment like: relative dielectric constant, conductivity and the standard deviation of the surface roughness; if the wall width is not known, the transmission coefficient is specified. All of this information is provided in a plain text file with a .cdb extension that can be manually or automatically generated with specific auxiliary tools. Inputs. Selection of the simulation parameters In this functional group, user introduces the transmitters and receivers positions, the different kinds of receivers available and other important simulation parameters: frequency, type of antennas, coupling mechanisms considered, etc.
Selection of the type of receiver. The different options are: - receiver at a point - receiver along a multiple straight path - receiver along a curved trajectory - receiver in mesh of points defined by a four sided polygon.
Selection of antennas. The user can select the working frequency in MHz. Also it is possible to select the antenna model between electrical dipole, λ/2 dipole or define a generic antenna by their radiation pattern. Coupling mechanisms. This capability is very important from the viewpoint of the accuracy of the results, also is very critical in the time necessary to simulate the indoor scenario. So an adequate selection of the coupling mechanisms is a very important task in the simulation. The different coupling mechanisms to be considered in this program are: Page 60 (73)
WHERE2
D4.6 - direct ray - reflected (from single to quadruple) rays - diffracted (single and double) rays - diffracted-reflected and reflected-diffracted rays
Selection of pulse shape. To compute the power profile, it is necessary to select a pulse to be used as a transmitted signal. There are four pulse shapes available: Gaussian, hanning, raised cosine and square.
Run. Running the program Once the user has selected the different options, everything is ready to run the program. Running the program generates the output files that allow the presentation of the screen with the program utilities. Outputs. Results visualization Once the simulation has finished, the results can be presented directly on the screen. The results that are available depend on the type of study selected by the user: point, trajectory or 2D map analysis. Some of the results visualization of CINDOOR are: ray tracing, impulse response, wideband parameters, coverage maps, narrowband parameters and statistical analysis. A very important part of the outputs are the files that CINDOOR generates. These files provide more detailed information that the results presented directly on the screen. At each point and with each ray the presented results are: delay time, magnitude and phase of the voltage (impulse response) , the angles defining the arrival direction of the ray and the type of ray. Also outputs contain the mean power in the receiving antenna in miliwats and the module and phase of each Cartesian component of the field.
About the scenario The scenario for estimating the parameters describes an indoor space of about 500 m2 with maximum dimensions of 36 m length, 19 m width, and 3 m height. In this scenario, besides the walls, we have also considered the ceiling and the floor. All the walls of this scenario are supposed to be brick made walls. This scenario has a perimeter with different sized rooms that may be used as offices. In the center of the scenario, there is also space that is occupied by two isolated interior offices. The idea behind the selection of this scenario is to choose a building plant that was representative enough to be able to generalize the results obtained with it to a wide class of indoor scenarios. In the following figure, the plant of the scenario is represented in a top view and in a 3D view.
Page 61 (73)
WHERE2
D4.6
19
36
Figure 67: The scenario.
As we have mentioned, the measurements are going to be obtained with the simulation tool called CIDOOR. The working band is 2.4 GHz and the transmitting and receiving antennas are both omnidirectional. shows the distribution of the Tx’s/Rx’s. There are (37x20=740)measure points located in an1 m. square grid, this allows a huge number of different configurations between transmitter and receivers (37x20)2=547.600. Figure 68
This figure also shows, that apart from the indoor points, there are points that are located outdoor. These points may be useful for other studies.
Figure 68: The scenario with the test points.
Database Internal structure In order to obtain the different rays between the Tx and the Rx, the simulation tool considers different types of rays as the direct ray, the reflected (from single to quadruple) rays, the diffracted (single and double) rays and the diffracted-reflected and reflected-diffracted rays. Information is stored in this way. For each pair (Tx-Rx) and each ray the following information is provided: Page 62 (73)
WHERE2 -
D4.6
delay time (seconds) magnitude of the voltage (miliVolts). Magnitude of the complex envelope phase of the voltage (degree). Phase of the complex envelope. Theta and Phi angles defining the arrival direction of the ray (degree).
This information is stored in the database called UPM_RAY TRACINGDB, that is stored in two files: UPM_RAYTRACINGDB.mdf and UPM_RAYTRACINGDB_log.ldf. Internally the database only has a table with all the information. All fields, except INDICE, is of char type in order to make it compatible with most of the platforms. The figure shows this table called UPM_RAYTRACINGTABLE. UPM_RAYTRACINGTABLE PK
INDICE
INTEGER
TX
CHAR(50)
RX
CHAR(50)
DELAY
CHAR(1000)
MAGNITUDE
CHAR(1000)
PHASE
CHAR(1000)
THETA
CHAR(1000)
PHI
CHAR(1000)
Table 15: UPM_RAYTRACINGTABLE.
The UPM_RAYTRACING database Matlab API In order to make easier the database manipulation, two functions have been provided in order to get information like the rays or the impulse response: RayMatrix=UPMdB_GetRayTracing(TxPosition, ReceiverPosition); %This function returns to RayMatrix the rays corresponding to an indoor scenario when the %positions fo the Tx and the Rx are specified. % The positions are constrained to a %plant of 36x18 square meters %Input parameters % TxPosition: 2x1 column vector that contains the transmitter position % RxPosition: 2x1 column vector that contains the receiver position %Output parameters % RayMatrix: [NumberOfRays x 5] matrix that contains all information concerning the rays. % Each row corresponds to a different ray, while the column dimension has the % information about each ray: The information provided is organized in the following fields: % DELAY: in seconds % MAGNITUDE: magnitude of the arriving ray in volts % PHASE: phase of the arriving ray in degrees % THETA: arrival angle in degrees (horizontal plane) % PHI: arrival angle in degrees (vertical plane)
Page 63 (73)
WHERE2
D4.6
[h, fs] = UPMdB_GetChannelImpulseResponse(TxPosition, RxPosition, Bandwidth ) %Returns the indoor channel impulse response from the Tx to the Rx when a bandwidth is specified. % %Input parameters % TxPosition: 2x1 column vector that contains the transmitter position % RxPosition: 2x1 column vector that contains the receiver position % Bandwidth: Channel bandwidth in Hz. % %Output parameters % h: returned indoor channel impulse response. % fs: samplingfrequency. 2xBandwidth
4.1.3.2
User’s Guide
Installing the dataBase UPM_RAYTRACINGDB is a Microsoft SQL Server database. The data are in a compressed .rar file. In order to install the database, the following 5 steps need to be done: 1. - Uncompress ‘UPM_RAYTRACINGDB.rar’ (107.347 Kbytes). This file contains - UPM_RAYTRACINGDB.mdf (1.336.320 Kbytes) - UPM_RAYTRACINGDB_log.ldf (13.632 Kbytes) 2. - Copy them to the DATA directory of Microsoft SQL Server. By default is located in: ..:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA 3. - Setting up ODBC data Source. Before you can use the Database Toolbox software to connect to a database, you must set up a data source. A data source consists of: - Data that the toolbox accesses - Information required to find the data, such as driver, folder, server, or network names Data sources interact with ODBC drivers or JDBC drivers. An ODBC driver is a standard Microsoft Windows interface that enables communication between database management systems and SQL-based applications. This is a necessary step before making queries to the database. In order to make this task, two different tools can be used: -
ODBC Data Source Administrator. This software is included in the Microsoft Windows operating system as an administrative tool.
-
Querybuilder included in Matlab Database toolbox. This need that the optional Database toolbox be installed in the computer. Internally, this software calls to the ODBC Data Source Administrator, but the toolbox tutorial contains a detailed description of how to setting up this connection.
4. - Installing the adodb_toolsMatlab toolbox.
Page 64 (73)
WHERE2
D4.6
This free toolbox encapsulates the ado database API in order to make easier the database manipulation. This toolbox will be used by the Matlab functions designed for quering the database. After installing this toolbox, it is necessary to update the matlab path. (matlabpath command). 5. - Setting the database parameters for making queries Before making queries to the database, it is necessary to set the login and password. To do this task, The following command inside the function UPMdB_GetRayTracing() must be changed: connectionString='PROVIDER=SQLOLEDB; Data Source=MyPCName; initial catalog=UPM_RAYTRACINGDB; User ID=myUser; password=MyPassword;';
It is the first non-commented line and opens the SQL database. The following parameters must be set to your current database installation: Data Source: The name of the server where MS SQL Server database is installed must be specified Userd ID: A valid User of the MS SQL Server must be specified. Password: A valid password the MS SQL Server must be specified
Making queries to the database Three functions have been developed for making the queries. In this section we present several examples that will aid to populate through de database. Before making the queries it is a must to have installed the database according the steps on the above section. First example: Calculate the indoor impulse response between the transmitter (5, 5) and the receiver (15, 15). The technology used by the tx-rx pair use a bandwidth of 1 GHz. The function returns the complex envelope impulse response sampled twice the bandwidth. TxPosition=[5;5]; RxPosition=[15; 15]; Bandwidth=1e9; %1 GHz h=UPMdB_GetChannelImpulseResponse(TxPosition, RxPosition, Bandwidth); plot( (0:length(h)-1)/(Bandwidth), abs(h) ); grid xlabel('time (seconds)'); ylabel('volts'); title('Indoor impulse response')
Page 65 (73)
WHERE2
D4.6
Figure 69: Impulse response.
Second Example: Based on the first example but we need the individual rays (infinite bandwidth). In this example only the magnitude of the complex envelope is shown. Information about complex envelope phase and arrival angle is also available. TxPosition=[5;5]; RxPosition=[15; 15]; RayMatrix=UPMdB_GetRayTracing(TxPosition, RxPosition); stem( RayMatrix(:,1), RayMatrix(:,2) ); grid; xlabel('time (seconds)'); ylabel('volts'); title('Indoor impulse response');
Page 66 (73)
WHERE2
D4.6 -3
1
Indoor impulse response
x 10
0.9 0.8 0.7
volts
0.6 0.5 0.4 0.3 0.2 0.1 0
0
0.5
1
1.5 time (seconds)
2
2.5
3 -7
x 10
Figure 70: Individual Rays.
4.2
Demonstrations
4.2.1 FUNEMS In this section we present a trial realization based on the meeting room scenario that took place during the “Future Network & MobileSummit 2013” (FUNEMS) conference.
Figure 71: FUNEMS 2013 - floor plan.
Page 67 (73)
WHERE2
D4.6
The numbers represent booths, in particular: 3 - Medieval booth 4 - GREEN-T booth 5 - WHERE2 booth The red path in the figure above represents the measurement campaign that was performed, starting in front of the WHERE2 booth, passing in front of the GREEN-T and Medieval booths and then turning left towards the Entrance. The measurements were made every 1m. From the set of APs identified during the measurement campaign, only 8 (eight) APs (owned by the Hotel where the conference took place) – known to be always available and stationary – were considered for the fingerprinting, discarding the many APs present in other booths which we did not have any guarantees regarding availability and positioning. This abundance of APs in such a small space caused interference, influencing the results of the trials. The following screenshots show the application running during a trial, the available POIs and the navigation from the WHERE2 booth to the Medieval booth.
Figure 72: Application start – user’s position is obtained and mapped.
Page 68 (73)
WHERE2
D4.6
Figure 73: POIs available.
Figure 74: Information associated with an upcoming event.
By clicking the “Go To Event” button, the application starts the navigation towards the location of the event.
Page 69 (73)
WHERE2
D4.6
Figure 75: Navigation towards the event location.
When the user reaches the destination – the meeting location – that information is sent to the Context Broker so that the other attendees of the meeting can receive the information about who is already attending it.
Figure 76: Event information updated with an attendee’s location.
The application was presented to the conference participants by letting each of them navigate from the WHERE2 booth towards the Medieval booth, in a sort of trial. Along with the interference caused by the amount of APs in the area, the results of each trial were affected by the amount of people surrounding the user, such that the accuracy error varied from 1 to 4 meters.
Page 70 (73)
WHERE2
5
D4.6
Conclusions
The present deliverable is a valuable demonstration of the project importance for the actual services, either for communications purposes or application refinement/enhancement, where the location information in indoor environment is highly restricted. This location knowledge can be integrated in different scenarios, from location aware applications up to communications enhancement processes. This document also addresses some techniques pursued during the project, which may be expanded to further scenarios. Starting with the secure cluster communication protocol used during the measurement campaign to interexchange information between the Android nodes. A secure cluster communication protocol, like this, which allows exchanging information between mobile nodes (Android mobile phones), can be useful in common applications to establish secure P2P communications between nodes. Its application would allow for a more secure information channel for close communications, either in a P2P link, or in a cluster configuration mode. One other important work is the opening detection algorithm, which is able to detect building openings (like windows, or doors) from existing three-dimensional representations of the building. Such work, part of the building characterisation and mapping (T2.3), is address on the document and evaluated using a specific set of data unable to be collected during the measurement campaign, due to restrictions on the hardware transportation. A plausible extension for this work would be to extend the application of such technique for indoor operation to document the building structure from the inside and use the information to aided on the location process. A set of algorithms from WP2, in cooperation with the measurement campaign from WP4, is under the scope to evaluate their ability to extract accurate location estimations from the provided data. The systems used for those tests were the UWB (for two different systems), and the ZigBee information for another one. There is also a work, which promotes an heterogeneous cooperation between the two systems stated above. Three different scenarios, where the location information was used, are presented to demonstrate how this information can be important and useful on communications and also on user applications refinement. A first scenario evaluates the horizontal handover process, which is based on a RSSI fingerprint location system, and allows enhancing the handover process with the help of the location information. Another scenario, where the location information is used in communications enhancement, is for the evaluation of the data throughput when taking into account the nodes location. A work that was carried out under T3.3 and is here documented. Finally, a last scenario demonstrates the location information importance for user applications, more specifically for context aware applications, where the location is used for different ends like presenting accurate routes to a given location in an indoor environment, or better targeted information accordingly with the user’s location. A main set of data is common to the various tests presented on this report, except for the specific scenarios, where the conditions required were not available, like in the building opening detection algorithm and the demonstration carried out during the FUNEMS’13. The report is a clear cooperative work between the various partners within the project, with various links to WP2 and its location algorithms, but also with T2.3 building characterisation and mapping. WP3 is also linked to this document, consequence of the secure cluster protocol here demonstrated and to the data throughput evaluation on systems aware of the nodes’ location.
Page 71 (73)
WHERE2
6
D4.6
References
[1] WHERE2 Partners. Test and evaluation of the integrated system under real scenario conditions. Technical report, Deliverable D4.5 of the WHERE2 Project (ICT-248894), 2013.. [2] WHERE2 Partners, ICT-248893 WHERE2 Deliverable D3.2: "Intermediate: Realization and usage of geo-location based clustering and mobile relaying", January 2012. [3] WHERE2 Partners, ICT-248893 WHERE2 Deliverable D3.5: "Final: Realization and usage of geo-location based clustering and mobile relaying", June 2013. [4] "ICT-248893 WHERE2 Deliverable D3.3: "Intermediate: Location-aided PHY/MAC layer design for advanced cognitive radios"," 2012. [5] M. A. Fischler and R. C. Bolles, ""Random sample consensus: a paradigm for model fitting with applications to image analysis and automated cartography"," ommun Acm, vol. 24, no. 6, pp. pp. 381–395, 1981. [6] WHERE2 Partners, "ICT-248893 WHERE2 Deliverable D2.6: "Final report on selflearning positioning using inferred context information"," May 2013. [7] WHERE2 Partners, "ICT-248893 WHERE2 Deliverable D1.8: "Final report on n the WHERE2 Channel Model"," 2013. [8] WHERE2 partners, "ICT-248893 WHERE2 Deliverable D2.4: "Final synergetic cooperative location and communications for dynamic Heterogeneous Networks"," May 2013. [9] WHERE2 Partners. Test and evaluation of the integrated system under real scenario conditions. Technical report, Deliverable D4.5 of the WHERE2 Project (ICT-248894), 2013. [10] Laaraiedh, M. and Avrillon, S. and Uguen, Bernard. Enhancing positioning accuracy through direct position estimators based on hybrid RSS data fusion. Proc. VTC Spring, pages 1–5, Barcelona, Spain, 2009. [11] S. Zirari and B. Denis. Velocity-based crlb predictions for enhanced cooperative links selection in location-enabled mobile heterogeneous networks. In IEEE WPNC'13, Dresden, 2013. [12] S. Zirari and B. Denis. Comparison of links selection criteria for mobile terminal positioning in cooper-ative heterogeneous networks. In IEEE SoftCOM'12, Sept 2012.. [13] R. Raulefs et al.. Technical report, Technical report, Deliverable D2.4 of the WHERE2 Project (ICT-248894), Oct 2013. [14] B. Uguen et al. Scenarios and parameters. Technical report, Deliverable D1.1b of the WHERE2 Project (ICT-248894), Aug 2011. [15] Y. Ma et al. Performance of where cooperative positioning techniques. Technical report, Deliverable D2.4 of the WHERE Project (ICT-217033), May 2010. [16] S. Avrillon M. Laaraiedh and B. Uguen. Enhancing positioning accuracy through direct position esti-mators based on hybrid rss data fusion. In Proceedings of VTC spring 2009, Page 72 (73)
WHERE2
D4.6
pages 1-5, April 2009. [17] WHERE2 Partners, ICT-248893 WHERE2 Deliverable D4.2: "Technology Evaluation Platforms", Sept 2012. [18] WHERE2 Partners, ICT-248893 WHERE2 Deliverable D4.3: "Interoperability Framework Development and Implementation", Dec, 2012. [19] WHERE2 Partners, ICT-248893 WHERE2 Deliverable D4.4:"Test and Evaluation of the integrated System under laboratory conditions", May 2013.
Page 73 (73)
![Related WHERE2 Deliverable - SatNav Model Page - DLR [PDF]](https://m.moam.info/img/260x300/related-where2-deliverable-satnav-model-page-dlr-p_648ca56a098a9e2d608b464d.jpg)
![Related WHERE2 Deliverable - SatNav Model Page - DLR [PDF]](https://m.moam.info/img/260x300/related-where2-deliverable-satnav-model-page-dlr-p_64f55339098a9e9a768b45ff.jpg)
![Related WHERE2 Deliverable - SatNav Model Page - DLR [PDF]](https://m.moam.info/img/260x300/related-where2-deliverable-satnav-model-page-dlr-p_64afae36098a9e101c8b464c.jpg)
