Multipath TCP over multi-hop heterogeneous wireless IoT networks

Abstract

A node device for forming a multi-hop network is provided. The node device is configured to support one or two communication interfaces, a low-speed communication interface and a high-speed communication interface. The node device joins a heterogeneous multi-hop wireless network and simultaneously delivers data packets via Multipath TCP (MPTCP) routes. A method for constructing MPTCP routes for a node device is provided for constructing multiple routes to a data center. An adaptive congestion control algorithm for a node device is developed for controlling congestion on MPTCP routes based on route characteristics such as route length, route bandwidth, and route loss. A Markov chain model for calculating round-trip time on MPTCP routes for the IEEE 802.15.4 slotted CSMA algorithm is provided, and an M / M / 1 / K model is applied to calculate queuing time. A novel route scheduling method for a node device is provided for delivering data to a data center based on the calculated round-trip time and the calculated adaptive congestion control window. The node device includes a transceiver configured to transmit and receive regular data and other packets in the heterogeneous wireless network, a memory configured to store a computer-executable program including a route of the node device, a round-trip time of the route, and route information for downstream nodes, and a processor configured to execute steps of the computer-executable program, the steps including constructing a route, controlling congestion, calculating the round-trip time, and scheduling packet transmissions.

Description

[Technical Field]

[0001] The present invention relates generally to transporting data in wireless communication networks, and more particularly to reliably transporting data over multiple paths in heterogeneous wireless communication networks. [Background technology]

[0002] With the emergence of 5G and beyond, consumer IoT devices are evolving from the current generation to the next generation. Next-generation IoT devices, called multi-link devices, enable multiple communication interfaces and perform more functions. Therefore, IoT network technologies must adapt to the emerging multi-link devices to improve network performance.

[0003] It is not realistic to completely remove the current generation devices deployed in the evolutionary phase. As a result, the next generation IoT network will be a mixture of current and next generation devices.

[0004] Taking the next-generation smart meter network as an example, current-generation meters support one communication interface and only collect periodic metering data. However, next-generation meters will support multiple communication interfaces, such as IEEE802.15.4, IEEE802.11, and 5G, and will be able to collect periodic metering data as well as sense power supply information. Power supply information is essential for smart grids to perform predictive maintenance and diagnose the causes of abnormal events such as power outages, and therefore must be delivered reliably. To achieve this, the Multipath TCP (MPTCP) protocol can be used to deliver power supply information via multiple routes to ensure reliability.

[0005] The MPTCP protocol is the preferred transport layer protocol for networks with multi-link devices. Standardized in IETF standard RFC8684, the MPTCP protocol is an evolution of the traditional TCP protocol to enable the simultaneous use of multiple interfaces for reliable data delivery. The MPTCP protocol aims to improve throughput, reliability, and reduce latency through the simultaneous use of multiple data delivery paths established using multiple communication interfaces.

[0006] Despite the success of MPTCP in computer networks, its deployment over wireless networks has not been well studied, especially over carrier sense multiple access (CSMA)-based wireless networks where random backoff delays pose significant challenges to route scheduling. Wireless IoT networks, such as smart meter networks, do not have dedicated routers. Data nodes must deliver their own data and relay it to other nodes as needed. As a result, the network environment is different from that in router-based networks.

[0007] Therefore, it is desirable to provide a multipath TCP technique for reliable delivery of high priority data in heterogeneous wireless IoT networks. Summary of the Invention

[0008] Some embodiments of the present invention are based on the recognition that consumer IoT devices are evolving from the current generation to the next generation. The current generation devices support a single communication interface and perform one simple function. The next generation devices will support multiple communication interfaces and be able to perform more functions. Devices that support multiple communication interfaces are called multi-link devices.

[0009] Some embodiments of the present invention are based on the recognition that next generation IoT devices will be able to sense data that is essential to maintaining normal operation of the IoT network. This high priority data must be reliably delivered to a data center and analyzed by a network manager.

[0010] Some embodiments of the present invention are based on the recognition that it is not practical to completely remove deployed current generation devices. As a result, next generation IoT networks will be a mixture of current generation nodes and multi-link nodes that support multiple communication interfaces. IEEE 802.15.4 and 5G communication standards are used as example wireless communication technologies to illustrate the inventive multipath TCP method over heterogeneous wireless IoT networks.

[0011] Therefore, one objective of various embodiments of the present invention is to form a heterogeneous wireless IoT network using a data center and a mixture of IEEE 802.15.4 data nodes and Multilink data nodes, where the Multilink data nodes support both IEEE 802.15.4 and 5G communication interfaces. The data center is considered a Multilink node. The IEEE 802.15.4 node can communicate with the data center, neighboring IEEE 802.15.4 nodes, and Multilink nodes via the low-speed IEEE 802.15.4 interface. The Multilink node can communicate with neighboring IEEE 802.15.4 nodes via the low-speed IEEE 802.15.4 interface and with the data center and 5G base station (BS) via the high-speed 5G interface.

