05 Network Domain

Chapter 5
Network Domain
335-Ntdef
Modeling Concepts
336-Ntdef
Modeling Concepts
Ntdef.1
Introduction
Introduction
A network model defines the overall scope of a system to be simulated. It is a
high-level description of the objects contained in the system. The network model
specifies the objects in the system, as well as their physical locations,
interconnections and configurations.
The size and scope of the networks modeled can range from simple to
complex. A network model may contain a single node, a single subnetwork, or
many interconnected nodes and subnetworks, since the structure and complexity of
a network model typically follows those of the system to be modeled. For example,
a network with a star topology has a corresponding network model with one center
hub node and several peripheral nodes connected to it with point-to-point links.
Star Topology in Abstract and Network Model Representations
Ntdef.2
Network Objects
Network models are composed of the following main building blocks:
subnetworks, communication nodes, and communication links. These objects,
either singly or as a whole, may be referred to as a site. A subnetwork encapsulates
other network level objects. Communication nodes model network objects with
definable internal structure. Communication links provide a mechanism to
transport information between communication nodes. This section describes each
object type available at the network level.
Ntdef.2.1
Subnetworks
337-Ntdef
Network Domain
Subnetworks are essentially containers that abstract the network components

specified within them into a single object. A subnetwork can encompass a set of
fixed or mobile nodes and links, usually to represent a physical or logical grouping
of objects, such as a local area network. A subnetwork may also contain other fixed
or mobile subnetworks. Subnetworks within other subnetworks form the hierarchy
of the network model. This hierarchy may be extended as required to model the
structure of the network. A subnetwork in the hierarchy and the objects it contains
can be described in what is termed a parent/child relationship. The subnetwork is
Network Objects
Modeling Concepts
the parent of the objects inside of it and the objects are the children of the
subnetwork.
Subnetworks Abstract the Network
Components Contained Within Them
A special subnetwork called the top level or global subnetwork is the highest
level subnetwork in the network hierarchy. The top level subnetwork does not have
a parent object. Ordinary subnetworks may be created and interconnected within
this top level or within other subnetworks.
Subnet Hierarchy
top subnet
Subnetworks may be located within the

top subnetwork or within other subnetworks
338-Ntdef
Modeling Concepts
Network Objects
Subnetworks provide a powerful mechanism to manipulate complex network

structures and to break down the system's complexity through abstraction. A large
network with many components typically can be segmented into distinct parts
based on the proximity, connectivity or other architectural considerations of the
constituent elements. For example, a university may have several campuses, each
of which is represented by a subnetwork object. Within each campus, there may be
one or more buildings, each of which is also represented by a subnetwork object
and so on.
Other than the objects it contains, the primary attributes of a subnetwork are
its geographical position, size, and mobility. However, a subnetwork may be used
in an entirely abstract role, where its position is irrelevant during simulation and is
used strictly for its ability to abstract other network level objects.
Additionally, subnetworks may exist entirely independently from each other
with no interaction whatsoever. Typically, the elements of a network model do
interact, but in some cases it is useful to model the elements as independent of one
another. One such case is a set of experiments designed to determine the effect of
interaction between subnetworks. For example, there is a proposal to join two
separate Ethernet segments via a bridge. In order to determine the effect of the
interconnection on the performance of the two Ethernets, a series of simulation
runs are set up for each case: unbridged and bridged. In the unbridged case, the
two Ethernets exist within the network model, but do not interact. The results of
the two series of simulations can be compared to determine the effect of the bridge
on performance of the Ethernets.
There are three types of subnetworks: fixed, mobile and satellite. These
subnetworks have essentially the same core capability, and differ only in the way
they relate their movement during simulation and how they can be connected to
links.
Ntdef.2.1.1
Fixed Subnetworks
A fixed subnetwork is unable to change its position during simulation, since its
x position and y position attributes cannot be modified during simulation. If the
subnetworks region is defined in degrees, then the x position attribute is the
subnetworks longitude and the y position attribute is the subnetworks latitude.
If the subnetworks region is defined in units other than degrees, the position
attribute values are also in those units and can, if it is not the top subnetwork,
represent a location relative to the position of the parent subnetwork. Refer to
section Ntdef.4 Physical Coordinate Systems for details.
339-Ntdef
Network Domain
Since a fixed subnetworks position does not change, it is typically used to

model static networks. In order to communicate with other subnetworks, a fixed
subnetwork is often connected to the others via one or more links. A fixed
subnetwork is the only type of subnetwork that supports connections to point-topoint and bus links.
Network Objects
Ntdef.2.1.2
Modeling Concepts
Mobile Subnetworks
A mobile subnetwork has the capability to change positions during a
simulation via one of three mechanisms: either by statically defined trajectory
segments, by a vector trajectory, or by direct changes to the subnetworks position
attributes. If trajectory segments are specified, the subnetworks position is
automatically updated at appropriate times to follow that trajectory during
simulation. Refer to Ntdef.5.1.1 Trajectories for more details.
Mobile subnetworks are typically used to contain model networks whose
overall position varies with time, such as submarines, airplanes, and other mobile
networks. Because mobile subnetworks move relative to the earth, objects within
them cannot be connected to other objects outside the network with point-to-point
or bus links. Mobile subnetworks are available only in the Radio version of
OPNET.
Ntdef.2.1.3
Satellite Subnetworks
A satellite subnetwork has the capability to change position during a
simulation via an assigned orbit, which specifies its orbital path through time. The
satellite subnetworks position is automatically updated at appropriate times during
simulation to follow that orbit. You can produce orbit files using the Satellite Tool
Kit program from Analytical Graphics, and then import the files into OPNET. (See
Pt.6.5 Import STK Orbit for more information on using this program.) You can also
produce orbit files using the EMA interface (refer to the External Model Access
chapter of External Interfaces for more information).
Satellite subnetworks cannot be connected to point-to-point and bus links and
are available only in the Radio version of OPNET. For more information on
satellite subnetworks, refer to section Ntdef.5 Modeling Node and Subnetwork
Movement.
Ntdef.2.2
Communication Nodes
A communication node exists within a subnetwork and represents a network
device with a wide range of possible capabilities. The actual function and behavior
of a node is determined by its node model, which is specified by the nodes node
model attribute. A node model is defined in the Node Editor and specifies the
internal structure of the node. A node may refer to a derived node model rather
than an actual node model specified in the Node Editor. In this case, there is an
implicit reference to the base model that the derived model depends on. For the
purposes of discussion in this chapter, the term node model will be used to refer to
Node Domain models in general, including both base and derived node models. A
node is said to be an instance of its node model. Distinct instances of the same
node model operate independently of each other during a simulation, just as
distinct pieces of equipment are independent of each other in a real network,
although they may have identical capabilities. A network model may contain an
arbitrary number of communication nodes, possibly of the same or different node
models.
340-Ntdef
Modeling Concepts
Network Objects
The Node Model Specifies the

Internal Structure of a Node
Node Object
Node Model
There are three types of communication nodes: fixed, mobile and satellite. The
node types have essentially the same core capability, since the node model defines
the internal behavior of the node. The only differences in capability between the
node types relate to their movement during simulation and how they can be
connected to links.
Ntdef.2.2.1
Fixed Nodes
A fixed communication node is unable to change its position during
simulation, since its x position, y position and altitude attributes cannot be
modified during simulation. If the parent subnetworks region is defined in
degrees, then the x position attribute is the nodes longitude, the y position
attribute is the nodes latitude, and the altitude attribute value is in meters. If the
parent subnetworks region is defined in units other than degrees, the position
attribute values are also in those units and represent a location relative to the
position of the parent subnetwork. Refer to section Ntdef.4 Physical Coordinate
Systems for details.
Since a fixed nodes position does not change, a fixed node is typically used to
model static network devices, such as workstations, gateways, and satellite ground
stations. In order to communicate with other nodes, a fixed node is often connected
to the others via one or more links. A fixed node is the only type of node that
supports connections to point-to-point and bus links.
LAN Nodes
341-Ntdef
Network Domain
LAN nodes are a special kind of fixed node that represents an entire Ethernet,
FDDI, or Token Ring LAN (local area network) and its aggregate traffic as a single
entity. These nodes are switched devices that contain a variable number of
workstations, as well as a server. LAN nodes can be directly connected to any
Ethernet, FDDI, or Token Ring node except a hub, any fixed subnetwork, or
Network Objects
Modeling Concepts
another LAN with the same data rate and protocol. LAN nodes can also be
connected to other objects with different data rates (for example, a 10BaseT LAN
connected to a 100BaseT LAN) by using an intermediate router or switch.
Typical LAN Node
Ntdef.2.2.2
Mobile Nodes
A mobile communication node has the capability to change positions during a
simulation via one of three mechanisms: either by trajectory segments, by a vector
trajectory, or by direct changes to the nodes statically defined position attributes.
If a statically defined trajectory is specified, the nodes position is automatically
updated at appropriate times to follow that trajectory during simulation. Refer to
section Ntdef.5 Modeling Node and Subnetwork Movement for more details.
Every mobile node is located within a subnetwork object. The placement of
mobile nodes within a subnetwork is useful when describing the motion of the
mobile nodes, since a subnetwork object has the capability to define a region that is
dimensioned in units that may be appropriate for the range of the mobile nodes.
For example, a subnetwork object may be used to define the area of a building,
where hand-held communication units are represented by mobile nodes, or the
subnetwork may be used to define the area of a city, where automobiles with
cellular telephones are represented by mobile nodes.
A mobile node is typically used to model terrestrial network elements whose
positions vary with time, such as automobiles, aircraft, and maritime vessels. Since
mobile nodes move relative to the earth, they may not be connected to point-topoint and bus links. Mobile nodes are available only in the Radio version of
OPNET.
Ntdef.2.2.3
Satellite Nodes
A satellite communication node has the capability to change position during a
simulation via an assigned orbit, which specifies its orbital path through time. The
satellite nodes position is automatically updated at appropriate times during
simulation to follow that orbit. Satellite nodes are usually assigned an orbit file
created using the Satellite Tool Kit from Analytical Graphics, and then imported
into OPNET. See Pt.6.5 Import STK Orbit for more information on creating and
importing orbit files.
342-Ntdef
Modeling Concepts
Network Objects
Every satellite node is located within a subnetwork object. If an orbit is

assigned to a satellite node, then the inclusion of that satellite node within a
particular subnetwork has no physical implications. The orbit fully specifies the
location of the satellite during simulation and the parent subnetworks location and
size do not affect the orbital path of the satellite. This is in contrast to fixed and
mobile nodes, whose positions are often defined relative to their parent
subnetworks. Refer to section Ntdef.5 Modeling Node and Subnetwork Movement
for details.
Satellite nodes may not be connected to point-to-point and bus links and are
available only in the Radio version of OPNET.
Ntdef.2.3
Communication Links
Links allow communication of information between nodes in the form of
structured messages called packets. When a packet is submitted to a transmitter in
a source node, the packet is conveyed over a link to a receiver in a destination
node. A transmitter may support multiple outgoing channels into a link and,
similarly, a receiver may support multiple incoming channels from a link. A link is
actually composed of one or more communication channels, each of which defines
a connection between a transmitter channel and a receiver channel. A
communication channel can be thought of as a pipe, where packets are placed in
one end by a transmitter channel and retrieved at the other end by a receiver
channel. If a link has multiple communication channels, it can be thought of as a
bundle of pipes, each one conveying packets from the source node to the
destination node.
A Link Is Composed of One or More
Independent Communication Channels
Communication Channel
Transmitter
Link
Receiver
Point-to-point links, bus links, and bus taps are represented as objects in the
Project Editor. Radio links exist as a function of dynamic conditions and so are not
represented by objects. Instead they result from a dynamic evaluation by the
Simulation Kernel. Those links that are represented by objects are described by an
343-Ntdef
Network Domain
OPNET supports three types of links: point-to-point, bus, and radio. Each link
type provides a fundamentally different type of connectivity: point-to-point links
connect a single source node to a single destination node, bus links connect a fixed
set of nodes to each other, and radio links potentially allow all nodes in a model to
communicate with each other, based on a dynamic evaluation. Each type of link is
described in more detail later in this section.
Network Objects
Modeling Concepts
underlying link model or derived link model in the same way that nodes are
described by a node model. For more information on link models, refer to the
Communication Mechanisms chapter.
While the general type of connectivity provided by these links is predefined by
OPNET, an open architecture is provided to allow developers to specify
customized behavior for each individual link and on a per-transmission basis. This
architecture is referred to as the transceiver pipeline because it provides a conduit
connecting a transmitter to one or more receivers. The basic functionality of a
transceiver pipeline is to determine when a packet arrives at the receiver and if it is
successfully received.
The transceiver pipeline has a similar structure for each of the three supported
link types. In each case, the Simulation Kernel manages the transfer of packets by
implementing a series of computations. The sequence of the computations and
their interface are standardized for each type of link. However, each computation is
performed outside the Simulation Kernel by a user-supplied procedure, called a
pipeline stage. In this manner, OPNET provides an open and modular architecture
for implementing link behavior. Refer to the Communication Mechanisms chapter
for more information on the transceiver pipelines.
Ntdef.2.3.1
Simplex and Duplex Point-to-Point Links

