Enabling LPWANs for Coexistence and Diverse IoT Applications in Smart Cities Using Lightweight Heterogenous Multihomed Network Model

Abstract

Smart cities have been envisioned to provide smartness in managing internet of things (IoT) application domains, such as transport and mobility, health care, natural resources, electricity and energy, homes and buildings, commerce and retail, society and workplace, industry, agriculture, and the environment. The growth trajectory in usage of these IoT domains has led to a heterogeneous dense network in a smart city environment. The heterogeneous dense network in smart cities has led to challenges, such as difficulties in the management of LPWAN coexistence, interference, spectrum insufficiency, QoS, and scalability issues. The existing LPWAN technologies cannot support the heterogeneous dense network challenges in smart cities. Further, it cannot support diverse IoT, including medium- to high-bandwidth applications, due to the power, complexity, and resource constraints of the LPWAN devices. Hence, this paper addresses high data rate IoT applications and heterogeneous dense networks. This paper proposes a lightweight heterogenous multihomed network (LHM-N) model for diverse smart city applications that will address dense heterogeneity network challenges in a smart city. The work aims to advocate and integrate a manageable license-free LPWAN that will coexist with 5G private and public cellular networks in the LHM-N model. This will help to provide a cost-effective solution model in a heterogeneous dense smart city environment. Further, a secured lightweight energy-efficient packet-size forwarding engine (PSFE) algorithm is presented using the discrete event simulation (DES) methodological approach in MATLAB for complexity evaluation. In addition, a 5G reduced capability (RedCap) IoT device is integrated into the (LHM-N) model to support smart city. Finally, the results show that the LHM-N model outperforms the conventional quadrature amplitude modulation (QAM) protocol scheme in terms of error rate, latency, and data throughput with reduced energy costs for medium- to high-bandwidth industrial IoT applications. This validates the suitability of the LHM-N model for high data rate IoT applications.

1. Introduction

A low-power wide area network (LPWAN) is a communication means for applications that require low data rate, low power, and low cost over a long range. The Internet of Things (IoT) is a typical example of such an application. There are numerous LPWAN technologies. However, the predominant ones are LoRaWAN, Sigfox, LTE-M (long-term evolution for machine-type communication (MTC)) enhanced MTC, and NB-IoT (Narrowband IoT). These technologies have significantly impacted numerous IoT deployment use cases, especially in the smart cities ecosystem. Smart cities have been envisaged to provide smartness in managing domains, such as transport and mobility, health care, natural resources, electricity and energy, homes and buildings, commerce and retail, society and workplace, industry, agriculture, and the environment. The use cases of these domains have led to a heterogeneous dense network in a smart city environment. Supporting massively connected devices requires very low-cost end users devices, such as LPWANs [1,2,3].

Several LPWANs meant to satisfy diverse IoT application domains can be attributed to this dense heterogeneity in a smart city. Heterogeneity is inherent in IoT communications due to the vast range of hardware and software capabilities [4]. LPWANs are considered preferred technologies for diverse IoT connectivity compared to short-range communication technologies, such as Bluetooth, ZigBee, and Wi-Fi, due to their unique characteristics [5]. However, high-bandwidth smart city applications, such as industrial wireless sensors (smart manufacturing/smart factory), smart wearabl, and video surveillance, are not supported by LPWAN. Consequently, the third-generation partnership project (3GPP) has finalized the specification for the 5G reduced capability (RedCap) device, which was recently published in the latest 3GPP release-17 [6]. This will support medium to high-speed connections for bandwidth-demanding smart city applications. Hence, RedCap devices can be positioned as a lower segment than eMBB (enhanced mobile broadband) devices with little variation in complexity and coverage distance compared to LPWAN devices. This means that it has more complexity with lesser coverage than the LPWAN by achieving a balance between network performance (high bandwidth and low latency) and device costs. Nevertheless, the reduced coverage can be compensated by considering smaller data rate specifications. This will help to improve coverage distance for the NR RedCap [7]. Further, the device protocol enhancement can achieve a reduction in complexity. Therefore, 5G RedCap could be considered as LPWAN-MHS (medium-high speed), i.e., an LPWAN with medium to high-speed applications support based on the specification for improved distance and low power.

Moreover, other challenges exist, such as coexistence, interference, spectrum insufficiency, and scalability issues, due to this heterogeneity densification. These problems can affect the quality of service (QoS) requirements of IoT applications, including performance degradation of LPWAN devices. Several methods have been advocated to address these problems. For instance, in addressing the problems of interference and spectrum insufficiency, the authors in [8] suggested that spectrum allocation can be moved from the 2.4 GHz band to a license-free spectrum in the sub-1 GHz free band. However, as the use cases increase in the sub-1 GHz band due to IoT network densification, this band will face comparable interference issues to the 2.4 GHz band. Further, the use of multi-radio access technology (multihoming) integration has been suggested in [9] in dealing with the problems of coexistence and scalability issues. Consequently, to circumvent the identified problems, this paper proposes a lightweight heterogenous network model for enabling LPWANs’ coexistence and diverse IoT applications in a heterogenous dense smart city’s IoT network. Hence, to actualize this, the following objectives are enumerated:

• To integrate a manageable license-free LPWAN that will coexist with 5G private and public cellular networks.
• To develop an LHM-N model for enabling the coexistence of different LPWANs.
• To provide a very cost-effective solution model in a heterogeneous dense smart city environment.
• To develop a secured, lightweight, energy-efficient packet-size forwarding engine (PSFE) algorithm.

To this end, the original contributions of this paper include:

