EMnify: Building a Cloud Native Mobile Network for IoT Leveraging AWS's Global Infrastructure
Summary
TLDRIn 'This is My Architecture', Steffen from EMnify explains how their API-driven mobile network enables global cellular connectivity for IoT devices like e-scooters. He details the process from SIM card integration to backend communication, showcasing EMnify's architecture on AWS with a focus on high-speed data processing and security. The platform supports various protocols and is ahead of the telco industry in cloud-native mobile network solutions.
Takeaways
- 🌐 EMnify provides an API-driven mobile network that enables global cellular connectivity for devices.
- 🛴 For e-scooter platforms, EMnify offers tiny SIM chips that can be integrated into the devices for connectivity.
- 🔒 The platform supports security configurations and features that can be managed via an API Gateway and a customer portal.
- 🌍 EMnify has roaming agreements with over 540 operators in more than 180 countries, facilitating global connectivity.
- 🔄 The IP exchange is a global private network for cellular roaming traffic, connecting multiple carriers for reliable service.
- 🚀 Data communication from devices like e-scooters to the backend involves establishing a connection through the mobile network and AWS platform.
- 🛡️ The architecture includes a UDP network load balancer and a control plane application that handles session creation requests using the GDP protocol.
- 📈 Customers can configure their devices for automated provisioning, configuration, and monitoring through EMnify's platform.
- 🔑 The platform responds to device requests with information such as IP addresses, facilitating data flow between the device and backend.
- 📶 Customers have the flexibility to choose communication protocols like MQTT or HTTP for backend communication.
- 🚀 EMnify's architecture is cloud-native, running on AWS, and is ahead of the traditional telco industry in adopting software-based and cloud architectures.
Q & A
What is EMnify and what does it specialize in?
-EMnify is an API-driven mobile network that enables customers to connect their devices reliably anywhere in the world using cellular connectivity.
How does EMnify enable connectivity for devices like e-scooters?
-EMnify provides tiny SIM cards in the form of chips that can be soldered into devices like e-scooters, allowing them to connect to the cellular network and communicate with backend applications.
What is the role of the cellular modem and EMnify SIM card in an e-scooter?
-The cellular modem and EMnify SIM card in an e-scooter enable it to report its status, such as battery level and coordinates, and to be unlocked remotely by the customer application.
How does the e-scooter communicate with the backend application?
-The e-scooter communicates with the backend application by establishing a connection through the mobile network, which sends a request to EMnify's platform hosted on AWS.
What is the significance of roaming with more than 540 operators in 180 countries for EMnify?
-Roaming with over 540 operators in 180 countries allows EMnify to provide global connectivity for its customers' devices, ensuring they can connect anywhere in the world.
What is the IP exchange in the context of EMnify's architecture?
-The IP exchange is a global private network used for cellular roaming traffic, interconnecting all the operators that EMnify works with, ensuring reliable connectivity.
How does EMnify's platform handle incoming requests from devices?
-Incoming requests from devices are received by a UDP network load balancer, which then forwards them to the control plane application that processes the requests according to the SIM card's configuration.
What is the GDP protocol and how is it used in EMnify's platform?
-The GDP protocol is used in mobile networks for session creation. EMnify's control plane application uses this protocol to handle requests from devices like e-scooters.
How does EMnify's platform enable customers to configure security features for their devices?
-Customers can configure security features for their devices using EMnify's API Gateway and portal, or by integrating the platform into their applications for automated device provisioning, configuration, and monitoring.
What is the role of the user plane in EMnify's architecture?
-The user plane in EMnify's architecture is responsible for handling all the IP traffic once the session is created and the device is ready to communicate with the backend.
What are the options for communication protocols that customers can use with EMnify's platform?
-Customers can choose from various communication protocols depending on their implementation needs, including HTTP or MQTT, with the latter being more suitable for IoT use cases.
How does EMnify ensure high-speed data processing in its architecture?
-EMnify uses a specialized framework for high-speed packet processing in a cluster of EC2 instances to handle high throughput use cases.
What makes EMnify's architecture special in the context of the telecommunications industry?
-EMnify's architecture is special because it is a cloud-native mobile network running on AWS, which gives it an advantage over the traditional telco industry that is just beginning to migrate to software-based architectures with 5G.
Outlines
📱 EMnify's Cellular Connectivity for IoT Devices
In this segment, the host introduces Steffen from EMnify and explores how EMnify's API-driven mobile network enables devices like e-scooters to connect globally using cellular connectivity. Steffen explains the process of integrating EMnify's SIM cards into devices and how the platform facilitates communication between the device and the customer's backend application. The discussion delves into the architecture, highlighting the establishment of a connection through the mobile network, the use of the IP exchange for global roaming with over 540 operators in 180 countries, and the deployment on AWS. The session also touches on the use of the GDP protocol for session creation and the configuration of SIM cards through the API Gateway and EMnify's portal for automated device management.
🌐 Special Features of EMnify's Cloud Native Mobile Network Architecture
This paragraph focuses on the unique aspects of EMnify's architecture, emphasizing its operation on AWS and the use of standard network load balancers alongside custom-developed ones to handle telco protocols. The conversation highlights the system's ability to support high-speed packet processing for high throughput use cases and the use of EC2 instances for this purpose. Steffen points out that EMnify's cloud native mobile network has been in operation since 2016, giving the company a significant head start over the rest of the telco industry, which is only now beginning to migrate to software-based architectures with the advent of 5G. The segment concludes with a discussion on the flexibility of communication protocols that customers can implement, such as MQTT or HTTP, and how data is processed through the packet gateway application for accounting, firewall, and security before reaching the customer's AWS or on-prem servers.
Mindmap
Keywords
💡EMnify
💡API
💡e-scooter
💡SIM card
💡cellular connectivity
💡backend application
💡GPRS
💡IP exchange
💡roaming
💡VPC
💡UDP network load balancer
💡GDP protocol
💡API Gateway
💡EC2 instances
💡Transit Gateway
💡IoT
💡MQTT
Highlights
EMnify is an API-driven mobile network providing global cellular connectivity for devices.
Customers can utilize EMnify's platform with SIM cards in the form of tiny chips for devices like e-scooters.
E-scooters equipped with a cellular modem and EMnify SIM card can report battery levels and coordinates.
The customer's backend application can unlock e-scooters for end-users via the EMnify platform.
EMnify's architecture involves heavy lifting for communication between e-scooters and the backend.
The platform establishes a connection through the mobile network and interacts with over 540 operators worldwide.
Roaming capabilities are facilitated by the IP exchange, a global private network for cellular roaming traffic.
EMnify uses Direct Connect for reliable connectivity with multiple carriers in various regions.
Incoming requests are received by a UDP network load balancer within the AWS Virtual Private Cloud (VPC).
The control plane application handles the create session request as part of the GPRS Data Protocol.
Customers can configure security features for SIM cards using the API Gateway and EMnify portal.
The control plane application sends information to the user plane, which manages IP traffic.
The response to the mobile network includes information such as the IP address for the e-scooter.
A tunnel is established from the visitor network to EMnify's network for data flow.
Customers can choose communication protocols such as MQTT or HTTP for backend communication.
Data sent from the device goes through EMnify's packet gateway application for accounting and security.
The architecture utilizes a specialized framework for high-speed packet processing in EC2 instances.
EMnify's cloud-native mobile network has been running on AWS since 2016, ahead of the telco industry's migration to software-based architectures.
The architecture's uniqueness lies in its operation on AWS as a telco system and the use of standard network load balancers.
Transcripts
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'.
Browse More Related Video
AWS Solution Architect Interview Questions and Answers - Part 2
Internet Of Things (IoT) In 10 Minutes | What Is IoT And How It Works | Great Learning
Improve API Performance by Utilizing the Platform Cache
What is the Internet of Things (IoT)?
In Demand TECH Jobs in 2020 (What you should study?!)
Cisco Spine-leaf Network Topology | Cisco CCNA 200-301
5.0 / 5 (0 votes)