Interoperability Framework Development and Implementation · (Wi-Fi, LTE, ZigBee, UWB) and...

WHERE2 D4.3. Version 1.0

Page 1 (101)

ICT- 248894 WHERE2

D4.3. Version 1.0

Interoperability Framework Development and Implementation

Contractual Date of Delivery to the CEC: M29

Actual Date of Delivery to the CEC: M30

Editor: Marios Raspopoulos

Author(s): Marios Raspopoulos, Stavros Stavrou, Lorena de Celis, Jacobo

Domínguez, Emanuel Staudinger, Lionel Biard, Roberto Vieira,

Roi Arapoglou, George Agapiou

Participant(s): SIG, ACO, DLR, CEA, PTIN, NKUA, OTE

Work package: WP4 – Heterogeneous Test Bed for Location and Communications

Security: PU

Nature: R

Version: 1.0

Total number of pages: 101

This deliverable describes the current implementation activities regarding the interoperability

framework defined in the WHERE2 project. It describes the main components which constitute

this framework including the database, the interfaces which retrieve context from the

positioning platforms, the interfaces which provide positioning-related context to the database

and also how the communication platforms are implemented and make use of the positioning

information generated by the positioning algorithms. The deliverable serves as a handbook,

providing the necessary information required to integrate the defined framework paying specific

attention on how to connect to the database, update it or retrieve information from it.

Keyword list: WHERE2 Database, Demonstration, Implementation, Interface, Interoperability

Framework, hardware platforms adaptation


Page 2 (101)

Executive Summary

A comprehensive description of the implementation activities carried out in the WHERE2

project towards the integration of the defined interoperability framework is provided in this

deliverable. This framework basically serves two main purposes; (1) to demonstrate the benefit

in positioning (accuracy and performance) from utilising heterogeneous and cooperative radio

(Wi-Fi, LTE, ZigBee, UWB) and non-radio technologies (inertial sensors) and (2) to

demonstrate the benefit in heterogeneous communication from having accurate positioning

information. The deliverable provides a description of the main components of the framework

paying specific attention on how context is extracted from the available technologies and how

this context is communicated with the other components of the framework. The implemented

database serves as a central point of context exchange in the framework and is accessed through

a number of interfaces which either provide or retrieve data from it. Three interfaces (A,B,C)

are used to translate the information received from the low level positioning platforms and

provide it into the database in a common form through a common communication framework

which has been also defined within the project. This heterogeneous context is made available to

the various positioning algorithms which utilise it to perform position estimations and provide

the result back in the database. The estimated positions are then used by the communication

platforms (Vertical handover platform and context-based application platform) to demonstrate

the communication benefit.


Page 3 (101)

Authors

Partner Name Phone / Fax / e-mail

SIG Marios Raspopoulos Phone: +35722325240

Fax: +35722325241

e-mail: [email protected]

SIG Stavros Stavrou Phone: +35722325240

Fax: +35722325241


CEA Lionel Biard Phone: +33 438782854

Fax: +33 438786586


DLR Emanuel Staudinger Phone: +49 8153 28 2887

Fax: +49 8153 28 1871


ACO Jacobo Domínguez Phone: +34 942 764 400

Fax: +34 942 764 403


ACO Lorena De Celis Phone: +34 942 764 400

Fax: +34 942 764 403


PTIN Miguel Santos Phone:

Fax:


PTIN Isabel Borges Phone:

Fax:


NKUA Roi Arapoglou Phone: +30 210 727 5211

Fax:


OTE George Agapiou Phone:

Fax:

Email: [email protected]

mailto:[email protected]







mailto:%[email protected]




Page 4 (101)

Table of Contents

List of Acronyms and Abbreviations .................................................................. 12

1. Introduction ................................................................................................ 13

2. Environment ................................................................................................ 15

3. Interoperability Framework Overview ......................................................... 16

3.1 Interface A (Adapter) ................................................................................................... 17

3.1.1 ZigBee Interface ................................................................................................... 17

3.1.1.1 Configuration ............................................................................................. 17

3.1.1.2 Information provided by the platform ........................................................ 20

3.1.2 UWB Interface ..................................................................................................... 21

3.1.2.1 General system information ....................................................................... 21

3.1.2.2 Information provided by the platform ........................................................ 22

3.1.2.3 Interface with the Common Framework .................................................... 22

3.1.3 Interface for OFDM-based RTD test-bed – Cooperative test-bed ....................... 23


3.1.3.2 Estimated parameters for WHERE2 database ........................................... 25

3.1.3.3 Calibration ................................................................................................. 26

3.1.3.4 Low-level interface A to WHERE2 common framework ......................... 26

3.1.4 LTE Interface ....................................................................................................... 27


3.1.4.2 Estimated parameters for WHERE2 database ........................................... 29

3.1.4.3 Calibration ................................................................................................. 30

3.1.4.4 Low-level interface A to WHERE2 common framework ......................... 30

3.2 Interface B (Base) ........................................................................................................ 30

3.3 Interface C (Cooperative) ............................................................................................ 32

4. Database ...................................................................................................... 35

4.1 Design .......................................................................................................................... 37

4.2 Database tables details ................................................................................................. 40

4.3 Deployment .................................................................................................................. 51

4.3.1 Installing the database locally .............................................................................. 51


Page 5 (101)

4.3.2 Remote Access to a database ............................................................................... 58

4.3.3 Multiple Measurements for different Scenarios ................................................... 61

4.3.4 Matlab or Java as SQL query client ..................................................................... 64

5. Higher layers - GUI development ................................................................. 65

5.1 Framework Interfaces .................................................................................................. 65

5.1.1 Communication with the different test beds front ends – Interface B .................. 65

5.1.2 Communication with the database – Interface C ................................................. 68

5.1.2.1 Database connection options ..................................................................... 68

5.1.2.2 Database information ................................................................................. 69

5.1.2.3 Database Logging ...................................................................................... 71

5.2 Support features ........................................................................................................... 72

5.2.1 Log functionality .................................................................................................. 72

5.2.1.1 Log file generation ..................................................................................... 72

5.2.1.2 External viewer .......................................................................................... 73

6. Position-based Communication Platforms .................................................... 77

6.1 Vertical Handover - IP Mobility functionality............................................................. 77

6.1.1 SOEKRIS Platform .............................................................................................. 79

6.1.2 Vertical Handover Algorithms ............................................................................. 83

6.2 Context-based Platform and Application ..................................................................... 85

6.2.1 Context Framework .............................................................................................. 85

6.2.2 Protocol ................................................................................................................ 85

6.2.3 Context Sources and Context Providers ............................................................... 86

6.2.3.1 APInfo / Positioning .................................................................................. 86

6.2.4 Communication with the database (Interface E) .................................................. 87

6.2.5 PTIN Positioning System ..................................................................................... 87

6.2.6 Applications ......................................................................................................... 88

6.2.6.1 Implementation scenario - “Meeting Room” ............................................. 88

6.2.6.2 Maps .......................................................................................................... 89

7. Summary ..................................................................................................... 90

References ......................................................................................................... 91


Page 6 (101)

Appendix A Stored Procedures to Populate the WHERE2 database ......... 93


Page 7 (101)

List of Figures

Figure 1-1: WHERE2 System. .................................................................................................... 14

Figure 2-1: Help file built for WHERE2 Common Framework.................................................. 15

Figure 3-1: WHERE2 framework overview (class diagram). ..................................................... 16

Figure 3-2: ZigBee Location profiles (interface A - commands implemented) .......................... 17

Figure 3-3: Overview of DLR’s cooperative test-bed. ................................................................ 23

Figure 3-4: OFDM framing for the RTD test-bed. ...................................................................... 24

Figure 3-5: Allocated subcarriers for the ranging symbol. ......................................................... 24

Figure 3-6: Allocated subcarriers for the comb-type synchronization symbol. .......................... 25

Figure 3-7: Overall bandwidth and virtual subcarriers. .............................................................. 27

Figure 3-8: Framing for LTE demo in time domain. .................................................................. 28

Figure 3-9: A complete 32 symbol frame for the test setup. ....................................................... 28

Figure 3-10: Pilot mapping in frequency domain. ...................................................................... 28

Figure 3-11: Classes that implements interface B ....................................................................... 31

Figure 3-12: Interface B (properties, methods and events) ......................................................... 32

Figure 4-1: WHERE2 Demonstration Architecture .................................................................... 35

Figure 4-2: Communication within the WHERE2 Architecture ................................................. 37

Figure 4-3: Database schema for positioning-based context from DLR, CEA and ACO ........... 39

Figure 4-4: Database schema for Task 2.3 Ray Tracing simulations .......................................... 40

Figure 4-5: SQL server installation ............................................................................................. 51

Figure 4-6: SQL features selection .............................................................................................. 51

Figure 4-7: SQL instance configuration ...................................................................................... 52

Figure 4-8: SQL server configuration ......................................................................................... 52

Figure 4-9: SQL database configuration (authentication mode) ................................................. 52

Figure 4-10: SQL server connection ........................................................................................... 53

Figure 4-11: Attach database....................................................................................................... 53

Figure 4-12: Attach database (add) ............................................................................................. 54

Figure 4-13 : Attach database (locate db) ................................................................................... 54

Figure 4-14: Attach database (authentication mode) .................................................................. 55

Figure 4-15: Database properties ................................................................................................ 55


Page 8 (101)

Figure 4-16: Database new login ................................................................................................ 56

Figure 4-17: New login properties .............................................................................................. 56

Figure 4-18: Database new user .................................................................................................. 57

Figure 4-19: Creation of roles (query) ........................................................................................ 57

Figure 4-20: User roles ................................................................................................................ 58

Figure 4-21: SQL server access .................................................................................................. 58

Figure 4-22: Database connection properties (remote access) .................................................... 59

Figure 4-23: SQL server configuration manager (services) ........................................................ 60

Figure 4-24: SQL server configuration manager (client protocols) ............................................ 60

Figure 4-25: TCP properties ........................................................................................................ 60

Figure 4-26: SQL services restarting .......................................................................................... 61

Figure 4-27: Multiple measurements, initial setup. ..................................................................... 61

Figure 4-28: Database renaming ................................................................................................. 62

Figure 4-29: SQL instance with two databases ........................................................................... 62

Figure 4-30: Example with three database instances .................................................................. 63

Figure 4-31: SQL queries for two WHERE2 databases in the same SQL server instance ......... 63

Figure 5-1: WHERE2 User interface look and feel .................................................................... 65

Figure 5-2: Options to connect a platform .................................................................................. 66

Figure 5-3: Information provided by a node ............................................................................... 67

Figure 5-4: Measurements (inertial sensors and link measures) ................................................. 68

Figure 5-5: Database options....................................................................................................... 69

Figure 5-6: Database overview tab .............................................................................................. 69

Figure 5-7: Measurement campaign details into database .......................................................... 70

Figure 5-8: Location algorithms tab ............................................................................................ 70

Figure 5-9: Real time mode settings ........................................................................................... 71

Figure 5-10: Trigger measure mode ............................................................................................ 71

Figure 5-11: New logger – Sentinel (step 1) ............................................................................... 74


Figure 5-13: New logger – Sentinel (App settings) .................................................................... 74



Page 9 (101)


Figure 5-16: NLog external viewer (Sentinel) ............................................................................ 76

Figure 6-1: Position-Based Vertical Handover Demonstration Architecture .............................. 79

Figure 6-2: Foundation blocks of monitoring software ............................................................... 80

Figure 6-3: User’s terminal position measurements passed to the database ............................... 84

Figure 6-4: VHO process (Position measurements – Database- Decision- Handover) ............... 84

Figure 6-5: PTIN Test bed .......................................................................................................... 85

Figure 6-6: XML example of one AP data fields ........................................................................ 86

Figure 6-7: Meeting Room scenario ............................................................................................ 89

Figure 6-8: Screenshot of the application pointing the user’s location (indoor) in a custom map

............................................................................................................................................. 89


Page 10 (101)

List of Tables

Table 3-1: Configuration parameters of a mobile node .............................................................. 18

Table 3-2: Configuration parameters of a base station ................................................................ 18

Table 3-3: Configuration parameters of the coordinator/network ............................................... 19

Table 3-4: Localization information received from mobiles nodes ............................................ 20

Table 3-5: Link measurements information provided by ZigBee nodes ..................................... 20

Table 3-6: Inertial information provided by mobile nodes ......................................................... 21

Table 3-7: Inertial sensors metrics provided by the UWB mobile nodes .................................... 22

Table 3-8: Link metrics provided by the UWB mobile nodes .................................................... 22

Table 3-9: UWB network APIs description ................................................................................ 23

Table 3-10: Summary of OFDM parameters for the RTD test-bed. ........................................... 24

Table 3-11: Link measurement parameters from the RTD test-bed. ........................................... 25

Table 3-12: Summarized OFDM parameters for the LTE-like test-bed. .................................... 27

Table 3-13: Link measurement parameters from each of the two “LTE” receivers for the

database table DLR_LTE_Measurements. .......................................................................... 29

Table 3-14: Parameters for the database table DLR_LTE_TDoA_Table. .................................. 29

Table 3-15: Interface B methods ................................................................................................. 31

Table 3-16: Methods to access the WHERE2 database from the application. ............................ 33

Table 4-1: Trolleys Table Description ........................................................................................ 40

Table 4-2: Trolleys Table Description ........................................................................................ 41

Table 4-3: Nodes Table Description ........................................................................................... 41

Table 4-4: Position Table Description ........................................................................................ 42

Table 4-5: TruePosition Table Description ................................................................................. 42

Table 4-6: ReferencePoint Table Description ............................................................................. 43

Table 4-7: Algorithm Table Description ..................................................................................... 43

Table 4-8: ACOLinkMeasurements Table Description .............................................................. 43

Table 4-9: ACOSensorMeasurements Table Description ........................................................... 44

Table 4-10: CEASensorMeasurements Table Description ......................................................... 44

Table 4-11: CEALinkMeasurements Table Description ............................................................. 45

Table 4-12: DLR_COOP_Measurements Table Description ...................................................... 45


Page 11 (101)

Table 4-13: DLR_LTE_Measurements Table Description ......................................................... 46

Table 4-14: DLR_LTE_TDoA Table Description ...................................................................... 47

Table 4-15: Simulation Table Description .................................................................................. 48

Table 4-16: Transmitters Table Description ............................................................................... 48

Table 4-17: Receivers Table Description .................................................................................... 49

Table 4-18: omniResults Table Description ................................................................................ 49

Table 4-19: sectorResults Table Description .............................................................................. 50

Table 6-1: NetworkManager interface ........................................................................................ 80

Table 6-2: Wired interface .......................................................................................................... 81

Table 6-3: Wireless interface ...................................................................................................... 82

Table 6-4: Basic Classes of the Monitor block ........................................................................... 83

Table 6-5: Monitor ...................................................................................................................... 83


Page 12 (101)

List of Acronyms and Abbreviations

Term Description

AAF Analog amplify and forward

API Application Programming Interface

AWGN Additive White Gaussian Noise

CFR Channel frequency response

CIR Channel impulse response

COTS Commercial off-the-shelf

CRLB Cramér-Rao lower bound

FE Front-end

FPGA Field programmable gate array

GUI Graphical User Interface

IR-UWB Impulse Radio Ultra Wide Band

JSON JavaScript object notation

LINQ Language Integrated Query

LO Local oscillator

LS Least-squares

LTE Long Term Evolution

OFDM Orthogonal frequency-division multiplex

ORM Object Relational Mapping

PSD Power Spectral Density

RF Radio-frequency

RSSI Received signal strength indication

RTD Round-trip delay / Round-trip distance

SINR Signal to interference and noise ratio

SNR Signal to noise ratio

SQL Structured Query Language

TDoA Time difference of arrival

VHO Vertical Handover

XML Extensible Markup Language


Page 13 (101)

1. Introduction As defined in the Description of Work the WHERE2 interoperability framework handles the

different standards integration and collaborative operations, and therefore will deal with the

higher layers of the stack, preferably in the application layer, in order to make use of the current

standards, and improve the operation and performance of envisioned integrated multi-standard

systems. Based on the data collected from the different technology front-ends, the system must

be able to combine and process the information, enhancing the precision and reliability of the

system, both on the communication links and localization algorithms. In this context, a

hardware trial platform has been defined and is being implemented within the project which

consists of experimental hardware platforms that are available from different project partners

and are adapted for being able to cooperate with each other.

Thus, a heterogeneous hardware trial platform is being implemented in the scope of WHERE2

project. The implementation is built around a common framework accessible from a collection

of Interfaces as shown in Figure 1-1. By means of this framework, a consolidated positioning-

related context can be provided into a central database from a variety of heterogeneous radio

and non-radio technologies. This context is then made available to the positioning algorithms

which perform the necessary computation to estimate the user’s location and update the

database accordingly. This user location information is made available to the communication

platforms which use it as a metric for improving wherever possible the communication and also

the quality of service and quality of experience.