A point-to-point link can be thought of as a bundle of one or more
communication channels between the transmitter(s) and receiver(s) that it
connects. Within a point-to-point link, the number of communication channels is
static, since there exists one communication channel between each transmitter
channel and receiver channel of the same index. Packets sent by transmitter
channel in the source node will be received by the receiver channel with same
index in the destination node. Each communication channel acts independently of
the others in the same link, as though it were defined in a separate and parallel
point-to-point link.
A simplex point-to-point link defines a connection from a transmitter in the
source node to a receiver in the destination node. Packets are conveyed in that one
direction. A duplex point-to-point link, however, defines a pair of connections
between two nodes, connecting a transmitter in each node to a receiver in the other.
Packets can flow in both directions, from each node to the other.
For a point-to-point link to be operable, it must be attached to point-to-point
transmitters and receivers in the nodes that it connects. The transmitter and
receiver of a simplex point-to-point link are designated using its transmitter and
receiver object attributes. For duplex links, four attributes, transmitter a,
receiver a, transmitter b, and receiver b, serve to identify the modules
within the nodes to which the link is attached.
344-Ntdef
Modeling Concepts
Network Objects
Point-to-Point Links and Attributes
Duplex Point-to-Point Link

Hub
Server
Duplex link attributes require

specification of two transceivers
in each node.
Simplex Point-to-Point Link

Chelsea
Hillary
The point-to-point transceiver pipeline models four link effects: transmission

delay, propagation delay, bit errors and error correction. These effects determine
when the packet arrives at the receiver and if it is successfully received. The
following descriptions of the link behavior is based on the default transceiver
pipeline. If the default pipeline procedures require modification to model the
effects in a different manner, refer to the Communication Mechanisms chapter in
the Modeling Concepts manual for the details of each pipeline stage.
345-Ntdef
Network Domain
A packet completely arrives at a receiver after both the transmission and

propagation delays have elapsed. The transmission delay is based on the data
rate attribute of the transmitter channel and the size of the packet. Since each
transmitter channel specifies its own data rate, a point-to-point link can support
multiple communication channels with different data rates or capacities. The
propagation delay is obtained by the transceiver pipeline from the links delay
attribute. This value applies to every communication channel within the link. The
Network Objects
Modeling Concepts
default value is 0.0 seconds, but may be set as required to model the propagation
delay across a link.
Once a packet has completed traversing a link, the transceiver pipeline
computes the number of bit errors that occurred and whether they exceed the
receivers ability to correct them. The number of bit errors allocated to a packet is
based on the ber attribute of the link and the size of the packet. The default
pipeline stage for bit error allocation uses a probabilistic algorithm to compute the
number of bit errors. For details, refer to the Pipeline Stages / Bus Link chapter in
the General Models manual. The number of bit errors that the receiver can correct
is determined by the size of the packet and the receivers ecc threshold attribute,
which specifies the maximum number of errors per bit that can be corrected. For
example, if a packets size is 1000 bits and the error correction threshold value is
0.002, then the receiver can correct the errors in the packet if the number of bit
errors is 2 or less. If there are no errors or the receiver is able to correct those that
occurred, the receiver accepts the packet and forwards it to the next module in the
node. If there are too many bit errors, the receiver drops the packet and does not
forward it to the next module in the node.
Ntdef.2.3.2
Bus Links and Taps

A bus link is a constrained broadcast communication medium and therefore
connects a limited set of nodes to one another. For those bus transmitters and
receivers that are connected to the bus, shared communication channels exist,
connecting transmitter channels to the receiver channels with the same index. In
the bus link, a shared communication channel has one or more transmitter channels
sending packets into it and one or more receiver channels receiving packets from
it.
Nodes that require access to and from a bus must contain bus transmitters and
receivers and are attached to the bus via another network object called a tap. Taps
are simple structural elements used to connect fixed nodes to bus links. A tap has a
transmitter attribute and a receiver attribute that designate the transceivers
within the node that are connected to the bus link via that tap.
Most taps have both the transmitter and receiver attributes set to a nonempty value, allowing packets to travel in both directions between the bus and
node. However, it is possible to leave either of these attributes empty (the value
NONE can be assigned) in order to create a unidirectional tap. If only the receiver
name is assigned, the tap is referred to as receive-only. If only the transmitter name
is assigned, the tap is called transmit-only. Receive-only taps are sometimes used
to monitor the status of the bus link to learn about the activities of other nodes, or
to collect statistics. Transmit-only taps can be used, for example, by a controller
346-Ntdef
Modeling Concepts
Network Objects
node that periodically emits a synchronization signal and has no need to receive
information from other nodes.
Bus Link and Taps with Attributes
Bus Link
Tap
Tap Attributes
Bus Attributes
Packets are transmitted one at a time from a transmitter channel onto the bus
link and may propagate simultaneously in both directions. When a packet is
transmitted, each of the eligible receivers is sent a distinct copy of the packet. This
allows each receiver to make an independent determination with regard to the
correct reception of the packet. In addition, if the packets are received correctly by
multiple receivers, then the distinct copies can be operated upon (e.g., modified,
destroyed, resent) without affecting each other.
347-Ntdef
Network Domain
The calculations required to determine when and if a packet is successfully

received are performed by the bus links transceiver pipeline. The bus transceiver
pipeline models five link effects: transmission delay, propagation delay, collisions,
bit errors and error correction. The following descriptions of the link behavior is
based on the default pipeline procedures. If the default pipeline procedures require
modification to model the effects in a different manner, refer to the
Communication Mechanisms chapter in the Modeling Concepts manual for details
on each pipeline stage.
Network Objects
Modeling Concepts
The time that a bit requires to travel from the transmitter to the receiver is the
propagation delay. This delay is determined by the bus links delay attribute and
the distance the packet travels from transmitter to receiver. The delay attribute
specifies the propagation delay in units of seconds per meter, rather than just a
fixed value, as in point-to-point links. The distance from a transmitter to a receiver
is actually the distance from the transmitters tap to the receivers, since the taps
identify where the transceivers are located on the bus. The distance is not the lineof-sight distance, but the distance along the bus. Since the transmitter may be
sending copies of the packet to multiple receivers at different locations, the packets
may arrive staggered in time at each receiver.
Packet Propagation Delay Is Dependent on Distance

along Bus Link from Source to Destination Node
60m
20m
Packet propagation distance from source to dest_0 is 20 meters.

Packet propagation distance from source to dest_1 is 60 meters.
The transmission delay is the time required by the transmitter channel to send a
packet. This delay is based on the data rate attribute of the transmitter channel
and the size of the packet. The last bit of a packet will arrive one transmission
delay after the first bit. This delay is important because the Simulation Kernel uses
it to determine when a receiver channel is busy and when the entire packet has
arrived at the receiver channel.
Since a bus is a shared broadcast medium, two or more transmitter channels
may send packets whose arrivals overlap in time at a particular receiver channel.
This is known as a collision. When a collision occurs, the transceiver pipeline
increments a collision counter that is stored in the OPC_TDA_BU_NUM_COLLS
Transmission Data Attribute of each packet involved. Refer to the Communication
Mechanisms chapter in the Modeling Concepts manual for more information on
each transmission data attribute built into the packet structure.
Once a packet has completed reception at a bus receiver channel, the
transceiver pipeline computes the number of bit errors that occurred in the packet.
The number of bit errors allocated to a packet is based on the ber attribute of the
link and the size of the packet. The default pipeline stage for bit error allocation
348-Ntdef
Modeling Concepts
Network Objects
uses a probabilistic algorithm to compute the number of bit errors. For details,
refer to the Pipeline Stages / Bus Link the in General Models manual.
The bus receiver will accept the packet if there were no collisions during
reception and if it can correct any bit errors that may have occurred in the packet.
The number of bit errors that the receiver can correct is determined by the size of
the packet and the receivers ecc threshold attribute, which specifies the
maximum number of errors per bit that can be corrected. For example, if a packets
size is 1000 bits and the error correction threshold value is 0.002, then the receiver
can correct the errors in the packet if the number of bit errors is 2 or less. If there
are no collisions and errors, or the receiver is able to correct those errors that
occurred, the receiver accepts the packet and forwards it to the next module in the
node. If there is at least one collision or too many bit errors, the receiver drops the
packet and does not forward it to the next module in the node.
Since bus links allow a single packet transmission to automatically propagate
to multiple destinations, they are generally used to represent local area networks,
computer buses, or other broadcast-based networks. In addition, because packet
broadcasting can be constrained to a subset of the nodes attached to the bus, and
even to a single destination, bus links can be used to represent networks with a
high degree of connectivity or with a dynamic connectivity that would otherwise
be difficult to represent using point-to-point links.
Ntdef.2.3.3
Link Consistency
OPNET supports a notion of compatibility for interconnected nodes and links
in the Project Editor. The purpose of incorporating this concept in OPNET is to
assist the network-level user in constructing correct models. This is particularly
important for users who work exclusively at the network level, as do IT
DecisionGuru and Modeler XE users, since they do not have visibility into the
node models to make their own determinations about compatibility issues. These
types of users are only aware of the information that is published by node and link
model developers in the model comments.
OPNETs refers to compatibility of combinations of links and nodes as link
consistency. A determination of consistency for a particular grouping of objects is
based on criteria applied to certain attributes of these objects. Two types of
connections can be subjected to a test for link consistency: the interconnection of a
point-to-point link (simplex or duplex) and two nodes on either end of it, and the
interconnection of a node and a bus links via a tap. Note that links may actually be
connected to a subnetwork object that contains a node, but the connection is still
with the node object and the subnetworks characteristics are not considered.
349-Ntdef
Network Domain
The objects that are actually involved in the consistency determination are the
link, and the attached transmitter and receiver objects within the nodes. The
characteristics of the channel objects which are embedded in the transmitters and
receivers that are considered as well. The attributes that are considered for these
objects are data rate and the packet formats. The data rate specifies the
Network Objects
Modeling Concepts
speed at which information can be transmitted through the object and is given in
bits per second. Compatibility is clearly dependent on this attribute since it would
not make sense for a device to transmit data at one speed to a device that is only
capable of receiving data at a different speed. The packet formats attribute
specifies the types of packets that the object is capable of carrying. Though in the
real world, this is not necessarily a constraint that is imposed by physical objects
such as channels and links, it does provide a valuable mechanism for enforcing
correct interconnection. Specifically, the channels are viewed as ports of the node
and the node model developer has knowledge of the type of communication
protocol that is expected to make use of the port. By specifying the same type of
information for each port of each node, node model developers provide OPNET
with enough knowledge to detect if ports are connected that support incompatible
protocols.
Objects Involved in Link Consistency Determination
de
No
ry
da
un
Bo
bus tap
duplex link
These objects are analyzed to

determine link consistency
bus link
For bus interconnection, it is the
tap that can be inconsistent
point-to-point
transceivers
The criteria are intrinsic to OPNET and cannot be modified by the user. They
can be expressed as a series of rules, none of which can be violated if consistency
is to be achieved. Because links have only one packet formats attribute and one
data rate attribute, these are compared only against the attributes of the zeroth
channel for each transmitter and receiver. Channels with higher indices do not
factor into the consistency calculation. These rules are presented in the following
table.
350-Ntdef
Modeling Concepts
Network Objects
Link Consistency Rules

