This preview shows page 1. Sign up to view the full content.
Unformatted text preview: Tutorials > Modeler Tutorials > Basic Processes Basic Processes
In the Project Editor, a network model is made up of individual nodes and a node is made of
modules. The process model defines the behavior of a module. By understanding process models,
you can build modules and combine them to build nodes to your exact specifications.
In this lesson, you will do the following:
Create process and node models
Define variables, macros, and transitions
• Run a simulation
Analyze simulation results This lesson shows how to build a module that counts the packets it receives and then writes that
number to a statistic that can be graphed. For each received packet, the process model increments
the value of a variable and records the variable.
Example Process Model A process model is a finite state machine (FSM). It represents the logic and behavior of a module.
An FSM defines the states of the module and the criteria for changing the states.
An FSM implements the behavior of a module. FSMs use states and transitions to determine what
actions the module can take in response to an event.
States and Transitions State—The condition of a module. For example, a
module may be waiting for a link to recover.
•Transition—A change of state in response to an event You can use an FSM to control module behavior, because you can attach fragments of C/C++ code
to states and transitions.
You can attach fragments of C/C++ code to each part of an FSM. This code, augmented by OPNETspecific functions, is called Proto-C.
The three primary places to use Proto-C are:
Enter Executive—Code that is executed when
the module moves into a state
Exit Executive—Code that is executed when the module leaves a state
Transition Executive—Code that is executed in response to a specific event
Enter and Exit Executives of a State Simulations are made up of events. Process models respond to events and can schedule new ones.
When an event occurs that affects a module, the Simulation Kernel passes control to the module’s
process model via an interrupt. The process model responds to the event, changing state and
executing related code, and then returns control to the Simulation Kernel (invocation 1).
The next time OPNET invokes the process model, it determines the state in which it was left
(invocation 2), responds to the new event, and passes control back to the Simulation Kernel.
Which State is Active? When a process model enters a state, it executes the enter executives and then, if the state is
unforced (as above), the process model stops execution and returns control to the simulation.
Forced and unforced states are discussed in more detail later. Designing the Model
The packet-counting process model you will build contains three states: an initializing state, an idle
state, and an arrival state.
When a packet arrives at the module containing your process model, the model must increment a
counter and then dispose of the packet.
Therefore, the module has two primary states:
Wait for a packet to arrive
) Process the packet after it arrives
You also need an initialization state that sets the appropriate variables to zero. The process model
will have the states shown in the following figure:
The Three States Required for the Model The packet-counting model contains three transitions: initialization-to-idle, idle-to-arrival, and arrivalto-idle.
The first time the process model is invoked (in this case, at the beginning of the simulation), it begins
in the initialization state. After initialization—which sets the packet-counter variable to zero—the
process model transitions to the idle state and waits for the first packet to arrive.
The process model is activated again and transitions to the arrival state when a packet arrives. The
arrival state increments the packet-counter variable and destroys the packet. Without pausing, the
process model then transitions back to the idle state to wait for the next packet.
Three Transitions are Required Implementing the Process Model
The first step in implementing the process model is to open the Process Editor and place the
model’s three states in the workspace.
Start OPNET Modeler if it is not already running.
Choose File > New… and select Process Model from the pull-down menu. Click OK.
Click the Create State tool button and place three states in the workspace as shown. Right-click to
3stop adding states.
Placing Three States Notice the first state you create is automatically the initial state; this is indicated by a heavy arrow.
Give each state a unique name that describes its function. You will use the name init for the
initialization state, idle for the idle state, and arrival for the arrival state.
Right-click on the initial state (the one with the
heavy arrow) and select Set Name from the
Object pop-up menu.
Name the state init and press Return.
Naming the State Repeat the procedure with the other two states
and name them as follows:
st_1: idle 3
st_2: arrival An unforced (red) state is one that returns control of the simulation to the Simulation Kernel after
executing its enter executives. A forced (green) state is one that does not return control, but instead
immediately executes the exit executives and transitions to another state.
A newly-created state is, by default, unforced; after executing its enter executives, the process
model blocks (that is, stops execution and returns control to the Simulation Kernel). The next time
the process model is invoked, execution begins again from the state in which it last blocked.
A forced state does not stop after the enter executives. Execution proceeds to the exit executives
and transitions to the next state.
Forced and Unforced States Two states in the process model you are building are forced states. The init state is forced because
it can proceed directly to the idle state after initializing variables. The arrival state is forced because
the process model should return to the idle state after counting and destroying each packet.
Change the init state to a forced state by rightclicking on it and selecting Make State Forced
from the Object pop-up menu.
The init state becomes green. 2Repeat step 1 for the arrival state so that it is also a forced state. Create State Transitions
The next step in building the process models is to create the transitions between the states. There
are two types of transitions, unconditional and conditional. When a transition is conditional, the
transition must evaluate to true before control passes from the source state to the destination state.
Click the Create Transition tool button. 1
Draw the transition by first clicking on the init state and then clicking on the idle state.
The arrow of the transition points from the source
state to the destination state. The transition is
automatically selected and appears as a dotted
and dashed line. (When unselected, the transition
will be a solid line, indicating that it is
Draw a curved transition by clicking first on the idle state, then at a vertex point between the idle
3 and arrival states, and finally on the arrival state.
Drawing Transitions 4
Right-click to stop drawing transitions.
Left-click in the workspace to unselect the transitions.
To create a conditional transition, you place a value in the condition attribute of the transition. You
must make the transition between idle and arrival conditional because the process model should
transition to the arrival state only when a packet arrives, and not in response to any other event.
Right-click on the transition between the idle and
arrival states and select Edit Attributes from the
2Change the value of the condition attribute to ARRIVAL (be sure to use all capital letters), press
Return, then click OK. The Attributes dialog box closes.
“condition” Attribute has Value of “ARRIVAL” The transition is now a dashed line and has a label with the name of the condition. You will define
the ARRIVAL condition macro later to specify that the transition will be used only when a packet
arrives and the process model is in the idle state.
There are two more transitions to implement in the process model. The first is an unconditional
transition from the arrival state to the idle state, and the second is a conditional transition from the
idle state to itself.
Click on the Create Transition tool button and
draw a transition from arrival to idle.
2Draw a transition from the idle state back to itself, as shown in the next figure. Hint: click on two
points in the workspace while drawing the transition before bringing it back to the idle state. 3
Right-click to stop drawing transitions.
4Right-click on the transition from idle back to itself and select Edit Attributes from the pop-up
menu to bring up the Attributes dialog box.
Change the value of the condition attribute to default (be sure to use all lower-case letters), press
5Return, and click OK.
“condition” Attribute has Value of “default” You may be wondering why you included a transition from idle back to itself and named that
transition default. As the simulation executes, the Simulation Kernel manages a list of events to take
place. As each event reaches the top (or head) of that list, it becomes an interrupt. Interrupts are
often delivered to specific modules, and this occurrence is what activates the module’s process
When the process model you are building is in the idle state, it transitions to the arrival state if the
ARRIVAL condition is true. Shortly, you will define ARRIVAL to evaluate to true if the interrupt
delivered to the module is a packet arrival interrupt. If it is a different type of interrupt, however, there
must be a transition that the process model can follow. The default transition handles these different
interrupt types. Define Conditions and Variables
In Proto-C, macros often replace more complicated expressions in transition conditions and
executives. The use of macros saves space and simplifies the task of interpreting an FSM diagram.
You specify macros with the C preprocessor #define statement and usually place them in the
process model header block. The header block may also contain #include statements, struct and
typedef definitions, extern variable declarations and global variable definitions, function
declarations, and comments in C and C++ style.
The next step is to define the ARRIVAL macro.
Click the Edit Header Block tool button. 1
An edit pad appears. 2Enter the following code into the edit pad:
#define ARRIVAL (op_intrpt_type () == OPC_INTRPT_STRM)
Choose File > Commit from the edit pad menu to
save the changes.
Choose File > Close to close the edit pad.
The ARRIVAL condition defined above tests if the current interrupt (which caused the FSM to
awaken and execute) occurred due to an arriving packet. It compares the value returned by the
Kernel Procedure op_intrpt_type() with the OPC_INTRPT_STRM constant. If the comparison
evaluates to true, this indicates that the interrupt is due to a packet arriving on an input stream.
You can declare variables in three places. Variables declared in the temporary variables block do
not retain their values between invocations of the FSM. Variables declared in the state variables
block retain their values from invocation to invocation. Variables declared inside a state’s executive
are only defined while that executive is executed.
The next step is to declare two state variables. One will store the value of the packet count; the other
is the “handle” for the local statistic used to analyze the count.
Click the Edit State Variables tool button. 1
Enter the following values into the dialog box:
Values for State Variables Dialog Box
Type Name Comments int pk_count Counts total packets Stathandle pk_cnt_stathandle Statistic to record packet count Clicking the value field for Comments opens an edit pad. After you type the comment, Choose
File > Commit. 3Click the OK button to save the changes and close the State Variables dialog box.
Statistics save values of interest for later analysis. When creating a statistic, you must declare that
statistic in the process model that records it. You will create one statistic for this process. 1
Enter packet count as the first Stat Name. Choose Interfaces > Local Statistics. The mode is automatically set to Single, count to
N/A, Low Bound to 0.0, and High Bound to
disabled. 3 Click in the Description field for packet count.
An edit pad opens.
4 Enter a short description for the statistic: Number of packets received. 5Choose File > Commit to save the changes and close the pad.
Declare Local Statistics Dialog Box 6Close the Declare Local Statistics dialog box by clicking the OK button. Create State Executives
The next step is to create the state executives needed in the FSM. In the first state, init, the
executives set the packet count to 0 and associate the name of the local statistic with its statistic
handle. Although the enter executives and exit executives of forced states are executed without
interruption, standard practice is to place all forced state executives in the enter executives block.
1Double-click on the top half of the init state.
Open the Enter Executives of the init State The Enter Executives edit pad opens.
2 Enter the following code to initialize the state variables pk_count and pk_cnt_stathandle:
pk_count = 0;
pk_cnt_stathandle = op_stat_reg ("packet count",
3Commit the changes and close the edit pad.
The second line of the preceding code registers the packet count statistic and sets up a handle for
the arrival state to use when recording the number of packets received.
The pk_count and pk_cnt_stathandle variables are state variables you defined, but the
op_stat_reg() function is a simulation Kernel Procedure (KP). Hundreds of built-in functions are
provided that you can use for a variety of purposes, such as manipulating a queue or creating
The numbers displayed in the workspace below each state indicate the line count for the enter and
exit executives of the state. Now that you have entered some code in the Enter Execs of the init state, the information has changed from 0/0 to 2/0. To toggle the display of these line counts, rightclick in the Process Editor workspace and choose Hide Line Counts. You can show them again
with the Show Line Counts menu.
Because there are so many functions, it can be difficult to determine the most appropriate one for a
particular task. However, a summary of the most frequently used KPs is provided. You will review
this summary in the next step of this tutorial, when you write the code for the Enter Execs in the
To define what happens in the arrival state, follow these steps:
Double-click on the top half of the arrival state.
The Enter Execs edit pad opens.
Now that you are In the arrival state, you need to increment the packet count, determine the packet
stream for the current interrupt, retrieve the pointer to the packet so that you can destroy it, and write
out the statistic. 2Increment the pk_count variable by entering the following code into the Enter Execs edit pad:
Determining the packet stream for the current interrupt, getting the packet’s pointer, and destroying
the packet is a bit more complex, but can be done using some of the KPs.
To determine the packet stream, get the pointer, and destroy the packet, you can use KPs from the
list of most commonly used KPs, the Essential Kernel Procedures. 3 Choose Help > Essential Kernel Procedures.
A list of the most frequently-used KPs opens in a
browser window. The first task—determining the packet stream for
the current interrupt—has to do with processing
an interrupt. Find the section called Interrupt
5From the KP descriptions, you determine that op_intrpt_strm() will return the necessary
The next two tasks, getting the packet’s pointer and using that pointer to destroy the packet, both
involve packet manipulation. Look in the Packet Generation and Processing section. You can
use op_pk_get() to determine the packet’s pointer, then use that return value (the pointer) to call
6op_pk_destroy() to destroy the packet.
You can type these function calls into the process model, or copy them from the Essential Kernel
Procedures file. In the following steps, you will copy these function calls. 7
7.1 Copy the op_pk_destroy() function call:
Go to the op_pk_destroy() function description in
Essential Kernel Procedures and select the function
syntax text. Copy and paste the function call into the enter
execs section of the arrival state, just after the
line where you incremented the packet count.
7.3Enter a semicolon at the end of the function call, so the line looks like this:
8Replace the pkptr argument with the following code: op_pk_get (op_intrpt_strm ())
The resulting line of code should look like this:
op_pk_destroy (op_pk_get (op_intrpt_strm ()));
The final task is to write out the value of the statistic. Refer to the Statistic Recording section for
information on the op_stat_write() KP.
The final code for the Enter executive of the arrival state should look like this:
op_pk_destroy (op_pk_get (op_intrpt_strm ()));
op_stat_write (pk_cnt_stathandle, pk_count);
Finally, save the enter exec code: 9Choose File > Commit, then close the edit pad.
The Essential Kernel Procedures are those that are most commonly used. Many additional KPs are
available. You can display a description of any KP by choosing Help > All Kernel Procedures from
the Process Editor menu.
In both KP help files, each KP name is a hypertext link to the KP documentation. Edit Process Interfaces
To control the attributes visible at the node level, edit the Process Interfaces. You can set initial
attribute values or hide attributes.
Choose Interfaces > Process Interfaces.
The Process Interfaces dialog box appears. 2 Change the Initial Value for the begsim intrpt
attribute to enabled.
This will cause the Simulation Kernel to deliver this
interrupt to the process model instance at the start
of the simulation.
Verify that the Initial Value for each of the
following attributes is set to disabled: endsim
intrpt, failure intrpts, intrpt interval, recovery
intrpts, and super priority. 3
Verify that the Initial Value of the priority attribute is 0. For all attributes, change the value of Status to hidden by left-clicking in the Status column and
5selecting hidden, so that the attributes will not appear in the node editor.
Changing the Value to “hidden” 6Click OK to close the Process Interfaces dialog box. Compile the Model All process models must be compiled before they can be used in a simulation. Compiling a model
makes its object code available to a processor module’s process model attribute.
To compile a process model:
Click the Compile Process Model tool button. 1 2 If you did not save your model previously, the
Save As dialog box opens. Save the process
model as <initials>_packet_count in your
A dialog box showing object type and compilation
status appears. Compilation Status Dialog Box Note: If an error message appears, close the error report and verify the code you have entered for
the process model so far. 3Click Close to close the dialog box.
If you did not save the process model before compiling it, you will also see this message:
Wrote File: (<file name>).
4Close the Process Editor. (If you left any edit pads open, they will close automatically.) Implementing the Node and Network Models
The node model in this lesson has two packet generator modules that send packets to a general
processor module. The processor module uses the previously defined packet_count process to
count and discard packets and to update an output statistic. Note that the process model could
accept any number of incoming packet streams because it automatically determines the correct
stream when an interrupt occurs. Create the Node Model
First, create a node model that uses the packet_count process.
Choose File > New…, then select Node Model
from the pull-down menu. Click OK.
2Use the Create Processor toolbar button to create three processor modules. Right-click to stop
Use the Create Packet Stream toolbar button to connect the modules with packet streams as
shown below. Right-click to stop adding connections. The model should resemble the following
Initial Node Model Now change the attributes of each module. The first processor module, p_0, will be a generator
Right-click on the icon and select Edit Attributes
from the pop-up menu to open the module’s
Attributes dialog box.
Change the name attribute to src1. 3
Click on OK to close the dialog box. Change the process model attribute to
simple_source. The second processor module, p_1, will count packets:
Open the Attributes dialog box of the module.
Change the name attribute to count. 3
Click on OK to close the dialog box. Change the process model attribute to
<initials>_packet_count. Set up the third processor module to generate packets:
Open the Attributes dialog box of the module.
Change the name attribute to src2.
Change the process model attribute to
4Click on Packet Interarrival Time in the left column to highlight the Attribute name, then right-click
and select Promote Attribute to Higher Level from the pop-up menu.
The word promoted is displayed in the Value cell of the attribute.
Promoting the Attribute 5Click on OK to close the dialog box.
Both generators send packets to count. The first generator sends packets at a constant rate of one
packet/second and the second generator sends packets at a variable rate, following a distribution
you will specify. Sometimes it is convenient or necessary to make a statistic available at the node level. A statistic
promoted to the node level can be renamed and given a different description. Before saving the
node model, promote the packet count statistic and rename it.
Choose Interfaces > Node Statistics.
2Click the first field in the Orig. Name column, select count.packet count from the list that appears,
and click Promote. 3
Change the Prom. Name to node packet count.
Change the Desc. field to Number of packets received at the node level.
Choose File > Commit from the Description edit
pad’s menu to save the text and close the edit
Close the Statistic Promotion dialog box by clicking the OK button. 7
Close the Node Editor. Choose File > Save and save the node model as
<initials>_packet_count. (The node and process
models can have the same name because
OPNET appends .nd.m to each node model and
.pr.m to each process model.) Create the Network Model
The network model for this lesson consists of a single node using the packet_count node model.
After placing the node in the Project Editor workspace, you can specify statistics and animations to
First, create a new project.
Choose File > New..., and click OK open a new
Name the project <initials>_packet_count and the scenario constant. 3Choose Quit on the first screen of the Startup Wizard.
Second, create a custom object palette.
Open the object palette by clicking on the 1
Open Object Palette tool button.
Switch to the icon view by clicking on the button in the upper-left corner of the object palette.
Click the Configure Palette… button.
Click the Clear button in the Configure Palette dialog box to remove all but the default icons from
4the palette. The subnet icon remains. (If you have Wireless functionality, the mobile and satellite
subnet icons remain as well.) Click the Node Models button and set the Status
of the <initials>_packet_count node model to
Click OK to close the Select Included Entries dialog box. Three versions of the <initials>_packet_count
node are added to the custom object palette:
fixed, mobile, and satellite.
7 Click OK to close the Configure Palette dialog box. 8At the prompt, save the custom model list as <initials>_packet_count.
Next, place the node in the workspace and select the proper statistics for collection.
Place an <initials>_packet_count fixed node in
the workspace, then close the object palette.
2Right-click on the node to open its Object pop-up menu, then select Choose Individual
DES Statistics from the sub-menu.
The Choose Results statistic browser appears.
Selecting Statistics Select the Animations > Node Animation
Select the Node Statistics > node packet count checkbox. 5 Right-click on Node Statistics >
node packet count to open its Statistic pop-up
menu, and choose Record Statistic Animation.
The Record statistic animation checkbox in the
Data collection area of the dialog box becomes
selected. You can also use that checkbox to toggle
the animation on or off. Record Statistic Animation Checkbox 6Click OK to close the browser window.
In the preceding steps, you:
• Created an animation of packet flow within the node (Animations > Node Animation).
Specified that the node packet count statistic be collected (Node Statistics > node packet count).
Specified that the node packet count statistic be animated.
When you built the node model, you changed the Packet Interarrival Time attribute for the second
generator module to promoted so that you could specify it later.
Now, you will specify the distribution for that attribute.
Right-click on the node to open its Object pop-up
menu, then choose Edit Attributes.
Click on promoted in the value column of src2.Packet Interarrival Time.
The Distribution Specification dialog box appears.
3 Verify that Distribution name is constant and Mean outcome is 1.0.
Distribution Specification Dialog Box 4
Click OK to close the Attributes dialog box. Click OK to close the Specification dialog box. To configure the simulations:
Choose DES >
Configure/Run Discrete Event Simulation…
Set the following values in the Configure DES dialog box:
— Duration: 100 seconds
Seed: 1471 — Values per statistic: 100
Expand the Outputs tree element, then the Animation element. Click on 2D and verify that the
3 Send animation to history file checkbox is selected.
Click on Apply to save the change, then Cancel to close the Configure/Run DES dialog box
4without running the simulation.
To investigate the effect of different PDFs, you can create new scenarios based on this one. After
simulating them, you can then compare the results. To create a new scenario and set the PDF:
Choose Scenarios > Duplicate Scenario...
Name the new scenario exponential. Click OK to save the file. 3 Right-click on the node and choose Edit Attributes from the Object pop-up menu.
4Click on the Value column of src2.Packet Interarrival Time; this opens its Specification dialog
Click OK to close the Specification dialog box.
Save the project as <initials>_packet_count. Select exponential from the Distribution name
pull-down menu and verify that Mean outcome is
set to 1.0. Click OK to close the Attributes dialog box. Running the Simulation
You are now ready to configure and run the simulations. You can run both simulations with one
command from the Manage Scenarios dialog box.
To configure the repositories:
Choose Edit > Preferences.
2Verify the Network Simulation Repositories preference is set to (), then click Cancel. If it is not
empty, delete all entries and click OK to close the dialog box.
To run the simulations: 3
Choose Scenarios > Manage Scenarios…
Change the value of the Results column for each scenario from uncollected to <collect>.
5 Click OK to begin the simulation runs.
The DES Execution Manager dialog box opens,
showing two planned simulations (one run for each
scenario). As each simulation executes, its
information is updated in that dialog box. DES Execution Manager Dialog Box The simulations should take less than one minute. If you have problems, see "Troubleshooting
Tutorials". 6Close the DES Execution Manager dialog box. Analyzing the Results
View results in the Project Editor. If necessary, switch to the exponential scenario
by choosing Scenarios > Switch To Scenario >
Right-click on node_0 and choose View Results from the node_0 pop-up menu. The Results Browser opens, showing the
statistics you can view.
In the results tree (lower-left), select the checkbox for Object Statistics > node_0 >
3 node packet count.
Results Browser 4Click the Show button to display the graph.
The resulting graph shows the number of packets received by the count processor module over time
during the simulation.
Number of Packets Received As illustrated in this graph, the results of the simulation indicate the total number of packets received
steadily increases over the simulation duration, though not at a perfectly constant rate. As expected,
with two sources delivering packets each at a mean of 1 packet/second, the total number of packets
received after 90 seconds of packet generation (packet generation commences after 10s of
simulation time) is about 180.
A close-up visual examination of the graph reveals more detail. To see the detail, magnify the graph.
Drag the cursor along the graph, selecting a box that covers the trace from 20 seconds to
51 minute on the time axis.
Select the Area to Magnify The graphs changes to a close-up of the selected graph area.
Magnified Area You can contrast the graph of the packet count in the exponential scenario with the one in the
constant scenario. 6
Close the current graph and click Delete.
7In the Results Browser, click on the drop-down list next to Results for: and select
The Results tree shows available data files for all scenarios of the current project.
Viewing all Scenarios’ Output for a Project Switch to the constant scenario by selecting
<initials>_packet_count > constant, then
unselecting <initials>_packet_count >
Show the graph for Object Statistics > node_0 > node packet count. Zoom in on a portion of this graph as you did for
the last graph.
Magnified (as shown in the following figure), this graph reveals a step pattern that results from the
two generators sending packets at the same constant arrival rate.
Zooming Reveals Step Pattern A discrete graph of this data will illustrate the true quantized property of the counting statistic and the
underlying event-driven property of the packet arrivals.
Right-click on the graph to open the Graph pop-up
2 Choose Draw Style > Discrete from the Graph pop-up menu.
The graph now displays the data as individual points. The discrete plotting style depicts only the
discrete statistic values without connecting them.
Discrete Draw Style Applied The discrete graph reveals that the Simulation Kernel repeatedly delivered two packets during each
second of simulation time, each of which was counted separately. The graph also shows the eventscheduled nature of the Simulation Kernel. The simultaneous events (multiple packets arriving every
second) caused the Simulation Kernel to advance simulated time once, but invoke the
packet_count process twice. In turn, the packet_count process incremented the packet count
statistic once each time it was invoked. 13 Close the graph dialog box, then click Delete. 1
4 Close the Results Browser.
Finally, you can view the animations created during the simulation. The animation viewer allows you
to view statistic and packet animations.
Choose DES > Play 2D Animation.
The Animation Viewer opens, showing the statistics
animation for the exponential scenario.
To see the packet animation, choose Windows >
Animation Viewer > top.node_0 packet flow.
This animation shows the packets moving from
each generator to the count module. 2
To exit the Animation Viewer, choose File > Exit.
Note that the Project Editor is still open. To view the animations for the constant scenario,
change to the constant scenario (Scenarios >
Switch to Scenario > constant), and then
choose DES > Play 2D Animation.
The animation for the constant scenario appears. 4 5. Exit the Animation Viewer.
For more information about the Animation Viewer, see Animation Viewers Reference Manual.
You have now completed the Basic Processes lesson of the tutorial. You should have a good
understanding of how to control node behavior by creating custom process models.
The next lesson, Packet Switching, explores the creation of a packet switching network.
To continue with the next lesson, save your work and close all open editor windows. Return to the
list of tutorials in the Contents pane and choose Packet Switching I. Related Topics Popup Popup See Also Popup Home
© 1986-2010 OPNET Technologies, Inc. All Rights Reserved. This software may be covered by one or more U.S. Patents. See
complete patent notice in the Legal Notices section.
OPNET Support Center ...
View Full Document
- Spring '11