• Proposing a model with a low error rate that improves the data throughput by a magnitude of over five times more than the conventional quadrature amplitude modulation (QAM) protocol scheme with reduced energy cost for medium- to high-bandwidth industrial IoT (IIoT) applications.
• Optimizing the Physical (PHY) layer protocol of 5G reduced capability (RedCap) IoT devices to operate comparatively with LPWAN in terms of signal-to-noise ratio (SNR) symbol energy while maintaining medium to high data throughput.
• Designing and implementing a lightweight heterogenous multihomed network (LHM-N) model for diverse smart city applications.
• Advocating and incorporating a manageable license-free LPWAN coexistence with 5G private and public cellular networks to provide a very cost-effective solution model in a heterogeneous dense smart city environment.
• Proposing a packet-size forwarding engine (PSFE) algorithm for secured lightweight energy-efficient and minimized errors in packet forwarding.
• Integrating a 5G reduced capability (RedCap) IoT device in the multihomed LPWAN solution model, thereby supporting high-bandwidth smart cities applications, such as industrial wireless sensors (smart manufacturing/smart factory), video surveillance, etc.

The rest of this paper is organized as follows: In Section 2, related works are discussed. Section 3 presents the architecture and design methodology of the lightweight heterogenous multihomed network (LHM-N) model. The implementation of the LHM-N model is carried out in Section 4. Results and analysis are presented in Section 5. Finally, Section 6 provides the concluding remarks of the paper.

2. Related Works

Some strategies to address the reported challenges associated with the densification of heterogeneity for the connections of LPWAN technologies with billions of end users in smart cities have been advocated in the literature. These challenges include interference, spectrum insufficiency, unmanaged coexistence, quality of service (QoS), and scalability issues. For instance, the need for spectrum optimization for improved spectrum efficiency, QoS, low latency, and appreciable throughput has been opined by the authors in [10,11,12]. The optimized spectrum enables unlicensed and licensed users to coexist. Works in this area of spectrum optimization are found in [13,14,15,16]. Further, the authors of [17] suggested the use of machine learning to accurately identify the available spectrum channels of the LPWAN technologies that are present within an area based on the channel state and network information (CSNI), such as channel frequency, packet loss rates, typical sizes of error burst, and so on. In addition, dynamic frequency allocations, including the use of frequency hopping to mitigate interference problems, are presented in [18,19].

Going forward, the inter-symbol, co-channel, and cross-layer interference in LPWAN can be mitigated by multiple input-multiple outputs (MIMO) and a smart antenna [20]. This method is unsuitable for LPWAN due to its low complexity and low energy capability. The issue of co-channel interference has been addressed in [21], in which the authors used maximum rational combiner in mitigating co-channel interference of sensor nodes in a smart grid environment. The work in [22] proposed a joint reception mechanism as a solution to the degradation encountered due to interference from other overlapping technologies. Furthermore, another method of overcoming the challenges is the coexistence of technologies with multiple IoT radio access technologies (multi-RAT) on a single device. This will offload some of the connectivity to other LPWAN technology devices, thereby reducing the interference and congestion that would have been encountered by a single LPWAN device. However, the coexistence should be managed using a coordinated coexistence mechanism [8]. The authors in [23] proposed the support of multi-RAT on a single LPWAN device. They considered two RATs, namely, LoRaWAN and NB-IoT, in a smart city environment. Other works that considered multi-RAT on a single device are found in [21,24,25,26,27,28]. Further, enabling different IoT application services via a single infrastructure using a network slicing mechanism has been considered in [29,30,31]. Optimization of the LPWAN device physical (PHY) and media access (MAC) layer protocol settings, including the radio resource allocation management and deployment model, have been considered in [32,33,34,35,36,37,38] to improve the QoS in the IoT LPWAN-IoT network. In addressing the issue of scalability, the authors of [39] suggested the optimization of LPWAN technologies to support the Internet Protocol version 6 (IPv6) addressing scheme since IPv6 is not yet fully supported in LPWAN. This will enable multiple trillion LPWAN devices in a heterogenous dense environment. This is because the existing IPv4 addressing scheme does not support such an enormous capacity of devices to be connected.

Regarding the various mechanisms used to address the problems of dense smart cities networks in LPWAN coexistence scenarios, an end-to-end solution model is rarely investigated, i.e., optimization at the base station/gateway side and the end user device side. Most of the authors mainly focused on modifications at the base station or the end-user device. However, this paper considers a model that consists of optimization at the base station/gateway side as well as protocol optimization of the LPWAN end-user device. Further, the existing literature does not consider the use of LPWAN in the unlicensed spectrum jointly with 5G private and public cellular network coexistence. However, to provide a very cost-effective solution model, this paper considers license-free LPWAN coexistence with 5G private and public cellular networks. Lastly, the existing literature does not consider NR reduced capability (RedCap) devices in their LPWAN model. This paper, however, considers a lightweight NR RedCap as well as LoRaWAN and Sigfox in multihoming interfaces on a single device. This will address scalability, interference, congestion, QoS, and high-bandwidth applications in heterogeneous dense smart cities environment. Section 3 gives the architecture and design methodology of the unique lightweight heterogeneous multihomed network (LHM-N) model proposed in this paper.

3. Architecture and Design Methodology of the LHM-N Model

3.1. Lightweight Heterogenous Multihomed Network (LHM-N) Architecture

The LHM-N architecture ensures the connection of sensing end devices (EDs), gateway/radio modules, and end-to-end connectivity to the various servers and entities. This helps the transmission of status, sensed data, and control messages throughout the entire IoT ecosystem. The adopted architecture in LHM-N employs a special mixed topology approach:

(i)

The usual cellular network topology, in which EDs communicate directly with gateway/base station (BS), then from BS to network server/entity, and then to the IoT cloud.

(ii)

The communication of EDs with the gateway, then from the gateway directly to the cloud, and then to the server.

The network employs a 5G private network as the main backhaul over an unlicensed spectrum band. In cases where there is no available 5G private network, a licensed 5G public network is utilized as an alternative backhaul from the commercial cellular network operator. Figure 1 demonstrates the end-to-end connectivity and highlights the network architecture in LHM-N, which comprises the following:

