The AllJoyn Location Services Project is part of the AllSeen Alliance’s Technical Steering Committee Services group. The framework and several examples are available as open-source from the AllSeen Alliance’s repository. This article gives an overview of the Location Services Project, including terminology and operational capabilities as well as provides resources when considering commercial implementations.
AllJoyn Location Services Framework
The Location Services Framework (LSF) is an abstract framework enabling storage and retrieval of geographical (aka location) information about entities being observed by members of an AllJoyn proximal network. The LSF is written in C++. The framework does not define a specific implementation – that is, there are many ways to implement a location-based solutions using the Location Services Framework. This white paper will attempt to explain the framework and give some examples of possible implementation choices.
To get started it will be helpful to understand some of the terms used in the LSF; most notably queries, subscriptions, services and roles. At its core, the LSF comprises a database of location-based information that can be queried and subscribed to.
A query requests current information about a set of entities from the Location Services device (defined below). The set of entities is specified through a regular expression filter. For example a client application could query for all entities’ presence information. Or, a query could be made for the distance between Entity A and Entity B. A query will return an XML object containing all the appropriate information from the Location Services device.
A subscription requests that the subscriber be notified when there is a change in the set of entities’ information. Again, the regular expression filter can be used to specify the entities involved, and the service(s) specified will dictate what the change required for notification is. And the callback will also be specified. So for example, a Client application can subscribe to presence of all entities – i.e. notify me whenever an entity arrives or departs.
Overview of Services and Roles
Let’s now understand the information services offered: Registration, Presence, Position, Distance, and GeoFencing. These are the types of information stored and retrieved through the LSF.
- Presence:Is an entity currently present within the view of the LSF?
- Position: What is the current position of an entity (x, y, z) within the view of the LSF?
- Distance: What is the distance between two entities? (including an accuracy rating)
- GeoFencing: Is an entity within radius (r) of a reference entity (e)? (i.e. inside a sphere)
- Registration: What is the entity’s name and how may its information be used?
Second we will describe the roles played within the LSF. These are the actions performed by different service members.
- Client Application: The application using the LSF services
- Location Services:The central repository of the data
- Contributor:A device contributing location information to the Locations Services
- Entity:The entity being observed by the LSF
There are four major roles played within the LSF. Roles are not mutually exclusive and hence, multiple roles may be played by a single device – e.g. a smartphone application could play all four roles below.
The entity is the entity being observed. In other words it is the subject of the location information being contributed by the contributing device. An entity is characterized by three attributes: a globally-unique ID number (required), a descriptive string, and a set of Access-Control Lists (ACL). An entity whose descriptive string is null is called Anonymous (versus Registered). Registered entities may also have associated with them an ACL that controls how their associated information may be accessed. The LSF places no requirements on the GUID other than its uniqueness.
A Contributing device contributes information about entities that it observes to the Location Services device. This information can be presence, position, distance, geo-fencing, or registration information. When the contributing device joins the LSF, it identifies itself to the Location Services device. Location Services device knows that it is there and active using AllJoyn keep-alive . As the Contributing device observes changes, or arrival, or departure of entities, it reports that information to the Location Services device. Note that in no way is it specified how a Contributing device gets the information that it contributes. In addition to contributing information, a Contributing device may also fetch information from the Location Services device.
Within the AllJoyn proximal network there is one Location Service device that acts as the central repository of location information. It stores information received from contributing devices (along with time of receipt), and it serves that information to the queries and subscriptions received from client applications or Contributing devices. At the point that a Contributing device closes (or loses) connection with the Location Services device, the Location Services device deletes all information associated with the lost Contributing device. In this way, the data in the Location Service device’s database is as up-to-date as possible. Note that the Location Services device does not create any information. It simply stores information received from Contributing devices, and it retrieves that information to return as query and subscription results.
The client application communicates with the Location Services device in the AllJoyn network using APIs provided. The two main API categories are queries and subscriptions. A query requests current information about a set of entities (specified by a regular expression filter) from the Location Services device. A subscription requests that a notification (callback) be initiated whenever a change occurs in the requested property for the requested set of entities. Query and subscription are analogous to polling and interrupts.
It is important to note the following key things:
We have not specified how a contributing device learns its information about the entities that it is observing — e.g. is it visual, through RF, physical, etc. We have not specified either how a contributing device communicates with an entity, or if it does. We have simply stated that a contributing device observes entities (by its own means), and reports information about them to the Location Services device through the AllJoyn network per the LSF specifications.
A Contributing device does not need to contribute all five types of information (presence, distance, etc). It may contribute some or all. So a system could have Presence-Contributing devices and/or Distance-Contributing devices etc.
Both the Application and the Contributing devices may also query the Location Services device. So for example, a Contributing device could query the Location Services device for distance information, compute position based on those distances, and contribute that position information back to the Location Services device.
The Location Services and Contributing devices are members of the AllJoyn network with associated security checks and access control.
The Location Services device trusts information received from Contributing devices. That is, there is no checking of validity of information received. It is assumed to be valid and is placed in the database until that Contributing device goes offline.
When two or more Contributing devices contribute the same information (e.g. distance between A and B), then the newest active contribution is returned on a query.
Now let’s go into a little more depth on each of the services.
The registration information associated with a specific entity. At a minimum, the registration information includes a globally-unique identifier (GUID) for the entity. If all that is registered for the entity is its GUID, then the entity is called anonymous.
In addition to the GUID, an entity may also have a descriptive string (e.g. name).
And finally, the entity may have a per-service access control list (ACL). See the Security section below for more details on the ACL properties.
A Boolean attribute of an entity – i.e. Is an entity present? This will be reported true for an entity when any of the currently active Contributing devices report the presence of the entity to the Location Services device. An entity might be observed by multiple Contributing devices. The entity becomes present when the first Contributing device reports the entity’s presence, and becomes absent when the last Contributing device reports the entity’s departure from view. And as implied, a Contributing device that contributes presence information will contribute on both the arrival and the departure of an entity.
The three-dimensional position of an entity – i.e. where is the entity? This three-dimensional position will be reported by an active Contributing device. More than one Contributing device may report the position of an entity. In that case when queried, the most recently reported position is returned. And if a query is made regarding an entity for which there is no current position information, then nothing is returned. Position format is either the WGS84 universal coordinate system (GPS), or Origin X,Y,Z where Origin is an implementation-dependent position, and the distance is in centimeters from the origin.
The point-to-point distance between two entities – i.e. how far is Entity A from Entity B, and with what accuracy? The distance and an accuracy rating are reported to the Location Services device by a Contributing device. More than one Contributing device may report the distance between the same two entities. If so when queried, the most recently reported value is returned. And if a query is made for which there is no distance information, then nothing is returned. Distances are measured in centimeters.
A Boolean attribute of an entity – i.e. is the entity inside the fence? True if an entity’s distance from a specified reference-entity is less than a specified radius (r). Note that nothing is returned if the system does not have the needed distance information. Also note that the fence is a sphere defined by the radius from the reference-entity at the center.
Since the Location Services device, and all associated Contributing devices are members of an AllJoyn network, the authentication and security services of AllJoyn are inherited and used to allow access to the Contributors and Location Services. In other words, the service interfaces are secured by AllJoyn 2.0 security.
The entities are not necessarily part of the AllJoyn network (for example they could be people walking down the street). However, through the entity registration process, each registered entity may have a per-service Access Control List (ACL) as part of its registration information. That ACL will determine what querying nodes will receive as results when queries of the Location Services devce are made. In that way, a registered entity can make control access to its information on a per-service basis. Anonymous (i.e. unregistered) entities’ information is all available to the querying devices.
An overall example
As an overall example, we will make some specific decisions about the example implementation. We will use Bluetooth Smart (aka Bluetooth Low Energy – BLE) as the means by which Contributing devices observe Entities. And in particular we will use the transmissions of a BLE device as the observable quality of the entity. There are many BLE devices (cars, phones, beacons, etc) that emit BLE signals. And there are also many devices that can receive or sense those BLE emissions. And many devices that can both emit and sense – hence the dual-role possibility. For this discussion we will also assume that a sensor can receive a Received Signal Strength Indicator (RSSI) value from an emitter as well. And lastly without going into details, we will assume that the sensor can calculate an approximate distance from the emitter, based on the RSSI.
Note that in many systems, the sensors might be in a fixed position, and the emitters mobile – for example emitters on cattle, and sensors in the barnyard. And conversely in many systems the sensors might be mobile, and the emitters in a fixed position – for example emitters on parking meters, and sensors on collection vehicles. The specific application will dictate the system architecture. LSF does not dictate.
With this in mind, it is easy for a sensor to “scan” for BLE emitters (A, B, C…), receive their RSSI values, and calculate the distance from the sensor to the emitter. The Sensor in this case can be the Contributing device (r) and contribute the distances (r, A), (r, B), (r, C), … for the entities A, B, C… seen on the scan.
Let’s consider putting BLE beacons (emitters) on the ears of cattle. We then could place a smartphone over the barn door. In this example, the smartphone could act as both the Contributing device and the Location Services device and the Client application. The smartphone might also have a list of which beacons are on which cows – e.g. Beacon #00:11:22:33:44:55 on Elsie, etc.
In its role as Contributing device, the smartphone would start by contributing registration information to the Location Services device (e.g. #00:11:22:33:44:55 on Elsie). Then also as Contributing device, the smartphone could continuously scan for beacons. When it sees a new arrival or departure, it would report that presence to the Location Services device – e.g. Bessie is in the barn, Elsie has left the barn…
In its role as Location Services device, it would keep a database of all the registration and presence information.
In its role as Client application, it would subscribe to presence information for all the cattle, and when it receives notification, it could upload that information to a cloud portal for the farmer’s observation.
In this “nomadic” emitters example, the emitters can be very simple, low-cost, low-power, small devices. Whereas the sensor is much more sophisticated.
Parking Meter Example
Now let’s consider putting BLE beacons (emitters) on parking meters. We can put the sensor on the Parking Collections cart. In this example, the Parking Meter could emit both its BLE address, and the current amount of money inside the meter. The collections cart could again contain a smartphone that could act as the Contributing device, and it could be connected to a Location Services device in the cloud.
This demonstrates that there are no requirements on how the various roles are placed in the system architecture.
Commercial Systems based on AllJoyn Location Services
Companies such as Beechwoods Software also make available commercial implementations of the Location Services (based on Bluetooth and WiFi) that can be used to monitor the movement of entities within a location (think people in a building) and displaying a “live” map of the entity locations. Included in this commercial implementation are:
- A Location Services device
- Position, distance and presence Contributing devices
- Custom applications that monitor and display location information
Location Services Project
For detailed information on the Location Services Project (weekly meetings, members, resources, documents, etc.), please consult the AllSeen Alliance’s Location Services wiki page at https://wiki.allseenalliance.org/locationservices
In addition, the AllSeen Alliance demonstrates and discusses their technology at shows and conferences attended by the AllSeen Alliance and/or the Linux Foundation such as CES, The OpenIoT Summit, etc. https://allseenalliance.org/events
The source code for the Location Services project may be found at the AllSeen Alliance’s Git Repository page at: https://git.allseenalliance.org/cgit/location.git/
For a much more in-depth understanding of the LSF, please consult the AllSeen Alliance’s website for complete information.