Sub-GHz Band Communication Bridge Connecting TCP/IP Network

Recently, low power wide area (LPWA) communication devices have attracted attention in the construction of wide area sensor networks. A type of LPWA device called a sub-GHz band communication device allows a 1-hop wide area communication system to have improved power consumption. However, a sub-GHz band communication system is not scalable due to the lack of compatibility with heterogeneous communication devices, such as WiFi and LTE. In this paper, we propose a sub-GHz band communication bridge that builds a cross-over communication system connecting a conventional TCP/IP network and LPWA network. The communication bridge enables scalable TCP/IP network services (e.g., HTTP) by transmitting an ethernet frame over an LPWA network. Through experiments using IM920, a dedicated device for 920 MHz band communication, we evaluated the performance and behavior of communication through TCP applications over a TCP/IP network and LPWA network connected by the proposed communication bridge.


Introduction
The Internet of Things (IoT) has led to diverse communication requirements.For example, personal applications involving IoT have become common, such as the management of physical conditions by uploading data to the cloud using a wearable device.In addition, network infrastructure with IoT allows for smart cities, which automatically collect various consumption states, such as electric power, gas, and water [1].Thus, with the advent of the IoT era, a data aggregation system for various sensor devices is essential.
To enable wireless sensor networks (WSNs) with wide area coverage and low cost devices, low power wide area (LPWA) communication devices have emerged in the past several years and have experienced rapid growth [2].A sub-GHz band communication device, one of the most common LPWA devices, uses a frequency band lower than 1 GHz for communication, and provides wide-range and low-power communication.Because sub-GHz band communication meets IoT requirements, studies have developed WSNs using sub-GHz band communication devices [3].Although communication standards have emerged for sub-GHz band communication, each communication standard requires a communication device with a dedicated data transfer method and lacks compatibility with heterogeneous communication devices, such as WiFi and LTE [8].
The aim of this study is to achieve cross-over communication that connects an LPWA network and heterogeneous network and makes it possible to use the benefits of both networks.In this paper, we propose a sub-GHz band communication bridge with a TCP/IP network.Specifically, the proposed communication bridge provides software-defined architecture that enables seamless communication over sub-GHz band communication and TCP/IP communication.By using the communication bridge, a client can use a conventional TCP application over the bridge that connects an LPWA network and TCP/IP network.
The design of the communication bridge is based on a packet processing factory, which has been proposed in previous studies [4], [5] (see Section 2.2) to leverage the programmability of a software-defined network (SDN).We implemented the communication bridge using IM920, a dedicated device for 920 MHz band communication (see Section 2.1), to connect a TCP/IP network (see Sections 3 and 4) and sub-GHz band network.Through experiments using IM920, we evaluated the performance of communication in terms of the packet loss rate and round trip time (RTT).In addition, we evaluated the communication behavior using an HTTP application over a TCP/IP and sub-GHz network connected by the proposed communication bridge (see Section 5).Conclusions of the study are provided in Section 6.

Related Work
In this section, we present a description of IM920 as a sub-GHz band communication device.We then describe the packet processing factory, which is the basis of the design of the communication bridge.

IM920
IM920 is an LPWA communication device developed by Interplan Co. Ltd. that enables many-to-many 920 MHz band communication [6].Specifically, IM920 is a longrange communication device with a small bitstream encoded to American Standard Code for Information Interchange (ASCII) [7].Several dedicated commands perform the communication control of IM920 (e.g., power consumption setting, data transmission) via a microcontroller unit capable of USB connection.The dedicated command area is composed of a command portion (4 bytes) and bitstream portion (variable length up to 64 bytes).For instance, an IM920 sender inputs "TXDA ABCD," and the IM920 receiver outputs "ABCD."The previous command is equivalent to "TXDA 0x410x420x430x44" expressed in an ASCII hex bitstream.In addition, IM920 has two types of communication ranges: a fast mode (up to 400 m) and long-range mode (up to 7 km).Because the fast mode has a shorter RTT than the long-range mode, the throughput of the former is higher than that of the latter.In this study, we use the fast mode for the evaluation of the proposed communication bridge.
Several studies have used IM920 to construct a WSN [9]- [12].In a previous study [11], we confirmed the effectiveness of using the proposed communication bridge to send sensor data and text messages collected from a WSN to a UDP/IP server.In this paper, we examine the utility for more general TCP applications.In addition, a proxy server device has been developed to connect heterogeneous networks [13], where sensor data from a WSN are accumulated to be transmitted over a conventional 3G network.Thus, the development of LPWA devices that are compatible with heterogeneous networks is an important topic.