This deliverable describes the current implementation activities regarding the higher layers of

the interoperability framework defined in the WHERE2 project. The main components, which

constitute this framework, are describing in this document, including the database, the interfaces

which retrieve context from the positioning platforms, the interfaces which provide positioning-

related context to the database and also how the communication platforms are implemented and

make use of the positioning information generated by the positioning algorithms. The

deliverable serves as a handbook, providing the necessary information required to integrate the

defined framework paying specific attention on how to connect to the database, update it or

retrieve information from it.

The interoperability framework handles different standards for the different platforms. After a

preliminary discussions about the common framework functionalities (task 4.1), one of the first

steps in this task was the environment definition. Section 2 exposes all the tools used in the

implementation of a common development environment. The main outputs of the different

platforms are provided to the database with positioning information (RSSI, ranging estimation,

inertial sensor data...). Section 3 offers a description of all the interfaces defined and

implemented for this data gathering. A common interface, “Interface B” (Base), has been

implemented by all platforms in order to present a common shared interface. The main features

of this interface are presented in section 3.2. The low level adaptation of each platform

(firmware, drivers…) to provide data to the common framework was also required. These

adaptations have been defined internally for each platform and are named under the common

name “Interface A” (Adaptor) in section 3.1.


Page 14 (101)

Figure 1-1: WHERE2 System.

The database which is the central point of context exchange in the WHERE2 demonstration

architecture is described in detail in section 4. It is envisioned to be sitting centrally, where this

database should be accessible through a dedicated IP address and will be used to host the

necessary positioning context collected from the different positioning platforms (CEA, ACO,

and DLR). Then, this information) will be made available to the positioning algorithms to

estimate the location of the user. The positioning algorithms will then update the position of the

user in the database based on this context. The section provides a comprehensive description of

the tables which constitute the database describing the data types of all the entries. Also a

description of the developed stored procedures used to populate and update it with context is

provided, as well as a description on how the database can be attached and used working with

SQL and/or MATLAB.

A graphical user interface is being implemented to test the interoperability common framework

as well as to show the project results. Section 0 summarizes the main functionalities

implemented currently in this GUI.

Finally section 6 provides a description of the communication platforms (Mobile IP platform

and context-based platform) which combine the position estimation, obtained by the positioning

algorithms, with the positioning context store in the communication platforms databases. In

addition, it offers a detailed view of monitoring and communication capabilities of the access

part of the platform. Handover decision is presented as a combination of network and position

related metrics.

Common Framework

COMMON CORE

ZigBeeAPI

UWBAPI

RTD + LTEAPI

Context

Trolley estimation position

Trolley estimation position Position Algorithms

(WP2)VHO Algorithms (UoA,SIG, OTE)

PTIN platform

WHERE2 Database

WHERE2 Database

Position(x,y)

Remote IP Connection Interface C

Interface B

Interface A


Page 15 (101)

2. Environment All the tools selected to build the common framework are free tools in order to work all the

partners with the same tools without any extra cost. The development environment is composed

by:

Microsoft Visual Studio 2008 Express Edition. Visual C# Express is an easy-to-use,

free, lightweight, integrated development environment (IDE) [1]. The common

programming languages selected have been:

o C#: type-safe object-oriented language that enables developers to build a

variety of secure and robust applications that runs on the .NET Framework [2].

o LINQ: provides built-in query capabilities across a variety of data sources. It is

a set of features that extends powerful query capabilities to the language syntax

of C# [3] [4].

SQL Server 2008 r2 Express Edition: Since Microsoft SQL Server 2008 R2 Express

Edition is free, there are a few limitations, but the available features are enough to

create WHERE2 database [5].

Sandcastle Help File Builder is a tool used for creating MSDN-style (*chm)

documentation from .NET assemblies and their associated XML comments files. Once

the C# code has been correctly commented, this tool generates automatically a help file

[6].

Figure 2-1: Help file built for WHERE2 Common Framework

NLog: free logging platform for .NET, Silverlight and Windows Phone with rich log

routing and management capabilities. It makes it easy to produce and manage high-

quality logs for your application regardless of its size or complexity [7]. One of the

more interesting features of using NLog is that once the logs are generated by the

application they can be watch by external free tools.

o The configuration of this kind of logs is very simple; it is based in a XML file

that needs to be included in the project as well as a library (dll file).

o The output of the log can be store in a file (*.txt, *.csv …) for post processing

proposes or it can be watch in real time using external tools like sentinel [8].


Page 16 (101)

3. Interoperability Framework Overview In computer programming, a software framework is an abstraction in which software providing

generic functionality can be selectively changed by user code, thus providing application

specific software. A software framework is a universal, reusable software platform used to

develop applications, products and solutions. Software frameworks include support programs,

compilers, code libraries, an application programming interface (API) and tool sets that bring

together all the different components to enable development of a project or solution [9]

One of the main objectives of WP4 is the integration of different technologies platforms into

one single test bed in order to evaluate and test the improvements in collaborative position and

location estimation. Taking this objective in mind it has been develop a common WHERE2

interoperability framework that is able to share the different platform information and store in a

common WHERE2 database. This data store could be used by WP2 in order to evaluate some of

its algorithms.

WHERE2 Common Framework is one of the outputs of task 4.3 “Higher Layers Application

Development and Implementation”. Besides this framework, a graphical user interface has been

implemented in order to test all the functionalities developed and also to easily show the project

results.

Figure 3-1 shows a class diagram where the main classes in the common framework are present.

Figure 3-1: WHERE2 framework overview (class diagram).

In the following sections the different interfaces between all the WHERE2 Subsystems will be

detailed. These interfaces are named from lower platforms to upper abstraction layers, Interface

A, B and C.

Common Framework

LTE + RTDDevice

ZigBeeDevice

UWBDevice


Page 17 (101)

3.1 Interface A (Adapter)

This interface adapts the physical platforms communications to the host computer WHERE2

framework. This communication has been implemented via different protocols for each platform

RS232, USB, or Ethernet. This has been defined and implemented by each platform owner

internally using their own languages and tools.

3.1.1 ZigBee Interface

A ZigBee network is formed by a coordinator and several routers and/or end devices. All the

data in the networks is received by the coordinator, so the communication between the Common

Framework and ZigBee network has been develop through the coordinator. A serial protocol has

been selected through a USB connector (exposed as a virtual serial port).

The specific software driver to communicate the coordinator with the common framework has

been implemented in C#, in the scope of the WHERE2 Common Framework.

ZigBee applications define the functionalities of the network by means of profiles. A Location

profile has been defined in the scope of the WHERE2 project. This profile is composed by

clusters (the commands that can be requested and received). Additional inertial sensor boards

have been developed that can be connected to mobile nodes, so a specific cluster to request the

information generated by these sensors are also included. All the commands implemented by the

“Interface A” of ZigBee platform could be summarized in Figure 3-2.

Figure 3-2: ZigBee Location profiles (interface A - commands implemented)

3.1.1.1 Configuration

WHERE2 location profile is formed by three different types of logical nodes:

the dongle (hosted in the coordinator),


Page 18 (101)

the base stations (nodes with known position also called anchors or reference nodes)

and the mobile node (the node which position is estimated, also called blind node).

Different parameters can be modified through this interface. The configuration parameters of a

mobile node are described in Table 3-1.

Table 3-1: Configuration parameters of a mobile node

Description Unit Valid Range Default Value

Parameter A Absolute signal power at one

meter distance dBm [0 - 60] 30

Parameter N Path loss exponent (N=5 Free

Space) - [0 - 30] 20

Operation

Mode

POLLED. Waits for Blind Node

Request to do a find and

response

AUTO. Automatically initiate a

location find and response

- [Auto, Polled] Auto

Collect Time

Time to wait for Reference

Node response after sending the

request

100ms [0 - 100] 2

Cycle Time

Time to wait before starting

calculation cycle. (Only in Auto

mode)

100ms [0 - 100] 5

Report

Short Node

Destination address for Blind

Node Response messages in

Auto Mode

- -

Report

Endpoint

Destination endpoint for Blind

Node response message in Auto

Mode

- [1 - 240] 203

Min

Reference

Nodes

Minimum Reference Nodes

used to calculate the location - [3 - 10 ] 3

Led Switch on /off a led - [ON, OFF] OFF

Button Indicate if a button is pressed or

not -

[PRESSED,

NOT_PRESSED] NOT_PRESSED

Version Firmware version - - -

RSSI Status

Enable/disable the option to

generate RSSI measures with

the rest of the nodes in the

network

- [ON, OFF] OFF

RSSI Time

If RSSI measurement is

enabled, this time indicates the

RSSI measurement cycle time

(in 100ms units).

100ms - 10

The configuration parameters of a base station can be summarized in Table 3-2:

Table 3-2: Configuration parameters of a base station

Description Unit Valid Range Default

Value

ACO_RefPosX X coordinate (relative position) of

the base station m [0-64] -


Page 19 (101)

ACO_RefPosX Y coordinate (relative position) of


ACO_RefPosZ Z coordinate (relative position) of


Led Switch on/ off a led. Indicates its

current status, on / off - [ON, OFF] OFF

Button Indicate if a button is pressed or

not -

[PRESSED,

NOT_PRESSED]

NOT_PRES

SED

Version Firmware version - - -

RSSI Status

Enable/disable the option to

generate RSSI measures with the

rest of the nodes in the network

- [ON, OFF] OFF

RSSI Time

If RSSI status is enabled, this time

indicates the RSSI measure cycle

time (in 100ms units).

100m

s - 10

Also other configuration parameters referred to the coordinator of the network exist and they

can be setup by the users. These parameters are related with the serial port settings and some

internal parameters defined in order to manage the ZigBee network.

Table 3-3: Configuration parameters of the coordinator/network

Description Unit Valid Range Default

Value

Serial Port Serial port Name - [COM1, ...] COM3

Serial Baud

rate Speed, data rate in bits per second bps - 38400

Serial Data

bits

The number of data bits in each

character Bits [5 - 9] 8

Serial Parity Parity is a method of detecting errors

in transmission -

[None, Odd,

Even, Mark,

Space]

None

Serial Stop

Bits

Sent at the end of every character

allow the receiving signal hardware

to detect the end of a character and to

resynchronise.

Bits [One, Two,

OnePointFive] One

Serial

Handshake

Hardware flow control. Signals in the

interface to pause and resume the

transmission of data

-

[None,

XOnXOff,

RequestToSend]

Request

ToSend

Timer

Reference

Setup

Step time to send broadcast frames

asking for base station nodes. Used in

discovery process

ms - 20000

Timer Blind

Setup

Step time to send broadcast frames

asking for mobile nodes. Used in

discovery process

ms - 20000

Timer

Sensors

Step time to request data from inertial

sensors. ms - 5000

Timer Ping Step time to check the connectivity

with the coordinator. ms - 15000

Timer

Remove

Time since the last frame received

from a node before removed from the

network.

ms - 20000


Page 20 (101)

Frequency

channel

Operation in the unlicensed

2.4 GHz. Sixteen channels are

allocated with 5 MHz of bandwidth

per channel.

- [11-26] 15

Pan ID Personal Area Network identifier - [0-65535] 65535

Update

position

directly

ZigBee network provide RSSI values

and also preliminary position

estimation. False value indicates that

the position is store only in the DB.

True indicates that the position

estimation will also be provided to in

the User Interface

bool [True, False] True

3.1.1.2 Information provided by the platform

WHERE2 ZigBee platform provide different information to the common framework,

localization estimations, RSSI measurements, and inertial data from different sensors

(accelerometers, gyroscopes and magnetometers).

The following parameters are provided by mobile nodes of the WHERE2 ZigBee Network. The

(X, Y, Z) coordinates indicate the estimated position of the mobile node obtained by the

embedded localization algorithm. The time stamp is included by the host PC when the data is

received.

Table 3-4: Localization information received from mobiles nodes

Description Unit Valid

Range

Default

Value

Timestamp Time of the estimated position set by the host PC time - -

X X coordinate (relative position) m [0-64] -

Y Y coordinate (relative position) m [0-64] -

Z Z coordinate (relative position) m [0-64] -

The following parameters are provided by each node in the network (if RSSI status is enabled).

The value of the RSSI is a measurement done between one node (the node that sends the

primitive) and the other nodes in the network. The time stamp is included by the host computer

when the data is received.

Table 3-5: Link measurements information provided by ZigBee nodes


Range

Default

Value

Timestamp Time of the data received set by the host PC time - -

PeerID List with the short address of the nodes which

measurements have been received - - -

RSSI

List with the Received Signal Strength

Indicator, measurement of the power present

in a received radio signal.

dBm - -

The following parameters are dynamic parameters provided by mobile nodes that are connected

to a inertial sensor board. The completed ZigBee network will be composed by at least 4 fixed

nodes and one or two mobile devices connected to an inertial sensor board.

http://en.wikipedia.org/wiki/Hertz

http://en.wikipedia.org/wiki/Megahertz


Page 21 (101)

Table 3-6: Inertial information provided by mobile nodes


Range

Default

Value

Timestamp Time of the data received set by the host PC time - -

ACO_MagX Magnetometer X component gauss - -

ACO_MagY Magnetometer Y component gauss - -

ACO_MagZ Magnetometer Z component gauss - -

ACO_AccX Accelerometer X component g - -

ACO_AccY Accelerometer Y component g - -

ACO_AccZ Accelerometer Z component g - -

ACO_GyroX Gyroscope X component deg/s - -

ACO_GyroY Gyroscope Y component deg/s - -

ACO_GyroZ Gyroscope Z component deg/s - -

ACO_Temp Temperature value provided by the mobile

node ºC - -

ACO_Pitch [Elevation]: Lateral axis, transverse axis, or

pitch axis. Axis running from the left to right deg - -

ACO_Roll [Bank]: Longitudinal axis, or roll axis deg - -

ACO_Raw

[Heading]: Vertical axis, or yaw axis, an axis

drawn from top to bottom, and perpendicular

to the other two axes

deg - -

3.1.2 UWB Interface

3.1.2.1 General system information

The UWB network is composed of nodes which are able to perform precise ranging

measurements thanks to the IR-UWB modulation used. The nodes include a custom RF/analog

front-end IC, an FPGA dedicated to MAC layer real-time features, and an ARM processor for

embedded software MAC and Application layers.

The UWB network management is highly inspired from IEEE 802.15.4 standard (ZigBee). A

coordinator node controls association/removal of other nodes to/from the network and

supervises all network communication activity. All UWB nodes are identical and can be

indistinctively interchanged, as long as a node-specific configuration file is provided, which

fully determines the node behaviour. Configuration information consists of the following

restricted set of parameters:

coordinator / simple device

mobile / anchor

MAC address

The application layer developed is dedicated to localization and tracking. The network is

composed of several mobile and anchor nodes, according to their initial configuration set. All

mobile nodes are requested to perform a ranging procedure with all other network nodes in turn,

in order to get mobile-to-mobile and mobile-to-anchor distance estimations. Anchor nodes are

not requested to perform ranging with each other as their position is supposed to be known. All

network measurements are centralized by the coordinator in order to make them available to a

host computer.


Page 22 (101)

3.1.2.2 Information provided by the platform

The following metrics are provided by each mobile node of the UWB network. They correspond

to the metrics from the inertial sensors embedded on each UWB node. These metrics are

obviously irrelevant for anchor nodes and are therefore not made available for this kind of node.

Table 3-7: Inertial sensors metrics provided by the UWB mobile nodes

Description Non-valid data indicator

Timestamp Local UWB network timestamp -1

MagX Magnetometer X component -

MagY Magnetometer Y component -

MagZ Magnetometer Z component -

AccX Accelerometer X component -

AccY Accelerometer Y component -

AccZ Accelerometer Z component -

GyrX Gyroscope X component -

GyrY Gyroscope Y component -

GyrZ Gyroscope Z component -

The following metrics are provided for each communication link established between a specific

mobile node and any other node of the UWB network. Note that no measurements are provided

by anchor nodes, as it would be redundant information for mobile nodes localisation purpose.

Table 3-8: Link metrics provided by the UWB mobile nodes


Range

Non-valid data

indicator

Timestamp Local UWB network timestamp time - -1

Distance Ranging metric m - -

BER Bit Error Rate - [0;1] -1

FER Frame Error Rate - [0;1] -1

CIR Channel Impulse Response - [0;255]

per sample -

A local timestamp generated by the UWB coordinator is provided along with the measurements.

This timestamp is only relevant regarding the UWB network, as it corresponds to the local time

base of the UWB network, and it should not be related to the common timestamp computed by

the Common Framework and provided in the WHERE2 database. It is used to detect and

indicate the obsolescence of the corresponding metrics stored on the UWB nodes when fetching

the data. It should be underlined that a negative value is used for this timestamp to indicate that

the requested metric is either obsolete or unavailable. This happens for example when

requesting data from an anchor node, or from a non-existing pair of nodes. Negative values are

also used for BER and FER to indicate unavailability of the metrics, which happens for example

if the averaging time is too short.