IoT end devices (EDs): This consists of single EDs and multihomed EDs. The single EDs are Sigfox ED, LoRaWAN, and NB2-IoT. The multihomed ED is the LHM-N access ED module, which contains the following interfaces: Sigfox, LoRaWAN, and RedCap interface. The IoT EDs communicate directly with the LHM-N gateway.

Multihomed LHM-N Gateway: This contains multi-radio interfaces that are built on top of a lightweight Raspberry Pi Zero. The multi-radio interfaces include Sigfox, LoRaWAN, RedCap, and NB2-IoT. The block diagram of the multihomed LHM-N gateway is shown in Figure 2. It communicates with EDs through its various interfaces, then transmits collected information via the main backhaul 5G private network over the license-free band to various designated servers. If the 5G private network is not available, the information destined for the 5G core network server is routed via a licensed 5G public network as an alternative backhaul for data delivery.

gNB base station: This is a 5G base station that communicates directly with mobile devices. It also communicates with the LHM-N gateway and serves as an alternative backhaul in transmitting data to the 5G server via the 5G public network.

5G core network: Leverages a service-based architecture comprising many interconnected 5G Network Functions (NFs). The collected information is provisioned in the IoT cloud/software as a service (SaaS). LoRaWAN network server: Processes the data collected from a LHM-N gateway, which is then provisioned to various application servers.

Application servers: These servers house respective processed information collected from the LoRaWAN network server, which can further be provisioned to the IoT cloud/SaaS. Sigfox cloud: This is the cloud hub that directly stores received data from the multihomed gateway via the Sigfox radio interface. The stored data can be integrated into the IoT platform/SaaS via an IoT-integrated plugin from the application backend for better management and usability. The Sigfox data are also accessible by vertical industry IoT solutions. Vertical industry servers: Vertical industry, such as the IoT solutions industry’s servers, collects Sigfox data for monitoring and proper management of EDs, including data visualization and analytics. This will enable efficient data usage.

3.2. Design Methodology of the LHM-N Model

We shall look at the overview of the technologies adopted in this model and the design methodology as follows:

3.2.1. Overview of Technologies Adopted

The technologies employed in this paper range from fundamental to emerging technologies, thus, leading to the novel proposed LHM-N model for IoT applications solution in smart cities scenario. As stated earlier, the model considers a 5G private network over a license-free band. The 5G new radio unlicensed (5G NR U) is part of the aspect that has been finalized in the recent 3GPP release-17 [6]. It will enable industries and private networks to leverage sub-7 GHz as well as the millimeter wave (60 GHz) spectrum band for IoT and broadband solutions. Also, 1.9 GHz is a license-free band in the sub-7 GHz bannd. The 1.9 GHz band has been well advocated for supporting eMTC and industrial IoT (IIoT) technologies’ devices by Multefire Alliance [40,41]. Further, the 5G RedCap IoT device is well suited for medium to high IoT applications, including IIoT [42]. The 5G RedCap IoT device operates on both licensed and unlicensed spectrums. However, the 5G RedCap IoT will need to be well modified to have features nearer to an LPWAN. This modification or optimization may entail the employment of reliable technologies to be implemented at the physical (PHY) layer of the 5G RedCap IoT. The optimization will enable 5G RedCap IoT to support diverse LPWAN-IoT applications in smart city scenarios. One of the reliable technologies that can be implemented on RedCap is the Trellis code modulation (TCM). The TCM is a bandwidth-efficient scheme that is accomplished using convolutional code. It conserves bandwidth by doubling the constellation points of the signal, thus increasing the bit rate, but the symbol rate remains the same [43]. Hence, TCM is bandwidth and energy-efficient error correction coding (ECC) without a complexity cost, unlike the conventional ECC by Shannon’s law, in which there is a trade-off between bandwidth and energy with complexity cost [44].

However, the author of TCM did not take into consideration a Rayleigh fading distribution; rather it was modeled under an additive white gaussian noise (AWGN) channel. For this scheme to work effectively over a Rayleigh fading channel distribution, there is a need to implement it alongside a technology that will produce a satisfactory result. A smart city is a typical terrain that requires Rayleigh fading channel distribution to model communication access technologies and application use cases in a smart city scenario. This is because several buildings in the city cause a non-line of sight (NLOS) and scattering of the wireless signal due to the multipath fading (Rayleigh fading). To overcome this shortfall, this work proposes a receiver diversity-based TCM technique, RX-TCM. Hence, the RX-TCM protocol alongside the LHM-N model is proposed to support medium to high data rate IoT applications. The RX-TCM protocol will be implemented on the LHM-N model for diverse IoT applications as a solution in smart cities scenarios. The LHM-N model consists of a multihomed LHM-N gateway and a multihomed LHM-N end device (ED). Both maintain the same technologies as well as the same radio module interfaces, except that the former has NB2-IoT and higher complexity in addition to supporting numerous LPWAN-IoT devices. Hence, the LHM-N model employs the following technologies.

• 5G NR U: specifically, the 1.9 GHz band advocated by the Multifire Alliance
• Private 5G network
• 5G RedCap IoT
• RX-TCM

These technologies are implemented specifically on the PHY layer of the RedCap radio module interface. Other radio module interfaces in the multihomed device are meant to offload dense IoT data to their respective use cases depending on the application’s requirements. The RedCap interface is meant to support medium to high data rate IoT applications that cannot be supported by other low-data LPWANs (LoRaWAN, Sigfox, eMTC, and NB2-IoT) in smart city scenarios. This coordinated coexistence of the LPWAN technologies in a multihomed strategy will help to mitigate interference and congestion while improving the QoS of the IoT connectivity in heterogeneous dense smart city environments. The next section demonstrates the design methodology of the LHM-N model.

3.2.2. Design Methodology

There are two phases in the design methodology. The packet size forwarding engine and the model.

