Discover and Announce: A Serverless Location Application Built on Akamai IoT Edge Connect
Discover — learn and understand the world around you
Announce — transmit your presence in the world, with any degree of dilution of precision or identity
100% serverless
Location, whether real or virtual, is a critical part of so many services and applications that we take for granted. Transport, gaming, entertainment, and logistics — our world does not work without the location services that are embedded so deeply into these and other industries.
The use case and demo that follow are of an application our team recently built for a webinar. We call this “Discover and Announce,” because it allows clients to explore the world, learn about things of interest near them, and (optionally) share their state with the world on a common broadcast channel for that location.
Most importantly, Discover and Announce is 100% serverless, and can run entirely at the Akamai edge.
User clients read and write to Message Queue Telemetry Transport (MQTT) topics on Akamai IoT Edge Connect that represent location
The World Editor service is also an MQTT client that updates location information in the appropriate topics
The Analytics service can read Announce messages sent by the user clients to make further sense of the world (e.g., how many users are in a particular location)
Military Grid Reference Squares — the backbone of our world
We start with a mapping system that allows us to assign MQTT topics to specific locations on Earth. Luckily, this is done for us already via Military Grid Reference Squares (MGRS). MGRS is a geocode for Earth, assigning coordinates that can be specified in 1 m, 10 m, 100 m, 1 km, and 10 km squares.
For example, see the following coordinate:
16TFQ 4104 8222
It is the location of Short’s Brewery in Bellaire, Michigan, USA, specified to the 10-meter-square precision. If we wished to specify a 1 km location square, we simply truncate the eastings (first set of integers) and northings (second set):
16TFQ 41 82
An online mapping application that shows MGRS overlays can be found here:https://mappingsupport.com/p2/gissurfer.php?center=14SQH05239974&zoom=4&basemap=USA_basemap.
MGRS can be derived from a latitude and longitude point via a simple formula that is available across many platforms, including JavaScript, which we will explore in a moment.
Our IoT Edge Connect topic structure can mirror the MGRS geocode. For the demo application, the topics for the above two applications look like this:
/16FTQ/4104-8222/
/16FTQ/41-82/
There’s also a richer, more complex design that allows the use of MQTT wildcards to “see” events at any level of precision you want. In this example, we’d write the first MGRS topic like this:
/16FTQ/4/1/0/4/x/8/2/2/2/x/
MQTT wildcards could then be used to run a really smart query. Here’s how you’d query that structure to find all the info within the 1 km square:
SUBSCRIBE /16FTQ/4/1/+/+/+/8/2/+/+/+/
(There’s actually a much more elegant, efficient way to structure this, but this way is visually more appropriate for the purpose of this article).
The world editor
We built a client that can be used to update the world map with objects. We can create an object, name it on a World Editor map, and specify its location by dragging it around the map. Each dragged-and-dropped object sends a message to IoT Edge Connect on the corresponding MQTT topic for the location’s MGRS value. The World Editor makes use of a MGRS JavaScript library that translates latitude and longitude using the MGRS geocode.
With additional logic to understand polygons and spheres, unique location shapes can then be defined, such as irregular features in the world.
Additional clients could use this similar service to announce their presence. In the webinar, we thought of characters in a park who might move from location to location. Characters could have clients that announce their presence once they arrive in a location.
The user client
A user can do two things:
1. First, the user can learn of the world around them by subscribing to topics for their location. Using MQTT wildcards, they can even specify the range of their interest.
The sample application looks at GPS coordinates provided via iOS every second. These values are translated locally to the MGRS value, and if the value has changed from the previous second, the client subscribes to the new location.
Here’s where it becomes beneficial to understand input options other than latitude and longitude. We’ve been asked to support indoor locations where GPS isn’t feasible. The practice in this case is to use Bluetooth beacons, which can indicate the client’s location. A flat dataset, stored locally or in Akamai EdgeKV, could assign beacon values to MGRS locations. Discover and Announce can be compatible with many different location sharing types and schemes.
2. Second, the user can then choose to announce themself. By using the MGRS topic structure, the user alone can decide whether to publish their location at the 10 km, 1 km, 100 m, 10 m, or 1 m topic level. This allows the user to dilute their location precision.
Of course, the user can choose what to send or not send in that announcement. Within our demo application, the user client simply calls themself “user.”
We built a sample user client user interface that shows the user location on a map, along with objects they discover, and the additional information that can be added to the object in the World Editor.
Real-time world analytics
The Analytics Service does what it says. The service includes an MQTT client that reads announcement messages, then logs and processes them. In our sample application, we added the Analytics feed to the World Editor, so that real-time data (in this case, user client location) can be displayed on the map.
The uses for this real-time data are exciting. For instance, user density statistics for locations can be determined and updated every second.
Going beyond our world
Location is important in virtual worlds as well, whether it’s gaming, simulation, or closed environments such as logistics warehouses and factories. This same structure can also be applied to those environments with the same benefits.
Why Akamai?
For our demo application, we considered the vision of the service running in support of a parks application, used by hundreds of thousands of visitors, all using phones tied to cellular carriers from around the world; the message volume could exceed billions per hour at peak times. We offer a simple, scalable, reliable, and secure platform that can handle all that and more. Origin services can live anywhere, and don’t have to scale up to meet customer demand. In our demo scenario, the customer can focus on building rich applications on top of our platform, creating further wonder and delight, while the Akamai edge does the heavy lifting.
Learn more
These application components can be run in any cloud environment, in nearly any container type. If you’d like to discover more about Discover and Announce, visit https://techdocs.akamai.com/iot-edge-connect/docs. We also have sample environments that can help you launch 1 or 1,000 clients and bring your ideas to life.