![[PukiWiki]](image/cs27logo5.png "[PukiWiki]")
[[Research/SOA]] * 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. &attachref(); #ref(kulocs1.png,nolink,30%); * 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. #ref(kulocs2.png,nolink,30%);
