5G Networks – Just Over the Horizon

Introduction

How many times have you heard yourself say ‘this call might fail because I am boarding a bus/train/aircraft’? How many times have you tried making a call while in a busy area and found that the call does not get through? How many times have you lost mobile signals on a highway and not been able to make a call let alone access 3G/4G data? How many times have you struggled to send an email as you go in and out of a metro (underground) station? How many times have you screamed silently when connecting to a ‘free’ wifi is harder than learning how to fly a plane!

Finally how confident are you that high data rate services such as video calls, live streaming, YouTube etc. will continue to work as you commute, attend events (such as concerts), travel or just take a walk in a mall (reinforced concrete and steel are bad for mobile signals!).

5G networks aim to address many of these problems ‘out of the box’.

There are several major projects underway all over the world to produce specifications, proof of concepts, commercial and technology test beds. The European Commission is heavily involved via the 5G-PPP (Public Private Partnership) initiative which also means there is decent amount of funding available.

So what is 5G? How is it different from 4G? What are its major use cases? I will attempt to answer some of these questions in this post.

What is 5G?

Firstly while 5G is obviously about connecting wireless smart devices, it involves a whole lot more. Unlike our familiar 4G/3G network which is mostly restricted to the wireless domain, 5G aims to be a fusion of wireless and wired. The reason I call it a fusion is because the main thrust of 5G is towards removing boundaries between different domains (mobile, wifi, wired broadband) from the end user perspective and provide seamless access.

Seamless, On-demand Services

To enable seamless access for the user, all the various network functions and resources need to be packaged as a product, made accessible through a standard interface. On top of this you need a catalogue based mechanism which effectively allows stitching together of these resources and functions to provide a service to the end user.

Think of it like preparing a new dish. Once you get the recipe, you go to your local supermarket and gather the ingredients (resources) from a clearly laid out aisle. Then you come home and gather various cooking implements (functions) to process the ingredients. Finally you follow the recipe and transform the ingredients using the cooking implements into a dish – which you serve to the end user.

This is broadly speaking what a 5G network will attempt to do – while keeping track of the Quality of Service and ensuring Service Levels do not fall below an advertised limit. This equates to maintaining food quality at a certain advertised level irrespective of whether you are cooking at a campsite or in your own kitchen or in a restaurant.

For example if you are attempting to watch a HD video stream while on the move – all the resources and functions you need (and this is not a static set – as you may move in and out of various radio access technology domains such as 3G, 4G and Wifi) should be provided at a given point in time so that there is no disruption in the video stream.

Dawn of IoT

5G networks are also being designed, from the ground up, to support so called ‘machine type communication’. Machine type communication is characterised by a very large number of simple low-power sensors that require a data-link to push data to a gateway server. The data-link is usually wireless and often has low-bandwidth requirements. Several specialised sensor-gateway protocols are being developed (e.g. LoraWAN), but at a given level all that traffic will end up using 5G network links.

There are other machine type communication requirements that behave more like humans i.e. they require always on (mission critical) connections. For example an autonomous car may use an active data-link to pull down maps, upload sensor data or initiate transactions on behalf of the driver (e.g. pay tolls).

Current networks will find it almost impossible to maintain and service such a large number of hosts with such a wide spectrum of requirements.  In fact this is not a trivial use-case.

 

 

Comparing 5G with 4G

In this section I will highlight the principle differences between 5G and 4G and what features we can look forward to in the next decade:

End to End Latency: Latency is the time taken for a packet to travel from its source to its destination, lower the better. 4G = 25 milliseconds to 5G < 5 milliseconds (5 times less)

Reliability: Percentage of packets that are successfully passed through the network. In this case higher the better. 4G = 99.99% to 5G = 99.999% which means 1 in 100,000 packets is lost.

Service Deployment Time: The time to setup a new service should be as less as possible thereby allowing a faster time to market; basically no one likes to wait! The target is to reduce it from the current 4G wait of 90 days to 90 minutes for 5G.

