In order to increase the usability of NCTUns in terms of the support for wireless vehicular communication network, several improvements are still underway and will be available in the future releases.
• Traffic Signal
Currently, the only supported traffic signal type is traffic light. Other different types of traffic signals should also be provided to support more realistic road network environments, such as the stop sign and speed limit sign. This im-provement includes not only the GUI functionalities for setting up these traffic signals in a road network, but also the car agent’s driving logic that has to react to these newly supported traffic signals.
• Centralized Traffic Light Control
Regarding the current implementation of the signal agent that controls a group of traffic lights, a signal agent does not cooperate with other signal agents during simulation. However, in the real life, the centralized traffic light control is common, especially on those roads with heavy traffic load. The goal of the centralized traffic light control is to control the signal statuses of a set of traffic light groups to efficiently direct heavy traffic flows. To support this kind of control, NCTUns may involve a new communication channel among signal
agents or a new type of signal agent that controls a set of traffic light groups instead of just one group. Besides, more complex control mechanism has to be provided for users to specify their desired operations on the traffic light control.
• Road Infrastructure
Currently, only some fundamental road types are supported for users to con-struct road networks. Although many road network environments can be constructed by these fundamental roads, other road infrastructures are still required for more accurate road network representation and reflecting the real-world environments, such as the circular roads, the left-turn dedicated lane at intersections, the toll stations on freeways, and so on. These road infrastruc-tures are required because they affect the vehicular movement during simu-lation. With more complex road networks being supported, the microscopic vehicle mobility model also has to be improved to support new road network environments. For example, when approaching a toll station on a freeway and finding that there is a long waiting line ahead, some drivers not only slow down their vehicles but also change to an adjacent lane with a shorter waiting line. It is clear that a more intelligent microscopic vehicle mobility model is required to simulate these behaviors.
• Platoon of Vehicle
According to the studies published in [36] and [37], one finding shows that in VANET a viable multi-hop routing path usually has limited length in hop count (say, less than ten hops). The result indicates that some VANET appli-cations are only viable when they are applied on the moving vehicles always close to each other. A platoon of vehicle fits this requirement. Thus, the sim-ulation of platoon movement is required. Within a platoon, a vehicle has to follow its front vehicle (if any) and also wait its rear vehicle (if any). Besides, all vehicles belonging to the same platoon have to move along the same path.
The support of the platoon simulation can provide those platoon applications a very useful testing environment.
• Network Protocol and Channel Model
As of writing this disseration, the IEEE 802.11p/1609 communication technol-ogy proposed for wireless access in vehicular environments has been supported in the NCTUns platform. Besides, the IEEE 802.16e communication standard proposed for mobile WiMAX environments has also been supported. Based on the support of vehicular communication protocols, we have conducts some research and the results have been published [38, 39]. Currently, the IEEE 802.16j standard proposed for multi-hop relay in WiMAX environments is un-der development, including the implementation of new MAC- and PHY-layer modules. The requirements for emerging network protocols and wireless chan-nel models are endless. NCTUns will keep updating its simulation capabilities with new communication technologies.
• Module-based Vehicular Mobility Control
As that shown in Figure 4.5, a car agent is an independent user space pro-cess. As the number of vehicles deployed in the road network increases, the number of car agent processes also increases during simulation. Thus, during simulation the CPU context switching between the simulation server process and the car agent processes becomes more frequent. This is one consider-able overhead with respect to the simulation speed. Besides, the increasing frequency of database accessing from the car agents to the command server results in more communication overhead. This considerable overhead includes the request/reply data copy between the user space and the kernel space and the TCP protocol operations to deliver the request/reply packets.
In order to eliminate the overhead, a new design to replace the car agent is proposed, called the module-based vehicular mobility control. The concept of the new design is to transplant a car agent into a protocol module located in
MNode
Figure 7.1: The module-based vehicular mobility control
the simulation server. In Figure 7.1, one can see that no car agent exists in this new architecture. Instead, a new type of protocol module, called Vehicular Mobility module, is placed on the top of each mobile host’s Interface module.
Comparing Figure 7.1 with Figure 4.5, the virtual time based network packet transmission path is almost the same except that the packet sender/receiver is now a protocol module instead of a car agent process. In addition, no real time based request-reply communication is needed. Instead, it is replaced with the intra-process function call within the simulation server.
Using the module-based design, we can expect significant speed-up on the
simulation speed. Besides, this design can be applied on a signal agent. In this case, a signal agent is transplanted into a protocol module, called Signal module, located in the simulation server. The module-based signal control can facilitate the above-mentioned centralized traffic light control because it is convenient to synchronize a set of traffic light groups when they are all located within the simulation server process.
Because the simulation server process does not represent any simulated node, the node identification number in its corresponding kernel-space task struct is zero. As stated in Section 3.5.5, when a socket is opened within the simulation server process, the node identification number in the socket’s corresponding kernel-space sock is also zero. In other words, the kernel does not recognize the simulation server as a virtual time based NCTUns process. Thus, by default, any socket opened in the simulation server process is based on the real time.
However, in Figure 7.1, the network packet sockets should be based on the virtual time. To solve this problem, the simulation server should masquerade as if it belongs to some simulated node before opening a network packet socket.
For example, in Figure 7.1, before the simulation server opens the network packet socket in Mobile Host 1’s Vehicular Mobility module, it first calls a customized system call to set its tasks struct’s node identification number to Mobile Host 1’s node identification number. The system call is the same as that mentioned in Section 3.5.4. When the network packet socket is opened, its corresponding sock’s node identification number is equal to Mobile Host 1’s node identification number. The kernel then treats it as a NCTUns socket and operates it based on the virtual time. After the socket is opened, the simulation server has to call the same system call to set its tasks struct’s node identification number back to zero.
In addition, the protocol module programming is a bit different from the in-dependent process programming. For example, a process can call a blocking read() or write() system call to read from or write to an opened socket, but
this kind of system call can not be used within a protocol module. This is because when a blocking system call is called within a protocol module, the whole simulation server may be blocked on that socket and be put to sleep by the kernel. The blocked socket may be waiting for some incoming data that is supposed to be sent from another socket that is also opened in another protocol module. This results in a dead lock situation. Another example is that calling the sleep() system call, based on the real time, is useless within a protocol module. Because when the whole simulation server is put to sleep by the kernel, no one is responsible to advance the virtual time. Thus, when the simulation server wakes up, the simulated virtual time is still the same as that when it was put to sleep. Yet another example is that no infinite loop can be used within a protocol module. The infinite loop makes the whole simulation engine get stuck in the module forever.
The above-mentioned forbidden usages of some function calls or programming syntax can be solved by using some replacement. For example, one can use the non-blocking system calls to replace the blocking system calls. One can use the protocol module event or timer, mentioned in Section 3.5.2, to replace the sleep() system call. In addition, one can also use the protocol module timer to imitate the infinite loop. Although in some case the imitation of the agent’s processing procedure can not be exactly the same as that of the agent process, we think these alternative implementations are still acceptable for obtaining significant simulation speed improvement.
Chapter 8 Conclusion
In this dissertation, we present a software simulator, called NCTUns. NCTUns is an open source tool that integrates communication/network simulation with road/traffic simulation for wireless vehicular communication network research.
We first introduce the original architecture of NCTUns, which is designed to support communication protocol simulations. In addition to the NCTUns’ major components and the execution procedure of these components, several design and implementation issues are illustrated, including the kernel re-entering simulation methodology, the specific routing scheme, the IP address translation, the discrete-event simulation engine, and the port number translation.
Based on the original architecture, we then present the extended architecture of NCTUns, which is developed to further support vehicular network simulations.
The design and implementation issues on these extensions are illustrated, including the GUI extension, the simulation server extension, the car agent, and the signal agent. Besides, we also explain the utilities provided to facilitate the operations of conducting simulations, such as road network construction, vehicle deployment, car profile setting, and network protocol setting.
Next, we test the vehicular mobility control with respect to the reaction to traffic light signal and the car following behavior. Our tests show that the simulated vehic-ular moving behavior is consistent with that derived from the theoretical formulas.
This confirms that the information update between a car agent and the simulation engine or between a signal agent and the simulation engine are completed in time.
Finally, we evaluate the simulation speed and the physical memory usage under different simulation scales. Our evaluations shows that the increase of the number of deployed roads does not affects the simulation speed significantly, while the increase of the number of deployed vehicles does. The simulation results show that in the case with 850 vehicles, the advance of the simulated virtual time is 63 times slower than the advance of the real time.
Since NCTUns was first released in 2002, we have continually updated its capabil-ities to support new communication protocols and more user-friendly GUI facilcapabil-ities.
Besides, we have kept maintaining the NCTUns forum [41] to interact with NCTUns users, such as answering the questions about the usage of NCTUns, inspecting the reported bugs and fixing them if they do exist, etc. As of May 25, 2009, according to the download user database, more than 14,603 people from 132 countries have registered at the NCTUns Web site [9] and downloaded it to use. Some of these users also have published their research results on international journal or conference papers [40]. The above achievement shows that NCTUns has become a reliable and useful research tool for many researchers around the world.
Regarding the support of the vehicular network simulation, we have expanded the usability of NCTUns to the wide-ranging ITS research fields. After the capa-bilities of the vehicular network simulation were released, several users have con-tacted us asking the usage and functionalities of the NCTUns vehicular network simulation. The users’ requirements and feedback give us stronger motivation and practical developing directions to keep improving NCTUns. We believe that in the future NCTUns will be more and more useful for users to conduct wireless vehicular communication network research.
Bibliography
[1] “IEEE 802.11p/D3.0: Draft Standard for Information Technology - Telecommu-nications and information exchange between systems - Local and metropolitan are networks - Specific requirements - Part 11, Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications,” IEEE Standards Activities Department, July 2007.
[2] “IEEE 1609.1 Trial - Use Standard for Wireless Accesses in Vehicular Envi-ronments (WAVE) - Resource Manager,” IEEE Vehicular Technology Society, October 2006.
[3] “IEEE 1609.2 Trial - Use Standard for Wireless Accesses in Vehicular Envi-ronments (WAVE) - Security Services for Applications and Management Mes-sages,” IEEE Vehicular Technology Society, October 2006.
[4] “IEEE 1609.3 Trial - Use Standard for Wireless Accesses in Vehicular Envi-ronments (WAVE) - Networking Services” IEEE Vehicular Technology Society, October 2006.
[5] “IEEE 1609.4 Trial - Use Standard for Wireless Accesses in Vehicular Envi-ronments (WAVE) - Multi-channel Operation,” IEEE Vehicular Technology Society, October 2006.
[6] “IEEE 802.16e-2005 - Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems - Amendment 2: Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands,” IEEE Standard for Local and metropolitan area networks, February 2006.
[7] S.Y. Wang, C.L. Chou, C.H. Huang, C.C. Hwang, Z.M. Yang, C.C. Chiou, and C.C. Lin, “The Design and Implementation of the NCTUns 1.0 Network Simulator,” Computer Networks, Vol. 42, Issue 2, June 2003, pp. 175-197.
[8] S.Y. Wang, C.L. Chou, C.C. Lin, “The Design and Implementation of the NC-TUns Network Simulation Engine,” Simulation Modelling Practice and Theory, 15 (2007) 57-81.
[9] NCTUns Network Simulator and Emulator, available for download at http:
//NSL.csie.nctu.edu.tw/nctuns.html.
[10] The Network Simulator - ns-2, available at http://www.isi.edu/nsnam/ns.
[11] The QualNet software, available at http://www.scalable-networks.com/.
[12] The OPNET modeler, available at http://www.opnet.com/.
[13] R. Barr, “Java in Simulation Time / Scalable Wireless Ad hoc Network Simu-lator,” available at http://jist.ece.cornell.edu.
[14] The ptv simulation - VISSIM, whose reference link is http://www.english.
ptv.de/cgi-bin/traffic/traf_vissim.pl.
[15] The TransModeler traffic simulator, whose reference link is http://www.
caliper.com/transmodeler/.
[16] The SUMO traffic simulation package, available at http://sumo.
sourceforge.net/index.shtml.
[17] A real-time freeway traffic simulator - FreeSim, available at http://www.
freewaysimulator.com.
[18] A microscopic traffic simulation model - CORSIM, whose reference link is http:
//www-mctrans.ce.ufl.edu/featured/TSIS/Version5/corsim.htm.
[19] H. Wu, J. Lee, M. Hunter, R. M. Fujimoto, R. L. Guensler, and J. Ko, “Simu-lated Vehicle-to-Vehicle Message Propagation Efficiency on Atlanta’s I-75 Cor-ridor,” in Transportation Research Board Conference Proceedings, Washington D.C., 2005.
[20] Multiple Simulator Interlinking Environment (MSIE) for C2CC in VANETs, available at http://www.cn.uni-duesseldorf.de/projects/MSIE.
[21] C. Schroth, F. Dotzer, T. Kosch, B. Ostermaier, and M. Strassberger, “Sim-ulating the traffic effects of vehicle-to-vehicle messaging systems,” in Proc. of the 5th International Conference on ITS Telecommunications, Brest, France, 2005.
[22] The TraNS (Traffic and Network Simulation Environment), available at http:
//wiki.epfl.ch/trans.
[23] B. Khorashadi, A. Chen, D. Ghosal, C.N. Chuah, and M. Zhang, “Impact of Transmission Power on the Performance of UDP in Vehicular Ad Hoc Net-works,” ICC 2007. IEEE International Conference on Communications.
[24] R. Vuyyuru and K. Oguchi, “Vehicle-to-Vehicle Ad Hoc Communication Pro-tocol Evaluation using Simulation Framework,” in Proc. of the 4th IEEE/IFIP Wireless On demand Networks and Services, pp. 100-106, Austria 2007.
[25] L. Bononi, M. Di Felice, M. Bertini, E. Croci, “Parallel and Distributed Sim-ulation of Wireless Vehicular Ad Hoc Networks,” in proc. of the ACM/IEEE International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM), Torresmolinos, Spain, 2006.
[26] C. Gorgorin, V. Gradinescu, R. Diaconescu, V. Cristea, L. Ifode, “An Integrated Vehicular and Network Simulator for Vehicular Ad-Hoc Networks,” in Proc. of the European Simulation and Modelling Conference (ESM), Bonn, Germany, May 2006.
[27] Jungkeun Yoon, Mingyan Liu, and Brian Noble, “Random Waypoint Consid-ered Harmful,” IEEE INFOCOM 2003, March 2003.
[28] S.Y. Wang, H.T. Kung, “A simple methodology for constructing extensible and high-fidelity TCP/IP network simulators, IEEE INFOCOM’99,” March 21-25, New York, USA, 1999.
[29] S.Y. Wang, H.T. Kung, “A New Methodology for Easily Constructing Exten-sible and High-Fidelity TCP/IP Network Simulators,” Computer Networks 40 (2) (2002) 257-278.
[30] Harvard TCP/IP network simulator 1.0, available at http://www.eecs.
harvard.edu/networking/simulator.html.
[31] Hubert Zimmermann, “OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection,” IEEE Transactions on Communications, Vol. 28, No. 4, April 1980, pp. 425 - 432.
[32] S.Y. Wang, C.L. Chou, Y.H. Chiu, Y.S. Tseng, M.S. Hsu, Y.W. Cheng, W.L.
Liu, and T.W. Ho, “NCTUns 4.0: An Integrated Simulation Platform for Ve-hicular Traffic, Communication, and Network Researches,” 1st IEEE WiVec 2007 (International Symposium on Wireless Vehicular Communications, colo-cated with VTC 2007 Fall), September 30 - October 1, 2007, Baltimore, MD, USA.
[33] S.Y. Wang and C.L. Chou, “NCTUns Simulator for Wireless Vehicular Ad Hoc Network Research,” a chapter of the “Ad Hoc Networks: New Research”
book, 2008, (ISBN: 978-1-60456-895-0, published by Nova Science Publishers) [34] S.Y. Wang and C.L. Chou, “NCTUns Tool for Wireless Vehicular
Communi-cation Networks Research,” Simulation Modelling Practice and Theory,” (ac-cepted and to appear) [SCI]
[35] “ESRI Shapefile Technical Description,” An ESRI white paper, July 1998.
[36] S.Y. Wang, C.L. Chou, “On the characteristics of Information Dissemination Paths in Vehicular Ad Hoc Networks on the Move,” International Journal of Computer Systems Science and Engineering, Vol. 23, No. 5, 2008 (SCI)
[37] S.Y. Wang, C.L. Chou, and C.C. Lin, “On the Characteristics of Routing Paths and the Performance of Routing Protocols in Vehicle-Formed Mobile Ad Hoc Networks on Highways,” Wiley Wireless Communications and Mobile Computing (accepted and to appear, already published online on March 24, 2009) (SCI)
[38] S.Y. Wang, H.L. Chao, K.C. Liu, T.W. He, C.C. Lin and C.L. Chou, “Eval-uating and Improving the TCP/UDP Performances of IEEE 802.11(p)/1609 Networks,” IEEE ISCC 2008 (IEEE Symposium on Computers and Communi-cations 2008), July 6-9, 2008, Marrakech, Morocco.
[39] S.Y. Wang, C.L. Chou, K.C. Liu, T.W. Ho, W.J. Hung, C.F. Huang, M.S.
Hsu, H.Y. Chen, and C.C. Lin, “Improving the Channel Utilization of IEEE 802.11p/1609 Networks,” IEEE WCNC 2009 (Wireless Communications and Networking Conference), April 5-8, 2009, Budapest, Hungary.
[40] The collection of the NCTUns-based papers is available at http://nsl.csie.
nctu.edu.tw/NCTUnsReferences/.
[41] The NCTUns forum is located at http://nsl10.csie.nctu.edu.tw/phpBB/.