[0012] Some embodiments of the present invention are based on the recognition that a multilink node can communicate directly with a data center or can be connected to a data center via a base station network, the operation of which is governed by a network infrastructure, and therefore the base station network can be conceptually viewed as a single base station node.

[0013] Some embodiments of the present invention are based on the recognition that the first task for setting up MPTCP transport over a communication network is to build MPTCP routes. A multilink node builds a one-hop route to a data center if it can communicate directly with the data center, or a two-hop route to the data center if it connects to the data center through a base station network. An IEEE 802.15.4 node builds a one-hop route to a data center if it can communicate directly with the data center, or builds multiple multi-hop routes if it cannot communicate directly with any data center.

[0014] Some embodiments of the present invention are based on the recognition that nodes in a wireless network form a mesh topology, where a node may have physical connectivity with many neighboring nodes. Therefore, a node may build many routes to a data center. Building many routes is not practical.

[0015] Therefore, various embodiments of the present invention use a path number threshold NP to limit the number of paths that are constructed. t The following is established.

[0016] Some embodiments of the present invention are based on the recognition that once a path is established, an MPTCP scheduler can schedule data transmissions from data nodes to a data center. MPTCP path scheduling depends on RTT, congestion control parameters, and path characteristics such as bandwidth, path loss, and buffer size.

[0017] Therefore, various embodiments of the present invention provide a method for calculating the RTT of a heterogeneous path consisting of IEEE 802.15.4 nodes and / or multi-link nodes. The time spent by a packet (data packet) at an IEEE 802.15.4 node includes (1) random queuing time, (2) random channel access time, (3) fixed RX-TX turnaround time, (4) fixed packet transmission time (given packet size and bandwidth), and (5) fixed MAC layer ACK packet transmission time (because IEEE 802.15.4 MAC sends MAC ACK before forwarding the packet to upper layers). The time spent by a TCP packet at a multi-link node consists only of the random queuing time and fixed packet transmission time. Therefore, the main task is to calculate the random queuing time of both IEEE 802.15.4 nodes and multi-link nodes, as well as the random channel access time of the IEEE 802.15.4 node.

[0018] Some embodiments of the present invention recognize that calculating exact values ​​of random variables is impractical. Therefore, some embodiments of the present invention provide methods for calculating expected queuing times and expected channel access times. A Markov chain model is provided to calculate the expected IEEE 802.15.4 backoff time required to transmit a packet. Another Markov chain model is provided to illustrate the adaptive congestion control mechanism.

[0019] Some embodiments of the present invention are based on the recognition that MPTCP path scheduling must ensure that packets sent over multiple paths reach their destination in order.

[0020] One objective of some embodiments is to provide a path scheduling method that takes into account RTT and packet loss to deliver data packets over multiple MPTCP paths and ensures that packets arrive at a data center in order.

[0021] Some embodiments of the present invention are based on the recognition that congestion control parameters are used by path scheduling to calculate the number of packets that can be scheduled on a path.

[0022] Therefore, some embodiments of the present invention provide an adaptive congestion control method that configures congestion control parameters based on wireless network conditions.

[0023] Additionally, the present invention provides a method for calculating the expected time required to deliver multiple packets from a data node to a data center.

[0024] Embodiments of the present disclosure will be further described with reference to the accompanying drawings, in which the drawings are not necessarily to scale, emphasis instead generally being placed upon illustrating the principles of embodiments of the present disclosure. [Brief explanation of the drawings]

[0025] [Figure 1A] FIG. 1 illustrates a conventional TCP protocol stack. [Figure 1B] FIG. 1 illustrates an MPTCP protocol stack. [Figure 2] FIG. 1 is a schematic diagram illustrating a heterogeneous wireless IoT network consisting of a data center, an IEEE 802.15.4 data node, a multi-link data node supporting both an IEEE 802.15.4 interface and a 5G interface, and a 5G base station, according to some embodiments of the present invention. [Figure 3] FIG. 2 illustrates an example of a Multipath TCP (MPTCP) route established for a data node in a heterogeneous wireless IoT network, according to some embodiments of the present invention. [Figure 4] FIG. 1 illustrates the MPTCP NewReno congestion control algorithm. [Figure 5] FIG. 1 illustrates the IEEE 802.15.4 slotless carrier sense multiple access with collision avoidance (CSMA-CA) algorithm. [Figure 6] FIG. 1 illustrates possible maximum unit backoff periods that may be used in an IEEE 802.15.4 slotless CSMA-CA channel access attempt, according to some embodiments of the present invention. [Figure 7] FIG. 2 is a schematic diagram illustrating a Markov chain model provided for the IEEE 802.15.4 slotless CSMA-CA algorithm, according to some embodiments of the present invention. [Figure 8] FIG. 1 illustrates the calculation of round trip time (RTT) for a multi-hop MPTCP path in a wireless IoT network using TCP synchronization (SYN) and acknowledgement (ACK) according to some embodiments of the present invention. [Figure 9] FIG. 2 illustrates the calculation of inter-hop RTT over a multi-hop MPTCP path in a wireless IoT network according to some embodiments of the present invention. [Figure 10] FIG. 2 illustrates an MPTCP path scheduling mechanism from a data node D to a data center C over NPt paths according to some embodiments of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0026] While the above drawings set forth embodiments of the present disclosure, other embodiments are contemplated as described herein. The present disclosure presents illustrative embodiments by way of representation and not limitation. Those skilled in the art can devise numerous other variations and embodiments that fall within the scope and spirit of the principles of the disclosed embodiments.

