Communications of the ACM

Contributed articles

Multimedia Data Delivery Based on IoT Clouds

By Xiaonan Wang, Xingwei Wang
Communications of the ACM, August 2021, Vol. 64 No. 8, Pages 80-86
10.1145/3474089
Comments

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.

Back to Top

Key Insights

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.¹⁰

Internet Protocol (IP) version 6 could be the IoT's future.^5,13 However, if IP-based data delivery methods^{3,11,15,23,25} are directly deployed in the IoT, they might be confronted with the following challenges:^2,19

• IP-based data delivery methods are centered on end-to-end communications;²⁵ that is, each data-delivery process is independently performed between a source and destination pair. A source node must retrieve data from a destination node even if an intermediate device can provide target data. Consequently, the data-delivery latency is considerable. Moreover, if the destination is unreachable, the data-delivery process might fail.^3,9
• Because of the end-to-end feature, it is difficult for devices to collaborate, create, and share multimedia data because each data-delivery process is performed independently.²³ However, it is significant for IoT devices to collaborate because of their limited resources.
• If a device moves to a new IP domain, it must be configured with a Care-of Address (CoA).¹² Since CoA configuration is time-consuming, it introduces extra data-delivery latency and causes data-delivery failures.^18,22

According to Kahn et al.,⁸ 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:

• ITC members can collaboratively generate and locally maintain multimedia data so they can rapidly provide them.
• A user can retrieve multimedia data from the nearest cloud member so data-delivery latency can be reduced.
• A user can acquire multimedia data without CoA configuration to improve data-delivery success rates.

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:

• An ITC construction algorithm is proposed so IoT devices can collaborate to create locally relevant multimedia data. Based on the ITC construction algorithm, a multimedia data-delivery algorithm is proposed so a user can acquire data from the nearest member rather than a target device defined by a destination address. Moreover, a device is identified by an invariable device ID, which may be a media access control (MAC) address or may be configured by employing existing addressing methods and does not need to perform CoA configuration. Consequently, data-delivery failures caused by address changes are avoided.
• Multi-hop Ethernet architecture is introduced to IoT. The proposed architecture consists of the multi-hop Ethernet backbone, made up of infrastructures, and the ITC, composed of mobile IoT devices. The proposed scheme is a combination of both wired and wireless systems because it consists of wired infrastructures, such as routers or switches, and wireless IoT devices, such as sensor nodes or smartphones. Based on the multi-hop Ethernet architecture, a multimedia data request aggregation mechanism is proposed to enable multiple users to retrieve multimedia data via one data-delivery process in parallel. Since the size of multimedia data is large, request aggregation substantially reduces data-delivery latency. Moreover, the multi-hop Ethernet architecture expands the area covered by a local network so, in most cases, a user can retrieve data locally. Consequently, data-delivery latency is further reduced.

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.¹⁰ Moreover, it is usually local or nearby users who are interested in locally relevant data.²⁴

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.

Back to Top

IoT Architecture

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.

Figure 1. LRP configuration.

Table 1. Acronyms.

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.

Table 2. Cloud address.

Table 3. Unicast address.

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:

1. The AR sends a Conf-LRP message from each interface f linking with a switch or an AP, and the payload in Conf-LRP includes c, f, and h.h is the hierarchy in a tree, and the initialization value is 0.
2. The infrastructure receiving Conf-LRP constructs its LRP, where the first h·c bits are equal to the ones of the source LRP in Conf-LRP, the following c bits are f, and the last i-(h+1)·c bits are 0.
3. If the infrastructure is a switch, it increases h by 1, forwards Conf-LRP from each interface f linking with a switch or an AP, and goes to Step 2.
4. The LRP configuration is complete.

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.

Back to Top

Multimedia Data Delivery

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:

1. AP2 constructs a unicast address, where the GRP and device ID are 0 and the LRP is AP2's 1, and then sends a Gen-MD message to associated devices. The source address in Gen-MD is the unicast address, and the destination address is CA1.
2. If the device receiving Gen-MD can share the resources to generate part(s) of MD1, it returns a Gen-Ack message with the generated data.
3. AP2 processes the data in the received Gen-Ack to construct MD1 and sends a Share-MD message with MD1.
4. The device receiving Share-MD selectively stores MD1 and becomes an ITC1 member.

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.

