Back

Blogs


There is a sense in our community that while industry-standard interface definitions are important, these do not have to come from traditional “Standards.” Instead they can come from a development community, e.g. from an open source project.  Moreover, having these come from an open source project is better because the result is not just a document, but running code. Before I dive into this, let me be very clear: open source has had and continues to have tremendous and largely positive impact on our industry and beyond.  It dramatically lowers barriers to entry into the market and in doing so enables small, nimble and highly innovative companies to play on a more equal footing with large established players.  

But let me focus a bit more on whether open source eliminates the need for traditional telco standards, as many believe.  To illustrate the point, I need to pick on a project, so let me pick on OpenStack.  Not because it’s bad… quite the contrary because it is so very good and is quite important to our industry’s transition to NFV.  As anyone who has worked with OpenStack knows, developing to the OpenStack API requires specifying:

  • Which version of OpenStack you are developing to and which APIs you need. 
  • Which OpenStack you are developing to (RedHat, Mirantis etc.)

Yes, they are almost the same – but almost is not quite the same as the same.   And when you are a small company, having 100 edge clouds that present almost the same interfaces still leaves you with the challenge of scaling to integrate with 100 different – slightly, but still different – implementations.   In other words – you are still missing a standard. 

This is not OpenStack’s fault, nor is it the fault of the several companies that harden and commercialize it for the market. The primary goal of OpenStack has been and remains to enable its users to get to market as fast as possible and to concentrate their investments where they believe they can add value to the base.   Interoperability should be a side benefit (and good open source projects like OpenStack do try hard to maintain backward compatibility, etc.), but it is not a primary goal. In an ideal world, open source projects would utilize formally Standardized interfaces in those areas where these are needed – i.e. where large-scale inter-vendor interoperability needs are expected. 

As the development of a Telco edge picks up steam with TIP, Linux Foundation and OpenStack all having launched large scale project focused on the telco edge, ETSI MEC is perfectly positioned to fill that role.  Our service APIs are precisely the APIs that exist at the intersection of the needs of a large number (100’s) of global communication service providers (CSPs) and an even larger number (100 000s) of application developers that need to use services exposed by the CSPs.  In such an environment a lack of standardization can be a significant barrier to the evolution of the market and we remain the only standards development organization focused on this issue. 

Moreover, by serializing these APIs – see https://forge.etsi.org/gitlab/mec - we are enabling software developers (and yes, particularly open source developers) to easily integrate our work in their applications. No more reading standards documents in PDF! Furthermore, to accelerate and encourage the development of new and innovative services in this growing Telco edge ecosystem, we have recently established a working group (DECODE) to focus specifically on issues around enabling the use of these APIs in forums such as open source.

So the conclusion of this post is a call to action – we are here and ready to help you get the Edge done!  Let us know how we can help. 



One problem with summer holidays in our industry (or is it a benefit?) is that one tends to let certain things slide and to enjoy more time away from work – whether it be on a formal vacation or just by working a little less than our usual “40 hours” – a very loooong 40 hours – per week. I am certainly guilty of that this summer – and one of the things I am guilty of is not highlighting some really important output from the ETSI MEC ISG. But… as they say… better late than never. So here it goes, but let’s start with background and get to the cool things ETSI MEC produced as we go.

We’ve all heard that “MEC is a 5G technology” although what that means is not exactly clear. In fact, in my very first blog posting, I highlighted that this can lead to some of my (least) favorite “MEC myths”. Here those myths are, re-stated:

  • MEC is a 5G technology, so until I roll-out a 5G network I don’t need to worry about it
  • ETSI MEC will be made irrelevant as soon as 3GPP defines its AF/NEF
  • MEC is only needed before 5G, at which point CUPS (meaning the UPF) replaces it

Side note: yes, the first and third statements are in fact mutually contradicting. But these are myths, they don’t need to be mutually consistent.

Clearly, I disagree with all of these statements, but what is the truth “according to Alex”?


What is Edge?

2018-05-14 Posted by Alex Reznik, Chair of MEC ISG 1968 Hits