[0027] The following description provides exemplary embodiments only and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of exemplary embodiments will provide those skilled in the art with an enabling description for implementing one or more exemplary embodiments. Various changes are contemplated that may be made in the function and arrangement of elements without departing from the spirit and scope of the disclosed subject matter, as set forth in the appended claims.

[0028] In the following description, specific details are set forth to provide a thorough understanding of the embodiments. However, those skilled in the art will recognize that the embodiments may be practiced without these specific details. For example, systems, processes, and other elements of the disclosed subject matter may be shown as components in block diagram form to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known processes, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments. Furthermore, like reference numbers and names in the various drawings refer to like elements.

[0029] Individual embodiments may also be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. While a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process may be terminated when its operations are completed, or may have additional steps not shown or included in the drawings. Moreover, not all operations in any specifically described process occur in all embodiments. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, the end of the function may correspond to the function returning to the calling function or the main function.

[0030] Furthermore, embodiments of the disclosed subject matter may be implemented, at least in part, manually or automatically. The manually or automatically implemented forms may be executed or at least assisted by a machine, hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware, or microcode, program code or code segments for performing the necessary tasks may be stored on a machine-readable medium. A processor may perform the necessary tasks.

[0031] Some embodiments of the present invention are based on the following recognition: MPTCP is a set of features added on top of traditional TCP to enable a transport connection to function simultaneously across multiple paths. FIG. 1A shows a traditional TCP protocol stack, with TCP layer 101 located between the application layer and the IP layer. FIG. 1B shows the MPTCP protocol stack. MPTCP layer 102 is located between the application layer and the TCP layer 103, and an MPTCP flow can be divided into multiple TCP subflows. MPTCP is transparent to both upper and lower layers. To the application layer, an MPTCP connection looks like a traditional TCP connection. To the IP layer, each MPTCP subflow looks like a traditional TCP flow. MPTCP has been successful in computer networks such as Ethernet networks. Research has shown that using multiple interfaces simultaneously can achieve higher throughput and complete transmission in a shorter time.

[0032] The main components of the MPTCP protocol include (1) path management, (2) path scheduling, and (3) congestion control.

[0033] (1) Route management in computer networks (infrastructure networks) is performed by infrastructure networks, i.e., router networks. The Linux kernel implements four route managers: (a) default, (b) full mesh, (c) ndiffPorts, and (d) binder. In default mode, the route management mechanism does not create new subflows. Therefore, even if there are multiple communication interfaces, only one communication interface is used. In full mesh mode, a multihomed host advertises its addresses to peers and creates a complete mesh of new subflows across all possible pairs of IP addresses. In ndiffPorts mode, the route manager initiates subflows between the same IP pair using different source and destination ports. Thus, any number of subflows can be created between pairs of IP addresses. In binder mode, the route manager uses loose source and record routing (LSRR) without modifying end-user devices. The binder provides a list of available gateways to MPTCP subflows and ensures that the subflows access these gateways to discover all available routes in the network. Packets of subflows are distributed through the network using relays and proxies to discover available network paths. Recently, MPTCP path management methods for wireless networks have been proposed, such as MPTCP path management for 5G and WiFi networks and cross-layer MPTCP path management approaches for vehicular networks. However, no prior art has been reported that addresses MPTCP path construction, which is the first step required to set up MPTCP transport. Therefore, an MPTCP path construction method is needed, especially for MPTCP over wireless networks.

