IoT in 5G Network – Research by Jayakumar. S PhD – Part 2

Editors Pick

5. Intelligence Inference in IoT Data

IoT in 5G appears to be enjoying two major functional features such as “massive onboarding of IoT Nodes” and also “low latency communication from IoT Node to Cloud Native Applications”


IoT Edge serves as a telemetry system to collect data and transfer it to Cloud-native applications. But in 5G, there is an Edge network introduced in which the latency time is much less to respond to a given Event in an IoT Node. IEEE 21451 is one of the popular standards that have been used for handling the above mentioned IoT Node-based events in the industrial control segment. Further, IEEE is bringing a standard P1451-99 to establish service harmonization.

6. Smart Sensors (IEEE 1451)

“The expansion of smart sensors usage is being hindered by the lack of a universal standard, especially in the wireless region. Recognizing that no single sensor bus or network is likely to dominate in the foreseeable future, the IEEE 1451 set of standards was developed to unify the diverse standards and protocols by providing a base protocol. One feature of the IEEE 1451.0 open standard is that the data and TEDS of all transducers are communicated on the network (Internet) with the same format for all sensors and actuators for both wired and wireless networks. The development of the main parts of the IEEE 1451 standards, including those relating to wireless, have recently been approved. This smart transducer standard is illustrated with several wired and wireless network examples.”

