01 Modeling Overview

8/6/2019 01 Modeling Overview

1/62

1-Ov

Modeling OverviewChapter 1


2/62

2-Ov

Modeling Concepts


3/62

3-Ov

Modeling Concepts

Introduction

Ov.1 Introduction

OPNET provides a comprehensive development environment supporting the

modeling of communication networks and distributed systems. Both behavior and

performance of modeled systems can be analyzed by performing discrete event

simulations. The OPNET environment incorporates tools for all phases of a study,

including model design, simulation, data collection, and data analysis.

This chapter provides an overview of OPNETs capabilities and structure. It is

intended to provide an introduction to the package and context for further reading

of the documentation. The chapter is divided into five sections, as follows:

This chapter is designed to allow reading at two levels: detailed

and

conceptual

. For more detailed information, merely read the paragraph text, as you

would a traditional text. To cover the information more quickly, remain at a

conceptual level by reviewing only tables, diagrams, bullet list headings, and

special key concepts

boxes, as shown below. If you require more detail on a

particular topic, read only the paragraphs in the corresponding section.

Overview Chapter: Content Summary

Section Topic

Key System Features Enumerates salient and distinctivecharacteristics of the OPNET software.

Typical Applications Presents some applications typically addressedwith OPNET and some of the features thatprovide direct support for those applications.

Architecture Describes the OPNET approach to each phase

of the modeling and simulation project. Presentsfundamental modeling constructs.

Tools Introduces the tools that constitute the OPNET

environment. Each tool supports a particularphase or sub-phase of the simulation andmodeling project.

Authoring Capabilities Discusses the use of OPNET as an authoringtool to prepare models for off-the-shelf use byend users in the IT DecisionGuru or Modeler XE

environments.


4/62

4-Ov

Introduction

Modeling Concepts

Ov.1.1 Multiple User Communities

OPNET users can be divided into two broad categories: system modelers

and

authors

. System modelers are the traditional users of OPNET, who study technical

problems using simulation. They are usually interested in performance measures

and behavioral analysis of a proposed system. Often they are designers of

networks, network devices and protocols, or distributed applications. Authors, on

the other hand, do not use OPNET to conduct their own simulation studies, but to

prepare an environment for others to do so. OPNET Modeler is used to create

customized models that are appropriate for a particular type of end user. Themodels are typically delivered to the end user in the Modeler XE environment,

which offers the benefit of greater simplicity and ease of use.

Refer to the end of this chapter for more information on specific features of

OPNET that support its use as an authoring tool.

OPNET exists as both a core

product, and in a Radio version (using the

optional Radio module). Modeler, in conjunction with the Radio module, provides

specific features to support projects related to wireless networking. It includes,

among other radio-specific capabilities, the ability to model node mobility and the

effects of interference on radio link performance. Of course, many projects do not

require radio capability and these can be carried out with the core version.Throughout this manual, indications are provided when features specific to the

Radio version are discussed.

Key Concepts

To quickly cover the material in this chapter, simply skip over para-graph text, reviewing only tables, diagrams, bullet list headings, andkey conceptsboxes such as this one.

Key Concepts

OPNET Modeler is used to construct models for two different pur-

poses: to study system behavior and performance; and to deliver amodeling environment to end users with products such as IT Guru.


5/62

5-Ov

Modeling Concepts

Key System Features

Ov.2 Key System Features

OPNET is a vast software package with an extensive set of features designed to

support general network modeling and to provide specific support for particular

types of network simulation projects. This section provides only a brief

enumeration of some of the most important capabilities of OPNET. Subsequent

sections of this chapter provide more detailed information on these features, as

well as other aspects of OPNET.

Object orientation

. Systems specified in OPNET consist of objects,each with configurable sets of attributes. Objects belong to classeswhich provide them with their characteristics in terms of behavior andcapability. Definition of new classes are supported in order to addressas wide a scope of systems as possible. Classes can also be derived fromother classes, or specialized in order to provide more specific supportfor particular applications.

Specialized in communication networks and information systems

.

OPNET provides many constructs relating to communications and in-formation processing, providing high leverage for modeling of net-works and distributed systems.

Hierarchical models

. OPNET models are hierarchical, naturally paral-leling the structure of actual communication networks.

Graphical specification

. Wherever possible, models are entered viagraphical editors. These editors provide an intuitive mapping from themodeled system to the OPNET model specification.

Flexibility to develop detailed custom models

. OPNET provides aflexible, high-level programming language with extensive support forcommunications and distributed systems. This environment allows re-alistic modeling of all communications protocols, algorithms, andtransmission technologies.

Automatic generation of simulations

. Model specifications are auto-matically compiled into executable, efficient, discrete-event simula-tions implemented in the C programming language. Advancedsimulation construction and configuration techniques minimize compi-lation requirements.

Application-specific statistics.

OPNET provides numerous built-inperformance statistics that can be automatically collected during simu-lations. In addition, modelers can augment this set with new applica-tion-specific statistics that are computed by user-defined processes.

Integrated post-simulation analysis tools

. Performance evaluation,and trade-off analysis require large volumes of simulation results to be


6/62

6-Ov

Key System Features

Modeling Concepts

interpreted. OPNET includes a sophisticated tool for graphical presen-tation and processing of simulation output.

Interactive analysis

. All OPNET simulations automatically incorpo-rate support for analysis via a sophisticated interactive debugger.

Animation

. Simulation runs can be configured to automatically gener-

ate animations of the modeled system at various levels of detail and caninclude animation of statistics as they change over time. Extensive sup-port for developing customized animations is also provided.

Application program interface (API)

. As an alternative to graphicalspecification, OPNET models and data files may be specified via a pro-grammatic interface. This is useful for automatic generation of modelsor to allow OPNET to be tightly integrated with other tools.


7/62

7-Ov

Modeling Concepts

Typical Applications of OPNET

Ov.3 Typical Applications of OPNET

As a result of the capabilities that were described in the previous sections,

OPNET can be used as a platform to develop models of a wide range of systems.

Some examples of possible applications are listed below with specific mention of

supporting features:

Standards-based LAN and WAN performance modeling

detailedlibrary models provide major local-area and wide-area network proto-cols. Configurable application models are also provided by the library,or new ones can be created.

Internetwork planning

hierarchical topology definitions allow arbi-trarily deep nesting of subnetworks and nodes and large networks areefficiently modeled; scalable, stochastic, and/or deterministic modelscan be used to generate network traffic.

Research and development in communications architectures and

protocols

OPNET allows specification of fully general logic and pro-vides extensive support for communications-related applications. Fi-nite state machines provide a natural representation for protocols.

Distributed sensor and control networks

, on-board systems

OPNET allows development of sophisticated, adaptive, application-level models, as well as underlying communications protocols andlinks. Customized performance metrics can be computed and recorded,scripted and/or stochastic inputs can be used to drive the simulationmodel, and processes can dynamically monitor the state of objects inthe system via formal interfaces provided by statistic wires.

Resource sizing

accurate, detailed modeling of a resources request-processing policies is required to provide precise estimates of its per-formance when subjected to peak demand (for example, a packetswitchs processing delay can depend on the specific contents and typeof each packet as well as its order of arrival). Queuing capabilities of

Proto-C

provide easy-to-use commands for modeling sophisticatedqueuing and service policies; library models are provided for manystandard resource types.

Mobile packet radio networks

specific support for mobile nodes,including predefined or adaptive trajectories; predefined and fully cus-

tomizable radio link models; geographical context provided by OPNETnetwork specification environment. (Radio version only)

Satellite networks

specific support for satellite nodes, including au-tomatic placement on specified orbits, a utility program for orbit gener-ation, and an orbit visualization and orbital-configuration animationprogram. (Radio version only)


