NS3中的高速移动模型和车联网

【实例简介】
一篇不错的论文，使用NS3仿真车联网。“highway mobility and vehicular ad-hoc networks in NS-3”。
Arbabi and Weigle customize Highway(including highway length, uni-or bi-directional traffic flow, number of lanes, lane width, and center median width to create a variety of simulation scenarios Vehlcle Model Lane change c|a55 Fields Fields Lane Change vehicles NetDevice Truck Sedan Considerate Inconsiderate Cass Class Cla C ≯Made ≯Mdel H Lane Change → Lane change Obstacle → wehicle Figure 1: Class diagram of the main components in our design In the following sections, we will describe each of the classes in order. The source code, including an example and documentation, is available online (OdU 2010) 2.1 Vehicle a Vehicle is a mobile node that contains a wireless communications device. a Vehicle has the following propcrtics vchicleID width- width of the vehicle in meters length-length of the vehicle in meters lane - lane number on the highway where the vehicle is located direction- -1, 1,(Assume eastbound is l and westbound is-1) position-a vector (, y, z), where x is the rear position of the vehicle, y is the center of the ve- hicle, and z is the altitude of the vehicle above the highway(all units in meters) velocity- in m/s acceleration -in m/s model- mobility model settings, desired velocity is associated with the mobility model lanechange- lane change model settings In our design, the Highway object is in charge of managing the positions, directions, and the lane numbers of its vehicles. A Vehicle's acceleration and velocity can be set manually or can be calculated based on the IDM mobility model rules. a Vehicle is able to change lanes, if necessary and if possible, based on the mobil lane change model. Vehicle objects can either be manually created and inserted onto the Highway or can be automatically injected onto the Highway Since a Vehicle contains a wireless communications device, we can control the vehicle's wiFi capa bilities. Vehicles are able to communicate(send/receive) through the standard ns-3 WiFi channels. The messages,including sent and received packets, and all related events can be captured by setting the ap- propriate event handlers to the implemented callbacks, which are designed and considered for these pur poses A Vehicle can unicast packets or it can send broadcast messages. The user has full control on how to schedule the sending process and how to handle the receive callback there are also several callbacks for the purpose of tracing the different layers of the network and the mobility of the vehicle. These help the user create and trace simulation scenarios easily 2993 Arbabi and Weigle 2.2 Obstacle An obstacle is a static node that contains a wireless communications device. It is inherited from the ve hicle class and has all of the capabilities of a Vehicle except that it cannot be mobile (i.e, velocity acceleration= model= lanechange =0). An obstacle can be used as an barrier to close a lane or to temporarily create stoppages that result in congestion on the highway. An obstacle can also be used as a roadside unit or other picc of infrastructure along, but outside of, the highway. If an Obstacle is placed on the highway, it must have a direction and lane number. Anything that can be done to a vehicle object can be done to an Obstacle object(aside from affecting mobility), so in the rest of this paper we will just use the term vehicle 2.3 Mobility model Model is the class that implements the mobility model for a vehicle. we have implemented the intelligent Driver Model (IDM) in ns-3 based on equations and parameters developed by Treiber(Treiber, Hen necke, and Helbing 2000; Treiber 2006a). IDM is a car-following model, meaning that each vehicles ac- celeration or deceleration depends upon its own velocity, its desired velocity, and the position and veloci- ty of the vehicle immediately in front in the same lane, which Treiber calls the fronl vehicle Each vehicle in IDM has a desired velocity, safety time headway(time needed to cover a gap between two vehicles, e.g., the "2 second rule"), acceleration in free-flow traffic, comfortable braking deceleration and desired minimum distance to the front vehicle. IDM uses these parameters and the current state of the vehicle and front vehicle to compute the new acceleration. acceleration is, in turn, used to update the ve locity and position of the vehicle. Note that acceleration necessarily decreases towards o when the veloci ty of the vehicle approaches the desired velocity. The function CalculaleAccelerulion in the model class uses the idm equations to calculate and return the new acceleration at each time step the vehicle's new velocity and position are then adjusted based on this new acceleration For customizability, each vehicle can have its own set of IDM parameters. Treiber suggests different parameter settings for cars and trucks. For example, trucks have a lower desired velocity, acceleration in free-flow, and comfortable deceleration than cars. "Careful " drivers would have a high safety time head- way, and"pushy"drivers would have a low safety time headway, higher desired velocity, acceleration in free-flow, and comfortable deceleration In our design, we also allow each Vehicle object to have its own IDM parameters. We have included reasonable default values for cars(the Sedan class)and trucks (the Truck class ) The user can create their own vehicle types with different parameter values for specific experiments. For example, a user may want to create a mix of careful and pushy drivers, or include sports cars, police cars, emergency vehicles, and buses, all of which would have very different mobility characteristics 4 Lane change model Lane change is the class that implements the lane changing model for a vehicle. We have implemented the mobil lane change model based on equations and parameters developed by Treiber(Treiber 2006b, Treiber and Helbing 2002). Each lane change in this model must satisfy both the safety criterion and the incentive critcrion. The safety criterion states that the lanc change must not cause the vchicle that is being changed in front of (the back vehicle) to decelerate unsafely(faster than a certain threshold). The incen tive criterion is satisfied if the lane-changing vehicle's advantage is greater than the other vehicles'disad- vantages. Note that although the incentive criterion is usually much easier to satisfy than the safety crite rion, both must hold for the lane change to occur. In addition, the IDM rules still apply, meaning that the new front vehicle must be a certain distance ahead in order for the lane change to occur To compute the incentive criterion, MOBIL first calculates the lane-changing vehicles advantage This is simply the difference between the vchicle's current acceleration and the vchicle's new acceleration after the lane change. The goal is to increase the acceleration, or to reduce the braking deceleration, which 2994 Arbabi and Weigle are essentially the same things. the disadvantage to both the back vehicle in the current lane and the back vehicle in the new lane are considered. Again, this is done by comparing the acceleration before the lane change with the acceleration after lane change To allow for some variability in how aggressive drivers are in deciding when to change lanes, MOBIL weights the other vehicles'disadvantage with a politeness factor, p. When p> 1, the driver is considerate and puts others' disadvantages equal to or ahead of their own advantage. In reality, most driv ers are in the 0<p<0.5 range, where some weight is given to other drivers'disadvantage If p-0, the driver is inconsiderate, discounting the disadvantage to others MOBIL also includes a right-lanc bias parameter when computing the incentive criterion. This para- meter allows for modeling situations in countries where passing a vehicle on the right is not allowed. The parameter can also be used to allow vehicles to pass from either side or prevent trucks from travelling in the leftmost lanes The function Checklane Change in our Lane change class returns a boolean to indicate if the lane change can take place or not. Checklane Change uses the MObiL equations and suggested parameters along with the statuses of the lane-changing vehicle, the current front vehicle, the new front vehicle, and the new back vchicle. As with our IDM implementation, we have included reasonable default valucs for each of these parameters. We provide a Considerate driver class and an inconsiderate driver class. The user can, of course, create their own driver types with different parameters 2.5 Highway Highway is the class that holds Vehicles and manages their mobility. We will discuss Highway's physical properties, Vehicle management tasks, and how users can control vehicles on the highway in order to cus- tomize simulations 2.5.1 Physical Properties Highway represents a straight highway topology and has the following physical properties length-length of the highway in meters(up to 10,000 m) number of lanes-in each direction [1, 5] o lane width- in meters median gap-width of the median, in meters bidirectional -true if the highway contains two-way traffic, false if the highway is one-way Figure 2 shows two example highway configurations. Figure 2a is a unidirectional highway with three lanes, and Figure 2b is a bidirectional highway with four lanes in each direction Figure 2: A small segment of a highway. Cars are represented by small blue rectangles, and trucks are represented by larger red rectangles. (a) unidirectional highway with three lanes,(b) bidirectional high way with four lanes in each direction and a separating median 2995 Arbabi and Weigle 2.5.2 Vehicle management There are several Vehicle management functions that Highway performs. Highway can automatically create Vehicle objects with certain parameters automatically insert these created objects into lanes and move each Vehicle according to its mobility and lane change models 2.5.2.1 Automatic Creation and Injection of vehicles When the Auto Injection parameter of Highway is true, vehicle objects will be automatically created and injected onto the highway. For this purpose, Highway creates default mobility models with parameters sct ppropriately for the standard car and truck, named Sedan Model and TruckModel, respectively. Highway also creates default lane change models with appropriate parameters set for cars and trucks. The ratio of cars to trucks that are created is controlled by the injection Mix parameter. Automatically-created vehicle objects are provided with default WiFi Phy/Mac settings appropriate for VANETS Ilighway stores each lane as a list structure. When a vehicle object is added to Ilighway, it is inserted in its proper place according to its lane, direction, and x position. For auto-injection, there is a min Gap pa rameter that specifies the minimum distance between two vehicles entering the highway. Newly created Vehicle objects are not inserted until the x position of the last Vehicle in the lane is at least min Gap meters from the start of the highway. Vehicles are inserted with a negative x position, so that the front of the ve hicle starts at the start of the highway (x=0). Each lane is checked to see if a Vehicle can be added, in round-robin fashion, starting with the rightmost lane(lane= 0)in the eastbound direction(direction 1)and ending with the leftmost lane in the westbound direction(direction =-l, if using bidi tional traffic). Thus, on a bidirectional highway, vehicles are added to both directions at the same rac rec 2.5.2.2 Mobility of vehicles Every Deltal seconds, Highway calls its step function which updates the position, velocity, and accelera tion of each Vehicle according to its mobility model. In this way vehicles with different mobility charac teristics(e. g, trucks, emergency vehicles) can be represented on the same highway. Vehicles are updated by lane in round-robin fashion, starting with the vehicles in the rightmost lane in the eastbound direction After the update, if a Vehicle's x position is greater than the length of the Highway, the Vehicle is re- moved from the lane list. After all Vehicle positions have been updated, automatic injection of new Ve- hic cles occurs The opportunity for each vehicle to change lanes is evaluated every 10* DeltaT seconds to prevent unrealistic lane-changing patterns(e. g, vehicles changing lanes multiple times in less than I second). If a vehicle can safely change lanes(according to the vehicle's MOBIl parameters), Highway removes the Vehicle from the current lane and adds it to the target lane at the x position specified according to IDM/MOBIL. When a lane change is allowed, it occurs before mobility is updated, so a Vehicle changing lanes only has its mobility updated one time in Deltar seconds The best case driver reaction time is 0. 7 seconds(Green 2000). Vehicle positions should be updated more often than the driver reaction time and we choose 0. 1 seconds for the default value of deltat as a tradeoff between efficiency and accuracy. Reducing Deltar(i. e, having the step function called more of ten) will produce a more detailed translation of the position of the vehicle, but will result in a slower si- mulation( Figure 3). Increasing DeltaT(i.e, having the step function called less often)will cause less ac- curacy in mobility since each step may result in a larger displacement of the vehicles(figure 4 2.5.3 User Control of vehicles To allow for feedback between the network and the mobility model, there must be a way for the users application code to interact with individual vehicle objects. Highway allows the user to access any ve 996 Arbabi and Weigle hicle object through its Vehicleln using Findvehicleo. The user can then use this object to change any of the Vehicle's parameters. In addition, Highway provides find vehicles nranged which returns a list of all Vehicle objects within range meters of the given Vehicle. Find yehiclesinsegment( returns a list of all Vehicle objects in a particular lane between positions x, and x2. To access these Vehicle objects at particu lar times, Highway triggers several events that can be bound to an event handler created by the user. The events InitVehicle. ControlVehicle. and ReceiveData are discussed below. In addition there are several other events, such as DevRxTrace and PhyRxErrorTrace, for the purposes of tracing the communication channel, the PhY/MAC layer, and the behavior of the network devices installed on vehicles sAltatO ol DeltaT=01 DeltaT=0.7 15 Deltata10 05 051015202530354045556 Simulation Time[ seconds Figure 3: The elapsed real time for 1 minute of dense traffic simulation(average 180 vehicle/km) DeltaT=005 2 -DEItaT0.I E20 DEltaT=0.5 E - DeltaT=10 Figure 4: A vehicle's displacement vs. velocity in a single simulation step with different DeltaT values Initvehicle is triggered at Highway initialization time. This gives the user the ability to create custo mized scenarios or modify the initial settings. Although the user can create and position Vehicle objects at any time, inside this event handler is the ideal place to create and place initial objects on the highway. If Autoinjection is set to true in Highway, automatically-created vehicles will move around the previousl placed Vehicles. The event handler is passed a pointer to the llighway and a reference to a vehiclelDd(set to l initially). Any manually-created Vehicles should use and increment this vehiclelD so that all objects will have unique IDs. Note that any manually-created vehicles will be controlled by Highway according to the vehicles mobility model. The event handler should return true if vehicles have been manually added to the Highway or default settings have been modified. In this case, Highway will sort the lane lists based on the vehicle positions. If no Vehicles have been added, there is no reason to sort the lists, so the event handler should return false For each Vehicle, Controlvehicle is triggered by the step function, which is executed every DeltaT seconds. In this way, the user has full control of each Vehicle at each time step For example, a particular 2997 Arbabi and Weigle Vehicle could be made to decelerate or stop in order to create traffic congestion. In addition, this event handler is an ideal place to output the locations of all Vehicles in order to produce traffic visualizations The event handler is passed a pointer to the Highway, a pointer to the particular Vehicle, and the value of DeltaT. If the event handler has changed the Vehicles position, it should return true, so that the vehicles acceleration will not be updated by the mobility model. Otherwise, the event handler should return false so that Highway will adjust the Vehicle's position according to its mobility model ReceiveData is triggered when any Vehicle successfully receives data from the network. The event handler is passed a pointer to the vehicle that received the data, a pointer to the data packet, and the ad dress of the packet's sender 3 CUSTOMIZATIONS We provide a basic framework for a straight highway scenario and tools for generating communicating vehicles traveling with a realistic mobility. There are many possible customizations that can be made us ing this framework. We describe a few customizations that can be made with Vehicle objects any vehicle can be associated with a parameterized mobility or lane-change model. This allows the user to create simulations that contain various types of vehicles. For example, a police car is a vehicle that during a chase has a higher desired speed and acceleration than a normal vehicle. In addition, the user could set the networking parameters such that the police car also has a more powerful transceiver than a normal vehicle. In another instance, a helicopter used to transmit advertisements, warnings, or reports could be simulated as a Vehicle with a positive z value(altitude). Since the helicopter does not travel on the highway, it should not be added to or managed by Highway. Instead at every time step(i.e, in the ControlVehicle event handler), the helicopter's position should be updated manually. Stationary roac ldside units, such as digital guides, placed outside the highway can be created using Ob stacles. As with Vehicles that are outside the highway, these devices should not be added to Highway. As another example, a gantry on top of a highway could be represented as an Obstacle with a positive z val- ue. Sensors under the road could be obstacles with negative z values. These devices may have different communications requirements than standard vehicles, so the user is free to adjust the network parameters as well 4 VALIDATION In this section, we validate our implementation of IDM/MObIL in ns-3 against Treiber's own implemen tation of IDM/MOBIL in a Java applet (Treiber 2010). The first step is to validate that the functions Mod- el: CalculaleAccelerutiono and Lune Change. CheckLane Changeo produce output correctly in compari- son with Treiber's formula, model, and code individually with various input and mobility model settings The second step is to produce simple traffic in a one lane roadway and compare the vehicle's acceleration, deceleration, velocity, and position at each simulation interval. Finally, we need to show that despite the difference in our design and the logic of step function, we are able to create traffic similar to that created by Treiber’ s applet. The first two steps have been performed during code implementation and testing. We omit these for brevity. Here we show the results of the third step of validation. We use Treiber's Java applet to produce traffic on a straight two lane roadway for several traffic inflow rates. We record traffic statistics(simula- tion time, vehicle type, acceleration, velocity, position, and lane) at two points. Point a is the roadway en trance, and point B is 500 m from the entrance. We apply the generated traffic recorded at point A in Trei ber's applet to our ns-3 simulation and record the traffic statistics at point B. This is to mitigate the different injection models used by Treiber's applet and our code. We compare the traffic at point b in Treiber's applet with the traffic at point B in our ns-3 code during a 5 minute simulation. Figure 5 shows the average traffic density over the 500 m as the traffic inflow rate increases and with different desired speeds. The results between the two applications are almost identical. Figure 6 shows the average differ ences in position and speed between the two applications for each vehicle as it passes point B. Again, 2998 Arbabi and Weigle there is very little difference between the two. The position differences are less than 7 mm, and the speed differences are less than 1 cm/s O5 m/s ns-31 口15 m/s[ ns-3 X15m/s [ Treiber 因 1000 2000 2500 Figure 5: Comparison between average density results of our code in ns-3 and Java applet for different traffic inflow and different desired velocitv 001 0038 a0.004 1500 Flow(vehicle/hour) Figure 6: Average difference in position(m) and average speed(m/s) between ns-3 version and Treiber Java applet for different traffic densities 5 EXAMPLE We have provided an example to show how to create a customized highway, set parameters, handle events, and control which vehicles send and receive customized messages. This example, available online (OdU 2010), demonstrates how a user can have full control of events to produce the desired scenarios and experiments. The example generates output suitable for plotting vchicle positions using gnuplot or other graph-plotting tool We have created a Controller class to handle events and create special vehicles. The highway is a bi- directional 1 km roadway with two lanes in each direction The lane width and median width are both 5 meters. The sedan-truck mixture is 80%0 so 80% of vehicles are sedans and 20% are trucks, Automatical- ly-generated vehicles will enter and be injected to the highway with at least a 10 meter gap We place a broken car(Obstacle object) in the middle of the highway (lane=0, direction=l, x=500) which broadcasts a safety message revealing its location and asking for help every 5 seconds. We also create a police car with a VehiclelD of 2. The police car is faster than a normal car and has a higher wireless transmission range. It listens for messages and unicasts a reply for each received request. The police car will decelerate when it reaches the broken car and will eventually stop nearby The generated output points can be directed to gnuplot to be plotted and animated. Figure 7 shows the gnuplot snapshot after 2 minutes and 40 seconds of the simulation. The police car reached the broken car nt 500 meters after 20 seconds and stopped in the second lane, causing congestion 2999 Arbabi and Weigle 十十十 Police ++HHH+++H+H++ en can Figure 7: A sample plotted highway output for a 1000m roadway with two lanes in cach direction. This snapshot is taken at time 2 minutes, 40 seconds. The police car has stopped in the lane next to the broken car at time 20 seconds, causing the congestion behind it Below, we show a skeleton of a Controller class and maino function. Comments that are shown in italics are placeholders for user-defined code Controller. h class Controller public object private: Ptr<highway> O七her1oCa1 variables publi Controller oi Controller (Ptr<Highway> highway) l/ event handlers bool Initvehicle (ftr<highway> highway, int& vehicleID) bool Controlvehicle (Itr<Highway> highway, Ptr<vehicle> vehicle, double dt) void RcccivoData (Ftr<vchiclc> vch, ptr<const Packct> pct, Addrcss addr)i othcr function declarations Controller.cc Controller:: Controller(i] Controller:: Controller(ptr<Highway> hi ghway)im highway highway j bool Controller:: InitVehicle(Ptr<Highway> highway, int& vehicleID) // objects to create, settings to change at highway initialization time eturn true; , let Highway sort vehicles in highway la bool Controller:: C olVeh-cle(Ptrshigh Ptr<vehicle h double dt) // actions that should occur each time this vehicle's mobility is updated return false / let Ilighway manage the mobility of this vehicle oid Controller:: ReceiveData(Ptr<vehicle> veh, ptr<const Packet> pckt addr) that should h time a ge isr 3000 【实例截图】
【核心代码】