## 5 Simulations  
### Simulation Setup  
As shown in Figure 8, we use the 10524 \(\times\) 6924 m\({}^{2}\) experiment area to perform our simulations in this paper. This area includes part of the urban map of Taipei, Taiwan and contains forty road segments and twenty-five junctions. Assume four RSUs at different junctions regularly broadcast content pieces that are encoded by SLNC from a file. This experiment adopts two simulation tools. The first one is the Simulation of Urban Mobility (SUMO) tool [37], which creates 216, 867 and 3468 randomly distributed vehicular nodes and their corresponding trajectories based on the car-followingmodel. The instant velocity and speed acceleration of every vehicle are uniformly distributed in the interval (0, 15) m/s and (\(-\)0.5, +0.5) m/s\({}^{2}\), respectively. Afterward, we use the popular network simulator, NS-2.34 [38], to execute simulations for the SLNC-based CCD procedures, according to simulation parameters listed in Table 4. Assume every vehicular node and RSU adopt IEEE 802.11p and the Nakagami physical propagation model [39] where the energy detection range (ER) the data communication range (CR) are 700 m and 250 m, respectively. For fair comparisons in this paper, we use the same SLNC parameter values as those in CodeOn [18]. First, we adopt 3 Mbps and 12 Mbps to be the base rate for broadcasting beacons in the control channel and the data rate for forwarding SLNC-coded content pieces in the service channel, respectively. Time slots of both control and service channels are 50 ms. Moreover, the number of content pieces in a SLNC generation, the initial TTL value, the size of a SLNC-coded content piece and the output queue length of each vehicular node are 32 content pieces, 60 s, 1 Kbytes and 100 content pieces, respectively. Finally, \(\Delta t_{max}\) and \(T_{j}\) in Equation (2) are set as 2 ms and 100 \(\upmu\)s, respectively. Figure 8: The experiment area used in simulations. In this paper, we will compare four schemes for evaluating their performance on stimulating content-sharing incentives for twenty runs as follows. The first two schemes are SocialCode (SC) and its variation, that is, SocialCode without Dynamic priority (SC without DP). The third and fourth ones, that is, RCM + CodeOn and FRAME + CodeOn, are two combinations of the traditional SLNC-based CodeOn and two credit-based incentive schemes, that is, RCM and FRAME, respectively. Please note that simulation results of RCM + CodeOn and FRAME + CodeOn in Figures 9-14 are denoted as RCM and FRAME respectively due to the limited space in these figures. Here, we compare three performance metrics of these four schemes with respect to three different file sizes, that is, 10, 6 and 2 M bytes (MB) and three different numbers of vehicle nodes, that is, 3468, 867 and 216, where 6 MB and 867 nodes are their default values in simulations. The probability for every vehicular node to become one of the intermediate, destination and overhearing nodes is equal. Each node has the same initial credit (\(\gamma\) = 50). Both RCM + CodeOn and FRAME + CodeOn set one unit of reward as 0.2. FRAME + CodeOn further fixes its probability to win the sweepstake and its extra sweepstake reward as 0.5 and 0.1, respectively. We also assign 0.2, 0.04, 0.01 and 0.5 to be the default value of \(\alpha\), \(\beta\), \(\delta\) and \(\omega\), respectively, as done in FRAME. Definitions of these three metrics are listed as follows. 1. _Average decoding percentage_: this metric represents the average of the percentages to decode SLNC-coded content pieces back to the original file for all destination nodes as the time elapses;
2. _Average file downloading delay_: this metric denotes the average of all elapsed time for the destination node to decode content pieces back to the original file completely;
3. _Average credits_: this metric expresses the average of all credits owned by the intermediate, overhearing and destination nodes as the time elapses.