Proceedings Template - WORD - Twente Student Conference on IT

More documents

Recommendations

Info

3.1 Simulation Environment The simulations are executed in OMNeT++ [14] in combination with MiXiM [13]. OMNeT++ is an open source discrete event simulation environment which can be used for modelling wireless communication networks [14]. MiXiM is used as an expansion for OMNeT++ to implement a wireless and mobile network, like a VANET. With OMNeT++ and the MiXiM framework the IEEE 802.11p and the IEEE 1609.4 multichannel operations are implemented. In the simulations it is assumed that all the nodes are within each other’s range and their position does not change. All nodes are visible to each other so in this situation no hidden terminals exist. The nodes are uniformly distributed in an area smaller than the communication range. Due to the simplified propagation model, relative position and distances between nodes have no impact. Also it is assumed that the communication channel (CCH) is a ‘perfect channel’, so no bit errors can occur during transmission. This means that packets can only be lost during a collision. This is not how VANETs will operate in the real world, but it gives insight on the beaconing performance when different buffering/queuing-mechanisms and different channel switching methods are used. 3.1.1 Simulation scenarios/modes Two main simulation scenarios/modes are used and analysed in the simulation experiments. The scenario that implements the operation of the CCH as defined in IEEE 802.11p, where a transmitting node uses 100% of the time the CCH for beaconing is denoted as continuous scenario. The scenario wherein a node switches every 50 milliseconds between the CCH and the SCH, as specified in IEEE 1609.4 is denoted as alternating scenario. 3.1.2 Simulation parameters The simulation experiments are performed using the following parameters: - Beacon generation rate: For safety messages it is assumed that 10 messages per second are sufficient to provide a cooperative awareness [5]. The mean beacon generation rate is 10 Hz. In the continuous scenario the generation of beacons is uniformly distributed. In the alternating scenario beacon generation is restricted to a uniform distribution within the CCH guard and CCH periods, minus the duration of one transmission. This method is similar to the one used in [2], see Eq. 1. Unif(0, T cch – T s ) (1) Where, T cch stands for the CCH interval time, namely 50 ms. and T s for the duration of the transmission of one beacon, see [2]. - Data rate: In the simulations a data rate of 3 Mbit/s is used for all nodes, the lowest data rate defined in IEEE 802.11p. Given the critical nature of the communicated information, the most robust modulation is assumed. - EDCA class: EDCA class 0 (Background traffic, see Table 1) is used in the simulations. The EDCA 0 class has the largest contention window CW min, namely 15, see Table 2. This gives transmitted beacons the smallest probability of collisions due to simultaneous expiration of backoff counters, see [15]. - Beacon size: As stated earlier, a typical beacon has a size of 400 bytes, including security fields. This beacon size is therefore used in the simulations. - Scheduling: There exists two popular scheduling mechanisms, namely First-In, First-out (FiFo) and Last-in, Last-out (LiFo). In a FiFo scheduler packets are transmitted in the order as they arrived. On the contrary, with a LiFo scheduler newly arrived packets are transmitted first. From [6] it can be concluded that it does not really make any difference which of the two mentioned scheduling mechanisms (LiFo or FiFo) is used. For this reason a FiFo scheduler is used in the simulations as this is also the standard scheduling mechanism used in EDCA. - Number of nodes: The simulations are performed using a different number of nodes to simulate different vehicle densities. The number of nodes ranges from 10 to 120 nodes, where 120 nodes is a realistic number of nodes during rush hour on a highway, within transmission range Note that for the continuous scenario 160 and 200 nodes were also considered. - Queue size: The simulations are performed with different queue sizes to analyse the buffering performance. The maximal queue size ranges from 1 to 5 packets. - Buffering mechanism: To analyse which buffering mechanism perform best two buffer mechanisms are compared, namely Oldest Packet Drop (OPD) and Newest Packet Drop (NPD), see [6]. With OPD the oldest packet in the queue is dropped when the queue is full in order to make room for a newly arrived packet. With NPD however, the newly arriving packet is dropped if it finds the queue full. This is the default tail-drop policy adopted in many implementations. - Propagation model: The freshness of a received beacon depends on several components, such as queuing delay, contention delay and transmission delay. In these experiments all generated beacons have the same length, so the transmission delay becomes a constant. Because of the fact that all nodes in a VANET are relative close to each other, the propagation delay is negligible. Parameters not listed in Table 2 or 3 can be found in the IEEE 802.11p [11] or IEEE 1609.4 [10] specifications. Parameter Beacon generation rate Data rate EDCA class Beacon size CW min Scheduling Simulated time limit Parameter Number of nodes Queue size Buffering Mode Table 2: Simulation parameters Value 10 Hz 3 Mbit/s AC0 400 bytes 15 FIFO 200 seconds Table 3: Varied parameters Value [10, 20, 30, 40, 60, 80, 120, 160, 200 (Only for Continuous mode)] [1, 2, 5] [NPD, OPD] [Continuous, alternating]
3.2 Performance Metrics To analyse the beaconing performance, multiple performance metrics can be used. The following subsections describe the performance metrics used in this research. 3.2.1 Reception probability This metric indicates the probability that a beacon, once transmitted, is successfully received. As more nodes in the system exist, the more beacons are broadcast on the CCH channel per second. As the number of beacons transmitted increases, the collision and dropping probabilities increase. The reception probability is calculated by measuring the total number of received beacons and dividing it by the total number of transmitted beacons. 3.2.2 End-to-end delay (Freshness) As the number of beacons transmitted increases, the network channel becomes more congested and so the contention delay increases. It is important that the end-to-end delay of beacons is not too high in order to make sure that the other nodes receive ‘fresh’ information from the sending node. To compute the delay of beacons, the sending node adds a timestamp to the beacon when it begins contention of this beacon. In the simulations all nodes use the same clock, so their timers are perfectly synchronized. In this way the receiving node can subtract the timestamp of the received beacon from the current time in order to compute the beacon end-to-end delay or freshness. The average end-to-end delay is calculated by summing up the end to end delays of all beacons received by all nodes and dividing it by the total number of received beacons. 3.3 Simulation results and analysis In this section the results of the simulation experiments are reported. In order to calculate the 95% confidence intervals of the presented results, each simulation experiment is run several times. For all performed experiments, the calculated 95% confidence intervals are lower than ±5 % of the shown calculated mean values, and are omitted from the plots for readability. 3.3.1 Reception probability As discussed earlier, the load on the channel increases as the number of nodes increases. This results in more collisions and the dropping probability will increase. In the simulation experiments this effect is very noticeable. In Figure 7, the reception probability is plotted against the number of nodes for a queue length of 1, when (1) both the buffering mechanisms, OPD and NPD and (2) both continuous and alternating scenarios are used. It can be seen that there is no difference in reception probability for the two studied dropping mechanisms, OPD and NPD. An explanation for this result is that the circumstances in the simulations with respect to the channel load are equal. So all frames suffer from the same collision probability and queue drop as other frames, no matter how old the frame is. Also, the dropping of frames due to a full queue was only observed for the alternation scenario with a queue size of 1. This resulted in at most 6% loss for 120 nodes. On the other hand, the use of the continuous or alternating scenario has a significant impact on the reception probability. In the case the alternating scenario is used the reception probability is lower than in the case the continuous scenario is used, starting from a topology that incorporates more than 10 nodes. This observation was expected and is due to the fact that the effective load on the channel significantly increases when the alternating scenario is used, since a node has to transmit the same number of beacons in less than halve the time compared to the continuous scenario. This results in a reception probability which appears to decrease twice as fast for the alternating scenario. Figure 7. Reception Probability for continuous/alternating scenarios, with OPD, NPD, and queue length of 1. Figures 8 and 9 show the reception probabilities for all number of nodes and queue sizes for the continuous and alternating scenario respectively. From these figures, it can be concluded that also the queue size has a negligible effect on the reception probability. A node sends only 10 beacons per second. As long as the channel is not saturated it can transmit its beacon before arrival of the next, so the buffer hardly contains more than one beacon. As mentioned above, frame were only dropped in the alternating scenario for a queue size of 1. Therefore the buffer size and its effect on the dropping of frames does not affect the reception probability, the impact for Q=1 is barely visible in Figure 9. 3.3.2 End to end delay (Freshness) Figure 10 plots the average end-to-end delay (freshness) against the number of nodes, for a queue size of 1 and when (1) both the buffering mechanisms, OPD and NPD and (2) both continuous and alternating scenarios are used. As expected, the average beacon end to end delay increases as the number of nodes increases. When the alternating scenario is used, the average beacon end to end delay increases much faster than the continuous scenario. This is because in the alternating scenario nodes have to send the same number of beacons in half the time, resulting in a much larger congestion of the channel. Again the buffer mechanism used, OPD or NPD, does not have a significant impact on the average beacon end-to-end delay. Figure 11 shows the average beacon end-to-end delay against the number of nodes, for a queue size of 5 and when (1) both the buffering mechanisms, OPD and NPD and (2) both continuous and alternating scenarios are used. Compared to Figure 10, it can be concluded that the queue size does not have a significant impact on the average beacon end-to-end delay. Surprisingly, for the alternating scenario the end-to-end delay decreases as the number of nodes is greater than 60, as seen in Figures 10 en 11. The delay is even lower for the alternating sending scenario compared to the continuous scenario when more than 120 nodes are using the channel. This effect can be explained if the results are compared to the results presented in Figure 7. Only packets that are received successfully have an end-to-end delay. This means that, due to the congestion of the channel, only the beacons with a small end-to-end delay will complete transmission. The result is a decrease of end-to-end delay, but fewer beacons complete transmission. The same
Page 1 and 2: Impact of IEEE 1609.4 channel switc
Page 3: choosing different values for the c
Page 7 and 8: continuous scenario, it can be conc
Page 9: ecause the channel is saturated bef

Proceedings Template - WORD - Twente Student Conference on IT

Create successful ePaper yourself

Delete template?

Save as template?