Figure 2. Multimedia data delivery.

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:

1. The AP creates an index entry—where the cloud address is CA1 and the interface is f—and sends a Gen-Index message with CA1 to its parent.
2. If the parent receiving Gen-Index from interface f' does not have an index entry for CA1, it goes to Step 3. The parent abandons Gen-Index and goes to Step 4.
3. The parent creates an index entry for CA1. If the parent is a switch, it forwards Gen-Index to its parent and goes to Step 2.
4. The process is complete, as shown in Figure 3a.

Figure 3. Multimedia data-delivery evaluation.

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.

1. D1 constructs its unicast address, where the GRP is 0 and the LRP is AP1's 1, and then sends a Req-MD message, where the source address is the unicast address and the destination address is CA1.
2. After Req-MD is received from interface f, it is dealt with based on the following cases:

• Case 1: An infrastructure receives Req-MD

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.

• Case 2: A device receives Req-MD

If the device can provide MD1, it returns a Rep-MD with MD1 and goes to Step 4.

1. The infrastructure deals with Req-MD based on the following cases:

• Case 3: There is an index entry for CA1

The infrastructure forwards Req-MD from the interface in the index entry and goes to Step 2.

• Case 4: There is no index entry for CA1

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.

1. After the Rep-MD is received, it is dealt with based on the following cases:

• Case 5: An infrastructure receives Rep-MD.

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.

• Case 6: A device receives the Rep-MD

The device selectively stores MD1 and becomes a member.

1. The process is complete, as shown in Figure 4.

Figure 4. Multimedia data-delivery comparison.

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:

1. D1 constructs its unicast address, where the GRP is 0 and the LRP is AP1's 1, and sends Req-M, where the source address is the unicast address and the destination address is CA3.
2. After Req-MD is received from interface f, it is dealt with based on the following cases:

• Case 1: An infrastructure receives Req-MD

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.

• Case 2: A device receives Req-MD

If the device can provide MD3, it returns Rep-MD with MD3, and goes to Step 4.

1. The infrastructure deals with the Req-MD based on the following cases:

• Case 3: The infrastructure in S1 receives Req-MD

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.

• Case 4: The infrastructure in S2 receives Req-MD

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.

1. After MD-Rep is received, it is dealt with based on the following cases:

• Case 5: An infrastructure receives Rep-MD

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.

---

• Case 6: One device receives the Rep-MD

The device selectively caches MD3 and becomes a member.

1. The process is complete, as shown in Figure 4.

Back to Top

Evaluation

The proposed scheme is evaluated in ns-2, as shown in Figures 3 and 4. The simulation parameters are shown in Table 4.

Table 4. Simulation parameters.

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.

This proposal is compared with the standard,¹¹ as shown in Figure 4.

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%.

Back to Top

Conclusion

In this article, we propose MDITC which, according to experimental results, reduces data-delivery delays and improves success rates. The main reasons are twofold:

• Users can acquire multimedia data from the nearest members via one data-delivery process.
• ITC members do not need to perform lengthy CoA configuration.

The proposed scheme integrates MC with IoT to construct ITC, and ITC has the following differences from clustering:

• The main objective of clustering is to enhance routing reliability and scalability by reducing node population involved in forwarding and enhancing network stability.^4,20 The main goal of ITC is to enable resource sharing and collaboration among cloud members to create, share, and provide multimedia data.
• The architecture of clustering is hierarchical because each cluster member independently generates data, and a cluster head is responsible for aggregating data generated by cluster members to enhance data-delivery efficiency.^4,20 The architecture of ITC is flat, since each member is equal and has a right to cache and provide multimedia data.
• In clustering, each data-delivery process is independently performed between a source and destination pair. That is, a source node has to retrieve data from a specific node identified by a destination address.^4,20 In ITC, by contrast, multiple users can acquire data from the nearest ITC member via one data-delivery process.
• In clustering, cluster heads need to perform CoA configuration and suffer from data-delivery failures caused by address changes.^4,20 In ITC, each member does not need to be configured with CoA, so data-delivery failures caused by address changes are avoided.

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.

Back to Top

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2021 ACM, Inc.

---

No entries found