5G Impact on Software Development

5G cellular network innovation has gotten everyone excited in recent years. It wouldn’t be an exaggeration to say that 5G cellular network has the potential to become a game-changer, not only for industries but for the entire world.

The great advantage of 5G is the speed at which it transfers data between devices and a huge number of concurrent network connections as compared to 4G. Although these are some of its many advantages that will change our lives.

In this blog post, we will explore the impact of 5G revolution on software architecture design. We will explore the architecture of an imaginary sample IoT application platform and will discuss what changes need to be done in its current architecture to accommodate 5G impact.

Before we deep dive into an IoT platform architecture, let’s first understand some functional requirements which this application fullfills. This IoT application allows its users to connect to IoT devices in the field and allows them to communicate and collect data from IoT devices. This application platform also allows users to visualize collected data in various actionable insights.

Below is the current application architecture which serves its users on 4G network. Let’s assume, current application architecture supports 0.01 million (1,00,00) IoT devices and can serve a couple of hundred customers and their users per second.

The current application architecture is capable to communicate with each IoT device in the field via a scalable network server, which collects data from IoT devices, validates and decrypts the payload and hands it over to the application layer for further business processing via a message broker. Both network servers and message brokers are scalable components and can handle the current application load.

The frontend application clients are also able to query backend servers for reporting and other data visualization purposes. Due to 4G network’s latency, the current application architecture can process 1000 concurrent users and 500 requests per second.

Fig-1: IoT platform architecture on 4G network (Architecture 1.0)

5G network supports more number concurrent network connections and has very low latency as compared to 4G network. If we switch from 4G network to 5G network, we can accommodate at least 0.1 (100000) million IoT devices and can serve a lot more concurrent users and a large number of requests per second. But this is not possible with the current application architecture, because scaling message brokers beyond certain limits will require a lot more hardware and is a tedious complex task, also the network server will not be able to manage concurrent network connections and process the data simultaneously from a large number of IoT devices.

The application layer also needs to be re-designed to serve more concurrent users and a large number of user requests per second.

To address all these concerns, we need to re-design application architecture and call it Architecture 2.0. Let’s discuss what architecture changes are needed and why they are important in the context of 5G.

For the sake of brevity, I have omitted NFR from the architecture design for now.

Architecture 2.0

The figure below shows the updated architecture of the IoT application platform to operate on 5G network with re-designed architecture components (Blue coloured).

Fig-2 IoT platform architecture on 5G (Architecture 2.0)

Scaling Network Layer

In order to scale the network layer (IoT device layer), we added new software components ‘Proxy Network Server’ and ‘Data Stream Processor’ to support a large number of IoT devices in the field. The proxy network server manages concurrent connections with the IoT devices, collects data from them and hands it over to Data Stream Processor for further processing.

The Data Stream Processor allows asynchronous data passing between Proxy and actual Network server. Data Stream Processor also handles back pressure in case of slower Network Server and Faster Proxy Network Server and vice versa. Data Stream Processor also allows us to generate intermediate data streams and can also persist raw data into persistent storage. Network Server will consume device data from DataStream Processor async, decrypts it and passes it to the application layer for further processing. Network Server also consumes communication commands to be sent to IoT devices from Message Broker, encrypts them and hands them over to Proxy Network Server via Data Stream Processor. Since Data Stream Processor, such as Apache Storm or Apache Samza are more scalable and manageable solutions at scale compared to Message Brokers, we can now handle a large number of IoT devices and data volumes.

Scaling Data Storage Layer

Since we are now able to handle a large number of IoT devices and can have more network bandwidth available due to 5G network, we can now collect more data points at less intervals. This will in turn increases data volume to be managed at the backend persistent storage layer. That’s why we also need to scale data storage and persistent layer in the architecture by adding horizontally scalable storage solutions. We also need to select different types of data storage solutions to meet different requirements (We assume that in previous architecture 1.0, only one type of persistence storage was there, mongoDB). For example, to manage users and their IoT devices along with authentication and authorization, mongoDB will suffice, but to store a large volume of data mongoDB will not work well, for that we need to choose Apache Cassandra or InfluxDB or ScyllaDB or Apache Hive or HBase or cloud storage such as DynamoDB or AWS Redshift or Snowflake. These highly scalable data storage solutions can handle a large amount of data and can scale as and when required.

Scaling Backed Layer

Now due to decreased latency, a new architecture must be able to serve more concurrent users and a number of requests per second. In order to achieve this, we have implemented microservice-based architecture as opposed to previous Service Oriented Architecture. We decomposed Device Manager and Data processing services into more fine-grained services, Device Manager Service (Manages IoT devices and their configuration), Device Communication Service (Manages IoT device communication), Data processing Service (processes IoT devices data and takes action) and Reporting Service (Data Visualization Service). This fine-grained decomposition of services allows us to scale our backend very effectively without affecting other backed services on demand.

Conclusion

5G revolution is going to bring lots of new opportunities and challenges. It is clear that current application architectures running on 4G networks will see a considerable amount of re-work and re-design to enhance their existing application architecture to cater huge increase in user traffic. Those who will adapt to these new architectural changes will be able to add value for their customers.