* Background [#f34b78a5]
Smart combination of IoT, positioning systems and cloud
services enables a sophisticated platform to acquire and man age locations of mobile users and objects. Nowadays, every
smartphone is equipped with GPS. Also, various GPS modules for IoT appear on the market. The latest indoor positioning systems (IPS) can locate users even
inside buildings or underground, where GPS cannot cover.
The enabling technologies of IPS include Wi-Fi, Bluetooth beacons, RFID, Pedestrian Dead Reckoning
(PDR), IMES. Gathering such indoor/outdoor location information in the cloud would create a great variety
of location-based services and applications.
The location information gathered in the cloud should be
provided as a service, so that client applications can easily
consume the locations based on standard Web service protocols. We call such a cloud service locating service in this
paper. In fact, several practical services come onto market recently. They include Swarm, Glympse, Google Maps APIs, Pathshare, Apple Family Sharing and
IndoorAtlas. Although features and operation policies vary from one service to another, the basic idea is to use
the cloud for exchanging or sharing location information acquired by a certain positioning system. Most services provide Web-API for application developers.

* Challenge [#i4476e6d]
In general, there is no compatibility among different locating services and API, since they are individually developed
and operated. Each service is tightly coupled with the underlying positioning system. For example, Glympse assumes
to use GPS information collected by smartphones, while IndoorAtlas use a magnetic field to locate the position inside
a building. Thus, Glympse cannot directly use the data
of IndoorAtlas, and vice versa. In order to cover both indoor and outdoor locations, one may want to integrate these
two services. However, the lack of compatibility forces the
application developer to use different API, and to perform
expensive data integration within the application.

Figure 1 shows the conventional architecture to integrate
the existing locating services. Let us assume an application,
say “where-are-you?”, with which a user A tries to find location of another mobile user B. Suppose also that B is in
either indoor or outdoor space, and is located by a certain
locating service. When A executes a query “Where is B?”,
the application has to invoke all possible locating services
to find B. Although the query “Where is B?” is essentially
simple, the application has to know how to invoke API and
interpret the result for every locating service. This makes
the application complex, low-performance, and non-scalable.


* Purpose and Approach [#o4bdc7eb]
To cope with the problem, in this paper, we propose a unified locating service, called KULOCS (Kobe-university Unified LOCating Service). KULOCS horizontally integrates
the existing heterogeneous locating services, and provides an
abstraction layer between the applications and the locating
services. To make location queries compatible among many
locating services, we design KULOCS with three technology-
independent elements [when], [where] and [who].
Based on the three elements, KULOCS integrates data
and operations of the heterogeneous locating services. In
the data integration, we propose a method that different
representation of time, heterogeneous locations and different
namespace of users are consolidated by Unix time, location
labels and alias table, respectively. The location labels consist of local label and global label, which abstract concrete
coordinates of IPS and GPS, respectively. A user of KULOCS queries every location by a label, whereas KULOCS
internally converts the label to specific representation for
individual locating services.
For the operation integration, we propose KULOCS-API,
which integrates heterogeneous operations by possible combinations of [when], [where] and [who]. The API is deployed as Web service, so that applications on various platform can easily consume KULOCS. For example, the query
“Where is B?” of “where-are-you?” is simply implemented
by http://kulocs/where?user=B&time=now. For this, the
application needs not to know how B is located by which
service. Thus, the application can consume location information quite easily and efficiently.


トップ   編集 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS