Sunday, July 26, 2020

5G at the Edge: How MEC Accelerates 5G Deployment

Two organizations that have been working on the development of Multi-Access Edge Computing (MEC) in the mobile space are expected to announce early next month specifications for the technology.

One is the ‘5G Future Forum’, an operator-led group that came together in January , that includes Verizon,  Vodafone (Europe), Telstra (Australia), America Movil (Latin America), Rogers (Canada) and South Korean carrier KT.


Recommended:


The other is the European Telecommunications Standards Institute (ETSI) that established an MEC initiative back in 2014, betting that the technology represents a key architectural concept capable of enabling the evolution of 5G.

It is now becoming clear that MEC can indeed play a significant role in reducing latency in 5G networks. It will also shift and spread the load of cloud computing to reduce congestion in mobile networks by bringing data closer to the end user and streaming it more directly to mobile phones and tablets.

Alex Reznick

At the moment, most applications handle their online computations and content storage on remote servers that are typically located far away from the end user. The promise and premise of MEC is to bring these processes closer by allowing them to be integrated into local base stations.

The 5G Future Forum is expected to detail within weeks two key specifications for what it terms MEC Experience Management and MEC Deployment.

The former will define a set of intent-based APIs for “functional exposure of edge and workload discovery with potential expansion to include further MEC functions and capabilities which are driven by network intelligence.” Meanwhile MEC Deployment envisages a technical roadmap for service providers “to deploy and integrate global MEC physical frameworks, including facilities (for instance power and cooling), monitoring, operational considerations and security.”

There are suggestions that the Forum will also reveal a tactical switch away from its operator-only focus. According to Rima Qureshi, Verizon’s chief strategy officer, this would include companies already involved in the development of use-cases for 5G such as machine learning, smart cars and cities, IoT applications, virtual and augmented reality and autonomous industrial equipment.

Separately and coincidentally, Verizon last week announced it would be collaborating with IBM on 5G and edge computing innovations, combining the operator’s 5G Multi-access Edge Compute  capabilities, IoT devices and sensors at the edge with IBM’s expertise in AI, hybrid multicloud, edge computing, asset management and connected operations.

The deal also includes collaboration on potential combined solutions for 5G and “MEC-enabled use cases such as near real-time cognitive automation.”

Initial projects will focus on ready-made targets such as mobile asset tracking and management solutions, while more long-term ideas might include such hot-button topics as remote control robotics, real-time video analysis and plant automation.

Over in Asia, South Korea’s SK Telecom has also organized a group of local companies, primarily operators, to establish the ‘Global MEC Task Force’. Companies on board include SingTel, Globe, Taiwan Mobile and PCCW Global, the strategy for now being to share research and development data on developments in 5G and MEC across the region.

Meanwhile, in Europe, ETSI’s Specification Group focusing on Multi-Access Edge Computing  (ISG-MEC) earlier this month unveiled  a novel MEC service for ‘Wireless LAN Information’, that will allow specific applications to take advantage of the latest information from the underlying WLAN access networks.

According to Alex Reznik, Chair of the ETSI MEC group, the API “meets enterprises’ requirements as they increasingly take advantage of a heterogeneous wireless network access strategy, comprising both WLAN and mobile technology-based solutions.”

It is worth noting that this specification, dubbed ETSI MEC GS028, specifically targets enterprises.

The group also stressed in a report issued earlier this year that MEC functionalities will need to support network slicing and discussed the impact this might have on emerging specifications. The researchers looked at the four most common slicing concepts — those from the 3GPP, the NGMN (Next Generation Mobile Network) Alliance, the Open Networking Foundation (ONF) and its own specification.

It has prioritised those from the 3GPP and its own in the use cases for its Phase 2 work on the topic as these were considered to represent the most appropriate functionalities needed to support the on-going work.

The initial Phase 2 specifications were released last March. They focus on architecture, framework and general principles for service APIs, and a broadening of support for different access technologies and NFV (network function virtualization) integration.

Indeed another report released in January  suggested that “most of ETSI’s MEC specifications are virtualization technology agnostic” and would thus require minimal updates of existing standards.

“We know that non-VM based virtualization is a key technology for edge  computing. We therefore wanted to make sure that the ETSI MEC architectural framework is capable of supporting such technologies and that it is consistent with ETSI NFV,” commented Reznik.

He added that the good news regarding this virtualization agnosticity just highlights the quality and future proof capabilities of the APIs ETSI has managed to achieve within this standardization effort.

Last year, the group started work on the next stage of its virtualization project, Release 4, which will focus on enhancing NFV infrastructure (NFVi) to support lightweight virtualization technologies such as containers.

There is a wealth of information on the whole topic of 5G and MEC networks in a 2018 update on ETSI’s original white paper.

mobile edge
Integrated MEC deployment in 5G network. (Source: ETSI)

The standards group is planning to publish an update on this within days.

Here, ETSI acknowledges that the specifications developed are not necessarily a total blueprint for how to build an MEC. However, the report does lay out the key points regarding 5G MEC deployment.

It also stresses that MEC, in an LTE context, had to be designed as an add-on to a 4G network so as to offer any kind of service in the edge. Importantly, with 5G, “edge computing was considered from the beginning to be one of the key technologies required to support [requirements such as] low latency together with mission critical and future IoT services.”

In the past Reznik has commented that it is possible for the industry to do edge computing without 5G, but you can’t do 5G [applications] without edge computing.

The next key step for ETSI is to seek out a host of developers to its framework. Towards this end, the organization recently created an online edge emulation environment designed to aid application developers   learn about and experiment with the MEC Service APIs, in both emulated city and indoor environments.

Such implementations should demonstrate the necessary interaction among MEC services, edge applications, the end user and access networks, including 3GPP LTE/5G and WLAN.

Initial releases are expected later this year.

Having said all that, a report earlier this year from IDC urges caution. While praising ETSI’s achievement to develop a ‘basic’ framework for MEC, it notes that CSPs “will still need to build their own cloud-native server solutions and software stacks that integrate into the 5G infrastructure and support a variety of real-time and non-real time applications.”

As such, the market research group considers that “the business model for MEC is still a work in progress,” and that the industry is also exploring alternative models.

The post 5G at the Edge: How MEC Accelerates 5G Deployment appeared first on EE Times Asia.



from EE Times Asia https://ift.tt/2ZZcEp6

No comments:

Post a Comment

Please do not enter any spam link in the comment box.

How I channel my inner Star Trek character at work

In a recent Twitter thread , I self-identified as "some days Deanna, some days Riker." Others shared their own "Star Trek Sp...