[0034] (2) Path scheduling is the most studied component of MPTCP. Round trip time (RTT) is one of the necessary parameters for the MPTCP path scheduler and is defined by IETF standard RFC 793 as the elapsed time between the transmission of a data octet and the receipt of an acknowledgment. Fastest RTT is the default scheduler, in which paths are scheduled based on the RTT, with paths with shorter RTTs being given higher priority. Round robin and redundancy are also two typical schedulers. With round robin, paths are scheduled in a round-robin fashion. With redundancy, data is transmitted redundantly over all available paths. There are scheduling methods that enhance the fastest RTT scheduler by considering other metrics, such as delay-aware scheduling, blocking estimation-based scheduling, and loss-aware scheduling. However, no prior art has addressed the calculation of RTT, which is essential for MPTCP path scheduling and difficult to calculate in wireless networks. Therefore, a new path scheduling method is needed, especially for MPTCP over wireless IoT networks.

[0035] (3) Congestion control is essential for MPTCP to achieve high network efficiency, especially in data-centric networks. Although there are several alternative congestion control methods, the NewReno algorithm specified in the IETF standard RFC6582 is the default congestion controller for MPTCP. However, the NewReno algorithm is designed for computer networks with dedicated routers (infrastructure networks) where network conditions are relatively stable. On the other hand, wireless IoT networks typically do not have dedicated routers and network conditions are dynamic. Therefore, a congestion control method for wireless networks is needed.

[0036] In the following, the IEEE 802.15.4 and 5G communication standards are used as examples of wireless communication technologies to explain the multipath TCP technique of the present invention on a heterogeneous wireless IoT network. In addition, because device-to-device (D2D) communication in 5G is not yet fully supported, communication between multilink nodes is not considered. As a result, a multilink node can communicate with an IEEE 802.15.4 node using a low-speed IEEE 802.15.4 interface and with a data center or 5G base station using a high-speed 5G interface.

[0037] With the emergence of 5G and beyond, consumer IoT devices are evolving from the current generation to the next generation. Next-generation IoT devices, called multi-link devices, enable multiple communication interfaces and perform more functions. Therefore, IoT network technologies must adapt to the emerging multi-link devices to improve network performance.

[0038] It is not realistic to completely remove the current generation devices deployed in the evolutionary phase. As a result, the next generation IoT network will be a mixture of current and next generation devices.

[0039] Taking smart meter networks as an example, current-generation meters support one communication interface and only collect periodic metering data, whereas next-generation meters will support multiple communication interfaces, such as IEEE802.15.4, IEEE802.11, and 5G, and will be able to collect periodic metering data and sense power supply information. Power supply information is essential for smart grids to perform predictive maintenance and diagnose the causes of abnormal events such as power outages, and therefore must be delivered reliably.

[0040] Figure 2 shows a heterogeneous wireless IoT network 200 consisting of a data center 201, an IEEE 802.15.4 data node 202, a multilink data node 203, and a 5G base station 204. The multilink node supports both the IEEE 802.15.4 communication interface and the 5G communication interface. The data center is considered a multilink node. The nodes form a multihop mesh network based on physical connectivity. Although control messages such as acknowledgment (ACK) messages can be sent in either direction, the general flow of data packets is from the data node (802.15.4 node or multilink node) to the data center 201. At least one data node cannot communicate directly with the data center 201. In other words, at least one data node in the heterogeneous wireless communication network does not have support for direct communication with the data center. Therefore, communication must be relayed by an intermediate node. The 802.15.4 node can only communicate using the low-rate 802.15.4 communication interface. However, a Multilink node can communicate using both a low-rate 802.15.4 communication interface and a high-rate 5G communication interface. As a result, a low-rate link 205 can be formed by two 802.15.4 nodes or by an 802.15.4 node and a Multilink node. On the other hand, a high-rate link 206 can be formed only by a Multilink node and a 5G base station or a Multilink node and a data center.

[0041] To deliver high-priority data in IoT networks, such as power supply information in smart meter networks, the Multipath TCP (MPTCP) protocol can be applied to ensure reliability. The MPTCP protocol is a desirable transport layer protocol for networks with multi-link devices. Standardized in the IETF standard RFC8684, the MPTCP protocol is an evolution of the traditional TCP protocol to enable the simultaneous use of multiple interfaces for reliable data delivery. (MPTCP Route Construction on Heterogeneous Wireless IoT Networks)

[0042] In a wired network, routes are constructed through physical wires, allowing for the construction of many more logical routes. In a CSMA-based wireless network, nodes form a mesh topology based on physical communication links. A node may have connectivity with many other nodes in the network, allowing for the construction of many routes to a destination. However, constructing too many routes is not practical. Therefore, to limit the number of routes to be constructed, a route number threshold NP is established. t is determined.

