KR101125365B1 - Integrated design method of communication protocols with sdl-opnet co-simmulation technique - Google Patents

Abstract

Disclosed is a single model based integrated design method of a communication protocol using the SDL-OPNET co-simulation technique. The single model-based integrated design method of the communication protocol may include: designing a protocol model that satisfies protocol requirements by using a specification and description language (SDL); Performing functional verification on the protocol model to generate a verified SDL design model; Building a performance evaluation environment model using OPNET; Designing SDL environment functions and OPNET external system interface code; And performing a performance evaluation on the verified SDL design model using the SDL environment function and the OPNET external system interface code.

Description

Single-model-based integrated design method of communication protocol using SDL-OPEN co-simulation technique {INTEGRATED DESIGN METHOD OF COMMUNICATION PROTOCOLS WITH SDL-OPNET CO-SIMMULATION TECHNIQUE}

The present invention relates to a method of designing a communication protocol, and more particularly, known as Tau, which is widely used as a design and verification tool using a specification and description language (SDL), and a best network performance evaluation tool. A single model-based integrated design method for communication protocols using SDL-OPNET co-simulation technique using tool connection between OPNETs.

Recently, as communication service requirements such as high speed, multimedia, and mobile communication are diversified and complicated, new communication systems are constantly emerging, and communication system implementation products are being developed accordingly. In general, when designing a new communication system or improving the performance of an existing system, performance analysis is performed to evaluate the performance of the designed system. The performance analysis method may use mathematical analysis or actual performance measurement of the implemented product, but as the accuracy of the design and the complexity of the functional operation increase, the simulation method is recognized as a realistic and reliable method.

On the other hand, in order to design a communication system that satisfies various complex service requirements, a clear description of the structure, functional operation, and the relationship between services is essential. To meet this need, formal description languages, such as Specification and Description Language (SDL), have been developed. Currently, ITU-T recommends that SDL specifications for protocol operation be standardized when standardizing new communication protocols. SDL design tools, such as IBM's Rational Tau SDL Suite (Tau), allow you to automatically generate code for implementation as well as easy validation of designed model behavior.

In designing a new communication system, performance evaluation of the system and functional verification through formal design are both important. In reality, it is not uncommon to design a communication system by faithfully performing both processes. That is, the design is carried out by focusing on one part which is considered more important during the functional verification and performance evaluation of the system, and the other part is omitted or postponed later. It is naturally expensive to perform both functional verification and performance evaluation, but the problem is that functional verification and performance evaluation for one protocol are performed in different design environments. This is due to the fact that functional verification and performance evaluation have been studied separately until now, in order to perform both functional verification and performance evaluation, it is necessary to perform individual modeling in duplicate and ensure the sameness between the overlapped models.

In the past, various studies have been conducted to integrate functional verification and performance evaluation to solve this problem. The process of developing a reliable and high performance protocol using integrated design techniques is roughly as follows. First, a protocol model is designed with a design tool that supports formal modeling language, and the functional accuracy is verified. Then, a simulation environment is constructed using a performance evaluation tool, and a final model is obtained through performance evaluation. In order for these integrated design techniques to be actively used in the design and development of actual communication protocols, the reliability and effectiveness of the integrated design techniques must be demonstrated. However, when the integrated design technique uses a non-standard extension language other than the standard formal language or a self-developed performance evaluation tool instead of the existing performance evaluation tool, it is difficult to verify the scalability or reliability of the proposed technique. It is therefore necessary to use standard formal description languages and proven design and evaluation tools to ensure the effectiveness and reliability of integrated design techniques.

Integrated design techniques using existing validated evaluation tools can be categorized into a model mapping method for converting a functional model into a performance model and a tool connection method for linking functional verification tools with performance evaluation tools. Recently, an integrated design technique that links the SDL design tool Tau with the open performance evaluation tool ns-2 has been proposed.However, OPNET Modeler (OPNET), which is recognized as the most reliable performance evaluation tool, is a commercial tool. As a result, it is not well used in integrated design techniques.

The present invention is proposed to overcome the problems of the integrated design techniques described above. It is a technical problem to solve to provide a single model-based integrated design method of a communication protocol using the SDL-OPNET co-simulation technique.