Recently, one of the ETSI staff folks pinged me an e-mail that said, “Someone asked me ‘What is Edge’ and I could not quite reply. Can you help?” Well, come on! The answer is simple. 

Edge is… and this is where I got stuck. Really, the answer depends… well… on who you ask and when or where you ask them. And this, really, is how some blog posts are born.

Let’s start with examples. Amazon seems to have a clear definition of what edge is – just look at Greengrass.

Microsoft more or less agrees with them, ergo Azure IoT Edge  or AzureStack.

So there we are – the definition of the edge. Take your favorite cloud provider, one with the foresight to “extend” their cloud to on-prem deployments either on IoT devices or otherwise and that’s the edge. Well, that is an edge, and, perhaps in the world of Enterprise IT computing it is the prevalent type of edge, but in Telco (i.e. in the world of MEC) it is not – it’s just an edge.



Let’s start at the beginning, as the saying goes; and in the case of this blog that seems to be the question of what the group I work in – ETSI MEC – does, what it produces and how it fits into the overall Edge Computing ecosystem.

Coincidentally, this is related to one of my favorite myths, which goes something like this. “There are soooo many standards, industry bodies and open source groups working on MEC. With all of these organizations competing with each other, it’s not clear which one to choose. I think we need to wait for the dust to settle before doing anything in MEC.

Like most myths, this one has a not-so-small core of truth. It is true that there are quite a few standards, industry bodies and open source groups working on Edge Compute related topics. And, it is certainly true that this has created a certain amount of confusion in the marketplace.



A blog about MEC? Well, as the chair of ETSI’s MEC ISG for a year now, I wondered what was there about MEC that could be said in a blog format; that would be of real interest to the community; that would have some chance of making me the social media superstar of edge computing?

This took some sleeping, but one fine sunny morning in Shanghai (during our very successful 13th plenary), I hit on an idea. One of the privileges of chairing a standards group is that you get to represent that group in various public events. And so, over the past year, I’ve been doing a good amount of public speaking on edge computing in general and MEC specifically. I’ve also been doing quite a bit of “private speaking” of a similar kind, as part of my day job at HPE.

Thinking back over all that speechifying on that fine sunny morning in Shanghai I realized that much of it is spent addressing the MASSIVE CONFUSION that exists around MEC – and that much of what I say is constant across the various venues and audiences. And so… why not use the tools of social media to get the message out and try and dis-spell some of that confusion.


The race is on!

2016-04-29 Posted by Dirk Lindemeier, Nokia 4289 Hits

Two weeks ago I had the pleasure to attend the Formula 1 Chinese Grand Prix in Shanghai. A pleasure not only because a German guy won the race; my real excitement, in fact, came from the world’s largest deployment of Mobile Edge Computing in a live network to date.

China Mobile and Nokia, at the Shanghai International Circuit, deployed an ultra-dense network of small cells and several MEC servers for providing a 5G-like mobile broadband experience. Spectators could follow the race from different in-car, trackside, and airborne camera perspectives and dashboards, all delivered in real time into an intuitive-to-use app. MEC made a huge difference in video latency and quality, which was testified by a user survey indicating high satisfaction and willingness to pay.



I had the great pleasure to represent the MEC ISG as ETSI MEC ISG chair and to present Mobile Edge Computing at the co-located 5G Observatory and Fog Networking conferences that took place on March 8-11, 2016 in Paris. Philip Lamoureux from Juniper represented the ISG at the MPLS+SDN+NFV world congress. Both congresses were endorsed by ETSI.
The congress attracted 1500+ attendees, coming from 65 countries, with a strong presence of service providers.




The ETSI Mobile Edge Computing Industry Specification Group opens the door to wider innovation and value creation.

What is Mobile Edge Computing (MEC)?

MEC offers IT service and cloud-computing capabilities at the edge of the mobile network in an environment that is characterized by proximity, ultra-low latency and high bandwidth. Furthermore, it provides exposure to real-time radio network and context information.

Imagine how all this can be intelligently leveraged by applications to transform the mobile-broadband experience.


We use cookies or similar technologies to collect data about your use of this website and to improve your experience when using it. To find out how to disable our cookies, please visit our Privacy Policy.

  I accept cookies from this site.