Phase 1: Packet-Size Forwarding Engine Algorithm: The function of the packet-size forwarding engine (PSFE) algorithm is to forward packets from the multihomed input interface to the appropriate output chipset interfaces. This will enable each chipset interface to transfer the packet to its final destination. The PSFE algorithm will forward data packets to appropriate interfaces based on their respective payload size threshold. Specifically, data packets forwarded or destined to the 5G RedCap IoT device interface will work according to the optimized model transmission mechanism. However, data packets forwarded to other interfaces will be transmitted normally. The data packet format has three major field parameters, which are represented as header, trailer, and payload. The header contains source and destination information, including fragments and the current sectional numbers. The trailer field includes a frame checksum sequence for error control with cyclic redundancy check (CRC) or parity bits. The payload is the actual data information being transmitted. Each field holds a size or length of data bits; the header and trailer have a smaller length, while the payload has a longer length containing the actual data bits information. Figure 3 shows the packet length information. Actually, packet forwarding uses information in the header field to forward the payload data to the appropriate chipset interfaces.

Formulation of Optimization Problem for the PSFE: The forwarding of packets is carried in the forwarding plane of the multihomed gateway/ED. The length of a packet is denoted as L and a chunk or block of packets is denoted as B. A block of packet length is represented as $BL$. A block of originating packet length from the input of the gateway to be forwarded to the output chipset interface is denoted by $B{L}_O$. This packet length is based on the payload size. For a packet to be forwarded, a number of optimization problem conditions must be met:

(i)

The payload must attain a general minimum threshold size denoted as $B{L}_{GMin}$ or a block of general minimum threshold packet length.

(ii)

The specific port address must be known, which is denoted as $Por{t}_{Addr}$.

(iii)

The block of the originating packet length $B{L}_O$ must move to the block of the packet forwarding state, denoted as $B{L}_F$.

Hence, the probability of packet forwarding $P{r}_{PF}$ is the probability of $B{L}_{GMin}$ or $B{L}_F$ and $Por{t}_{Addr}$, which is expressed as $P{r}_{PF}$.

$$P{r}_{PF}=Pr[(\left(B{L}_{GMin}\right)+\left(B{L}_F\right))\ast \left(Por{t}_{Addr}\right)]$$

(1)

Then, the probability of no packet forwarding is

$$P{r}_{NPF}=1-P{r}_{PF}$$

(2)

Algorithm 1 illustrates the PSFE for forwarding a block of data packets to the respective chipset interfaces.

Algorithm 1: Packet-size forwarding engine (PSFE) algorithm.

1. Initializes→ $B{L}_O$; $B{L}_{GMin}$$B{L}_F$; % Block of originating, general minimum threshold, and forwarding packet length, respectively; 2. For $B{L}_{GMin}$ <= $B{L}_F$; 3.        Move packet block to forwarding state; 4. if $B{L}_O$ >= $B{L}_{GMin}$; 5.       Determine interface port address; 6. if $B{L}_O$ < $B{L}_{(min-RC)}$; 7.         re-route or find appropriate interface; 8. else if $Por{t}_{Addr}$ = $Por{t}_{RC}$ && $B{L}_O$ >= $B{L}_{(min-RC)}$ && $B{L}_O$ <= $B{L}_{(max-RC)}$; 9.        Forward $B{L}_O$ to RedCap; 10. else if $Por{t}_{Addr}$ =$Por{t}_{NB}$ && $B{L}_O$ >= $B{L}_{(min-NB)}$ && $B{L}_O$ <= $B{L}_{(max-NB)}$; 11.        Forward $B{L}_O$ to NB2-IoT; 12. else if $Por{t}_{Addr}$ = $Por{t}_{LR}$ && $B{L}_O$ >= $B{L}_{(min-LR)}$ && $B{L}_O$ <= $B{L}_{(max-LR)}$ 13.          Forward $B{L}_O$ to LoRaWAN; 14. else if $Por{t}_{Addr}$ =$Por{t}_{SF}$ && $B{L}_O$ >= $B{L}_{(min-SF)}$ && $B{L}_O$ <= $B{L}_{(max-SF)}$ 15.        Forward $B{L}_O$ to Sigfox; 16. While $B{L}_O$ < $B{L}_{(min-SF)}$; 17.        No packet forwarding; 18. If $B{L}_O+1$; %increment by 1 by additional packet length. 19.        Move to appropriate interface packet threshold. 20. else; 21.        Wait for attainment to any interface packet threshold before forwarding; 22. While $B{L}_O+1$ >= $B{L}_F$; 23.Forward incremented $B{L}_O$ to appropriate interface; 24. else; 25.        Move to initialize $B{L}_{GMin}$ then to $B{L}_F$ state 26. end if; 27.end; end; end; end; end;

Algorithm 1 symbols

• $B{L}_O$: Block of originating packet length
• $B{L}_{GMin}$: Block of general minimum packet threshold
• $B{L}_F$: Block of packet forwarding state
• $B{L}_{(min-RC)}$: Block of minimum packet threshold for RedCap interface
• $Por{t}_{Addr}$: Port address
• $Por{t}_{RC}$: RedCap port address
• $B{L}_{(min-SF)}$: Block of minimum packet threshold for Sigfox interface

Algorithm 1 Explanation: The block of originating packet length, $B{L}_O,$ initializes the attaining of the general minimum packet threshold, $B{L}_{GMin}$, as well as the block of packet forwarding state, $B{L}_F$. Data packets should move to the packet forwarding state so long as the $B{L}_{GMin}$ is less than or equal to $B{L}_F$. PSFE should identify the specific interface port address if $B{L}_O$ is greater than or equal to $B{L}_{GMin}$, and if $B{L}_O$ is less than the block of minimum packet threshold for the RedCap interface $B{L}_{min-RC}$. Otherwise, if the identified port address, $Por{t}_{Addr}$ is the RedCap port address, $Por{t}_{RC}$, and the $B{L}_O$ is less than or equal to $B{L}_{min-RC}$, and the $B{L}_O$ is also less than or equal to the maximum packet threshold for the RedCap interface, $B{L}_{max-RC}$, then $B{L}_O$ should be forwarded to the RedCap interface. The same conditions also hold for NB2-IoT, LoRaWAN, and Sigfox. Therefore, as long as $B{L}_O$ is less than the minimum packet threshold for the Sigfox interface, $B{L}_{min-SF}$, no packet should be forwarded. If $B{L}_O$ is incremented by 1 when there is an additional packet length, the $B{L}_O$ should move to the appropriate interface packet threshold. Otherwise, it should wait for attainment to any interface packet threshold before forwarding. While the incremented $B{L}_O$ is greater than or less than $B{L}_F$, it should be forwarded to the appropriate interface. Else it should move to initialize $B{L}_{GMin}$, then to $B{L}_F$ state. End if conditions are met, otherwise the process begins again, then ends.

