MobiledgeX Releases World’s First Public Mobile Edge

February 19th, 2019

Sunay Tripathi

Chief Technology Officer & EVP of Engineering & Product

Well, we’ve done it—we’ve released MobiledgeX Edge-Cloud R1.0 version of our product.  All of you who have been part of a startup know what an exciting moment this is—a chance to expose and talk openly what you’ve been working on in stealth and secrecy (in our case since January 2018).

MobiledgeX Edge-Cloud R1.0

The press release has all the salient details. I’m going to talk about the same thing but in a more narrative and explanatory form here.

We’ve announced the first public mobile edge running in the Deutsche Telekom cellular infrastructure in Germany.  Let’s unpack that. The “edge’ means close to the user (closer than current cloud as measured in the quality of the network connection—latency, bandwidth, jitter, packet loss).

The Value of Cellular Infrastructure

Using the cellular infrastrastructure means more than most might expect. First, cellular is rapidly becoming a critical part of cloud computing and few people understand how different the cellular infrastructure is from wired Internet infrastructure. As those differences become better understood, the value of having cloud resources in the cellular edge will become clearer. To begin with, use of the cellular infrastructure solves some of the fundamental problems with the existing Internet—you know a lot about a cellular user (they have a contractual relationship with an operator), you know a lot about where they are independently of where a smartphone thinks it is using radio location data that can’t be spoofed. And compared to the Internet, the cellular infrastructure is much more secure and private (there are no third parties lurking and looking at your traffic).

Second, using cellular infrastructure we have a straightforward way of building out an edge cloud because mobile operators (our business partners) have lots of compute near the edge and are used to resource sharing and compensation (that’s how telephony roaming works). A successful edge has to be global and multi-tenant (public). It’s not at all clear how you do that with the wired Internet because those network service providers don’t necessarily do a lot of computing or have hosting business models.

What’s an “edge-cloud?”

So that’s a little about the edge and why we think the cellular infrastructure is a good place to operate. So what’s an “edge-cloud.”  Modern clouds provide a developer-friendly way to create and deploy application code onto an on-demand, pay-for-what-you-use service platform. We’re enabling that at the edge—which has some exciting ramifications we’ll talk about in a second—but the basic idea is just convenient, agile cloud computing, at the edge.

Some of the Early Deployment Use Cases

The use cases already online do a good job of highlighting why cloud computing at the cellular edge is more than the sum of those concepts. First, we can factor in the cellularly determined and verified user identity and location. You can’t easily to that in today’s cloud. And then we can deploy application code in that context—trusting the user far beyond what’s possible today, and deploying the code near their location.  Sometimes we talk about this as “application mobility”—the users are mobile; let’s make the applications mobile as well. The initial deployments make the value of these new functions for immersive gaming and AR experiences clear. Authenticated location solves location spoofing issues in gaming and ride services. We’re quite sure this will prove to be valuable as autonomous systems start to be developed and deployed (e.g., cellularly connect self-driving vehicles).

The early augmented and mixed reality games and experiences also highlight the value of being able to push compute power out near the user.  In these applications, that enables the use of local context (e.g. a database about what’s in the user’s field of view) and provides high-bandwidth networking and data sharing among local users (e.g., location and movement sharing in a multi-person gaming or AR experience (these early deployments have shown a big improvement in the number of users that can be supported).

The final category of interesting deployments I want to talk about briefly is image processing and facial recognition.  It’s pretty obvious that “cloud” resources can augment the capabilities of a typical smartphone. If the image service is in today’s cloud, it will cost a lot to upload all of that video data to the cloud, so bandwidth savings is another pretty obvious benefit of edge processing.  But there are nuances that are quite possibly more valuable still. Image processing in the cellular infrastructure runs within a secure network—that’s pretty nice—no chance of data snooping. And then cellular image processing means that you know a lot about where the camera is and where the processing is done. That, in conjunction with our location specific control planes, means that regulation can be enforced within the location. So the data is secure and local, the video transmission is secure, and it’s pretty easy to enforce regulatory compliance. I bet you didn’t think of that before when you thought of a mobile edge-cloud!

Edge Use Cases

Check out companies that are bringing the power of the edge to applications today.

What’s New Technically?

OK, we’ve talked a little about why and what from the user’s point of view.  What have we built for the developer to make this possible (and easy). From a developer’s perspective here are some of the interesting bits.

Device SDK’s

First, we’ve developed device and platform independent SDK’s for Android and IOS devices—libraries that an be integrated into (for example) smartphone applications (in Java, C++, C# and REST so far) that enable the application, when invoked by the user, to register with the MobiledgeX edge-cloud, initiate deployment of backend code in an optimized location, and provide the cellularly derived, authenticated user and location information to the application as well.

The Distributed Matching Engine

We’ve created infrastructure we call the Distributed Matching Engine (DME) that does a number of interesting things. First, it’s distributed (as the name suggests). At the highest level it’s at the core of how MobiledgeX finds and uses the operator resources with which we build our edge-cloud (where we deploy our execution “Cloudlets”). Looking from the bottom up, the DME is integrated (to begin with) into Deutsche Telekom’s mobile network in Germany and is the means by which developers can assure the location and identity of the user which assures that this critical personal information is maintained securely (not disclosed to MobiledgeX for example).

The Control Plane

“Underneath” that (at least the way I think about it) we run a global and local (Germany in this case) “control plane.” A control plane is an application or (in this case) infrastructure “bus” that we use to control, share and gather data across the massive overall infrastructure (yes, we’re building this out on a global scale) while concealing a lot of complexity. For example, a developer doesn’t have to understand the complexity of the global infrastructure and yet has full access to all critical data; the control plane understands the nuances of how Cloudlets are deployed (in Germany we run on DT’s OpenStack infrastructure but in 1.0 VMware and native Kubernetes are supported alternatives) but those details are concealed where they don’t matter (in the end it’s all containers running on cloudlets). The control plane plays an important role in application deployment providing the context that enables optimal deployment, understands what resources are available where (does the application need a GPU?) and existing loads and capacities.

The Portal

Finally, we’ve created a global edge-cloud SAAS portal—a web interface system—that provides a view into all of this, allowing operators to visualize application execution and developers to insert and maintain the application code that runs in MobiledgeX provided containers (running on cloudlets).

Some Final Thoughts—Lambda Processing

AWS has created a lot of interest in what it names “serverless” computing.  The AWS Lambda systems let a developer specify little bits of code that are to be executed when particular events occur (real external sensed events or detected AWS system or application conditions).  Entire application systems have been built in this Lambda model. It's obviously not really “serverless”—AWS servers run all the code, it’s just that the developer doesn’t have to worry about getting the program to run on a server—it just happens.

That’s an interesting way to think about MobiledgeX as well. Our automatic deployment of container packaged code to an optimal edge location when a needing application is deployed by a mobile user fits that model—execution is triggered by events; the developer doesn’t have to worry about the server unpinings that do the work.

But if you’re familiar with AWS Lambda already there are some important (and valuable differences). First, we can deploy pretty heavyweight code to the edge that requires GPU support and does image process or AI or machine learning. Most of the Lambda uses to date have been for much lighter weight processing (Javascript execution, for example).

And we also know how to deploy mobile code that is positioned optimally for a mobile user. That may come to AWS Lambda at some point in time, but it’s not there now.

So that’s my story.  Finally, I want to express my awe and appreciation for all the hard work done by the MobiledgeX team, our Deutsche Telekom partners and all the early developers and builders using the platform.  It’s a complete pleasure and humbling experience to work with such an amazing set of people—I’m honestly awestruck. Thanks!