3.1.2.3 Interface with the Common Framework

A USB link is used to connect the coordinator node to the computer hosting the WHERE2

Common Framework. A specific set of APIs is provided to the Common Framework as a


Page 23 (101)

dynamic library, to fetch all useful network information and measurements from the coordinator

node. It is reminded that all measurements carried out by any of the network nodes is made

available on the coordinator side. The following table describes the APIs used.

Table 3-9: UWB network APIs description

Description Parameters

GetNodeList()

Get

information

about UWB

associated

nodes

NbNodes (out): Number of associated nodes in the UWB

network.

NodeIds (out): List of associated nodes MAC address.

NodeTypes (out): List of mobile/anchor characteristic of

associated nodes.

GetSensorData()

Get sensor

metrics from a

specific UWB

node

NodeId (in): MAC address of the UWB node.

SensorValues (out): Sensor metrics of the requested node.

GetLinkData()

Get link

metrics for a

specific pair of

UWB nodes

SourceNodeId (in): MAC address of the ranging

procedure initiator.

DestNodeId (in): MAC address of the ranging procedure

recipient.

LinkValues (out): Link metrics of the requested node pair.

The metrics provided by the UWB nodes (Table 3-7 and Table 3-8) are periodically fetched by

the Common Framework. They are formatted according to the WHERE2 database requirements,

and labelled with a timestamp common to all low-level platforms, which replaces the local

UWB network timestamp.

3.1.3 Interface for OFDM-based RTD test-bed – Cooperative test-bed


The cooperative test-bed based on round-trip delay (RTD) with an analog amplify and forward

(AAF) scheme consists of two nodes, see Figure 3-3. Each node is comprised of a full-duplex

radio-frequency (RF) front-end (FE) and a commercial off-the-shelf (COTS) FPGA board

serving as a data grabber. The master node initiates transmission of an OFDM frame, whereas

the slave node mirrors the signal back, without any processing in digital domain. Both nodes are

unsynchronized. The forward link is set to 5.5 GHz and the return link to 5.7 GHz. With this

frequency configuration, we do not interfere with commonly used lower 5 GHz WiFi channels.

Figure 3-3: Overview of DLR’s cooperative test-bed.

This test-bed uses OFDM modulated signals, see the summarized parameters in Table 3-10. The

analog bandwidth of the front-end is approximately 40MHz. Due to the used scheme, we

experience band-edge insertion losses four times (master Rx – slave Rx – slave Rx – master

Rx). Thus, we limit the used bandwidth to approximately 36MHz.


Page 24 (101)

Table 3-10: Summary of OFDM parameters for the RTD test-bed.

Parameter name Notation Value

Sampling frequency fs = Ts-1

120 MHz

FFT length N 8192

Subcarrier spacing fsc = (N∙Ts)-1

~14.65 kHz

Max. used number of subcarriers Nu 2500

Effective bandwidth fsc∙Nu ~36.62 MHz

Cyclic prefix length CP 1024∙Ts

Master node Tx power PTx ~100mW – 150 mW

Number of symbols per frame -- 4

Each ranging frame consists of four OFDM symbols which are defined as follows, see also

Figure 3-4. The first symbol is composed of the first out of three primary synchronization

symbols as defined in 3GPP-LTE. This narrowband signal is used for debugging purposes and

to adjust the gain control. The unused subcarriers are set to zero and the PSS symbol is

normalized to 1. Thus, the full transmit power is divided over the allocated subcarriers for the

PSS.

Figure 3-4: OFDM framing for the RTD test-bed.

The second symbol is empty, in order to simplify receiver noise floor estimations for a later

SNR or SINR (signal to interference and noise ratio) estimation. The third symbol is actually

used for ranging. It is composed of a full block-type synchronization symbol where we use a

QPSK-mapped PRN sequence which is then mapped on the subcarriers. See Figure 3-5 for the

simplified allocation scheme. Measurements with the used RF-FEs showed some residual signal

power around DC which might be a result of LO leakage.

Due to the currently built test-bed we cannot calibrate this possible LO leakage. We therefore

use some virtual carriers around DC to blank this part of the spectrum out. Furthermore, in

terms of accuracy determined by the Cramér-Rao lower bound (CRLB), inner subcarriers

around DC have no significant contribution to the overall accuracy. The freed power from those

inner virtual subcarriers is then also divided over the allocated subcarriers, such that the overall

symbol is again normalized to a power of 1.

Figure 3-5: Allocated subcarriers for the ranging symbol.


Page 25 (101)

The fourth symbol is a comb-type synchronization symbol to estimate the SINR in a simplified

way. Every single subcarrier is separated by 10 virtual carriers.

Figure 3-6: Allocated subcarriers for the comb-type synchronization symbol.

3.1.3.2 Estimated parameters for WHERE2 database

The RTD test-bed does not provide any sensor information like, e.g., INS, magnetometer etc. It

provides link measurements between the master node and the slave node only. Table 3-11

shows all estimated parameters obtained from the RTD master node.

Table 3-11: Link measurement parameters from the RTD test-bed.

Parameter Description Unit Expected

range

Non-valid

data indicator

DLR_PeerID Link identifier, always

set to 1

--,

integer -- --

DLR_RTD Round trip distance [m],

double [0.5,40.0] 0.0

DLR_SNR Signal to noise /

interference ratio

[dB],

double [-10.0,30.0] 100.0

DLR_RSSI Received signal

strength indicator

[dBm],

double

No evaluated

yet 100.0

DLR_coop_CIR_Real

Real part of the

complex round-trip

channel impulse

response

-- -- All amplitude

values are 0.0

DLR_coop_CIR_Imag

Imaginary part of the

complex round-trip

channel impulse

response

-- -- All amplitude

values are 0.0

Parameter DLR_RTD holds the round-trip distance (due to naming convention). Thus, this

value must be divided by two to get the true range between the master node and the slave node.

The values for DLR_RTD in the database are already compensated for internal delays etc. and

represent the true round-trip distances over the air interface. In a first version, this distance is

estimated with a single-tap correlation receiver with incoherent peak detection. Thus this

estimate can be biased by multipath.

Parameter DLR_SNR holds the estimated signal to interference and noise ratio (SINR). First

measurements showed that the SNR only is not an appropriate figure of merit. We estimate the

noise based on the Null-symbol and the interfering power based on the virtual carriers between

the allocated subcarriers of the Comb-type synchronization signal. The signal power itself is


Page 26 (101)

estimated based on the allocated subcarriers of the Comb-type synchronization symbol and is

compensated by the estimated noise power. Typical values for cable-based measurements are

around 20dB.

Parameter DLR_RSSI holds the calculated received signal strength at the master node, which

corresponds to round-trip RSS. The initial transmit power is not known and calibrated. Thus, a

known reference point, e.g., master node and slave node at 1m distance, must be used to

estimate a power offset. The RSSI is calculated based on the ranging-block signal and we

account for gain settings in the master node and slave node. The true factors for the gain settings

are taken from the RF-FE chip datasheet and not additionally calibrated.

Parameters DLR_coop_CIR_Real and DLR_coop_CIR_Imag hold the real and imaginary part

of the round-trip channel impulse response (CIR). The channel frequency response is obtained

by least-squares (LS) estimation on the ranging-block signal in frequency domain. We then cut

out the used spectrum only, e.g., the very left subcarrier index minus one in Figure 3-5 until the

very right subcarrier of the allocated block, and use this amount of subcarriers as new FFT

length. This snapshot is then transformed into time-domain and represents the un-interpolated

CIR. The CIR string in the database contains amplitude values, not power values and the tap-

delays are in integer-multiples of the new sampling frequency. No super-resolution algorithm is

applied here. To correctly get the CIR, we use a back-off value of 40 chips at 120 MHz from the

symbol beginning, which will also be documented by an accompanying measurement

document.

3.1.3.3 Calibration

The RTD test-bed must be calibrated before a measurement, in order to compensate for internal

delays, insertion losses, phase distortions etc. The procedure is as follows:

a) Switch on the RF-FEs and let them run for approximately 15 minutes. This will let the

ovenized oscillators warm up and stabilize.

b) Perform dummy-ranging with true ranging signals to warm up the whole RF-FE chain

c) Use calibrated cables and attenuators to connect the master node and slave node

d) Grab at least 1000 snapshots, estimate the delay and phase of each snapshot and

coherently average all snapshots.

e) Take the coherently averaged snapshots as new reference signal for correlation and

channel estimation.

By using the averaged snapshots as new reference signal, we avoid equalizing the received

signal and also avoid colouring the noise floor which would occur by equalization.

3.1.3.4 Low-level interface A to WHERE2 common framework

The master node and the slave node are connected to the processing computer / notebook via a

local set up Gigabit Ethernet connection. This connection is used to acquire the snapshots from

the master node and configure both nodes at the same time. The processing computer serves as

client and the master node and the slave node both serve as server.

A second Ethernet connection is used to connect the running MATLAB instance on the

processing computer, with the common framework. The MATLAB instance serves as client and

the interface within the common framework serves as server. As a protocol over Ethernet, we

use JSON strings. This allows a simplified data transfer, data parsing and delivers enough

flexibility to quickly adapt to changes.

The RTD test-bed itself can deliver up to 15 full parameter estimate snapshots. This value

depends on the type range estimator and is currently valid for the correlation receiver

architecture. Once the MATLAB instance is connected to the common framework, it starts


Page 27 (101)

streaming all snapshots to the common framework. The server instance within the common

framework signals this by an event. The current database update rate however, is limited to 1

second. Thus, not all snapshots can be stored and some get dismissed directly. Thus, only the

latest available snapshot gets stored in the database. This has no impact on, e.g., any statistics.

All estimated parameters are snapshot based and each snapshot is completely independent from

another one. There are no hidden states or averaging functions in the MATLAB estimation

routine.

3.1.4 LTE Interface


This test-bed consists of four, pairwise synchronized base stations. This allows the estimation of

two independent TDoAs for positioning. Furthermore, up to two receivers might be available.

One FPGA boards generates the signals for two base stations. In the current setup, the two base

stations have an antenna cable length of up to 56m each. Thus they can be spatially separated by

about 100m.

The first transmitter pair, called Tx1 and Tx2 has a centre frequency of 2.415 GHz. The second

transmitter pair, called Tx3 and Tx4 has a centre frequency of 2.445 GHz. The bandwidth for all

transmitters is approximately 20MHz.

Table 3-12: Summarized OFDM parameters for the LTE-like test-bed.

Parameter name Notation Value

OFDM core symbol length N 1024

Cyclic prefix length CP 144

Base band sampling clock fc 20 MHz

Virtual subcarriers on each side of spectrum BVIRT 625 kHz

RF centre frequency fG 2.45 GHz

Pilot subcarrier spacing for one transmitter PSS 16 subcarriers

Pilot subcarrier offset between transmitters PSO 4 subcarriers

Frame length FL 32 OFDM symbols

Subcarrier spacing fSC fc/N ≈ 19.5 kHz

OFDM core symbol duration Tsc 1/fSC = 51.2 us

Cyclic prefix duration TCP CP/N = 7.2 us

Useable bandwidth BU fc – 2*BVIRT = 18.75 MHz

Figure 3-7 shows a sketch of the overall bandwidth and truly usable bandwidth for carrier

allocation and the not used side bands of BVIRT on each side of the spectrum.

Figure 3-7: Overall bandwidth and virtual subcarriers.


Page 28 (101)

The framing basically consists of the known SSCH codes, PSCH codes (Zadoff Chu) and some

scattered pilots (scattered in frequency domain). The SSCH and PSCH codes are orthogonal in

time between one transmitter pair to avoid interference. The scattered pilots itself are orthogonal

in frequency domain for all used transmitters. Figure 3-8 shows the basic framing in time

domain which will be used for further algorithm testing and adaption.

Figure 3-8: Framing for LTE demo in time domain.

The frame length FL is set two 32 (just 32 or 64 usable by the transmitter), thus five complete

subframes and two additional null symbols comprise a frame. Figure 3-9 shows the overall

frame with 32 OFDM symbols in time domain.

Figure 3-9: A complete 32 symbol frame for the test setup.

The occupied total bandwidth for the SSCH and PSCH codes is approximately 1.23 MHz (63

subcarriers), whereas the scattered pilots occupy the whole usable bandwidth. Figure 3-10

shows the pilot mapping in frequency domain. The pilots itself consist of QPSK mapped PRN

sequences where every transmitter gets its own initial bit mask.

Figure 3-10: Pilot mapping in frequency domain.

The subcarrier spacing between pilots of different transmitters is set to 4 to have enough

interference margins in case of high carrier frequency offsets between the FPGA boards.


Page 29 (101)

3.1.4.2 Estimated parameters for WHERE2 database

The two receivers do not provide any sensor information, but only link parameter estimates.

Each receiver estimates the pseudo-ToA ranges to each of the two pairwise synchronized base

stations and then calculates the TDoAs based on the pseudo-ToAs. Table 3-13 and Table 3-14

show the parameters, estimated by each of the two receivers.

Table 3-13: Link measurement parameters from each of the two “LTE” receivers for

the database table DLR_LTE_Measurements.


range

Non-valid data

indicator

DLR_CFO

Carrier frequency offset between

the receiver and base station with

ID DLR_BSID

[Hz],

double +- 100.0kHz 0.0

DLR_RSSI

Estimated received signal

strength for the signal from base

station with ID DLR_BSID

[dBm],

double

Not

evaluated

yet

100.0

DLR_SNR

Estimated SNR or SINR for the

signal from base station with ID

DLR_BSID

[dB],

double [-10.0,30.0] 100.0

DLR_BSID The ID of one of the four base

stations

[ ],

integer {1,2,3,4} 100

DLR_CIR_Real

Real part of the complex channel

impulse response for the pseudo

range link to base station with ID

DLR_BSID

-- --

All amplitude

values are set to

0.0

DLR_CIR_Imag

Imaginary part of the complex

channel impulse response for the

pseudo range link to base station

with ID DLR_BSID

-- --

All amplitude

values are set to

0.0

Table 3-14: Parameters for the database table DLR_LTE_TDoA_Table.


range

Non-valid data

indicator

DLR_TDoA_BSID

For TDoA we need a second

base station. This is the ID of

the second base station.

[ ],

integer {1,2,3,4} 100

TDoA

The estimated TDoA value

converted to meters between

the base station with ID

DLR_BSID and base station

with ID DLR_TDoA_BSID

[m],

double +-100.0 1e3

The TDoAs are only valid for the base station pairs 1-2 and 3-4. We estimate the pseudo-ranges

and calculated the TDoAs as follows: pseudo range BS 1 minus pseudo range BS 2 gives us the

TDoA for the first base station pair. Pseudo range BS 3 minus pseudo range BS 4 gives us the

TDoA of the second base station pair.

Parameter DLR_CFO holds the carrier frequency offset between the receiver and the base

station with ID DLR_BSID. It might not be useful for positioning, but is useful for us for

debugging purposes.


Page 30 (101)

Parameter DLR_RSSI holds the estimated received signals strength for the link between the

receiver and the base station with ID DLR_BSID. Note that his estimate is not calibrated and a

known reference point must be used to calibrate the initial transmit power.

Parameter DLR_SNR holds the estimated SNR or SINR for the pseudo range link between the

receiver and the base station with ID DLR_BSID. The SNR for the final TDoA value must then

be calculated appropriately, based on the two SNR/SINR values for the pseudo ranges.

Parameter DLR_BSID holds the ID of the four base stations. It can only be one of the four

values {1, 2, 3, 4}. 1 and 2 are synchronized as well as 3 and 4. Thus, we have two pairwise

synchronized base stations and can obtain two TDoAs only. For the real measurement setup

Parameter DLR_TDoA_BSID holds the base station ID of the second base station / the second

pseudo range link. Valid values are actually only 2 and 4 because of the pairwise synchronized

base stations.

Parameter TDoA finally holds the TDoA value, but already converted to meters. Due to the

measurement setup, we will limit the TDoA value to approximately 100m or 200m which helps

to detect outliers in our low level estimation. The pseudo range for each link is estimated with a

single-tap correlation receiver as for the RTD test-bed. The estimates are therefore biased by

multipath. Superresolution algorithms can use the stored CIR to refine this estimate.

3.1.4.3 Calibration

A calibration is required before measurements take place. The whole setup is briefly as follows:

a) Adjust DAC phases for all DAC channels (spectrum analyser is needed).

b) Switch on all RF devices and let them warm up for about 30 minutes.

c) Connect all four base stations with a power combiner and attenuators to each receiver.

Grab a sufficient number of snapshots and estimate calibration parameters.

3.1.4.4 Low-level interface A to WHERE2 common framework

Each of the two LTE receivers has its own Ethernet connection to the common framework. The

MATLAB instances running on the receivers and estimating the parameters serve as clients and

the common framework serves as server. As for the RTD test-bed, each receiver estimates

independent snapshots as fast as possible and streams them to the low level API of the common

framework. The scheduler in the common framework then takes the latest parameter set and