Benefits of the PSFE Algorithm: PSFE uses a strategy that allows data packets to fulfill certain conditions before forwarding. Instead of forwarding packets arbitrary and too frequently, packets are accumulated to a substantial level before forwarding to their respective interfaces. This is because frequent packet forwarding causes excessive overheads to the packet header and trailer, thereby leading to errors, a sluggish network, and high energy.

$$PO=\frac{Total packetlength-payload}{Total packetlength}$$

(3)

The total packet length comprises the header length, trailer length, and payload size. The smaller the value of the protocol overhead, the better the efficiency of the device protocol. Further, because the PSFE does not follow conventional packet forwarding, session hijacking and injection attacks that use conventional brute force attack methods are overwhelmed and circumvented. Hence the benefits of PSFE includes:

• Minimized packet-error forwarding
• Energy-efficient packet forwarding
• Lightweight and less overhead packet forwarding
• Reliable network packet forwarding
• Mitigation of session hijacking and injection attacks

Phase 2: The Model: The design of the LHM-N model considers a system model comprising a transmitter (Tx) and a receiver diversity with two receiver (Rx1 and Rx2) systems; that is, a single-input multiple-output (SIMO) system. Figure 4 illustrates the receiver diversity (RX)-TCM system model. The transmitter is responsible for sending a bit stream (message signal), which has been encoded by the TCM encoder and modulated by a 16-QAM (quadrature amplitude modulation) modulator before transmitting. A Rayleigh fading channel is considered during this transmission. The signals received by the two receiving antennas are combined by the maximum ratio combiner (MRC) technique. The corresponding output is then demodulated and decoded by the TCM decoder; the result is then checkmated with the initial bits stream by the bit error rate (BER) estimator for error performance computation.

Assuming the channel state information (CSI) is known at the receivers’ side, the received signal y is represented as

$$y_1=h_{1}x+n_1$$

(4)

$$y_2=h_{2}x+n_2$$

(5)

where $y_1$ is the signal received by antenna 1, $h_1$ is the fading channel at antenna 1, x is the transmitted coded signal, and $n_1$ is the Gaussian noise coefficient at antenna 1. Similarly, $y_2$ is the signal received by antenna 2, $h_2$ is the fading channel at antenna 2, and $n_2$ is the Gaussian noise coefficient at antenna 2. Since the fading channel h is a complex coefficient with real and imaginary parts, the conjugate of h, that is $h*$ together with a square of h modulus, ${\left|h\right|}^2$, is applied to obtain the signal equalization z, given as:

$$z_1=h_1^{*}{y}_1={\left|h_1\right|}^{2}x+h_1^{*}{n}_1$$

(6)

$$z_2=h_2^{*}{y}_2={\left|h_2\right|}^{2}x+h_2^{*}{n}_2$$

(7)

Finally, the combined received signal $y_c$ is given by:

$$y_c=z_1+z_2/|h_1{|}^2+{\left|h_2\right|}^2$$

(8)

Then the transmitted coded symbol is estimated from the combined received signal using the Viterbi decoding algorithm together with a soft detection metric, such as the maximum likelihood detector (MLD). The MLD is computed based on the squared free distance $\left(d_{free}^2\right)$, which is the smallest Euclidian distance of the coded symbol sequence to the all-zero symbol sequence bits [45]. This process of estimation with detection will account for the sent TCM convolutional coded bits and constellation mapping of the 16-QAM. Since the transmitted coded signal is over a Rayleigh fading channel distribution, the error performance of the 16-QAM signal, that is, the symbol error rate of the QAM signal $\left(SE{R}_{\left(QAM\right)}\right)$ in the Rayleigh fading channel, is given by:

$$SE{R}_{QAM}=\underset{0}{\overset{\infty }{\int }}{P}_{SE{R}_{QAM}}\left(\left(\overline{\gamma }\right|\gamma )\right)f_{\gamma }\left(\gamma \right)d\gamma$$

(9)

where $\left(\gamma \right)$ is the signal-to-noise ratio (SNR), $\overline{\gamma }$ is the average SNR, $P_{SE{R}_{QAM}}$ is the symbol error probability of the QAM signal, and $f_{\gamma }\left(\gamma \right)$ is the probability density function (PDF) of $\left(\gamma \right)$. Hence, the SNR, $\left(\gamma \right)$ is given as

$$\gamma =E_s/N_0$$

(10)

$$f_{\gamma }\left(\gamma \right)=\frac{1}{\overline{\gamma }}exp\frac{-\left(\gamma \right)}{\overline{\gamma }}$$

(11)

where $E_S$ is the symbol energy per bit, and $N_0$ is the Gaussian noise coefficient. Then, considering the SNR combined signal ${\gamma }_c$, the PDF of ${\gamma }_c$ is given by

$$f_{{\gamma }_{cs}}\left({\gamma }_{cs}\right)=\frac{{\gamma }_{cs}^{N_{ra}-1}}{{\overline{\gamma }}^{N_{ra}}\left(N_{ra}-1\right)!}exp\left(\frac{-{\gamma }_{cs}}{\overline{\gamma }}\right)$$