Packet processing factory
The design of the proposed communication bridge is based on the packet processing factory proposed in previous studies [4], [5].The packet processing factory handles communication traffic using communication sockets in the C programming language.In addition, it operates on a communication host to capture, modify, and release traffic from the sockets on equipped communication devices.The packet processing factory has two simple architectures: a communication end and a network switch.Figure 1 presents the two architectures of the software bridge.Sub-GHz Band Communication Bridge Connecting TCP/IP Network 3 factory.In Figure 1 (b), the relay traffic is processed between the sockets on the pNICs and is a process of the communication end architecture.In this section, we introduce the concept of a network system using the proposed communication bridge.The network system consists of a TCP/IP network and LPWA network connected by the communication bridge.The communication bridge splits traffic from the TCP/IP network into single/multiple traffic for the LPWA network.

Overview
In addition, the traffic from the LPWA network is combined with an ethernet frame by the communication bridge.In this way, the TCP/IP communication ends can use conventional network applications via an LPWA network without any changes to the required equipment.Figure 2 presents an overview of the network system with the sub-GHz band communication bridge connecting the TCP/IP network.The communication bridge devices displayed in Figure 2 equip two types of network interface cards: TCP/IP network interface cards (NICs; e.g., wired ethernet card, WiFi base unit) and sub-GHz band communication devices.TCP/IP NICs handle the ethernet frame in TCP/IP, while sub-GHz band communication devices handle the bitstream in the LPWA network.This network system provides a physical layer in which both TCP/IP NICs and sub-GHz band communication devices operate in a compatible way to deliver data from the upper TCP/IP application layers on the communication ends.For example, when a PC downloads HTML code/page(s) on a server through the HTTP protocol, HTTP traffic composed of single/multiple ethernet frames is delivered between PCs.The relay bridge devices split an ethernet frame into single/multiple LPWA bitstreams for LPWA outbound traffic and combine single/multiple LPWA bitstreams into an ethernet frame for LPWA inbound traffic.

Packet processing in a bridge device
Because a bridge device must split/combine traffic from TCP/IP NICs or sub-GHz band communication devices, we apply the concept of the packet processing factory to the bridge devices.The packet processing factory represents the traffic split/combine process through communication between the sockets on TCP/IP NICs and sub-GHz band communication devices.Figure 3 displays the traffic flow in a bridge device.The bridge device connects the TCP/IP NIC and sub-GHz sender device and receiver device.The sub-GHz sender device communicates with another bridge device's receiver device for outbound communication from TCP/IP NIC.Similarly, the receiver sub-GHz device handles inbound traffic to the TCP/IP NIC.
Packet processing takes place between the TCP/IP NIC and sender/receiver sub-GHz device.For outbound traffic from the TCP/IP NIC, the bridge device first splits an ethernet frame into multiple bitstreams for sub-GHz communication.Second, each bitstream is assigned control bits of fixed length for data combination.The control bits represent the sequence number in the bitstream composing the ethernet frame over sub-GHz band communication.The bridge device finally transmits each bitstream in order according to the index in the control bits through the sub-GHz sender device.For inbound traffic from the sub-GHz receiver device, the bridge device receives multiple bitstreams with control bits.If the index of the bitstream is final index the bridge device removes the control bits from each bitstream and combines multiple bitstreams into an ethernet frame according to the sequence number in the control bits of each bitstream.The bridge device finally transmits the ethernet through the TCP/IP NIC.

