1

Topic: Research on Simulation Platform Based on Wireless Sensor Network

I. Introduction

With the rapid development of sensor networks (WSN), various network schemes and protocols are becoming more and more complex, and the network scale is getting larger and larger. For network researchers, the importance of mastering network simulation is self-evident. WSN simulation can study WSN applications in a controllable environment, including operating system and network protocol stack. It can simulate a large number of nodes, observe unpredictable interactions between nodes caused by unpredictable interference and noise, and obtain detailed details between nodes, thus improving the network success rate after nodes are put into operation and reducing the network maintenance work after they are put into operation. At present, the main simulation tools for wireless sensor networks are NS2, TinyOS, OPNET, OMNET++ and so on. TinyOS is specially developed for the characteristics of wireless sensor networks.

Second, brief introduction of wireless sensor network simulation

In sensor networks, a single sensor node has two outstanding characteristics. One feature is that its concurrency is very dense; Another feature is that sensor nodes are highly modular, which makes the simulation of wireless sensor networks need to solve the problems of scalability and simulation efficiency, distributed and asynchronous characteristics, dynamics, comprehensive simulation platform and so on.

Thirdly, common simulation tools for wireless sensor networks.

The commonly used simulation tools for wireless sensor networks are NS2, OPNET, OMNET++ and TinyOS. Let's briefly introduce their respective performances and characteristics.

3. 1 NS2

NS is an extensible, configurable and programmable time-driven simulation tool, which is developed on the basis of the real simulator. In the design of NS, two programming languages, C++ and OTCL, are used, and C++ is a language with relatively fast running speed but slow conversion, so C++ is used to realize the network protocol and write the simulation engine at the bottom of NS. OTCL is a scripting language, which runs slowly, but can be converted quickly, which is only the supplement of C++. Therefore, OTCL is used to configure various parameters in the simulation and establish the overall structure of the simulation. OTCL script defines the topological structure of the network by calling various attributes and methods in the engine, configures the source node and the destination node to establish links, generates the scheduling, running and tracking simulation results of all events, and can also perform corresponding statistical processing or drawing on the results. NS can provide wired networks. Many protocols in NS are very close to the real code, and their authenticity and reliability are very high.

3.2 OPNET

OPNET is a network simulation software product developed by MIL3 company on the basis of MIT research results. The main features of OPNET include the following aspects: (1) Using object-oriented technology, the attributes of objects can be configured at will, and each object belongs to a class with corresponding behaviors and functions, and different system requirements can be met by defining new classes; (2)OPNET provides processing components and modules for various communication networks and information systems; (3) OPNET uses graphical interface modeling to provide users with three-layer (network layer, node layer and process layer) modeling mechanism to describe the real system; (4) OPNET uses finite state machine to model other protocols and processes at the process level, and the user model and OPNET built-in model will automatically generate C language, so as to realize an executable simulation process with high efficiency and high discrete events; (OPNET has many built-in performance analyzers, which will automatically collect the result data of the simulation process; (6)OPNET predefines almost all commonly used business models, such as uniform distribution, Poisson distribution, Olam distribution, etc.

3.3 OMNET+++version

OMNET++ is an object-oriented discrete event simulation tool, which provides simulation support based on process and event. OMNET++ adopts mixed modeling method, and uses ned (Network Description) language and C++ which are unique to OMNET++ to model. OMNET++ mainly consists of six parts: simulation kernel library, network description language compiler, graphic network compiler, simulation program graphical user interface, simulation program command line user interface and graphic vector output tool. NED is the main model topology description language of OMNET++, which can be used to describe a network model. Network description includes the following components: input statement, channel definition, system module definition, simple module definition and composite module definition. NED is used to describe the network and generate a. NED file, which cannot be directly used by C++ compiler. First of all. The NED file needs to be compiled into a. cpp file by using the compilation tool NEDC provided by OMNET++. Finally, C++ compiler is used to connect these files with simple module programs designed by users themselves into executable programs.

3.4 TinyOS

TinyOS is an operating system specially developed for sensors. The programming language on TinyOS is NESC (C language of network embedded system).

NesC language is an extension of C language, which is intended to combine the idea of componentization/modularization with TinyOS event-driven execution model. There are two kinds of nesC components: module and configuration. In the module, it is mainly to compile code, and in the connection configuration file, it is mainly to connect components and modules into a whole.

TinyOS program adopts modular design, so its program core is often very small, which can break through the limitation of sensor storage resources, so that TinyOS can effectively run on wireless sensor networks and carry out corresponding management work. The characteristics of TinyOS are mainly reflected in the following aspects:

(1) Component-based architecture. TinyOS components can usually be divided into the following three categories: hardware abstract components, comprehensive components and advanced software components; Hardware abstraction component maps physical hardware to TinyOS component model. Synthetic hardware components simulate the behavior of advanced hardware. Advanced software module completes control, routing and data transmission. }