[0043] There is no prior art addressing a method for constructing MPTCP paths. The present invention provides a route construction method for a heterogeneous wireless IoT network consisting of IEEE 802.15.4 nodes and multilink nodes that support both IEEE 802.15.4 and 5G communication interfaces. For multilink nodes, routes within the 5G network are managed by a base station network, which can conceptually be considered a super 5G node. Device-to-device (D2D) communication in 5G is not yet fully supported. Therefore, communication between multilink nodes is not considered. As a result, a multilink node constructs a one-hop route to a data center when directly connected to the data center, and a two-hop route when connected to the data center via a base station network. For IEEE 802.15.4 nodes, a multipath routing protocol can be applied to construct MPTCP paths. The IETF IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) is a multipath routing protocol applied to demonstrate MPTCP path construction. RPL uses destination-oriented directed acyclic graph (DODAG) information object (DIO) messages to build upstream routes by organizing nodes in the network into a DODAG, and uses destination advertisement object (DAO) messages to set up downstream routes. The present invention extends the DIO message to include the traversed path and node type (NT) (0 for IEEE 802.15.4 nodes and 1 for multilink nodes), and extends the DAO message to include the constructed path and path ID. The extended fields in the DIO message are used by downstream nodes to construct MPTCP paths.The extension field in the DAO message is used by the upstream node to store the MPTCP path for the downstream node as {source node ID, path ID, upstream next hop, downstream next hop}.

[0044] Data center C initiates route construction by broadcasting a DIO message over both the 5G interface and the IEEE 802.15.4 interface, with a traversing route {C} and an NT=1. Upon receiving the DIO message over the 5G network, the 5G base station rebroadcasts the received DIO message to the multilink nodes connected to the base station. Upon receiving the DIO message over the 5G network, the multilink node constructs a one-hop route = {Node, C} if the sender of the DIO message is node C, or a two-hop route = {Node, BS, C} if the sender of the DIO message is the base station. The multilink node then updates the DIO message with the constructed route and NT=1, propagates the constructed route by broadcasting the updated DIO message in the IEEE 802.15.4 network using the IEEE 802.15.4 communication interface, assigns a route ID to the route, and sends a DAO message along the route to node C. Upon receiving a DIO message, an IEEE 802.15.4 node selects a parent using RPL protocol criteria such as rank and constructs a path = {node, node included in the received DIO message, path}. The number of paths is NP. tIf the route exceeds the threshold, the node can replace the existing route with a more suitable one, taking into account the route length, the number of multilink nodes on the route, and the buffer size of the next-hop node on the route. A shorter route is considered more suitable than a longer route. For routes of equal length, a route with more multilink nodes is considered more suitable than a route with fewer multilink nodes. For routes of the same length and number of multilink nodes, a route with a next-hop node with a larger buffer is considered more suitable than a route with a next-hop node with a smaller buffer. For each constructed route, the 802.15.4 node propagates the constructed route by broadcasting an updated DIO message with the constructed route and NT=0. The node then assigns a route ID to the route and sends a DAO message for upstream nodes to remember the route. When the node receives the DAO message, it records the DAO source node's route as {source node ID, route ID, upstream next hop, downstream next hop}. The stored route records are used to forward upstream data packets and downstream ACK packets. Additionally, IEEE 802.15.4 nodes can build routes that pass through only IEEE 802.15.4 nodes, or routes that pass through a mixture of IEEE 802.15.4 and multi-link nodes.

[0045] Figure 3 shows an example of multipath construction for the network shown in Figure 2. IEEE 802.15.4 node 1 constructs a one-hop route 1 → C, and IEEE 802.15.4 node 2 constructs three routes: a three-hop route 2 → 3 → 4 → C, a two-hop route 2 → 5 → C, and another three-hop route 2 → 6 → M1 → C. Route 2 → 3 → C is a route using only IEEE 802.15.4 nodes, and route 2 → 6 → M1 → C is a mixed-node route. Also in Figure 3, multilink node M1 constructs a one-hop route M1 → C, and multilink node M2 ​​constructs a two-hop route M2 → BS1 → C. (Adaptive NewReno Algorithm for Wireless IoT Networks)

[0046] The MPTCP NewReno algorithm uses a congestion window (cwnd), a slow start threshold (sst), and a receiver window (rwnd) to control congestion. cwnd limits the number of packets that can be sent in a scheduling round, and rwnd indicates the amount of data that a receiver is willing to accept. The general rule for configuring cwnd is that the number of in-flight packets plus cwnd is less than or equal to rwnd. Figure 4 shows the NewReno algorithm, which states that cwnd = cwnd min and sst start The algorithm starts in the slow start (SS) state, where cwnd is set to the advertised maximum rwnd or to a value based on the network path. If there is no packet loss in a scheduling round, cwnd is doubled in the next scheduling round. When cwnd reaches sst, the algorithm transitions to the congestion avoidance (CA) state, where cwnd is increased to cwnd max In each scheduling round, cwnd is incremented by 1 until it reaches sst / 2. In either SS or CA state, if a packet loss occurs in a scheduling round, the algorithm transitions to the fast retransmit (FR) state if the packet loss is triggered by three double ACKs and the lost packets can be recovered within the remaining cwnd, otherwise it transitions to the retransmit timeout (RTO) state. When the algorithm transitions to the FR state, both sst and cwnd are set to cwnd / 2. When the algorithm transitions to the RTO state, sst is set to cwnd / 2 and cwnd is set to cwnd / 2. min The NewReno algorithm was designed for computer networks with dedicated routers where network conditions are relatively stable, and so is not well suited for wireless networks.