(Reference: https://ieeexplore.ieee.org/document/4374241 )

  • 21451.0 covers high-level common operations and a general TEDS format
  • 21451.1 provides a “…common object model and programming paradigm for smart transducer systems.”
  • Both 21451.0 and .1 communicate with the actual sensors and actuators through a number of communications alternatives that I’ll summarize here. Each of these has a TEDS specification.
  • 21451.2 provides a point-to-point TIM-to-NCAP connection.
  • 21451.3 provides a multi-drop TIM-to-NCAP connection based on HPNA – the home phone protocol.
  • 21451.4 provides a special mixed-mode interface for analog sensors that have analog and digital modes.
  • 21451.5 deals with wireless interfaces between TIM and NCAP.
  • 21451.6 provides a TIM-to-NCAP interface via the CANopen protocol for safety-critical applications
  • Ref: https://www.eejournal.com/article/20150504-ieee/

5G network provides an option to plug IEEE 21451 as a part of handling IoT data flow and also associated AI-based applications for modern industrial, healthcare segments, supply chain, and several business verticals. The following diagram provides information on the application layer to the hardware layer. It appears that Openshift actually plays a key role in automating the delivery of workloads on RHEL and associated hardware from Intel and BAREFooT. Mentioned deployment is using a software solution from Kaloom to automate Network related workload.  However, Kaloom provides support to User Plane Functions, but there is no provision to handle IoT data such a time sensitivity parameter can be taken care of. The following diagram provides software and hardware used in Leaf or Spine Switch. Tofino is an ASIC processor to perform high-speed packet switching and also P4 language is used to program Tofino. A similar thing is done with FPGA (stratix 10) as well.


The above diagram shows a reference architecture of IEEE 21451 based IoT systems. IEEE 21451 enables the interoperability of smart transducers and enables service harmonization. Another important observation to be made is use of ANSI/IS-95 standard along with the IEEE 21451 family of standards. Further, IEEE 21451 NCAP can interface with a variety of smart transducers (wireless, wireline), and extendable to interface with PLC’s (Programmable Logic Controllers), OPC-UA element, Modbus etc.

7. IoT Edge Cloud Configuration


P4 language is used to handle workload in Network applications. Kaloom provides contaninter for network applications.

“P4 was first described in a paper entitled “Programming Protocol-Independent Packet Processors.”  P4 allows a programmer to fully arbitrarily define how packets traversing programmable dataplane blocks will be processed. The commonly used term in P4 is a target, which represents a variety of devices—switch, router, Network Interface Card (NIC) inserted into the server, a software switch—which in general can be programmed using P4. ++The great advantage of P4 is that it allows for processing not only standard well-known protocol headers (e.g. Ethernet, IP, TCP, etc.) like traditional switches or routers normally do, but also fully custom ones”

Ref:   https://codilime.com/p4-network-programming-language-what-is-it-all-about/




P4 language is used to program Dataplane work which will be handled in CPU or CPU and Tofino or CPU and Stratix 10 FPGA.

8. DLtrain (Edge Native Platform)

Following diagram provides information on the tool set used in each processor. DLtrain is Edge-Native platform that has provision to handle both (compute and network) workloads.


CUDA (SDK 10.2) language is used to program CUDA core in RTX 2070 GPU from Nvidia.  Programmers divide work into threads, threads into thread blocks, and thread blocks into grids. The work distributor allocates thread blocks to Streaming Multiprocessors (SMs).

“Using the CUDA Toolkit you can accelerate your C or C++ applications by updating the computationally intensive portions of your code to run on GPUs. To accelerate your applications, you can call functions from drop-in libraries as well as develop custom applications using languages including C, C++.”

Ref:  https://developer.nvidia.com/how-to-cuda-c-cpp

gcc and g++ tool set is used to program OpenPower processors. Host OS is Ubuntu 18.04 and Docker image also created CPU alone DLtrain.

DLtrain includes the following I/O configurations.

Inputs:  DL Model, Network Model  and Data-set

Output:  “jjnet” Trained model for Network, “jjnet” Trained model for DL

CPUs: to train NN model CPU is used

GPUs:  this is used in training NN Model

ASIC:  Tofino will be used to handle Network Workload in real time.

9. Edge-Native to Cloud-Native

Sense:  IEEE 21451 std based IoT nodes are used to measure physical processes in real time.

Control:IoT nodes are used to control physical processes in real time.

Communicate 1:IoT nodes are connected with Edge Cloud by using 5G network infrastructure.

EMBB (Enhanced Mobile Broadband) – It has a high data throughput of the order of more than 10 Gbps, high system capacity of the order of more than 1000 times that of LTE and a much better spectral efficiency than LTE (3 – 4 times that of LTE). Its use cases are high-speed mobile broadband, virtual reality, augmented reality, gaming, etc.

    1. URLLS (Ultra-Reliable Low Latency Services) – It focuses on low latency, high reliability and high availability aspects. The expectation is of the order of less than 1 millisecond of latency and availability of the order of 99.9999 percent. This is basically for mission-critical use cases and applications.
    2.  mMTC (Massive Machine-type Communication) – It aims to provide connectivity to a huge number of devices whose traffic profile is typically a small amount of data (spread) sporadically. So, latency and throughput are not a big concern. The main concern is the optimal power utilization of those devices because they are battery powered and the expectation of battery life is around 10 years or so.

      Ref: https://iot.electronicsforu.com/content/tech-trends/5g-mmtc-challenges-and-solutions/

Edge Cloud:   Computing, communicating and storing are three major workloads in Edge Native applications in Edge Cloud.


Communicate 2: Edge Native applications in Edge cloud are using a wide area transport network to communicate with Cloud Native applications in Core / Central Cloud. Satellite (LEO) based communication link appears to be emerging as a primary network to carry data from Edge to Core /Central cloud.  FTTH (Optical Fiber) might be a good option to provide Robust Link between Edge-Native applications and Core Cloud Native applications. Maybe FTTH can take the form of FTTE (Fiber to the Edge). Existing 4G networks might be an immediate option to provide links between Edge-Native applications and Core Cloud Native applications. In Long run 5G might play some role in this segment as well.

Compute and Store: IBM Watson AI (catalog listed micro service) service is used to carry out intelligence gathering work from collected data of IoT nodes via Edge-Native applications. Cloud Object Storage is used to store data from Edge-Native applications. For example, Visual recognition micro service deployed in IBM cloud and the same can be used by using Android phones.  Case study is presented in https://www.jkuse.com/visual-recognition/ibm-watson-vr

Service Access: Cloud Native application provides micro services that can be accessed by using Web application or Smartphone application or by both.

“Thanks to Mr. P V S Maruthi Rao (pvsmaruthi@ieee.org) for providing detailed information about smart sensors which is presented in section 6.”



Dr. Jayakumar Singaram is a founding member of Rinanu Semiconductors, Epigon Media Technologies, PiiTech Systems and GPTL. Dr. Jayakumar is also an alumnus of IIT Bombay and has been on the forefront of the emerging trends in embedded systems and IOT, having worked with organizations like HAL (Helicopter Design Bureau), Cranes InfoTech, Mistral Solutions and Essel Utilities and some significant others over a career spanning across two decades. He has worked on key projects such as design and development of the Karaoke Machine (a project in collaboration with Analog Devices and MIT Media Lab) for TAITO Corp. He also worked on Satellite Radio Receiver for WorldSpace broadcast Satellites (and DAB Radio Receivers), using low-cost Digital Signal Processors.


Leave a Reply

Your email address will not be published. Required fields are marked *