8/62

8-Ov

Typical Applications of OPNET

Modeling Concepts

C3I and tactical networks

support for diverse link technologies;modeling of adaptive protocols and algorithms in Proto-C; notificationof network component outages and recoveries; scripted and/or stochas-tic modeling of threats; radio link models support determination offriendly interference and jamming.


9/62


10/62


11/62

11-Ov

Modeling Concepts

OPNET Architecture

editor has its own specific set of objects and operations that are appropriate for the

modeling task on which it is focused. For instance, the Project Editor makes use of

node and link objects; the Node Editor provides processors, queues, transmitters,

and receivers; and the Process Editor is based on states and transitions. As a result,

the diagrams developed in each editor have a distinct appearance, as shown in the

following screen samples.

Ov.4.1.2 Modeling Domains

The Network, Node, and Process modeling environments are sometimes

referred to as the modeling domains

of OPNET, since they essentially span all the

hierarchical levels of a model. The remaining specification editors correspond tono particular modeling domain since they mainly support the three principal

editors. As mentioned earlier, the capabilities offered by the three modeling

domains mirror the types of structures found in an actual network system; the

issues addressed by each domain are summarized in the following table and then

briefly described in the remainder of this section.

Graphical Editors for Network, Node, and Process Models

Project Editor

Node Editor

Process Editor


12/62

12-Ov

OPNET Architecture

Modeling Concepts

Network Domain

The Network Domains role is to define the topology of a communication

network. The communicating entities are called nodes and the specific capabilities

of each node are defined by designating their model

. Node models are developedusing the Node Editor, discussed later in this section. Within a single network

model, there may be many nodes that are based on the same node model; the term

node instance

is used to refer to an individual node, in order to distinguish it from

the class of nodes sharing the same model. However, in general, when the term

node

is used by itself, in the context of the network domain, it can be assumed that

a node instance is being referred to, rather than a node model.

A network model may make use of any number of node models. OPNET does

not place restrictions on the types of nodes that can be deployed in a

communication network; instead it adopts an open approach whereby modelers

can develop their own library of node models to use as building blocks fornetwork models. In addition, there are no limits on the number of node models or

node instances that a network model may contain (other than those imposed by

workstation memory limitations).

The Project Editor can provide a geographic context for network model

development. You can choose locations on world or country maps for the elements

of wide-area networks and can use dimensioned areas for local-area networks. In

addition to providing an intuitive environment for deploying the components of a

OPNET Modeling Domains

Domain Editor Modeling Focus

Network Project Network topology described in terms ofsubnetworks, nodes, links, and geographical

context.

Node Node Node internal architecture described in terms offunctional elements and data flow between them.

Process Process Behavior of processes (protocols, algorithms,applications), specified using finite state machinesand extended high-level language.

Key Concepts

A network model may contain any number of communicating entitiescalled nodes. Nodes are instances of node models, developed using

the Node Editor. Modelers can develop their own library of custom-ized node models, implementing any functionality they require.


13/62

13-Ov

Modeling Concepts

OPNET Architecture

network model, this feature provides an intrinsic notion of distance, which allows

automatic calculation of communication delays between nodes.

The basic object used to build network models is the fixed

communication

node. In OPNET, this is the only type of node available. Fixed nodes can be

assigned arbitrary locations, but during a simulation their location may not change.

OPNET Radio versions allow networks to contain fixed nodes, but also add

capability for mobile

and satellite

nodes. Mobile nodes can be assigned predefinedtrajectories that specify their positions as a function of time throughout a

simulation run; similarly, satellite nodes are assigned orbits that prescribe their

motion. With the Radio version, simulations can involve all three types of nodes.

Most nodes require the ability to communicate with some or all other nodes to

perform their function in a network model. Several different types of

communication link architectures are provided to interconnect nodes that

communicate with each other. OPNET provides simplex (unidirectional) and

duplex

(bidirectional)point-to-point links

to connect nodes in pairs and a bus link

to allow broadcast communication for arbitrarily large sets of fixed nodes. The

Radio version adds the capability for fixed, satellite, and mobile nodes tocommunicate with each other via radio links

. While bus and point-to-point links

are modeled as explicit objects that you must create, radio links are dynamically

evaluated based on characteristics of the communicating nodes. As will be

discussed in later chapters, each type of link can be customized by editing

parameters or supplying new logic for the underlying link models. The following

figures show some typical network model diagrams involving each of the

supported link types.

Key Concepts

Network models consist of nodes and links which can be deployedwithin a geographical context. OPNET provides fixed nodes andpoint-to-point and bus links; the Radio version in addition provides

mobile and satellite nodes, and radio links.


14/62

14-Ov

OPNET Architecture

Modeling Concepts

To break down complexity and to simplify network protocols and addressing,

many large networks make use of an abstraction known as a subnetwork

. A

subnetwork is a subset of a larger networks devices that forms a network in its

own right. OPNET provides fixed, mobile, and satellite subnetworks to enhance

network models. These subnetworks can then be connected by different types of

communication links, depending on the type of subnetwork. The larger network

can then be viewed as a network of its subnetworks. This abstraction can be carried

out at many levels. In other words, one can form networks of subnetworks, which

in turn are formed of other subnetworks, and so on. At the bottom of this hierarchy,

the lowest level subnetwork is composed only of nodes and links, but no other

subnetworks.

Network Models with Radio, Bus, and Point-to-Point Links

Radio Links

Bus Link

Point-to-Point Links

Key Concepts

Fixed, mobile, and satellite subnetwork objects provide hierarchy inthe network model and are used to break down complexity into multi-

ple levels. Subnets can contain various combinations of nodes, links,and other subnets, and can be nested to any depth.


15/62

15-Ov

Modeling Concepts OPNET Architecture

In OPNET network models, subnetworks can be nested to an unlimited depth

to construct complex topologies. The following set of diagrams, captured in the

Project Editor, illustrate the use of fixed subnetworks to model hierarchical

networks.

Node Domain

The Node Domain provides for the modeling of communication devices thatcan be deployed and interconnected at the network level. In OPNET terms, these

devices are called nodes, and in the real world they may correspond to various

types of computing and communicating equipment such as routers, bridges,

workstations, terminals, mainframe computers, file servers, fast packet switches,

satellites, and so on.

A Hierarchical Network with Two Levels of Subnetworking


16/62

16-Ov

OPNET Architecture Modeling Concepts

Node models are developed in the Node Editor and are expressed in terms of

smaller building blocks called modules. Some modules offer capability that is

substantially predefined and can only be configured through a set of built-in

parameters. These include various transmitters and receivers allowing a node to be

attached to communication links in the network domain. Other modules, called

processors and queues, are highly programmable, their behavior being prescribed

by an assigned process model. Process models are developed using the Process

Editor.

A node model can consist of any number of modules of different types. Three

types of connections are provided to support interaction between modules. These

are called packet streams, statistic wires (also sometimes referred to as streams and

statwires, respectively), and logical associations. Packet streams allow formatted

messages called packets to be conveyed from one module to another. Statistic

wires convey simple numeric signals or control information between modules, and

are typically used when one module needs to monitor the performance or state of

another. As will be discussed later in this manual, both packet streams and statistic

wires have parameters that may be set to configure aspects of their behavior.

Logical associations identify a binding between modules. Currently, they areallowed only between transmitters and receivers in order to indicate that they

should be used as a pair when attaching the node to a link in the Network Domain.

The following diagram illustrates a typical node model that includes the three

types of connections.

Key Concepts

Node models consist of modules and connections. Modules are infor-mation sources, sinks, and processors. Some modules have pre-defined behavior; processor and queue modules are programmable