(2) Event-driven architecture. Event drivers are divided into hardware drivers and software event drivers. Hardware event-driven means that the hardware issues an interrupt and then enters the interrupt handling function. The software driver sends events through the singular keyword.

(3) Concurrent model of tasks and events. Tasks are used in applications that are not very strict with time, and tasks are equivalent, that is, they are executed in sequence and cannot be preempted by each other. TinyOS processes tasks according to a simple FIFO queue. Events are used in time-critical applications and can take precedence over tasks and other events.

(4) Phase separation operation. In TinyOS, because tasks cannot preempt each other, TinyOS does not provide any blocking operation. In order to complete a long-term operation as soon as possible, it is generally achieved by separating the demand for this operation from the completion of this operation in order to obtain higher execution efficiency.

(5) light thread. Lightweight threads (task in TinyOS) are scheduled in FIFO mode, and preemption between lightweight threads is not allowed; Hardware processing thread (called hardware processor in TinyOS), that is, interrupt processing thread can interrupt the user's lightweight thread and low-priority interrupt processing thread, and quickly respond to hardware interrupts.

(6) Active messages. Each message maintains an application layer and a processor. When the target node receives this message, it will take the data in the message as parameters and pass it to the processor of the application layer for processing. The processor of the application layer generally completes the unpacking operation of message data, calculation processing or sending response messages.

The common simulation platforms in TinyOS operating system are TOSSIM and Avrora.

(1) tossim (TinyOS Simulation) is an emulator, which supports Tinyos-based applications to run on PC. TOSSIM runs the same code as the sensor hardware, and the simulation compiler can directly compile and generate the simulation program from the component list of Tinyos application.

(2)Avrora is a tool to provide simulation analysis for programs written in AVR microcontroller language on Atmel and Mica2 nodes. Its main features are as follows: 1) It provides accurate cycle simulation for AVR single chip microcomputer, and makes the static program run accurately. It can simulate on-chip device drivers and provide a conventional interface for off-chip programs. 2) Monitoring code can be added to report the running performance of the simulation program, or statistical data can be collected and a report can be generated after the simulation; 3) A set of basic monitors for analyzing programs is provided, which is helpful to analyze the execution mode and resource usage of programs. 4)Avrora can debug the program with gdb; 5) Avrora can provide a program flow chart for the program, through which the structure and organization of the machine code program can be clearly expressed; 6) Avrora provides a tool for analyzing energy consumption, which can set the charged size of equipment; 7) Avrora can be used to limit the maximum stack space of a program. It will provide some information reports about the maximum stack structure in the current program, as well as some information reports about space and time consumption.

3.5 Performance comparison

TinyOS uses behavior modeling to simulate cross-layer protocols; The simulation program is transplanted to the node without secondary coding.

Through the analysis and comparison of the above simulation software, we can clearly see the characteristics and application scope of each simulation software, and we can choose the appropriate simulation software according to the research needs, so that our study and research can get twice the result with half the effort.

Concluding remarks

Network simulation technology provides a scientific and effective method for communication network planning and optimization. Network simulation has only developed in China in recent years, but the network simulation technology abroad is quite mature. We should boldly learn from foreign advanced technology and promote the rapid development of domestic network simulation technology.

refer to

1 Yu Haibin, Ceng Peng, etc. Intelligent wireless sensor network. Science Press, 2006, P283 ~ P303,

2 Shi Huaiwei, Li,, Network Simulation Technology and OPNET Application Practice, Computer System Application, 2006.3.

3, Wu, TCP/IP protocol simulation based on OMNeT++, Journal of Lanzhou Jiaotong University (Natural Science Edition), August 2005.

4 Yuan Honglin, Xu Chen, Zhang Guoan, TOSSIM: Wireless Sensor Network Simulation Environment, Sensors and Instruments, Vol.22, No.7-1, 2006.

2

Research on Simulation Modeling of Cluster Virtual Server

Source: Electronic Technology Application Author: Li Jindi Ye Yuning

This paper expounds the working principle of cluster virtual server and three load balancing methods, discusses the simulation and modeling methods of virtual server through examples, creates the input and system model for testing and simulating system performance, and verifies its probability distribution according to Q-Q diagram and cumulative distribution function.

Keywords: cluster virtual server load balancing simulation modeling probability distribution

With the rapid growth of Internet traffic and data traffic, new applications emerge one after another. Although the processing power and computing intensity of Intemel server have increased correspondingly, the development of business volume has exceeded the previous forecast, so that the server system built according to the optimal configuration in the past can not bear it. In this case, if the existing equipment is abandoned and the hardware is simply upgraded, the existing resources will be wasted. Therefore, the current and future network services should not only provide richer content, better interactivity and higher security, but also undertake higher visits, which requires higher performance, greater availability, good scalability and excellent cost performance. Therefore, cluster virtual server technology and load balancing mechanism came into being.

Cluster virtual server can gather some real servers together to form an extensible, highly available and reliable whole. Based on the existing network structure, load balancing provides a cheap, effective and transparent method to establish a server cluster system, expand the bandwidth of network devices and servers, increase throughput and enhance the network data processing ability. Improve the flexibility and availability of the network. Using the load balancing mechanism, a large number of concurrent access or data traffic can be distributed to multiple node devices for processing respectively. The processing capacity of the system is greatly improved, and the waiting time of users is greatly reduced.

In practical application, the more virtual servers contain real servers, the higher the performance index of the whole server (such as response delay, throughput, etc.). ), but the higher the price. Channels or other parts of the cluster may also enter saturation. Therefore, it is necessary to design the simulation model of virtual server according to the actual application, and determine the probability distribution type and parameters of random variables according to the measured data of the actual system. The probability distribution of performance indicators such as response or propagation delay is verified by Q-Q diagram and cumulative distribution function, and the running state and performance characteristics of the server are analyzed in advance by simulation software and tools (such as Automod), which makes the overall performance of the cluster system stable, improves the objectivity and reliability of virtual server design, and reduces the investment risk of server construction.

1 cluster virtual server architecture

Generally speaking, it is necessary to establish an Internet protocol camouflage mechanism, that is, IP camouflage, on the cluster virtual server, and then create an IP port forwarding mechanism, and then give the relevant settings on the real server. Figure 1 shows the general architecture of cluster virtual server. Cluster virtual servers usually include: RealServers and Load Balmlcer.

Because the network address translation method of the virtual server is based on IP camouflage, there is no special requirement for the operating system of the real server in the background, which can be windows operating system, Lmux or other operating systems.

The load balancer is the only entrance to the server cluster system. When the customer request arrives, the equalizer will select a server from the actual server according to the actual server load and the set scheduling algorithm, and then forward the request to the selected server and record the scheduling situation. When other messages of the request arrive, the message will also be forwarded to the previously selected server. Because all operations are completed in the core space of the operating system, the scheduling overhead is very small, so the load balancer has high throughput. The structure of the whole server cluster is transparent to customers, who only see one virtual server.

There are many schemes to realize load balancing cluster, one of which is Linux virtual server LVS(Linux Virtual Server). There are three technologies for LVS to achieve load balancing: network address translation, direct routing and IP tunneling.

According to IETF standard, network address translation allows the whole organization to appear on the Internet as a public IP address. The load balancer rewrites the destination address of the request message through network address translation, and schedules the request to the real server at the back end according to the preset scheduling algorithm; When the reply message from the real server passes through the equalizer, the source address of the message is rewritten, the internal private network address is translated into a legal network IP address, and then it is returned to the customer to complete the whole load scheduling process.

The scheduling and management of directly routed reply connection is the same as network address translation, but its message is directly forwarded to the real server. In the direct routing response, the equalizer does not modify or encapsulate the IP message, but changes the MAC address of the data frame to the MAC address of the selected server, and then sends the modified data frame on the LAN. Because the MAC address of the data frame is the selected server, the server can definitely receive the data frame and get the IP message from it. When the server finds that the destination address of the message is in the local network device, the server processes the message, then replies the message according to the routing table and returns it directly to the customer.

IP tunneling is a technology that encapsulates one IP message in another. This technology can package the data message sent to one port address and forward it to another IP address. Users use IP tunneling technology to package and forward the request message to the back-end server, and the reply message can be directly returned to the customer from the back-end server. In this way, the load balancer is only responsible for scheduling requests, and the reply is directly returned to the customer, without processing reply packets, which will greatly improve the throughput of the whole cluster system and effectively reduce the load of the load balancer. IP tunneling technology requires that all servers must support IP Yunnehng or lP. Encapsulation protocol.

2 Determination of message delay of cluster virtual server

Through an actual system with five real servers, the Linux virtual server is realized by using network address translation technology, and the time stamp files of request and response messages can be obtained. According to these files, the data needed for cluster virtual server simulation modeling can be calculated.

In order to determine the distribution type and parameters of random variables, the following delays need to be calculated: (1) transportation delay); From customer to load balancer; (2) response delay); Load balancer; (3) propagation delay from the load balancer to the real server; (4) The response delay of the real server; (5) propagation delay from real server to load balancer; F6 1 Response delay of the load balancer to the real server; (7) Propagation delay from the load balancer to the customer.

The above delay time is described in detail in the timestamp file generated by the actual system. This file contains the following contents:

When a service request arrives at the cluster virtual server system, it generates a synchronization request packet with a unique serial number, forwards the message to a real server, and establishes a connection between the server and the client, each connection has a unique port number; The server confirms the request packet through the connection until the server receives the complete request packet. For each type of request message, the system gives the corresponding reply message. Therefore, in different message timestamp files, if two records have the same port number, message type and serial number, they are the same request or response message, and the delay data needed for cluster virtual server system simulation modeling can be obtained by subtracting the relevant timestamp. These delays can be calculated by C++ program.

3 system simulation model

As shown in Figure 2, the simulation model of the actual cluster virtual server system mentioned above, all messages transmitted or processed in the load balancer, each channel and five real servers are request or reply messages.

4 Determination of random variable model

To simulate the cluster virtual server with random variables, it is necessary to determine the probability distribution of its random variables, so as to sample these distributions in the simulation model and get the required random variables.

4. 1 Overview of actual virtual server latency data

In the actual virtual server's load balancer, each channel and five real servers have a certain delay in request and reply messages. Some statistics of message delay are shown in table 1.

As can be seen from the data in Table L, the median and mean of message delay are quite different, so its probability distribution is asymmetric. The coefficient of variation is not equal to l, so the probability distribution will not be exponential distribution, but may be γ distribution or other distribution.

4.2 Probability distribution of random variables

Fig. 3 is a histogram of channel message propagation delay between the first real server and the load balancer, where t is the message delay time and h(t) is the number of message delay intervals. As can be seen from Figure 3, the packet propagation delay data in the channel approximately obeys the gamma distribution or lognormal distribution.