As a means for solving the technical problem, the present invention comprises the steps of designing a protocol model to meet the protocol requirements using SDL; Performing functional verification on the protocol model to generate a verified SDL design model; Designing a performance evaluation environment model using OPNET; Designing SDL environment functions and OPNET external system interface code; And performing a performance evaluation on the verified SDL design model by using the SDL environment function and the OPNET external system interface code.

In an embodiment of the present invention, the designing of the performance evaluation environment model may include designing a performance evaluation target module as an empty dummy module, and designing the SDL environment function and the OPNET external system interface code may include: The SDL environment function and the OPNET external system interface code may be designed and stored in a co-simulation controller.

In this embodiment, performing a performance evaluation on the validated SDL design model may include: the dummy module and the verified SDL design model in a data exchange manner using the SDL environment function and the OPNET external system interface code. It may include the step of being connected.

Further, in this embodiment, performing the performance evaluation on the verified SDL design model includes: setting, by the dummy module, a message generated by another module in the performance evaluation environment model to an external system interface; Receiving, at the co-simulation controller, a message set in the external system interface and converting the message into an SDL message format; Sending, at the co-simulation controller, a message converted to an SDL message format to the verified SDL design model; Outputting a result message generated by performing an operation according to the received message by the verified SDL design model; Receiving, at the co-simulation controller, the result message and converting the received result message into an OPNET packet format; Setting, at the co-simulation controller, a message converted to the OPNET packet format to the external system interface; And receiving, by the dummy module, a message converted into the OPNET packet format set in the external system interface.

In addition, the step in which the dummy module sets a message generated by another module in the performance evaluation environment model to an external system interface may include a message generated by the dummy module at the other system interface to the external system interface through an Esys kernel procedure. It may be a step of setting.

In addition, in the co-simulation controller, receiving a message set in the external system interface and converting the message into an SDL message format may be automatically invoked when the dummy module sets a message in the external system interface. -By the ESA callback function pre-registered in the simulation controller, the co-simulation controller can determine that a message has been set by the dummy module on a fraudulent external system interface.

In addition, in the co-simulation controller, transmitting a message converted into an SDL message format to the verified SDL design model may include: converting the message converted into the SDL message format by the co-simulation controller into an SDL environment function 'xOutEnv ( ') May be transmitted to the verified SDL design model.

In addition, in the co-simulation controller, receiving the result message and converting the received result message into the OPNET packet format may include converting the result message by the SDL environment function 'xInEnv ()' in the co-simulation controller. Receiving may include.

In addition, in the co-simulation controller, setting the message converted into the OPNET packet format to the external system interface may include: in the co-simulation controller, converting the message converted into the OPNET packet format by using an OPNET ESA API. The setting may be performed in the external system interface.

In addition, receiving the message converted into the OPNET packet format set in the external system interface by the dummy module may include generating an ESI interrupt when the message converted into the OPNET packet format is set in the external system interface; When an ESI interrupt occurs, the dummy module may include receiving a message converted to the OPNET packet format set in the external system interface using an Esys kernel procedure.

According to the present invention, there is an advantage of using the Tau and the OPNET tool together and the performance evaluation function of the OPNET. Therefore, a designer skilled in both SDL and OPNET wants to directly link the function verification function of the Tau and the performance evaluation function of the OPNET. Can be used actively. In this case, performance evaluation is performed on the functionally verified SDL model without configuring an OPNET model separately, so that the reliability of the performance evaluation result can be improved and the protocol design and development period can be shortened.

BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 illustrates a method of accessing an outer area through an environment function of Tau.
2 illustrates the structure of an OPNET external system interface for co-simulation.
3 illustrates an integrated design method of a communication protocol according to the present invention.
4 is a block diagram illustrating an SDL-OPNET co-simulation system in accordance with the present invention.
5 shows an example of an SDL-OPENT co-simulation scheduling algorithm.
Figure 6 is a block diagram showing the configuration of the InRes protocol consisting of an Initiator node and a Responder node to which the present invention is applied.
7 illustrates the structure of an InRes protocol co-simulation system in accordance with the present invention.
8 is an Initiator Esys when InRes protocol co-simulation is applied according to the present invention. State transition diagram of the module.
9 is a graph showing the result of InRes protocol co-simulation (cumulative received packet number) according to the present invention.