Rule
Details
Completeness
All of the transmitters and receivers required by the link

must be assigned to a valid object within the nodes on
each end. For a simplex point-to-point link, this means
that the transmitter and receiver attributes of the
link must be assigned. For a duplex point-to-point link,
the transmitter a, receiver a, transmitter
b, and receiver b attributes must be assigned. Bus
link attachments allow transmit-only and listen-only
configurations. Therefore it is consistent for a bus tap to
have either the transmitter, the receiver, or both assigned.
Same number of channels
The channel count attribute for the link object and

the count of the channel compound attribute for each
assigned transmitter and receiver must be equal. A
promoted value is considered to match any value to
which it is compared.
Equal data rates
The data rate attribute of the link, and the data

rate attribute of channel [0] of each assigned transmitter and receiver must be equal. A value of unspecified may be provided for a data rate attribute, in
which case, it is considered to match any value to
which it is compared. Similarly, a promoted data rate
also matches any value to which it is compared.
Packet Format Match
The list of packet formats specified in the packet

formats attribute of the link and the packet formats attribute of channel [0] of each assigned transmitter and receiver must have a non-empty
intersection. These attributes support the special status values all formatted and unformatted, both
of which can be simultaneously supported. Unformatted means that packets with no format are supported.
All formatted means that any formatted packet can be
supported.
351-Ntdef
Network Domain
Link consistency plays two primary roles in OPNET. Its primary use is as a
verification mechanism to be used during specification. OPNETs Project Editor
supports this with the Verity Links operation. This operation detects inconsistent
links and indicates them with a red X to call attention to them. Double-clicking
on the X opens a dialog box that describes why the link is inconsistent.
Optionally, this operation can attempt to correct the problematic link definitions.
Refer to the Project Editor chapter in the Editor Reference manual for more
information on using the Verify Links operation.
Network Objects
Modeling Concepts
Some examples of inconsistent links are presented below to illustrate the

application of the rules in above table. The cross superimposed on each link
indicates that it is in an inconsistent state.
Link Inconsistency Examples
Tap is inconsistent due to lack of

bus transceivers in FR_Switch
Duplex links are inconsistent due to

packet format and data rate differences
4 port node white_hub cannot

support any additional candidate
stations, therefore link to station
gingrich is inconsistent
The second application of link consistency criteria occurs during simulation.

First, the Simulation Kernel attempts to achieve link consistency wherever
attributes have been left in the unspecified state. Unspecified attributes are made
to match the values of the same attributes in other objects, if those are specified. In
other words, an unspecified attribute mimics the values of other specified attributes
that are considered in the same link attachment. If all of the attributes involved
have an unspecified value, then the default value for the attribute of the link
object is assigned to each of the attributes (note: in the special case where this
value is itself unspecified, an error message is issued and the simulation is
stopped). Once this is done, all attributes values have been resolved and link
consistency evaluation can be performed.
If a link is detected to be inconsistent at the start of simulation, the Kernel
considers the link to be disabled for the entire simulation. The link object does
appear to be present, when queried through the OPNET debugger, for example.
However, any packets that are submitted to the links transmitter are dropped rather
352-Ntdef
Modeling Concepts
Network Objects
than being transmitted. A warning message is generated when this occurs, but the
simulation is allowed to continue.
Even though a link may be consistent in terms of its physical attachments,
OPNET may still detect inconsistencies between the link and the traffic that it
carries. Specifically, a packet may be submitted for transmission whose format is
not included in the links packet formats attribute.The packet format may also
not be supported by the transmitter channel in the source node or by the receiver
channel in the destination node. Packet format incompatibilities can occur not only
for bus and point-to-point links, but also for radio links, since each radio
transceiver channel also provides a packet formats attribute.
When a packet is detected to be inconsistent with a transmitter channel, the
packet is dropped from the transmitter. It does not consume any of the transmitters
bandwidth, and the transmitter is allowed to move on immediately to begin
processing of the next packet that is queued for transmission (if any). This is true
of all three types of transmitters. Furthermore, if the packets format is inconsistent
with the supported formats of the connected link object, point-to-point and bus
transmitters discard the incompatible packet in the same manner.
When a packet is received by any of the three types of receivers, the Simulation
Kernel verifies that the packet can be supported by the receiver channel, as
specified in the channels packet formats attribute. If the packet format is
supported, the packet is forwarded normally to one of the other modules that is
attached to the receiver. If the format is not supported, the packet is instead
automatically discarded by the Simulation Kernel. Packet format inconsistency at
the receiver does not affect any of the pipeline computations which are performed
prior to consistency evaluation.
Transceiver Choosing
Note that OPNETs Project Editor does not indicate inconsistent links until it is
explicitly requested to do so via the Verify links operation. This brings up the
question of when links become inconsistent and when it makes sense to apply this
operation. There are several ways in which this can happen, each of which is
described in the table below.
Network Domain
353-Ntdef
Network Objects
Modeling Concepts
Causes of Inconsistency
Cause
Details
Inconsistent at creation
When a link and one or more devices are connected together in the Project Editor, it may not be possible for a
consistent link to be established. This may be due to
the fact that there are no matching transmitters/receivers available in the node models, or that none are available (i.e., they are already used for other links). Rather
than create a link that does not match its transceivers,
the Project Editor will simply leave the transceivers unassigned. The link is then inconsistent according to the
completeness rule in the table above.
External Specification
Network models can also be specified using the External Model Access (EMA) capability. In this case, link
transceiver attributes can be configured in an arbitrary
manner, and may violate one or more of the rules in the
table above.
Model changes
A consistent link may become inconsistent due to

changes to link or node models. Specifically, removal or
renaming of transceiver objects, as well as changes to
data rate, packet formats, and channel count
attributes may violate one or more of the consistency
rules described in the table above.
Another interesting question is: how do links become consistent?. In other

words, what steps must be taken by the user to form consistent links. The general
answer is that the user must ensure that the link consistency rules stated in the table
above are all satisfied for the link of interest and the objects attached to it.
However, it is a tedious task to manually assign the transceiver attributes of each
link to ensure consistency. Fortunately, OPNETs Project Editor can help automate
this process by automatically selecting the transceiver assignments when a link and
a node are attached. This occurs when links are first created in the Editor, and can
also be performed retroactively to repair inconsistent links. This service is
available via the reselect transceivers option of the Verify Links operation.
Refer to section Pt.6.12 Verify Links in the Editor Reference manual for a detailed
description of this procedure.
For certain nodes where all transceivers are similar and would match an
attached link, any choice is fine, and the Project Editor can choose the first
available transceiver(s). However, it is common for nodes to support several
different types of interconnections and therefore contain transceivers with different
configurations. In these cases, the Project Editor must attempt to make an
intelligent choice. It does so by examining the available transceivers and selecting
those that will permit a consistent link to be formed. Transceivers that are already
used for an existing link are considered unavailable. In general, the editor will
attempt to create consistent links whenever possible, taking into account all of the
354-Ntdef
Modeling Concepts
Network Objects
available transceivers in each of the involved nodes. However, if no matching

transceivers can be found, the link will still be created and certain transceiver
attributes of the link may be left blank.
In selecting transceivers for duplex point-to-point links and bus taps, the editor
takes into account logical associations that exist between transmitters and receivers
so that they can be kept together. The editor will not break associations between
transmitters and receivers, even if there is no other way to form a consistent link. In
other words, if an associated transmitter and receiver cannot be simultaneously
assigned to the link, then they cannot be used at all.
Ntdef.2.3.4
Link Connectivity
The link connectivity utility allows you to identify the IP interfaces and
physical port numbers connected on either sides of a link. The difference in the
information provided by this feature and that available using the port information
feature is that link connectivity provides information only for the selected link,
whereas port information provides a table for all connections on the loaded subnet
view.
When link connectivity is enabled, a new operation called Link Interfaces
appears when the Attributes dialog box is opened for a given link. The supported
link types include duplex/simplex point-to-point links and bus taps.
To choose ports for a link
1) Open a network model for which interface and port information are required.
2) Right-click on a link.
The links Attributes dialog box appears.
Network Domain
355-Ntdef
Network Objects
Modeling Concepts
3) Click the Link Interfaces button.

Connected interface and port information for the nodes. attached to the link
are generated and displayed, as shown:
The above information shows that IP interface #0 from RT3 is connected to IP

interface #2 of node RT6. Thus, if static addresses need to be assigned, these two
interfaces should be considered on the same IP network. The interface numbers
correspond to the index of the IP Address Information [i] in the IP address
information table.
Ntdef.2.3.5
Radio Links
A radio link might exist between any radio transmitter-receiver channel pair
and is dynamically established during simulation. The possibility of a radio link
between a transmitter channel and a receiver channel may be dependent on many
physical characteristics of the components involved, as well as time-varying
parameters. In OPNET simulations, parameters such as frequency band,
modulation type, transmitter power, distance, and antenna directionality are
commonly factored into the determination of whether a radio link exists or not at a
particular time. Therefore, a radio link is not statically represented by an object, as
are point-to-point and bus links.
Correspondingly, radio transmitter and receiver objects have a greater role in
determining the behavior of a radio link. Unlike point-to-point and bus link objects
which have attributes to specify the pipeline stages, a radio link is not an object and
cannot provide those values. Therefore, the radio transmitter and receiver objects
attributes identify the appropriate pipeline stage values that make up the
transceiver pipeline, which performs the calculations required to determine when
and if a packet is successfully received. For a full description of the radio link
transceiver pipeline, refer to the Communication Mechanisms chapter in the
Modeling Concepts manual. The remainder of this section explains how the
network level objects affect the default radio transceiver pipeline. If the default
pipeline procedures require modification to model the effects in a different
manner, refer to the Communication Mechanisms chapter in the Modeling
Concepts manual for the details of each pipeline stage.
356-Ntdef
Modeling Concepts
Network Objects
Since radio is a broadcast technology and depends on dynamically changing

parameters, the transceiver pipeline must evaluate the possible connectivity
between a transmitter channel and every receiver channel for each transmission.
The network level characteristics factored into the default transceiver pipeline
calculations are the source and destination sites locations, the distance between
the sites, and the direction the radio signal travels from the source site to the
destination site. If the sites are mobile or satellite sites, then these position-related
parameters may change during simulation.
The locations of the sites are significant factors in a radio link, because the
default transceiver pipeline computes whether the source site has direct line of
sight to the destination node. Line of sight depends on where the sites are
positioned relative to the earth. If the earths surface is between the two sites, then
the sites are said to be occluded and the computation of the radio link is
discontinued. If the earth is not between the two sites, then link closure is said to
exist and the computation of the link continues.
Default Model of Occlusion by the Earths Surface
The earths surface does not occlude the source

and destination sites, so a radio link is possible.
The earths surface occludes the source and

destination sites, thus no radio link is possible.
The distance between the sites determines the propagation delay and path loss
of the radio signal. The default transceiver pipeline computes the propagation
delay of the radio signal traveling from the source site to the destination site at the
speed of light. The transceiver pipeline also models the weakening of the radio
signal as it propagates from the source site. It is assumed that the path loss is
directly related to the reciprocal of the distance squared.
357-Ntdef
Network Domain
As a packet is sent from a radio transmitter or received by a radio receiver, the

power of the radio signal may be influenced by antennas. In some directions, the
signal level may be higher and in other directions, lower. The default transceiver
pipeline takes this into account by determining the direction the radio signal travels
from the source site to the destination site. As the radio signal radiates from the
transmitter, the transceiver pipeline calculates the signal power out that direction of
the antenna. If there is no antenna object attached to the transmitter in the site, the
transceiver pipeline assumes that the signal power is equal in all directions. When
Network Objects
Modeling Concepts
Locations of Source and Destination Nodes

Affect Radio Link in Default Transceiver Pipeline
Distance between nodes = r

Propagation delay =
Received power =
rC
2
- G rx
P tx G tx ---------------- 16 2 r 2
C is the speed of light, P is transmitter power, G is directional