[0047] Wireless network conditions are dynamic. Typically, wireless IoT networks do not have dedicated routers. For multi-hop data-centric IoT networks, the bottleneck is the node close to the data center. Therefore, the NewReno algorithm needs to be enhanced accordingly. The Adaptive NewReno (A-NewReno) algorithm is presented for MPTCP applied across multi-hop heterogeneous wireless IoT networks. The A-NewReno algorithm provides the following enhancements: (1)cwnd min and cwnd max Adaptation:cwnd min and cwnd max is not uniform across the network. Data nodes closer to a data center have a smaller cwnd min and larger cwnd max The farther the data node is from the data center, the greater the cwnd min ≦cwnd max As long as cwnd min becomes larger and cwnd max This enhancement takes into account the fact that data nodes far from the data center need time to recover from packet loss caused by multi-hop relays, and therefore require a relatively stable cwnd. On the other hand, data nodes close to the data center can react quickly to packet loss. (2) RTO Timer Adaptation: Setting the RTO timer is difficult. IETF RFC793 provides a method for setting RTO = min{UB, max{LB, (β*SRTT)}}, where UB is the upper bound, LB is the lower bound, β is the delay dispersion coefficient, and the smoothed RTT (SRTT) is given by SRTT = α*SRTT + (1-α)*RTT, where α is the smoothing coefficient. An adaptive RTO timer configuration is provided, in which the RTO timer is set proportional to the path length, so that longer paths have longer RTO timers and shorter paths have shorter RTO timers. This adaptation is based on the fact that longer paths typically take more time to deliver data. On the other hand, shorter paths take less time to deliver data. (3) cwnd Update Frequency Adaptation: Data nodes far from the data center do not need to update cwnd in each scheduling round. These nodes can search for a cwnd value that provides good performance and then maintain cwnd until it reaches a defective performance. (Modeling of IEEE802.15.4 slotless CSMA algorithm)

[0048] The IEEE 802.15.4 random backoff delay in channel access contention can be significant. Therefore, the random backoff delay must be taken into account when calculating the RTT on a path consisting of IEEE 802.15.4 nodes. IEEE 802.15.4 defines two CSMA operation modes: slotted mode and unslotted mode. Typically, IoT networks employ the IEEE 802.15.4 unslotted mode. Therefore, the present invention models the IEEE 802.15.4 unslotted CSMA algorithm as a Markov chain model to calculate the expected number of backoff periods required to transmit a data packet.