Implementation
We implemented a network system with the proposed communication bridge described in Section 3 by developing dedicated C software on Linux using real devices.Figure 4 illustrates the implementation of the network system with the proposed communication bridge using IM920 with two PCs.Each PC equips a sender IM920 and receiver IM920 for sub-GHz band communication, and each IM920 uses the fast mode as the communication type presented in Figure 4.This implementation enables a 920-MHz communication bridge connecting a TCP/IP network between two PCs through each equipped vNIC.To install the combine and split processes in the two PCs, we used communication end architecture with the packet processing factory.
Figure 5 illustrates the internal work on a PC for the implementation of the communication bridge using IM920.First, the transmission of outbound traffic from vNIC (Multi-thread process 2 bound with the communication socket of IM920 Sender in Figure 5) and the reception of inbound traffic to vNIC (Multi-thread process 1 bound with the communication socket of IM920 Receiver in Figure 5) operate independently using multi-threaded programming.Then, to deliver the bitstream encoded by ASCII over IM920 communication, each multi-threaded processes performs base64 encoding/decoding for the split/combine process.Therefore, the size of an encoded ethernet frame bound for the IM920 is 4/3 times the size of the original ethernet frame according to the base64 encoding method [14].In addition, the size of a bitstream, which is the unit of communication traffic between the IM920s, consists of a data payload of 60 bytes and control bits of 4 bytes in the form of a sequence number field.

Evaluation
In this section, we evaluate the communication performance of the implementation described in Section 4.
Then, we evaluate the behavior of the communication through conventional HTTP download using the implementation.It should be noted that the distance between PCs was fixed at a sufficiently small length for a small experiment.

Evaluation of communication performance in terms of packet loss rate and RTT
In this subsection, we evaluate the communication performance in terms of the packet loss rate and RTT upon executing the ping command 1,000 times on a Linux machine.It is assumed that the time interval between each ping command is sufficiently large.Table 2 presents a comparison of the packet loss rate according to the size of the ping packet (which equals the size of the ethernet frame minus 14 bytes) in the range of 64 bytes to 1,500 bytes.It can be seen that the packet loss rate increases with an increase in the size of the ping packet.Because a large ping packet has a large amount of communication traffic between IM920s and increases the   Figure 7 presents a comparison of the average RTT with error bars from the minimum RTT to the maximum RTT according to the size of the ethernet frame.As in the evaluation of the packet loss rate, the RTT increases with an increase in packet size.However, the standard deviation of the RTT is unstable regardless of the packet size.

Evaluation of communication behavior through conventional HTTP download
In this subsection, we provide an evaluation of the communication behavior through conventional HTTP download using the proposed implementation.We prepared a scenario in which a PC downloaded a file with text size in the range of 1 kb to 10 kb from an Apache HTTP server on another PC using the curl command on Linux.Table 3 presents a comparison of the average TCP connection times and HTTP download times according to the size of the download file in the range of 1,000 bytes to 10,000 bytes in 100 download trials.The TCP connection time represents the time length from the start of the connection on TCP to the end of the three-way handshake.The HTTP download time represents the time length from the start of the connection on TCP to the end of the download.Figures 8 and 9 also present a comparison of the average TCP connection time and HTTP download time, respectively, with error bars representing the standard deviation.
Table 3 and Figure 8 reveal that the connection time is generally unstable.Because the traffic in the TCP connection is constant regardless of the download size, we consider that the unstable results are affected by TCP retransmission.However, the results are relatively stable in the range of 4,000 bytes to 8,000 bytes.We consider that the stable results operate without being affected by TCP retransmission.Table 3 and Figure 9 also demonstrate that the download time increases as the download size increases.According to the evaluation of RTT in Section 5.1, we conclude that the download time increases with an increase in traffic between IM920s.In addition, despite the increase in download size, the download time is almost identical for download sizes from 6,000 bytes to 7,000 bytes.We believe that this behavior is also caused by TCP retransmission.
Figure 10 illustrates the behavior of TCP communication through the file download capture by Wireshark.We can see that the TCP three-way handshake is successful (part A in Figure 10).The ideal TCP connection time is thus approximately 0.14 seconds.According to this result, it can be concluded that a very small TCP segment behaves practically because its RTT is acceptable for conventional TCP communication.However, according to Table 3 and Figure 8, when a communication loss occurs between IM920s, a large delay due to TCP retransmission is observed.
In addition, when multiple TCP segments are transmitted to the client by TCP, many full-sized retransmission (1,514 bytes) segments are transmitted by TCP retransmission control (part B in Figure 10).As illustrated in Figure 7, this result reveals that full-sized TCP segments have a very large RTT, which causes redundant retransmission with conventional TCP.The redundant retransmission causes a fatal delay for conventional TCP in a range of 6,000 bytes to 10,000 bytes in Figure 9, and further increases the possibility of bit error between IM920s.

