idnits 2.17.1 draft-jang-iot-d2dlc-00.txt: -(126): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(129): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 5 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 2020) is 1287 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force Hyeonjoon Jang 2 Internet-Draft KAIST 3 Intended status: Informational 4 Expires: March 15, 2021 5 October 2020 7 The Device-to-Device Multi-hop Capability 8 Based On Heterogenous Link Chaining 9 draft-jang-iot-d2dlc-00 11 Abstract 13 Recently, D2D communication is drawing attention as a technology 14 capable of reducing an excessive load on a network infrastructure and 15 increasing network coverage. When using heterogeneous wireless 16 communication technologies such as WiFi and Bluetooth, which are 17 basically provided to user terminals such as smartphones, the 18 connectivity of D2D communication can be further strengthened. 19 In this paper, we propose a multi-hop communication technique using 20 heterogeneous wireless communication technologies. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as 36 "work in progress." 38 This Internet-Draft will expire on March 15, 2021. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . .. . . . . . 2 58 2. Heterogeneous Link Stitching. . . . . . . . . . . . . . . . . . 3 59 2.1 Discovering the neighboring nodes and end-to-end routes. . . . . 3 60 2.2 End-to-end TCP connection. . . . . . . . . . . . . . . . . . . . 3 61 3. IANA Considerations . . . . . . .. . . . . . . . . . . . . . . 4 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Normative References . . . . . . . . . . . . . . . . . . . . . 5 65 5.2. Informative References . . . . . .. . . . . . . . . . . . . . 5 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 As the amount of mobile traffic generated by user terminals such as 72 smartphones, which are widely used in recent years, is rapidly 73 increasing, a direct communication between terminals (D2D) technology 74 is attracting attention as a technology for preventing excessive load 75 on the network infrastructure. In particular, most user terminals such 76 as smartphones are basically equipped with various wireless 77 communication interfaces such as WiFi and Bluetooth as well as cellular 78 interfaces. In an environment in which various wireless communication 79 technologies are mixed, a multi-hop communication technology composed 80 of heterogeneous links can provide more opportunities for connection 81 between user terminals. In fact, it is known that the use of D2D 82 communication services such as OpenGarden can increase the message 83 delivery rate up to 80% in dense crowd environments such as movie 84 theaters and concerts and emergency situations. 85 When implementing multi-hop networking technologies in the application 86 layer, it has the advantage of supporting interworking between wireless 87 communication technologies that are rapidly developing with the advent 88 of the Internet of Things era without modifying the operating system. 89 Therefore, in this document, we propose a heterogeneous multi-hop 90 networking technique in the application layer and discuss 91 considerations. 93 2. Heterogenous Link Stitching 95 A brief description of the multi-hop networking technology in the 96 application layer proposed in this document is shown in Figure 1. The 97 agent application shown in Figure 1 is installed on nodes A, B, and C to 98 perform multi-hop communication consisting of WiFi and Bluetooth links. 99 In order to allow nodes A and C to send and receive HTTP data through a 100 multi-hop path composed of heterogeneous links, the agent application is 101 capable of : 1) discovering of neighboring nodes using heterogeneous 102 communication technology and end-to-end routes between them 2) providing 103 end-to-end TCP connections. 105 2.1 Discovering the neighboring nodes and end-to-end routes 107 As shown in Figure 1, suppose that nodes A and B have connectivity 108 through WiFi using WiFi-Direct technology and Bluetooth technology, and 109 nodes B and C have connectivity through Bluetooth. In a given environment 110 , agents installed in each node broadcast a HELLO message through all 111 communication methods that exist in each terminal. Through the HELLO 112 message, each terminal knows the address of a neighboring nodes connected 113 via WiFi and Bluetooth. After the neighboring terminal is searched, the 114 agent of A sends out a route search message (e.g. RREQ message) through 115 all communication interfaces of A in order to find a route from terminal 116 A to C. The RREQ message arriving at the agent of B through the WiFi 117 connection between A and B is delivered to C through the Bluetooth 118 interface of B, and through this, the multi-hop path consisting of 119 WiFi and Bluetooth from A to C is searched. The agent of each terminal 120 maintains the destination address and nexthop address found in this way. 122 +-------------------+ +------------------+ +--------------------+ 123 |+------+ +------+| | +------+| |+------+ +---------+| 124 ||client|-->| agent|| | +---+agent|| ||client<---+ agent || 125 |+------+ +---|--+| | | +|-----+| |+------+ +-|-------+| 126 +---------------V---+ +-------Λ---V------+ +-----------Λ--------+ 127 +---------------|---+ +-------|+ +|------+ +-------+ +-|--------+ 128 | TCP/IP stack| | |TCP/IP || ||Blue- | |TCP/IP | | | Blue- | 129 +---------------V---+ +-------Λ+ ||tooth | +-------+ | | tooth | 130 +---------------|---+ +-------|+ ||(RFC- | +-------+ | | (RFC- | 131 | IEEE802.11 | | |802.11 || ||OMM) | |802.11 | | | OMM) | 132 +---------------V---+ +-------Λ+ +V------+ +-------+ +-Λ--------+ 133 | | | | 134 +----->---------+ +------------------------+ 135 +------------------------+ +--------------------------+ 136 | B's IPaddr | C's IPaddr| | C's BTaddr | C's IPaddr | 137 +------------------------+ +--------------------------+ 139 Figure 1: Heterogeneous Multihop Link Stitching in Application Layer 141 2.2 End-to-end TCP Connection 143 In order for the web browser application (client) of node A to 144 communicate with the HTTP server of node C, the agent of each node was 145 implemented as a local HTTP proxy. All HTTP packets are sent to the 146 operating system's TCP layer. As shown in the red line in Figure 1, the 147 HTTP payload goes through the agent, and the nexthop is determined 148 according to the destination information maintained by the agent, and 149 it goes down to the corresponding transmission layer. For example, in 150 Figure 1, a packet whose destination is C's IP address is encapsulated 151 as an TCP/IP packet whose destination is B's IP address because the 152 nexthop is B's WiFi interface. When it is delivered to B, and the 153 agent of B forwards the original packet destined for C's IP address to 154 the corresponding nexthop, C's Bluetooth interface(Which has C's 155 BTaddr as its Bluetooth address). 157 A:Client A:agent B:agent C:agent C:server 158 | | | | | 159 |<----------------->| | | | 160 | TCP connected | | | | 161 | | | | | 162 | HTTP/TCP data | | | | 163 |------------------>| | | | 164 |<------------------| | | | 165 | TCP ack | | | | 166 | |<----------->| | | 167 | | TCP connect | | | 168 | | | | | 169 | |<----------->| SYNC(->) & | | 170 | | SYNC(->) & | RFCOMM ack(<-)| | 171 | | TCP ack(<-) |<------------->| TCP connected | 172 | | | |<-------------->| 173 | | |<------------->| | 174 | | | SYNC ack(<-) &| | 175 | | | TCP ack(->) | | 176 | |<----------->| | | 177 | |SYNC ack(<-)&| | | 178 | | TCP ack(->) | | | 179 | | | | | 181 Figure 2. End-to-end TCP connection 183 Figure 2 shows the connection and data transmission between each node 184 for HTTP communication between nodes A-C in the situation of Figure 1. 185 The point to be considered in this situation is that node A's web 186 browser (client) establishes a TCP connection with node A's agent 187 (HTTP proxy) as shown in the figure, so the reliability of the 188 connection to node C cannot be guaranteed. Therefore, each link must 189 use reliable transmission protocols such as TCP and RFCOMM. 191 3. IANA Considerations 193 There are no IANA considerations related to this document. 195 4. Security Considerations 197 There are no security considerations related to this document. 199 5. References 201 5.1. Normative References 203 5.2. Informative References 205 6. Acknowledgements 207 This work was supported by Institute for Information & communications 208 Technology Promotion(IITP) grant funded by the Korea government(MSIT) 209 (No.2015-0-00557, Resilient/Fault-Tolerant Autonomic Networking Based 210 on Physicality, Relationship and Service Semantic of IoT Devices) 212 Authors' Addresse 214 Hyeonjoon Jang 215 Electrical Engineering Department, 216 Korea Advanced Institute of Science and Technology(KAIST) 217 Daejeon, South Korea 218 Phone: +82 (0)42 350 5473 219 Email: thefelix@kaist.ac.kr