Last March 2021, I’ve started my new journey in ETSI MEC, taking over the Chairman position from my friend Alex Reznik (HPE). Sure, of course I’m not a “beginner” in this group (as most of you who know me can appreciate that I’m there in the MEC Leadership Team since the beginning of the Phase 1!). Nonetheless, given the great work done together in these amazing years in collaboration with all MEC stakeholders, I’m grateful of the trust of many companies who elected me and expressed their warm support in my new role.
Last week I transitioned the position of Chair of ETSI MEC over to Dario Sabella from Intel. Having spent four amazing years serving as the Chair of this group, I am happy to see it in such good hands. For years Dario has been a significant contributor and an enthusiastic advocate of our work. He’s been the driving force behind many of our Hackathons. Moreover, Intel’s support and commitment for the group is a strong signal of our importance. The best days for MEC are in the future and this is where all of us should look. Still, leaving a position such as this, one does tend to reflect on one’s years of tenure and so for my last blog as Chair I am going to do just that.
I’ve been looking over some of my previous entries lately and noticed how many were touching on the subject of interaction between ETSI MEC and other standard and open source bodies. The subject is indeed still one of significant interest and the question about “fragmentation” and “competition” is one that comes up much too frequently.
Those of you who’ve read some of my previous musings on this subject might recall my position on this subject. Standards and open source serve very different functions: standards ensure interoperability between components where it may be necessary and open source provides implementations of such components. As such, the two types of bodies are highly complementary. Moreover, I’ve also maintained that even in the standards space itself little duplication of effort exists around MEC. Alas, hard evidence to support my view was previously missing – but that is changing fast.
Quite some time has passed since my last blog entry, and while I thought about a new blog a number of times, a good topic – i.e. one which is appropriate for discussion in a short, informal and public format - just did not seem to present itself. That’s not for the lack of interest or activity in MEC. 2019 is shaping up to be a critical year in which many operators are now public about their plans for edge computing, initial deployments are appearing and, as expected, holes in what the industry has been working on are beginning to be found (witness the much publicized and excellent Telefonica presentation at last month’s Edge Compute Congress). It’s just that it’s hard to blog about on-going work, even when it is very active, much less about internal efforts of various players in MEC. After all, what would that look like “this is hard and we are working hard on it…”
Nevertheless, the time has come. Those of you who follow my random MEC thoughts on a semi-regular basis might recall the subject of that last post ages ago (I mean in February): the need for both a vibrant Open Source community and Standards development in a space like MEC; and how the two are complimentary in that the focus is, by definition, on complimentary problems. And, if you don’t follow me religiously, here is the link: https://www.etsi.org/newsroom/blogs/entry/do-we-still-need-standards-in-the-age-of-open-source, grab a coffee, tea, a…. whatever … and read up!
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”?
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.
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.
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.
Mobile World Congress 2016 was busier than ever!
And Mobile Edge Computing was notably present at the event, on a lot more stands than in previous years. This certainly reflects the fact that meanwhile more than 60 companies have joined the ETSI MEC ISG.
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.