via their process model. Connections (packet streams and statisticwires) allow information to flow between modules.


17/62

17-Ov


The modeling paradigm selected for the Node Domain was designed to support

general modeling of high-level communication devices. It is particularly wellsuited to modeling arrangements of stacked or layered communication

protocols. In the Node Editor, a device that relies on a particular stack of protocols

can be modeled by creating a processor object for each layer of that stack and

defining packet streams between neighboring layers, as shown in the following

diagram for the familiar TCP/IP stack.

Process Domain

As mentioned earlier in the discussion of the Node Domain, queue and

processor modules are user-programmable elements that are key elements of

communication nodes. The tasks that these modules execute are calledprocesses.

A process can in many ways be thought of as similar to an executing software

program, since it includes a set of instructions and maintains state memory.

Processes in OPNET are based on process models that are defined in the Process

Editor. The relationship between process model and process is similar to the

relationship between a program and a particular session of that program running as

Node Model Employing Packet Streams, Statistic Wires,and Logical Associations

statistic wire

packet stream

logical association

Possible OPNET Representation of TCP/IP Protocol Stack


18/62

18-Ov


a task (in fact, the term process is used in many operating systems as well). Just

as nodes created in the Project Editor are instances of node models defined with

the Node Editor, each process that executes in a queue, processor, or esys module

is an instance of a particular process model.

The process modeling paradigm of OPNET supports the concepts ofprocess

groups. A process group consists of multiple processes that execute within the

same processor or queue. When a simulation begins, each module has only one

process, termed the root process. This process can later create new processes

which can in turn create others as well, etc. When a process creates another one, itis termed the new process parent; the new process is called the childof the

process that created it. Processes that are created during the simulation are referred

to as dynamic processes.

OPNET places no limits on the number of processes that may be created in a

particular processor or queue. Processes may be created and destroyed based on

dynamic conditions that are analyzed by the logic of the executing processes. This

paradigm provides a very natural framework for modeling many common systems.

In particular, multitasking operating systems where the root process represents the

operating system itself and the dynamically created processes correspond to new

tasks; and multi-context protocols where the root process represents a sessionmanager, for example, and each new session that is requested is modeled by

creating a new process of the appropriate type.

Only one process may be executing at any time. A process is considered to be

executing when it is progressing through new instructions that are part of its

process model. When a process begins execution it is said to be invoked. A process

that is currently executing can invoke another process in its process group to cause

it to begin executing. When this happens, the invoking process is temporarily

suspended until the invoked process blocks. A process blocks by indicating that it

Key Concepts

Process models define behavior for programmable modules. A pro-cess is an instance of a process model and operates within one mod-

ule.

Key Concepts

Initially, each programmable module contains only one process; how-

ever, processes can create additional child processesdynamically.These can in turn create additional processes themselves. This para-

digm is well-suited to modeling systems with dynamically instantiatedcontexts, like certain protocols, or multi-tasking operating systems.


19/62

19-Ov


has completed its processing for its current invocation. Once the invoked process

has blocked, the invoking process resumes execution where it had left off, in a

manner similar to the procedure-call mechanism in a programming language such

as C.

Processes in OPNET are designed to respond to interrupts and/or invocations.

Interrupts, which are discussed in significant detail in later sections of this manual,

are events that are directed at a process and that may require it to take some action.They may be generated by sources external to a process group, by other members

of a process group, or by a process for itself. Interrupts typically correspond to

events such as messages arriving, timers expiring, resources being released, or

state changes in other modules. Once a process has been invoked due to an

interrupt, it may invoke other processes in the group and these may in turn invoke

other processes, etc. An interrupts processing is completed when the first process

that was invoked blocks.

OPNETs Process Editor expresses process models in a language called

Proto-C, which is specifically designed to support development of protocols and

algorithms. Proto-C is based on a combination of state transition diagrams (STDs),

a library of high-level commands known as Kernel Procedures, and the general

facilities of the C or C++ programming language. A process models STD defines aset of primary modes or states that the process can enter and, for each state, the

conditions that would cause the process to move to another state. The condition

needed for a particular change in state to occur and the associated destination state

are called a transition. The following example, taken from the Process Editor,

shows the relationship between states and transitions in a process models STD.

Key Concepts

Processes respond to interrupts, which indicate that events of interesthave occurred such as the arrival of a message or the expiration of atimer. When a process is interrupted, it takes actions in response andthen blocks, awaiting a new interrupt. It may also invoke another pro-

cess; its execution is suspended until the invoked process blocks.


20/62

20-Ov


Proto-C models allow actions to be specified at various points in the finite state

machine. The actions can be extremely general in nature since they are expressed

as C or C++ statements. In addition, because Proto-C is focused on modeling

protocols and algorithms, it provides an extensive library of over 300 Kernel

Procedures (also known as KPs) that can be invoked to perform commonly needed

actions. Kernel Procedures are grouped into packages of related functions. The

following table shows some of the capabilities provided by the Kernel Procedurelibraries.

Major Simulation Kernel Procedure Packages

Package Applications

Anim Support for custom animation development

Dist Probability distribution and random number generation

State Transition Diagram in the Process Editor

Key Concepts

Process models are expressed in Proto-C, a language combining

graphical state-transition-diagrams, embedded C/C++ language dataitems and statements, and a library of Kernel Procedures that providecommonly needed functionality for modeling communications and

information processing systems.


21/62

21-Ov


The state transition diagram representation of Proto-C is well suited to the

specification of an interrupt-driven system because it methodically decomposes the

states of the system and the processing that should take place at each interrupt.

STDs developed in OPNETs Process Editor have a number of extensions beyond

the capabilities offered by traditional state-transition diagram approaches:

State Variables. Processes maintain private state variables withnamed variables of arbitrary data types, including OPNET-specific,general C/C++ language, and user-defined types. This capability allowsa process to flexibly maintain counters, routing tables, statistics related

Ev Event list and event property query; event cancellation

Ici Formal interfaces between processes; association of information withinterrupts

Id Identification of objects

Ima In-simulation query and modification of object attributes

Intrpt Query of interrupt properties; control of interrupt handling

Pk Creation, destruction, modification, analysis, and transmission of packets

Prg Programming support: linked lists, memory, string manipulation, debugging

Pro Creation, invocation of processes; process group shared memory

Q Queueing statistics; high-level queueing operations

Rad Dynamically changing a radio transmitter channels receiver group (Radio

version only)

Rte Basic routing support for static routing implementations

Sar Segmentation and reassembly of packets

Sim Simulation control: customized messaging, simulation execution control

Stat Custom statistic generation; intermodule signalling via statistic wires

Strm Communication between modules via packet streams, packet delivery

Subq Low-level queueing operations: enqueueing, dequeueing, statistics, etc.

Tbl Accessing of tabular data: antenna patterns, modulations

Tim Importing traffic into an existing OPNET network model

Td Setting and getting of transmission data for custom link models

Topo Query of model topology (e.g., for automatic discovery and configuration)

Major Simulation Kernel Procedure Packages (Cont.)

Package Applications


22/62

22-Ov


to its performance, or messages requiring retransmission. Arbitrarycombinations of state variable values may be used in all decisions andactions implemented by a process.

State Executives. Each state of a process can specify arbitrarily com-plex actions associated with the process entering or leaving that state.These actions, called state executives, are expressed with the full flexi-bility of the C/C++ language. Typical actions include modifying state

information, creating or receiving messages, updating the contents ofand sending messages, updating statistics, and setting or responding totimers.

Transition Conditions. Transition condition statements, which deter-mine whether a transition should be traversed, may be expressed asgeneral C/C++ language booleans that make reference to properties ofa new interrupt as well as to combinations of state variables.

