Talk about Multi-Access Edge Computing (MEC) based on SDN

The development of data generation and data processing has a strong impact on the demand and evolution of the underlying infrastructure network. 5G networks are often seen as the harbinger of ubiquitous high-speed connectivity that can meet data demands. That being said, 5G networks still face many significant challenges in fulfilling this promise.

[[241681]]

ETSI has proposed Multi-Access Edge Computing (MEC) to address some of these challenges. This article discusses these challenges and how to add network programmability to MEC to improve the overall MEC solution.

challenge

To support the growth of IoT devices, 5G wireless infrastructure will need to support a large number of connected devices and complex applications. This will require the network to support high scalability, ultra-low latency, high throughput, and reliable data transmission. These critical latency and bandwidth requirements prompted ETSI to propose multi-access edge computing as a viable solution to push services to the edge and closer to end users. But this approach also brings a series of challenges:

• Compared with high-end servers in the cloud, MEC servers have limited computing resources.
• The heterogeneity of requests from end devices needs to be handled. Some may require high computational power, while others may have more critical latency requirements.
• Load balancing between MEC servers may be required. Consuming the computing power of a small number of MEC servers while other servers are idle may result in increased service time.

Proposed Solution

One possible solution to address some of the above challenges is to introduce a MEC coordinator into the system. This MEC coordinator is aware of the available MEC servers and their capabilities (in terms of the resources and services they provide). In other words, the MEC coordinator acts as a proxy of sorts that connects applications to the right MEC servers.

The MEC coordinator isolates the operator from network decisions such as:

• MEC servers may have different hardware capabilities. Where can a specific instance of a MEC application be executed?
• MEC servers may have different computing capabilities and different MEC applications. Which MEC server should be used for a specific client/device request?

The MEC coordinator can make these decisions based on various factors such as server capabilities, current load, and its location.

Furthermore, the MEC coordinator can leverage SDN concepts for service discovery (to track instances of services) and orchestration (service instantiation and management) needs of MEC services.

The centralized SDN controller has a global view of the network. The MEC coordinator can be integrated with the SDN controller to collect information from the network.

The MEC coordinator can internally maintain a database of services available on MEC servers. It can use the SDN controller to connect the right MEC server to the application request. For example, an end user can request a facial recognition service just by mentioning the name of the service. The MEC coordinator will identify the MEC server that provides this service and add flows in the network accordingly.

Solving latency issues

The two main motivations behind the concept of MEC systems are computation offloading and latency reduction. The latency of centralized data centers or public clouds is very high. This is why MEC servers are deployed so close to the edge. Before deciding where to process a request, the MEC coordinator must make an intelligent decision based on the latency, energy, and bandwidth requirements of the client request.

There are two main considerations that must be taken into account when trying to reduce latency:

• The distance between the client and the MEC server that can handle this client request needs to be considered. The distance between the client and the MEC server is an important determining factor.
• The transmission cost needs to be compared with the local computation cost. This helps determine whether the computation should be moved to the MEC server or should be processed locally on the client.

The MEC coordinator needs to come up with a solution that minimizes the energy consumption of the devices and meets the execution latency constraints (latency requirements) of the client requests or applications.

In addition, the nature of the application needs to be considered - whether it is latency sensitive (high responsiveness requirements) or compute intensive. Latency sensitive requests should be moved to MEC servers close to the client (even if they have fewer resources), while compute intensive requests will target more powerful MEC servers (even if they are farther away from the client device). Therefore, different network slices from the same device may have different paths and may be handled by different MEC servers.

Integration of SDN controller and MEC

The first version of the MEC ETSI specification seems to be inclined towards providing MEC services as "network services" on a virtualized platform. These services are basically a combination of VNFs running software related to network middlebox functions. By building the solution on an NFV platform, the complete lifecycle of these MEC services (instantiation, termination, expansion, etc.) can be managed. The NFV platform also supports VNF forwarding graphs to implement service chains of VNFs on MEC services.

Adding SDN to the platform can make the network more flexible and dynamic. SDN allows a global view of the underlying network, so traffic steering rules can be applied to implement complex service chaining scenarios. It can be used to manage the network of interconnected distributed MEC servers.

The SDN controller can host a “MEC coordinator northbound application” which can be programmed to handle various scenarios:

• Monitor service instances running on MEC servers to determine which MEC server can be used to service requests from client applications on end devices in terms of computing power, storage area, or a certain service type?
• Monitor the capacity and utilization of MEC servers to decide which MEC server should be used to instantiate a service instance?
• If there are multiple MEC servers running instances of the same service, which one should be chosen to handle the end device request for this service? Ideally, the request should be moved to the server with less load.

Therefore, the MEC coordinator can reuse the SDN architecture, where customized northbound applications define the behavior of the network. The SDN controller provides northbound APIs for these applications to trigger commands. The controller also has a southbound interface (usually based on OpenFlow), which communicates with the managed devices (using OpenFlow switches in the network).

Commands from northbound applications in the MEC coordinator can be converted by the SDN controller into low-layer traffic control rules based on OpenFlow and sent to OpenFlow devices connected to or as part of the MEC server in the network. These OpenFlow rules can be integrated with the rules of the "traffic offload service" running on the MEC server. The "traffic offload service" is a MEC platform service responsible for routing traffic to the MEC application or MEC applications.

***, Status and statistics from OpenFlow devices can be communicated back to the MEC coordinator application by the SDN controller. This provides the MEC coordinator with a global view of the network and utilization/load on links/MEC servers.

Implementation Challenges

ETSI introduced the concept of MEAO (Mobile Edge Application Orchestrator), which is responsible for triggering the lifecycle management of MEC services. The SDN controller needs to integrate with MEAO to trigger MEC services on MEC servers based on its custom decisions/algorithms.

The SDN controller needs to be integrated with the agent (running on the MEC server) to achieve the following functions: reporting the capabilities of the MEC server; reporting client application requests to obtain the latest MEC server.

Handling UE mobility will create more complexity in the design. When the location changes, the SDN controller will have to change the routing/flow information between the user and the MEC server. The location service running on the MEC server can be used for active device location tracking and transmit the device location to trigger flow updates from the SDN controller.

When dealing with different workloads on the MEC server, you must determine whether the SDN controller should attempt to recalculate the best path while considering the service continuity of the device. The SDN controller may periodically reload the MEC server and update the flow accordingly. But the device is not aware of the existence of the MEC server. Any impact on the device's running traffic due to the device's computation being moved to the new MEC server is unacceptable.

in conclusion

To summarize, SDN can help MEC-based infrastructure in several ways:

• Computational load balancing: Use the southbound interface of an OpenFlow-compatible server to periodically collect OpenFlow-based statistics.
• Simpler end devices: By supporting service-centric access rather than host-centric access, all service instances can register with the SDN controller.
• Easy plug-and-play capabilities for network edge devices: SDN relies heavily on OpenFlow - new devices can be easily detected using LLDP/OFDP, and traffic rules can be easily updated.
• Decision making for computation offloading: A centralized SDN controller can provide devices with information about channel conditions, server load, etc.

Therefore, SDN concepts can be used in MEC to provide a unified control plane interface, retrieve network context or device information, and subsequently use this information for intelligent traffic control across the network.

Original link:

https://www.sdxcentral.com/articles/contributed/enabling-sdn-based-multi-access-edge-computing-systems/2018/08/