Opportunities with dynamic device offloading as a 6G service

Over the past few years, the telco industry has been undergoing its own digitalization journey. Today, increasingly virtualized commodity hardware assets form the base of already vastly distributed network infrastructure. These infrastructure investments promise multiple benefits such as reduced operational costs, increased deployment and development agility, and maximum performance of network functions. Importantly, they also allow communications service providers (CSPs) to evolve their networks into a platform offering services beyond connectivity.

As part of our journey toward 6G, we see an opportunity to take advantage of these vastly distributed, virtualized network assets to offer network integrated compute. Our vision is a dynamic computational offloading service exposed by developer friendly, programmatic application programming interfaces (APIs). CSPs are typically local actors operating under strict regulations by national laws and data protection policies, so we consider them especially well-suited to handling sensitive data and tasks.

Dynamic computational device offloading as a network service

The core idea behind dynamic computational offloading is to expand application functionality from the connected user equipment (UE), for example, mobile phones, drones, extended reality (XR) glasses, or IoT devices, to a compute environment that is part of the network (see Figure 1).

Figure 1: Dynamic device offloading and some of its benefits

Typical edge computing solutions target the edge from the opposite direction. They move application functionality traditionally running in the cloud to edge or on-premise compute facilities. In this interpretation of edge computing, an edge site is basically an extension of the cloud, located closer to the user device. Such edge application deployments typically involve relatively static, pre-deployed application servers targeting vertical use cases with large groups of users.

In contrast, our envisioned computational offloading service aims at a dynamic and flexible deployment of highly granular application tasks, triggered by the device or the application based on situational changes. Such a solution would be use-case agnostic, offering sandboxed, network-embedded compute to any application running on a mobile device. As such, it has the potential to target even the long tail of regional enterprises and developers who will not engage in heavy burdens in deployment, management, and contract handling related to contemporary telco edge computing offerings. We aim for a lightweight and lean solution, which offers developers convenient programmatic APIs when designing applications and allows end users to enjoy the benefits as part of their existing subscriptions.

At this stage, we would like to point out the potential benefits such a solution would offer to the main actors involved:

Application end-users would benefit from the automated capabilities to balance compute and energy tradeoffs between the user device and the offloading site. Quality of experience can be improved when certain parts of an application are not executed in the device but on an external, more powerful compute infrastructure. Enhanced graphics, higher frame rates, and shorter computation times are examples of possible benefits. At the same time, device battery life and heat generation can be improved. For very lightweight devices, like head-mounted devices or IoT sensors, this might be the only option to offer a richer application experience. To make the service attractive, automation is important, so that involvement and complexity for the application end-user can be minimized.

Application providers would be able to differentiate application features and performance through the possibility of customizing application deployment based on the requirements and current situational context of individual customers. Critical parts of an application can be separated to be deployed remotely as a reaction to dynamic changes in the environment. Such changes could be in device battery levels or connectivity quality and could involve users moving between cells, or application-specific events like new players joining or a temporary need for higher rendering resolutions.

With offloading realized by a lightweight and lean framework and associated programmatic APIs, this won’t require much extra development work. In addition to improved application behavior for individual users, the set-up helps support synchronization and coordination among a set of collaborating users, for example in augmented reality gaming or the collaborative perception of vehicles and drones.

CSPs can find new revenue streams by bundling computational offloading with connectivity services. Mobile networks and their network functions together already form a vast distributed application, so novel network offerings related to distributed compute could reuse many existing services and procedures, for example, authentication, identity management, and other management functions. Remote offloading sites would be fully integrated into the network, which means that access to network internal information can enable a leaner and faster solution with localized procedures and decisions. Since the connectivity and compute resources required for an application would be managed and controlled jointly, new optimization possibilities arise, for instance with respect to local RAN utilization, device-specific packet handling, and collaborative orchestration of resources in a common location close to all participating users/devices.

Commercialization and Adoption

Beyond the technical aspects, a crucial dimension for the success of computational offloading is commercial availability. Giving the development of smartphone applications to almost everyone promotes innovation. In the same way, we want even the smallest application providers to be able to leverage computational offloading to innovate within their applications.