Hereinafter, various embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, embodiments of the present invention may be modified in various other forms, and the scope of the present invention is not limited to the embodiments described below. Embodiment of this invention is provided in order to demonstrate this invention more completely to the person skilled in the art to which this invention belongs. Therefore, it should be noted that the shape and size of the components shown in the drawings may be exaggerated for more clear explanation.

First, in order to understand the SDL-OPNET co-simulation method, the external system interfaces provided by Tau and OPNET, which are representative SDL design tools, are described.

Tau External environment interface

1 is a diagram illustrating a method for accessing an external area through an environment function of Tau.

Tau does not provide a special interface for co-simulation with other simulators, but can be interworked by exchanging messages with an external simulator using an external environment interface for generating target code. Environment functions provided by the external environment interface 10 of Tau are as follows. 'xInitEnv ()' (11) is an environment function called by the SDL_Halt () function, respectively, when the SDL system is initialized. Code to be executed when the SDL system starts and exits. Includes. 'xOutEnv ()' (12) is an environment function that controls the sending of signals to the outside. First, the output signal is checked, and then, when there is an output to the outside, a necessary function is performed. 'xInEnv ()' (13) is an environment function that sends an external signal to the SDL system. To check the presence of an external signal, the system continues to call this function while staying in a logical state. If there is a signal sent to the SDL system 1, 'xInEnv ()' (13) sends a signal to the SDL system through the SDL_Output () function.

In the case of the 'xInEnv ()' (13) function, polling is used to check the presence of signals from the external environment, so when the system is very complicated, the reliability becomes poor. Therefore, to improve reliability, a method of designing and using a thread that monitors the presence of a signal from an external environment can be used. Tau only generates skeleton code for the above external functions when compiling the SDL model, so the above external functions must be completed for complete connection with the external.

OPNET External system interface

2 is a diagram illustrating the structure of an OPNET external system interface for co-simulation.

OPNET provides an OPNET co-simulation package to support co-simulation between other external software and OPNET. The OPNET co-simulation package includes the Esys module (21), the External System Definition (ESD) model, the Kernel Procedure (KP) 220 and the External System Aceess (ESA) APIs. 230 can be configured to include.

The Esys module 21 of the OPNET 20 is a special gateway used by the OPNET to exchange data with an external system, and is defined in the node model in a form similar to a process module using packet streams and statistics line connections. The Esys module 21 has an ESD model that defines an interface between the external co-simulation code and the OPNET, that is, an External System Interface (ESI) 210, for performing co-simulation. The OPNET sends and receives co-simulation messages through the ESI 210 defined in ESD. For this purpose, the op_esys kernel program controls when and how to read and write data through the Esys interface in the process model of the Esys module 21. Scissor 220 is used.

The code for the external system interface differs depending on whether the OPNET main function is placed inside or outside the OPNET. In the case of co-simulation using a connection with external software, the OPNET external code 200 is normally Functions are put in place to control the overall co-simulation execution. The ESA API 230 is a C API called from the OPNET external code. The ESA API 230 connects the OPNET model 20 and the co-simulation code to perform simulation initialization and loading, flow control management, Esys interface processing, and data exchange through the Esys interface. Can be used to perform.

Next, the co-simulation system structure and co-simulation control method applied to the single model-based integrated design method of the communication protocol and the single model-based integrated design method of the communication protocol according to the present invention. Explain about.

Co-simulation based integrated design technique

The single model-based integrated design technique of the communication protocol according to the present invention uses the designed SDL model for both functional verification and performance evaluation. 3 is a diagram illustrating an integrated design method of a communication protocol according to the present invention.

The protocol model 32 is designed using the standard formal language SDL (for example, Tau) from the protocol requirement 31 for the development of the communication protocol (S1). The protocol design process is carried out in an integrated development environment (IDE) provided by Tau (S1). Perform the functional verification using the simulator and validator provided by Tau for the designed SDL model 32 (S2), and modify the model according to the result, and then verify the SDL design that meets the requirements. Model 23 is obtained. In this case, when performing verification using a simulator, a separate tester model for simulation may be constructed.