Energy Efficiency: Energy Efficiency needs to be improved to 10% of current consumption! This is not an easy task and requires a new generation of hardware and software systems.

Device Density: Current networks (4G) support up to 1000 devices per sq. km. but for 5G networks the target density is 1 million per sq. km. Before you start asking how you could fit a million devices per sq. km (maybe if everyone is pushed underground because of nuclear war) remember the machine-type communication use-case with hundreds of thousands of sensors in a city centre environment which contains high density business spaces.

Mobility: Everyone loves fiddling with their phones while commuting. But the second you step on a train or enter an underground system things start going bad unless there is train based ‘free wifi’ or mobile signal boosters are installed. 4G works fairly well for up to 100-150 kmph speeds  (e.g. local trains) but fails badly as you get on the super-fast trains (e.g. intercity express trains that run above 200 kmph). 5G networks are being designed to support ground transport speeds of 500 kmph.

Peak Data Rates: This is a fairly straight forward one, 4G supports 100 Mbps and 5G aims to kick this up to 10Gbps. The one thing to note is that this is an ‘up to’ measure so not all users or locations will get the max (up to) limit. In urban locations a guaranteed minimum speed of 50 Mbps has been promised.

High Data Density: To support large number of human and machine hosts concentrated in a small area the 4G data density of 10 Gb/s/sq. km needs to increase to 10 Tb/s/sq. km.

Universal Provisioning: To improve services in rural or so-called low ARPU (Average Revenue Per User/Unit) areas. This is very important not just for the people living in rural communities but also for service continuity (e.g. while driving on a highway). The challenge is to find a trade-off between financial viability and service offerings in rural locations. 5G networks aim to solve this problem.

Make Your Own IoT Twitter Bot

Internet of Things (IoT) is one of the big buzzwords making the rounds these days.

The basic concept is to have lightweight computing platforms integrated with everyday devices turning them into ‘smart’ devices. For example take your good old electricity meter embed a computing platform on it and connect it to the Internet – you get a Smart Meter!

Basic ingredients of an IoT ‘device’ include:

  • A data source, usually a sensor (e.g. temperature sensor, electricity meter, camera)
  • A lightweight computing platform with:
    • low power requirements
    • network connectivity (wireless and/or wired)
    • OS to run apps
  • Power connection
  • Data connection (mobile data, ethernet or WiFi)

In this post I wanted to build a basic IoT sensor using an off-the-shelf computing platform to show how easy it is!

This is also to encourage people to do their own IoT projects!

Raspberry Pi and Tessel2 platforms are two obvious choices for the computing platform.

I decided to use Tessel2 which is lot less powerful than Pi (sort of like comparing a Ford Focus with a Ferrari F40).

Tessel2 has a 580MHz processor, 64MB RAM and 32MB flash (just for comparison Pi3B has a Quad Core 1.2GHz processor, 1GB RAM) – both have Wifi and Ethernet built in.

Pi comes with a Debian based OS with full desktop-class capabilities (GUI, Applications etc.) where as Tessel2 just supports Node.JS based apps (it is running Open WRT) and has no GUI capabilities. Therefore it is lot closer to a IoT platform in terms of capabilities, power requirements and form factor.

Temperature Tweeter Architecture

Temperature Tweeter Architecture

Architecture

Computing Platform: Tessel2

Tessel2 has a set of basic hardware features which includes USB2.0 ports, sensor sockets (where you can plug in different modules such as temperature, GPS, bluetooth) and one Ethernet socket.

Since there is no UI for the Tessel2 OS you have to install the ‘t2’ command line tool to interact with your tessel.

The Tessel2 website has an excellent ‘first steps’ section here.

If you are blessed with a Windows 10 based system you might have some issues with detecting the Tessel2. One solution is to install ‘generic USB drivers’ here. But Google is your friend in case you run into the dreaded: ‘Detected a Tessel that is booting’ message.