Transition Executives. Transitions may specify general actions, calledexecutives, that are implemented each time that they are traversed.

Process Model Attributes

A process model may define parameters, called attributes, that are used once it

is instantiated as a process to customize aspects of its behavior. This technique

fosters reuse of process models for various purposes by avoiding hardwired

specification where possible. For instance, a process model that performs window-

based flow control, may be defined with the window size as an attribute, so that it

is reusable in different situations requiring different values of the window size.

Ov.4.1.3 Models, Objects, and Attributes

The preceding sections have discussed certain major OPNET model types andobjects. In this section, the OPNET object model is presented in greater detail.

Wherever possible, information is presented in a manner which is independent

from particular modeling domains, except when focusing on examples.

Objects

Objects represent entities that are part of the system of interest. In general, an

object is a component, or building block of a model and the object is said to be

part of that model. So for example, a processor module is an object that is part of

a node model. An object generally plays one or more of the following roles in a

model:

Typical Roles of an Object in a Model

Specify behavior

Create information

Store and manage information


23/62

23-Ov


Objects are created by various mechanisms in OPNET models. Many result

from explicit specification by the user via graphical or programmatic methods. So

for example, a link object may be created in a network model by physically

dragging it from the Project Editors object palette. Other objects are created

automatically by the system. For example, subqueue objects are automatically

created for a queue object. Similarly, when a node object is created, the objects

within the node are also implicitly assumed to exist. Finally, during simulation,

some objects are created dynamically by the system or by the model. A process,

for example, can be considered an object and may be created at any time by

another process in order to perform a task. Dynamic objects are different in many

ways than the statically created OPNET objects; in particular they offer morespecialized interfaces, allowing them to be manipulated in a more efficient manner.

Most of the discussion in this section will not apply to dynamic objects.

Attributes

In order to achieve predictable and tractable behavior when building a complex

many-object system, each object must offer a well-defined interface. The interface

of an OPNET object consists primarily of the attributes that it makes available and

the procedures that it supports to access its attributes or to cause it to perform

actions. Some procedures supported by objects are provided automatically by

OPNET; others are programmed by users for specialized needs. Most procedures

vary according to the object type, and so few general comments can be made about

them except to say that it is crucial that they have a well known interface and thatthey shield users from underlying details of object implementation.

Process, modify, or relay information

Respond to events

Contain other objects

Attribute Components

Name

Typical Roles of an Object in a Model

Key Concepts

Objects are the building blocks of OPNET models and appear in eachof the modeling domains. Some objects are created explicitly by the

user; others are implicitly created by OPNET. During a simulation,certain types of objects can be created dynamically.


24/62


25/62

25-Ov


Models

It was mentioned that many OPNET models (network, node, and process)

consist largely of objects. At the same time, most objects have a model that

confers upon them some or all of their characteristics. The object is said to be an

instance of the model, since there is a many-to-one relationship between a model

and the objects that refer to it. The model defines an object class that all of the

related objects belong to.

Some of OPNETs objects are fundamental and have an implicit model that

cannot be changed by the user. For example, state objects in process models aresimple objects whose only means of external control is provided by their attributes.

Their characteristics and behavior are defined and documented and these constitute

their model; however, their fundamental behavior and structure are always similar

and cannot be changed. Thus they offer no model attribute.

However, several key objects in OPNET offer a model attribute that allows

their fundamental behavior and structure to be controlled externally. In fact,

altering an objects model can even cause it to acquire a completely new interface.

Indeed, these objects are fundamentally quite generic, and most of their

characteristics are obtained from the model that they refer to. The following table

enumerates the OPNET objects that support a model attribute.

In each of the model types listed in the table above, a models interface is

specified. One of the characteristics transferred to an object from its model is its set

of attributes. The model dictates which new attributes will be acquired by the

object, and what their names and values will be. Similarly, it can specify values for

attributes that intrinsically belong to the object and can also cause these to become

Objects Supporting Model Assignment

Object Modeling

Domain

Model Type

Node (all types) Network Node

Link (all types) Network Link

Processor Node Process

Queue Node Process

Key Concepts

Objects provide attributes as a means of controlling their behavior.The attributes constitute part of the objects interface. Each attributehas a name, a value, and properties. Properties specify the rules gov-

erning the attributes use, including its data type, allowable values,suggested values, and documentation.


26/62

26-Ov


hidden from the user. Thus, the model can completely control the attribute

interfaces of the object.

Model Attributes and Attribute Promotion

With both models and attributes introduced as concepts, the notion of a model

attribute can be defined. In addition to describing objects, attributes can be

associated with models in order to represent a parameter of the model. This was

already briefly mentioned in the case of process models in a previous section. The

importance of providing a parameter for a model lies in increasing the generality ofthe model. By varying the values of the models parameter, a user can alter its

behavior in some well-defined manner, without having to actually modify the

model itself. This approach can be contrasted with hardwiring the value of the

attribute into the model itself, which exposes no control to the models user.

Obtaining the behavior corresponding to a new value of the attribute would then

require complete duplication of the model and a change to the hard-wired value.

Multiple versions of the model would then have to be maintained in a parallel

manner over time, which is clearly undesirable. The model attributes mechanism

therefore supports increased reusability of models.

In concrete terms, model attributes are specified as part of a model, but they

appear on objects. They are acquired by an object at the moment when that objects

model is specified. The models attributes are simply added to those that are

intrinsic to the object, as illustrated in the following diagram.

Key Concepts

OPNET objects have behavior and structure that is specified by a

model. Models also specify part or all of an objects interfaces.

Some objects have implicit models that cannot be changed; otherscan be assigned models via their model attribute, allowing extensivecustomization.

Key Concepts

Models can be parameterized using model attributes. This mecha-nism provides users of the model with a means of control over someaspect of model behavior without requiring changes to the model

internals. Model attributes generalize a model, making it more reus-able for diverse applications.


27/62

27-Ov


A mechanism similar to that provided for model attributes allows objectattributes to be passed upward in the modeling hierarchy. This mechanism is called

attribute promotion. Promotion causes an objects attribute to no longer have a

value; instead, the attribute appears at the next level in the model. For example,

in the case of a module attribute in a node model, promotion moves the attribute

into the node models attribute interface, meaning that it will then be inherited by

any node object in the network level that references the node model. In the case of

node objects in the network level, a promoted attribute is added to the attributes of

the subnet that it encompasses it. Attributes that promote all the way through the

model hierarchy become attributes of the overall system model, or equivalently

attributes of the simulation. These can be assigned values at simulation run time

via a variety of mechanisms. It is then possible to iterate through a range ofparameter values in different simulations in order to study the system as a function

of the parameters.

Other Model Data

Model Attributes

Model M

Object Attributes

Object O

object refers to model M

object acquires attributesA,B, C, and D

Inheritance of Model Attributes by an Object

ABCDXYZ

ABCD

Model = M

Key Concepts

Model attributes are inherited by objects that refer to the model. Theybecome part of the objects attribute list.


28/62

28-Ov


Derived Models

In many cases, model developers have a need to customize a models interface

without actually changing the models internal structure or behavior. Node and link

model attribute interfaces can be modified using a mechanism called model

derivation. Model derivation operates upon an existing model and generates a

derived model that has attribute interfaces that differ in various ways.The resulting

model is called a derived model, and the model used as the basis for its derivation

is referred to as itsparent model. A model which is derived from no other model (a

very common case) is called abase model

. All derived models have a unique basemodel that they refer to via one or more derivations.

The purpose of providing the derived model mechanism is to allow specialized

interfaces to be developed without having to duplicate or recreate core