antenna gain, and is the center wavelength of the signal.
The subscript tx indicates the transmitter and rx the receiver.
the radio signal reaches the destination site, the transceiver pipeline also calculates
the direction of the signal into the receivers antenna, if there is an antenna. The
antenna may increase or decrease the signal received based on the incoming
direction of the radio signal. As with the transmitter, if a receiver does not have an
antenna object attached to it, then the signal level is not adjusted.
The propagation delay and signal strength computations are important factors
in determining when and if a packet arrives successfully at the destination site. The
propagation delays of packets determine when the packets arrive and whether the
packets collide. Collisions cause interference which is noise to the signal of a
particular packet. With the signal strength and noise computed, the transceiver
pipeline calculates the signal-to-noise ratio and from that the bit error rate and bit
error count, which determines the acceptability of the packet. Refer to the
Communication Mechanisms chapter for more details on the radio transceiver
pipeline.
Ntdef.2.4
Using Paths to Represent Virtual Circuits

OPNET Modeler allows you to create path objects between nodes or subnets.
Any protocol model that can use logical connections or virtual circuits (MPLS,
ATM, Frame Relay, etc.) can use paths to route traffic.
Paths have no inherent, built-in simulation behavior: the underlying protocol
models determine exactly when and how to use a particular path. Refer to the
relevant model documentation for information on how particular models utilize
paths.
Ntdef.2.4.1
Path Model Options

A path is a defined route between one fixed node object or subnetwork (called a
site) and another. The process of defining a path is similarthough not identical
to defining a link. First you configure an object palette to include the models you
358-Ntdef
Modeling Concepts
Network Objects
want (as described in XREF); then you select a model and click on objects in the
Project Editor workspace to connect them.
Choosing a Path Model
Each path model has a set of defined options that determine the type of path
you can and cannot create. When creating a path object in the Project Editor, you
should verify that the underlying models options allow you to create the type of
path you want. If you cannot find a path model whose options exactly match the
type of path you want to create, you may want to create or derive a new model.
Path Model Description Dialog Box
path
options
Path Connectivity
A path object defines, at the very least, two end sites. It may also define a
partial or complete path (that is, a set of connecting sites and links) between these
sites. The Path Connectivity option defines the extent to which you can define this
intermediate path. The three possible settings are:
Links RequiredIn a required-link path, you must specify all connecting links and midpoints between the two end nodes. Note that you
can only define a required-link path across point-to-point links. Traffic
follows the exact path from source to destination.
Links IgnoredIn an ignored-link path, you can only specify the

paths two end sites. The underlying models fully determine the path
between the source and destination.
359-Ntdef
Network Domain
Network Objects
Modeling Concepts
Links OptionalThis is a combination of the required-link and ignored-link types. You must define the two end sites, but defining any
connecting links and nodes is optional. If there is no defined path between two sites, the underlying models determine the path that traffic
takes between them.
The following diagram shows a router network connecting a site in Canada to

one in Texas. Traffic that takes the required-link path (left) always follows the
exact path defined between Canada and Texas. If traffic takes the ignored-link path
(center), the underlying models fully determine the route(s) taken. Traffic that
takes the optional-link path (right) always uses the link between Canada and router
E; the underlying models route the traffic between router E and Texas.
Keep in mind that in a situation like this, with multiple paths defined between
the same two sites, the underlying models choose the actual path taken by a packet.
Other Options
The other defined path options are:
Packet FormatsEach path has a defined set of supported packet formats. You cannot define a link as part of a path unless it supports all
formats included in that path models Packet Formats field.
Two Endpoints OnlyIf this option is set to Yes, you can only create
single-segment paths.
Subnets IgnoredIf this option is set to No, you cannot include a subnetwork in a path definition.
Allow CyclesIf this option is set to No, you can only include each
link or site once in a path definition.
360-Ntdef
Modeling Concepts
Ntdef.2.4.2
Network Objects
Creating a Path Object
To create a path between two nodes...

1) If necessary, open an object palette and configure it to include the path models
you want.
2) Left-click on a path model in the object palette to select it.
The cursor changes appearance to indicate that you are in path-creation
mode.
3) Left-click on a site that forms one endpoint of the path you want to define.
Once you are in path-creation mode, OPNET Modeler provides extensive
visual feedback to indicate valid and invalid additions to your path. If you
move the cursor over an invalid node, for example, the cursor changes
appearance and a tooltip appears with an error message.
Visual Feedback in Path-Creation Mode
OK to add link/ to path
Not OK to add link/site to path
5) Left-click on the node that forms the end of the path.
361-Ntdef
Network Domain
4) (Required-link and optional-link paths only): Left-click on any sites that form
midpoints in your path. This step is optional for optional-link paths; if you are
defining a required-link path, you must define every midpoint.
Modeling Network Traffic
Modeling Concepts
6) Right-click in the project workspace and choose Finish Path Definition from
the pop-up menu. OPNET Modeler auto-assigns a unique name to the new
path.
Note: When you nish dening a path, you are still in path-denition mode. You can create another path (based
on the same underlying model) by repeating steps 3 through 7. To exit path-denition node, right-click and
choose Abort Path Denition from the pop-up menu.
Ntdef.3
Modeling Network Traffic

Once you have built your network model, you will want to load it with traffic.
There are several different types of traffic which can be used in any combination to
provide an accurate model of the load on a network: explicitly modeled traffic,
device/link load traffic,and conversation pair traffic.
Explicitly modeled traffic is defined via several attributes, such as Client
Applications (e-mail, FTP, remote login, etc.). This type of traffic is usually
modeled as a number of units (such as e-mails or sessions) in a given amount of
time. You can explicitly specify the size of the transactions occurring and their
frequency. This type of traffic is specified at the source object.
Link load traffic, on the other hand, specifies the background traffic load on a
particular link as a percentage of the maximum possible load on that link.
Another type of background traffic is conversation pair traffic: traffic specified
between a particular source object and one or more destination objects. This traffic
can be created explicitly, or it can be imported.
The advantage to using conversation pair traffic instead of device/link load
traffic is that conversation pair traffic responds to dynamic network changes. For
example, if a node or link fails in an OSPF network, conversation pair traffic will
re-route according to protocol specifications. However, because link load
(background utilization) traffic applies only to a specific link, if that link fails or is
connected to a node that fails, the link load traffic will no longer be taken into
account on the failed object. You can convert link load traffic to conversation pair
traffic using the Convert Utilization to Flows tool, and it will then be re-routed if
appropriate.
Each traffic type is described in detail in the following sections.
Ntdef.3.1
Explicitly Modeled Traffic

Explicitly modeled traffic can be defined for both _station and _wkstn
objects. If using a _wkstn object, the accompanying _server object must also be
set to model explicit traffic. Explicit traffic is modeled via several attributes,
including the Application attributes for _station objects, and the Client
Application attributes for _wkstn objects. For _station objects, traffic is
modeled by setting a generation rate and a transaction size. _wkstn objects traffic
can be defined in greater detail, as each different Client Application can be set up
to generate a certain amount of traffic according to several specifications. These
362-Ntdef
Modeling Concepts
Physical Coordinate Systems
user-defined inputs are then varied according to the appropriate pre-defined

distributions for that application.
Ntdef.3.2
Device/Link Load Traffic

Suppose a particular link in your network has a baseline load of 50%, and you
are interested in explicitly modeling a client application such as FTP or e-mail on
top of the baseline load. Instead of explicitly generating the baseline traffic, you
can use the objects background utilization attribute to specify the baseline
load. Using this feature to generate baseline traffic has the advantages of reducing
the time needed to configure the traffic load and making the simulation run faster.
Device/link load traffic, as defined by an objects background utilization
attribute, is a percentage of the maximum possible load for a particular link. To
implement this, you must define at least one utilization period. A utilization period
specifies the period between two start times, or the period between a single start
time and the end of the simulation, during which the link will be loaded with the
traffic you specify. A link may have many utilization periods which can specify
background traffic for the entire simulation, or only a portion of the total
simulation time. The default value for a links background utilization attribute
is 0%.
Note: If your network uses a routing protocol that responds dynamically to network topology changes, any device/link load traffic on
objects affected by the topology change will not be taken into
account.
Ntdef.3.3
Conversation Pair Traffic

Another type of background traffic is called conversation pair traffic. Unlike
device/link load traffic, which models traffic on a particular object, conversation
pair traffic is from a single source to one or more destinations. Conversation pair
traffic can either be specified in the Project Editor (user-defined conversation pair
traffic), or it can be imported (imported conversation pair traffic). For detailed
information on imported conversation pair traffic, refer to the Importing Network
Traffic chapter.
If you have device/link load traffic that you want to be considered in dynamic
topology change scenarios, you can convert it to conversation pair traffic using the
Convert Loads to Conversation Pairs tool option under the Traffic menu. Although
device/link load traffic is not considered on failed links in such scenarios,
conversation pair traffic will be re-routed along with any explicit traffic.
OPNET network models support three types of coordinate systems that
pinpoint the locations of subnetworks and nodes: geographic, subnetwork-relative,
and geocentric. The position of an object within the global coordinate system is
described by its latitude and longitude for fixed subnetworks, and by latitude,
longitude, and altitude for fixed nodes and mobile or satellite sites. The
363-Ntdef
Network Domain
Ntdef.4
Modeling Concepts
subnetwork-relative coordinates of an object are its position relative to a particular

point called the origin within the parent subnetwork object. The geocentric
coordinate system is a three-dimensional Cartesian coordinate system with the
origin at the center of the earth. The location of any site can be described in each
coordinate system, but one may be more appropriate for a particular modeling task
than the others. Each of these coordinate systems will described in more detail
later in this section.
Ntdef.4.1
Subnetwork Extent and Units

Every network level object, except the top subnetwork, is contained within a
fixed, mobile, or satellite subnetwork object and has a location within that
subnetwork. Therefore, in order to specify locations, an internal coordinate system
is associated with each subnetwork object. The coordinate system is placed within
a region called the subnetworks extent, which specifies the subnetworks location
and size.
A Subnetworks Extent Specifies its Location and Size
Extent boundary
A subnetworks coordinate system has configurable units. Degrees, arc

seconds, kilometers, meters, miles, and feet may be specified as the units for fixed
subnetworks. Kilometers, meters, miles, and feet may be used for mobile and
satellite subnetworks. Degrees may only be used in certain cases: a fixed
subnetwork may have units of degrees if its parent subnetwork also has units of
degrees. Conversely, if a parent subnetwork does not have units of degrees, then
any child subnetworks may not either. The choice of units for a subnetwork is
typically based on how convenient the units are for describing the locations of
objects within the subnetwork.
A fixed subnetworks coordinate system has two axes, x and y, wheras the
coordinate systems for mobile and satellite subnetworks have x, y and z axes. The
x axis is horizontal and always increases left to right. The y axis is vertical and,
when not in degree units, increases top to bottom. This differs from a traditional 2-
364-Ntdef
Modeling Concepts
dimensional Cartesian coordinate system display, where the y axis increases

bottom to top. The z axis for mobile and satellite subnetworks defines altitude, but
is not visible in the OPNET workspace. The origin of the coordinate system
depends on the units. If the units are degrees, then the origin is located at 0
latitude, 0 longitude. Otherwise, the origin is located at the top left corner of the
subnetworks extent.
Subnetworks Internal Coordinate System

X direction
Y direction
A subnetworks extent is defined by its x span and y span attributes,

which specify its height and width. The values of the attributes are in the units of
the parent subnetworks coordinate system.
Network Domain
365-Ntdef
Modeling Concepts
Subnetworks Extent Attributes

x span
y span
Extent boundary
Extent Specification
The units and extents of all subnetworks are configurable, except for those of
the top subnetwork. The top subnetworks units are always degrees and its extent is
always the entire earth, from -180 to +180 longitude, and from +90 to -90
latitude. Its child subnetworks may have any type of units and different size
extents.
Ntdef.4.2
Global Coordinate System

The position of a network level object within the global coordinate system is
described by its latitude, longitude, and altitude. The latitude specifies how far
north or south the object is, relative to the equator. Positive latitudes are in the
northern hemisphere, negative in the southern. The longitude specifies how far east
or west the object is, relative to the prime meridian. Positive longitudes, to +180,
are in the eastern hemisphere and negative longitudes, to -180, are in the western.
The altitude is the height of the object directly over the location determined by the
latitude and longitude values. The altitude is measured in meters above sea level.
366-Ntdef
Modeling Concepts
Global Coordinate System

