The internet of Things (IoT) comprises embedded sensing and computing devices and aims to improve quality of life.5,13 Mobile IoT can be applied in all walks of life, such as safe driving and smart healthcare.2,16 For example, smartphones can produce road-safety multimedia data for safe and efficient driving, and sensor nodes attached to patients are capable of sensing vital signs for real-time monitoring.
With the IoT's dramatic development, the data it produces is experiencing a shift from simple text data to enormous multimedia data that is usually locally relevant and of a size that individuals cannot handle due to resource limitations.1,10 Therefore, one of the most critical challenges facing IoT-related multimedia data is to improve its delivery efficiency by sharing resources with IoT devices to collaboratively produce and rapidly provide locally relevant multimedia data.10
Internet Protocol (IP) version 6 could be the IoT's future.5,13 However, if IP-based data delivery methods3,11,15,23,25 are directly deployed in the IoT, they might be confronted with the following challenges:2,19
According to Kahn et al.,8 Mobile Cloud (MC) is a novel technology that integrates cloud computing with mobile devices such as smartphones to overcome the resource limitations of an individual mobile device. In MC, cloud members can share resources and collaborate to create multimedia data, and a user can acquire data from any cloud member.7,10,14 The features of MC might help overcome these challenges and create a new method of achieving IoT. Based on this observation, we are motivated to integrate MC with IoT to construct IoT Cloud (ITC) and achieve the following objectives:
Based on the motivation and objectives, we propose a multimedia data delivery based on ITC (MDITC) and aim to reduce multimedia data-delivery latency and improve success rates via the following innovations:
The proposed scheme focuses on producing and sharing locally relevant multimedia data with a relatively short life span, such as road condition information, and aims to provide data rapidly. While IoT devices can upload and download data to and from the Internet cloud, the Internet cloud is costly and time-consuming, especially for locally relevant data with a relatively short life span.10 Moreover, it is usually local or nearby users who are interested in locally relevant data.24
For example, drivers are interested in local and nearby road-safety information to improve driving safety and efficiency. Therefore, in the proposed scheme, IoT cloud members share and maintain data locally so that users can rapidly acquire data from the nearest member instead of the Internet cloud. The typical application of the proposed scheme is that users can quickly acquire multimedia data on road conditions associated with specific locations, such as intersections, to improve pedestrian safety and efficiency.17,24 For instance, a pedestrian can effectively avoid road hazards or accidents by rapidly retrieving multimedia data on road conditions from the nearest IoT cloud member.
The IoT architecture comprises infrastructures and devices. Infrastructures, such as access routers (ARs), switches, and access points (APs), mainly perform routing functions, while devices, such as sensor nodes and smartphones, primarily collect location-related multimedia information. Devices are associated with an AP via wireless interfaces. A subnet is made up of one AR, switches, APs, and associated devices. The infrastructures in a subnet are organized into a tree topology, where the root is the AR, the intermediate nodes are the switches, and the leaf nodes are the APs, as shown in Figure 1. The devices associated with an AP construct an IoT Cloud and can collaborate to produce location-related multimedia data. The acronyms used by the proposed scheme are shown in Table 1.
To efficiently seek and retrieve location-related multimedia data, MDITC proposes a cloud address and a unicast address, as shown in Tables 2 and 3. A cloud address includes the global routing prefix (GRP), link routing prefix (LRP), cloud flag, and content ID. The GRP identifies a subnet, the LRP defines a specific location in the subnet, and the content ID identifies a kind of multimedia data, so a cloud address uniquely defines a specific type of location-related data. Since ITC is constructed to generate a type of location-related multimedia data, it is also identified by a cloud address. In a cloud address, the cloud flag is 1. To rapidly locate a device or an infrastructure, a unicast address is proposed and consists of the GRP, LRP, cloud flag, and device ID. In a unicast address, the cloud flag is 0. The device ID of an AR is 1 and the device ID of a switch or an AP is 0.
The i-bit LRP is divided into hierarchies, and c is an adjustment coefficient that represents one hierarchy and guarantees the uniqueness of LRP. The infrastructures at different depths of a tree are configured with a unique LRP with different hierarchies that are proportional to the depths. The LRP of an AR is 0, and it launches the following LRP configuration process:
As shown in Figure 1, where i is 16 and c is 4, AR1 launches an LRP configuration process by sending Conf-LRP from interface 1. Switch SW1 receiving Conf-LRP is configured with LRP 0x1000 and forwards Conf-LRP from interfaces 1 and 2. Similarly, switch SW2/SW3 receiving Conf-LRP is configured with LRP 0x1100/0x1200 and forwards Conf-LRP from interface 1. Finally, API/AP2 receiving Conf-LRP is configured with LRP 0x1110/0x1210.
Each infrastructure maintains an index table to store the information on ITC members, and each index entry includes the interface and cloud address.
Multimedia data generation. Location-related multimedia data MD1 is identified by cloud address CA1, where the GRP is GRP1, the LRP is equal to the LRP of AP2, and the content ID is CID1. Messages Gen-MD and Share-MD are used to generate location-related multimedia data. AP2 generates MD1 by creating ITC1:
As shown in Figure 2a, AP2 creates ITC1 to generate multimedia data MD1, defined by cloud address CA1. Then, AP2 starts an index entry-generation process so that its upstream infrastructures—including switch SW3, switch SW1, and AR1—establish an index entry for CA1.
After a device becomes an ITC1 member, the payload of a beacon sent by the device includes CA1. If an AP receiving a beacon with CA1 from interface f does not have an index entry for CA1, it launches the following index entry-generation process:
Local multimedia data delivery. To achieve request aggregation, each infrastructure stores a pending table, and each pending entry includes the interface and the cloud address. Multimedia data MD1 is identified by cloud address CA1 and is generated by creating ITC1. User D1 is located in subnet S1 with GRP1 and is associated with AP1. If either Condition 1 or Condition 2 is satisfied, D1 acquires MD1 based on the local multimedia data-retrieval process:
Condition 1. The GRP of CA1 is GRP1 and the LRP is equal to the 1 of AP2 in S1.
Condition 2. The GRP of CA1 is not GRP1, but there is at least one ITC1 member in S1 that can provide MD1.
If the infrastructure has the pending entry, where the cloud address is CA1 and interface is f, it goes to Step 4. The infrastructure creates a pending entry for CA1. If the infrastructure has only one pending entry for CA1, it goes to Step 3. Otherwise, it goes to Step 4.
If the device can provide MD1, it returns a Rep-MD with MD1 and goes to Step 4.
The infrastructure forwards Req-MD from the interface in the index entry and goes to Step 2.
If the infrastructure is AP2, it generates MD1, and returns Rep-MD with MD1 and goes to Step 4. The infrastructure forwards Req-MD from the interface maximally matching the LRP of CA1 and goes to Step 2.
For each pending entry for CA1, the infrastructure forwards Rep-MD from the interface in the entry, removes the pending entry, and goes to Step 4.
The device selectively stores MD1 and becomes a member.
Remote multimedia data delivery. User D1 is associated with AP1 and is located in subnet S1, where the AR is AR1 and the GRP is GRP1. In subnet S2, the AR is AR2 and the GRP is GRP2. Multimedia data MD3 is identified by CA3, where the GRP is GRP2 and the LRP is equal to the 1 of AP4 in S2. MD3 is generated by creating ITC3, and D1 acquires MD3 via the following process:
If Condition 3 is satisfied, it goes to Step 4. If both Condition 4 and Condition 5 are satisfied, it goes to Step 4. If both Condition 4 and Condition 6 are satisfied, it goes to Step 3. The infrastructure creates a pending entry for CA3. If the infrastructure has only one request entry for CA3, it goes to Step 3. Otherwise, it goes to Step 4.
Condition 3: The infrastructure has a pending entry, where the cloud address is CA3 and interface is f.
Condition 4: The infrastructure is AR2 and f is the interface linking with the Internet backbone.
Condition 5: The infrastructure has a pending entry for CA3.
Condition 6: The infrastructure has no pending entry for CA3.
If the device can provide MD3, it returns Rep-MD with MD3, and goes to Step 4.
If the infrastructure is AR1, it updates the GRP of the source address in Req-MD with GRP1, forwards Req-MD to the Internet backbone where Req-MD is routed to AR2, and goes to Step 2. The infrastructure forwards Req-MD to its parent and goes to Step 2.
If the infrastructure has an index entry for CA3, it forwards Req-MD from the interface in the entry and goes to Step 2. If the infrastructure is not AP4, it forwards Req-MD from the interface maximally matching the LRP of CA3 and goes to Step 2. AP4 generates MD3, returns Rep-MD, and goes to Step 4.
If AR2 receives Rep-MD, it forwards Rep-MD to the Internet, where Rep-MD is routed to AR1 and goes to Step 4. For each pending entry for CA3, the infrastructure forwards Rep-MD from the interface in the entry, removes the pending entry, and goes to Step 4.
One of the most critical challenges facing IoT-related multimedia data is to improve its delivery efficiency by sharing resources with IoT devices.
The device selectively caches MD3 and becomes a member.
As shown in Figure 3a, data-delivery latency decreases with speed. The main reason is the increase in speed augments the area where the ITC members spread, reducing the distance between a user and the nearest member or the intermediate infrastructure performing request aggregation.
In ITC, users acquire data from the nearest members or share data from the intermediate infrastructure, so data-delivery latency in S1 and S2 decreases. In S2, the data is delivered between a user and the intermediate infrastructure performing request aggregation, so data-delivery latency is lower than the one in S1. The average data-delivery delay is the one of multiple users retrieving data in either S1 or S2; it also reduces with the growth in speed. Consequently, the success rates in S1 and S2 slightly grow, as shown in Figure 3b.
In Figure 3c, with the increase in speed, the remote multimedia data latency slightly grows. The main reason is that the retransmission of the lost packets brings the extra delivery latency. In S1, a user retrieves data from a remote ITC member. Since the distances between a user and the local AR and between an ITC member and the remote AR are hardly affected by speed, data-delivery latency tends to be steady. In S2 or S3, a user obtains data from the intermediate infrastructure that performs request aggregation and is located in the local or remote subnet. Similarly, the distances between a user and the local AR and between the local or remote AR and the intermediate infrastructure are hardly impacted by speed, so data-delivery latency in S2 or S3 also tends to be stable. The delay in S2 is minimal and the one in S1 is maximal.
To sum up, the mobility of ITC members has little impact on data-delivery latency due to the following reasons: Firstly, most users acquire data from intermediate infrastructures performing request aggregation in either S2 or S3. Since mobility has no impact on intermediate infrastructures, it has little influence on data delivery latency. Secondly, during mobility, CoA reconfiguration and address binding account for a large proportion of mobility handover latency.18,22 Since ITC members perform neither CoA reconfiguration nor address binding, delays caused by mobility are avoided. Lastly, users acquire data from the nearest ITC members that have usually completed reconfiguration to system changes. Since the increase in speed weakens the link performance, the remote data-delivery success rate slightly decreases, as shown in Figure 3d.
Figure 4a shows the effect of speed on the average delay of users retrieving data locally or remotely. As depicted in Figure 3a, local data-delivery latency decreases with the growth in speed because the distance between a user and the nearest ITC member or the intermediate infrastructure performing request aggregation is shortened. As illustrated in in Figure 3c, remote multimedia data latency slightly grows with the increase in speed. Since multi-hop Ethernet architecture expands the area covered by a local network, in most cases users can retrieve data locally.
Consequently, the average delay of users retrieving data slightly decreases with the growth in speed. Since the growth in speed increases the handover frequency, data-delivery latency and cost in the standard grow. As shown in Figure 4b, network performance degrades as speed increases, so data-delivery success rates in the proposal and the standard decrease. This proposal reduces data-delivery delay by nearly 43.68% and improves data-delivery success rates by nearly 15.12%.
In this article, we propose MDITC which, according to experimental results, reduces data-delivery delays and improves success rates. The main reasons are twofold:
The proposed scheme integrates MC with IoT to construct ITC, and ITC has the following differences from clustering:
Acknowledgments. This work is supported by the National Natural Science Foundation of China under Grant No. 61872073 and the LiaoNing Revitalization Talents Program under Grant No. XLYC1902010.
1. Baccarelli, E., Chiti, F., Cordeschi, N., Fantacci, R., Marabissi, D., Parisi, R., and Uncini, A. Green multimedia wireless sensor networks: Distributed intelligent data fusion, in-network processing, and optimized resource management. IEEE Wireless Commun. 21, 4 (2014), 20–26.
2. Balico, L.N., Loureiro, A.A.F., Nakamura, E.F., Barreto, R.S., Pazzi, R.W., and Oliveira, H.A.B.F. Localization prediction in vehicular ad hoc networks. IEEE Commun. Surveys & Tutorials 20, 4 (2018), 2784–2803.
9. Khelifi, H., Luo, S., Nour, B., Moungla, H., Faheem, Y., and Hussain, R. Named data networking in vehicular ad hoc networks: State-of-the-art and challenges. IEEE Commun. Surveys & Tutorials 22, 1 (2020), 320–351.
13. Sheng, Z., Yang, S., Yu, Y., Vasilakos, A., McCann, J., and Leung, K. A survey on the IETF protocol suite for the Internet of Things: Standards, challenges, and opportunities. IEEE Wireless Commun. 20, 6 (2013), 91–98.
23. Zhu, Y.H., Chi, K., Tian, X., and Leung, V.C. Network coding-based reliable IPv6 packet delivery over IEEE 802.15.4 wireless personal area networks. IEEE Trans. Vehicular Technology 65, 4 (2016), 2219–2230.
24. Zhou, J., Leppanen, T., Harjula, E., Ylianttila, M., Ojala, T., Yu, C., and Yang, L.T. Cloudthings: A common architecture for integrating the Internet of Things with cloud computing. In Proc. of the IEEE 17th Intern. Conf. Computer Supported Cooperative Work in Design (2013), 651–657.
25. Zhu, Y.H., Qiu, S., Chi, K., and Fang, Y. Latency aware IPv6 packet delivery scheme over IEEE 802.15.4 based battery-free wireless sensor networks. IEEE Trans. Mobile Computing 16, 6 (2017), 1691–1704.
©2021 ACM 0001-0782/21/8
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from email@example.com or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.
No entries found