Two parameters are needed to describe γ distribution: shape parameter α and scale parameter (Scahj). The relationship between these two parameters and mean m and variance v is nonlinear:

The description of lognormal distribution also needs shape parameter σ and proportion parameter μ, and the relationship between these two parameters and mean m and variance v is also nonlinear:

Equations (1) ~ (4) can be obtained by MLE (maximum likelihood estimation) method or steepest descent method. Table 2 shows the packet delay probability distribution parameters in the channel from the first real server to the load balancer obtained by these two methods.

Cumulative distribution function and Q-Q diagram can be used to verify and further determine the probability distribution of message propagation delay in the above channels. Using the parameters in Table 2, the cumulative distribution function of γ distribution can be obtained, as shown in Figure 4, where t is the message delay time and F(t) is the cumulative distribution function of message delay. For comparison, the experimental distribution is also drawn in the figure. The Q-Q diagram of γ distribution and lognormal distribution is shown in Figure 5.

As can be seen from Figures 4 and 5, the gamma distribution is very consistent with the data distribution of packet propagation delay in this channel. The message delay histograms of other channels have similar shapes. After calculation and analysis, the probability distribution of message propagation delay in these channels also approximately obeys γ distribution.

According to the data in table 1 and the related histogram, it is difficult to determine the theoretical distribution of message delay in load balancer and real server. Therefore, the experimental distribution is adopted as its model.

5 model simulation

After establishing the system simulation model of the cluster virtual server as shown in figure 1 and determining the distribution characteristics of its random variables, the simulation software Automod input model developed by Brooks Automation can be used to simulate and analyze the cluster virtual server through programming in the Automod environment.

In the process of Automod simulation, the resources provided by the software can be directly used as the unit for processing various message data. The message queuing activities of each part of the system can be directly realized by queuing; Create a load generator, which is equivalent to a customer who uses a virtual server on Inlemtet.

Using Automod attribute variable can solve the problem of bidirectional message processing function of load balancer. The load balancer uses round robin scheduling algorithm, that is, assuming that all real servers have the same processing performance, it schedules requests to different servers in turn.

The verification simulation model can be compared from two aspects: (1) the load balancer, the number of response or propagation messages queued in each real server and channel; (2) cPU utilization of real servers and load balancers. For example, when the actual response or propagation message is used to delay data, if a low amount of resources is set in the simulation model of Automod, most of the load will be blocked in the queue of the real server during the simulation process, that is, the ability of the real server to process messages is too low to compare with the actual system situation; If a higher amount of resources is set, it means that the parallel processing capacity of the server will increase, the utilization rate of the real server will increase, and the load is little or not stuck in the queue of the real server. Therefore, the simulation model resources in Automod can be adjusted according to the actual situation.

If the load generation rate of the load generator is increased in Automod, it is equivalent to increasing the number of users' visits. By observing the load retention rate in the queue, we can find the maximum message processing capacity of the system and the possible bottlenecks in answering messages in various parts of the system. For example, if the load generation rate doubles, although the system can still handle all messages, the average utilization rate of each real server will reach about 80%. Obviously, the "bottleneck" of the system response message at this time is the real server, so a new real server needs to be added to the system.

Through a real virtual server system including five real servers. Collect and calculate sample data for simulation and modeling. According to the median, mean, coefficient of variation and histogram of system message delay, the probability distribution of system random variables is determined. The specific parameters of channel probability distribution are obtained by maximum likelihood estimation method and steepest descent method. According to the Q-Q diagram and cumulative distribution function, the probability distribution form of the channel is further verified and finally determined. Using Automod software to simulate modeling and programming. With the help of the simulation results, the maximum processing capacity and possible "bottlenecks" of the virtual server can be found. By locating the "bottleneck" of the system in time, we can further study and improve the system and effectively improve the system performance. The simulation method adopted can also be used for simulation modeling or analysis in other fields.

In the simulation model, in order to compare different virtual server systems, it is necessary to further increase the load balancing method and scheduling algorithm. The sample data needs to be further expanded to avoid the autocorrelation of message delay.