Prime Meridian
Equator
Lines of Latitude
Lines of Longitude
For subnetworks and nodes contained within a subnetwork whose coordinate

system has units of degrees or arc seconds, the positionrelated attributes of these
objects hold global position coordinates. For example, within the top subnetwork,
a nodes x position attribute is its longitude, its y position attribute is its
latitude, and its altitude attribute is its altitude in meters.
In whatever subnetwork a node is located, its global position can be obtained
during simulation with the Kernel Procedure op_ima_obj_pos_get(). If all of a
nodes parents are fixed subnets, the values returned for a fixed node do not change
over time. For mobile and satellite nodes, the values returned reflect the position of
the node at that moment in the simulation.
Network Domain
367-Ntdef
Modeling Concepts
Example Fragment of a Process Model State Executive

Determining Global Position Coordinates of a Node
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Ntdef.4.3
/* This process just received the self interrupt that signals

/* it to re-point the antenna at the mobile base station.
/* Obtain the (possibly) new coordinates of the base station.
/* Note that only the latitude, longitude and altitude coords
/* are of interest. The geocentric (x,y,z) coordinates are
/* not used.
op_ima_obj_pos_get (base_station_objid, &lat, &lon, &alt,
&tmp_dbl, &tmp_dbl, &tmp_dbl);
/* Set the pointing
op_ima_obj_attr_set
op_ima_obj_attr_set
op_ima_obj_attr_set
*/
*/
*/
*/
*/
*/
attributes of the antenna module. */

(antenna_mod_objid, target latitude, lat);
(antenna_mod_objid, target longitude, lon);
(antenna_mod_objid, target altitude, alt);
/* Schedule the next re-pointing timer. */

op_intrpt_schedule_self (op_sim_time () + REPOINT_TIMEOUT,
REPOINT_TIMER);
Subnetwork-Relative Coordinate System

The position of a network-level object is determined by its location within the
extent of the parent subnetwork. In the case of subnetworks whose units are not
degrees or arc seconds, the coordinates of a child objects location is an offset from
the origin of the subnetworks extent, which is its top left corner. A description of a
position as an offset within a subnetworks extent is termed subnetwork-relative.
A site has x position, y position and (except for fixed subnetworks)
attributes that specify its location. In a subnetwork-relative coordinate
system, the attribute values are in the units of the subnetwork. The x position
attribute specifies the x offset and the y position attribute specifies the y offset
from the extents origin. The altitude attribute indicates the sites altitude
relative to its parent subnetwork. (In this case, the parent subnetworks elevation is
its absolute distance above global sea level.) Fixed subnetworks have an implicit
altitude of 0. As a mobile or satellite site moves during simulation, the x position,
y position, and altitude attribute values change correspondingly.
altitude
Fixed nodes, mobile nodes, and mobile subnetworks contain an enumerated

attribute called altitude modeling, which determines how OPNET interprets
an objects altitude attribute. This attribute has three possible settings:
relative to subnetplatform The objects altitude is

relative to its parent subnetwork. (The parent subnetworks elevation is
its absolute distance above global sea level.)
absolute the objects altitude is relative to global sea level.
relative to terrain the objects altitude is relative to the

368-Ntdef
Modeling Concepts
underlying terrain (ocean, hill, valley, etc.).

Position Attributes within a Subnetwork-Relative
Coordinate System
x offset = 600 km
y offset =
400 km
For an object within a subnetwork-relative coordinate system, determining its

global position may involve a recursive set of computations. If the parent
subnetworks extent is specified in the global coordinate system, then obtaining an
objects global position only requires computing its offset in degrees from the
extents top left corner. However, if the parent subnetwork is also within a
subnetwork-relative coordinate system, then its extents global position, too, must
be computed. Thus, a series of computations may be required, until a parent
subnetworks global position is known. All of these computations are handled by
the Simulation Kernel.
Network Domain
369-Ntdef
Modeling Concepts
Determining Global Position Coordinates from

Subnetwork-Relative Coordinates
Steps to compute global position coordinates of an object:
1) Compute global position coordinates of the top left corner of the parent subnetworks
extent.
2) Compute the objects latitude offset in degrees.
3) Compute the objects latitude.
4) Compute the objects longitude offset in degrees at the computed latitude.
5) Compute the objects longitude.
6) Compute the objects altitude offset in meters.
7) Compute the objects altitude.
Units are degrees
Step 1:
Top left corner of subnetwork in degrees (x, y) =
(x_position - (1/2) x_span, y_position +
(1/2) y_span)
Latitude = 0.0 + (1/2) 7.5 = 3.75
Longitude = -137.0 - (1/2) 7.2 = -140.60
Step 2:
Units are kilometers
3.59
(-140.60, 3.75)
Latitude offset of 400 km = 3.59
5.39
Step 3:
Latitude of object = 3.75 - 3.59 = 0.16
Step 4:
Longitude offset of 600 km = 5.39
( at 0.16 latitude)
Step 5:
Longitude of object = -140.60 + 5.39 = -135.21
Step 6:
Altitude offset of object = - 10 m
Step 7:
Altitude of object = 1000m - 10m = 990m
370-Ntdef
In this example, the nodes x

position is 600 km, its y
position is 400 km, and
its altitude is -10 meters.
Modeling Concepts
Ntdef.4.4
Geocentric Coordinate System

The geocentric coordinate system is a 3-dimensional Cartesian grid with the
origin at the center of the earth. It has three axes, x, y, and z, and has the units of
meters. Each of the axes is defined by a vector that starts from the center of the
earth and intersects a point on the surface. The x-axis intersects the surface at 0N
90E, the y-axis at 0N 0E, and the z-axis at 90N.
Geocentric Coordinate System
z
90E
0E
x
0N
An objects position is specified by its (x, y, z) coordinate values.
The Simulation Kernel computes the geocentric position coordinates for site
objects only. There are two mechanisms provided to obtain these values. The
Kernel Procedure op_ima_obj_pos_get() returns the geocentric, as well as the
global, position coordinates of a site at the moment in the simulation when the
procedure is invoked. The second mechanism is part of the radio transceiver
pipeline. The geocentric position coordinates of the sending and receiving nodes
are automatically included in the Transmission Data Attributes of a packet for
radio transmission. The Simulation Kernel computes these values for the
transceiver pipeline. The default radio transceiver pipeline uses the geocentric
position coordinates for the line of sight and distance calculations. Refer to the
Communication Mechanisms chapter for more details on the radio Transceiver
Pipeline.
Network Domain
371-Ntdef
Modeling Node and Subnetwork Movement
Modeling Concepts
When the Simulation Kernel requires the geocentric position coordinates of a

site, it computes them from the sites global position coordinates using the
following formulas:
Formulas for Conversion of Global Position
Coordinates to Geocentric
R
X
Y
Z
=
=
=
=
altitude + Earths radius

R cos ( latitude ) sin ( longitude )
R cos ( latitude ) cos ( longitude )
R sin ( latitude )
The x and y axes within the coordinate system of a subnetwork do not

correspond to the x and y axes used in the geocentric coordinate system. For
example, as the following diagram shows, a change in the y coordinate within the
subnetwork possibly entails changes in all three geocentric position coordinates.
Relationship Between Subnetwork-Relative
and Geocentric Coordinate Systems
z
(x,y) = (0,0)
x
x (incr. long.)
y (decr. lat.)
y
Ntdef.5

Distance, line-of-sight, and other position related characteristics are often
important to the performance of a system utilizing radio-based technologies.
Therefore, good models of node and subnetwork movement are critical to many
simulations of communication networks. The Radio version of OPNET provides
mobile and satellite sites with the capability to change locations based on
trajectories and orbits. The Simulation Kernel automatically updates the position
of mobile and satellite sites, modeling continuous movement. The updates occur
during radio transmission and whenever the location of a site is directly queried,
via the KP op_ima_obj_pos_get(), or by applying the KP op_ima_obj_attr_get() to
one of a sites position attributes.
372-Ntdef
Modeling Concepts
Ntdef.5.1
Mobile Nodes and Subnetworks

Mobile sites support two mechanisms to change location during a simulation:
trajectories and direct manipulation of position attributes. For each particular
instance of a mobile site, only one of the two mechanisms may be in use over the
course of a simulation. If a trajectory is specified for a mobile site, then that
trajectory is used by the Simulation Kernel to determine the mobile sites location.
If no trajectory is specified, then any process can directly modify the position
attributes of the mobile site. Each of these mechanisms is explained in more detail
later in this section.
Ntdef.5.1.1
Trajectories
A trajectory is a path specification for a mobile objects motion during a
simulation. The trajectory of a mobile node or subnet object is specified by its
trajectory attribute.
A trajectory can be defined either as vector-based or segmentbased. A vectorbased trajectory consists of a direction and a velocity that can be changed at run
time. If a mobile objects trajectory attribute is set to VECTOR, then the
trajectory is defined by the ground speed, ascent rate, and bearing
attributes.
A segment-based trajectory consists of one or more traversal-time values and a
set of three-dimensional (x, y, and altitude) coordinates that define the mobile
objects path. Segment-based trajectories are stored in ASCII text files with a .trj
extension, which you assign to a mobile node or subnet using the trajectory
attribute. The Project Editors Define Trajectory operation (found on the Network
menu) allows you to define a segment-based trajectory. See Pt.6.1 Define
Trajectory in the Editor Reference manual for details on this operation.
Segment-based Trajectories: Fixed-Interval and Variable-Interval

During simulation, a mobile object follows its trajectory by moving in a greatcircle path from one defined point to the next. OPNET determines an objects
position at a given time by interpolating between the trajectory points immediately
before and after that time. A segment-based trajectory specifies a mobile objects
location for a finite duration; if the simulation continues beyond the last specified
time in the trajectory, the object remains at the trajectorys end point.
In a variable-interval trajectory, by contrast, each point has its own specified

altitude, wait time, and (last-point-to-this-point) traversal time. The wait time
373-Ntdef
Network Domain
Segment-based trajectories come in two varieties: fixed-interval and variableinterval. In a fixed-interval trajectory, one value determines the traversal time for
all segments; hence an object takes the same amount to time to traverse every
segment, regardless of the segments length. In addition, a single value determines
the altitude for all points.
Modeling Concepts
causes a mobile object to pause at each point before it begins traversing the next
segment.
Segment-Based Trajectory Files
Both types of segment-based trajectories rely on ASCII-format trajectory (.trj)
files to specify the units for trajectory coordinates. The formats for fixed-interval
and variable-interval trajectories are shown below.
Fixed-Interval Trajectory File Format
integer
double (in seconds)
Degrees, Kilometers,
Meters, Miles, Feet,
or Local
fixed or relative
doubles
<coordinate_count>
<sample_time_step>
<position_units>
<coordinate_method>
<x_coord_0>, <y_coord_0>, <alt_0>
<x_coord_1>, <y_coord_1>, <alt_1>
...
<x_coord_n>, <y_coord_n>, <alt_n>
Variable-Interval Trajectory File Format

integer
Degrees, Kilometers,
Meters, Miles, Feet,
or Local
fixed or relative
absolute
integer
doubles
(times in seconds)
Version: <version_number>
Position_Unit: <position_unit>
Altitude_Unit: <altitude_unit>
Coordinate_Method: <coordinate_method>
Altitude_Method: <altitude_method>
Coordinate Count: <coordinate_count>
X Position
Y Position
Altitude Traverse Time
<x_coord_0>, <y_coord_0>, <alt_0>, <trav_time_0>,
<x_coord_1>, <y_coord_1>, <alt_1>, <trav_time_1>,
...
<x_coord_n>, <y_coord_n>, <alt_n>, <trav_time_n>,
Wait Time
<wait_time_0>
<wait_time_1>
<wait_time_n>
Though file formats differ for fixed-interval and variable-interval trajectories,

both contain some common characteristics:
Position Units: Both types of trajectories can define positions in terms

