In the first blog in our three-part Getting to the Edge blog series, I discussed the key technology and business divers for edge computing. Communication service providers (CSPs) and equipment manufacturers are realizing that in order to meet the data demands of the 4th Industrial Revolution, workloads must move towards the edge and be closer to the customer. The combination of reduced latency and increased bandwidth associated with 4G and 5G applications is driving the new mobile edge. In this second blog in our series, I’ll explore the challenges of building an edge-focused mobile solution.
What Does it Take to Pull Together a Mobile Edge Solution?
Let’s use the ETSI MEC Architecture as an example. It is important to note that while this is a common MEC architecture, it is not mandatory and other architectures could be used. It pulls together all the major components required.
Figure 1: ETSI MEC Architecture
Starting from the top of the diagram is where you’ll find the mobile edge system level components and the bottom highlights the mobile edge host level components. The assumption here is that the edge host level components runs closer to the End User (EU).
I’ve next broken this down into eight domains, and each domain comes with a set of choices to choose from.
- 3GPP Network Choices
- RAN: Intel® FlexRAN or third-party, multiple split choices
- Packet Core: 4G, 4G with CUPS support, 5G Core
- MEC Host Location Choices
- Cell site, Aggregation site (Tier 1, 2, 3), Edge site
- Data Plane Choices
- Local breakout, Inline (uni vs. bi-directional), Tap
- NFVi Choices
- X86 CPU, GPU, FPGAs (NIC offload, Inline offload), Multiple Network Switch types
- VIM and Compute Environment Choices
- Bare-metal, VM/Containers, OpenStack, Container-based Micro-services
- MEC Mobility Choices
- Intra vs. Inter host mobility, Stateful vs. stateless application mobility
- Mobile Edge Platform (MEP) Choices
- Intel® NEV (now part of Akraino), third-party
- Edge Orchestrator & MEP Manager Choices
- ONAP, Cloudify, third-party, Extent of global vs. local orchestration
Each choice introduces tradeoffs that affect the overall solution architecture, and come with three major challenges to be solved, including:
- Identifying choices that map to each domain and location
- Software and hardware integration of those choices
- Functional and performance testing, including scaling
Optimal Choice for RAN, MEC Deployment
Let’s take a closer look at a couple of the domains – looking at the deployment choices on the RAN side and the location choices of where you can place the capabilities.
Figure 2: RAN Sliced for Different Use Cases
The 3GPP 4G/5G RAN deployment choices include three blocks: Centralized Unit (CU), Distributed Unit (DU) and Radio Unit (RU). There are a number of centralized RAN locations, including low level split all the way to high level splits available for deployment. Function placement depends on the specific CSP requirements. Other considerations for RAN architecture include physical site constraints and transport network constraints such as topology, latency and capacity. The system integrator’s role is to propose overall design/architecture and help to test and validate optimization tradeoffs for CSPs.
I covered these choices and tradeoffs in more depth in the webinar “Getting to the Edge – Exploring 4G/5G Cloud-RAN Deployable Solutions” that I encourage you to download here.
In the final blog in our “Getting to the Edge” series, I’ll cover pulling it all together. Stay tuned.
About the Author
