Welcome from Munich to 'This is My Architecture'.
Today, my guest is Steffen from EMnify.
Welcome Steffen.
Hi Thomas.
So Steffen, I'm curious, what are you holding in your hand?
Is EMnify in the movie business?
No, actually not.
EMnify is an API driven mobile network allowing customers
to reliably connect their devices anywhere in the world using cellular connectivity.
Okay, cool.
So I see your e-scooter.
So if I would operate a platform of e-scooters
how would I make use of the EMnify platform?
Yeah, first of all you probably would get such a real of SIM cards
in the form of very tiny chips, that you would solder into this device.
Okay.
So our customers, they have their e-scooter,
with a cellular modem,
and an EMnify SIM card,
and they also operate their backend application.
And in this example,
the e-scooter would regularly want to report its battery level and its coordinate.
and the customer application would for example,
want to unlock this e-scooter when an end customer wants to use it.
Okay, Steffen, let's go a little bit deeper into your architecture.
So looking here at the architecture,
it looks like you're doing quite a lot of heavy lifting.
So what actually needs to happen so that the e-scooter,
can communicate with the backend?
Yeah, first it needs to establish connection
through the mobile network,
so it communicates with the visitor operator,
and this is then sending a request into our platform.
But before this request can reach our deployment on AWS,
we first need a connectivity to all of these operators worldwide.
So we have roaming with more than 540 operators,
in more than 180 countries.
Wow, that's quite impressive.
And the network that interconnects all of these operators,
is the so-called IP exchange,
which is a global private network just for cellular roaming traffic.
And we are connected using multiple carriers,
via Direct Connect to have reliable connectivity
in all of the regions where we are deploying this packet gateway architecture.
Okay.
So the request when it then reaches our VPC,
is first received by a UDP network load balancer.
Okay.
And from there it's forwarded into our control plane application,
which receives this create session request.
And this is part of the GDP protocol,
which is used in mobile networks.
So actually what needs to happen that the scooter gets a response
and what's in that response actually?
What our platform then does it look up the configuration of this SIM card,
which features should be enabled, which security configurations,
as the customer defined previously.
Our customers are then able to configure these security features
using the API Gateway and our portal,
but they also integrate our platform into their applications
for automated device provisioning and configuration and monitoring purposes.
Makes sense.
So when we have this configuration read from the database,
first of all, our control plane
application here,
sends some of that information down to our user plane,
which later handles all the IP traffic.
And other parts of the systems are sent back as a response,
to this request to the mobile network,
and that includes information like for example, the IP address.
That is then used for the e-scooter.
So it's happening quite a lot for just establishing that connection.
But it's then ready really to send data.
So now is the scooter ready to communicate with the backend?
Yes, with all that information available,
there is basically a tunnel established from the visitor network to our network,
and through this the data can flow.
So are there any restrictions on protocols you can use communicate
with the backend? So like MQTT or HTTP or whatever?
Yeah, it's up to our customer which do the implementation,
and yes it could be HTTP,
but in the IoT use cases,
something better fitting like MQTT as you said for example
with a broker in AWS IoT would definitely make sense.
Okay, cool.
And this data is then sent into this tunnel from the device,
and then reaches our packet gateway application,
which does the accounting, firewall, and other security features.
And then it's usually then sent to our customer running on AWS,
via Transit Gateway or in their on-prem servers.
And to allow high throughput use cases,
we are using specialized framework for high-speed packet processing here
in this cluster of EC2 instances.
Well, amazing.
So what overall makes this architecture special?
Well, first of all that it runs on AWS,
this is a telco system,
and it's very nice to be able to use a standard network load balancer.
In other parts of the system,
we have developed our own load balancer just to handle the telco protocols.
Apart from that it's very nice since already 2016
in our cloud native mobile network,
whereas the rest of the telco industry just now slowly with 5G
is migrating into software-based architectures
and running those things in the cloud.
So we are couple of years ahead.
Awesome, that sounds amazing.
Steffen, thanks for giving us insight into your architecture,
and thanks for being my guest.
Thanks for the invitation.
And thanks for watching, 'This is My Architecture'.