functionality in a model. Since a model and a derived model are fundamentally the

same in terms of structure and behavior, it makes sense that specification of this

information should be shared. This provides economy of specification and enforces

long-term consistency of these models as they are modified over time.

Ov.4.2 Modeling Communications with Packets

The previous sections describe the support OPNET provides for representing

the structure of a network, including the elements that appear at different

hierarchical levels. Communication of data takes place at all levels of thishierarchy and most of the supported objects play some role in implementing this

communication: processes can be considered to be both the sources and sinks of

data and control information; the node domain is the context in which processes

communicate information with each other and with physical layer transmitters and

receivers; and the network domain allows nodes to exchange information with

each other via various types of communication links.

Key Concepts

Instead of having a value that is specified in advance, objectattributes can be promoted. A promoted attribute moves up to thenext level in the model hierarchy, allowing its specification to be per-

formed there. Attributes that are promoted through the top of the hier-archy (topmost subnetwork) become attributes of the simulation.

Key Concepts

When a specialized version of a model is needed, a derived modelcan be created from it. The derived model shares the same structuraland behavioral specification as its parent model, but parts of the par-

ents interface may be altered. Successive derivations may be per-formed. A model that is not derived from any other is a base model.


29/62

29-Ov


There are many forms of communication that are supported by the OPNET

modeling environment. However, there is one fundamental structure, calledpacket,

that provides the most commonly used mechanism for information exchange.

Packets are objects that contain formatted information that can change

dynamically. They can be stored by and transferred between objects in each of the

modeling domains. In the Node Domain, packets typically travel over streams; in

the Network Domain, they are typically transferred over links. Packets are

essentially composed of three main storage areas. The first area can be viewed as alist of user-defined values called packet fields; the second area consists of a set of

predefined values that are used by the OPNET system for tracing and accounting

purposes; and the third area contains transmission data attributes that are used to

support customizable models for communication links.

Because OPNET simulations model each individual packet in a network

model, and the packet fields contain actual data values, fully accurate models of

protocol interactions can be implemented. Processes can modify and obtain values

of fields and base their actions upon their contents. Packet fields may contain data

of one of several supported data types. Integer and double (floating-point) fields

can be used to represent flags, counters, timer values, network addresses, etc.

Packet fields allow packets to be encapsulated within other packets, which is a

Key Concepts

Packets carry formatted information between simulation entities. They

represent messages, packets, cells, transactions, etc. Packets can betransferred between objects in the Node and Network domains. Each

packet contains 3 areas: user-defined fields, pre-defined fields foraccounting, and transmission data used by link models.

User-Defined Fields

Index Name Type Contents Size

0 src_addr integer 5 16

1 dst_addr integer 9 16

2 timer_a double 0.84 12

3 timer_b double 1.00 8

4 ack integer 0 1

Predef. Fields

Name Contents

creat_mod 19

creat_time 4.005

owner 19

format transp_x

id 116

TD Attrs.

Index Contents

0 8

1 100.0

2 11.505

3 1.07e-07

4 11.509

(Note: Due to space limitations this chart shows the same number of items in each category, butin actuality, both user-defined fields and TDAs can have a variable number of entries; also, not

all predefined fields are shown.)

Three Main Storage Areas of Packet Contents


30/62

30-Ov


fundamental mechanism supporting layered protocol modeling, since higher-layer

protocols request that lower layer protocols transport packets to remote peers.

Structure fields provide general support for carrying user-defined C/C++ language

data structures within packets; this is sometimes useful for sophisticated

applications where complex information, such as routing tables, are transferred

across networks. The information field type is provided for convenient support of

bulk or filler data in a packet, which can be important to accurately model

packet size; information fields contain no values.

Packets fall into two broad categories:formattedand unformatted. A formatted

packet is one whose fields are defined according to a template called a packet

format. Packet formats are created in the Packet Format Editor and specify a list of

field names, data types, sizes (that is, field lengths specified in bits), and default

values. When formatted packets are created, they instantly acquire the fields

defined in their format and, when applicable, default values are installed in those

fields. Unformatted packets have no fields when they are created; fields are added

one at a time and can only be referenced by numeric index, not by name.

Unformatted packets are typically useful only for very simple applications and the

recommended approach is to define packet formats for most models, particularlywhen several different types of packets are used in a network.

Packet Field Types

Type Use

integer Whole numbers: flags, counters, addresses, etc.

double Floating point numbers: timer values, statistics, etc.

packet Encapsulation of higher-layer protocol data

structure Transport of complex user-defined data types

information Modeling of field size when content is irrelevant

Key Concepts

Each packet is modeled individually and can have arbitrary content in

its fields. Several data types are supported for fields, includingnumerical values, encapsulated packets, and general data structures.Field size is specified, allowing accurate modeling of processing

delays, transmission delays, buffer occupancy, etc.


31/62

31-Ov


Packets can be used to transfer data at all levels of an OPNET network model

via several communication mechanisms. Processors, queues, and other modules

forward packets within nodes via packet streams, which were introduced earlier in

this chapter. Packet streams may introduce delay and also queue packets until a

destination module is ready to accept them. At the network level, packets are sent

between nodes over communication links. Communication links use customizable

underlying models to model delays and errors in packet transmission. A third

packet transfer mechanism, called packet delivery, supports transfer of packets

between modules, regardless of their location in a network, without requiring any

physical connection to exist between them.

OPNET packets are intended to represent information-carrying structures of

various types that appear in communications and systems architectures, including

packets, messages, frames, cells, datagrams, and transactions. The term packethas

been chosen as a general term and should not be interpreted as restricting the types

of applications for which OPNET can be used.

For some communication networks, information transfer does not necessarily

occur in packet form. In particular, some devices communicate with streams of

data where information flow is continuous. In such cases, OPNET packets can be

treated as messages that carry only model-relevant information between the

communicating entities. This may include information such as the amount of data

transferred, or signaling data that is needed by the application models at either end

of the stream. Depending on what the goal of the modeling effort is, the data

streams can be adequately represented by modeling the important phases of their

operation (setup, tear-down, and control information transfer) with packets, or

even with other OPNET communication mechanisms that will be discussed later in

this manual.

Key Concepts

Packets may be made to conform to apacket format. Packet formatsare defined in the Packet Format Editor and specify a template for apackets fields, including the names, types, and sizes of each sup-

ported field.

Key Concepts

Though the term packet is used, OPNET packets can be used torepresent other forms of communication as well. In stream-orientedcommunications, for example, packets may be used to represent key

signalling information, allowing the connection to be modeled interms of its duration, bandwidth requirements, etc.


32/62

32-Ov


Ov.4.3 Data Collection and Simulation

The objective of most modeling efforts is to obtain measures of a systems

performance or to make observations concerning a systems behavior. OPNET

supports these activities by creating an executable model of the system. Provided

that the model is sufficiently representative of the actual system, OPNET allows

realistic estimates of performance and behavior to be obtained by executing

simulations. Several mechanisms are provided to collect the desired data from oneor more simulations of a system.

Ov.4.3.1 Simulation Output Data Types

OPNET simulations are capable of producing many types of output. Of course,

because of the general programmability of process models and link models,

developers are able to define their own types of output files, including text reports,

proprietary binary files, etc. However, in most cases, modelers use the types of data

directly supported by OPNET. These are output vectors, output scalars, and

animation. Each is briefly described in this section.

Output Vectors

The types of data that can be collected have several different forms. The most

common result extracted from a simulation is called an output vector, which is

simply a collection of pairs of real values, called entries. An output vector, often

called simply a vector, contains an arbitrarily-sized list of entries collected during a

single simulation run.The first value in the entries can be thought of as the