Next, to evaluate the performance of the designed protocol, OPNET is used to build a performance evaluation environment model 34 such as a network configuration (S3). The SDL-OPNET co-simulation system 35 controls the simulation between the OPNET performance evaluation model 34 and the SDL function model 33 to obtain a performance evaluation result. Tau environment functions and OPNET external system interface code are designed to build a co-simulation environment. This Tau environment function and OPNET external system interface code can be stored in separate co-simulation controllers. Co-simulation setting between SDL (Tau) and OPNET will be described later in more detail. If performance evaluation through the SDL-OPNET co-simulation (S4) is performed (S5). As a result, the SDL model may be modified again. When the final SDL model 36 is completed through this feedback process, the protocol product 37 may be obtained through an implementation process such as target porting provided by Tau (S6).

Structure of Co-Simulation System

4 is a block diagram illustrating an SDL-OPNET co-simulation system according to the present invention.

In order to evaluate the performance of the protocol model designed with SDL, in order to co-simulate the SDL simulator Tau with the network simulator OPNET, it is necessary to determine how to connect the two tools and control the co-simulation. Since both tools have external system interfaces, the basic tool connection can be a message exchange between tools. Since the target protocol model operates in Tau and other network configurations for performance evaluation should operate in OPNET, the OPNET simulation system must be designed appropriately for this structure. The present invention provides a method of designing a target protocol as an empty dummy module 41 when designing a performance evaluation environment model in the OPNET 40 and connecting the SDL model with a data exchange method through an external co-simulation control code. use.

The target protocol, which is designed as an Esys module that lacks operating techniques in the OPNET network model, is configured in the ESI 432 through the Esys kernel procedure 432 for packets coming from other protocol models inside the OPNET. At this time, the ESA callback function 433 is registered with the external co-simulation controller 44 so that the ESA callback function 433 can be automatically called. The callback function, which is called automatically, is defined in the external co-simulation controller 44. The packet sent from the OPNET is retrieved through the ESA API 434, converted into a format according to the SDL message format, and the SDL environment function 'xOutEnv ()' (442) Send to the SDL protocol model through the design. When the SDL protocol model performs an action upon receiving a message and outputs the message, the environment function 'xInEnv ()' (441) designed for the co-simulation controller converts the message according to the OPNET packet format, and then the OPNET ESA API (434). Is set in the ESI 432 using. At this time, the ESI interrupt 435 occurs in the OPNET system 40 and the OPNET Esys module 41 uses the Esys kernel procedure 432 to obtain this packet.

Control of Co-Simulation Systems

If the co-simulation control code simply performs message matching to perform OPNET-SDL co-simulation, OPNET and Tau manage the simulation time flow separately. Both OPNET and Tau support discrete event-driven simulation and realtime simulation, but there are significant differences in how the two tools simulate simulation and time management. Since SDL basically does not have a time progression other than time progression through timers, if the timer does not exist in the SDL model, the operation in the SDL model does not generate time progression. Management is possible. However, if there is a time progression through the timer in the SDL model, separate control methods are required for time synchronization between the two simulation systems for accurate co-simulation between SDL-OPNETs. The SDL-OPNET co-simulation control technique applied to the present invention controls the execution of the SDL model and the OPNET model simulation by integrating and managing the events of the OPNET system and the SDL system in the co-simulation control code. That is, one main function exists in the co-simulation control code, and the 'Esa_Execute_Until ()' and 'SDL_Execute ()' functions are called to control the simulation of OPNET and Tau, respectively. The role of the co-simulation control code is the initialization and termination of the OPNET system and the SDL system, the scheduling of OPNET events and SDL / Tau events, the time synchronization between the OPNET and SDL simulations, the packet forwarding between the OPNET and SDL, and the packet format conversion. 5 shows a scheduling algorithm of SDL-OPNET co-simulation. SDL_RQ, SDL_TQ, and OPNET_Q refer to the SDL ready queue, the SDL timer queue, and the OPNET event queue, respectively, where n (Q) is the size of queue Q, ev (Q) and evtime (Q) are respectively at queue Q. Gets the next event to execute and the runtime of that event.