(12)

where $N_{ra}$ is the number of receiving antennas. Hence, the $P_{SE{R}_{QAM}}$ for the combined signal in a Rayleigh fading channel is given by

$$\begin{array}{c}{P}_{SE{R}_{QAM}}=\underset{0}{\overset{\infty }{\int }}\frac{a}{n}\left\{\begin{array}{c}\frac{exp\left(-b\frac{{\gamma }_{cs}}{2}\right)}{2}-\frac{aexp\left(-b{\gamma }_{cs}\right)}{2}\hfill \\ +(1-a)\sum _{i=1}^{n-1}exp\left(-b\frac{{\gamma }_{cs}}{s_i}\right)\hfill \\ +\sum _{i=n}^{2n-1}exp\left(-b\frac{{\gamma }_{cs}}{s_i}\right)\hfill \end{array}\right\}\hfill \\ \times \frac{{\gamma }_{cs}^{N_{ra}-1}}{{\overline{\gamma }}^{N_{ra}}\left(N_{ra}-1\right)!}exp\left(\frac{-{\gamma }_{cs}}{\overline{\gamma }}\right)\mathrm{d}{\gamma }_{cs}\hfill \end{array}$$

(13)

Applying trapezoidal simplification gives

$$\begin{array}{c}\hfill P_{SE{R}_{QAM}}=\frac{a}{n}\left\{\begin{array}{c}{\left(\frac{1}{b\overline{\gamma }+2}\right)}^{N_{ra}}-\frac{a}{2}{\left(\frac{1}{\overline{\gamma }+1}\right)}^{N_{ra}}\hfill \\ +(1-a)\sum _{i=1}^{n-1}{\left(\frac{s_i}{b\overline{\gamma }+s_i}\right)}^{N_{ra}}\hfill \\ +\sum _{i=n}^{2n-1}{\left(\frac{s_i}{b\overline{\gamma }+s_i}\right)}^{N_{ra}}\hfill \end{array}\right\}\end{array}$$

(14)

where

$$a=1-\frac{1}{\sqrt{M}},b=\frac{3}{M-1},s_i=\frac{2sin\left(i\pi \right)}{4n},$$

The next section provides the implementation in MATLAB.

4. Implementation of the LHM-N Model

4.1. Implementation Overview

The implementation is conducted in MATLAB. Reliable results are achieved in modeling and simulations that are based on discrete events simulations (DES). For instance, an autoregressive integrated moving average (ARIMA) based on the DES method was used to generate a reliable result with minimal error in smart framing [46]. Further, soft computing optimization based on the DES approach was used for the modeling and simulation analysis for a reliable mechanized operation solution [47]. Hence, the LHM-N model is based on DES. The illustrative phase of the LHM-N model implementation is shown in Figure 4. In the simulation, a random binary bit stream was created. The bit stream is then encoded into a convolutional code by the TCM encoder. The coded bit is then mapped to a 16-QAM modulator, which modulates the coded bit streams. A Rayleigh fading channel is then added to the modulated data in order to simulate a multipath fading channel. Then, the MRC combines the data received by the two receivers, which the simulation prepares for demodulation and decoding by the Viterbi decoder. Finally, the simulation compares the decoded information with the original bits streams in order to compute the bit error rate (BER).

4.2. The TCM Encoder Implementation

The TCM encoder is represented by ($n,k,m$) convolutional code parameters; where n is the output, k is the input, and m is the memory register. The coding rate R is configured as $k/n$. For example, $R=2/3$ means 2 input message streams and 3 coded output bit streams. This model considers (3,2,3) convolutional code, wherein z1, z2, and z3 represent the three memory registers, and $R=2/3$. The constraint length L is determined by $m+k$. Figure 5 depicts a coding rate of a $2/3$ TCM encoder, in which the coded bit stream is mapped by the QAM mapper to the QAM modulator. Hence, the convolutional code equation is given by,

$$y\left(i\right)=u\left(i\right)G$$

(15)

The output $y\left(i\right)$ is dependent on the input $u\left(i\right)$ and on the previous input $u(i-1),u(i-2),u(i-3),\cdots \cdots ,$ where i denotes the passing time, and G is the generator matrix. Now, considering $k=2,n=3$, and $m=3$ as in our case of $R=2/3$ for the 16 QAM signal, here, the input bits u(i) are transformed into the output vectors $y\left(i\right)=\left(y1\right(i),y2(i),y3(i\left)\right)$ by the following encoding equation:

$$y\left(i\right)=\left\{\begin{array}{c}\left(y1\right(i)=u(i)+u(i-3),\hfill \\ y2\left(i\right)=u\left(i\right)+u(i-1)+u(i-2),\hfill \\ y3\left(i\right)=u\left(i\right)+u(i-1)+u(i-2)+u(i-3))\hfill \end{array}\right.$$

(16)

From the above encoder, it can be seen that i needs to remember the three previous input bits $u(i-1),u(i-2)$ and $u(i-3)$. The contents of the three memory bits juxtapose the encoding function. Thus, at any time i, the encoder is in a previous state or new state designated by the state vector $s\left(i\right)$.

$$s\left(i\right)=\left(s1\right(i),s2(i),s3(i)=u(i-1),u(i-2),u(i-3\left)\right)$$

(17)

The convolution code can be encoded with a polynomial generator G. The matrix representation of a polynomial generator G is given by

$$G=\left[\begin{array}{cccc}{g}_0^{\left(1\right)}& g_0^{\left(2\right)}& \cdots & g_0^{\left(n\right)}\\ g_1^{\left(1\right)}& g_1^{\left(2\right)}& \cdots & g_1^{\left(n\right)}\\ g_2^{\left(1\right)}& g_2^{\left(2\right)}& \cdots & g_2^{\left(n\right)}\\ ⋮& ⋮& \ddots & ⋮\\ g_m^{\left(1\right)}& g_m^{\left(2\right)}& \cdots & g_m^{\left(n\right)}\end{array}\right]$$

(18)

where $gi=(g_0^{\left(1\right)}{g}_0^{\left(2\right)}\cdots g_0^{\left(n\right)})$, $0\le i\le m$. The generator $g\left(i\right)$ is the polynomial connection and can be represented in binary or octal format. It can also be represented in the transform domain, D (delay operator) form, which is given by the following convolutional code equation as

$$y\left(D\right)=u\left(D\right)G\left(D\right)$$

(19)

thus, the polynomial generator matrix in a D-transform domain is given as,

$$G\left(D\right)=\left[\begin{array}{cccc}{g}_0^{\left(1\right)}\left(D\right)& g_0^{\left(2\right)}\left(D\right)& \cdots & g_0^{\left(n\right)}\left(D\right)\\ g_1^{\left(1\right)}\left(D\right)& g_1^{\left(2\right)}\left(D\right)& \cdots & g_1^{\left(n\right)}\left(D\right)\\ g_2^{\left(1\right)}\left(D\right)& g_2^{\left(2\right)}\left(D\right)& \cdots & g_2^{\left(n\right)}\left(D\right)\\ ⋮& ⋮& \ddots & ⋮\\ g_m^{\left(1\right)}\left(D\right)& g_m^{\left(2\right)}\left(D\right)& \cdots & g_m^{\left(n\right)}\left(D\right)\end{array}\right]$$

(20)

A particular TCM code (n, k, m) parameter can be encoded by many polynomial generators $g_i$. Not all polynomial generators are good. Hence, $g\left(i\right)$ depends on the number of trellis states and $d_{free}^2$ to give a good asymptotic coding gain for GT. The number of trellis states is depicted by $2^m$. For example, in our case of the $16-QAM$ (3,2,3) TCM encoder parameters, the trellis state is 8. The $d_{free}^2$ is estimated by the smallest Euclidian distance of a coded symbol sequence to the all-zero symbol sequence. The TCM asymptotic coding gain of GT is given by

$$G_T=10log\left[(\left(d_{free}^2\right)/\left(d_{\left(mi{n}_u\right)}^2\right))(E_{\left(s_u\right)}/E_s)\right]$$

(21)

where $d_{free}^2$ is the squared free distance of the TCM encoder and $d_{\left(mi{n}_u\right)}^2$ is the squared minimum Euclidian distance of the uncoded scheme; $E_{\left(s_u\right)}$ and $E_s$ are the symbol energy of the uncoded scheme and TCM encoder, respectively.

Table 1. Optimal polynomial generators for a good TCM encoder.

Trellis State	${\mathit{g}}_{\mathit{o}}$	${\mathit{g}}_1$	${\mathit{g}}_2$	${\mathit{g}}_{\mathit{m}}$	${\mathit{d}}_{\mathit{free}}^2$	Asymptotic Gain (dB) for 16-QAM
4	5	2	-	-	4	4.4
8	11	2	4	-	5	5.3
16	23	4	16	-	6	6.1
32	41	6	10	-	6	6.1
64	101	16	64	-	7	6.8

illustrates optimal polynomials generators/connections $g_{\left(i\right)}$ in octal (base 8) format with the associated parameters for a good TCM encoder.

4.3. Throughput

Adequate asymptotic Gain $G_T$ will improve the data rate throughput $\left(Tdr\right)$ of a communication signal. From Shannon’s law, the throughput of an uncoded scheme is given by

$$T_{\left(d{r}_u\right)}=CB({log}_2)(1+SNR)$$

(22)

Hence, the throughput for coded scheme $T_{\left(d{r}_{GT}\right)}$ gives

$$T_{\left(d{r}_{GT}\right)}=CB\left(G_T\right)\left({log}_2\right)(1+SNR)$$

(23)

where CB is the channel bandwidth of the carrier signal. The next section presents the simulation setup for the model implementation.

4.4. Simulation Experimental Setup

Table 2. Simulation parameters.

Parameters	Value
Simulation runs	100,000
Channel fading	Rayleigh
Modulation size	16-QAM
SNR	0:5:50 (dB)
Channel bandwidth (CB)	20 MHz
Tx	1
Rx	2
Encoder	TCM
Frequency	1.9 GHz
Trellis state	8
Trellis structure	Poly2trellis
Polynomial generator (gi)	g0, g1
Device type	5G RedCap
Combiner type	MRC
Simulation runtime for overhead computation	100 s
Total packet length	1642 Byte
Minimum payload	64 Byte
Maximum payload	1500 Byte

presents the parameters for the simulation of the LHM-N model implementation and PSFE algorithm. The model is experimented with and compared with the conventional QAM protocol. The performance efficiency of the implemented model is evaluated based on the following instances:

(1)

Evaluation with respect to BER and SNR over a Rayleigh fading channel.

(2)

Evaluation with respect to throughput and SNR over a Rayleigh fading channel.

(3)

Evaluation with respect to bit error rate (BER) and latency over a Rayleigh fading channel.

Further, the PSFE algorithm is experimented with and compared with TCP Reno and TCP Cubic algorithms for packet forwarding. TCP Reno uses slow start and fast retransmit, including packet loss, as criteria to detect network congestion during packet transmission. TCP Cubic uses a cubic function of time from the inception of the last packet loss with the inflection point set to the window prior to the congestion occurrence during packet transmission. These algorithms are compared with the PSFE algorithm in terms of packet forwarding to the device interface.

5. Result and Analysis

Figure 6 shows the performance of communication signal transmission with respect to BER and SNR over the Rayleigh fading channel of the LHM-N model compared with the conventional QAM protocol (uncoded scheme). From Figure 6, it can be deduced that the bit error rate (BER) at a given SNR in the LHM-N model is lower than the bit error rate in the conventional QAM protocol. For example, the LHM-N model exhibits a lower BER below 1, approximately 0.5 at an SNR of 5 dB, whereas the conventional QAM protocol exhibits a higher BER above 1, approximately 6 at the same SNR of 5 dB. Further, at an SNR of 50 dB, the BER in the LHM-N model is ${10}^{-4}$, whereas the BER in the conventional QAM protocol is above ${10}^{-4}$. Therefore, it is apparent that it will take lower errors for communication signal transmission in the LHM-N model than in the conventional QAM protocol, which has more errors in transmission, as depicted in Figure 6. Hence, the LHM-N model coding gain GT of 5.3 dB validates the performance improvement without the expense of bandwidth energy. For example, at a given SNR (a function of symbol energy per bit), the communication signal improves with less error compared to the conventional QAM protocol at the same symbol energy per bit.

Figure 7 shows the performance of the communication signal transmission with respect to throughput and SNR over the Rayleigh fading channel of the LHM-N model compared with the conventional QAM protocol. From the result, it confirms that the LHM-N model can effectively maintain a higher throughput or data rate in communication signal transmission. This is depicted in Figure 7, which shows a higher throughput than the existing or conventional QAM protocols (uncoded signal). For instance, for the LHM-N model, at an SNR of 25 dB, a throughput of approximately 800 Mbps is obtained whereas for the existing QAM protocol, approximately 100 Mbps throughput is obtained at the same 25 dB. Similarly, at an SNR of 50 dB, throughputs of approximately 850 and 150 Mbps are obtained for the LHM-N model and existing QAM protocol, respectively. Hence, it is evident that the throughput of the LHM-N model is five times the throughput of the existing QAM protocol. This validates an appreciable and improved throughput in the LHM-N model than in the existing QAM protocol. This throughput improvement makes this model (an optimization of a 5G RedCap IoT device) suitable for medium to high data rate IoT applications without the expense of energy increase (low power). Thus, this model has a comparable LPWAN potential capability. The 5G RedCap IoT device with the existing protocol cannot attain appreciable throughput without the expense of energy increase (high power consumption), which makes it unsuitable for LPWAN-IoT potential capability. Hence, the existing RedCap does not support low power capability comparable with the LPWAN.

Figure 8 shows the performance of the communication signal transmission with respect to BER and latency over the Rayleigh fading channel of the LHM-N model compared with the conventional QAM protocol. From the result, it can be seen that at any instance of the transmission, the LHM-N model exhibits low BER as well as a lower latency compared to the conventional QAM protocol For example, the transmission latency is 30 ms with a BER slightly below 10${}^{-3}$ in the LHM-N model. Whereas at the same BER of 10${}^{-3}$, the transmission latency or delay was 45 ms in the conventional QAM protocol. This validates the lower latency or delay in the LHM-N transmission than in the conventional QAM protocol.

Figure 9 shows comparisons of the protocol overhead for packet forwarding transmission. From the three evaluated algorithms, the PSFE algorithm outperforms TCP Reno and TCP Cubic algorithms with very low protocol overhead throughout the simulation runtime during the packet-forwarding transmission. The PSFE has a maximum attainment of 0.5 protocol overhead. This is the least attainment of protocol overhead compared with TCP Reno and TCP Cubic, whose maximum protocol overheads are 0.9 and 0.8, respectively. Hence, the TCP Reno and TCP Cubic encountered higher protocol overhead due to the frequent packet forwarding in their algorithm’s criteria. This causes excessive overhead for the packet header and trailer, which can lead to packet loss errors, sluggish network, congestion, and high energy consumption on the device. However, the PSFE maintains conditional properties based on a given threshold for packet forwarding. This allows only accumulated packets to be forwarded based on the conditional criteria leading to minimal protocol overhead. The minimal protocol overhead can be attributed to enabling congestion avoidance in packet-forwarding transmission.

6. Conclusions and Future Work

In this paper, the design and implementation of a lightweight heterogenous multihomed network (LHM-N) model for diverse smart city applications is carried out. The LHM-N model addresses dense heterogeneity network challenges, such as the difficulties in the management of LPWANs coexistence, interference, spectrum insufficiency, QoS, and scalability issues, in a smart cities’ scenario. The solution model advocates the enabling of smartness in the diverse IoT application domains, such as transport and mobility, health care, natural resources, electricity and energy, homes and buildings, commerce and retail, society and workplace, industry, agriculture, and the environment. A receiver diversity-based TCM technique, RX-TCM, is implemented on the LHM-N model for the IoT application solution suitable for a smart city ecosystem. In addition, the paper integrates a manageable license-free LPWAN coexistence with 5G private and public cellular networks in the LHM-N model. This provides a very cost-effective solution model in a heterogeneous dense smart city environment. Further, a 5G reduced capability (RedCap) IoT device is integrated into the (LHM-N) model for supporting high-bandwidth smart city application solutions. Furthermore, the optimization of the PHY layer protocol of the 5G reduced capability (RedCap) IoT device to operate comparatively with LPWAN in terms of signal-to-noise ratio (SNR) symbol energy is carried out. The 5G RedCap performs optimally at medium to high data throughput with low latency in the LHM-N model.

Furthermore, the MATLAB simulation results validate the performance of the LHM-N model with a lower error rate and lower transmission delay compared to the conventional QAM protocol. The 5G RedCap protocol optimization performs five times better than the conventional QAM protocol in terms of data throughput without an energy cost expense for medium- to high-bandwidth industrial IoT (IIoT) applications. In addition, the proposed packet-size forwarding engine (PSFE) algorithm outperforms TCP Reno and TCP Cubic algorithms with very low protocol overhead. Finally, the minimal protocol overhead in the PSFE algorithm can be attributed to enabling congestion avoidance in packet-forwarding transmission.

Regarding future work, the authors aim to carry out coverage and energy/complexity evaluations of the developed LHM-N model compared with conventional LPWANs, such as LTE-M (eMTC), in a smart city scenario. This is to establish the nearness of the LHM-N model features to features of the LPWAN in a smart city scenario.