COMP9334 Project, Term 1, 2019:Fog/cloud ComputingVersion 1.0Due Date: 11:00pm Friday 26 April 2019.This version: 20 March 2019Updates to the project, including any corrections and clarifications, will be posted on thesubject website. Make sure that you check the course website regularly for updates.Change logNothing for Version 1.0.1 Introduction and learning objectivesThis project is inspired by the research work reported in the article FogQN: An Analytic Modelfor Fog/Cloud Computing [2] on modelling a computing system that makeg use of both fog andcloud computing. The key question studied in the paper is on how to distribute work betweentwo computing resources, namely the fog and the cloud. In this project, you will use simulationto try to answer a similar research question.In this project, you will learn:1. To use discrete event simulation to simulate a computer system2. To use simulation to solve a design problem3. To use statistically sound methods to analyse simulation outputs2 Support providedIf you have problems doing this assignment, you can post your question on the message boardon the subject website. We strongly encourage you to do this as asking questions andtrying to answer them is a great way to learn. Do not be afraid that your questionmay appear to be silly, the other students may very well have the same question!3 Description of the fog/cloud computer system3.1 Introduction to fog/cloud computingYou are probably aware that there are many more devices with Internet connectivity nowadays.These new devices include sensors, vehicles, Internet-of-Things (IoT) etc. In general, these devicesare referred to as the edge devices. The fog and the cloud are two places to process the data comingfrom these edges devices, see Figure 1.1MOURADIAN et al.: COMPREHENSIVE SURVEY ON FOG COMPUTING: STATE-OF-THE-ART AND RESEARCH CHALLENGES 421Fig. 4. The Fog System.the name of Mobile Edge Computing (MEC), with a focuson mobile networks and VM as virtualization technology.However, its scope has been expanded in March 2017 toencompass non-mobile network requirements (thus thereplacement of “Mobile” by “Multi-Access” in the name), aswell as virtualization technologies other than VM.Prior to the scope expansion, the concept (envisioned asa key technology towards 5G) [34] aimed at providing cloudcomputing capabilities at the edge of mobile networks, andwithin the Radio Access Network (RAN). These capabilitiesare provided by mobile edge computing servers which canbe deployed at LTE macro base stations (eNodeB) sites, 3GRadio Network Controller (RNC) sites, and at multi-RadioAccess Technology (RAT) sites. The envisioned applicationsinclude augmented reality, intelligent video acceleration, andconnected cars. The edges of non-mobile networks and relatedapplications will certainly now be considered due to thenew scope.The functional entities [41] (before the scope expansion)include the mobile edge platform and the mobile edge host.The mobile edge platform provides the functionality requiredto provision mobile edge applications on a specific virtualizationinfrastructure while the mobile edge host anchors theplatform and the virtualization infrastructure. Other functionalentities might now be added to the architecture as a result ofthe scope expansion.A fundamental goal assigned to the ETSI initiative is tostandardize the APIs between the mobile edge platform andthe applications in order to foster innovation in an openenvironment. Several APIs have already been standardized(e.g., Mobile application enablement API [42], radio networkAPI [43], Location API [44]). Reference [45] providesa survey of MEC.D. Fog ComputingFog computing, a concept introduced by CISCO in 2012, isan extension of cloud computing paradigm from the core to theedge of the network. It enables computing at the edge of thenetwork, closer to IoT and/or the end-user devices. It also supportsvirtualization. However, unlike cloudlet and MEC, fog istightly linked to the existence of a cloud, i.e., it cannot operatein a standalone mode. This has driven a particular attention onthe interactions between the fog and the cloud [11]. Moreover,fog has an n-tier architecture, offering more flexibility to thesystem [13], [16].Fig. 4 shows a fog system with a three-tier architecture.It has three strata: The cloud stratum, the fog stratum, andthe IoT/end-users stratum. The fog stratum can be formed byone or more fog domains, controlled by the same or differentproviders. Each of these fog domains is formed by thefog nodes that can include edge routers, switches, gateways,access points, PCs, smartphones, set-top boxes, etc. As for theIoT/end-users stratum, it is formed in turn by two domains,the first including end-user devices and the second includingIoT devices. It should be noted that one of these twodomains may be absent in the stratum. It is, for instance,the case of fog systems based – content delivery. There isFigure 1: This figure depicts the three layers of edge devices, fog and cloud. The edge devicesare the end-user devices and IoT, which is short for Internet-of-things. Note that LAN and WANstand, respectively, for local area network and wide area network. This diagram shows that theedge devices are closer to the fog computing resource than the cloud computing resource. Thisfigure is taken from [1]. The fog is a computing facility located closer to the edge devices. The network latency toreach the fog computing facility is therefore low. However, the fog has a lower processingspeed. The cloud is a computing facility farther away from the edge devices. The network latencyto get to the cloud is higher. However, the processing speed at the cloud is higher than thatin the fog.Given that there are two facilities to process the data from the edge devices, a question iswhich facility we should make use of in order to reduce the overall response time. Note thatthe overall response time of using a facility is the sum of two parts, which are the network latencyto reach the facility and the response time of doing the processing at the facility. Now, letus consider the case of doing all the processing at the fog. The network latency will be low butthe response time of doing the processing at the fog is high. On the other hand, if we do all theprocessing at the cloud, then the network latency will be high but the response time of doing theprocessing at the cloud is low. Neither one of these two options appears to be the best option.In this project, you will investigate how to distribute work between the fog and the cloud inorder to minimise the overall response time. Note that this is all about fog/cloud computing thatwe will tell you so that you get enough intuition to understand this project. If you want to learnmore about the fog/cloud computing paradigm, which is an area of commercial and academicresearch at the moment, you can consult [1].3.2 Fog/cloud setup for this projectFigure 2 depicts the fog/cloud system to be considered in this project. The system consists ofthree components: the fog, the network and the cloud. We assume that all the requests will goto the fog computing facility in the beginning. The fog will process these requests but imposes2Fog Network Cloud ArrivingrequestsPermanentdepartureat the fogRequestsproceedingto the cloudvia thenetworkPermanentdepartureat the cloudis a PS server is a server withvariable delay Notation:Figure 2: The fog/cloud computing system in this project.an upper limit on the processing time spent on each request. If a request requires an amount ofprocessing less than or equal to the upper limit, this request will be completed at the fog and leavethe system permanently upon completion. On the other hand, if a request requires an amount ofprocessing more than the upper limit, the request will be sent to the cloud via the network andthe cloud will complete the rest of the processing. After the cloud finishes the processing, therequest will leave the system permanently.In this project, we model the fog as a processor sharing (PS) server. The same holds for thecloud.The network is modelled as a server with variable delay. We use the term network latency torefer to this delay. Consider a request which is to be sent to the cloud. If this request leaves thefog at time t and the network latency for this request is x, then this request will arrive at the cloudat t + x. For a server with variable delay, the value of x for different requests can be different.Note that there are no queues at the variable delay server modelling the network.4 ExamplesWe will now present three examples to illustrate the operation of the fog/cloud system that youwill simulate in this project. In all these examples, we assume that the system is initially empty.4.1 Example 1: Simulating a PS serverIn this example, we assume there are 5 requests. The arrival times and service times required atthe fog are given in Table 1.We further assume that the fog will give each arriving request a processing time of no morethan 5 time units. Since the service times of the five requests are all less than or equal to thisupper limit, all these requests will be completed at the fog and will not be sent to the cloud. Thiseffectively means that, for this example, we only need to simulate the PS server for the fog, and3Arrival time at the fog Service time required at the fog1 2.12 3.33 1.15 0.515 1.7Table 1: Data for Example 1.we can neglect the network and the cloud. The aim of this example is to show you how to simulatea PS server.The PS server was discussed in Lecture 4A. When there are n jobs in the server, then each jobreceives 1nof the service.The events in a PS server are the arrival of a job to the server and the departure of a completedjob from the server. You should convince yourselves that between two consecutive events,the number jobs in a PS server remains the same. The discrete event simulation advances froman event to the next one.The key data structure that you need to maintain is the list of jobs in the server. Each job ischaracterised by two attributes: the time the job arrives at the server and the remaining amountof service the job still needs. Each time when a job arrives or departs, this data structure shouldbe updated. We will explain how this update can be done in a moment.We will illustrate how the simulation of PS server works using “on-paper simulation”. Threeof the quantities that you need to keep track of are: Next arrival time is the time of the next arrival Next departure time assuming no more arrivals is defined as the time of the nextdeparture assuming that no more arrivals will come in the future. For simplicity, we willsimply use the phrase next departure time. For example, if there are three jobs in the serverat a certain time and these jobs still need 5, 6 and 10 units of service, then the next departuretime will be 15 time units later. The list of jobs in the server. Each job is characterised by a 2-tuple. The first element ofthe 2-tuple is the arrival time of the job at the server and the second element is the amountof service it still needs.The “on-paper simulation” is shown in Table 2. The notes in the last column explain whatupdates you need to do for each event. Please note that there are more quantities that you needto keep track of than those three that are mentioned above.A graphical representation of the PS server status over time is given in Figure 3. This graphicalrepresentation is the same as the one used in Lecture 4B to explain how you can calculate thedeparture time of jobs in a PS server. There are three plots in the figure, showing the arrival times,remaining amount of service for each job and the departure times. The figure is best viewed incolour because the quantities related to each job is shown in a specific colour. Note that in betweentwo consecutive events, the remaining amount of service for each job is not a constant. Whatis constant in between two consecutive events is the number of jobs in the server. The numberof jobs in the server determines the service rate of each job which is the slope of the remainingservice curves. You will see that the slope stays constant in between two events and changes eachtime an event occurs.�t = 0 – 1 ∞ – We assume the server is empty at the start of thesimulation and this is indicated by departure timeof ∞.t = 1 Arrival 2 3.1 (1,2.1) Since the event is an arrival, we need to update(i) Next arrival time; (ii) Job list; and (iii) Nextdeparture time. There is one job in the list. Thenotation (1,2.1) means the job arrives at t = 1and at the time of the master clock, it still needs2.1 units of service. If there are no more arrivals,the next departure is expected to be at time 3.1and this is the next departure time.t = 2 Arrival 3 4.2 (1,1.1),(2,3.3)Since the event is an arrival, we need to update (i)Next arrival time; (ii) Job list; and (iii) Next departuretime. Note that for the job list, you needto add the new job to the list and you also need toupdate the amount of service still needed by thosejobs that were in the server before the arrival ofthis job. We now explain how the job (1.2.1) isupdated to (1,1.1). At the time of the last event(which was t = 1), this job needed 2.1 units ofservice. Given that the current time is t = 2,which means 1 time unit has lapsed. Since therewas only one job in the server between t = 1 andt = 2, the job received one unit of service henceits remaining service time is 2.1 – 1 = 1.1. Thismeans that your simulation needs to rememberthe time of the last event.t = 3 Arrival 5 4.8 (1,0.6),(2,2.8),(3,1.1)One unit of time has lapsed since the last eventand there were 2 jobs in the server, so the jobs inthe server received 0.5 units of service each.t = 4.8 Departure 5 5.8 (2,2.2),(3,0.5)Since the event is a departure, you will need toupdate the (i) Job list; and (ii) Next departuretime.t = 5 Arrival 15 6.2 (2,2.1),(3,0.4),(5,0.5)t = 6.2 Departure 15 6.4 (2,1.7)(5,0.1)t = 6.4 Departure 15 8 (2,1.6)t = 8 Departure 15 ∞ –Table 2: Table illustrating the updates in a PS server.5ArrivalsFigure 3: Figure illustrating PS.64.2 Example 2: Simulating the fog, the network and the cloudThis example illustrates the simulation of the fog/cloud system. We label the requests with indices1, 2, 3 and so on; these indices are in the first column of Table 3. The second column of the tableshows the arrival times. The third column shows the amount of processing required and thisamount is measured by the time the request will need if all the processing is done in the fog. Sincethe amount of time is measured with respect to the fog, we refer to it as the service time in thefog time unit.Request Arrival time at the fog Service time in the fog time unit1 1.1 4.12 6.2 5.23 7.4 1.34 8.3 2.05 9.1 3.26 10.1 4.1Table 3: Arrival times and service times in the fog time unit for Example 2.For this example, we assume that the fog will only provide no more than 2 time units of serviceto each request. This means that: If a request requires 2 time units or less service from the fog, then the request will becompleted entirely at the fog. For the requests in Table 3, both Requests 3 and 4 will beentirely completed at the fog. If a request requires more than 2 time units of service from代做COMP9334作业、代写Analytic Model作业、代写Python, C/C++, Java编程作业、代做 the fog, the request will get 2time units of service from the fog. After receiving a service of 2 time units, the request willbe sent to the cloud via the network. The remaining work of the request will be completedat the cloud. For the requests in Table 3, Requests 1, 2, 5 and 6 will each receive 2 timeunits of service at the fog before they are sent to the cloud.In general, we use the parameter fogTimeLimit to denote the maximum amount of service arequest can receive from the fog. For this example, the value of the parameter fogTimeLimit is 2.In order to simulate those requests that are sent to the cloud, we will need their networklatency and the service time they need at the cloud. For this example, the network latency forRequests 1, 2, 5 and 6 are given in the fourth column of Table 4.We will now explain how the service time at the cloud is to be computed. Consider a requestwhose service time in the fog time unit is x where x > fogTimeLimit, the amount of time requiredby this request at the cloud is given by:fogTimeToCloudTime (x fogTimeLimit)where fogTimeToCloudTime is a parameter. In this example, we assume the value of the parameterfogTimeToCloudTime is 0.6. Therefore, Request 1 will need 0.6 ? (4.1 ? 2) = 1.26 timeunits of service at the cloud. Note that the quantity (x ? fogTimeLimit) represents the work thatthis request still needs. This work is measured in terms of the amount of time needed at thefog, but since this work is now to be completed at the cloud and the cloud is a faster computingfacility, so we need to convert the amount work to the time needed at the cloud. We model thisconversion by using the multiplication factor fogTimeToCloudTime. You can expect the value offogTimeToCloudTime is less than 1 because the cloud has a higher processing speed than the fog.By using the setup above, Table 4 shows the actual time each request gets at the fog and theservice time needed at the cloud. Note that the actual time a request gets at the fog (third column7in Table 4) is the smaller of the service time in the fog time unit (third column in Table 3) andthe value of the parameter fogTimeLimit. Note also that the service time needed at the cloud(fifth column in Table 4) is deduced from the service time in the fog time unit, together with theparameters fogTimeLimit and fogTimeToCloudTime.Request Arrival time atthe fogActual servicetime provided atthe fognetwork latency Service time requiredat the cloud1 1.1 2 1.5 1.262 6.2 2 1.3 1.923 7.4 1.34 8.3 25 9.1 2 1.6 0.726 10.1 2 1.8 1.26Table 4: This table shows arrival time at the fog, actual service time provided at the fog, networklatency and service time required at the cloud for Example 2.In the simulation of the fog/cloud system, there are five events:1. Arrival at the fog2. Departure from the fog (without going to the network)3. Departure from the fog to the network4. Departure from the network to the cloud5. Departure from the cloudTable 5 shows the event times in ascending order with an explanation of the events.8Time Request Event1.1000 1 Arrival at the fog3.1000 1 Departure from the fog to the network4.6000 1 Departure from the network to the cloud. Note thatRequest 1 departed from the fog at time 3.1 and thenetwork latency for this request is 1.5, therefore thisrequest departs from the network at 3.1 + 1.5 = 4.6.5.8600 1 Departure from the cloud. Note that Request 1 arrivedat the cloud at time 4.6 and with no other jobsarriving at the cloud when it was served, it departedfrom the cloud at 4.6 + 1.26 = 5.86.6.2000 2 Arrival at the fog7.4000 3 Arrival at the fog8.3000 4 Arrival at the fog9.1000 5 Arrival at the fog9.4333 2 Departure from the fog to the network. Note thatby this time, Request 2 has received 2 (= 1.2 + 0.9/ 2 + 0.8 / 3 + 0.3333 / 4) units of service. Sincethe value of the parameter fogTimeLimit is 2, thisrequest has to depart from the fog.10.1000 6 Arrival at the fog10.7333 2 Departure from the network to the cloud11.2111 3 Departure from the fog12.6533 2 Departure from the cloud14.6611 4 Departure from the fog15.1944 5 Departure from the fog to the network15.5000 6 Departure from the fog to the network16.7944 5 Departure from the network to the cloud17.3000 6 Departure from the network to the cloud17.7289 5 Departure from the cloud. Request 5 requires 0.72units of service from the cloud. At time 17.7289,the amount of service it has received is (17.3000 16.7944) + (17.7289 17.3000)/2 = 0.72.18.7744 6 Departure from the cloudTable 5: The event times for Example 2.94.3 Example 3: Trace driven simulationThis example illustrate the data that you will be given if you are asked to do a trace-drivensimulation. You will be given: The values of fogTimeToCloudTime and fogTimeLimit. For each request, you will be given the arrival time at the fog, service time in the fog timeunit and network latency. Note that for a request whose service time in the fog time unit isno more than the fogTimeLimit, we use a zero network latency to indicate this request willnot be sent to the cloud.The data for this example are:Arrival time at the fog Service time in the fog time unit network latency1 3.7 1.52 5.1 1.44 1.3 05 2.4 06 4.5 1.6fogTimeLimit = 2.5fogTimeToCloudTime = 0.7With the data above, the events in the fog/cloud system are shown in the table below. Notethat we have labelled the requests in the order that they arrive at the fog.Time Request Event1 1 Arrival at the fog2 2 Arrival at the fog4 3 Arrival at the fog5 4 Arrival at the fog5.6667 1 Departure from the fog to the network6 5 Arrival at the fog7.1667 1 Departure from the network to the cloud8.0067 1 Departure from the cloud8.7556 3 Departure from the fog9.3556 2 Departure from the fog to the network10.7556 2 Departure from the network to the cloud11.8222 4 Departure from the fog12.2 5 Departure from the fog to the network12.5756 2 Departure from the cloud13.8 5 Departure from the network to the cloud15.2 5 Departure from the cloudYou can compute the system response times by using the arrival and departure times from thesystem. The following table shows the arrival and departure times that can be used to compute thesystem response times. The mean response time is 7.6720 without considering transient removal.Arrival time Departure time1 8.00672 12.57564 8.75565 11.82226 15.2105 Project descriptionThis project consists of two main parts. The first part is to develop a simulation program for thefog/cloud system which is described in Section 3.2 and illustrated in Section 4. In the second part,you will use the simulation program that you have developed to solve a design problem.5.1 Simulation programYou must write your simulation program in one (or a combination) of the following languages ornumerical package: Python (either version 2 or 3), C, C++, Java or Matlab. All these languagesand numerical packages are available on the CSE system. We will test your program on the CSEsystem so your submitted program must be able to run on a CSE computer. Note that it ispossible that due to version differences, code that runs on your own computer may not work onthe CSE system. It is your responsibility to ensure that your code works on the CSE system. Inparticular, if you plan to use Matlab, you need to know that CSE runs Matlab 2013, which isunfortunately older than expected.We require you to write your simulation program as a function in your chosen language. Yourfunction must have the following seven inputs:1. A parameter mode of string type. This parameter is to control whether your program willrun simulation using randomly generated arrival times, service times and network latencies;or in trace driven mode. The value that the parameter mode can take is either random ortrace.2. A parameter arrival for supplying arrival information to the program. The meaning ofarrival depends on mode. We will provide more information later on.3. A parameter service for supplying service time in the fog time unit to the program. Themeaning of service depends on mode. We will provide more information later on.4. A parameter network for supplying network latency to the program. The meaning ofservice depends on mode. We will provide more information later on.5. A parameter fogTimeLimit to input the value of fogTimeLimit. This parameter is a positivefloating point number.6. A parameter fogTimeToCloudTime to input the value of fogTimeToCloudTime. This parameteris a positive floating point number.7. A parameter time_end which stops the simulation if the master clock exceeds this value.This parameter is only relevant when mode is random. This parameter is a positive floatingpoint number.Note that your simulation program must be a general program which allows different valuesto be used. When we test your program, we will vary the parameter values. You can assume thatwe will only use valid inputs for testing. You can have additional parameters if you wish.For the simulation, you can always assume that the system is empty initially.Note that we assume that it takes negligible time to send the requests to the fog.5.1.1 The random modeWhen your simulation is working in the random mode, it will generate the inter-arrival times,service times in the fog time unit and network latencies in the following manner.111. The inter-arrival probability distribution is exponentially distributed with parameter λ. Thismeans the mean arrival rate of the jobs is λ. You will need to supply the value of λ to yourprogram using the input parameter arrival.2. The service time in the fog time unit t is generated by the probability density function g(t)�Note that this probability density function has three parameters: α1, α2 and β.3. The network latency is uniformly distributed in the open interval (ν1, ν2) where ν2 > ν1 > 0.Note that network latency only applies to requests that are to be sent to the cloud.5.1.2 The trace modeWhen your simulation is working in the trace mode, it will read the list of arrival times, the listof service times in the fog time unit and the list of network latencies from three separate ASCII files.Let us use Example 3 in Section 4.3 for an illustration. The arrival times are [1, 2, 4, 5, 6],the service times in the fog time unit are [3.7, 5.1, 1.3, 2.4, 4.5] and the network latencies are[1.5, 1.4, 0, 0, 1.6]. Your program is required to simulate until all jobs have departed. For thisexample, the last departure occurs at time 15.2 and you can stop the simulation there.We will supply the arrival times, service times in the fog time unit and network latencies toyou using three ASCII files. The names of these three files have specific format, which we willdiscuss in Section 6 on testing. For Example 3 in Section 4.3, the service times in the fog timeunit will be specified by a file whose contents are as follows:3.7005.1001.3002.4004.500where each service time takes up a line of the file. The same format is used for arrival times andnetwork latencies. You can assume that the data we provide for trace mode are consistent inthe following way: (1) The number of arrival times, the number of service times in fog unit andthe number of network latencies are equal. (2) If the service time in fog unit for a request is notgreater than fogTimeLimit, then the corresponding network latency is zero.5.2 Determining a suitable value of fogTimeLimitAfter writing your simulation program, your next step is to use your simulation program to do adesign.For this design problem, you will assume the following parameter values: λ = 9.72, α1 = 0.01,α2 = 0.4, β = 0.86, ν1 = 1.2, ν2 = 1.47 and fogTimeToCloudTime is 0.6.12Your aim is to determine the value (or a range of values) of the parameter fogTimeLimit thatgives the best system response time. Recall from Section 3.1 that we will not get the best overallresponse time if we do all the processing at the fog or all the processing at the cloud. Doing allthe processing at the fog corresponds to setting fogTimeLimit to infinity. Doing all the processingat the cloud corresponds to setting fogTimeLimit to 0. This means that for some non-zero valueof fogTimeLimit, you can get a better overall response time.In solving this design problem, you need to ensure that you use statistically sound methodsto compare systems. You will need to consider parameters such as length of simulation, number ofreplications, transient removals and so on. You will need to justify in your report how you choosethe value or range of fogTimeLimit.6 Testing simulation programAs part of the assessment for this project, you are asked to attend an interview so that we cantest your simulation program. During the interview, we will ask you to run a series of tests. Eachtest is specified by a number of configuration files. For each test, we require four output files ofspecific format so that we can verify the correctness of your simulation program. The aim of thissection is to specify the format of the configuration files and output files.The number of tests that you will need to run is specified in an ASCII file with the namenum_tests.txt. If we want to run 12 tests in the interview, the file num_tests.txt contains thestring 12 only.Each test is specified by 5 configurations files. We will index the tests from 1. If 12 tests areused, then the indices for the tests are 1, 2, ...., 12. The names of the configuration files are: For Test 1, the configuration files are mode_1.txt, para_1.txt, arrival_1.txt, service_1.txtand network_1.txt. The files are similarly named for indices 2, 3, ..,9. For Test 10, the configuration files are mode_10.txt, para_10.txt, arrival_10.txt, service_10.txtand network_10.txt. The files are similarly named if the test index is a 2-digit number.We will refer to these files using the generic names mode *.txt, para *.txt etc.6.1 Wrapper fileWhen you submit your project, you must include a wrapper file which will loop through all thetests. We will use this wrapper file in your interview to run your simulation. The pseudo-code foryour wrapper file is as follows.Read the file num_tests.txt to determine the number of testsFOR test_index from 1 to num_testsRead in the configuration files for the test_indexSet the simulation mode and parameter valuesCall your simulation functionWrite the output files % This can be in the wrapper or your simulation functionThe filename of this wrapper file must be called wrapper followed by the appropriate file extensionfor the language that you used, e.g. wrapper.py for Python.13Note that another purpose of the wrapper file is to show us how to run your code. We may needto run additional tests and the wrapper file will allow us to do that. You should have commentsin the wrapper file to explain to us how to run your code.6.2 Configuration file format6.2.1 mode *.txtThis file is to indicate whether the simulation should run in the random or trace mode. The filecontains one string, which can either be random or trace.6.2.2 para *.txtIf the simulation mode is trace, then this file has two lines. The first line is the value of fogTimeLimit.The second line is the value of fogTimeToCloudTime. If the test is Example 3 in Section4.3, then the contents of this file are:�If the simulation mode is random, then this file has three lines. The first two lines contain,respectively, the values of fogTimeLimit and fogTimeToCloudTime. The last lin转自：http://www.7daixie.com/2019041013143623.html
