However, we find that there are critical situations where the recognition of the high usability of IoT devices becomes untrue. When there are only a few IoT devices of the same type in a location, naming is not a problem. In a nutshell, QuickTalk on a user device uses IR to locate and trigger an IoT device and to provide the ID of the user device (eg WiFi MAC address).
Networking Architecture
There is a large body of research in the context of designing IoT systems. In this section, instead of providing a broad introduction, we focus on the previous studies that are highly relevant to our work in the following two aspects: 1) network architecture and 2) control interface for IoT devices.
Control Interface
Then, with an overview of QuickTalk's software architecture, we explain the required function blocks of a user device and an IoT device that use QuickTalk. The state of an IoT device can be roughly classified into two categories: 1) uninitialized and 2) registered. The uninitialized state of an IoT device means that the device has just been taken out of its box and is not currently connected to a control center (or a control interface provided by the control center).
Each IoT device is given to a user in its uninitialized state and requires the user to go through a certain setup procedure. Once the installation procedure is completed, an IoT device's status changes to registered and becomes controllable through its control interface. It is important to note that once an IoT device is registered with a control interface, control permission is given to the person or group of people who own the access rights to the control interface.
Thus, users who are not accessible to the control interface of an IoT device are all prevented from controlling the IoT device. Also, when there are too many IoT devices on site, it is difficult for her and other visitors to identify which device in the control interface corresponds to which actual IoT device.
QuickTalk Architecture
User Device
One way to direct her to use these IoT devices is to authorize her to access the control interface where all these IoT devices are pre-registered. However, if the space has many visitors, the authorization of individual visitors is not secure, given that the control interface is accessible from anywhere via the Internet after authorization. Revoking the authorization when he leaves the place is possible, but it is too complicated.
To solve these issues, our goal is to provide a user who is near those IoT devices with an immediate and intuitive method of controlling IoT devices. We aim to design a method to be able to physically locate an IoT device and work with any IoT device that is uninitialized or registered.
IoT Device
Technical Challenges
IR Pinpointing
Association-Free WiFi Communication
The distance and angles are controllable since the IR transmitter is on a swivel and movable carriage and the IR receiver is on a rotating carriage. In this section, we propose our system designs as solutions to the challenges raised in implementing IR pinpointing and association-free communication and validate our proposed design using Raspberry Pi version 2 devices with 4.1.19 Linux kernel installed, which emulates both user devices and IoT devices. The purpose of IR determination is twofold: 1) to specify an IoT device to be controlled and 2) to trigger the WiFi interface, enabling association-free communication.
To achieve both, we design a data frame that is transmitted whenever a user device pinpoints an IoT device. Our design is to broadcast the user device ID in the form of its WiFi MAC address (24 bits) and broadcast the device type filters in a hierarchical fashion (14 bits in total, which are divided into 4, 4 and 6 bits according to the level of categorization) along with parity bits (2 bits). In total, each IR signal emission delivers 40 bits of information to an IoT device, which typically takes less than 95 milliseconds.
The reason why we have hierarchical device type filters is to maximally limit the designated candidates, ultimately locating a device. Using the concept of a hierarchical filter, a user device can make a user convenience trade-off (e.g. a) Indoor: The transmission angle (θ) varies while φ=0. b) Indoor: reception angle (φ) varies while θ=0.
Validation
ON period and 4.5 ms of OFF period) of line code emission at the beginning for the purpose of separating each IR signal. Since we find that the repetition of whole bits followed by the data frame transmission, which is specified in NEC format, does not critically affect the success rate of IR transmissions, we have intentionally omitted this repetition part for simplicity. As shown in Figure 4 (a), it is natural to observe that the longer the distance, the narrower the decodable angle.
However, it is important to note that even at a distance of 5 meters, we can manage to narrow the decodable angle to be less than 10 degrees, which means that IoT devices at a distance of 5 meters will be activated when placed in a circle of 88.2 centimeters at that distance. Given the typical distance between IoT devices, it's fair to say it's sharp. According to a recent study [17], the decodable angle of an IR transmitter can be physically controlled without manufacturing a high-cost transmitter only by adjusting the depth of installation of an IR transmitter in its housing.
Considering that IoT devices can be installed in different positions, thus having their IR receivers pointed in random directions, our observation in Figure 4 (b) is optimistic for users who want to remotely control such IoT devices . Finally, Figure 4(c) shows that IR signal exchange up to 2.5 meters is even possible in a sunny outdoor environment as long as the IR receiver is protected from direct sunlight.
Association-Free WiFi Communication
Validation
The experiment measures the RTT (Round-Trip Time) between the broadcast of a random 24-bit payload every 3 seconds from a user device to a. IoT device and the same payload response to the user device from the IoT device. For this experiment, we first use no application-level packet retransmission scheme to identify the pure performance of the proposed method and keep the signal strength between the user device and the IoT device between -30 and -60 dBm.
In this section, we present the implementation details of the user device and the IoT device that use QuickTalk. Our user device implementation consists of two parts: 1) user interface and 2) IR and WiFi services. When the type information and the command are given, the IR service first sends the device type information and MAC address of the user device as described in Section 4, then the WiFi service captures (i.e. tracks) the MAC address broadcast by the triggered IT device and delivers command to this IoT device.
Because the IR module in the user device for QuickTalk is deliberately designed not to receive information via IR communication, it is challenging to find the channel where the activated IoT device is transmitting packets. We describe the general procedures that a user device goes through to control an IoT device as a pseudocode in Algorithm 1.
IoT Device Implementation
Ii represents the packet arrival rate (packets per second) of the ongoing CoAP communication session, while IQuickTalk represents the packet arrival rate of QuickTalk. We evaluate the performance of QuickTalk in a challenging situation where the candidate IoT devices to be controlled have previously registered with a control hub and communicate with the hub via a WiFi access point, as shown in Figure 7. In such a situation, we test first if QuickTalk does indeed enable immediate control of an IoT device by measuring the end-to-end latency of QuickTalk, and then we further test how much performance loss of the ongoing sessions between the IoT devices and the control hub is experienced when a user device communicates with one of the IoT devices via QuickTalk.
The end-to-end QuickTalk delay from the transmission of the IR signal to the reception of the WiFi acknowledgment packet for the IoT command is mainly composed of two delay components: Tsearch and Tbroadcast, as shown in Figure 8. Here, Tsearch indicates the time duration of scanning the sensing channels in which channel an IoT device, triggered by an IR signal, transmits. We find that the end-to-end latency of QuickTalk is mainly affected by two main components:. The end-to-end QuickTalk delay is also presented in Figure 9 (b) for the case of no ongoing CoAP session.
As mentioned above, we find that the end-to-end delay is not much different from Tsearch+Tbroadcast and is bounded above at 2.5 seconds while its average is only around 0.74 seconds. Note that once the WiFi channel is discovered, the end-to-end latency of QuickTalk approaches Tbroadcast, which is roughly bounded above by 1 second.
Coexistence with Ongoing Sessions
In this work, we proposed QuickTalk, a connectionless communication method for nearby IoT devices that is designed to enable intuitive, immediate, and accurate communications with IoT devices around an IoT user. Our implementation of QuickTalk using Raspberry Pi 2 devices confirms that QuickTalk works reliably in realistic environments and further shows that its end-to-end latency for issuing a command is quite low with a worst-case bound of 2.5 seconds. We believe that QuickTalk that can be enabled on any IoT device just by adding a few cents IR receiver can deliver a whole new user experience for IoT devices, especially for non-tech users.