In the scheduling algorithm of FIG. 5, initial events are generated through initialization of the OPNET system and the SDL system, and simulation is performed until all event queues are empty. When the event having the fastest execution time is determined in the event queue according to the scheduling algorithm, the unit simulation is performed by the event in the corresponding model. As new simulations are generated as a result of the simulation, each event queue is automatically updated and updated, which is then used to determine the next event in the scheduling algorithm.

Example

Hereinafter, an embodiment to which the single model-based integrated design method of the present invention is applied to the InRes protocol will be described.

The InRes protocol is an asymmetric connection-oriented data transmission protocol consisting of Initiator and Responder protocols.It is a simple data transmission / reception protocol, but it is a test protocol that is frequently used as a sample protocol in communication protocol engineering research because it is fully equipped with access control and error control functions. .

6 shows a configuration of an InRes protocol consisting of an Initiator node 61 and a Responder node 63. Initiator node 61 is composed of an Initiator protocol 611 and an Initiator User 612 that communicates using the Initiator protocol 611, Responder node 63 is composed of a Responder protocol 631 and a Responder User 632. The present invention can design and verify the SDL model for the Initiator protocol and perform the performance evaluation through the proposed SDL-OPNET co-simulation technique.

7 is a diagram illustrating the structure of an InRes protocol co-simulation system.

In FIG. 7, the Initiator module of OPNET is written as Esys module 71 for external connection, and the ESD specification of the Initiator module defines two ESI, if_user, for co-simulation for the upper Initiator User 72 and the lower link connection. (73) and if_resp (74). if_user interface 73 is used for packet transmission between Initiator User 72 and SDL Initiator 75, and if_resp interface 73 is used for packet transmission between SDL Initiator 75 and Responder. The OPNET model for Initiator and Responder nodes and links between nodes except for the Initiator module is designed according to the InRes protocol specification, and the actual model of the Initiator protocol is an SDL model and is designed in the SDL Initiator system 75.

The main items of SDL-OPNET co-simulation system design for InRes protocol are as follows. First, in the OPNET system, configure the Initiator Esys module to set up packets coming into the Initiator Esys module from other protocols to the ESI and vice versa, and secondly, to exchange messages with the SDL model and OPNET. Designing the Tau environment function and packet transform function, and finally designing the main function that performs co-simulation control, including event scheduling. Packet exchange between the Initiator Esys module and the ESI is implemented through the design of the Esys module, including state transition diagrams. The state transition diagram of the Initiator Esys module consists of a single red state, as shown in FIG. Both packet transfer functions are implemented using the op_esys kernel procedure.

The co-simulation control code converts the co-simulation main loop function that performs the SDL and OPNET simulations, the ESA callback functions and the SDL output message, which receives and converts the OPNET packet into the SDL message, according to the scheduling algorithm of FIG. SDL environment functions sent to OPNET ESI.

The SDL-OPNET co-simulation scenario for the InRes protocol is as follows. The inter-arrival time of the connection request and disconnection request between the Initiator and Responder nodes from the Initiator User and the data transfer request from the Initiator User to the Initiator is randomly determined according to an exponential distribution of values 20, 10, and 30, respectively. OPNET simulation time is 1 hour. Through co-simulation, the connection setup and data transfer between the SDL Initiator model and the OPNET Responder model were smoothly performed. As shown in the simulation result of FIG. 9, the Responder User received about 2,600 packets successfully sent by the Initiator User for 1 hour. It was.

As described above, the present invention has the advantage that the Tau and the OPNET tool can be used together, and the performance evaluation function of the OPNET can be used. Thus, designers who are skilled in both SDL and OPNET can use the function verification function of the Tau and the performance evaluation function of the OPNET. It can be used actively if you want to connect directly. At this time, performance evaluation is performed on the functionally verified SDL model without configuring an OPNET model separately, so that the reliability of the performance evaluation results can be improved and the protocol design and development time can be shortened.

In the detailed description of the present invention, specific embodiments have been described, but various modifications may be made without departing from the scope of the present invention. Therefore, the scope of the present invention should not be limited to the described embodiments, but should be defined by the following claims and their equivalents.