writes it to the database. As for the RTD test-bed, several parameter sets might get dismissed.

This has also no impact, because the parameter sets are self-contained and each set in

completely independent from each other. No averaging, tracking filter etc. is applied to the raw

estimates.

As protocol over Ethernet, we also use JSON strings but with different members compared to

the RTD test-bed.

3.2 Interface B (Base)

Through this interface, each platform (low level) provides a set of common

functionalities available to the Common API. The main functionality of the WHERE2

platform is to provide a set of measurements that can be used to estimate the position of

a node in order to store in a common data base and an estimated position of the mobile

terminal if available. As shown in Figure 3-11, a common base class for the existing low


Page 31 (101)

level platforms have been implemented in other to provide basic functionalities such as,

multithreading, link measurement tables, nodes list…

Figure 3-11: Classes that implements interface B

A "Where2 Platform" must implement this interface in order to allow integration with

the Common Framework. The functions defined by this interface are listed in the

following table:

Table 3-15: Interface B methods

Description

Open Open this instance.

Close Close this instance.

CommmitNodeParameters Commit of the modifications in the parameters of a node

GetAllLinkMeasure Get link measure table.

GetLinkMeasure Gets the latest link measure data from source node to the rest of

nodes.

GetLinkMeasure Gets the latest link measure data from source to destination node.

RemoveNode Request the removal of a node.

SetLinkMeasure Update a link measure from a source to a destination node.

TriggerLinkMeasure Triggers the update of a link measure and returns it. Used mainly

in Trigger mode.

TriggerNodeMeasure Triggers the update of a node measure and returns it. Used mainly

in Trigger mode.

UpdateNodeParameters Updates the node parameters with the actual value obtained from

the node.

In the same way, a minimum set of properties and events should implemented by all the

WHERE2 platforms.

The main properties refers to the environment (real or simulated), the list of connected nodes in

the network, the parameters of the platform (if any), and the database logging status (enable or

disable) for the information generated by that platform.


Page 32 (101)

The events fired by the interface can be used for example in the user interface to update the

information presented in the screen. Most of the events are related with the nodes (new node,

remove node, node update). Also two events related with the measures exist. Two types of

measures have been defined, the sensor and the link measures. Both events, MeasureUpdate and

LinkMeasureUpdate, indicated that a new measure of sensor or link is available respectively.

Table 3-15 summarizes the methods, the properties and the events that must be defined by all

the platforms in order to provide the information to the common framework and implement

Interface B.

Figure 3-12: Interface B (properties, methods and events)

3.3 Interface C (Cooperative)

The main functionality of interface C is to provide a common interface that all the partners

could use to retrieve data from low level platforms and provide location solutions. This interface

is the same that the Common Framework with WHERE2 database in order to insert and read


Page 33 (101)

data generated by the different WHERE2 platforms. The interface is logically implemented

using a SQL Server database that provides a standard SQL interface. For this propose, taking

into account that .NET has been selected for the WHERE2 Common Framework, the language

chosen to access this SQL interface is the LINQ (Language-Integrated Query) working with

Entity Objects. However

LINQ offers a set of extensions to the .NET Framework extends C# with native language syntax

for queries and provides class libraries to take advantage of these capabilities.

LINQ to Entities is considered to be one of Microsoft's new ORM (Object-Relational Mapping)

products. It is a programming technique that contains a set of classes that map relational

database entities to objects in a specific programming language.

With ORM, each database is represented by an ORM context object in the specific

programming language, and database entities such as tables are represented by classes, with

relationships between these classes. The ORM is responsible for the mappings and the

connections between these classes and the database. So, to the application, the database is now

fully-represented by these classes. The application only needs to deal with these classes, instead

of with the physical database. The application does not need to worry about how to connect to

the database, how to construct the SQL statements, how to use the proper locking mechanism to

ensure concurrency, or how to handle distributed transactions. These database-related activities

are handled by the ORM. [4]

Once all the classes needed to work with the database has been generated, some methods have

been implemented in order to access the interface C from the user interface developed to test

the Common Framework. The summary of these helper methods is presented in Table 3-16.

Table 3-16: Methods to access the WHERE2 database from the application.

Description

DBAddAlgorithm Add new algorithm to DB.

DBDeleteAlgorithm Delete algorithm from DB.

DBGetAlgorithm Gets one algorithm from DB.

DBGetAlgorithmPosition Gets the position from a specific algorithm in the

DB.

DBGetDefaultTrolley DBs the get default trolley and creates it if

necessary.

DBGetStats Get the Where2 DB entries count for all tables.

DBGetTrolleyByDescription DBs the get the trolley by its description or create

if it does not exist

DBGetTruePositions Gets the true positions from the DB.

DBRemoveAll Remove all entries from all tables. Does not

reinitialize the auto increment indexes.

DBTest Performs a read test in the Where2 DB to check

for connection.

DBTest Test DB connections.

DBUpdateAlgorithm Update the DB with the algorithm information.

DBUpdateAllNodes DBs the update all nodes parameters in

Where2DB and create them if necessary.

DBUpdateConnectionString Update the Where2DB connection string.


Page 34 (101)

DBUpdateNode

Update a node instance from the Where2DB

given its unique node name and a Where2 Node

object.

DBUpdateNodePositionFromAlgorithmLastKnown Gets the last known position from a specific

algorithm in the DB for all the available nodes.

To insert the data received from the WHERE2 platforms two events have been create,

InitDBLogging and EndDBLogging. These events are currently fired from the UI when selecting

the option to start/stop the logging to the WHERE2 data base.


Page 35 (101)

4. Database

Figure 4-1: WHERE2 Demonstration Architecture


Page 36 (101)

Provision has been made so that the database supports two modes of operation:

Trigger mode: the database will be trained offline and will be made available for

testing the algorithms offline

Demo: To demonstrate the overall architecture based on the two demonstration

scenarios:

o Vertical Handovers (VHO) using SIGINTs IP Mobility platform and the

position based VHO algorithm implementation from UoA (see section 6.1.2)

o Context-based service Application scenario from PTIN (see section 0)

The exchange of context with the database is achieved through a number of interfaces which

either access the data directly or through the common framework which acts as a proxy. These

interfaces which are depicted in Figure 4-2 are:

Interface A (Adaptor) is the one that provides the communication between each

terminal device and the host computer. This interface is defined and implemented by the

owner of each platform. The main functionality of this interface is the management of

the data communication between the platforms and the host. (see section 3.1)

Interface B (Base) is the one between the common framework, and each platform

API/driver. This interface is defined between all the partners depending on the

capabilities of each platform. Interface B is the interface that all the WHERE2 platforms

expose to the common framework API. (see section 3.1.4.1)

Interface C (Cooperative) manages the communication between the common

framework and the database. The common framework will be used by the central host

and to monitor the platforms and access (insert/retrieve) the information into the

database. This interface is implemented via a standard method of communication by

exposing a rich SQL query interface to the web. (see section 3.3)

Interface D is a Bi-directional interface between the database and the positioning

algorithms (WP2). They receive the context and update the position into the database.

Interface E is the interface through the IP-mobility and PTIN platforms receive the

estimated position from the database and use it inside their algorithms.

There is also data provision in the database to be trained with Ray Tracing Simulation data for

the synthetic environment in Task 2.3. Initially this data have been provided into a MATLAB

structure for algorithm-testing purposes but the requirement of the project was to include it into

common WHERE2 database. In Figure 4-2, the architecture presented previously has been

summarized by showing the main functional blocks and their interfaces for a demo scenario.


Page 37 (101)

Figure 4-2: Communication within the WHERE2 Architecture

4.1 Design

The database has been implemented in Microsoft SQL based on the schemas shown in Figure

4-3 and Figure 4-4. Figure 4-3 shows the schema of the database which contains positioning

context coming from the positioning platforms from DLR, ACORDE and CEA. These

platforms have been described in detail in deliverable D4.1, but briefly:

ACORDE ZigBee-based platform is a wireless communication platform working at 2.4

GHz, aimed for smart wireless sensor networks. It is composed by two core elements,

the MSP430 micro-processor, which takes the responsibility of the interfaces between

the radio and the upper layers, the sensors and the external interface to communicate

with a PC when the device is configured as Access Point or coordinator. The radio core

is based on the CC2431, a true single-chip 2.4 GHz IEEE 802.15.4 compliant RF

transceiver designed for low-power and low-voltage wireless applications. Some nodes

of this platform (mainly mobiles nodes) are equipped with inertial sensors in order to

improve the ranging information provided to the location algorithms.

The platform provided by CEA is an Impulse Response Ultra Wide Band (IR-UWB)

based system, well suited for sensor network deployment. It allows Low Data Rate

(LDR) data transmission, as well as location and tracking features based on round trip

delay (RTD) measurements between peer-to-peer devices. Each node can be configured

either as a fixed or as a mobile device, according to the demonstration scenario

requirements. The data exchange requires an underlying centralized topology network,


Page 38 (101)

for which one of the devices is configured as the coordinator, and the others as simple

devices.

DLR provides two different platforms.

o The first platform is a flexible LTE test-bed to estimate a mobile terminal’s

position with TDoAs. It consists of four, pairwise synchronized base stations

and two mobile receivers. Each receiver can then estimate two TDoAs.

o The second platform is called the cooperative test-bed. It’s comprised of two

additional mobile nodes with full-duplex RF-FEs in the 5 GHz band to allow

RTD between those two nodes. This test-bed also uses OFDM modulated

signals but with an effective bandwidth of up to 36 MHz. These two RTD-

nodes are then mounted on the same place where the LTE receivers are located.

This allows a joint test-bed to receive LTE-like signals and perform RTD-based

ranging between those two combined test-beds.


Page 39 (101)

Figure 4-3: Database schema for positioning-based context from DLR, CEA and ACO

Measurements

Deployment Positioning


Page 40 (101)

Figure 4-4 shows the schema of the part of the database that is used to hold simulated data in the

synthetic environment which has been generated using Ray Tracing Simulations by SIGINT

Solutions, SIRADEL and University of Rennes.

Figure 4-4: Database schema for Task 2.3 Ray Tracing simulations

4.2 Database tables details

In this subsection a summary of the database tables’ content is detailed for better understanding

of the overall responsibilities and relations between the different data structures.

MeasurementDetails Table

This table contains static information about the measurement campaign. It only contains one

entry that describes the current scenario where all the measurements for this database instance

have been performed.

Table 4-1: Trolleys Table Description

Entry Name Data Type Description

MeasurementID Integer Uniquely identifies the measurement. Private Key

MeasurementDescription Char(1000) Description of the measurement


Page 41 (101)

MeasurementLocation Char(100) The location of the measurement

MeasurementDate Datetime The Date and time of the measurement

Trolleys Table

This table identifies the trolleys (mobile users) in the demonstration scenario and manages the

grouping of platforms. Each trolley is basically a mobile user in the demonstration scenario who

is equipped with a multi-technology terminal supporting heterogeneous radio access

technologies (ZigBee, LTE or UWB). Each trolley might physically carry a number of nodes

(heterogeneous) and that is why the node table has a FK to this table.

Table 4-2: Trolleys Table Description


TrolleyID Integer Uniquely identifies the trolley. Private Key

TrolleyDescription Char(1000) Description of the trolley

Nodes Table

This Nodes table identifies the nodes (mobile users) in the demonstration scenario. The nodes

are the basic entities that compose each positioning platform and may be grouped on trolleys

(e.g. a ZigBee Node, an inertial sensor, LTE receiver etc.).

Table 4-3: Nodes Table Description


NodeID Integer Uniquely identifies the node. Private Key

TrolleyID Integer The ID of the trolley that the node sits on. Foreign Key

NodeName Char(20) The name of the Node

NodeOwner Char(10) The owner of the Node (ACO,CEA, DLR, EUR)

NodeDescription Char(1000) A description about the node

NodeOwnerID Integer The ID of the Owner (1:ACO 2:CEA, 3: DLR, 4:EUR)

MobileOrAnchor Integer Identifies whether the node is mobile or an anchor (0: for

mobile and 1: for anchor)

Position Table

The Position Table hosts the time-stamped estimated position of every node in the architecture.

The X, Y, Z coordinates are estimated with regards to an absolute reference point which is

defined in the reference point table using the algorithm which is defined in the algorithm table.


Page 42 (101)

Table 4-4: Position Table Description


PositionID Integer Uniquely identifies the estimated position. Private Key

NodeID Integer The ID of the node which is positioned (FK to the node

table)

ReferencePointID Integer The ID of the reference point with respect which X,Y,Z

where estimated (FK to the reference point table)

AlgorithmID Integer The ID of the algorithm that was used to estimate the

position (FK to the algorithm table)

X Double The relative (to the reference point) X coordinate (in

meters)

Y Double The relative (to the reference point) Y coordinate (in

meters)

Z Double The relative (to the reference point) Z coordinate (in meters)

timestamp Datetime The time the position was estimated

TruePosition Table

The TruePosition Table hosts the real (true) position of every node in the network. The X, Y, Z

coordinates are provided with regards to an absolute reference point which is defined in the

reference point table using the algorithm which is defined in the algorithm table. It will be

mainly used in the trigger mode to evaluate the accuracy of the positioning algorithms

Table 4-5: TruePosition Table Description


TruePositionID Integer Uniquely identifies the true position of the node. Private

Key

NodeID Integer The ID of the node (FK to the node table)

ReferencePointID Integer The ID of the reference point with respect which X,Y,Z

where provided (FK to the reference point table)

X Double The relative (to the reference point) X coordinate (in

meters)

Y Double The relative (to the reference point) Y coordinate (in

meters)

Z Double The relative (to the reference point) Z coordinate (in meters)

timestamp Datetime The time the position was provided

ReferencePoint Table

The ReferencePoint Table contains the reference points, real absolute coordinates, with respect

which the X, Y, Z entries in the Position table and the TruePosition table are provided.

Longitude, Latitude and Height are provided in decimal degrees and meters.


Page 43 (101)

Table 4-6: ReferencePoint Table Description


ReferencePointID Integer Uniquely identifies the reference point. Private Key

ReferencePointDescription Char(1000) Description of the reference point

Longitude Double The longitude of the reference point in decimal

degrees

Latitude Double The latitude of the reference point in decimal degrees

Height Double The height of the reference point in decimal degrees

Algorithm Table

The Algorithm table contains the different location algorithms used to estimate the user

position. A detailed description and a WHERE2 partner identifier that has implemented the

algorithm are included in this table

Table 4-7: Algorithm Table Description


AlgorithmID Integer Uniquely identifies the algorithm. Private Key

AlgorithmDescription Char(1000) Description of the algorithm

AlgorithmDeveloper Char(10) The algorithm Developer

ACOLinkMeasurements Table

The table contains the RSSI values collected by each ACO node (between each other)

Table 4-8: ACOLinkMeasurements Table Description


ACOLinkMeasurementID Integer Uniquely identifies the measurement. Private Key

NodeID Integer The ID of the Node that received the signal.

Foreign Key to the Nodes Table

ACO_PeerID Integer The ID of the Peer Node that transmitted the

signal. Foreign Key to the Nodes Table

ACO_RSSI Double The Received Signal Strength Indication (RSSI)

received by the Node

Timestamp Datetime The time the RSSI measurement was taken

ACOSensorMeasurements Table

The table contains the inertial measurements collected by each ACO mobile node that has been

extended with an ACO inertial board. An estimation of the attitude of the inertial board (pitch,

roll, and yaw) is also included in this table.


Page 44 (101)

Table 4-9: ACOSensorMeasurements Table Description


ACOSensorMeasurementsID Integer Uniquely identifies the measurement. Private Key

NodeID Integer The ID of the Node made the measurements.


ACO_AccX Double Accelerometer X component

ACO_AccY Double Accelerometer Y component

ACO_AccZ Double Accelerometer Z component

ACO_GyroX Double Gyroscope X component

ACO_GyroY Double Gyroscope Y component

ACO_GyroZ Double Gyroscope Z component

ACO_MagX Double Magnetometer X component

ACO_MagY Double Magnetometer Y component

ACO_MagZ Double Magnetometer Z component

ACO_Temp Double Temperature

ACO_Pitch Double Pitch

ACO_Roll Double Roll

ACO_Yaw Double Yaw

Timestamp Datetime The time the inertial measurements were taken

The table contains UWB measurements collected between CEA nodes including an estimation

of ranging in meters, quality link indicators and channel input response.

CEASensorMeasurements Table

The table contains the inertial measurements collected by each CEA node

Table 4-10: CEASensorMeasurements Table Description


CEASensorMeasurementID Integer Uniquely identifies the measurement. Private Key

NodeID Integer The ID of the Node made the measurements.


CEA_AccX Double Accelerometer X component

CEA _AccY Double Accelerometer Y component

CEA _AccZ Double Accelerometer Z component

CEA _GyroX Double Gyroscope X component

CEA _GyroY Double Gyroscope Y component

CEA _GyroZ Double Gyroscope Z component

CEA _MagX Double Magnetometer X component

