Abstract
Mobile Fog Computing (MFC), as a crucial supplement to cloud computing, has its own special traits in many aspects. As smart mobile devices grow and vary in shapes and formats over the years, the need for real-time interactions and an easy-to-use network is imminent. In this paper, we propose a smart collaborative policy for MFC scenarios by considering the target of rural vitalization. The challenges and drawbacks of extending cloud to fog are reviewed at the beginning. Then, the analysis of policy design is presented from the perspectives of feature comparisons, urgent requirements, and possible solutions. The details of policy establishment are introduced with necessary examples. Finally, performance evaluations are provided based on simulation platforms. Validation results related to round trip time and transmission time illustrate the significant improvements of our proposal in certain ways compared to the original candidate, which enables larger deployment in impoverished areas.
1. Introduction
Mobile Fog Computing (MFC) [1], with outstanding performance and specialties in certain aspects of network deployment [2–4], is gradually attracting attentions to solve the problems of practical usage benefitting impoverished regions. For countries such as China, with large gaps of development between urban and rural areas, there is an urgent need for a solution that could handle issues such as limited infrastructural facilities [5–7], tight distribution of current adjacent resources [8–10], and connecting remote districts to the world outside [11–13]. As rural vitalization process is on the way in many places, a comprehensive architecture utilizing modern technology could bring new development opportunities. In this paper, we propose a smart collaborative policy involving mobile fog computing to fully leverage local advantages and avoid possible troubles in operation.
Rural vitalization strategy, which is believed to be one of the Chinese government’s next major steps, is a key factor to determine the future direction of the nation. Due to the differences between people's living standards, educational levels, etc., efficient solutions need to be adopted to bring more evolutional opportunities to these less developed regions, including medical, educational, technological, and employment improvement. In China, rural areas are often associated with poverty, distance, and insufficient infrastructural facilities, along with conservative mindset. As part of the plan, the government hopes to adopt an approach which could create a user friendly network that covers remote impoverished districts and coordinates with the progress to achieve functions. Hopefully, it can enable local rural citizens to receive online education [14] and online medical care [15], together with creating an authoritative platform to introduce more Internet-based enterprises to benefit people by providing employment opportunities [16] and advanced technology [17], as well as supplying fresh and high quality products.
Motivated by the facts stated above, we aim to find a suitable solution utilizing mobile fog computing to assist the rural vitalization process, together with implementation specifically planed for impoverished regions considering their special needs. The contributions of this paper are as follows: A smart collaborative policy for mobile fog computing is proposed and analyzed based on the rural vitalization background. A simulation is executed and the validation results illustrate the practicability of our proposal.
The structure of this paper is as follows: Section 2 presents related work from four different perspectives. Both the advantages and disadvantages are carefully demonstrated. Section 3 introduces generic ideas during the policy design processes. Section 4 discusses the details of policy establishments. Necessary examples and evidences are also provided. Section 5 focuses on performance comparisons. Relevant experiments, scenarios, and cases are properly imported and analyzed. Section 6 concludes the whole paper and points out the future work.
2. Related Work
There are already several surveys and review works done on Mobile Edge Computing (MEC) [18–20] and IoT [21–23] fields. Here, we mainly focus on the latest and typical progress in four specific areas.
For security improvement, Shirazi et al. [24] identified the need for establishing a secure and resilient extension for current cloud network. The authors made a comprehensive comparison between fog and MEC network and analyzed relevant requirements. Both the classic features and implementation methods were discussed to investigate the capacity of the system. The deployment issues were also presented to highlight the availability of schemes. Rathore et al. [25] focused on the contradictions between dynamical changes of security services and efficient support of hosts’ needs. The selection process can be modeled by multicriteria decision making. Hesitant fuzzy soft set was utilized to ensure lower or upper approximation operators. A practical case was introduced during the validation procedures and the results were provided via tabular form. Bierzynski et al. [26] emphasized the importance of combining cloud, fog, and edge computing. They proposed four different schemes to allocate the workload to proper components. Moreover, this paper also analyzed potential issues in the utilization process, including transparent gateways, end-to-end encryption, and hardware security. Dang et al. [27] advocated the merits of using cloud and fog together and discussed the difficulty of data protection in mobile circumstances. A novel model named Region Based Trust Aware was proposed to guarantee dependable translations. An access control scheme was presented for fog nodes as well. Both the applicability and efficiency were verified based on the implemented results.
For mobility enhancement, Puliafito et al. [28] gave a brief description of fog computing evolution and explained the relationship between cloud and edge. Since it is hard to ensure the original transmission connection in mobile fog scenarios, the authors introduced three representative situations: citizen’s healthcare, drones for smart urban surveillance, and tourists as time travelers. This paper also analyzed the relevant problems to illustrate mobility support between fog and IoT. Allam et al. [29] focused on the combination issues of powerful cloud and mobile terminations and insisted that available resources should be provided to end users in a mobile cloud computing environment. Many crucial questions, such as limited computational capacity and battery life, connectivity, data security and privacy, latency, and heterogeneity were presented and corresponding solutions were provided. Tang et al. [30] worried that the existing fog computing could not handle the mobility when a large number of users and plenty of applications were involved. Therefore, the authors proposed an intriguing container migration algorithm to reduce the cost of computational power and communication latency. Markov Decision Process spaces were adopted to establish a container migration model. The benefits of implementation were quantitatively demonstrated based on a prototype system. Zhang et al. [31] extended the mobility investigations from IoT to Internet of Vehicles and declared the shortcomings of the current solutions. By referencing the requirements of smart city, the authors took an initiative to alleviate data burdens of traffic and proposed a regional cooperative fog computing architecture. Service types, such as data obtained in multiple sources, distributed computation, and transmission in multiple paths, are discussed in depth. Both the intra-fog and inter-fog resource administration were analyzed.
For application supporting, Bilal et al. [32] highlighted the significance of video services by introducing the situations of its bandwidth utilization and routine usage. Since the latest demands of interactive gaming are strict, this paper mainly studied the efficient schemes for reducing transmission delay and other resource consumption. Liu et al. [33] reviewed the requests offloading from fog and cloud aspects. The authors insisted that the performance could be improved if energy harvesting and social network are taken into account. To decrease the execution cost of social groups, game theory was leveraged to schedule the computation tasks. Multiple queuing models were adopted to describe the latency and energy usage. Hakiri et al. [34] not only indicated the necessity of exploring wireless mesh networks, but also declared the obstacles of hop-based routing protocols. The authors selected Software Defined Networking (SDN) to extend the visibility of management in wireless fog environment. The evaluations illustrated the results of load balancing, delay decreasing, and other capacities. Tinini [35] emphasized that optical networks could jointly operate with fog computing and network function virtualization to support data exchanging from energy perspectives. An integer linear programming model was built to design an optimal scheme for processing. The comparisons with other candidates showed that the power consumption could be cut down.
For platform establishment, Alonso-Monsalve et al. [36] made an attempt to utilize storage and computing resources to avoid bandwidth saturation by reassigning workload. The proposal was described in video-downloading and video-filtering scenarios with volunteers donating part of the buffer space in their personal smart devices. Multiple experiments were executed and simulation results displayed the performance of the new scheme, in terms of network load, servers load, and throughput. Roca et al. [37] introduced a triple-layer architecture of fog computing and proposed a new orchestration scheme to enhance the interoperability. Both the nodes constellations and Fog Function Virtualization (FFV) were implemented to establish a scalable and pervasive platform. Specific approaches of new services deployment were also presented based on detailed examples. Ali et al. [38] pointed out that, although cloud computing is a promising paradigm, drawbacks are still obvious, such as latency in real-time video streaming, mobility support, and location identification. To minimize the delays, the authors put forward an optimization solution by selecting joint cloudlets within fog scenarios. The relevant limitations in workload were properly designed and validations illustrated the feasibility of the idea. Verma et al. [39] performed a research for patient health remote monitoring through the smart gateway. Several practical services, including embedded data mining and distributed storage, were explained and supported. Totally 67 patients whose homes were equipped with IoT facilities were carefully observed for 30 days. The response latency and accuracy of Bayesian belief network classifier-based model were validated based on comparisons with other baseline algorithms.
3. The Analysis of Policy Design
In terms of educational needs in rural areas, lacking of good faculty resource is a major concern. Putting together the best possible teaching staffs by utilizing the mobile fog computing approach would enable students to receive real-time visual lessons. Moreover, such method could also provide them with the opportunity to learn from default lessons online, especially for schools with minimal amount of students (due to geographical and historical reasons). In this way, they could exchange ideas, raise questions through a shared system, and interact with peers without latency.
When it comes to medical conditions in certain rural areas, well trained medical staffs are in high demand. However, due to budget concerns of local government as well as living standards in such regions, it is difficult for medical units to recruit enough staffs with sufficient skills. There are still critical vacancies need to be filled. Mobile fog computing, on the other hand, is able to integrate local medical resources and provide patients with decent medical treatments. It is also possible to provide online treatment through patients’ personal devices under supervision. By adopting this approach, the gaps of medical level between various areas will not be so obvious. At the moment, it is difficult to send well-trained medical staffs to impoverished districts to give local medical staffs guidance and to treat local patients. However, with the completion of a well-designed mobile fog computing platform, it is likely that medical staffs in the entire area could learn from more skillful ones without latency, reducing physical distances and travel obstacles.
Currently, the government is attempting to introduce Internet related enterprises to enter the rural market, aiming to bring about advanced technology and employment opportunities, along with a variety of goods that were previously distant from the residents’ daily lives in impoverished regions. Nevertheless, some of these residencies are located in rocky mountain areas isolated from the world outside, with poor signal coverage, extreme weather, and traffic conditions. Considering such natural disadvantages, it is crucial that the logistics approaches adopted in such areas can be supervised through real-time equipment to ensure the safety of couriers and to know precise locations during delivery procedures.
3.1. Feature Comparisons
Based on the structure of mobile fog computing platform, growing combinations to bring fundamental changes to rural vitalization are expected. When it comes to designing a network that meets the need of local people, comprehensive factors should be considered. Cloud computing, already a successful and widely utilized solution, had been existing for more than 10 years to date. It does have its own merits, such as high coverage and large storage space, but with the ever-growing demand to achieve specific approaches, there are still some challenges:(i)Setup costs: Compared to mobile fog computing, it is expensive (including longer deployment periods and higher prices) for the cloud computing systems to establish available connections. These costs are significant in most cases.(ii)Real-time response: The time it takes to upload and download within cloud network largely depends on the distance and intermediate facilities, as well as the devices in use. Such a situation makes video streaming and interactive gaming unstable.(iii)Localized features: Normally, the current mobile fog network is based on locations, and many of the rural regions are isolated or even located in mountain areas. A network with geographic traits would encourage local people to connect with each other achieving regional collaborations.
Mobile fog computing, as an extension and successor to the existing cloud network, makes the connection of various portable devices, such as laptops, tablet PCs, and smart phones a lot easier, and adding new devices into existing networks is also relatively convenient. Compared with cloud computing, fog computing focuses on the edges of calculation resources, which reduced severe risks that large data processing centers face such as malicious attacks and distributed denial of services.(i)Data transmission speed: As fog network is established within a specific area, the transferring speed among participant devices is faster than that of cloud network due to short communication distance.(ii)Sharing of storage capacity: MFC allows users to store their data on nearby devices safely, which means the buffer capacity of each candidate can be greatly extended if availability is well guaranteed.(iii)Cost-effective and resource friendly: The cost to build a fog network is considerably less compared to a cloud network. Besides, as not all the information is being processed through the same router nor at the same time, bandwidth utilization will be more flexible and can be reserved for specific needs.
These specialties determine that fog computing is a more suitable approach for smaller scale coverage, budget concerned, and real-time stream required circumstances. In many cases, the effective usage of fog computing would enable rural areas to develop at a higher speed with lower cost. Meanwhile, it can also be a protection for companies or the government to carry out experimental actions. For example, if an Internet company aims to provide its services to a remote impoverished region, considering its geographic distance and natural environment, it is unsure whether the investment will be effective. By adopting a cloud computing network, it will first need to prepare for the entire connection procedure, which takes more time and more resources. If the project cease to continue in the future, the primary input will then be significantly huge compared to adopting a fog computing method which is more on the easy-to-use and easy-to-quit side.
3.2. Urgent Requirements
Big cities have to establish highly reliable wireless systems. From the infrastructural perspective, massive redundant base stations are built to guarantee basic telecom signal coverage. Both sporadic and intensive access points of WiFi are strong supplements for Internet signal coverage. Huge populations and diverse applications had continuously added enormous burdens and challenges (such as low spectrum utilization, regular transmission congestion) for all kinds of access modes. Big data generated from each end host stimulate redundant constructions of base stations and access points. Such circulations had been witnessed for many years. The designer, implementer, and administrators are attempting to enhance the efficiency and reduce the cost since the beginning. From the service perspective, encryption is a kind of frequently used approach to achieve dependable transmission. Many complicated algorithms had been proposed in different layers to improve security, which enable the possible utilization in multipath scenarios. A simple understanding is that distributing the data packets on multiple available paths would definitely increase the difficulty of sampling. More importantly, the transmission would not be interrupted when one path fails since data packets could be sent on other paths and the service could be maintained. This evidence shows that more paths may bring strong dependability.
Based on the population mobility features, information point distribution patterns, online business content, user sensitive data, etc., it makes sense to provide full coverage, high bandwidth, excessive links, and smart mechanisms to meet various users’ demands in metropolises. However, for impoverished regions, the urgent requirements are quite different.
Firstly, the mobility of population is relatively low and the distribution of impoverished people is unbalanced. Without modern transport vehicles and convenient highways, it is difficult for the natives to extend the range of routine activities. In such circumstances, the capacity of one base station might be more than enough for a small village. It is inefficient and uneconomical to establish individual coverage just for sparsely populated places. A better way is to cover larger areas with more base stations. However, the reasonable deployment patterns need to be investigated carefully.
Secondly, more and more data collection points (for plant monitoring, animal shepherding, etc.) and dissemination points (for agricultural knowledge training, culture courses teaching, etc.) are urgent for natives to connect to the Internet. In order to help people to shake off the burden of poverty, bidirectional communication with high quality and high dependability is necessary. As the strong supporters, various candidates are qualified in this direction.
Thirdly, the environment and condition of deploying networks in impoverished regions are harsh and complicated. Building wired connections, sometimes, is extremely hard and may cost triple or quadruple capital expenditures comparing with establishing them in cities. Therefore, more wireless connections should be considered and adopted. Some hybrid solutions are also preferable if the construction condition is allowable.
3.3. Possible Solutions
The reasonable responses for previous requirements can be generated from different points of view based on novel mechanisms, emerging technologies, and up to date equipment.
Firstly, optimizing strategy and sufficient planning should be made by considering overall situation comprehensively. For instance, traditional impact factors, such as execution difficulties, people distributions, and signal coverage, should be used to determine the construction modes of the base stations and the access points. Taking a large-scale case as an example, three kinds of patterns, i.e., uniform, intensive, and dispersive, are demonstrated in Figure 1. One satellite picture is selected to schematically show the location of native people. The base stations marked with red color can also be replaced by access points in reality. Covered areas are enclosed with multiple hexagons. These fundamental infrastructures also provide support for the following new policy implementation.
Secondly, multiple paths created by various access modes (2.5G, 3G, 4G, etc.) can be synergistically utilized to improve reliability, enhance security, reduce latency, and increase bandwidth. More specifically, as the aggregation node, it may contain several Subscriber Identity Module (SIM) cards and one standard WiFi interface simultaneously to achieve flexible networking. Native users could easily connect to it via electronic devices to communicate with remote experts. The intermediate routers are also available to provide encryption and decryption. Such reliable transmission in a mobile multipath environment is illustrated in Figure 2.
Thirdly, wireless LTE-enable microcell and picocell can be implemented to cooperate with base stations. Due to the advantages in size, weight, and cost, such equipment can be easily adopted in complicated and severe environments. In order to leverage the high performance of wired connections, the combination scheme between LTE and Ethernet is also convenient to achieve. Industrial class products (CPU, memory, hard disks, etc.) are preferred to guarantee the reliability.
4. The Details of Policy Establishment
There are plenty of reasons to adopt one way delay instead of round trip time (RTT) in designing a smart collaborative policy. A high priority packet arriving at the destination with a faster speed is recommended. The selected path with minimum forward or backward delay will be the most suitable candidate.
Due to the absence of mandatory clock synchronization in current Internet or other computer networks, the absolute value of one way delay is extremely hard to obtain, especially in some large-scale scenarios. The existing random errors in the clock calibration procedure may severely confuse the measurement results. By witnessing these facts, we proposed Relative Delay Estimator (RDE) in the previous work. The idea is to calculate relative differences rather than the absolute values. The implementation scheme simply added some new chunks to the protocol stack. However, we argue that the efficiency can be further enhanced via novel approach.
The basic clue is to change the format of current Stream Control Transmission Protocol (SCTP) chunks (i.e., data chunk and acknowledgment chunk) and encapsulate relevant information used by RDE into packets. Three time variables are applied to calculate relative delay for each path. By updating these variables continually during packet interaction procedures, the sender will be clearly aware of the changes in one way delay.
4.1. Timestamp Usage
If the sending (receiving) timestamp at the sender-side is stored when the data packet (acknowledgment sent by receiver) is being sent (received), only adding the timestamp of receiver-side into the acknowledgment is sufficient for RDE calculation. The basic assumption is that the receiver would respond as soon as it obtains the data packet (i.e., there is no latency between the data packet receiving and acknowledgment sending at the receiver-side). In order to prove the rationality and feasibility, we review the functions of conventional timestamp in Transmission Control Protocol (TCP).
Firstly, the length of sequence number field in TCP packet header is 32 bits, which seriously restricts the maximum value of corresponding volume, i.e., 232. In high bandwidth circumstances, the sequence number might wrap within a short period if there are huge data packets need to be transferred. That means it is possible to see two data packets with the same sequence number in the same network. The TCP timestamp can be used to avoid this awkward situation. As an extension to the sequence number space, it will assist the sender and receiver to differentiate these data packets and make the right decision. Such scheme is called “Protection Against Wrapped Sequence (PAWS) Numbers”.
Secondly, in some implementation processes, TCP only measures the RTT once in each data sending window. The retransmission timer will be set when the data packet is sent, and the RTT would be calculated when the acknowledgment is received by the sender. However, the value of such calculation cannot accurately reflect the variety of RTT very well. Therefore, the timestamp can be added to each packet header to obtain a more precise result without increasing more storage burdens at the sender-side. Whenever an acknowledgment arrives, the sender can compute directly by using sending timestamp (inside the packet header) and receiving timestamp (recorded by the local timer). If the delay acknowledgment is enabled, the corresponding adjustments will be needed. For example, the specific delay period could be pointed out by the receiver and piggybacked with acknowledgment. When the sender obtains such information, the value of RTT could be easily achieved.
Based on above discussions, there are two main reasons why TCP contains sending timestamp in the packet header. The first one is for protecting the PAWS. The second one is to accurately calculate RTT and reduce the burden of the sender.
However, we argue that these two reasons may not hold true in SCTP anymore. Although there are still 32 bits in sequence number field for both SCTP and Concurrent Multipath Transfer (CMT) SCTP cases, it is not easy to see the packet with wrapped sequence numbers even in high bandwidth networks, because each Transmission Sequence Number (TSN) is assigned to a data chunk (in TCP case, TSN is assigned to each byte). The second reason is true only when the resource of user’s equipment is quite limited. With the evolution of hardware design, the performance of terminals has been greatly improved after TCP timestamp was proposed. Since the data packets sent to network can be uniquely identified with TSN, one can store the sending timestamp for RTT calculation at the sender-side without consuming too much storage resource. Compared with the burden introduced by recording sending timestamp, filling more messages into each data packet may be more important in many scenarios.
As a brief summary, for the high performance end host which aims to implement new scheme and send more messages in each packet, it makes sense to record the sending timestamp at the sender-side. For the end host which really cares about the storage resource, they could implement new schemes by adding sending timestamp into packet header.
4.2. Protocol Simplification
Apart from whether it is suitable to keep the sending timestamp at the sender-side, there are still some difficulties during the protocol simplification.
The first one is whether to let the receiver know about the result of RDE (i.e., the backward path with minimum delay). If the answer is “Yes”, some changes in both the data packet format and process procedures are needed. Since there is no RDE state recorder inside the receiver, a possible solution for the sender is to contain the path identifier in retransmitted packets and guide the receiver to transmit the Selective ACKnowledgment (SACK) via a corresponding path. However, it may consume precious space of the data packet header. The extra process for checking the notification provided by the sender has to be designed at the receiver-side. If the answer is “No”, the original data packet format could be maintained. In most current multipath transport protocols, the data packets sent on one path could also be acknowledged by the SACKs sent on other paths. Such mechanism enables the sender to update relevant calculation variables quickly. Nevertheless, the disadvantage is that the sender may wait for a bit longer time to realize the receiving situation of previous retransmitted packets. Here, we choose the second scheme to minimize modifications at both sides.
The second one is on how to find the data chunk that triggered the SACK chunk inside the send buffer. In order to better prepare the retransmission brought by packet loss, all the data chunks sent on different paths will be stored inside the send buffer. Our solution is to use a chain table to link each data chuck and the sending timestamp. When the sender receives a new SACK chunk, it should look up the data chunk inside the send buffer to search for the relevant sending timestamp. We suggest recording the sending timestamp in the original structure of the data chunk. Due to the rules that one SACK chunk may acknowledge more than one data chunk, such as delay SACK or SACK missing, the sender should treat the data chunk with largest sending timestamp as the “trigger data chunk” and use the sending timestamp of this data chunk to update corresponding calculation variables.
The third one is on how to modify the format of SACK chunk. There is no doubt that the receiver’s timestamp is needed when the sender wants to update relevant information. According to the requirement of RDE, we add 4 bytes receiver’s timestamp into each acknowledgment. The difference between the original and the new format of SACK chunk is shown in Figure 3. Necessary actions on both sides will be given in the following. Based on the Karn algorithm, the SACK of retransmitted packets should not be used in calculating RTT. That is because both original and retransmitted packet may trigger such SACK. The situation is the same during the RDE calculation process. For distinguishing these SACKs from normal ones at the sender-side, the bits inside “Chunk Flags” could be fully utilized. For instances, something like “FLAG RTX” can be used to indicate the SACKs which should be ignored. At the receiver-side, it is not necessary to contain the receiver’s timestamp anymore for these SACK chucks.
The fourth one is on how to deal with “out-of-order” SACK chunks. In the mechanism of SCTP or CMT-SCTP, a cumulative TSN value will be maintained at the sender-side. When a new SACK chunk with a larger cumulative TSN is received, the sender will update this value and delete the data chunks with smaller TSNs inside the send buffer. If the new SACK chunk has a smaller cumulative TSN, it will be ignored. It is true that out-of-order SACK chunk should not be processed when the sender calculates the congestion window increase value. However, in the new scheme, such mechanism may introduce serious problems. In a common case, assuming “SACK chunk A” was firstly sent on path 1, then “SACK chunk B” was launched on path 2. Their arriving sequence to the destination might be reversed due to the difference of transmission delay. Normally, the cumulative TSN contained in “SACK chunk B” should be larger than that of “SACK chunk A”. As a result, the sender will drop “SACK chunk A” thus cannot update calculation variables of the path which has large backward delay. Even though this “SACK chunk A” is processed by the sender when it arrives, the corresponding sending timestamp may not be found because the data chunks with smaller TSNs had been deleted. If most SACK chunks sent on path 1 are handled in the same way, the information related to path 1 cannot be gathered to reflect the current situation. In order to avoid it, the sender should keep the sending timestamp of the data chunk until it is acknowledged by the SACK chunk sent on the same path. More importantly, each SACK chunk should be carefully processed even if it is out-of-order.
4.3. Implementation Procedure
After four-way handshakes, a CMT-SCTP association will be established. Then the calculation variables of RDE for each path should be set to 0 at the sender-side. The normal data chunk (not retransmitted ones) and normal SACK chunk (not for confirming retransmitted ones) should be transferred as ordinary rules, i.e., on the preassigned path based on a scheduling mechanism. RDE calculation will be operating in backstage and the result should be prepared for further usage at any time. When packet drop is pointed out via duplicated SACKs or timeout, the retransmitted data chunk(s) will be sent on the path with minimum forward delay. Although the corresponding SACK chunk may not be sent on the path with minimum backward delay, the overall performance should not be seriously influenced because retransmitted data chunks could be quickly confirmed by the SACK chunks sent on other paths.
During the discussion process, we only selected a SCTP-based transport protocol as the modified object. However, the described method is workable as well for TCP-based protocols in multiple scenarios.
5. Simulation and Comparisons
To better evaluate the performance of our new policy, comprehensive validations are executed based on NS2 and Matlab. A generic mobile fog computing environment is implemented within a specific area with source, intermediate, and destination nodes. Necessary modifications have been carefully accomplished in source code. The key parameters, such as covered areas, packet volume, and transmission latency, are adjusted according to different requirements.
Two experiments together with two scenarios are established based on moving ability and interval delay, respectively. Case one is to illustrate that a few nodes are randomly deployed and resulted in weak connectivity. Case two is to demonstrate that more nodes are involved and abundant connections have been created.
5.1. Experiment One
The first experiment is focusing on the static situation. During the transmission processes, the participants are able to store and forward the content without changing locations. Two cases are implemented to display the improvements.
More than 1 hop might be triggered from the source to the destination when a single packet was sent. The relationships between RTT and number of hops are illustrated in Figure 4(a). For case one (shown in blue lines), the initial values of two policies are quite close to each other. From 2 to 10 hops, the differences can be clearly observed. The gap value is getting larger until the number of hops reaches 6. The reason might be that most packet sending is finished within 8 hops in such situations. When 9 or 10 hops appear, the gap value becomes larger again. For case two (shown in green lines), similar phenomenon can be found if more nodes join in. Due to expanded distance, the cost of packet forwarding is also increased compared with that of case one. However, for both of them, the curve fluctuations of our policy are always small since it can choose a better route among various candidates.
(a)
(b)
The transmission time is recorded and analyzed when multiple packets are sent, which is demonstrated in Figure 4(b). From the beginning to the end, all the packets are generated uniformly. For case one (shown in red lines), the gap value is quite small when 500 packets appear. Although advantages of the policy can be easily displayed in the previous figure, it is not obvious when the unit was changed from ms to s. With the increasing of packet number, the gap value arises again and reaches the maximum when 2500 packets are set. For case two (shown in black lines), it is quite interesting to discover that gap value is enlarged when X axis is equal to 2000. Similar variation cannot be found in case one. The reason might be that more routing options are provided when strong connectivity is established. If there is only one path between the source and destination node, the overall latency will be the same no matter which policy is adopted. Such accumulation will not benefit the transmission efficiency if too many “no option” packets are forwarded within the network. Anyhow, both cases have illustrated the superiority of the new policy.
5.2. Experiment Two
The second experiment is focusing on a dynamic situation, which means the involved nodes can change their positions during data exchange. Two cases, similar to previous experiment, are launched to describe the complex processes.
In Figure 5(a), the variations of RTT are described based on the hop number increasing. For case one, the curve of original policy (marked with circle) is getting higher with strong fluctuations. The curve of updated policy (marked with square) maintains its stable characteristic. At the beginning, the improvement ratios for 1 and 2 hops are 49.1% and 49.5%. Then, such value is reduced to 29.6% when hop number is equal to 3. The unstable pattern of gap values can be observed as well. The minimum and maximum enhancements are 10.8% and 34.9% when the hop number is from 4 to 10. For case two, the locations of two curves are a bit higher than that of case one. A noteworthy observation is that the fluctuation of original policy is weakened. One possible reason is that strong connectivity in dynamic situation converges the distribution of nodes. Due to position changing, transmissions might be interrupted or stopped, which seriously affects the curve tendency. Therefore, all the values are greater than 90 ms if 9 or 10 hops are selected.
(a)
(b)
In Figure 5(b), the growth of transmission time is presented based on different packet numbers. For case one, curves of the original policy and updated policy are increased proportionately. The improvement ratios are 34.4%, 23.0%, 23.8%, 22.5%, and 28.0%, respectively. Although more packets have inhibited the fluctuations of the original policy, the final performance is still not acceptable. For case two, such pattern is maintained and even more connections are involved. About 44.1% (or 22.1%) overall latency can be reduced in the best (or worst) circumstance. When the packet number is equal to 2500, the maximum gap value is 24.7s. From the above results, the influences brought by node mobility are almost negligible if the new policy is employed accurately.
6. Conclusions
Mobile Fog Computing (MFC) has been recognized as a powerful tool for cloud computing extensions. In order to solve practical difficulties during the rural vitalization process, we proposed a smart collaborative policy based on specific demands. Firstly, the significant preliminaries and discussions were given to deal with multiple application categories. Secondly, the timestamp usage, protocol simplification, and implementation procedure were respectively, presented to establish the policy in detail. Thirdly, two experiments were designed according to the node mobility situations. For each of them, two scenarios and two cases were involved to provide comprehensive validations. The advantages of our policy, in terms of round trip time and transmission time, were fully illustrated when different hop and packet numbers were utilized. For instance, in the second experiment, the improvement ratio is 29.6% when hop number is equal to 3.
For future work, the large-scale deployment will be considered and implemented. The enhancements of the smart collaborative policy should be achieved based on the feedback of applications.
Data Availability
The data used to support the findings of this study are included within the article.
Conflicts of Interest
The authors declare that they have no conflicts of interest.
Acknowledgments
This work was supported in part by the Fundamental Research Funds for the Central Universities under Grant 2017JBM012, in part by Joint Foundation of China University of Petroleum-Beijing at Karamay, and in part by the Project of State Grid Corporation of China under Grant SGRIXTJSFW2016]377.