of degrees, kilometers, meters, miles, or feet; if the setting is local,
the trajectory uses the coordinate system of the subnetwork in which it
was created.
Note: If a mobile object resides within a mobile subnetwork, and
uses a segment-based trajectory, the parent subnetworks motion
374-Ntdef
Modeling Concepts
affects the objects motion only if the trajectory is defined in nondegree coordinates (feet, meters, etc.).
Coordinate method: A trajectory file supports both relative and absolute path definitions. If the coordinate method is specified as relative, the coordinates are interpreted as offsets from the objects initial
position. If the coordinate method is fixed, the coordinates are interpreted as absolute coordinates within the parent subnetwork.
Examples of Relative and Absolute Trajectory Definitions
in a Fixed-Interval Trajectory
4
60.0
Meters
relative
0.0, 0.0, 5.0
50.0, 25.0, 5.0
50.0, 50.0, 5.0
4
60.0
Meters
fixed
0.0, 0.0, 5.0
50.0, 25.0, 5.0
50.0, 50.0, 5.0
Vector-based Trajectories
For example, the diagram below shows a possible site, called the origin, and its
trajectory based on the great circle around the earth (shown as dark lines). The
objects latitude and longitude would be at the origin at the beginning of the
375-Ntdef
Network Domain
A vector-based trajectory moves in a continuous circular path around the earth,

as specified by the objects bearing, ground speed, and ascent rate attributes.
This path passes through a specific point, usually the mobile site that is following
the path. During simulation, the sites latitude and longitude follow the circular
trajectory. The objects location changes as long as ground speed or ascent rate are
not zero; unlike segment-based trajectories, vector-based trajectories have no fixed
duration.
Modeling Concepts
simulation, and the bearing, ground speed, and ascent rate attributes would determine
its path. Latitude/longitude coordinates follow the great circle path based on the
ground speed of the object, and the altitude varies based on the ascent rate.
The path of an object can change during simulation if the bearing of the object
is changed. In this case, the current latitude/longitude coordinates of the object
become the new point of origin, and a new great circle route is recomputed based
on the new bearing and origin.
Path of an Object on the Great Circle Route
N
trajectory
N
longitude
origin
trajectory
bearing
Equator
longitude
origin
latitude
latitude
S
Ntdef.5.1.2
Direct Manipulation of Position Attributes

If a trajectory is specified for a mobile site, then its path is predetermined for
the entire simulation. However, if no trajectory is specified for a mobile site, then
that sites position may be directly updated by any process during simulation. A
mobile sites x position and y position attributes specify its location in its
parent subnetwork. A mobile sites altitude attribute specifies its elevation
relative to sea level, the underlying terrain, or the parent subnetwork (depending on
the sites altitude modeling attribute setting). A change to one of these
attributes will effect an immediate change in the location of the mobile site.
Typically, one of two techniques is employed to dynamically change the
location of a mobile site. In both cases, a user-defined process is responsible for
modifying the position attributes of a mobile site. The first technique is a
centralized approach, where one process is responsible for updating the positions
of all of the mobile sites in a network model. Often this process resides within a
site specially designated as a central control site. The second technique is a
decentralized approach, in the sense that each mobile site has a process executing
within it that updates the position of the site. The following diagrams show code
samples from an example process model implementing each technique.
376-Ntdef
Modeling Concepts
Example Process Model Fragment Implementing Centralized

Management of all Mobile Nodes Position Attributes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
/* Determine number of mobile nodes in the system. */

num_nodes = op_topo_object_count (OPC_OBJTYPE_NDMOB);
/* For each mobile node, obtain its object ID, system ID */
/* and new location. Set the new values in the position */
/* attributes of the node.
*/
for (i = 0; i < num_nodes; i++)
{
/* Obtain the i_th mobile nodes object ID. */
node_objid = op_topo_object (OPC_OBJTYPE_NDMOB, i);
/* Obtain the new subnet-relative coordinates for the mobile node. */
node_position_compute (node_objid, &x_pos, &y_pos, &alt);
/* Set the parent nodes position attributes to the new values. */
op_ima_obj_attr_set (node_objid, x position, x_pos);
op_ima_obj_attr_set (node_objid, y position, y_pos);
op_ima_obj_attr_set (node_objid, altitude, alt);
}
Example Process Model State Implementing Decentralized

Management of Parent Mobile Nodes Position Attributes
1
2
3
4
5
6
7
8
9
10
/* Obtain the parent nodes object ID. */

parent_node_objid = op_topo_parent (op_id_self ());
/* Obtain the new subnet-relative coordinates for the parent node. */
node_position_compute (parent_node_objid, &x_pos, &y_pos, &alt);
/* Set the parent nodes position attributes to the new values. */
op_ima_obj_attr_set (parent_node_objid, x position, x_pos);
op_ima_obj_attr_set (parent_node_objid, y position, y_pos);
op_ima_obj_attr_set (parent_node_objid, altitude, alt);
377-Ntdef
Network Domain
In contrast to trajectories, where the Simulation Kernel can model continuous

movement, direct manipulation of a mobile sites position attributes forces discrete
position changes. Discrete position changes of a mobile site may cause unexpected
behavior with respect to the default radio transceiver pipeline. Specifically, there
may be issues involving the default signal locking mechanism, packet interference
calculations, and the busy statistic of the radio receiver channel. These
mechanisms rely on the fact that when two packets are sent back-to-back from a
single radio transmitter channel, the first packets reception completion time is the
same as the second packets arrival start time. This is based on two propagation
Modeling Concepts
delay calculations: the first packets propagation delay at the end of its
transmission and the second packets propagation delay at the beginning of its
transmission. If these propagation delays are not the same, then two back-to-back
packets will incorrectly appear to overlap each other or to have a gap between
them.
As two sites move closer together or farther apart during transmission, the
propagation delay of the radio signal will correspondingly change. Thus, at the
beginning and end of transmission of one packet, the start and end propagation
delays for a packet sent from a mobile site may be different. If the difference in
propagation delays is not accounted for, then the overlap or gap behavior occurs
with back-to-back packets.
The default radio transceiver pipeline does not prevent the overlap or gap
behavior in the case of discrete position changes. This is due to the fact that the
Simulation Kernel cannot predict the future location of a mobile site without use of
a trajectory. In this case, the Simulation Kernel sets the end of transmission
propagation distance in a packets TDA OPC_TDA_RA_END_DIST to the same value
as the start of transmission propagation distance, found in the packets TDA
OPC_TDA_RA_START_DIST. The default radio pipeline stage that computes the
propagation delays, dra_propdel.ps.c, uses these values and therefore returns
the same result for both delays.
One solution is to replace the default radio pipeline stage with another that
will correctly compute the end of transmission propagation delay. Below is an
example pipeline stage that correctly calculates this delay. It is assumed that the
procedure node_distance_calculate() returns the distance in meters between the
specified sites at the specified time. If such a procedure is not possible, then some
other solution that handles the default signal locking mechanism, packet
interference calculations, and the busy statistic of the radio receiver channel issues
should be used instead.
378-Ntdef
Modeling Concepts
Example Propagation Delay Radio Pipeline Stage

/* mobile_propdel.ps.c */
/* Propagation delay model for radio link Transceiver Pipeline */
#include <opnet.h>
/* propagation velocity of radio signal (m/s) */
#define PROP_VELOCITY 3.0E+08
void
mobile_propdel (Packet *pkpt)
{
double
start_prop_delay, end_prop_delay;
double
start_prop_distance, end_prop_distance;
Objid
source_node_objid, destination_node_objid;
double
end_rx_time;
/** Compute the propagation delays separating the **/
/** radio transmitter from the radio receiver.
**/
FIN (mobile_propdel (pkptr))
/* Obtain source nodes object ID. */
source_node_objid = op_topo_parent (op_td_get_int (pkptr,
OPC_TDA_RA_TX_OBJID));
/* Obtain destination nodes object ID. */
destination_node_objid = op_topo_parent (op_td_get_int (pkptr,
OPC_TDA_RA_RX_OBJID));
/* Obtain the end of reception time. */
end_rx_time = op_td_get_dbl (pkptr, OPC_TDA_RA_END_RX);
/* Get the start distance between transmitter and receiver. */
start_prop_distance = op_td_get_dbl (pkptr, OPC_TDA_RA_START_DIST);
/* Compute the end distance between transmitter and receiver, based
/* on information that specifies where the nodes will be at the
/* time when the packet has been completely received. This is
/* necessary because, the end distance stored in the packets TDA
/* is invalid if either node moves during the transmission.
end_prop_distance = node_distance_calculate (source_node_objid,
destination_node_objid, end_rx_time);
*/
*/
*/
*/
*/
/* Compute propagation delay to start of reception. */

start_prop_delay = start_prop_distance / PROP_VELOCITY;
/* Compute propagation delay to end of reception. */
end_prop_delay = end_prop_distance / PROP_VELOCITY;
/* Place both propagation delays in packet trans. data attributes. */
op_td_set_dbl (pkptr, OPC_TDA_RA_START_PROPDEL, start_prop_delay);
op_td_set_dbl (pkptr, OPC_TDA_RA_END_PROPDEL, end_prop_delay);
FOUT
}
379-Ntdef
Network Domain
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Ntdef.5.2
Modeling Concepts
Satellite Sites
A satellite site uses an orbit to specify its location during a simulation. The
orbit file holds data specifying the times and locations that the satellite site will
pass through as the simulation progresses. Orbit files have a portable binary
format. You create orbit files using the Satellite Tool Kit program from Analytical
Graphics, and then import the files into OPNET. (See Pt.6.5 Import STK Orbit for
more information on the Satellite Tool Kit.) You can also create orbits via EMA
(refer to the External Model Access chapter in the External Interfaces manual).
The Satellite Tool Kit uses six orbital elements to compute the orbit at a set of
discrete points evenly sampled in time.
When the position of a satellite site is required, the Simulation Kernel will
recompute the location based on the points in the orbit. During simulation, the
satellite site follows the orbit by traveling in a straight line from one position
sample to the next, approximating the orbital path. Thus, the position of the site
during simulation is determined for any time by linearly interpolating between the
position sample just before that time and the next one after it in the orbit.
3-Dimensional View of Example Polar Orbit
While satellite sites with orbits are useful for modeling satellites that move
relative to the earths surface, some satellites motion may be modeled without an
orbit. Since a geostationary satellite maintains a relatively fixed position over one
point on the earths surface, a satellite site without a specified orbit may be an
appropriate model. If the orbit attribute of a satellite site is set to NONE, then the
380-Ntdef
Modeling Concepts
Modeling Node and Link Failure/Recovery
initial values of the position attributes are used, as if the site were fixed to that
location over the earth. This provides an increase in simulation efficiency, since the
sites position does not need to be recomputed each time that it is required.
However, if the slight perturbations of a satellites position in geostationary orbit
are important, then a geostationary orbit should be specified.
2-Dimensional View of a Low Earth Orbit
Ntdef.6

An important aspect of many performance studies is the effect of network
components that fail during operation. Therefore, OPNET simulations provide the
capability to enable and disable communication nodes and links. This section
describes the mechanisms available to model failures and recoveries and presents
some example applications of these capabilities.
When a node has failed, no interrupts destined for modules within that node
will be delivered. However, just before the node fails, failure interrupts, if there are
any, will be the last interrupts to be delivered to modules within that node until the
node recovers. Just after the node recovers, the first interrupts delivered to modules
381-Ntdef
Network Domain
Each node and link object has a condition attribute which specifies whether it
is in an operative state or not. When a node or link changes from an operative state
to an inoperative one, the Simulation Kernel may generate failure interrupts.
Similarly, when a node or link changes from an inoperative state to an operative
one, the Simulation Kernel may generate recovery interrupts. These interrupts will
be delivered to processor and queue modules that request them. These interrupts
are delivered forced, which means that the current event which is changing the
nodes condition attribute, is suspended and each of the interrupts is delivered
during that event.
Modeling Concepts
within that node are the recovery interrupts, also if any are to be delivered. Typically
this does not happen, but the possible exception to failure interrupts being the last
interrupts, and recovery interrupts being the first, to be delivered to modules within
the node, are other forced events that are generated from other interrupts within the
same failure or recovery event.
Ntdef.6.1
Failure and Recovery Mechanisms