31: Protocol Requirements
32: SDL Protocol Model (SDL Design Model)
33: Validated SDL Design Model (Valid SDL Protocol Model)
34: OPNET performance test model
35: OPNET co-simulation system
36: Final SDL Design Model (Final SDL Protocol Model)
37: Protocol Products

Claims (10)

Designing a protocol model that meets protocol requirements using Specification and Description Language (SDL);
Performing functional verification on the protocol model to generate a verified SDL design model;
Designing a performance evaluation environment model using OPNET;
Designing SDL environment functions and OPNET external system interface code; And
Performing performance evaluation on the verified SDL design model using the SDL environment function and the OPNET external system interface code,
The designing of the performance evaluation environment model may include designing a performance evaluation target module as an empty dummy module.
The designing of the SDL environment function and the OPNET external system interface code may include designing and storing the SDL environment function and the OPNET external system interface code in a co-simulation controller. A unified design method based on a single model of communication protocol.
delete The method of claim 1,
Performing a performance evaluation on the verified SDL design model includes connecting the dummy module with the verified SDL design model in a data exchange manner using the SDL environment function and the OPNET external system interface code. A single model-based integrated design method of communication protocol using SDL-OPNET co-simulation technique.
The method of claim 1,
Performing a performance evaluation on the verified SDL design model,
Setting, by the dummy module, a message generated by another module in the performance evaluation environment model to an external system interface;
Receiving, at the co-simulation controller, a message set in the external system interface and converting the message into an SDL message format;
Sending, at the co-simulation controller, a message converted to an SDL message format to the verified SDL design model;
Outputting a result message generated by performing an operation according to the received message by the verified SDL design model;
Receiving, at the co-simulation controller, the result message and converting the received result message into an OPNET packet format;
Setting, at the co-simulation controller, a message converted to the OPNET packet format to the external system interface; And
And a step in which the dummy module receives a message converted into the OPNET packet format set in the external system interface, based on a single model-based integrated design method of a communication protocol using the SDL-OPNET co-simulation technique.
The method of claim 4, wherein
In the dummy module, setting a message generated by another module in the performance evaluation environment model to an external system interface may include:
And setting the message generated by the other module to the external system interface through the Esys kernel procedure.
The method of claim 4, wherein
In the co-simulation controller, receiving a message set in the external system interface and converting the message into an SDL message format includes:
By an ESA callback function pre-registered in the co-simulation controller to be called automatically when the dummy module sets a message on the external system interface, the co-simulation controller by the dummy module on a fraudulent external system interface. A single model-based integrated design method of a communication protocol using the SDL-OPNET co-simulation technique comprising the step of determining that the message is set.
The method of claim 4, wherein
In the co-simulation controller, sending a message converted to an SDL message format to the verified SDL design model,
Transmitting, by the co-simulation controller, a message converted into the SDL message format to the verified SDL design model by an SDL environment function 'xOutEnv ()', wherein the communication using the SDL-OPNET co-simulation technique is performed. Unified model-based design of the protocol.
The method of claim 4, wherein
In the co-simulation controller, receiving the result message and converting the received result message into an OPNET packet format,
And receiving the result message in the co-simulation controller by an SDL environment function 'xInEnv ()'. A single model-based integrated design method of a communication protocol using an SDL-OPNET co-simulation technique.
The method of claim 4, wherein
In the co-simulation controller, setting the message converted into the OPNET packet format to the external system interface may include:
In the co-simulation controller, a step of setting a message converted into the OPNET packet format on the external system interface using the OPNET ESA API based on a single model of the communication protocol using the SDL-OPNET co-simulation technique Integrated design method.
The method of claim 4, wherein
Receiving the message converted by the dummy module to the OPNET packet format set in the external system interface,
Generating an ESI interrupt when the message converted into the OPNET packet format is set to the external system interface; and when the ESI interrupt occurs, the OPNET packet set to the external system interface by the dummy module using an Esys kernel procedure. A single model-based integrated design method of a communication protocol using the SDL-OPNET co-simulation technique, comprising receiving a message converted into a format.

Images