|
PoSIM components are independent of the ontology exploited by each integrated positioning system. However, policy,
filter rule and triggering event developers suppose each positioning system supplies information exploiting the same ontology.
Here we propose a simple ontology, exploited to deploy proposed policies, filter rules and triggering events. However,
this is only a possible ontology and PoSIM components do not depend on this specific one.
We distinguish information provided from positioning systems in
- features: describe positioning system characteristics, useful for positioning system control, and
- infos are location-related information. Usually, infos are not modifiable from outside the positioning systems.
We have identified three main feature and info categories: mandatory, common, peculiar.
- Every positioning system must offer mandatory features and infos; in particular
we propose as mandatory location info, either physical or logic, and exploited
network technology feature, e.g. Bluetooth for many external GPS clients and 802.11 for Ekahau.
- Common features and info are
optional but predefined, e.g., position information accuracy and precision or power consumption.
- Finally other could be
positioning system peculiar and a priori unknown, that is not shared between positioning system developers.
Let us stress
differences between common and peculiar features and infos is the former are known from positioning system developers, and
their syntax and semantic must be shared among them, the latter is completely unknown, typical for a particular positioning system.
For instance, it is not possible to evaluate power consumption of every positioning system. For this reason this feature is not
mandatory. However, if it is possible, developers should offer its estimate through powerConsumption feature and the returned
value measurement unit should be shared among integrated positioning system, e.g., in milliwatt or in a graduated scale from 0 to 9.
On the contrary, positioning system developers may add peculiar features and infos freely, without any requirement on returned
value semantic.
Below table reports examples of some mandatory, common and peculiar features and infos.
Category |
Name |
Modifiable |
Mandatory |
Info |
Location |
n.a. |
Timestamp |
n.a. |
PSState |
n.a. |
Feature |
Name |
no |
State |
yes |
ExploitedDevices |
no/yes |
LocationType |
no/yes |
Common |
Info |
Accuracy |
n.a. |
Feature |
PrivacyLevel |
no/yes |
PowerConsumption |
no/yes |
Peculiar |
Info |
FixType (GPS) |
n.a. |
Feature |
Status (Ekahau) |
no |
Among proposed features and infos we want to focuses on some of them, to better explain their semantic.
First of all we, among the above listed features/infos, let us rapidly focus on State and PSState, to better explain their semantic. The State feature returns on or off depending on the fact that the positioning system is switched on or off and thus may be exploited to obtain positioning data. Even if a currently switched off positioning system cannot provide localization info, the correspondent PSW can continue to offer old positioning data based on previous values, implicitly specifying they are history-based estimations via the timestamp info. Also PSState is either on or off, but that info represents if the positioning operations of a switched on positioning system have been performed in a correct way in the last time interval. For instance, even if a GPS device is active (State is on), it could not be able to provide a correct location information (PSState is off) since there are not enough satellites in line of sight (no fix in the GPS terminology).
-
Accuracy and precision are delineated both as info and feature, that is they are controllable
location-related information. In fact, in some circumstances it could be desirable to prevent from performing localization with
great accuracy. For example, take into consideration the case an external server performs localization based on raw data
provided from a mobile device. If the external server is not completely trusted, mobile device could send only partial
location-related raw data, allowing to perform localization only with low accuracy and precision. Moreover, other features could
vary accuracy and position indirectly. For instance, it may happen lowering frequency update, accuracy and precision lower too.
-
User privacy at positioning system level is performed changing privacy feature level, if available.
The goal is to prevent positioning systems to disclose user location while performing localization, e.g. interacting with
wireless infrastructure nodes. In fact, positioning systems based on communication technologies may need interaction with
wireless infrastructure nodes, for positioning or communication purpose, implicitly disclosing user location at a certain
detail level, e.g., the infrastructure knows a user is close to a particular 802.11 AP or Bluetooth device.
|