Each processor and queue module has attributes that allow the Simulation
Kernel to determine if it expects to receive failure and/or recovery interrupts. The
attribute failure intrpts indicates whether the module expects to receive failure
interrupts and, similarly, the attribute recovery intrpts indicates whether the
module expects recovery interrupts.
These attributes may have one of three values: network wide, local only or
If the attribute is set to network wide, then the module will receive an
interrupt when any node or link fails or recovers, regardless of location in the
network. If the attribute is set to local only, then the module will receive an
interrupt only when its parent node fails or recovers. If the attribute is set to
disabled, then the module will not receive any failure or recovery interrupts.
Disabled is the default value for the attributes, since most modules typically do
not expect these interrupts.
disabled.
When a node failure occurs, several related actions take place. The Simulation
Kernel suspends the current event and delivers the failure interrupts to the
appropriate modules throughout the model. Once all of the failure interrupts are
delivered, then the Simulation Kernel notifies the nodes transmitter and receiver
channels of the failure. All busy transmitter channels abort their current packets in
progress and flush their transmit queues. Each busy receiver channel sets the node
failure TDA in its packet(s) to the current simulation time, if this is the first time
the node failed during each packets reception. In the default transceiver pipelines,
a packet will not be accepted if the node failed at any time during its transmission
or reception. After the interrupts are delivered and the transmitter and receiver
channels have completed their actions, the condition attribute value is internally
set to disabled and the suspended event is reactivated.
Once a node recovers from a failure, the condition attribute value is
automatically set to enabled and then a set of actions occur. The Simulation
Kernel suspends the current event and delivers the recovery interrupts to the
appropriate modules. Once all of the recovery interrupts are delivered, then the
Simulation Kernel notifies the nodes receiver channels of the recovery. Each busy
receiver channel sets the node recovery TDA in its packet(s) to the current
simulation time. After the interrupts have been delivered and the receiver channels
have completed their actions, the suspended event is reactivated.
When a link failure occurs, several related actions take place. The Simulation
Kernel suspends the current event and delivers the failure interrupts to the
appropriate modules. Once all of the failure interrupts are delivered, the condition
attribute value is automatically set to disabled and the suspended event is
382-Ntdef
Modeling Concepts
reactivated. A link failure does not automatically cause packets to be dropped, as is

the case of a node failure. However, once a link is disabled, transmitters prevent
new packets from being sent on the link.
Once a link recovers from a failure, the condition attribute value is
automatically set to enabled. The Simulation Kernel then suspends the current
event and delivers the recovery interrupts to the appropriate modules. These
interrupts are delivered forced, which means that the event that is changing the
nodes condition attribute is suspended and each of the recovery interrupts is
delivered during the event. Once all of the recovery interrupts are delivered, the
suspended event is reactivated.
Ntdef.6.2
Generating Failures and Recoveries

Since a node or link cannot autonomously fail or recover, an external action
must take place to change the state of the node or link during simulation. Typically,
one of four such methods for generating failures and recoveries is utilized:
deterministic, scripted, stochastic or interactive. The deterministic method causes
one node or link to fail and recover at specific times during simulation. The script
method is more general than the deterministic method and is based on a file that
contains explicit times and locations of failures and recoveries. The stochastic
method generates failure and recoveries based on a specified distribution of times
and locations. With interactive manipulation, a failure or recovery is directly set
through the OPNET debugger. Each of these methods is presented later as an
example and may be modified to fit particular modeling requirements.
A failure or recovery occurs for an object when the condition attribute of the
object changes value. Thus, each of the four methods provides a mechanism to
change the attributes value. However, they are different in the manner in which the
object and the time for the failure or recovery is chosen.
Each of the methods, except interactive manipulation, requires that a process
change the condition attribute of the node or link. Generally, one centralized
process or many decentralized processes are responsible for generating the failures
and recoveries. A centralized process typically resides in a node set aside only for
this task and which would itself never fail. On the other hand, each decentralized
process usually resides within a different node and is responsible for its parent
nodes failure and recovery.
383-Ntdef
Network Domain
If a node is disabled, no interrupts will be delivered to the modules within the

node. Due to this fact, a process within the node cannot directly cause the node to
recover. In order to be invoked, the process itself requires an interrupt before it can
change the nodes state, but it cannot receive any interrupts because the node is
disabled. Therefore, if a process is responsible for causing its parent node to
recover, the process may schedule a procedure call interrupt that will invoke a
procedure that will cause the node to recover. Although a procedure call interrupt
invokes the procedure within the context of the process that scheduled it, the
interrupt is not delivered to an object within the node and, therefore, the
Simulation Kernel does not prevent the invocation of the procedure. The diagram
Modeling Concepts
in the next subsection contains example code fragments from a process that causes
its parent node to fail and then recover with this technique.
Ntdef.6.2.1
Deterministic Process Example

The deterministic process example presented in this section is based on the
concept that a particular node or link fails and recovers at a known simulation time.
The process has two attributes to specify the failure and recovery times: fail time
and recover time. Optionally, the process could have another attribute that would
specify the object to be modified, using, for example, a nodes or a links name.
However, this example process simply causes its parent node to fail and then to
recover, by setting the parent nodes condition attribute to disabled and then to
enabled. Since this process is responsible only for its parent node, it can be
considered an example of a decentralized failure/recovery process. The
deterministic process method is recommended when simple failure/recovery
modeling is required for the system. Typically just one failure/recovery cycle is
scheduled, rather than a sequence of them. The following listings contain example
code fragments of a deterministic failure/recovery process.
Example of Scheduling Failure and Recovery of Parent Node

1
2
3
4
5
6
7
8
9
10
11
12
/* Obtain the modules and parent nodes object IDs. */

module_id = op_id_self ();
node_id = op_topo_parent (module_id);
/* Obtain the failure and recovery simulation times. */
op_ima_obj_attr_get (module_id, "fail time", &fail_time);
op_ima_obj_attr_get (module_id, "recover time", &recover_time);
/* Schedule the nodes failure and recovery via "call" interrupts. */
op_intrpt_schedule_call (fail_time, FAIL_CODE, fail_recov_proc, OPC_NIL);
op_intrpt_schedule_call (recover_time, RECOV_CODE,
fail_recov_proc, OPC_NIL);
384-Ntdef
Modeling Concepts
Example Function Block Procedure that

Enables and Disables Parent Node
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Ntdef.6.2.2
fail_recov_proc (state_ptr, code)

char* state_ptr;
int
code;
{
Objid nd_objid;
/**
/**
/**
FIN
This procedure causes the parent node of the module that this **/
interrupt was scheduled in to either fail or recover,
**/
depending on the code.
**/
(fail_recov_proc (state_ptr, code))
/* Obtain the parent nodes object ID. */

nd_objid = op_topo_parent (op_intrpt_source ());
/* Depending on the code, either enable or disable the node. */
if (code == RECOV_CODE)
op_ima_obj_attr_set (nd_objid, "condition", OPC_BOOLINT_ENABLED);
else
op_ima_obj_attr_set (nd_objid, "condition", OPC_BOOLINT_DISABLED);
FOUT
}
Script File Process Example

A script file is a text file that specifies the failure and recovery times as well as
the objects that are affected. Based on the script file, an associated process
generates node and link failures and recoveries system-wide. Since this is the only
process that causes failures and recoveries for the entire system, it can be
considered an example of a centralized failure/recovery process. The script file
process method is useful when a large or complex series of failures and recoveries
occur during a simulation at specific times.
In this example, a script file contains a line for each failure or recovery event.
Each line has three values: the time at which the event is to occur, the user ID of the
object, and the type of event (failure or recovery). The user ID of the object is used
rather than the object ID, since the user id attribute values of nodes and links are
part of the network model and, therefore, are known in advance of the simulation.
Object IDs are assigned by the Simulation Kernel at run-time and can only be
discovered during simulation. Refer to the following diagram for an example script
file.
385-Ntdef
Network Domain
A script file may be generated from one of several sources. If the network
model corresponds to an existing network, the script file may be based on an actual
listing of node and link failures and recoveries. Another option is to create a script
file that represents some specific system behavior, such as a series of nodes failing.
Modeling Concepts
A script file may also be used to test worst case scenarios, for example, where a
set of interdependent nodes and links fail simultaneously.
The associated process reads the script file and builds a list of node and link
failure and recovery times. Once the list is built, the process schedules a self
interrupt for the time of the first failure or recovery event. When the self interrupt
occurs, the process sets the specified objects condition attribute to the
appropriate value by invoking the Kernel Procedure op_ima_obj_attr_set() and
schedules another self interrupt for the next failure or recovery event. The
following listing contains example code fragments of a script-based failure/
recovery process.
Example Script File

# Example script file for node/link failures/recoveries
# Times are expected in order
#
# time
user_id
event
10.00
12
failure
12.30
12
recovery
14.40
3
failure
14.40
4
failure
14.45
5
failure
14.55
4
recovery
100.00
3
recovery
Example Proto-C Causing Object to Fail or Recover

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
/* This process just received a self intrpt that signals a failure */

/* or recovery action. Obtain the top instruction from the list.
*/
inst_ptr = (Script_Inst*) op_prg_list_remove (event_list_ptr,
OPC_LISTPOS_HEAD);
/* Convert user ID to object ID. */
object_id = user_id_to_object_id_convert (inst_ptr->user_id);
/* Set the objects condition attribute to the specified value. */
if (inst_ptr->type == FAIL_CODE)
op_ima_obj_attr_set (object_id, condition,
OPC_BOOLINT_DISABLED);
else op_ima_obj_attr_set (object_id, condition,
OPC_BOOLINT_ENABLED);
/* Deallocate instruction. */
op_prg_mem_free (inst_ptr);
386-Ntdef
Modeling Concepts
Example Proto-C Scheduling Failure/Recovery Self Interrupt
1
2
3
4
5
6
7
/* Obtain the next instruction from the list. */

inst_ptr = (Script_Inst*) op_prg_list_access (event_list_ptr,
OPC_LISTPOS_HEAD);
/* Schedule a self interrupt for the time. */
op_intrpt_schedule_self (inst_ptr->time, 0);
Network Domain
387-Ntdef
Modeling Concepts
Example Proto-C Reading Script File
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
/* Obtain name of script file from the process attribute. */

