Apps World Series

Navigation Area

Lowering Costs and Driving Service Innovation by Migrating Capabilities to the Network Edge

Mobile Edge Congress

8 lessons from Mobile Edge Computing Congress 2016 Article


munich

 

Guest post by Iain Gillott, President at iGR.

Last week, I attended the Mobile Edge Computing Congress in Munich, Germany (I actually chaired the first day of the event). For those who pay attention to such things, yes, this year’s MEC event was at the same time as Oktoberfest. And yes, we had a beer or two!

The MEC Congress was a big success and it seemed that all the key players driving MEC forward were present. In addition to numerous presentations and panels, there were also a range of companies exhibiting their solutions. And six of the eight MEC Proof of Concepts were demonstrated:

PoC#3: “Radio aware video optimization in a fully virtualized network” – Eurecom, Intel, Politecnico di Torino, and TIM

PoC#4: “FLIPS – Flexible IP-based Services” – City of Bristol, CTVC, University of Essex, Interdigital and Intracom Telecom

PoC#5: “Enterprise Services” – ADVA Optical Networking, Bezea International, and Saguna

PoC#6: “Healthcare – Dynamic Hospital User, IoT and Alert Status management” – Argela, Quortus and Turk Telecom

PoC#7: “Multi-Service MEC Platform for Advanced Service Delivery” – Advantech, Brocade, Cloudify, Saguna, Vasona Networks and Vodafone

PoC#8: “Video Analytics” – Nokia, SeeTec and Vodafone.

In addition, iGR also attended an analyst afternoon at Nokia’s Munich offices, where Nokia demonstrated a number of video and entertainment MEC solutions. The fact that these solutions were running on commercial hardware shows that MEC solutions can be deployed today. As we shall discuss, while 5G needs MEC (or something like it that pushing content and processing to the edge), MEC does not have to wait until 5G is ready: many MEC solutions can be deployed today. Simply, MEC is as applicable in LTE environments as it will be in 5G.

From iGR’s perspective, there were several key takeaways from the conference:

1. MEC is ready now and does not need to wait for 5G

iGR believes this is perhaps the biggest misunderstanding with MEC today. Rather than being labelled a ‘5G solutions’ or ‘5G architecture’, MEC can be deployed today. In fact, Nokia was part of a team that demonstrated video applications at the Shanghai Formula 1 race in April 2016 – this used 80 – 100 cells in the stadium area to deliver video of the race and other information. But it was done using current technologies and did not require 5G radios or spectrum. Other solutions are running today that use MEC architectures – a good example is Vasona Networks’ SmartAir solution.

2. MEC needs application developers

One thing apparent in Munich was that, while the key players were all present, more developers are needed. Rather than simply talk about the benefits of the architecture, the industry needs folks who can build innovative solutions on the MEC architecture. And ideally, app and services developers who are not from the cellular industry but can think outside of the proverbial box and get really creative. This is analogous to Web developers – they did not have to understand how the servers and router that support the Internet worked – they just had to develop new apps and services. The same is true with MEC – creative thinking is needed to expand beyond the current Proof of Concepts.

3. The MEC name is likely to change

It is becoming clear that, with the work being done by the MEC group at ETSI, MEC does not just mean ‘Mobile edge computing’. Instead, the MEC architecture is being applied to low power networks, Wi-Fi and fixed wireless. MEC is really network agnostic and will suport a range of wireless protocols. The name ‘mobile’ implies 3GPP and cellular – this is no longer the case. The trick is to change the name without changing the acronym (the wireless industry likes to take this approach: remember when GSM was ‘Groupe Speciale Mobile’ and then became ‘Global Standard for Mobile’?). One suggestion is the MEC to be ‘Multi-access Edge Computing’. Get creative with the ‘M” and perhaps it could be ‘Massive Edge Computing’? Suggestions on a postcard to ETSI….