CEA _MagY Double Magnetometer Y component


Page 45 (101)

CEA _MagZ Double Magnetometer Z component

Timestamp Datetime The time the inertial measurements were taken

CEALinkMeasurements Table

The Table contains UWB measurements collected between CEA nodes

Table 4-11: CEALinkMeasurements Table Description


CEALinkMeasurementID Integer Uniquely identifies the measurement. Private Key

NodeID Integer The ID of the Node that received the UWB signal.


CEA_PeerID Integer The ID of the Node that transmitted the UWB signal.


CEA_Dist Double Distance between the node and the peer node

CEA _BER Double Bit Error Rate

CEA _FER Double Frame Error Rate

CEA _CIR Char(1000)

Channel impulse response received by the node from

the Peer Node. It is defined as a string (for hard disc

space issues and simplicity) with the following format

(comma separated values):

“CIR, NoOfComponents, time1, componentPower1,

time2, componentPower2,…, timeN,

componentPowerN”

CIR identifies that this is a Channel

Impulse Response

NoOfComponents is an integer which

identifies how many received paths

constitute the impulse response

TimeX time (in nanosec) of the received

component (path)

componentPower the power (in dBm) of

the received component (path)

e.g. for 3 components: “CIR,3,0, -78,10,-59,20,-60”

Timestamp Datetime The time the measurements were taken

DLR_COOP_Measurements Table

The table contains cooperative measurements collected between DLR nodes including ranging

information using time and power metrics as well as the complex channel input response.

Table 4-12: DLR_COOP_Measurements Table Description


Page 46 (101)


DLR_Coop_Meas_ID Integer Uniquely identifies the measurement. Private Key

NodeID Integer The ID of the Node that received the signal. Foreign

Key to the Nodes Table

DLR_PeerID Integer The ID of the Peer Node that transmitted the signal.


DLR_RTDcoop_CIR

_Real

DoubleChar

(1000)

The channel Impulse Response (CIR) real part. It is

defined as a string with the following format (comma

separated values):

“CIR, NoOfComponents, time1, componentRealPart1,

time2, componentRealPart2, …, timeN,

componentRealPart N”


Impulse Response


identifies how many received paths constitute

the impulse response


component (path)

componentRealPart real part of the

received component (path)

e.g. for 3 components: “CIR,3,0,

0.2,10,0.04,20,0.1”Round Trip Delay

DLR_

coop_CIR_Imag Char(1000)

The CIR Imaginary part. Similar as the real part but

contains the imaginary part of the components of the

impulse response.

DLR_RTD Double Round Trip Delay

DLR_RTD_RSSI Double RSSI Received

DLR_SNR Double SNR


DLR_LTE_Measurements Table

ThistableThe Table contains LTE measurements collected between DLR nodes and DLR LTE

Base stations.

Table 4-13: DLR_LTE_Measurements Table Description


DLR_LTE_Measurement

sID Integer Uniquely identifies the measurement. Private Key

NodeID Integer The ID of the Node that received the LTE signal.


DLR_BSID Integer The ID of the Node (Base Station) that transmitted the

LTE signal. Foreign Key to the Nodes Table

DLR_CIR_Real Char(1000) The channel Impulse Response (CIR) real part. It is

defined as a string with the following format (comma


Page 47 (101)

separated values):

“CIR, NoOfComponents, time1, componentRealPart1,

time2, componentRealPart2componentRealPart 2,…,

timeN, componentRealPart N”


Impulse Response


identifies how many received paths constitute

the impulse response


component (path)

componentRealPart real part of the


e.g. for 3 components: “CIR,3,0, 0.2,10,0.04,20,0.1”

DLR_CIR_Imag Char(1000)

The CIR Imaginary part. Similar as the real part but

contains the imaginary part of the components of the

impulse response.

DLR_CFO Double CFO

DLR_RSSI Double Received RSSI

DLR_SNR Double Received SNR


DLR_LTE_TDoA Table

The Table contains LTE Time Difference of Arrival (TDoA) measurements collected between

DLR nodes and DLR LTE Base stations

Table 4-14: DLR_LTE_TDoA Table Description


TDoA_MeasD Integer Uniquely identifies the measurement. Private Key

DLR_LTE_MeasurementsID Integer

The ID of the LTE Measurement that the TDoA

measurement refers to. Foreign Key to the

DLR_LTE_Measurements Table

DLR_TDoA_BSID Integer

The ID of the Node (Base Station) that the TDoA

was calculated. It is not the same as the BSID in the

DLR_LTE_Measurements Table since two Base

stations are needed for the calculation of the TDoA.


TDoA Double The estimated Time Difference of Arrival.

In order to populate the database a number of SQL stored procedures have been implemented.

These stored procedures which insert new values into the database or update the existing entries

are described in Appendix A.


Page 48 (101)

As mentioned earlier, WHERE2 database contains a subset of tables that is used in order to

populate them with Ray Tracing Simulations which have been carried out in Task 2.3. The

schema of this database part is shown in Figure 4-4 and their tables are detailed next.

Simulation Table:

This Simulation table is the parent of the schema and contains general information about the

simulation like description, simulator name, simulation environment and number of interactions

considered in the simulation (reflections, transmissions and diffractions)

Table 4-15: Simulation Table Description


simulationID Integer Uniquely identifies the simulation. Private Key

simulationDescription Char(2000) Description of the simulation

simulatorName Char(50) The name of the simulator used to generate the

database

noOfReflections Integer No of reflections considered in the simulator (-1

means unlimited)

noOfTransmissions Integer No of transmissions considered in the simulator (-1

means unlimited)

noOfDiffractions Integer No of diffractions considered in the simulator (-1

means unlimited)

simulationEnvironment Char(100) Description of the simulation Environment

Transmitters Table

Contains all the transmitters defined in the simulation. The stored information includes the

transmitter name, coordinates, transmitted power, bandwidth, frequency and antenna type.

Table 4-16: Transmitters Table Description


TxID Integer Uniquely identifies the Transmitter. Private Key

simulationID Integer Simulation to which the Transmitter is linked to. Foreign Key

TxName Char(50) The Name of the Transmitter

TxX Double The X coordinate of the transmitter (in meters)

TxY Double The Y coordinate of the transmitter (in meters)

TxZ Double The Z coordinate of the transmitter (in meters)

TxPower Char(10) The transmit power of the Transmitter (in dBm)

TxFrequency Double The frequency of transmission in Hz

TxBW Double The Bandwidth of transmission in Hz

TxType Char(50) The Type of the Transmitter antenna (e.g. isotropic, dipole ...)

Receivers Table

This table contains all the receivers defined in the simulation. The stored information includes

the receiver name, coordinates, receiver sensitivity and antenna type.


Page 49 (101)

Table 4-17: Receivers Table Description


RxID Integer Uniquely identifies the Receiver. Private Key

simulationID Integer Simulation to which the Receiver is linked to. Foreign Key

RxName Char(50) The Name of the Receiver

RxX Double The X coordinate of the Receiver (in meters)

RxY Double The Y coordinate of the Receiver (in meters)

RxZ Double The Z coordinate of the Receiver (in meters)

RxSensitivity Double The sensitivity of the Receiver (in dBm)

RxType Char(50) The Type of the Receiver antenna (e.g. isotropic, dipole etc.)

omniResults Table

This table contains the received parameters (Rx power and impulse response) assuming that the

receiver is omnidirectional. Each row represents the results of a specific RX-TX pair which are

provided as foreign keys in the table.

The Rx Power field is a double item field which defines the received power in dBm. The

omniIR is defined as a string for simplicity. The format is defined in the table below.

Table 4-18: omniResults Table Description


omniResultsID Integer Uniquely identifies the results received by the Receiver

assuming that the receiver is omnidirectional. Private Key

RxID Integer Receiver ID in which the sector belongs to. Foreign Key.

TxID Integer Transmitter ID from which the signal was received. Foreign

Key.

RxPower Double The received power receiver by the Receiver from the

transmitter identified by TxID (in dBm)

omniIR Char(2000)

The received omnidirectional Impulse Response received by the

receiver from transmitter TxID. It is defined as a string (for

hard disc space issues and simplicity) with the following format

(comma separated values):

“CIR, NoOfComponents, time1, componentPower1, time2,

componentPower2,…, timeN, componentPowerN”

CIR identifies that this is a Channel Impulse

Response

NoOfComponents is an integer which identifies

how many received paths constitute the impulse

response


component (path)

componentPower the power (in dBm) of the




Page 50 (101)

sectorResults Table

This table, sectorResutls, is similar to the omniResults table but each entry represents the

received signal parameters for a specific sector of the receiver antenna.

Table 4-19: sectorResults Table Description


sectorResultsID Integer Uniquely identifies the results received by a specific sector of

the receiver of the Receiver. Private Key

RxID Integer Receiver ID in which the sector belongs to. Foreign Key.

TxID Integer Transmitter ID from which the signal was received. Foreign

Key.

lowerAngle Double The lower angle (in degrees) of the receiver sector

upperAngle Double The upper angle (in degrees) of the receiver sector

Power Double The received signal power (in dBm) by the sector.

IR Char(2000)

The received Impulse Response received by the receiver

(RxID) sector from transmitter TxID. It is defined as a string

(for hard disc space issues and simplicity) with the following

format (comma separated values):

“CIR, NoOfComponents, time1, componentPower1, time2,

componentPower2,…, timeN, componentPowerN”

CIR identifies that this is a Channel Impulse

Response

NoOfComponents is an integer which identifies

how many received paths constitute the impulse

response


component (path)

componentPower the power (in dBm) of the



In order to populate this part of the database with the Ray Tracing Simulations carried out in

Task 2.3 by SIGINT Solutions and SIRADEL the following steps need to be followed:

Attached the database as described in Section 4.3.

Download the whole folder from here [10]

You need to run “RunThisToLoadToSQL.m” but first you need to change the first line

in the file which defines the connection string to the SQL database (depends where you

have the database installed and the credentials you have defined for the user). For

example:

connectionString='PROVIDER=SQLOLEDB; Data Source=MARIOS2-

PC\SQLEXPRESS; initial catalog=NEWWHERE2; User ID=where2;

password=where';

Basically it is needed to change the Data Source, the User ID and the password.

https://bscw.eurecom.fr/bscw/bscw.cgi/d387824/RunThisToLoadToSQL.m


Page 51 (101)

4.3 Deployment

4.3.1 Installing the database locally

The SQL version of the database (without data) is made available to download from the

WHERE2 server [11]. It is optimised for Microsoft SQL server 2008 R2. In order to test the

access to the database you need to follow the following steps.

1. Install SQL Server 2008 R2

a. Make sure the latest service pack is installed. If not you can download it from

WHERE2 server [12]

b. Install as new SQL stand-alone server installation

Figure 4-5: SQL server installation

c. Select all the instance feature

Figure 4-6: SQL features selection

d. Change the name of the instance


Page 52 (101)

Figure 4-7: SQL instance configuration

e. Select service accounts

Figure 4-8: SQL server configuration

f. Select Windows Authentication mode as shown Figure 4-9 and add an

administrator user for all databases.

Figure 4-9: SQL database configuration (authentication mode)


Page 53 (101)

2. Download and install Microsoft SQL Server 2008 R2 RTM-Express with Management

Tools [13]. Then open Microsoft SQL Server 2008/SQL Server Management Studio

3. Connect to the server you have defined during the installation phase (SQLESPRESSDB

in this example)

Figure 4-10: SQL server connection

4. Download the database from WHERE2 server, [11], then extract it and put the .mdf and

.log files in the MSQL folder (usually here C:\Program Files\Microsoft SQL

Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA)

5. Attach the database

a. In the MSQL server Management studio right click on the Databases and press

Attach

Figure 4-11: Attach database

b. Press Add


Page 54 (101)

Figure 4-12: Attach database (add)

c. Select the NEWWHERE2.mdf from the place you have stored it locally and

press ok. Some problems can appear during this process if the database file has

not the all the permissions enabled (read and write permissions)

Figure 4-13 : Attach database (locate db)

6. Once the DB has been attached some properties need to be modified

a. Right click on the SQL instance (SQLEXPRESSDB in this case), select

“Properties”. In the security menu, the server authentication needs to be change

to “SQL Server and Window Authentication Mode”


Page 55 (101)

Figure 4-14: Attach database (authentication mode)

Figure 4-15: Database properties

b. Once the database is attached and security properties modified In the

Security/Login folder, a new login has to be created


Page 56 (101)

Figure 4-16: Database new login

c. A new user is created. The name and the password need to be inserted by the

user and the option “Enforce password policy” is recommended to uncheck in

order to avoid to change the password frequency and other password policies.

Figure 4-17: New login properties

d. Then to access to the database it is necessary to link the login user to the

attached WHERE2 database. In the “NEWWHERE2” database/ security/user/

new user


Page 57 (101)

Figure 4-18: Database new user

e. It is necessary to create a new role to allow users the executing of “Stored

Procedures”. In the “NEWWHERE2” database/New Query and paste the

following query in the blank window:

CREATEROLE db_procexecutor

GRANTEXECUTETO db_procexecutor

The lower log window should show the success message. The whole process is

summarized in the following figure:

Figure 4-19: Creation of roles (query)

f. Select the user created previously, and in the “Database role membership” at

least three options have to be checked:

o Db_datareader

o Db_datawriter

o Db_procexecutor (created in previous step)


Page 58 (101)

Figure 4-20: User roles

7. Now can access the database info by using a standard SQL query interface.

To check this, an easy way is restarting the Microsoft SQL Server 2008/SQL Server

Management Studio.

Figure 4-21: SQL server access

8. Authentication mode should be modified to “SQL Server Authentication” and the user

previously created should access to the specific database.

9. In case of refused connection errors, be sure that local IP address is enabled through the

SQL Server configuration Manager (see next subsection)

4.3.2 Remote Access to a database

Once the database has been installed in a computer, it can be accessed locally or remotely. To

access remotely to the database, some options need to be checked.


Page 59 (101)

1. Once the database has been attached, by means the “Microsoft SQL server Management

Studio”, in the properties menu of the database, the option “Allow remote connections

to this server” has to be active.

Figure 4-22: Database connection properties (remote access)

2. Then, check TCP/IP and Named pipes are enabled through

Start Program files SQL Server 2008 R2 Configuration Tools SQL

Server configuration Manager

3. The server configuration manager show the main SQL services as well as it network

configuration


Page 60 (101)

Figure 4-23: SQL server configuration manager (services)

4. TCP/IP and Named Pipes need to be enabled.

Figure 4-24: SQL server configuration manager (client protocols)

5. Check that required IP addresses are Active and Enabled by double-clicking on

TCP/IP. Enable 127.0.0.1 IP address for local connection.

Figure 4-25: TCP properties


Page 61 (101)

6. If some of these parameters have been modified, the service of the SQL service needs to

be restarted.

Figure 4-26: SQL services restarting

The service “SQL Server Browser” needs to be Running.

4.3.3 Multiple Measurements for different Scenarios

If multiple measurements from different measurement scenarios should be available in the same

SQL server is possible to access them deploying all to the same SQL server. In this section an

example of this procedure is summarized following a simple renaming approach.

Firstly, the procedure detailed in section 4.3.1 should be performed for the first WHERE2

database files to be used. In the example shown in Figure 4-27, three different instances of the

same database are going to be installed in the same SQL server instance. The three folders with

WHERE2 database files are shown in the left while in the right only one has been installed.

Supposing that the first WHERE2 dataset installed is the one in folder A, the first step is rename

this existing database to avoid be overwrite by B and C when importing them. The renaming of

an existing database is possible from the SQL Server Management Studio by clicking the right

button and selecting Rename as shown in Figure 4-28:

Figure 4-27: Multiple measurements, initial setup.


Page 62 (101)

Figure 4-28: Database renaming

The name recommendation for WHERE2 database instances is as follows:

<original name>_<scenario name>[_<id>]

,where

<original_name> : the name of the current database “NEWWHERE2”,

<scenario_name>: space less unique name related to the measurement campaign, e.g.

DLRBUILDING0, PTINUPPERFLOORS, OTEMAINBUILDING…

<id> is an optional unique id defined for each scenario independent measurement

campaigns.

To avoid casing problems is advisable to use uppercase for the database names. In the presented

example the existing database has been renamed to NEWWHERE2_scenarioA and the second

database has been imported:

Figure 4-29: SQL instance with two databases


Page 63 (101)

In the presented example with three databases the resulted SQL server configuration is as

follows:

Figure 4-30: Example with three database instances

The renaming procedure could be repeated for any number of database instances, the only

drawback of this approach is that existing connections string to the NEWWHERE2 database

should updated to the renamed names. Two consecutives data queries are presented in Figure

4-31, for scenarioB and for scenarioC.

Figure 4-31: SQL queries for two WHERE2 databases in the same SQL server

instance


Page 64 (101)

4.3.4 Matlab or Java as SQL query client

The developed SQL database can be accessed through MATLAB by using the ADO connection