op_ima_obj_attr_get (op_id_self (), "script name", script_name);
/* Create and init list to hold failure/recovery instructions. */
event_list_ptr = op_prg_list_create ();
/* Load the file contents into a list. */
line_list_ptr = op_prg_gdf_read (script_name);
/* Loop through the lines of the list and parse each line. */
list_size = op_prg_list_size (line_list_ptr);
for (i = 0; i < list_size; i++)
{
/* Obtain the i_th line in the file. */
string = op_prg_list_access (line_list_ptr, i);
/* Decompose the line in to fields. */
field_list_ptr = op_prg_str_decompose (string, " ,/\t");
/* If the line does not have three fields or starts with '#' */
/* then skip it and try the next.
*/
if (op_prg_list_size (field_list_ptr) != 3)
goto dealloc;
field0 = op_prg_list_access (field_list_ptr, 0);
if (field0 [0] == '#')
goto dealloc;
/* Allocate a structure to hold the event instruction. */
inst_ptr = (Script_Inst*) op_prg_mem_alloc (sizeof (Script_Inst));
/* Fill in the instruction. */
inst_ptr->time = atof (field0);
inst_ptr->user_id = atoi (op_prg_list_access (field_list_ptr, 1);
field2 = op_prg_list_access (field_list_ptr, 2);
if (strcmp ("failure", field2) == 0)
inst_ptr->type = FAIL_CODE;
else inst_ptr->type = RECOVER_CODE;
/* Place the instruction on the end of the list. */
op_prg_list_insert (event_list_ptr, inst_ptr, OPC_LISTPOS_TAIL);
/* Deallocate the elements in the list and then the list itself. */
dealloc:
op_prg_list_free (field_list_ptr);
op_prg_mem_free (field_list_ptr);
}
/* Deallocate the elements in the list and then the list itself. */
op_prg_list_free (line_list_ptr);
op_prg_mem_free (line_list_ptr);
388-Ntdef
Modeling Concepts
Ntdef.6.2.3
Stochastic Process Example

A stochastic failure/recovery process generates node and link failures and
recoveries based on distributions, so that the states of the nodes and links change
randomly. The example process has four attributes that determine the frequency of
the failure and recovery events. The node fail mean and link fail mean
attributes specify the mean failure times for a node and a link, respectively.
Similarly, the node recover mean and link recover mean attributes specify the
mean recovery times. The process chooses a particular node or link randomly for a
failure and then schedules a recovery for that node or link. Often, the exponential
distribution is used to model the failure and recovery times. However, other
distributions may be more accurate for a particular system.
A stochastic process is recommended when randomly generated failures and
recoveries are an appropriate model for the system. A stochastic process is
typically more practical than a script file process when a large number of failures
and recoveries occur. A stochastic process has the additional benefit that it
dynamically generates failures and recoveries, adjusting for different size networks
and simulation durations. Also, it can automatically subject a network to typical
scenarios without requiring new user input.
The example process generates failures for nodes and links in parallel. Initially,
the process obtains the mean failure and recovery attribute values. Two failure
times are computed based on the mean times and one self interrupt is scheduled by
the process for a node failure, and another for a link failure. When a self interrupt
occurs for a failure, the process chooses a node or link at random and causes it to
fail by setting its condition attribute to disabled via the KP
op_ima_obj_attr_set(). The process then computes a recovery time for the node or
link based on the specified mean recovery time and schedules a self interrupt for the
recovery and includes the nodes or links object ID as the code of the interrupt. The
object ID is included so that the process can identify which object to enable. When
this interrupt occurs, the condition attribute of the object is set back to enabled.
Along with scheduling an interrupt for the recovery, the process also schedules the
next failure self interrupt. The following listing contains code fragments of an
example stochastic failure/recovery process.
Network Domain
389-Ntdef
Modeling Concepts
Example Proto-C Causing Object to Fail or Recover

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
38
39
40
41
42
43
44
45
46
47
48
49
50
/* This process just received an interrupt. Determine what is to */

/* happen. Node and link failures use the codes; recovery intrpts */
/* contain the object ID of the object to recover.
*/
code = op_intrpt_code ();
if (code == NODE_FAIL_CODE))
{
/* Obtain random node object ID and determine if already disabled. */
object_index = (int) op_dist_uniform (num_nodes);
object_id = op_topo_object (OPC_OBJMTYPE_NODE, object_index);
op_ima_obj_attr_get (object_id, condition, &current_condition)
if (current_condition != OPC_BOOLINT_DISABLED)
{
/* Cause the node to fail. */
op_ima_obj_attr_set (object_id, condition, OPC_BOOLINT_DISABLED);
/* Schedule recovery interrupt; first generate recovery time. */
intrpt_time = op_sim_time () + op_dist_outcome (node_recov_dist_ptr);
op_intrpt_schedule_self (intrpt_time, object_id);
}
/* Schedule the next fail interrupt; first generate failure time. */
intrpt_time = op_sim_time () + op_dist_outcome (node_fail_dist_ptr);
op_intrpt_schedule_self (intrpt_time, NODE_FAIL_CODE);
}
else if (code == LINK_FAIL_CODE)
{
/* Obtain random link object ID and determine if already disabled. */
object_index = (int) op_dist_uniform (num_links);
object_id = op_topo_object (OPC_OBJMTYPE_LINK, object_index);
op_ima_obj_attr_get (object_id, condition, &current_condition)
if (current_condition != OPC_BOOLINT_DISABLED)
{
/* Cause the link to fail. */
op_ima_obj_attr_set (object_id, condition, OPC_BOOLINT_DISABLED);
/* Schedule recovery interrupt; first generate recovery time. */
intrpt = op_sim_time () + op_dist_outcome (link_recov_dist_ptr);
op_intrpt_schedule_self (intrpt_time, object_id);
}
/* Schedule the next fail interrupt; first generate failure time. */
intrpt_time = op_sim_time () + op_dist_outcome (link_fail_dist_ptr);
op_intrpt_schedule_self (intrpt_time, LINK_FAIL_CODE);
}
else
{
/* This is a recovery; the code is the object ID of the object */
/* that is recovering. Set the condition attribute.
*/
op_ima_obj_attr_set (code, condition, OPC_BOOLINT_ENABLED);
}
390-Ntdef
Modeling Concepts
Ntdef.6.2.4
Interactive Manipulation
When a simulation is run under the OPNET debugger, attributes of objects may
be set directly with the ODB command attrset. Through this mechanism, a node
or link condition attribute can be set to enabled or disabled. If the value
changes, recovery or failure interrupts will be generated exactly as if some process
had changed the attributes value via a call to the Kernel Procedure
op_ima_obj_attr_set(). Interactive manipulation is useful for testing the systems
reaction to failures and recoveries on-the-fly.
Ntdef.6.3
Handling Failure and Recovery Interrupts

The transmitter and receiver modules automatically handle a parent nodes
failure and recovery. However, processor or queue modules which have processes
executing in them do not have the built-in capability to handle failure and recovery
interrupts. Three typical examples of processes that are designed to handle failure
and recovery interrupts are described below.
Ntdef.6.3.1
Routing Topology Example

If a node is maintaining a routing topology that is dynamically updated as
nodes and links conditions change, a typical method of updating the topology is
to add a module to the node model that is responsible for that task. You should set
the failure intrpts and recovery intrpts attributes of the modules process
model to network wide. When any node or link changes condition in the system,
the root process inside the module:
Receives a failure or recovery interrupt;
Calls the Kernel Procedure op_intrpt_type() to determine which type of

interrupt occurred;
Calls op_intrpt_source() to determine which node or link changed condition;
Updates the routing topology to reflect the change.
The following listing shows an example code fragment from a process model
that updates a routing table based on object failures and recoveries throughout the
network.
Network Domain
391-Ntdef
Modeling Concepts
Example Proto- C Updating Topology Based on Failure/Recovery Events

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Ntdef.6.3.2
/* This process just received a failure or recovery interrupt and needs

*/
/* to update the local routing topology to reflect the change.
*/
/* Determine where the failure or recovery occurred and the type of
*/
/* object. Only fixed nodes and simplex point-to-point links are
*/
/* expected.
*/
object_id = op_intrpt_source ();
object_type = op_id_to_type (object_id);
/* Determine if the object is a node. */
if (object_type == OPC_OBJTYPE_NDFIX)
{
if (op_intrpt_type () == OPC_INTRPT_FAIL)
{
/* Node has failed; disable it in the topology. */
op_rte_topo_node_disable (rte_topo_ptr,
op_topo_parent (object_id), object_id);
}
else
{
/* Node has recovered; enable it in the topology. */
op_rte_topo_node_enable (rte_topo_ptr,
op_topo_parent (object_id), object_id);
}
Node Failure and Recovery Examples

A node failure is usually considered a catastrophic event for the modules
within the node. Transmitters automatically abort any packets in transmission and
flush their transmit queue. Receivers will not accept packets while the node is
disabled. In addition, a process may require notification of the nodes failure so
that it can leave itself in a clean state. For example, a process within a queue
module may need to flush its buffers of packets or a process may destroy its child
processes. If a module requires notification of the parent nodes failure, the
modules failure intrpt attribute can be set to local only. The process set up to
receive the interrupt will be invoked just before the node actually fails, so that it
may take any actions necessary to handle the node failure. Typically, a process
calls the Kernel Procedure op_intrpt_type() to determine that the interrupt is a
failure interrupt. The following listing shows an example code fragment from a
process model that flushes its packet buffers just before its parent node fails.
392-Ntdef
Modeling Concepts
Example Proto-C Handling Various Interrupt Types

Including Failure Interrupts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
/* This process just received an interrupt. Based on the type of */

/* interrupt, take the appropriate actions.
*/
/* Determine which interrupt type just occurred.
*/
intrpt_type = op_intrpt_type ();
if (intrpt_type == OPC_INTRPT_STREAM)
{
/* Received stream intrpt. Call procedure to handle the packet. */
packet_receive_and_enqueue ();
}
else if (intrpt_type == OPC_INTRPT_SELF)
{
/* Received self interrupt. Call procedure to send a packet. */
packet_dequeue_and_send ();
}
else if (intrpt_type == OPC_INTRPT_FAIL)
{
/* This process just received a failure interrupt for its
*/
/* parent node and must flush the subqueues and cancel self */
/* interrupts.
*/
/* Flush the subqueues. */
op_q_flush ();
/* Cancel all self interrupts. */
op_intrpt_clear_self ();
}
Similarly, when a node recovers, processes within that node often need to reinitialize themselves. For example, a process could reset its counters, zero out its
arrays, and transition to the state where it expects incoming packets. If a process
requires notification when only its parent node recovers, then its containing
modules recovery intrpts attribute is set to local only, so that when the node
recovers, a recovery interrupt will be delivered to the module. The process calls the
Kernel Procedure op_intrpt_type() to distinguish this interrupt type from the others,
such as a stream or self interrupt. The following listing shows an example code
fragment from a process model which re-initializes its state variables when its
parent node recovers.
Network Domain
393-Ntdef
Modeling Concepts
Example Proto-C Handling Various Interrupt Types

Including Recovery Interrupts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/* This process just received an interrupt. Based on the type of */

/* interrupt, take the appropriate actions.
*/
/* Determine which interrupt type just occurred.
*/
intrpt_type = op_intrpt_type ();
if (intrpt_type == OPC_INTRPT_SELF)
{
/* Received self interrupt. Re-transmit packet. */
packet_retransmit ();
}
else if (intrpt_type == OPC_INTRPT_STREAM)
{
/* Received stream interrupt. Handle the packet. */
packet_receive ();
}
else if (intrpt_type == OPC_INTRPT_RECOVER)
{
/* This process just received a recovery interrupt for
*/
/* its parent node and must re-initialize its state variables. */
/* Reset counters to 0. */
num_packets = 0;
num_errors = 0;
/* Set current time. */
start_time = op_sim_time ();
/* Reset array values. */
for (i = 0; i = NUM_ENTRIES; i++)
entry_array [i] = NULL_ENTRY;
}
394-Ntdef

05 Network Domain

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

05 Network Domain

Uploaded by

Copyright:

Available Formats

Chapter 5

Star Topology in Abstract and Network Model Representations

Subnetworks are essentially containers that abstract the network components

Subnetworks may be located within the

Subnetworks provide a powerful mechanism to manipulate complex network

Since a fixed subnetworks position does not change, it is typically used to

The Node Model Specifies the

Every satellite node is located within a subnetwork object. If an orbit is

Simplex and Duplex Point-to-Point Links

Point-to-Point Links and Attributes

Duplex Point-to-Point Link

Duplex link attributes require

Simplex Point-to-Point Link

The point-to-point transceiver pipeline models four link effects: transmission

A packet completely arrives at a receiver after both the transmission and

Bus Links and Taps

The calculations required to determine when and if a packet is successfully

Packet Propagation Delay Is Dependent on Distance

Packet propagation distance from source to dest_0 is 20 meters.

These objects are analyzed to

Link Consistency Rules

All of the transmitters and receivers required by the link

Same number of channels

The channel count attribute for the link object and

Equal data rates

The data rate attribute of the link, and the data

Packet Format Match

The list of packet formats specified in the packet

Some examples of inconsistent links are presented below to illustrate the

Tap is inconsistent due to lack of

Duplex links are inconsistent due to

4 port node white_hub cannot

The second application of link consistency criteria occurs during simulation.

A consistent link may become inconsistent due to

Another interesting question is: how do links become consistent?. In other

available transceivers in each of the involved nodes. However, if no matching

3) Click the Link Interfaces button.

The above information shows that IP interface #0 from RT3 is connected to IP

Since radio is a broadcast technology and depends on dynamically changing

The earths surface does not occlude the source

The earths surface occludes the source and

As a packet is sent from a radio transmitter or received by a radio receiver, the

Locations of Source and Destination Nodes

Distance between nodes = r

C is the speed of light, P is transmitter power, G is directional

Using Paths to Represent Virtual Circuits

Path Model Options

Links IgnoredIn an ignored-link path, you can only specify the

The following diagram shows a router network connecting a site in Canada to

Creating a Path Object

To create a path between two nodes...

OK to add link/ to path

Not OK to add link/site to path

5) Left-click on the node that forms the end of the path.

Modeling Network Traffic

Modeling Network Traffic

Explicitly Modeled Traffic

Physical Coordinate Systems

user-defined inputs are then varied according to the appropriate pre-defined

Device/Link Load Traffic

Conversation Pair Traffic

Physical Coordinate Systems

subnetwork-relative coordinates of an object are its position relative to a particular

Subnetwork Extent and Units