Another factor that needs to be considered is the influence of the other edge compute initiatives, like the OpenFog Consortium. The Open Compute Project also has a role to play here. One debate is where between the cloud and the edge do you put the processing and content, and what standards are used. With the name potential name change, and the continuation of the ETSI MEC standards initiative (see blow), we could see something that merges MEC and OpenFog, for example. OpenMist? Open-Cloudy-Day-with-chance-of -rain? 5G is not possible without MEC/Something like it – 5G sets some lofty goals for bandwidth and low latency. To achieve this, it appears that new architectures are needed and the processing needs to get closer to the edge of the network, which leads directly to MEC. Not all 5G apps and services will need MEC (or something similar), but many of the

4. 5G is not possible without MEC/Something like it

5G sets some lofty goals for bandwidth and low latency. To achieve this, it appears that new architectures are needed and the processing needs to get closer to the edge of the network, which leads directly to MEC. Not all 5G apps and services will need MEC (or something similar), but many of the high performance solutions will. For this reason, iGR believes that MEC/something like it will become part of the standard 5G architecture requirements, along with NFV and massive MIMO for small cells.

5. MEC has implications for data centers, backhaul and the whole mobile architecture

MEC puts more processing at the edge of the network, closer to the radios and BBUs. MEC solutions include processing power, storage and of course, connections back to the rest of the network. So if video is cached on a MEC appliance at the edge, that will necessarily need GBytes of storage on the appliance. Depending on the MEC solution (it could be a self-contained appliance or a rack mounted data center solution), the hardware needs to securely housed somewhere. This could be at the base of a cell tower or in a local data center. The end result is that this hardware and the MEC solution will need to be deployed, secured, managed and maintained.

6. MEC is an ongoing work-in-progress

The original mandate to the MEC committee by ETSI has been extended. The first term is due to expire at the end of 2016 and will:

- Define API principles
- Study items related to MEC integration in NFV and end-to-end mobility
- Work items to increase MEC market acceleration.

The next term is due to run for two additional years with the following objectives:

- Support for 3GPP and non-3GPP access (WiFi and fixed)
- Extend virtualization support types
- Support new charging models
- Fill gaps necessary for lawful interception
- Develop test specifications and methodologies
- Expedite development of innovative applications
- Study new use cases
- Enable MEC deployments in NFV environments.

7.  Where is the edge of the network?

This is an interesting discussion, especially where MEC is concerned. Again, this brings in a discussion of OpenFog. In reality, the true edge of the mobile network is the end user device, while many people stop their definition at the cell site radio and antenna. But MEC really works at the application layer and if the application is deployed on the device, MEC can ‘influence’ the device. This is important for the mobile operator, especially as Google and Apple are controlling more and more of the device environment. MEC potentially provides a way for the operator to gain back some influence on the end user device.

8.  Not all applications and services need MEC

While some of the discussion in Munich centered on connected cars and IoT, the reality is that MEC will be more suited to localized applications and services than network-wide apps. In the case where a user is crossing from one side of a city to another, for example, the app is likely better hosted in the EPC or cloud. Trying to coordinate handoff between multiple MEC ‘islands’ across the network will be complex and expensive. MEC therefore makes more sense when the user stays local, for example in a town center or stadium or campus. Note that this does not mean the user has to stay within a single cell – the MEC server can be located in a BBU hotel or hosting location and so can serve multiple cells.

iGR took away from the conference that the MEC community is busy and thriving. The names involved are big and are from outside the usual mobile vendor ecosystem. MEC marries IT with mobile – in fact, I started the conference off with a statement that MEC is the IT-ization of the mobile network. MEC opens up the mobile environment to the IT managers, vendors and solutions and removes the barriers. Rather than seeing mobile networks as ‘special’ (or difficult, depending on your viewpoint), MEC enables the IT folks at incorporate mobile into everything they do. It will be interesting to see how MEC evolves in the next few years and how it plays with other edge initiatives.

Iain Gillott, vendor and analyst as well as founder of IGR, chaired last week’s Mobile Edge Computing Congress. View his speaker profile on MEC Congress.

Share this post:

One Comment

  • Very well summarized blog on the event. Covers comprehensively all aspects from the event.

    • Amit Gurtu
    • 22 Nov, 2016 @ 09:08

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>