Conclusion
In this paper, we propose a communication bridge connecting a TCP/IP network and LPWA network.A network system with the proposed communication bridge allows the TCP/IP communication ends to leverage the merits of the LPWA network without any changes to the equipment.Evaluation of an implementation using IM920 demonstrated that very small TCP segment communication is effective in conventional TCP.In contrast, sequential full-sized (MTU-sized) TCP segment communication is not practical in conventional TCP due to the very large RTT.In this paper, we also observed the need to handle TCP retransmission more effectively.

1 .
(a) Communication end of packet processing factory (b) Network switch of packet processing factory Figure Two simple architectures of the packet processing factory.

Figure 1 (
Figure1(a) displays the communication end of the packet processing factory.In Figure1(a), virtual network interface cards (vNIC) are the SDN interface for the communication end.vNIC receives/sends traffic from/to the host application by assigning the communication end's IP address.The traffic is processed according to the header information (e.g., ethernet header, IP header, TCP header in TCP/IP ethernet frame) between the sockets on the vNIC and physical network interface cards (pNICs).Figure1 (b)illustrates the network switch of the packet processing Figure1(a) displays the communication end of the packet processing factory.In Figure1(a), virtual network interface cards (vNIC) are the SDN interface for the communication end.vNIC receives/sends traffic from/to the host application by assigning the communication end's IP address.The traffic is processed according to the header information (e.g., ethernet header, IP header, TCP header in TCP/IP ethernet frame) between the sockets on the vNIC and physical network interface cards (pNICs).Figure1 (b)illustrates the network switch of the packet processing

Figure 2 .
Figure 2. Overview of network system with sub-GHz band communication bridge.

Figure 3 .
Figure 3. Traffic flow in the communication bridge.

Figure 4 .
Figure 4. Implementation of proposed communication bridge using IM920 with two PCs.

Figure 5 .
Figure 5. Internal processes on a PC for the implementation of the communication bridge using IM920.
07 2019 | Volume 5 | Issue 19 | e1probability of bit error, it can cause incomplete data communication due to bit error and can increase the packet loss rate.

Figure 7 .
Figure 7.Comparison of average round trip time (error bars representing standard deviation) according to the size of the ethernet frame in the range of 64 bytes to 1,514 bytes.

Figure 8 .
Figure 8.Comparison of average TCP connection time (error bars representing standard deviation) according to the size of the download in the range of 1,000 bytes to 10,000 bytes.

Figure 9 .
Figure 9.Comparison of average HTTP download time (error bars representing standard deviation) according to the size of the download in the range of 1,000 bytes to 10,000 bytes.

Figure 10 .
Figure 10.Behavior of TCP communication through file download capture by Wireshark.

Table 1 .
Specifications of PCs for implementation.

Table 2 .
Comparison of packet loss rate according to the size of the ethernet frame in the range of 64 bytes to 1,500 bytes.

Table 3 .
Comparison of average HTTP download time according to the size of the download in the range of 1,000 bytes to 10,000 bytes in 100 download trials.