idnits 2.17.1 draft-zeppelzauer-data-over-sound-00.txt: 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 186 has weird spacing: '... start messa...' == Line 187 has weird spacing: '... block block...' -- The document date (March 6, 2019) is 1877 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft M. Zeppelzauer 2 Intended status: Experimental A. Ringot 3 Expires: September 2019 St. Poelten UAS 4 March 6, 2019 6 SoniTalk: An Open Protocol for Data-Over-Sound Communication 7 draft-zeppelzauer-data-over-sound-00.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. This document may not be modified, 13 and derivative works of it may not be created, except to publish it 14 as an RFC and to translate it into languages other than English. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on September 6, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document defines a new protocol for communication via sound (and 52 in particular via near-ultrasound) that is simple enough to be 53 implemented on devices with limited computational resources, such as 54 Internet-of-Things (IoT) devices. The near-ultrasonic frequency band 55 in the range of 18-22kHz represents a novel and so far hardly used 56 channel for the communication of different devices, such as mobile 57 phones, computers, TVs, personal assistants, and potentially a wide 58 range of IoT devices. Moreover, data-over-sound enables to connect 59 low-end hardware devices to the Internet by near field communication 60 with other Internet-connected devices. Data-over-sound requires only 61 a standard loudspeaker and a microphone for communication, and thus 62 has very low hardware requirements compared to other communication 63 standards such as Bluetooth, WLAN and NFC. "SoniTalk" is designed as 64 an open and transparent near-ultrasonic data transmission protocol 65 for data-over-sound. This document provides a specification of the 66 protocol at the lowest layer (physical layer) in the sense of the OSI 67 model. 69 Table of Contents 71 1. Introduction...................................................2 72 2. Details........................................................3 73 3. Security Considerations........................................6 74 4. IANA Considerations............................................7 75 5. Conclusions....................................................7 76 6. References.....................................................7 77 6.1. Normative References......................................7 78 6.2. Informative References....................................7 79 7. Acknowledgments................................................7 80 Authors' Addresses................................................9 82 1. Introduction 84 The typical frequency band for data-over-sound starts at 18kHz. This 85 band can be corrupted by noise from the environment, which requires a 86 number of counter measures to ensure a robust signal transmission. 87 Especially the temporally varying characteristics of the channel 88 makes the transmission of messages over longer time-spans more likely 89 to be corrupted. The proposed protocol tries to mitigate these 90 sources of error by including redundancy in the encoding. Redundancy 91 is generated by encoding each bit in terms of a Manchester code with 92 a transition from high to low (and vice versa) for bit 1 and 0, 93 respectively. This type of redundancy makes the code not only more 94 robust, but also enables a simpler decoding of the message. To 95 minimize the temporal message duration and maximize data rate, 96 information is sent in multiple channels in parallel. 98 2. Details 100 Data in the protocol is represented by individual messages. Each 101 message is represented by an acoustic signal that encodes the 102 information contained in the message. A message has a temporal and a 103 spectral dimension, i.e., a two-dimensional layout in terms of 104 frequency and time (see Figure 1). Along the temporal dimension, a 105 message is composed of several consecutive blocks. Each message 106 starts with a "start block", followed by M "message blocks" and an 107 "end block". Each message block has a duration of D ms. The start- 108 and end blocks have a duration of D/2 ms. Each block spans multiple 109 carrier frequencies Fi, where Fi in {F1, F2, ... ,FC} are C equally- 110 spaced carrier frequencies covering a frequency band of B = FC-F1 Hz. 111 The spacing of the frequencies is S = B/(C-1) Hz. Each bit in the 112 message can be addressed by a block number and carrier frequency. 113 This layout allows for sending information in parallel on multiple 114 frequencies. 116 Information is encoded binary. Each message block encodes one bit at 117 each carrier frequency Fi. For a logical "1" the amplitude of the 118 first D/2 ms at frequency Fi of the block is "high" and the amplitude 119 of the second D/2 ms is zero. For a logical "0" the opposite is the 120 case, i.e., the amplitude of the first D/2 ms at carrier frequency Fi 121 of the block is zero and the amplitude of the second D/2 ms is 122 "high". The magnitude of "high" amplitude is not normative and 123 depends on the actual use case, employed hardware and the targeted 124 transmission range. 126 The binary message content is encoded across the carrier frequencies 127 (from lowest to highest frequency, i.e. F1 to FC) starting with the 128 first message block, i.e. the first bit is encoded at message block 1 129 and carrier frequency F1, the second bit is located at message block 130 2 and carrier frequency F2, etc. 132 Between two message blocks and in the middle of each block (i.e. 133 after the first D/2 ms of a message block) a pause can be inserted of 134 duration P with P >= 0. For a pause, the sending amplitude is set to 135 zero. The overall message duration is thus: D/2 + P + D*M + P*(2*M- 136 1) + P + D/2 = D*(M+1) + P(2*M+1) ms. 138 The first and last blocks of a message represent the start- and end 139 blocks. Start and end blocks are represented by the following 140 encoding: a start block has "high" amplitude at the higher C/2 141 frequencies (C/2 rounded up in case C is an odd number) and zero 142 amplitude at the remaining frequencies. For the end blocks the 143 opposite is the case, i.e. "high" amplitude is present at the lower 144 C/2 (C/2 rounded down) carrier frequencies and zero amplitude for the 145 remaining frequencies. 147 From the above specification it follows that the number of bits that 148 can be represented by a message is: M*C. The theoretical maximal 149 data rate corresponds to 1000 / (D*(M+1) + P*(2*M+1)) * (M*C) bits 150 per second. 152 The schematic two-dimensional spectro-temporal layout (time at the x- 153 axis and frequency on the y-axis) of a message for parameters: 155 M=4 blocks, 157 C=8 frequencies, 159 D=2 (corresponding to the spacing of 2 characters along the 160 temporal axis: "--"), 162 P=4 (corresponding to the spacing of 4 characters along the 163 temporal axis: "----"), 165 encoding the following binary information: 167 "01010011 01101111 01101110 01101001" 169 is provided in the following. Character "+" indicates "high" 170 amplitude and "0" indicates zero amplitude. Pause periods are 171 indicated with the following pattern "...." for better visibility: 173 +--------------------------------------------------------------+ 174 | ^ | 175 | | ------------------------------------------------- | 176 | f | F8 | +....+....0....+....0....0....+....+....0....0 | | 177 | r | F7 | +....+....0....+....0....+....0....0....+....0 | | 178 | e | F6 | +....0....+....+....0....+....0....0....+....0 | | 179 | q | F5 | +....0....+....+....0....+....0....+....0....0 | | 180 | u | F4 | 0....+....0....0....+....0....+....0....+....+ | | 181 | e | F3 | 0....0....+....+....0....+....0....1....0....+ | | 182 | n | F2 | 0....+....0....+....0....+....0....1....0....+ | | 183 | c | F1 | 0....0....+....0....+....0....+....0....+....+ | | 184 | y | ------------------------------------------------- | 185 | | | 186 | | start message message message message end | 187 | | block block 1 block 2 block 3 block 4 block | 188 | | | 189 | -------------------------------------------------------> | 190 | time | 191 +--------------------------------------------------------------+ 193 Figure 1 The spectro-temporal layout of a single message, "msg" 195 Note, the first eight bits of the message are encoded by the first 196 half of message block 1 from low to high frequency. The second half 197 of message block 1 represents the inverted information. The second 198 eight bits are encoded in the first half of message block 2 from low 199 to high frequency, etc. 201 Different profiles (configurations) of the protocol can be defined to 202 adapt it to the specific requirements of the respective use-cases. 203 The definition of a profile requires the following information: 205 D: the duration of a bit (i.e. a message block) in ms 207 P: the pause period in ms 209 F1: the lowest frequency in Hz 211 C: the number of frequencies 213 S: the spacing between successive frequencies Fi and Fi+1 in Hz 215 M: the number of message blocks 217 3. Security Considerations 219 This specification is targeting solely the physical layer of the 220 protocol. Thus SoniTalk itself provides no communications security, 221 and therefore a large number of attacks are possible including replay 222 attacks, sniffing, eavesdropping, denial of service attacks, message 223 destruction and message insertion. A passive attack is sufficient to 224 recover the binary information of messages transmitted with SoniTalk. 225 No endpoint authentication is provided by the protocol as this 226 definition only targets the physical layer. Sender jamming is 227 trivial, and therefore making messages unreadable is trivial. 228 Attacks are however limited to the local environment around the 229 communicating parties (usually within a few meters). If the 230 communication takes place in a room, possible attacks are most likely 231 successful from inside the room and unlikely from outside the room as 232 near-ultrasonic signals hardly pass through walls. 234 Unlikely attacks are message deletion and message modification as 235 this would require to acoustically manipulate the message while it is 236 sent over the air. While it cannot be guaranteed with absolute 237 certainty such attacks would be extremely difficult, e.g. sending 238 interference sound to cancel out a message acoustically. Furthermore 239 acoustically modifying individual bits of a message for message 240 modification would require precise timing and would very likely 241 destroy the integrity of the message since the acoustic overlay would 242 introduce interferences. 244 To ensure data integrity the use of an error detecting (e.g. a CRC 245 code) or an error correcting code is highly recommended when encoding 246 the message. To establish, confidentiality the binary message should 247 further be encrypted, e.g. by a symmetric or asymmetric encryption 248 scheme where the keys should be exchanged over an out-of-band channel 249 (e.g. Bluetooth). Peer entity authentication is also not implemented 250 at the physical layer and needs to be provided at a higher layer. 252 It is the particular duty of the developers of applications using the 253 protocol to comprehensively inform the user about the near-ultrasonic 254 data exchange (both sending and receiving) and moreover to inform the 255 users when personal information is sent over the protocol. 257 Particular care has to be taken in selecting the carrier frequencies 258 for the data transmission so that no actively or passively 259 participating party is disturbed by potential hearable artifacts of 260 the acoustic data transmission. This in particular includes children 261 as well as animals in the environment. 263 4. IANA Considerations 265 This document has no actions for IANA. 267 5. Conclusions 269 This internet draft introduces SoniTalk, which is the first open 270 protocol for acoustic near field communication via the near- 271 ultrasonic band. Near-ultrasound communication represents an 272 alternative and complement to other existing near-field communication 273 protocols, such as Bluetooth, radio-based NFC and WLAN and is 274 particularly well-suited for IoT devices thanks to its low hardware 275 requirements. This document specifies the protocol at the physical 276 layer and thus primarily focuses on the definition of the message 277 structure for information exchange. Extensions on top of this layer 278 are subject to future specification efforts. 280 6. References 282 6.1. Normative References 284 6.2. Informative References 286 [1] Hubert Zimmermann, OSI Reference Model - The ISO Model of 287 Architecture for Open Systems Interconnection, IEEE 288 Transactions on Communications, vol. 28, no. 4, April 1980, pp. 289 425-432 291 7. Acknowledgments 293 The work which led to this protocol specification was funded by 294 netidee Open Innovations of the Internet Foundation Austria. 296 This document was prepared using 2-Word-v2.0.template.dot. 298 Appendix A. Scope and Remarks 300 A.1. Remarks 302 It is recommended to split the M*C bits of a message into E parity 303 bits for error detection and error correction and M*C-E bits for the 304 payload of the message. The size of the parity information is not 305 normative and depends on the actual application (e.g. environmental 306 conditions etc.) 308 The message length is fixed and must not vary. In case the specified 309 message length is longer than the actual information to be sent, the 310 remaining bits must be filled (e.g. by some special symbol) to comply 311 with the protocol specifications. 313 A.2. Out of Scope 315 The spacing of carrier frequencies, the actual height of the 316 frequencies, the pause duration P inside a message as well as the 317 spacing between successive messages is not part of this 318 specification. 320 This protocol specification focuses exclusively on the lowest network 321 layer (i.e. physical layer according to the OSI reference model [1]). 322 A protocol for distributing information across several messages, 323 session handling, addressing, error detection and correction as well 324 as synchronous and asynchronous communication is beyond this 325 specification and subject to future norming initiatives. 327 Appendix B. Comments and Feedback 329 Please address all comments, discussions, and questions to 330 matthias.zeppelzauer@fhstp.ac.at 332 Authors' Addresses 334 Matthias Zeppelzauer 335 St. Poelten University of Applied Sciences 336 Matthias Corvinus-Strasse 15, 3100 St. Poelten 337 Austria 339 Email: matthias.zeppelzauer@fhstp.ac.at 341 Alexis Ringot 342 St. Poelten University of Applied Sciences 343 Email: alexis.ringot@fhstp.ac.at