For application providers to successfully build on computational offloading, the service needs to be available to all their users when and where needed. For the telco industry, this is not an easy problem to solve. The user base for an application is most often geographically distributed, maybe even globally, so a computational offloading service needs to be available on a global scale to be attractive. Even users located in the same geographical area will get their mobile connectivity service from different national CSPs. As computational offloading would be bundled with connectivity, application providers would need to rely on the computational offloading services individually offered by each of these CSPs.

Ultimately, this means that the application provider will need to be capable of leveraging the services of many CSPs. The more diverse the audience, the larger the geographical area, and consequently the more CSPs involved. Hence, it is important to explore how to make it as simple as possible for the application providers. For example, they'll require assistance in avoiding the need to individually integrate and establish business relationships with each of these CSPs.

We identify three main routes:

1. End-users subscribe to a computational offload service from their CSP.
2. Applications providers sponsor the usage of the computational offload service.
3. An aggregator is introduced.

Let’s explore these options.

End-user subscriptions

One option is to rely on the application end-user to procure all the necessary services from the CSP. In the same way that a smartphone application already relies on its user to buy a mobile broadband service, the user may also be expected to buy a computational offload service from their CSP, probably as part of the same subscription (see Fig. 2). In this context, the interface offered by the computational offload service would need to be standardized, allowing for the application to use it, irrespective of the CSP delivering the service.

Figure 2: End-user driven relationships

A possible weakness of this scenario is that it relies on the willingness of the subscriber to subscribe to a computational offload service. One pitfall to consider here is complexity: it should be as straightforward as possible for the subscriber to add the service to their existing mobile subscription.

Another important aspect is pricing. In this scenario, the subscriber is directly exposed to the cost of the computational offload service. Hence, it is crucial for the subscriber to understand the value of the service. The emergence of a killer application relying on computational offload would certainly resolve that.

Application provider sponsoring

Another option is for application providers to sponsor the usage of the computational offload service. Here, the subscriber is still the one subscribing to the computational offload service, and the application provider sponsors the portion of the cost attributed to their application . The subscriber pays the application provider for the use of the application, and the application provider pays the CSP for their usage of the computational offloading service. Thus, the subscriber would not be exposed to the full cost of the computational offloading. Using the application generates no cost for them, beyond the cost of the application itself . However, implementing such a sponsoring scheme may not be straightforward. For instance, the coordination of the technical and business aspects of sponsoring may require complex integration to be performed between the application provider and CSP.

Aggregator

One solution to make it simpler for application providers to leverage services from multiple CSPs is to introduce an aggregator. The aggregator would take care of business relationships and technical integration with the CSPs. They could even play a role in smoothing out the differences between the services each CSP offers, for example, differences in the API or in the functionality they support. The application providers would just need one relationship—with the aggregator. As for the subscribers, they would simply buy the application from the application provider.

A remaining challenge would be for the application providers to successfully monetize their applications in a way that allows them to pay for the cost of the computational offloading service.

Figure 3: Aggregator driven relationships

This aggregation scenario hinges on the emergence of one or multiple aggregators capable of providing a profitable service: a service that combines the offers from enough CSPs to build an offering covering the needs of the application providers. The effort required for the aggregator to combine all the offerings directly depends on the uniformity of the services and interfaces provided by the different CSPs. Through the standardization of appropriate exposure services, the telco industry could help alleviate the burden that falls on the aggregator and lower the cost associated with the aggregation.

Conclusions

With computational offloading, we believe that the mobile network has the potential to improve the subscriber experience on mobile devices, while simultaneously providing application providers with more capabilities to innovate. Going further, such a service could help strengthen the place of the CSP in the mobile application ecosystem.

At Ericsson Research, we are currently developing both the technical capabilities that make this service possible, and the support functionalities needed for the CSP to commercialize it. Ultimately, we want to ensure that this service falls into the hands of all the application developers and providers that can benefit from it.

Learn more

Follow the journey to 6G

Global Network Platform

Network Compute Fabric

Edge computing