FocusStack: Orchestrating Edge Clouds Using Location-Based Focus of Attention

Previously, we have seen several edge-cloud or edge computing architectures. Some architectures (outsourcing) are focusing on how to offload computation-intensive tasks to edge devices. For example, MAUI and CloudClone are two examples. While, some other architectures (IoT) are focusing on offering a platform which can interconnect different devices. Although these good designs and implementations can solve many problems, they do not pay attention to two properties – the physical position of edge devices and the mobility of edge devices. They all assume the edge devices are fixed in one known position.

The biggest contribution of this paper is that it defines a scope for edge devices. So, this architecture gives us a flexibility to design and implement many new applications based on physical position of those devices. The biggest distinction between FocusStack and some other edge-cloud architectures is that FocusStack includes a very important component which can offer the physical position of the edge device. So, this paper uses a great of space to say how to find the physical position of an edge device. In the following, I will explain the several important components in FocusStack.

FocusStack Architecture:

In the above figure, the green rectangles represent location-based situational awareness subsystem. This subsystem maintains a mapping table of devices and their physical position (We can imagine it as routing table used in TCP/IP layer). The edge devices (cars and drones) use GPS signal to find its own position and update the mapping table in Geocast Georoute through GClib. SAMonitor is a proxy for application to talk to LSA subsystem.

The yellow rectangles represent OpenStack extension for this architecture. This subsystem is used to interconnect users and the chosen edge devices. For example, we can call FocusStack API to launch an application on edge device’s container. Conductor is a component which implements many protocols to help a person to choose one or several edge devices in a scope. OpenStack nova is used to manage containers.

AT&T Labs Geocast System – share device’s own physical position

                                            Figure 2 AT&T Labs Geocast System

This figure shows the details in LSA subsystem. There are two protocols we can use to define the scope for edge devices (In this paper, scope is defined as a circle on the earth surface, described as a center and radius). Firstly, edge devices and the VM can create an ad hoc network. Physical positions of edge devices are shared within this ad hoc network. Secondly, we can use UDP/IP network to send messages to devices far away from us. Because the positions of devices are maintained in GRDB, we can fetch the position of any device in GRDB. And also, it is easy for us to find if an edge device is in our desired scope.

GCLib Framework

                                Figure 3. GCLib framework software architecture

The GCHub component is used to send and receive geographic addressing messages to and from ALGS GA (AT&T Labs Geocast System Geographic addressing) network. The Pub component implements a publish/subscribe system for data blocks. “It provides the plumbing for data to flow among components. Each component registers interest in data block tags and receive a copy when a component publishes a block update with a matching tag.” Responder is used to answer query from users. Of course, it only answers what it can answer. Components are many docker containers. 

Strengths:

1.     FocusStack architecture gives us a way to implement location-based application.

2.     Because we only a subset of all edge devices, the workload for control plane is minimized.

3.     The system is modularized and each subsystem can be replaced by alternatives easily.

4.     It also maintains features which are implemented in traditional edge-cloud system, such as workload offloading.

5.     The response for one query are sent to nodes around the node which just sends the query. This may lower the traffic load because many nearby nodes may be interested in same response.

Weakness & discussion:

1.     In this system, there are there parties – edge device provider, application developer and edge device owner. If we want to deploy an application on other people device, it may incur security problem. So is there feasible way to fix this?

2.     Because application users and device owner can both control devices, we need a method to define the who control the device at a time.

3.     This paper only focus on one area. If we want to monitor 10 areas and there are 100 edge devices, how should we allocate these devices optimally?

4.     This system seems need lots of energy because edge devices use GPS to locate itself. But do you think an ad hoc network is a good alternative in all situations?