objects, which work under Windows OS only. It is necessary to download the free toolbox

[14], extract it somewhere in your file system and add a path to it in MATLAB. Additional

information about this ADO connection objects – if needed – can be found in [15] and

[16]. It also can be found some sample code in the downloaded toolbox package.

This is an example from DLR’s side to connect to the WHERE2 database and get all entries

from the RTD measurements table. Adapt the IP-address, database name and user + password

accordingly. Here the database is called NEWWHERE2.

%---------- Beginning of sample code ----------------

close all

clear

clc

DB = adodb_connect('PROVIDER=SQLOLEDB; Data

Source=129.247.178.160\SQLEXPRESSDB; initial catalog=NEWWHERE2; User

ID=where2; password=where');

assert(DB.State == 1, 'Could not connect to database within the time out');

% get all entries already available from DLR's COOP Measurement table

% use the standard queries

[Struct Table] = adodb_query(DB,'select * from DLR_COOP_Measurement');

DB.Close;

%---------- End of sample code ----------------


Page 65 (101)

5. Higher layers - GUI development In order to test and evaluate the Common Interoperability Framework implemented, a WHERE2

graphical user interface has been developed. This user interface also targets the demonstration

of the project results. The appearance of this application is shown in Figure 5-1.

Figure 5-1: WHERE2 User interface look and feel

5.1 Framework Interfaces

In the first stages of the implementation, each platform generates simulated data, in order to

debug all the features of interface B. The simulated data are random values covering all the

possible values provided by each platform.

The network structured, as defined by each platform, is a list of connected nodes. This list is

presented in a tree hierarchy, and is shown in the left side of the first tab named “Map”.

5.1.1 Communication with the different test beds front ends – Interface B

Due to the common implementation of the interface B for each platform, the application

manages all the platforms internally, following the same architecture. For example, the same

open/close methods are used for connect/disconnect all the platforms.

Main menu Quick accesses

Connect/disconnect to

the WHERE2

platforms

List of the

nodes from

WHERE2

platforms

Opens the “sentinel.codeplex.com”

external log viewer to see all the

logs generated by the application.

Indicates if the

data is being

logged in DB


Page 66 (101)

The first step to manage a platform is to perform the connection to its base hardware. From the

graphical interface there are several options in order to connect and disconnect a platform:

Using the left tree view that shows all the platforms and all the nodes in each network.

Using the main menu, located in the top side of the application with the rest of the

options

Using a quickly access in the bottom side of the application. If double click is

performed on the platform icon, the connection with that platform is initiated/terminated

depending in its current status.

Figure 5-2: Options to connect a platform

As it can be viewed in Figure 5-2 , the user can select a simulated option, before connecting to a

platform. With this option the user can select working either with simulated data or real

hardware. The simulated data are random values of all the possible information provided by

each platform and its main advantage is that the actual hardware is not needed. This mode has

been used intensively during development stages.

For instance, ZigBee platform simulates the following data:

List of random nodes (always one coordinator, several base stations and several mobile

nodes)

Inertial random data from the different sensors (accelerometers, gyroscopes and

magnetometers)

Random link measurements (RSSI values between all the nodes)

When the connection has been established, either with a simulated or real platform, it is possible

to access to extended information for each platform nodes, by using the bottom tabs of the main

window. The three tabs, Node Info, Sensor Measures and Link Measures, show the available

information of every node connected in the network.


Page 67 (101)

Regarding the first of these tabs, Node Info, the main information from a node is presented, as

can be viewed in Figure 5-3 .

Figure 5-3: Information provided by a node

When a node is highlighted (showed with a grey background), it means that the node, in that

moment, is disconnected or out of range. All the nodes in every platform expose the same

properties:

The ID or name of the node

The PrivateID or private name given to the node from its parent platform

The parent platform

The description

The location capabilities

Timestamp: time when the last data from this node has been received

Relative position (common for all platforms): (x, y, z)

Is a mobile node

Node Type

The real position of the node: (x, y, z). Used for static nodes and during measurement

acquisitions to manually report the real position for a node.

Power status, default ON.

Trolley identifier for node grouping

Some of this common information is automatically filled, while other may be filled through this

screen and saved for future execution of the application using the same list of nodes.

The other information generated by the nodes, the measurements is presented in the following

two tabs “Sensor measures” and “Link measures”.

No all the platforms provided sensor data, only ZigBee and UWB platforms. But the three of

them give different link measurements.


Page 68 (101)

Figure 5-4: Measurements (inertial sensors and link measures)

The data related with the sensor measurement shows the source node and the actual sensor

measure. In the case of link measures, two nodes are indicated, the source and the destination of

the measurement and the value of the RSSI measure. In both measurements, the received

timestamp set by the host computer is shown.

5.1.2 Communication with the database – Interface C

The basic functionality of interface C is the connection with the database.

Currently, some actions like reading information from database and insert data in some of the

tables defined have been implemented.

These functionalities can be improved, or even some new ones can be included when more

measurement campaigns are carried out.

5.1.2.1 Database connection options

Basic connection information is required in order to establish the WHERE2 database

connection:

Server name

Database name

User

Password.

This information must be configured in order to successfully connect to the WHERE2 database

and must be defined during the SQL Server deployment (refer to section 4.3.1).

The connection parameters are accessed from the main menu, File/Options or the quick access

icon .

After the connection parameters are configured, it is advisable to check them directly from this

window.


Page 69 (101)

Figure 5-5: Database options

5.1.2.2 Database information

Once the connection with database has been successful established, the “Database” tab presents

some menus to update the database contents. See Figure 5-6.

Figure 5-6: Database overview tab

Obtains a summary of the database entities count.

Clears the entire database, use with precaution.


Page 70 (101)

Updates the node information for all connected nodes.

The application upper toolbar also contains a quick access to this action .

Through this tab, details about the measurement campaign can be directly edited in the database.

The information that can be included is a short name, the date and a detailed description of the

scenario.

Figure 5-7: Measurement campaign details into database

Other kind of information is the one related with the location algorithms. There is one table in

the database used to store the information of the location algorithms implemented by the

different partners. The actions can be performed from this window, selection of a location

algorithm to show its estimated position solutions; adding of a new algorithm and removing an

existing one (see Figure 5-8). Moreover the automatic update of the application node positions

using the latest position reported from a given location algorithm is possible by enabling it.

Figure 5-8: Location algorithms tab


Page 71 (101)

5.1.2.3 Database Logging

The main target of the common framework is to collect data from the heterogeneous platforms,

in order to include measurements of the different radio access technologies, enabled in the scope

of the WHERE2.

For this purpose, once a platform is connected, the data received can be logged into the

database. There are two modes to insert data into the database: real time mode and trigger

mode. With the real time mode active every step (milliseconds) the measured information from

all the platforms is inserted into the database. The trigger mode allows to manually triggering

the data insertion at a specific moment.

The virtual “led” showed in the bottom right of the application, is used to show the instant when

the platforms data is logged to the database.. If the virtual led is red , the data in

being logged into the database.

To activate the real time mode logging, there are two possibilities to start and stop the logging

actions in the database:

From the Overview left tab (see Figure 5-6). In this tab, also the configuration of the

time step is available. Once the interval of data logging is setup, the data logging action

can be started and stopped by means of the start and stop buttons (see Figure 5-9).

Figure 5-9: Real time mode settings

By using the quick access application toolbar buttons, and . The interval to

log the data in the database is the one setup in the previous tab.

To activate the trigger mode, two options are available:

From the database overview tab (Figure 5-6),

Figure 5-10: Trigger measure mode

By using the quick access application toolbar button for this action


Page 72 (101)

5.2 Support features

5.2.1 Log functionality

In order to debug the common framework implementation and provide rich custom log files, a

free logging platform for .NET has been included in the main application. As commented

previously (see section 2), NLog has been configured for this application.

Each software module provides a NLog logger, so using a simple code line, a new log row is

generated, as shown in the following C# example:

Logger.Trace("Message");

Logger.Debug("Message");

...

Different levels of log can be generated such as Trace, Debug, Info, Warning, Error and Fatal,

for allow better log filtering [7].

5.2.1.1 Log file generation

There is only one file to setup the log subsystem for the full application: Nlog.config.

The simplified format is the pure XML having the <nlog/> element as its root.

Different configuration elements can be used as children to <nlog/>. The first two elements

from the list are required to be present in all NLog configuration files; the remaining ones are

optional and can be useful in advanced scenarios.

<targets/> – defines log targets/outputs

<rules/> – defines log routing rules

<extensions/> – loads NLog extensions from the *.dll file

<include/> – includes external configuration file

<variable/> – sets the value of a configuration variable

In this application different targets (outputs) have been setup, several files and one external

viewer. All the log files are store in the log path defined as variable, in a folder called Logs as

defined by the following path variable:

By default, all the logs generated by the application are store in a text file: WHERE2_MT.log.

Some measurement campaigns or some specific tests could require being saved in independent

files; for example, store all the RSSI values received by ZigBee nodes. For this scenario is

possible to define the routing of the log messages to the different outputs. This is performed by

specifying the list of targets that should be written for each combination of source/logger name

and log level:

1. Create the target: There are two attributes required for each target, the name and the

type (such as "File", "Database", "Mail"…). See example below.


Page 73 (101)

2. Define rules: It is a simple routing table, where it is defined the list of targets that

should be written for each combination of source/logger name and log In the following

example, the target name is “targetFileMeasures”

With this rule, all the messages that contain the text “[ACO Data]” will be write to the

target targetFileMeasures, that it is a file which name is ACOmesures.csv and it is store in

the logFilePath. For more information about log filtering and log messages routing, see

[7].

5.2.1.2 External viewer

One of the targets defined in the graphical user application is one of the external viewers

available for free. Sentinel [8] is a log-viewer with configurable filtering and highlighting

(foreground / background colours).

A direct access has been added in the bottom side of the user application in order to open and

automatically setup this external viewer .

Once this button is clicked, a wizard to configure the viewer is shown. This wizard should be

executed each time the viewer is initiated, due to the lack of save option in Sentinel. The name

of the logger must be filling up; this name only will appear in the window name of the external

viewer.


Page 74 (101)

Figure 5-11: New logger – Sentinel (step 1)

Next step is to add a provider for the logs. In this case the WHERE2 application provides a

UDP logger.


The first setting is the type of log; in this case the type of log generated is nLog. Then, taking

into account the target configuration, the application will send the logs via an UDP connection

through the port 9999.

Figure 5-13: New logger – Sentinel (App settings)


Page 75 (101)

After defining the new provider the configuration will show as follows:


Finally, it only can be selected a traditional text based log to visualized all the messages.


The aspect of the external viewer Sentinel is the one shown in Figure 5-16


Page 76 (101)

Figure 5-16: NLog external viewer (Sentinel)

For more features please refer to the Sentinel project web page [8].


Page 77 (101)

6. Position-based Communication Platforms

6.1 Vertical Handover - IP Mobility functionality

As described in Deliverable D4.1, SIGINT Solutions provides to the WHERE2 project an IP-

Mobility Platform which will be used to “marry” the positioning information with the

communication part in unified demonstration architecture. It is used to demonstrate the

Location-Based Vertical Handover (VHO) by executing VHO requests initiated by VHO

algorithms which consider position as one of their primary decision metrics. The idea is to

demonstrate the potential benefits in preparation/execution of a vertical handover in a

heterogeneous environment due to the a priori knowledge of this kind of positioning

information and also the benefits in energy efficiency by having a positioning knowledge in

beyond 3G-communication where adapters of different Radio Access Technologies (RAT) need

to be awake and available in order to transfer (if needed) the call/connection to them. In such a

case, positioning information can be used in conjunction with premeasured or pre-calculated

coverage maps of the different Radio Access Networks (RAN) to switch ON and OFF the

respective adapters and thereafter save to the best possible extent as much energy as possible.

A comprehensive description of the IP-mobility platform is provided in Deliverable 4.1. This

platform will be integrated with the WHERE2 positioning database to receive positioning

information about the connected users in order to feed the position-based Vertical Handover

algorithms developed by NKUA by using the networking infrastructure provided by OTE and

SIGINT Solutions. An abstract view of this demonstration architecture is shown Figure 6-1. The

test-bed consists of five different or complementary technologies. These technologies/testbeds

are to be functioned only for the purposes of WHERE2 and are not used for commercial

purposes. They consist of base stations and access points that can be either commercial or

programmed ones. The commercial ones are more stable but they have characteristics that

cannot be programmed easily depending on the standard or the programming language of the

firmware. These are WiMAX (802.16d), mobile WiMAX (802.16e), LTE, Cisco based WiFis

(802.11n), Soecris based WiFis (802.11b/g) and Femtocells (HSDPA). The VHO process is

splitted in two processes. The Communication parameters RSSI and data rate are sent to the

database which in return forwards the position data to the platform that instructs the terminal to

be connected to the network that can provide the best communication means.

The terminals that will be tested in the communication scenarios will be conventional

laptops/notebooks which employ 2 USB Wireless adapters with; one Wi-Fi and one WiMAX

adapter as each of which can connect to either the Wi-Fi Soekris platform or to a WiMAX Base

station (802.16d). There will also be advanced 4G smartphones (Android based) and

tablets/ipads with 4G interface in order to show the VHO between the four technologies

(802.11g/n, 802.16d/e, femto and LTE).

The basic and most critical communication features of the different technologies that are going

to be used during the scenario demonstration are:

WiMAX 802.16/d,e

Item Specifications

Frequency bands RX, TX band (MHz), TDD mode

3441.5-3455.5 3541.5-3555.5

Output power 33 dBm (2W)

Power consumption <100 W

Transmission port One FE port


Page 78 (101)

LTE

Item Specifications

Frequency bands RX, TX band (MHz), FDD mode

900, 1900

Output power 36 dBm (4W)

Power consumption <200 W


FEMTO

Frequency bands RX band (MHz) TX band (MHz)

1920 to 1980 2110 to 2170

Output power 13 dBm (20 mW)

Power consumption < 8 W


WiFi (802.11g/n)

Frequency bands RX band (MHz), TX band (MHz)

2412 - 2472 5015 - 5085

Output power 21 dBm (100 mW)

Power consumption < 20 W

This multi-technology terminal has a direct SQL connection to the IP-mobility platform

database in order to provide real-time information about the discovered links, the power

consumption of the two adapters, user preferences and throughput information. This database is

also filled with context from the Soekris platform which involves network information like cell

load, available band-width. All this information, together with positioning information retrieved

from the WHERE2 positioning database is fed to VHO algorithms which decide whether the

user should hand-over the connection from one technology to another for example from Wi-Fi

or femto to WiMAX or LTE and vice versa. If a VHO decision is generated then this is

forwarded (using a dedicated client-server connection) to the Service connection manager

(which is basically a server which listens to a client sitting in the VHO algorithms) who in-turn

forwards this trigger to the MIP functionality for execution. An example of the decision format

that the Service-Connection manager accepts from the VHO algorithms in order to send a

handover trigger to a specific Terminal Unit is shown in table below. It includes the ID of the

Terminal Unit in which the VHO will occur, the MAC address of its adapter that it is currently

connected (source adapter MAC) to the Internet and the MAC address of its adapter that the live

IP connection will be handed over (destination adapter MAC). It also includes another field that

defines the type of command that is to be executed on the Terminal Unit (for a VHO this is

SWITCH).

Command Mobile Device

ID

Destination Adapter

MAC Source Adapter MAC

SWITCH 10.0.0.1 00:01:02:03:a1:a2 00:01:02:03:a1:b2


Page 79 (101)

Figure 6-1: Position-Based Vertical Handover Demonstration Architecture

6.1.1 SOEKRIS Platform

Soekris net-5501 [17] devices are used as WiFi Access Points. Their role is twofold, not only

they do provide networking capabilities to an indoor environment, but also they expose

programming flexibility. Ubuntu 10.04 LTS has been installed appropriately, in order to deploy

software modules which inspect device current state. For the purposes of WHERE2 Project, a

monitoring library has been developed and installed, implemented in Java 2 Standard Edition.

Its task is to constantly provide up-to-date contextual information regarding the operational

status of any network device. This library consists of two interrelated blocks which provide

hardware and Operating System (OS) agnostic behaviour. Also, a third extra block is deployed

for the efficient configuration of the underlying network device. More specifically, Executor,

Translator and Monitor are the three foundational blocks, as can be seen in Figure 6-2, whose

role is further described in the following lines.


Page 80 (101)

Figure 6-2: Foundation blocks of monitoring software

Both the Executor and the Translator constitute two interworking software parts that interact

directly with the underlying network device and provide a common API to the Monitor layer.

By common API, it is meant that different versions of the considered libraries (e.g.

Android/Windows oriented implementations) retain the same interface to the upper layers.

The most important classes of these two libraries are the NetworkManager, the Wired and the

Wireless. The NetworkManager provides all methods required for the activation and de-

activation of interfaces, the configuration of routing tables, the assignment of IPs to interfaces

and the deployment of a wireless device as an AP or a router. A description of a subset of these

methods is provided in Table 6-1.

Table 6-1: NetworkManager interface

NetworkManager Description

configureIpTablesBridge

Method used to configure the ip tables and bridge the wireless and

wired interfaces in order to route terminal traffic to the internet.

resetIpTables Clean the ip tables so that a new configuration can be inserted.

retrieveSubnetNodes

Retrieve a list of the mobile terminals active in the subnet of an

AP. The retrieved list is a set of MAC-IP tuples thus enabling an

AP to uniquely identify an attached client.

saveDhcpdConfiguration

Save the DHCP configuration in a text file (dhcpd.conf file).

DHCP configuration is dynamically generated and is unique per

access point.

saveHostpadConfiguration

Save the hostapd configuration in a text file (hostapd.conf file).

Hostapd configuration is dynamically generated and is unique per

access point.

startAccessPoint

Start the device functioning as an access point. Essentially, this

method creates the dhcpd and hostapd configuration files and

starts the hostap and dhcp daemons.

startDhcpServer Start the dhcp server

startHostapdServer Start the hostapd server

stopDhcpServer Stop the dhcp server

stopHostapdServer Stop the hostapd server

validateRoutingTable Assess the validity of the routing table.

The Wired class (Table 6-2) provides the basic functionality in order to manipulate any

interface, either wireless or wired. It builds upon their common subset of functionalities and

enables any application to direct an interface to start, stop, retrieve an IP address through DHCP

or return statistics related to its operational status.


Page 81 (101)

Table 6-2: Wired interface

Wired Description

configure Configure the interface. Essentially assign an IP and default gateway

to the interface.

getBroadcast Return the broadcast address of the interface.

getByName Static method used to retrieve an interface based on its name.

getCarrier Return the carrier of the interface.

getCollisions Return the number of collisions of this interface.

getConfiguredGateway Return the default gateway of the device.

getEnabledInterfaces Static method used to return a list of enabled interfaces.

getInterfaces Static method used to retrieve all network interfaces of a device.

getIp Return the IP of the interface.

getName Return the name of the interface (e.g. eth0)

getNetmask Return the netmask of the interface

getNetwork Return the network address of the interface.

getRx_bytes Return the Rx bytes as taken from /proc/net/dev

getRx_dropped Return the Rx dropped as taken from /proc/net/dev

getRx_errors Return the Rx errors as taken from /proc/net/dev

getRx_overruns Return the Rx overruns as taken from /proc/net/dev

getRx_packets Return the Rx packets as taken from /proc/net/dev

getTx_bytes Return the Tx bytes as taken from /proc/net/dev

getTx_dropped Return the Tx dropped as taken from /proc/net/dev

getTx_errors Return the Tx errors as taken from /proc/net/dev

getTx_overruns Return the Tx overruns as taken from /proc/net/dev

getTx_packets Return the Tx packets as taken from /proc/net/dev

ifdown Direct the interface to shutdown

ifup Direct the interface to become active

isEnabled Query the interface to validate its operational status

requestDhcp Request dhcp address

setGateway Set the gateway of the device

Additional functionality, supported only by a wireless interface is implemented by the Wireless

class which inherits and extends the wired class (Table 6-3)


Page 82 (101)

Table 6-3: Wireless interface

Wireless Description

connect Connect through this wireless interface to an access point (credentials provided

as parameters to the method)

disconnect Disconnect from the currently connected access point.

getAp Return details about the Access Point on which this interface is connected.

getBitrate Return the bit rate of this wireless interface.

getByName Static method which returns a list of all available wireless interfaces on the

device using as key the name representation of the interface (e.g. eth1).

getChannel Return the channel of this interface.

getEssid Return the essid of the interface.

getMode Return the mode of connectivity of the interface.

getTx Return the TxPower of the interface.

isConnected Return the connectivity status of the interface.

scan Scan the surrounding wireless environment. Returns a list of wireless scan

results.

setMode Set the mode of connectivity for this interface.

setTx Set the TxPower for this interface.

Finally, Monitor is a fundamental block of the library since it undertakes the aggregation of

information from the environment, its cleaning, its formulation into objects and its provision to

any requesting entity. In the heart of the Monitor block reside three classes which exploit the

functionality of the Executor and support the delivery of results to any requestor. These classes

are provided in Table 6-4 and comprise the basis for the monitoring threads presented in Table

6-5.

Each device initiates a thread which constantly monitors the appearance of new network

interfaces on the device. The term appearance in our case is used in its literal meaning,

signifying i.e. the plug-in of a USB network adapter on the device or the initiation of a virtual

interface (e.g. eth0:1). For each of the identified interfaces, a new NetworkInterfaceMonitor

thread is initiated. Additionally if the interface is wireless, a new WirelessInterfaceMonitor

thread is also started. Finally, a WirelessEnvironmentScanner thread is started which undertakes

the task of monitoring the wireless environment.

A straightforward question which comes up after this discussion is related to the number of

threads initiated to perform the monitoring task. This solution was adopted in order to manage

the diversity in the rate of events appearance on each network interface. It is normal to expect

that an interface which is deployed as an AP will have a higher rate of events than an interface

which is used only for scanning the environment or an interface which is not deployed at all.

Moreover, it is expected that changes in the bandwidth –on any interface- will occur more often

than the addition of a new network interface (which will happen only once or twice during the

experiment). Thus, it was decided that a single thread per interface will be deployed while its

sleep time between two consecutive loops will be adjusted according to the rate of events of this

particular interface.


Page 83 (101)

Table 6-4: Basic Classes of the Monitor block

Class Description

NetworkMonitor This class provides general utilities applicable to all network interfaces.

WiFiAPMonitor This class provides utilities for monitoring any wireless interface which

acts as an access point.

WiFiAPScanner

This class provides utilities for scanning the environment using a wireless

interface. It enables any device to react to any changes to its operational

environment.

Table 6-5: Monitor

Class Description

AvailableInterfacesMonitor

Class used to monitor the available network interfaces (i.e. the

exact number and nature of network interface. Returns the wired

interfaces which have an IP (thus are active) and all available

wireless interfaces.

Monitor This is the class, implementing all monitoring functionality

required.

NetworkInterfaceMonitor Class used to monitor the properties of a network interface

(either wired or wireless).

WirelessEnvironmentScanner Class used to scan the operational environment of each device.

WirelessInterfaceMonitor Class used to monitor a wireless interface associated with this

class.

Switcher

Class used to coordinate with the threads that use the wireless

interfaces. This class gets the sleep time information from the

other threads and decides whether there is sufficient and

common (i.e. concurrent) sleep time between the two threads

that use the same wireless interface. If there is sufficient

common sleep time, this class invokes the SwitchCommander

class in order to switch of the wireless interface when it is not

needed.

SwitchCommander

Class used to keep track of the power status of the wireless

interfaces (i.e. on or off) and to coordinate the switching off and

on of the various wireless interfaces, when it is instructed to do

so by the Switcher class.

6.1.2 Vertical Handover Algorithms

An indoor environment with several Soekris WiFi Access Points, where a terminal roams is

considered. In case of degraded QoS conditions (e.g. RSSI value drops below a certain

threshold), Network Domain Cognitive Manager, a central entity which has already been

described in D4.1, tries to find the best Access Point the terminal should associate to, based not

only on current load conditions but also on the exact position of the terminal.

For this reason, a cost function is introduced [18] in order to calculate the candidate Access

Point the terminal should associate to:


Page 84 (101)

( ) {

( )

where,

DMT->B is the distance between the exact position of the terminal and the candidate

Access Point B,

LB is the load of the Access Point and

max Distance is considered as the maximum radius the terminal may roam in.

The Access Point with the maximum cost function value is selected as the appropriate one the

terminal should associate to.

The following picture shows the x, y measurements of the user’s terminal that are passed to the

WHERE2 database. These are going to be used along with the capacity metrics as a criterion for

the handover process. The following figure shows the user’s position measurements which can

be done either by prediction (fingerprinting process, or by using any other algorithm produced

by different partners or by the SIRADEL’s environment).

Figure 6-3: User’s terminal position measurements passed to the database

The database in which the user’s position data are kept communicates either straight with a

user’s terminal which then decides to which network to be handed for the best communication

means or to a server which makes the decision and instructs the terminal to take the handover

action. The following Figure 6-4 shows the handover process action where the positioning data

are communicated form the database to a server or straight to the terminal for the handover

action.

Figure 6-4: VHO process (Position measurements – Database- Decision- Handover)


Page 85 (101)

6.2 Context-based Platform and Application

Context information may be considered “any information that characterizes a situation of an

entity (person, place or object)”. It is particularly interesting to characterize users and their

surrounding environment in order to understand their behaviour and build profiles. Location is a

very good and successful example of specific context information. Location Based (Internet)

Services (e.g. Google Latitude, Foursquare, Gowalla) are finally getting the attention of users

and investors. Nevertheless very little has been done related to positioning based services,

meaning indoor location based services. In this section a simple example of a positioning-based

application is presented along with the context framework which supports it. The interest of

integrating positioning into a broader context framework opens the possibility of building more

sophisticated and personalised services. The following subsections explain in more detail how

this can be achieved.

6.2.1 Context Framework

As described in Deliver D4.1, the context-based Framework provided by PTIN (represented in

Figure 6-5) integrates different types of context information (user profile, location, proximity,

presence, sensors, etc.) and offers a single interface to both smart applications and other

context-aware enablers. It is based on a facilitator component called Context Broker that

mediates the interaction between the sources that provide context data (e.g. sensor in a mobile

phone), designated Context Sources, the Context Providers which represent the context

information (simple, aggregated or processed) on the server side, and those that consume

context data – Context Consumers. Both Context Consumers (e.g. smart applications) and

Context Providers (when playing also the role of Context Consumers) can have access to the

context information via the Context Broker. Context source information located in the mobile

terminal can be both consumed directly by the applications and exported to the server to be

consumed by some other services/applications; this communication is facilitated by the

Terminal Agent.

Figure 6-5: PTIN Test bed

6.2.2 Protocol

The communication among the context framework components is in XMPP (Extensible

Messaging and Presence Protocol), a communications protocol [19] for message-oriented

middleware [20] based on XML (Extensible Markup Language) [21]. XMPP is defined as an


Page 86 (101)

open IETF standard [22] and uses an open systems [23] approach of development and

application, by which anyone may implement an XMPP service and interoperate with other

organizations' implementations.

The Context Broker includes a XMPP server and the XMPP pubsub extension which is a

protocol extension for generic publish-subscribe functionality. The protocol enables XMPP

entities to create nodes (topics) at a pubsub service and publish information at those nodes; an

event notification (with or without payload) is then broadcasted to all entities that have

subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can

serve as the foundation for a wide variety of applications, including news feeds, content

syndication, rich presence, geolocation and any other application that requires event

notifications.

6.2.3 Context Sources and Context Providers

Figure 6-5 shows the following Context Sources and Providers (only those relevant for the

proof-of-concept application):

Sensors / Sensor Info: representing the accelerometer and magnetometer data, the

bearing / heading of the user relative to a certain location can be obtained. This enables

the notion of direction in an application;

GPS / GPS Info: gives the location of the user on Earth (geographical coordinates);

APInfo / Positioning: the APInfo source delivers information about the Access Points

(APs) surrounding the user while the APInfo/Positioning provider receives the AP

information, compares it with referenced signal strength values and makes available to

the application the final positioning coordinates. This particular provider has been

developed for WHERE2 and is presented in more detail in the next subsection.

6.2.3.1 APInfo / Positioning

The APs are identified by the user’s terminal which then retrieves relevant data from each one

(APInfo). This data is composed of 4 (four) fields: BSSID, SSID, frequency (MHz) and RSSI

(dBm). From this retrieval a set of APs is created and published to the Context Broker, in order

to process the set of APs and calculate the user’s location (Positioning). This information is then

made available for the users who subscribe it.

Figure 6-6: XML example of one AP data fields

This positioning provider communicates with the central WHERE2 database in order to retrieve

the reference values which resulted from a previous off line learning process. Figure 6-5 shows

the particular case where the reference values came from the WiFi network learning process

developed by PTIN for WHERE2. But the provider can take any other reference values

obtained using any of the other positioning platforms developed in WHERE 2.

The important step here is the comparison between the real time data retrieved from the mobile

terminal of the user while he is on his way inside a certain building and the values pre-

calculated that map signal strength values into indoor coordinates.


Page 87 (101)

6.2.4 Communication with the database (Interface E)

The communication between applications and the database (DB) is held using the Context

Broker as an intermediary, where data coming from both ends (terminal and DB) ends up.

Mediating this communications we have Content Providers – one responsible for publishing the

sets of APs provided by the terminal and another in charge of sending such sets to be processed

against the DB. The DB is accessible through the call of a web service developed to receive data

relative to the APs surrounding a certain user, process it and return the location (in geographical

coordinates) to the caller (see Figure 6-5).

The access to the location information, to be used by the context platform, can be done in two

different ways (Figure 6-5): either by accessing to the WP4 WHERE2 database (described in

section 4) – which is the result of the cooperation between all the location systems in the

project; or directly to the location system developed by PTIN in WP2 (described in [24]) –

which is based on fingerprinting techniques applied to WiFi networks. For each approach there

is a different layer interconnecting the location systems and the context platform since the

database formats are different between both approaches.

WP4 WHERE2 database is the result of all the systems effort to locate a user terminal, using

one or more techniques addressed in the project. The location estimation value can be the result

of the cooperation of one or more devices and/or one or more algorithms applied to the collected

data. Furthermore, by using this location system the context platform is not only aware of the

location estimation, but also of the systems used, which is directly related to the value precision.

Depending on the desired precision, different services may require different approaches to

obtain such value. Thus, better location estimation values impose more requirements in terms of

means to achieve that value (either more devices and/or better algorithms – more data

processing capacity), while others can use rougher estimations and as a consequence simpler

techniques and algorithms.

Moreover, it is also possible to access directly to the location system developed by PTIN, and

obtain the location estimations directly from that system. By doing so, the user is constrained to

a similar precision since there is only information from one system. This precision, however,

can be slightly different depending on the number of access points the user device is able to

receive. In order to obtain a location estimation the context broker feeds a file in a XML format

containing the information about the surrounding WiFi networks, the user terminal

identification and, if available, the last location known to that user. The location application

running on a server, parses the file data, and tries to matches that information with the offline

information available on the MySQL database. The best match corresponds to the location

estimation for the device. The matching process is not only influenced by the RSSI patterns, but

also by user movement constraints and historical user movements.

6.2.5 PTIN Positioning System

The location system developed is based on the fingerprint principle, which consists in matching

the data obtained by the user device (online data) and the radio pattern for the building obtained

from a measurement campaign (offline data). To obtain an estimation of the user position, the

system has to find the best match between the online data and the possible values from offline

data. The space of results of offline data is assessed by some factors, like: a likely

neighbourhood which the user is limited to by known last location(s); and movement constraints

imposed, for instance by building physical constraints, like walls; amongst others. The matching

process itself starts to evaluate the number of matches in the online vector and the offline

vectors – more common access points represent a higher degree of similarity between points.

This first level of decision, however, takes into account that access points can be turned off and

disappear from the scenario, by giving a weight to this factor in the final decision for the

position location. A second factor to the equation is given by the Euclidean distance between

both vectors. A lower distance value represents a better match, as the difference between the

RSSI values (from the reference and the user equipment) is lower, and as a consequence the


Page 88 (101)

probability of being from the same point is higher. A last factor takes into the account the fact

that the radio signal attenuation has a logarithmic shape, which means that the difference

between measurements can be high for very small distances, and inversely for long distances.

This effect is minimised in the final decision.

At last it is important to note that, to minimize errors from equipment differences (between the

reference and the user’s) there is a factor of correction applied to the user device, which is

obtained in a calibration point in the building entrance, where the location is the same and the

difference is only caused by heterogeneity amongst devices’ WiFi interfaces.

6.2.6 Applications

Context-aware applications may take context information into account not just for direct display

on the users’ application GUIs (e.g. user’s location or indoor position display) but also to

influence their internal logic and behaviour.

In particular positioning-based applications may help users to automatically find indoor places

such as meeting rooms, parking places or shopping stores and receive information of interest

every time they are nearby one of those places. By combining user positioning with spot

location, new seamless location-based applications may be developed. In addition to this, if

information is combined with environmental and personal information (e.g. user preferences) it

will be possible to personalise applications and better adapt their behaviour to the users’ needs,

therefore build true context-aware services.

To prove the concept, PTIN specified two possible applications based on the following use

cases:

• Ana, who has configured some preferences and expressed some interests in Facebook,

is driving nearby her favourite shopping centre and decides to visit it to do some

shopping. She has previously subscribed the shopping centre application. Then, when

she is in the mediation she will start receiving the podcast from the centre that will not

be interrupted when she enters the underground parking lot (seamless mobility triggered

by positioning if needed). The way to a free spot in the parking lot will be indicated to

her (in a GPS kind of interface) and memorised. When she enters the shopping centre

the way to her favourite stores will be shown in a little map and when she approaches

the places of interest advertising videos (e.g. favourite music, video game, food or

wine) will start playing. At the end of her visit, the way back to her car will be

indicated.

• There is a meeting at PTIN’s premises. Participants may reach the place using their

GPS but once they enter the building one of the project positioning systems will guide

the users to the meeting place. As soon as a participant enters the building he/she checks

in with his/hers mobile terminal and receives the agenda of the meeting. Straight away

indications to the meeting room in a GPS-manner will be given to the participant. When

he/she arrives close to the room a list of participants will be sent to his terminal. When

he/she enters the room, information about the speaker and short summary of the subject

(next speaker/subject in case nobody is talking at the time) will be sent.

6.2.6.1 Implementation scenario - “Meeting Room”

As implementation scenario for the application, we considered the “Meeting Room” scenario,

showed in the following figure:


Page 89 (101)

Figure 6-7: 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. Furthermore, considering also weather

information provided by an external source, the user can be notified in time about the weather

conditions in that appointment location.

6.2.6.2 Maps

The application considers the location of the user and points it in a map. Such map is either

provided by Google (Google Maps) or a geo-referenced custom map (e.g. map of the IT

building). In the application context, Google’s maps present the user’s location in the outside

(i.e. outdoor locations), while the custom maps are intended to be shown when the user is inside

a building (i.e. indoor location).

Figure 6-8: Screenshot of the application pointing the user’s location (indoor) in a

custom map


Page 90 (101)

7. Summary In this document we have provided a comprehensive description of the implementation

activities towards carried out towards the integration of the interoperability framework defined

in the WHERE2 project which aims to validate the benefit in positioning by using a multi-

technology platform by obtaining parameters from different RATs and to validate benefit in

communications in a heterogeneous networking environment when the position and mobility

pattern of mobile users are known.

This integration includes the implementation of the various interfaces which are used to extract

context from the low-level positioning platforms and provide to a central database. A, a detailed

description of this database with examples on how to integrate it to the framework and how this

database can be access by either the low level platforms or the positioning algorithms and

communication platforms in order to insert or retrieve context to it.

It has been also presented how the communication platforms; namely the Mobile IP platform

that is used to demonstrate position-based Vertical handovers and also the Context based

application platform make use of the position information towards the benefit of

communications.


Page 91 (101)

References

[1] Microsoft, “Using the Visual C# IDE,” [Online]. Available: http://msdn.microsoft.com/en-

us/library/ms173063(v=vs.90).aspx.

[2] Microsoft, “Introduction to the C# Language and the .NET Framework,” [Online].

Available: http://msdn.microsoft.com/en-us/library/z1zx9t92.aspx.

[3] Microsoft, [Online]. Available: http://msdn.microsoft.com/en-us/library/bb397897.aspx.

[4] Codeproject, “LINQ to Entities: Basic Concepts and Features,” [Online]. Available:

http://www.codeproject.com/Articles/246861/LINQ-to-Entities-Basic-Concepts-and-

Features.

[5] A. K. MEHTA, “Overview of SQL Server 2008 R2 Express Edition,” 2012. [Online].

Available: http://www.sql-server-performance.com/2010/sql-server-2008-r2/.

[6] E. Woodruff, “Sandcastle Help File Builder,” [Online]. Available:

http://www.ewoodruff.us/shfbdocs/Index.aspx?topic=html/b772e00e-1705-4062-adb6-

774826ce6700.htm.

[7] NLog, “NLog,” [Online]. Available: http://nlog-project.org/.

[8] CodePlex, “Sentinel - Log Viewer,” [Online]. Available: http://sentinel.codeplex.com/.

[9] Wikipedia, “Software framework,” [Online]. Available:

http://en.wikipedia.org/wiki/Software_framework.

[10] Microsoft, “Microsoft® SQL Server® 2008 R2 SP1 - Express Edition,” [Online].

Available: http://www.microsoft.com/en-us/download/details.aspx?id=26729.

[11] M. Central, “Adodb_tools allow communication with different types of databases through

ADO OLEDB component,” [Online]. Available:

http://www.mathworks.com/matlabcentral/fileexchange/29615-adodbtools.

[12] W3schools, “Connection Objects (ADO connection objects),” [Online]. Available:

http://www.w3schools.com/ado/ado_ref_connection.asp.

[13] Microsoft, “Connection Object Properties, Methods, and Events,” [Online]. Available:

http://msdn.microsoft.com/en-

us/library/windows/desktop/ms681546%28v=vs.85%29.aspx.

[14] Soekris, “Soekris,” Soekris Engineering Inc., [Online]. Available: http://soekris.com/.

[15] G. Alyfantis, S. Hadjiefthyiades and L. Merakos, “Exploiting User Location for Load

Balancing WLANs and Improving Wireless QoS,” ACM Transactions on Autonomous and

Adaptive Systems , vol. 4, no. 2, 2009.

[16] “Intermediate: Location Information Extraction, Deliverable 2.2,” FP7 Project - WHERE2,

March 2012.


Page 92 (101)

[17] Wikipedia, “Communications protocols,” [Online]. Available:

http://en.wikipedia.org/wiki/Communications_protocol.

[18] Wikipedia, “Message oriented middleware,” [Online]. Available:

http://en.wikipedia.org/wiki/Message-oriented_middleware.

[19] Wikipedia, “XML,” [Online]. Available: http://en.wikipedia.org/wiki/XML.

[20] Wikipedia, “Open Standard,” [Online]. Available:

http://en.wikipedia.org/wiki/Open_standard.

[21] Wikipedia, “Open System Computing,” [Online]. Available:

http://en.wikipedia.org/wiki/Open_system_%28computing%29.

[22] WHERE2, “T2.3 database into WHERE2 SQL database,” [Online]. Available:

http://www.kn-s.dlr.de/where2/documents/Database/T2.3/.

[23] Microsoft, “Microsoft SQL Server 2008 R2 RTM - Express with Management Tools,”

[Online]. Available: http://www.microsoft.com/en-us/download/details.aspx?id=22985.

[24] WHERE2, “WHERE2 server - WHERE2 database,” [Online]. Available: http://www.kn-

s.dlr.de/where2/documents/Database/Where2DBSQL.zip. [Accessed 10 January 2013].


Page 93 (101)

Appendix A Stored Procedures to Populate the WHERE2 database

Trolleys

insertTrolley

Inserts a new Trolley entry into the Trolleys Table. The TrolleyID

is updated increasingly.

Column Type Parameter value Input/output

TrolleyDescription Nchar(1000) @TrolleyDescription input

getAllTrolleys

Returns all the columns of all the entries in the Trolley Table.

selectTrolley

Returns the Trolley (all the columns) with a specific TrolleyID


TrolleyID int @TrolleyID input

TrolleyDescription Nchar(1000) - output

updateTrolley

Updates a Trolley Entry in the the Trolley Table given its

TrolleyID and the parameters to update


TrolleyID int @TrolleyID input

TrolleyDescription Nchar(1000) @TrolleyDescription input

Nodes

insertNode

Inserts a New Node in the Database (requires that a Trolley exists

in the database)


NodeName Nchar(100) @NodeName input

NodeOwner Nchar(10) @NodeOwner input

NodeDescription Nchar(1000) @NodeDescription input

NodeOwnerID Int @NodeOwnerID input

MobileOrAnchor Int @MobileOrAnchor input

TrolleyID Int @TrolleyID input

updateNode


Page 94 (101)

Inserts a New Node in the Database (requires that a Trolley exists

in the database)


NodeID int @NodeID input

NodeName Nchar(100) @NodeName input

NodeOwner Nchar(10) @NodeOwner input

NodeDescription Nchar(1000) @NodeDescription input

NodeOwnerID Int @NodeOwnerID input

MobileOrAnchor Int @MobileOrAnchor input

TrolleyID Int @TrolleyID input

ACOSensorMeasurement

insertACOSensorMeasurement

Inserts an ACOSensorMeasurement in the database



Timestamp Timestamp @Timestamp input

ACO_AccX float @ACO_AccX input

ACO_AccY float @ACO_AccY input

ACO_AccZ float @ACO_AccZ input

ACO_GyroX float @ACO_GyroX input

ACO_GyroY float @ACO_GyroY input

ACO_GyroZ float @ACO_GyroZ input

ACO_MagX float @ACO_MagX input

ACO_MagY float @ACO_MagY input

ACO_MagZ float @ACO_MagZ input

ACO_Temp float @ACO_Temp input

ACO_Pitch float @ACO_Pitch input

ACO_Roll float @ACO_Roll input

ACO_Yaw float @ACO_Yaw input

updateACOSensorMeasurement

Updates an ACOSensorMeasurement in the database given its @

ACOSensorMeasurementID


ACOSensorMeasurementID int @ACOSensorMeasurementID input



ACO_AccX float @ACO_AccX input

ACO_AccY float @ACO_AccY input


Page 95 (101)

ACO_AccZ float @ACO_AccZ input

ACO_GyroX float @ACO_GyroX input

ACO_GyroY float @ACO_GyroY input

ACO_GyroZ float @ACO_GyroZ input

ACO_MagX float @ACO_MagX input

ACO_MagY float @ACO_MagY input

ACO_MagZ float @ACO_MagZ input

ACO_Temp float @ACO_Temp input

ACO_Pitch float @ACO_Pitch input

ACO_Roll float @ACO_Roll input

ACO_Yaw float @ACO_Yaw input

CEASensorMeasurement

insertCEASensorMeasurement

Inserts an ACOSensorMeasurement in the database



CEA_MagX float @CEA_MagX input

CEA_MagY float @CEA_MagY input

CEA_MagZ float @CEA_MagZ input

CEA_AccX float @CEA_AccX input

CEA_AccY float @CEA_AccY input

CEA_AccZ float @CEA_AccZ input

CEA_GyroX float @CEA_GyroX input

CEA_GyroY float @CEA_GyroY input

CEA_GyroZ float @CEA_GyroZ input


updateCEASensorMeasurement

Updates an CEASensorMeasurement in the database given the

@CEASensorMeasurement


CEASensorMeasurement int @CEASensorMeasurement input


CEA_MagX float @CEA_MagX input

CEA_MagY float @CEA_MagY input

CEA_MagZ float @CEA_MagZ input

CEA_AccX float @CEA_AccX input

CEA_AccY float @CEA_AccY input

CEA_AccZ float @CEA_AccZ input


Page 96 (101)

CEA_GyroX float @CEA_GyroX input

CEA_GyroY float @CEA_GyroY input

CEA_GyroZ float @CEA_GyroZ input


ACOLinkMeasurement

insertACOLinkMeasurement

Inserts an ACOLinkMeasurement in the database



ACO_PeerID int @ACO_PeerID input

ACO_RSSI float @ACO_RSSI input

Timestamp datetime @Timestamp input

updateACOLinkMeasurement

Updates an ACOLinkMeasurement in the database given the

ACOLinkMeasurementID


ACOLinkMeasurementID int @ACOLinkMeasurementID input


ACO_PeerID int @ACO_PeerID input

ACO_RSSI float @ACO_RSSI input


CEALinkMeasurements

insertCEALinkMeasurement

Inserts an ACOLinkMeasurement in the database




CEA_PeerID int @CEA_PeerID input

CEA_Dist float @CEA_Dist input

CEA_BER float @CEA_BER input

CEA_FER float @CEA_FER input

CEA_CIR Nchar(1000) @CEA_CIR input

updateCEALinkMeasurement


Page 97 (101)

Updates an CEALinkMeasurement in the database given the

CEALinkMeasurementID


CEALinkMeasurementID int @CEALinkMeasurementID input


CEA_PeerID int @CEA_PeerID input

CEA_Dist float @CEA_Dist input

CEA_BER float @CEA_BER input

CEA_FER float @CEA_FER input

CEA_CIR Nchar(1000) @CEA_CIR input

DLR_COOP_Measurement

insertDLR_COOP_Measurement

Inserts an DLR_COOP_Measurement in the database



DLR_RTD float @DLR_RTD input

DLR_SNR float @DLR_SNR input

DLR_PeerID int @DLR_PeerID input

DLR_coop_CIR_Real Nchar(1000) @DLR_coop_CIR_Real input

DLR_coop_CIR_Imag Nchar(1000) @DLR_coop_CIR_Imag input

DLR_RTD_RSSI float @DLR_RTD_RSSI input


updateDLR_LTE_Measurement

Updates an DLR_COOP_Measurement in the database given the

DLR_COOP_MeasurementID


DLR_COOP_MeasuremetID int @DLR_COOP_MeasuremetID input


DLR_RTD float @DLR_RTD input

DLR_SNR float @DLR_SNR input

DLR_PeerID int @DLR_PeerID input

DLR_coop_CIR_Real Nchar(1000) @DLR_coop_CIR_Real input

DLR_coop_CIR_Imag Nchar(1000) @DLR_coop_CIR_Imag input

DLR_RTD_RSSI float @DLR_RTD_RSSI input


DLR_LTE_Measurements


Page 98 (101)

insertDLR_LTE_Measurement

Inserts an DLR_LTE_Measurement in the database



DLR_CIR_Real Nchar(1000) @DLR_CIR_Real input

DLR_CIR_Imag Nchar(1000) @DLR_CIR_Imag input

DLR_CFO Float @DLR_CFO input

DLR_RSSI Float @DLR_RSSI input

DLR_SNR Float @DLR_SNR input

DLR_BSID int @DLR_BSID input


updateDLR_LTE_Measurement

Updates an DLR_LTE_Measurement in the database given the

DLR_LTE_MeasurementID


DLR_LTE_MeasuremetID int @DLR_LTE_MeasuremetID input


DLR_CIR_Real Nchar(1000) @DLR_CIR_Real input

DLR_CIR_Imag Nchar(1000) @DLR_CIR_Imag input

DLR_CFO Float @DLR_CFO input

DLR_RSSI Float @DLR_RSSI input

DLR_SNR Float @DLR_SNR input

DLR_BSID int @DLR_BSID input


DLR_LTE_TDoA_ID

insertDLR_ LTE_TDoA

Inserts an DLR_LTE_TDoA in the database



DLR_TDoA_BSID int @DLR_CFO input

TDoA Float @TDoA input

updateDLR_LTE_TDoA

Updates an DLR_LTE_TDoA in the database given the DLR_LTE_TDoA_ID



Page 99 (101)

DLR_LTE_TDoA_ID int @DLR_LTE_TDoA_ID input


DLR_TDoA_BSID int @DLR_CFO input

TDoA Float @TDoA input

MeasurementDetails

insertMeasurementDetails

Inserts the Measurement Details in the database


MeasurmentDate datetime @MeasurmentDate input

MeasurementDescription Nchar(1000) @MeasurementDescription input

MeasurementLocation Nchar(100) @MeasurementLocation input

update MeasurementDetails

Updates the measurement details in the database given the

MeasurementID


MeasurementID int @MeasurementID input

MeasurmentDate datetime @MeasurmentDate input

MeasurementDescription Nchar(1000) @MeasurementDescription input

MeasurementLocation Nchar(100) @MeasurementLocation input

Algorithms

insertAlgorithm

Inserts the algorithm details in the database


AlgorithmDeveloper nChar(10) @AlgorithmDeveloper input

AlgorithmDescription Nchar(1000) @AlgorithmDescription input

updateAlgorithm

Updates the algorithm details in the database given the AlgorithmID


AlgorithmID int @AlgorithmID input

AlgorithmDeveloper nChar(10) @AlgorithmDeveloper input

AlgorithmDescription Nchar(1000) @AlgorithmDescription input

Position


Page 100 (101)

insertPosition

Inserts the new calculated position in the database




X Float @X input

X Float @X input

Z float @Z input

AlgorithmID Int @AlgorithmID input

ReferencePointID Int @ReferencePointID input

updatePosition

Updates the calculated position in the database given the

positionID


PositionID int @PositionID input



X Float @X input

X Float @X input

Z float @Z input

AlgorithmID Int @AlgorithmID input


TruePosition

insertTruePosition

Inserts the new true position in the database




X Float @X input

X Float @X input

Z float @Z input


updatePosition

Updates the true position in the database given the positionID


Page 101 (101)


PositionID int @PositionID input



X Float @X input

X Float @X input

Z float @Z input


ReferencePoint

insertReferencePoint

Inserts the new reference point in the database


Longitude Float @Longitude input

Latitude Float @Latitude input

Height Float @Height input

ReferencePointDescription Nchar(1000) @ReferencePointDescription input

updatePosition

Updates the reference point in the database given the

ReferencePointID


ReferencePointID int @ ReferencePointID input

Longitude Float @Longitude input

Latitude Float @Latitude input

Height Float @Height input

ReferencePointDescription Nchar(1000) @ReferencePointDescription input

Date post:	13-Sep-2019
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

Interoperability Framework Development and Implementation · (Wi-Fi, LTE, ZigBee, UWB) and...

Documents