Page 76 - ITU Journal Future and evolving technologies Volume 2 (2021), Issue 5 – Internet of Everything

ITU Journal on Future and Evolving Technologies, Volume 2 (2021), Issue 5

computational and communication delays of the the IoT gateway and between the IoT gateway and the LN
proposed protocol; and 2) Cost which refers to the total gateway running on the cloud. We know the communi‑
monetary cost associated with sending payments using cation delays between the car and the IoT gateway from
the LN gateway. the previous section which were 9 ms and 0.8 seconds for
To compare our approach to a baseline, we considered the WiFi and Bluetooth respectively. The delay of the com‑
case where the LN gateway sends the payments to a des‑ munication between the IoT gateway and the LN gateway
tination by itself. In other words, no IoT device is present, running on the cloud on the other hand will be the delay
and all LN tasks are solely performed by the LN gateway. of a regular TCP communication between two computers.
We measured an average of 123 ms delay for this com‑
7.2 Computational and communication delays munication. The actual LN payment on the other hand
was sent in 2.1 seconds which is an average value calcu‑
We irst assessed the computational and communication lated from 30 separate payments sent at different times
delays of our proposed protocol. The computational delay throughout the day. There is also the 15 ms computa‑
of running the protocol on a Raspberry Pi comes from the tional delay at the car for each protocol message it gener‑
AES encryption of the protocol messages and HMAC cal‑ ates. Eventually, the total payment sending time for WiFi
culations. We used Python’s pycrypto library to encrypt was 2.658 seconds while BLE had 5.822 seconds.
the protocol messages with AES‑256 encryption. The en‑ We mentioned earlier that 802.11n and BLE were used
crypted data size for the messages was 24 bytes. For the for the measurements. The advertised range of 802.11n is
HMAC calculations, we used hmac module in Python. The approximately 250 meters [32] and the advertised range
delays for these operations are shown in Table 1. As can of BLE is around 220 meters [33]. If cars pass through
be seen, they are negligible. the toll gate with a speed of 50 miles per hour, there is
Table 1 – Computational delays on the IoT device around 11 seconds with WiFi and 10 seconds with Blue‑
AES Encryption HMAC Calculation Total tooth available for them to complete the protocol message
15 ms < 1 ms 15 ms exchanges with the LN gateway for a successful toll pay‑
ment. The results for varying vehicle speeds are shown
We then measured the communication delays which are in Table 2. As can be seen, for both WiFi and Bluetooth
used in other experiments to evaluate the timeliness of cases, our protocol meets the deadlines even under a high
the protocol. We de ine the communication delay as the speed of 80 mph. Even in the case of Bluetooth where the
delay of sending a protocol message from the Raspberry data rates are low, the deadline can be met due to the long
Pi to the IoT gateway and receiving an acknowledgment communication ranges of Bluetooth 4.0. If different tech‑
for that message from the IoT gateway or vice versa. This nologies with limited ranges are used, cars’ speed should
delay is also called the round‑trip time of a protocol mes‑ be enforced accordingly.
sage. When WiFi was used for the connection, the mea‑ Table 2 – Available time under different speeds to make a successful toll
sured round‑trip delay of a message was approximately 9 payment with WiFi and Bluetooth
ms. When Bluetooth was used, the same delay was 0.8 sec‑
WiFi Bluetooth
onds. As expected, the message exchanges with Bluetooth Vehicle Speed Available Time Satis ied? Available Time Satis ied?
are much slower compared to WiFi which is related to the 50 mph 11.2 s Yes 9.8 s Yes
9.3 s
60 mph
Yes
8.2 s
Yes
bandwidth difference between the two technologies. 80 mph 7 s Yes 6.2 s Yes
7.3 Toll payment use case evaluation of the 7.4 Coffee shop example
protocol
As another real‑life example, let us consider a case where
In this part, we consider an example case where real‑time customers pay for coffee at a coffee shop with their smart‑
response is critical. We assume a toll application where watches using our protocol. This payment is less time‑
cars pass through a toll gate and pay the toll without stop‑ critical compared to the toll payments, since the cus‑
ping. For this, wireless technologies are used. The cars tomers can wait by the cashier until they get the payment
that enter the communication range of the toll gate’s wire‑ con irmation from the coffee shop’s LN node. We already
less system immediately initiates a payment to the toll measured the total payment sending time for WiFi and
company’s LN node through the toll’s LN gateway which Bluetooth cases which were 2.658 seconds and 5.822 sec‑
is running on the cloud. Cars are noti ied upon a success‑ onds, respectively. Therefore, again in this example, the
ful payment. In order for this process to work, payment use of our protocol through the WiFi and Bluetooth wire‑
sending has to be completed while the car is still in the less technologies is feasible since the customers can wait
communication range of the toll gate’s wireless system. for more than 5.822 seconds for payment con irmations.
As can be seen in Fig. 6, there are 4 protocol message ex‑ As an alternative, customers can also pay for the coffee us‑
changes between the IoT device and the LN gateway in ing an existing device in the coffee shop that is connected
our payment sending protocol. For this toll example, in to the LN and ready to send payments using its existing LN
each protocol message exchange, there are 2 correspond‑ channels. In this case, however, there is no IoT device in‑
ing communication delays which are between the car and volved; therefore, no wireless communication delays.

64 © International Telecommunication Union, 2021