independent variable and the second as the dependent variable. In OPNET these

are referred to as the abscissa and the ordinate, respectively. In the majority of

cases, the independent variable of a vector is simulation time, which increases

monotonically as a simulations execution progresses. In other words, most vectors

represent the value of some quantity of interest as it varies over time. Under certain

conditions, it is interesting to create vectors that have abscissa variables other than

time; this topic is discussed later in this manual. The following diagram depicts a

typical data set contained in a vector. Note that it is possible for a vector to store

multiple ordinate values with the same abscissa value.

Key Concepts

Modelers can take advantage of the programmability of OPNET mod-els to create proprietary forms of simulation output, if desired. How-

ever, in most cases, users work with the output that can be providedautomatically by OPNET simulations. These are: output vectors, out-

put scalars, and animations.


33/62

33-Ov


Output Scalars

In contrast to vectors, scalar statistics are individual values. Typically, scalar

statistics are averages, probabilities, or peak values derived from a collection of

measurements. Examples include the average or peak size of a queue, the mean

end-to-end delay of packets, the proportion of calls blocked or dropped, the meancall duration, etc. Based on these examples it is clear that many scalars are simply

properties or statistics of the set of value pairs obtained in an output vector. In

other words, given all of the values in an output vector, a number of interesting

scalars can be computed and recorded by a simulation. Note that it is not usually

necessary to record all the values in a vector in order to compute a scalar that

reflects the entire data set. For example, the mean ordinate value of a vector can be

obtained by maintaining a running sum of the vectors values as they become

available and dividing by a running count of the number of values recorded. Thus,

recording scalars is often much more efficient in terms of disk space and disk I/O

than recording vectors.

Scalars are typically only of limited use when taken as individual data points.

Instead, the usual practice is to combine scalars recorded over multiple simulations

to form a graph or curve that indicates how a system variable varies as a function

of other system parameters. Both the dependent and the independent system

variables, used to generate such a graph, are recorded as scalars. For example, a

typical graph generated in performance analysis is Throughput vs. Offered Load,

which indicates how well a network is able to deliver the data that it is requested to

Key Concepts

Output vectors represent time-series simulation data. They consist ofa list of entries, each of which is a time-value pair.

time Q Size

0.0 0.0

0.3301 1.0

1.0 2.0

1.0 1.0

1.3301 0.0

5.0 1.0

5.0 2.0

5.0 3.010.0 2.0

10.6602 3.0

...

998.0 54.0

Output Vector Contents

ordinate (Q size) valuesabscissa (time) values


34/62

34-Ov


deliver, as the amount of data increases. Here the Offered Load scalar is an

independent variable that is varied as an input to each simulation. Throughput is

then measured over the course of the simulation, and its final value (since it is

already an average) is recorded as another scalar.

OPNET simulations record scalar statistics in a special type of file called an

output scalar file. Unlike output vector files, these files contain the results

generated by multiple simulations. Within an output scalar file, the scalars from

each simulation run are kept in groups so that they can be related to each other. In

other words, when Throughput is graphed against Offered Load, each point inthe graph is formed by taking an abscissa and an ordinate value from the respective

scalar statistics within the same simulation run. Each point of the graph usually

corresponds to a new simulation run. The following diagram shows a typical plot

generated from scalar values.

Application-Specific Statistics

Both scalar and vector statistics can be computed and recorded automatically

for a set of predefined statistics. Predefined statistics in OPNET are related to

values that can be measured at specific objects within the model. This includes

statistics such as queue sizes, link throughputs, error rates, and queuing delays. In

Key Concepts

Scalar statistics are individual values that represent a metric of inter-est. They are often derived from vector statistics, as an average, peak

value, final value, or other statistic. Typically, a single value for eachscalar statistic is recorded during a simulation; when many simula-

tions are run, their scalar outputs are combined to form a graph.

Plot of Scalar Statistic Values


35/62

35-Ov


addition, it is common for models to compute application-specific statistics during

a simulation and record them in scalar and/or vector output files. These statistics

may be computed in a completely general manner, taking into account events that

have occurred, the current state of the system, the content of packets, etc.

Custom statistics may be declared by process models, in which case OPNET

adds them to the set of built-in statistics of queues and processors that make use of

those process models. The custom statistics can have a scope which is local orglobal. A locally-scoped statistic is maintained separately for each processor or

queue that declares it. This is appropriate for recording information that relates

only to events at a particular location, such as the utilization of a CPU on a

particular server. In contrast, a global statistic is shared and contributed to by many

entities in the model, it is appropriate for recording information that relates to the

performance or behavior of the system as a whole. A typical example of a global

statistic is the end-to-end delay of all application data transported by a network,

regardless of origin or destination.

Animations

In addition to numerical forms of output, OPNET simulations can provide a

visual analysis of a network models behavior. An animation is a dynamic

graphical representation of selected events that occurred during a simulation. The

events may be depicted within a diagram from the Network, Node, or Process

domain, or simply in an empty window.

An OPNET simulation can be configured to generate certain types of

predefined animations automatically. In addition, the Animation Kernel Procedure

package provides the ability to program sophisticated animations that represent

simulation events in a customized manner. The kernel procedures of the Animation

package include general drawing as well as OPNET-specific graphics to provide a

flexible animation capability.

Both automatic and custom animations can be viewed interactively during asimulation run or afterwards in a playback mode. Refer to the documentation for

the Animation package Kernel Procedures in the Simulation Kernel manuals and

the op_vuanimprogram description in the Utility Programs manual for more

information on developing and viewing animations.

Key Concepts

OPNET supports predefined statistics that are typically of interest in

simulation studies. However, many projects require customized sta-tistics, computed in a manner specific to the application. OPNET sup-

ports both local (related to an object) and global (related to overallsystem) application-specific statistics.


36/62

36-Ov


Ov.4.3.2 Selecting Data for Collection

Because OPNET-developed models typically contain a very large number of

potential statistics and animations of interest, collection mechanisms are not active

by default when a simulation is executed. Instead, OPNET provides a mechanism

to explicitly activate particular statistics or animations so that they will be recorded

in appropriate output files. This is accomplished by specifying a list ofprobes

when running a simulation. Each probe indicates that a particular scalar statistic,

vector statistic, or form of animation should be collected. Probe lists are defined

using the Choose Results operation in the Project Editor. In addition, moreadvanced forms of probes can be defined in the Probe Editor, as described later in

this manual.

In addition to simply enabling a statistic or animation, a probe can specify

certain options that affect the manner in which data is collected. For statistics,

commonly used options include restricted time-windows for data collection, on-

the-fly data-reduction, and modified statistic names. For animations, probes allow

specification of window geometry, as well as particular options depending on the

type of animation being performed. Refer to the Simulation Design chapter of this

manual for more information on probes.

Ov.4.4 Analysis

The third phase of the simulation project involves examining the resultscollected during simulation. Typically, much of the data collected by simulation

runs is placed in output scalar and output vector files, as explained earlier in this

chapter. OPNET provides basic access to this data in the Project Editor and more

advanced capabilities in the Analysis Tool, which is essentially a graphing and

numerical processing environment.

Key Concepts

OPNET simulations can generate animations that are viewed duringthe run, or played back afterwards. Several forms of predefined orautomatic animations are provided (packet flows, node movement,

state transitions, and statistics). In addition, detailed, customized ani-mations can be programmed if desired.

Key Concepts

Simulations can potentially generate vast amounts of output data.Therefore, by default, each source of output data is disabled. Model-

ers must explicitly enable particular output data for collection. Resultsfor collection are defined byprobes, which also specify options thataffect the manner in which results are collected or displayed.
http://01_31_simde.pdf/http://01_31_simde.pdf/