Data Source: Climate Sensor Module

The sensor module we use as a data source for this example is the climate sensor which gives the ambient temperature and the relative humidity. The sensor module can be purchased separately and you can connect up to two modules at a time.

Power and Data:

As the sensor is based indoors we use a standard micro-USB power supply. For external use we can use a power bank. The data connection is provided through a wired connection (Ethernet) – again as we are indoors.

The Node.JS Application

Start by creating a folder for your Tessel2 app and initialise the project by using the ‘t2 init’ command within that folder.

Create the node.js app to read data from the sensor and then use the ‘twitter’ api to create a tweet with the data. The application is really simple but shows off the power of Node.JS and the large ecosystem of libraries available for it.

One good thing about the Tessel2 is that because it is such a lightweight platform you really cannot run fulll sized Node.JS apps on it. As a comparison, a single Node.JS instance can use up to 1.8GB of RAM on a 64-bit machine where as Tessel2 has only 64MB RAM in total for everything that is running on it!

Most common type of applications that you will find yourself writing, in the IoT space, will involve reading some value from a sensor or attached device then either exposing it via a REST server running on Tessel2 itself (pull) or by calling a remote server to write the data (push).

In other words you will just end up writing pipelines to run on Tessel2 which read from a source and write to a destination. You can also provide support for cross cutting concerns such as logging, authentication and remote access.

If you want to Tweet the data then you will need to register a Twitter account and create a ‘Twitter app’ from your account settings. All the keys and secrets are then generated for you. The Twitter API for Node.JS is really easy to use as well. All the info is here.

The implementation can be found here: https://twitter.com/machwe_bot

Few Pointers

Don’t put any complex calculations, data processing or analytics functionality in the pipeline if possible. The idea is also that IoT devices should be deploy and forget.

Be careful of the libraries you use. Certain objects such as ‘clients’ and ‘responses’ can be quite large considering the fact that you only have less than 64MB of RAM to play around with. So you might want to run the program locally and profile the memory use just to be sure.

‘t2 run’ command allows you to test your program on the tessel2 while getting console output to your terminal. This is an excellent way of testing your programs. Once you are ready to ‘deploy and forget’ your Tessel2 just use the ‘t2 push’ command to load your Node.JS app on the device. Thereafter every time the device restarts it will launch your app.

Code

This is the code for the ‘Climate Tweeter’:

‘npm install’ will get you all the imports.

var Twitter = require('twitter');
 
var tessel = require('tessel');
var climatelib = require('climate-si7020');
 
// Init Climate Module
var climate = climatelib.use(tessel.port['B']);
 
var data = {
  consumer_key: 'your consumer key',
  consumer_secret: 'your consumer secret',
  access_token_key: 'your access token key',
  access_token_secret: 'your access token secret'
};
 
var client = (new Twitter(data));
 
setInterval(function(){
    if (climate_status) {
        // Read the Temperature and Humidity
        climate.readTemperature('c', function (err, temp) {
          climate.readHumidity(function (err, humid) {
 
            // Output Tweet
            var output = (new Date())+',Bristol UK,Home,Temp(C):'+ (temp.toFixed(2)-5) + ', Humidity(%RH):'+ humid.toFixed(2);
 
            //Tweet to Twitter
            client.post('statuses/update', {status : output}, function(error, tweet, response) {
                    if (error) {												
                        console.error("Error: ",error);
                    }                                                                                                                         
            });     
        });
    });
}},600000);
 
climate.on('ready', function () {
  console.log('Connected to climate module');
  // Climate module on and working - we can start reading data from it
  climate_status = true;
});

What next?

The interesting thing is that I did not need anything external to the Tessel2 to make this work. I did not have to setup any servers etc. I can very easily convert the device to work outdoors as well. I could hook up a camera (via USB) to make this a ‘live’ webcam, attach a GPS and mobile data module with a power pack (for backup) and connect it to your car (via the power port or lighter) – you have a car tracking device.

Enjoy!