[0049] Figure 5 shows the IEEE 802.15.4 slotted CSMA algorithm, which starts with the backoff exponent (BE) set to macMinBe and the number of backoffs (NB) set to 0, and then randomly selects (2 BE The algorithm performs the first backoff by delaying for a (-1) unit backoff period. After completing the backoff, the algorithm performs a clear channel assessment (CCA). If the channel is idle, the channel access attempt succeeds. If the channel is busy, the algorithm increments NB by 1 and sets BE = min{BE + 1,macMaxBe}. If NB is greater than macMaxCsmaBackoffs, the channel access attempt fails. Otherwise, the algorithm proceeds with another random backoff.

[0050]

number

[0051] When modeling IEEE 802.15.4 slotted CSMA as a Markov chain, the backoff counter decrement state is omitted because the state transition probability in the backoff counter decrement process is always 1. We define the following Markov chain states:

[0052] D(i,j,k i ): The node sets the i-th backoff as k i This is done by delaying j backoff periods starting from the th backoff period, which indicates that the previous i backoffs, from the 0th backoff to the (i-1)th backoff, have failed, where 0≦i≦NB max , 0≦j≦W i -1, and i ≤ k i ≦T max is.

[0053] C(i,j): The node determines the backoff time for the i-th node (k i +j+1)-th backoff period, which indicates that the node has delayed j backoff periods in the i-th backoff, where 0≦i≦NB max , 0≦j≦W i It is -1.

[0054] B(-1): The node prepares to acquire the channel for data packet transmission. To transmit the data packet, the IEEE 802.15.4 CSMA algorithm performs the first backoff, i.e., the 0th backoff, regardless of whether the channel is idle or not. Therefore, the channel is considered busy at the (-1)th backoff. B(i): The channel is busy at the i-th backoff, 0≦i≦NB max is. T: The node acquires the channel and starts transmitting data packets. F: The node is backed off when the number of max If this is reached, channel acquisition will fail.

[0055]

number

[0056]

number

[0057]

number

[0058]

number

[0059] To calculate T2-T1 and T4-T3, we need to calculate the time the packet spends at each hop. The time the packet spends at an IEEE 802.15.4 node is: Random queuing time, Random channel access delay, Fixed RX-TX turnaround time, fixed packet transmission time, and Fixed MAC ACK transmission time, Includes: However, the time spent by a packet at an ML node is Random queuing time, and Fixed packet transmission time Contains only.

[0060] Given a packet size and bandwidth, the packet transmission time is fixed. In addition, IEEE 802.15.4 nodes are typically half-duplex devices, and therefore require turnarounds. However, the turnaround time is fixed and is defined as a Turnaround Time in the IEEE 802.15.4 standard. Furthermore, the IEEE 802.15.4 MAC sends a MAC layer ACK before forwarding a TCP packet to the upper layer, but the MAC ACK transmission time is also fixed. Therefore, the task is to calculate the random queuing time and random channel access delay of an IEEE 802.15.4 node. Calculating the exact values ​​of the random variables is not practical; therefore, expected values ​​are calculated.

[0061]

number

[0062]

number

[0063]

number

[0064]

number

[0065]

number

[0066]

number

[0067]

number

[0068] Figure 9 shows the calculation of RTT per hop, where each hop has multiple types of consumption time, i.e., delay time T D and packet transmission time T T There is. T D includes the queuing time, channel access contention time, and TX-TX turnaround time for IEEE 802.15.4 nodes, and the queuing time for multilink nodes, and T T includes packet transmission times and MAC ACK transmission times for IEEE 802.15.4 nodes, and packet transmission times for multi-link nodes. (MPTCP Route Scheduling over Multi-hop Heterogeneous IoT Networks)

[0069]

number

[0070]

number

[0071]

number

[0072]

number

[0073]

number

[0074] The above-described embodiments of the present invention may be implemented in any of numerous ways. For example, embodiments may be implemented using hardware, software, or a combination thereof. If implemented in software, the software code may be executed on any suitable processor or collection of processors, whether located on a single computer or distributed across multiple computers. Such a processor may be implemented as an integrated circuit, with one or more processors being components of the integrated circuit. However, a processor may be implemented using circuitry in any suitable format.

[0075] Also, embodiments of the present invention may be implemented as a method, examples of which are provided. The order of operations performed as part of the method may be arranged in any suitable manner. Thus, embodiments may be configured to perform operations in an order different from that illustrated, which may include performing some operations simultaneously, even though in the illustrated embodiment they are shown as a sequence of operations.

Claims

1. A node device for a heterogeneous wireless communication network, including a single-link data node, a multi-link data node, a data center, and a 5G base station network, wherein the node device: a transceiver configured to transmit and receive management packets and data packets in the heterogeneous wireless communication network; a memory configured to store a computer-executable program for executing a Multipath TCP (MPTCP) path construction algorithm, an MPTCP adaptive NewReno (A-NewReno) congestion control algorithm, and an MPTCP path scheduling algorithm on the data packets; a processor configured to execute the steps of the computer-executable program, the steps comprising: forming an MPTCP route in the heterogeneous wireless communication network, the forming of the MPTCP route comprising: Sending and receiving destination-oriented directed acyclic graph (DODAG) information object (DIO) messages to form an upstream path from the data node to the data center; In response to receiving the DIO message, sending and receiving an extended destination advertisement object (DAO) message to form a downstream path from the data center to the data node; This is done by assigning route identification data (ID) to the constructed upstream route, and the step further comprises: Minimum congestion window (cwnd ｍｉｎ ) and maximum congestion window (cwnd ｍａｘ Calculating a congestion window (cwnd) by determining scheduling transmission of the data packets along multiple routes formed from the data node to the data center to ensure that the data packets arrive at the data center via the multiple routes in order of their transmission times.

2. The extended DIO message further includes a path traversed by the DIO message and a node type of the DIO message sender, where 0 indicates a single-link node and 1 indicates a multi-link node; The node device of claim 1 , wherein the extended DAO message further includes the formed route and the assigned route ID.

3. an upstream path is formed by reversing the path included in the DIO message and attaching the DIO message sender as a path initiation node; A route identifier (ID) is assigned to the formed upstream route; The node device of claim 2 , wherein the data center configures a downstream path using information included in a DAO message.

4. Number of paths threshold (NP ｔ 2. The node device according to claim 1, wherein the parameter .DELTA..times ...

5. a multi-link data node establishes a one-hop MPTCP route to the data center if the node can directly communicate with the data center, or establishes a two-hop MPTCP route to the data center via a base station network if the node cannot directly communicate with the data center; A single-link node has a maximum NP to the data center. ｔ MPTCP routes can be constructed, The node device of claim 4 , wherein the MPTCP path of a single-link node can be one-hop or multi-hop.

6. The node device of claim 1 , wherein the adaptive NewReno congestion control algorithm determines a congestion window (cwnd) for an MPTCP path in a scheduling round.

7. The adaptive NewReno congestion control algorithm is a modification of the conventional NewReno algorithm, which is based on: (1) the minimum congestion window (cwnd ｍｉｎ ) and maximum congestion window (cwnd ｍａｘ 10. The node device of claim 6, wherein the node device enhances in three aspects: (1) congestion window update frequency adaptation; (2) retransmission timeout (RTO) timer adaptation; and (3) congestion window update frequency adaptation.

8. 8. The node device of claim 7, wherein the congestion window (cwnd) is a parameter that limits the number of data packets scheduled along an MPTCP path in a scheduling round so that the number of scheduled data packets in the scheduling round does not exceed the cwnd.

9. Data nodes closer to the data center have a smaller minimum congestion window (cwnd ｍｉｎ ) and a larger maximum congestion window (cwnd ｍａｘ ) Data nodes further from the data center have a larger minimum congestion window (cwnd ｍｉｎ ) and a smaller maximum congestion window (cwnd ｍａｘ ) the RTO timer is proportional to the MPTCP path length, such that shorter MPTCP paths have shorter RTO timers and longer MPTCP paths have longer RTO timers; Data nodes closer to the data center update the congestion window more frequently; The node device of claim 7 , wherein data nodes further from the data center update the congestion window less frequently.

10. 2. The node device of claim 1, wherein the data packet scheduling algorithm applies a round trip time (RTT) and a congestion window (cwnd) to determine the number of packets to be transmitted along the MPTCP path in a scheduling round.

11. 11. The node device of claim 10, wherein the round trip time (RTT) for an MPTCP path is the elapsed time from when the data node transmits a data octet to the data center along the MPTCP path until the data node receives an acknowledgment (ACK) from the data center along the same MPTCP path.

12. 12. The node device of claim 11, wherein the elapsed time is the sum of the time taken for the data octet to travel from the data node to the data center along the MPTCP path and the time taken for the ACK to travel from the data center to the data node along the same MPTCP path.

13. the time spent by the data octet is the sum of the time spent by the data octet at all nodes along the MPTCP path; The node device of claim 12 , wherein the time spent by the ACK is the sum of the time spent by the ACK in all nodes along the same MPTCP path.

14. The time spent by the data octet or the ACK at a single-link node (IEEE 802.15.4 node) includes: (1) random queuing time; (2) random channel access delay time; (3) fixed receive-transmit turnaround time; (4) fixed packet transmission time; and (5) fixed MAC layer ACK transmission time; The node device of claim 13, wherein the time spent by the data octet or the ACK in a multilink node (5G node) includes (1) a random queuing time and (2) a fixed packet transmission time. 【Request Item 15】 【Number 1】

16. The random channel access delay time consumed by a single-link node (IEEE 802.15.4 node) is N ｂｐ *|BP|, where |BP| is the length of the IEEE 802.15.4 backoff period, and N ｂｐ 15. The node device of claim 14, wherein ∑ i = ...

17. the scheduling algorithm schedules packet transmission over multiple MPTCP paths based on the fastest RTT; The MPTCP path with a smaller RTT is scheduled to transmit more data packets in a scheduling round; The node device of claim 1 , wherein an MPTCP path with a larger RT is scheduled to transmit fewer data packets in a scheduling round.

18. The scheduling round of an MPTCP path is the time taken to successfully transmit all scheduled data packets, 20. The node device of claim 17, wherein successful data packet transmission is confirmed by an acknowledgement from the data center.

19. The scheduling algorithm is １ , P ２ , ..., P ＮＰｔ In ascending order of RTT, １ ≦RTT ２ <...<RTT ＮＰｔ Place it in The corresponding congestion windows are cwnd １ , cwnd ２ , ..., cwnd ＮＰｔ It is determined as cwnd ＮＰｔ The packet is sent via the MPTCP path P ＮＰｔ and the MPTCP path P ＮＰｔ Within a scheduling round, the MPTCP path P １ , P ２ , ..., P ＮＰｔ－１ 18. The node device of claim 17, wherein multiple scheduling rounds may be performed for each of the nodes according to their RTTs and the congestion window.

20. MPTCP Path P ＮＰｔ In the scheduling round, the MPTCP path P ｉ (i=1,2,...NP ｔ 20. The node device of claim 19, wherein the number of data packets scheduled for −1) is a sum of data packets scheduled in all of the multiple rounds.

Images