37/62

37-Ov


Numerical Data Analysis

Both the Project Editor and Analysis Tool allow output vector files to be

selected and individual or multiple vectors to be loaded and displayed as

traces.Traces are ordered sets of abscissa and ordinate pairs, called entries (traces

are similar in structure to vectors). In addition, scalar files can be selected and

scalars from the same file can be plotted against each other to view the results of

multi-simulation parametric studies. Once scalars are plotted in this manner, theirdata points have been grouped as ordered pairs, and the resulting data set is treated

as a trace. Two graphs, one generated from vector data, and the other from scalar

data, are shown below:

Traces are held and displayed in analysis panels, and the user can arrange any

number of panels from one or more simulations as part of an analysis

configuration, which can be saved as a single file. A number of display options are

available to help you customize the datas presentation. These include multi-level

zoom, background colors, trace colors, plotting style, and labeling.

Scalar and Vector Data in Analysis Panels


38/62

38-Ov


Analysis panels provide a number of numerical processing operations that can

be applied to traces or vectors to generate new data for plotting. These are

summarized in the following table:

The Analysis Tool is linked to the Filter Editor, which supports the use of

mathematical filters to process vector or trace data. Mathematical filters are

defined as hierarchical block diagrams based on a predefined set of calculus,

statistical, and arithmetic operators (a typical filter is shown in the diagram below).

Predefined or user-defined filters can be invoked when specifying an analysis panel

and applied to combinations of data from output vector files and existing analysispanels, to generate and display new traces.

Trace/Vector Processing Operations

Probability Mass Function (PMF)

Cumulative Distribution Function (CDF)

Histograms (occurrence and duration-based)

Confidence Interval Calculation

Mathematical Filters defined in Filter Editor

Key Concepts

The Analysis Tool supports display of data stored in output vector andoutput scalar files. Information is presented in the form of graphs, or

traces. Each trace consists of a list of abscissa(X) and ordinate

(Y) pairs. Traces are plotted in analysis panels. A set of analysispanels can be saved and recalled as an analysis configuration.


39/62

39-Ov


Mathematical Filter Block Diagram

Key Concepts

The Analysis Tool supports a variety of methods for processing out-put data and computing new traces. Calculations such as histograms,PDF, CDF, and confidence intervals are supported directly by the tool.

In addition, mathematical filters constructed in the Filter Editor can beinvoked. Resulting data is displayed in new analysis panels.


40/62

40-Ov

OPNET Editors Modeling Concepts

Ov.5 OPNET Editors

OPNET presents its capabilities in the form of thirteen distinct environments,

called editors or tools. Each editor allows you to perform some set of related

OPNET functions within a window that is contained in the overall OPNET

graphical environment. The following table lists OPNETs editors and identifies

each ones purpose. The remainder of this section provides an overview of the

capabilities of each editor in summary form.

Editor Summary

Name Purpose Products

Project Editor Specify network topology and configure nodesand links. Choose results, run simulations, andview results.

All

Node Editor Create models of nodes by specifying internalstructure and capabilities.

Modeler

Process Editor Develop models of decision-making processesrepresenting protocols, algorithms, resourcemanagers, operating systems, etc.

Modeler

Link Model Editor Create, edit, and view link models. Modeler

Packet Format

Editor

Specify packet format, defining the order, data

type, and size of fields contained within thepacket.

Modeler

ICI Editor Create, edit, and view interface control

information (ICI) formats.

Modeler

Antenna PatternEditor

Create, edit, and view antenna patterns fortransmitters and receivers.

Modeler(Radio version only)

Modulation Curve

Editor

Create, edit, and view modulation curves for

transmitters.

Modeler

(Radio version only)

PDF Editor Create, edit, and view probability densityfunctions (PDFs).

Modeler

Probe Editor Identify sources of statistics and animation that

are to be collected during a simulation.

All

Simulation Tool Design and run sequences of simulations, eachpotentially configured with different inputs and/or

outputs.

All

Analysis Tool Plot and process numerical data generated bysimulations.

All

Filter Editor Define numerical processing that can be appliedto data in analysis panels.

Modeler


41/62

41-Ov

Modeling Concepts OPNET Editors

Ov.5.1 Project Editor Summary

The Project Editor is used to construct and edit the topology of a

communication network model. It also provides basic simulation and analysis

capabilities. The Network Domain in which the Project Editor works is the highest

modeling level in OPNET in the sense that it encompasses objects that are defined

in the other modeling domains. The network model therefore specifies the entire

system to be simulated. This section summarizes the objects used in the ProjectEditor and the operations that it provides.

Ov.5.1.1 Project Editor Objects

A network model contains only three fundamental types of objects:

subnetworks, nodes, and links. There are several varieties of nodes and links, each

offering different basic capabilities. In addition, each node or link is further

specialized by its model, which determines its behavior and functionality. The

following table summarizes the types of objects used to build OPNET network

models:

Network Model Objects

Object Type Definition Default Representation

Fixedsubnetwork

A container for additional network objects,including other subnetworks. Subnets can benested to any depth to model complex

hierarchical networks.

Mobilesubnetwork

Similar to a fixed subnetwork, except that it canphysically displace itself as specified by a user-

defined trajectory, or adaptively. In Radio

products only.

Satellite

subnetwork

Similar to a fixed subnetwork, except that it

displaces itself automatically on an assignedorbit. In Radio products only.

Fixed node A network terminal or device, usually with the

ability to communicate to other nodes. Can havea wide range of capabilities, as determined by its

model. Cannot change geographical positionsover time.

Mobile node Similar to a fixed node, except that it can

physically displace itself as specified by a user-defined trajectory, or adaptively. In Radio

products only.

Satellite node Similar to a fixed communication node, exceptthat it displaces itself automatically on an

assigned orbit. In Radio products only.


42/62

42-Ov


Ov.5.1.2 Project Editor Operations

The Project Editor provides operations to support the creation, editing, and

verification of network models. Operations related to major capabilities are

summarized in the following table. For a complete listing of operations and an in-

depth explanation of their use, refer to the Project Editor chapter of the Editor

Reference manual.

Simplexpoint-to-point

link

Supports uni-directional flow of packets betweentwo fixed nodes.

Duplex point-to-point link

Supports bi-directional flow of packets betweentwo fixed nodes.

Bus link Provides broadcast connectivity for a set of fixednodes. Nodes may transmit or packets onto the

bus, receive packets from the bus, or both.

Bus tap Attaches fixed nodes to a bus link.

Network Model Objects (Cont.)

Object Type Definition Default Representation

Project Editor Object Palette
http://../06_Editor_Ref/06_16_Pt.pdfhttp://../06_Editor_Ref/06_16_Pt.pdf


43/62

43-Ov


Project Editor Operations

Operationa

a. Operation names are not exact and may refer to several actual operations asa group.

Description

Create objects Individual subnetwork, node, and link objects can becreated by dragging and dropping them from a palette

(see figure above). Multiple palettes can be open and

each can be configured to show only certain models,based on a keyword search.

Import topology and traffic Use information from sources such as HP OpenViewNetwork Node Manager and NetMetrix to automatically

build a network model and set conversation pair trafficand link loads.

Rapid configuration Supports creation of common configurations of nodes

and links, including star, bus, ring, mesh, tree, andothers. Parameters control models of nodes and links,

graphical and geographical placement, number ofobjects, etc.

Edit object Right-click on an object to view or modify its attributes.Changes made to a single object can optionally beapplied to an entire set of selected objects.

Find object Certain operations, including editing attributes, moving,

copying, and deleting, can apply to a set of selectedobjects, instead of just one object at a time. Objectscan be selected manually by clicking on them,

automatically by searching on their names, or logicallybased their attribute values.

Verify links Verifies that links are connected in an appropriate

manner based on node and link characteristics.

Navigate networks Allows viewing of different subnetwork contexts bymoving up or down in the network hierarchy.

Select map Displays the selected map, cropped to the borders of

the current subnetwork. Maps are provided withOPNET and are based on the CIA World Data Bank.

Define mobile node

trajectory

Graphically specifies the path that a mobile node will

follow over time. Includes specification of time,implicitly specifying velocity. (Radio versions only)

Collect results Specify the statistics to be collected and run

simulations.

View results Specify which statistics to plot, graph characteristics,and calculations to be performed.


44/62

44-Ov


Ov.5.2 Node Editor Summary

The Node Editor is used to specify the structure of device models. These

device models can be instantiated as node objects in the Network Domain (such as

computers, packet switches, and bridges). In addition to the structure, the node

model developer defines the interface of a node model, which determines what

aspects of the node model are visible to its user. This includes the attributes and

statistics of the node model. This section summarizes the objects used in the NodeEditor and the operations that it provides.

Ov.5.2.1 Node Editor Objects

Nodes are composed of several different types of objects called modules. At the

node level, modules are black boxes with attributes that can be configured to

control their behavior. Each one represents particular functions of the nodes

operation and they can be active concurrently. Several types ofconnections support

flow of data between the modules within a node. The objects used to build node

models are briefly described in the following table.

Node Model Objects

Object Type Definition Default

Representation

Processor General purpose, programmable object whosebehavior is specified by a process model.

Generator Simple packet source using probabilitydistributions to control time intervals separating

arrivals as well as size of packets.

Queue General-purpose and programmable like a

processor, but also provides internal packetqueuing facilities consisting of a bank ofsubqueues. Subqueues are ordered lists of

packets.

Transmitter Allows packets to be sent outside of the nodesboundary via attached links. Three types of

transmitters correspond to supported link types:point-to-point, bus, and (in Radio versions)

radio.

Receiver Allows packets to be received from other nodesvia attached links. Same types as transmitters

above.

PacketStream

Connects an output stream of a source moduleto the input stream of a destination module,allowing packets to be communicated and

buffered between them.


45/62

45-Ov


Ov.5.2.2 Node Editor Operations

The Node Editor provides operations to support the creation and editing ofnode models. Operations related to major capabilities are summarized in the

following table. For a complete listing of operations and an in-depth explanation of

their usage, please refer to the Node Editorchapter of the Editor Reference

manual.

Statistic

Wire

Connects an output statistic of a source module

to the input statistic of a destination module,allowing numerical data to be communicated.

Optional active notification of value changes viainterrupts at the destination module.

Logical

Association

Indicates a coupling between two modules.

Currently supported for appropriate transmitter-receiver pairs only in order to specify that theybe kept together when attaching the node to a

link.

Node Editor Operations

Operationa Description

Create object Individual operations are provided to support thegraphical creation of each type of object listed in the

previous table.

Edit object Right-click on an object to view or modify its attributes.Changes made to a single object can optionally be

applied to an entire set of selected objects.

Edit model attributes Attributes that characterize the node as a whole (asopposed to a particular object within it) can be

associated with the node model. These attributesautomatically appear in the node models interface.

Node Model Objects (Cont.)

Object Type Definition DefaultRepresentation
http://../06_Editor_Ref/06_19_Nd.pdfhttp://../06_Editor_Ref/06_19_Nd.pdf


46/62

46-Ov


Ov.5.3 Process Editor Summary

The Process Editor is used to specify the behavior of process models. Process

models are instantiated as processes in the Node Domain and exist within

processor, queue, and esys modules. Processes can be independently executing

threads of control that perform general communications and data processing

functions. They can represent functionality that would be implemented both in

hardware and in software. In addition to the behavior of a process, the process

model developer defines the models interfaces, which determines what aspects of

the process model are visible to its user. This includes the attributes and statistics

of the process model. This section summarizes the objects used in the ProcessEditor and the operations that it provides.

Ov.5.3.1 Process Editor Objects

Process models use a finite state machine (FSM) paradigm to express behavior

that depends on current state and new stimuli. FSMs are represented using a state

transition diagram (STD) notation. The states of the process and the transitions

between them are depicted as graphical objects. The objects used to build process

models are briefly described in the following table.

Edit model attributeinterfaces

The attribute interface of a node model defines theattributes that a user of the node model has access to.

It also defines how they are presented, valueconstraints and choices, documentation, default

values, and several other properties. This operationallows you to hideattributes that should not appear inthe models interface.

Promote node statistics Statistics associated with modules can be promotedto the level of the node model, which means that theybecome associated with the node as a whole. This is

useful to rename statistics and to hide underlying nodemodel structure.

a. Operation names are not exact and may refer to several actual operations as

a group.

Node Editor Operations (Cont.)

Operationa Description


47/62

47-Ov


Ov.5.3.2 Process Editor Operations

The Process Editor provides operations to support the creation and editing of

process models. Operations related to major capabilities are summarized in the

following table. For a complete listing of operations and an in-depth explanation of

their usage, please refer to the Process Editor chapter of the Editor Reference

manual.

Process Model Objects

Object Type Definition Representation

State Represents a mode of the process which hasbeen attained due to previous stimuli and

corresponding decisions. States contain code

expressing processing that is performedimmediately after they are entered, orimmediately before they are exited. A state can

be forced or unforced. A process blocksimmediately upon executing the enter code ofan unforced state, at which point it waits for a

new interrupt before continuing.

Transition Indicates a possible path that a process cantake from a source state to a destination state.

Each state can be the source and destination ofany number of transitions. A transition has a

condition statement which specifies the

requirements for the process to follow thetransition. An executive statement specifiesactions that are to be taken when the processdoes follow the transition.

Model-levelinformationblocks

Several blocks of text specify additionalcomponents of the process, including:declaration of state (persistent), and temporary

(scratch) variables; user-defined functions thatcan be called by the process states and

transitions; code to be executed upon processtermination; and declaration of globally-scoped

variables, data structures, etc.
http://../06_Editor_Ref/06_22_Pr.pdfhttp://../06_Editor_Ref/06_22_Pr.pdf


48/62

48-Ov


Process Editor Operations

Operation a Description

Create object Individual operations are provided to support thegraphical creation of states and transitions.

Edit object Right-click on an object to view or modify its attributes.Changes made to a single object can optionally beapplied to an entire set of selected objects. For

states, this operation provides access to enter and exitexecutive code blocks, as well as other attributes. For

transitions, it includes access to condition andexecutive statements.

Set initial state Designates a particular state as the state where a

process should begin execution when it is created.

Edit model attributes Process model attributes are parameters of theprocess, allowing some aspects of its behavior to be

controlled externally. These attributes form part of the

models interface and are scoped locally to theprocess instance.

Edit simulation attributes Simulation attributes are parameters needed by theprocess, but scoped to the overall system model. That

is, the same attribute is shared by multiple processesand has one value throughout the entire simulation.

Edit model attribute

interfaces

Process models contain no objects with promotable

attributes. Only model attributes may be promoted.However this operation is still useful to controlattributes that are intrinsic to the processor or queue

that receives the process model. For example, the

process model can dictate how many subqueues thequeue should contain. This operation also hidesunnecessary attributes of the modules.

Edit statistics Process models declare statistics that they are

responsible for computing. These statistics can bescoped locally (contributed to only by this process) or

globally (shared across the entire system model).Declaring statistics makes them available in the NodeDomain for statistic wire connections and in the Probe

01 Modeling Overview

Documents

Transcript of 01 Modeling Overview