05 network domain

8/16/2019 05 Network Domain

1/60

335-Ntdef

Network omain

Chapter 5


2/60

336-Ntdef

Modeling Concepts


3/60

337-Ntdef

Modeling Concepts

Introduction

Ntdef.1 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 tocomplex. 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.

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

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

Star Topology in Abstract and Network Model Representations


4/60

338-Ntdef

Network Objects

Modeling Concepts

the parent of the objects inside of it and the objects are the children of the

subnetwork.

A special subnetwork called the top level or

global

subnetwork is the highestlevel 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.

Subnetworks Abstract the Network Components Contained Within Them

top subnet

Subnetworks may be located within thetop subnetwork or within other subnetworks

Subnet Hierarchy


5/60

339-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 twoseparate 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

subnetwork’s region is defined in degrees, then the x

position

attribute is the

subnetwork’s longitude and the y

position

attribute is the subnetwork’s latitude.

If the subnetwork’s 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.

Since a fixed subnetwork’s 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-to-

point and bus links.


6/60

340-Ntdef

Network Objects

Modeling Concepts

Ntdef.2.1.2 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 subnetwork’s position

attributes. If trajectory segments are specified, the subnetwork’s 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 asimulation via an assigned orbit, which specifies its orbital path through time. The

satellite subnetwork’s 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 node’s 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 toNode 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.

http://../06_Editor_Ref/06_16_Pt.pdfhttp://../07_Ext_Int/07_37_Ema.pdfhttp://../07_Ext_Int/07_37_Ema.pdfhttp://../06_Editor_Ref/06_16_Pt.pdf


7/60

341-Ntdef

Modeling Concepts

Network Objects

There are three types of communication nodes: fixed

, mobile

and satellite

. The

node types have essentially the same core capability, since the node model definesthe 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 subnetwork’s region is defined in

degrees, then the x

position

attribute is the node’s longitude, the y

position

attribute is the node’s latitude, and the altitude

attribute value is in meters. If theparent subnetwork’s 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 node’s 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

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

Node Object

Node Model

The Node Model Specifies the Internal Structure of a Node


8/60

342-Ntdef

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.

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 node’s statically defined position attributes.

If a statically defined trajectory is specified, the node’s 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-to-

point 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. Thesatellite node’s 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.

Typical LAN Node

http://../06_Editor_Ref/06_16_Pt.pdfhttp://../06_Editor_Ref/06_16_Pt.pdf


9/60

343-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 subnetwork’s 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.

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 tocommunicate with each other, based on a dynamic evaluation. Each type of link is

described in more detail later in this section.

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

Link

Communication Channel

Transmitter Receiver

A Link Is Composed of One or MoreIndependent Communication Channels


10/60

344-Ntdef

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 pipelinebecause it provides a conduitconnecting 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 chapterfor 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 andreceiver 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.

http://01_28_comec.pdf/http://01_28_comec.pdf/http://01_28_comec.pdf/http://01_28_comec.pdf/


11/60

345-Ntdef

Modeling Concepts Network Objects

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.

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 link’s delay

attribute. This value applies to every communication channel within the link. The

Point-to-Point Links and Attributes

Duplex link attributes requirespecification of two transceivers

in each node.

Server Hub

Duplex Point-to-Point Link

Chelsea

Hillary

Simplex Point-to-Point Link

http://01_28_comec.pdf/http://01_28_comec.pdf/


12/60

346-Ntdef

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

receiver’s 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 thenumber 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 receiver’s ecc threshold attribute,

which specifies the maximum number of errors per bit that can be corrected. For

example, if a packet’s 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 andreceivers 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 non-

empty 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

http://../10_General_Models/10_16_Ps_Bu.pdfhttp://../10_General_Models/10_16_Ps_Bu.pdf


13/60

347-Ntdef


node that periodically emits a synchronization signal and has no need to receive

information from other nodes.

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.

The calculations required to determine when and if a packet is successfullyreceived are performed by the bus link’s 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.

Bus Link and Taps with Attributes

Bus Link

Tap

Tap Attributes

Bus Attributes



14/60

348-Ntdef


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 link’s 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 transmitter’s tap to the receiver’s, since the taps

identify where the transceivers are located on the bus. The distance is not the line-

of-sight distance, but the distance along the bus. Since the transmitter may besending copies of the packet to multiple receivers at different locations, the packets

may arrive staggered in time at each receiver.

The transmission delay is the time required by the transmitter channel to send apacket. 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

20m

60m

Packet propagation distance from “source” to “dest_0” is 20 meters.

Packet propagation distance from “source” to “dest_1” is 60 meters.

Packet Propagation Delay Is Dependent on Distance along Bus Link from Source to Destination Node



15/60

349-Ntdef


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 receiver’s ecc threshold attribute, which specifies the

maximum number of errors per bit that can be corrected. For example, if a packet’ssize 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, andeven 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 thenode 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.

OPNET’s 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 subnetwork’s characteristics are not considered.

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

http://../10_General_Models/10_16_Ps_Bu.pdfhttp://../10_General_Models/10_16_Ps_Bu.pdf


16/60


17/60

351-Ntdef


Link consistency plays two primary roles in OPNET. Its primary use is as a

verification mechanism to be used during specification. OPNET’s Project Editor

supports this with the Verity Links operation. This operation detects inconsistentlinks 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.

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 oneach end. For a simplex point-to-point link, this meansthat 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. Buslink attachments allow transmit-only and listen-onlyconfigurations. Therefore it is consistent for a bus tap to

have either the transmitter, the receiver, or both as-signed.

Same number of channels The channel count attribute for the link object andthe count of the channel compound attribute for each

assigned transmitter and receiver must be equal. Apromoted value is considered to match any value towhich it is compared.

Equal data rates The data rate attribute of the link, and the datarate attribute of channel [0] of each assigned trans-

mitter and receiver must be equal. A value of unspec-

ified may be provided for a data rate attribute, inwhich case, it is considered to match any value to

which it is compared. Similarly, a promoted data ratealso matches any value to which it is compared.

Packet Format Match The list of packet formats specified in the packetformats attribute of the link and the packet for-

mats attribute of channel [0] of each assigned trans-mitter and receiver must have a non-emptyintersection. These attributes support the special sta-

tus values all formatted and unformatted , bothof which can be simultaneously supported. “Unformat-

ted” means that packets with no format are supported.“All formatted” means that any formatted packet can be

supported.



18/60

352-Ntdef


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.

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 link’s transmitter are dropped rather

Tap is inconsistent due to lack ofbus transceivers in FR_Switch

Duplex links are inconsistent due topacket format and data rate differences

Link Inconsistency Examples

4 port node “white_hub” cannot

support any additional candidatestations, therefore link to station

“gingrich” is inconsistent


19/60

353-Ntdef


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 link’s packet formats attribute.The packet format may also

not be supported by the transmitter channel in the source node or by the receiverchannel 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 transmitter’s

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 packet’s 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 channel’s 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 OPNET’s 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.


20/60

354-Ntdef


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, OPNET’s 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 firstavailable 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

Causes of Inconsistency

Cause Details

Inconsistent at creation When a link and one or more devices are connected to-gether in the Project Editor, it may not be possible for a

consistent link to be established. This may be due tothe fact that there are no matching transmitters/receiv-ers available in the node models, or that none are avail-

able (i.e., they are already used for other links). Ratherthan create a link that does not match its transceivers,

the Project Editor will simply leave the transceivers un-assigned. The link is then inconsistent according to the

completeness rule in the table above.

External Specification Network models can also be specified using the Exter-nal Model Access (EMA) capability. In this case, link

transceiver attributes can be configured in an arbitrarymanner, and may violate one or more of the rules in the

table above.

Model changes A consistent link may become inconsistent due tochanges to link or node models. Specifically, removal or

renaming of transceiver objects, as well as changes to

data rate, packet formats, and channel countattributes may violate one or more of the consistencyrules described in the table above.



21/60

355-Ntdef


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. Inother 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 link’s Attributes dialog box appears.


22/60

356-Ntdef


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 aparticular 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.



23/60

357-Ntdef


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 earth’s 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.

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.

As a packet is sent from a radio transmitter or received by a radio receiver, thepower 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

Default Model of Occlusion by the Earth’s Surface

The earth’s surface does not occlude the sourceand destination sites, so a radio link is possible.

The earth’s surface occludes the source anddestination sites, thus no radio link is possible.


24/60

358-Ntdef


the radio signal reaches the destination site, the transceiver pipeline also calculates

the direction of the signal into the receiver’s antenna, if there is an antenna. The

antenna may increase or decrease the signal received based on the incomingdirection 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 transceiverpipeline.

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 similar—though not identical—

to defining a link. First you configure an object palette to include the models you

Distance between nodes = r

Propagation delay =

Received power = P tx G txλ2

16Π2r 2------------------

G rx×××

r C ⁄

Locations of Source and Destination Nodes Affect Radio Link in Default Transceiver Pipeline

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.



25/60

359-Ntdef


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 model’s 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 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 Required—In a required-link path, you must specify all con-

necting links and midpoints between the two end nodes. Note that youcan only define a required-link path across point-to-point links. Trafficfollows the exact path from source to destination.

• Links Ignored—In an ignored-link path, you can only specify thepath’s two end sites. The underlying models fully determine the pathbetween the source and destination.

pathoptions

Path Model Description Dialog Box


26/60

360-Ntdef


• Links Optional—This is a combination of the required-link and ig-nored-link types. You must define the two end sites, but defining anyconnecting links and nodes is optional. If there is no defined path be-tween two sites, the underlying models determine the path that traffictakes 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 theexact 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 Formats—Each path has a defined set of supported packet for-mats. You cannot define a link as part of a path unless it supports allformats included in that path model’s Packet Formats field.

• Two Endpoints Only—If this option is set to Yes, you can only createsingle-segment paths.

• Subnets Ignored—If this option is set to No, you cannot include a sub-

network in a path definition.

• Allow Cycles—If this option is set to No, you can only include eachlink or site once in a path definition.


27/60

361-Ntdef


Ntdef.2.4.2 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 modelsyou 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.

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.

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

Not OK to add link/site to path

Visual Feedback in Path-Creation Mode

OK to add link/ to path


28/60

362-Ntdef

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 finish defining a path, you are still in path-definition mode. You can create another path (basedon the same underlying model) by repeating steps 3 through 7. To exit path-definition node, right-click andchoose Abort Path Definition 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 beset 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


29/60

363-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, youcan use the object’s 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 object’s 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 link’s background utilization attribute

is 0%.

Note: If your network uses a routing protocol that responds dynam-

ically 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, conversationpair 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.

Ntdef.4 Physical Coordinate Systems

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

http://01_43_trf.pdf/http://01_43_trf.pdf/http://01_43_trf.pdf/http://01_43_trf.pdf/


30/60

364-Ntdef

Physical Coordinate Systems 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 subnetwork’s extent , which specifies the subnetwork’s location

and size.

A subnetwork’s 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 subnetwork’s 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-

A Subnetwork’s Extent Specifies its Location and Size

Extent boundary


31/60

365-Ntdef


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 thesubnetwork’s extent.

A subnetwork’s 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 subnetwork’s coordinate system.

Subnetwork’s Internal Coordinate System

X direction

Y direction


32/60

366-Ntdef


The units and extents of all subnetworks are configurable, except for those of

the top subnetwork. The top subnetwork’s 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 isdescribed 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.

Subnetwork’s Extent Attributes

Extent boundary

y span

x span

Extent Specification


33/60

367-Ntdef


For subnetworks and nodes contained within a subnetwork whose coordinatesystem has units of degrees or arc seconds, the position–related attributes of these

objects hold global position coordinates. For example, within the top subnetwork,

a node’s 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

node’s 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.

Global Coordinate System

Prime Meridian

Equator

Lines of Longitude

Lines of Latitude


34/60

368-Ntdef


Ntdef.4.3 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 object’s location is an offset from

the origin of the subnetwork’s extent, which is its top left corner. A description of a

position as an offset within a subnetwork’s extent is termed subnetwork-relative.

A site has x position, y position and (except for fixed subnetworks)

altitude attributes that specify its location. In a subnetwork-relative coordinate

system, the attribute values are in the units of the subnetwork. The x positionattribute specifies the x offset and the y position attribute specifies the y offset

from the extent’s origin. The altitude attribute indicates the site’s altitude

relative to its parent subnetwork. (In this case, the parent subnetwork’s 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.

Fixed nodes, mobile nodes, and mobile subnetworks contain an enumerated

attribute called altitude modeling, which determines how OPNET interprets

an object’s altitude attribute. This attribute has three possible settings:

• relative to subnet–platform – The object’s altitude isrelative to its parent subnetwork. (The parent subnetwork’s elevation isits absolute distance above global sea level.)

• absolute – the object’s altitude is relative to global sea level.

• relative to terrain – the object’s altitude is relative to the

/* 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 attributes of the antenna module. */

op_ima_obj_attr_set (antenna_mod_objid, “target latitude”, lat);

op_ima_obj_attr_set (antenna_mod_objid, “target longitude”, lon);

op_ima_obj_attr_set (antenna_mod_objid, “target altitude”, alt);

/* Schedule the next re-pointing timer. */

op_intrpt_schedule_self (op_sim_time () + REPOINT_TIMEOUT,

REPOINT_TIMER);

1

2

3

4

56

7

8

9

10

11

12

13

14

15

16

17

Example Fragment of a Process Model State Executive Determining Global Position Coordinates of a Node


35/60

369-Ntdef


underlying terrain (ocean, hill, valley, etc.).

For an object within a subnetwork-relative coordinate system, determining its

global position may involve a recursive set of computations. If the parentsubnetwork’s extent is specified in the global coordinate system, then obtaining an

object’s global position only requires computing its offset in degrees from the

extent’s top left corner. However, if the parent subnetwork is also within a

subnetwork-relative coordinate system, then its extent’s global position, too, must

be computed. Thus, a series of computations may be required, until a parent

subnetwork’s global position is known. All of these computations are handled by

the Simulation Kernel.

x offset = 600 km

y offset =400 km

Position Attributes within a Subnetwork-Relative Coordinate System


36/60

370-Ntdef


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:

Latitude offset of 400 km = 3.59°

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

(-140.60°, 3.75°)

Units are degrees

Units are kilometers

3.59°

5.39°

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 subnetwork’sextent.

2) Compute the object’s latitude offset in degrees.

3) Compute the object’s latitude.4) Compute the object’s longitude offset in degrees at the computed latitude.5) Compute the object’s longitude.6) Compute the object’s altitude offset in meters.

7) Compute the object’s altitude.

In this example, the node’s x

position is 600 km, its y position is 400 km, and

its altitude is -10 meters.


37/60

371-Ntdef


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 0°N90°E, the y-axis at 0°N 0°E, and the z-axis at 90°N.

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 theglobal, 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.

Geocentric Coordinate System

y

z

x

0°N

0°E

90°E

An object’s position is specified by its (x, y, z) coordinate values.



38/60

372-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 site’s global position coordinates using the

following formulas:

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.

Ntdef.5 Modeling Node and Subnetwork Movement

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 providesmobile 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 site’s position attributes.

Formulas for Conversion of Global PositionCoordinates to Geocentric

R altitude Earth’s radius+=

X R la ti tu de( )cos× longitude( )sin×=Y R latitude( )cos× longitude( )cos×=Z R latitude( )sin×=

y

z

x

(x,y) = (0,0)

x (incr. long.)

y (decr. lat.)

Relationship Between Subnetwork-Relativeand Geocentric Coordinate Systems


39/60

373-Ntdef

Modeling Concepts

Modeling Node and Subnetwork Movement

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 site’s location.

If no trajectory is specified, then any process can directly modify the positionattributes 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 object’s 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 segment–based

. A vector-

based trajectory consists of a direction and a velocity that can be changed at runtime. If a mobile object’s 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

object’s 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 Editor’s 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 great-

circle path from one defined point to the next. OPNET determines an object’s

position at a given time by interpolating between the trajectory points immediately

before and after that time. A segment-based trajectory specifies a mobile object’s

location for a finite duration; if the simulation continues beyond the last specified

time in the trajectory, the object remains at the trajectory’s end point.

Segment-based trajectories come in two varieties: fixed-interval

and variable-

interval

. In a fixed-interval trajectory, one value determines the traversal time forall segments; hence an object takes the same amount to time to traverse every

segment, regardless of the segment’s length. In addition, a single value determines

the altitude for all points.

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

http://../06_Editor_Ref/06_16_Pt.pdfhttp://../06_Editor_Ref/06_16_Pt.pdfhttp://../06_Editor_Ref/06_16_Pt.pdfhttp://../06_Editor_Ref/06_16_Pt.pdf


40/60

374-Ntdef

Modeling Node and Subnetwork Movement

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.

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 termsof degrees, kilometers, meters, miles, or feet; if the setting is local,the trajectory uses the coordinate system of the subnetwork in which itwas created.

Note: If a mobile object resides within a mobile subnetwork, and

uses a segment-based trajectory, the parent subnetwork’s motion

, ,

, ,

...

, ,

Fixed-Interval Trajectory File Format

Version:

Position_Unit:

Altitude_Unit:

Coordinate_Method:

Altitude_Method:

Coordinate Count:

X Position Y Position Altitude Traverse Time Wait Time

, , , ,

, , , ,

...

, , , ,

Variable-Interval Trajectory File Format

integer

double (in seconds)

“Degrees”, “Kilometers”,

“Meters”, “Miles”, “Feet”,or “Local”

“fixed” or “relative”

doubles

integer

integer

“Degrees”, “Kilometers”,“Meters”, “Miles”, “Feet”,

or “Local”

“fixed” or “relative”

“absolute”

doubles

(times in seconds)


41/60

375-Ntdef

Modeling Concepts Modeling Node and Subnetwork Movement

affects the object’s motion only if the trajectory is defined in non-

degree coordinates (feet, meters, etc.).

• Coordinate method: A trajectory file supports both relative and abso-lute path definitions. If the coordinate method is specified as rela-tive, the coordinates are interpreted as offsets from the object’s initialposition. If the coordinate method is fixed , the coordinates are inter-

preted as absolute coordinates within the parent subnetwork.

Vector-based Trajectories

A vector-based trajectory moves in a continuous circular path around the earth,

as specified by the object’s 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 site’s latitude and longitude follow the circulartrajectory. The object’s location changes as long as ground speed or ascent rate are

not zero; unlike segment-based trajectories, vector-based trajectories have no fixed

duration.

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

object’s latitude and longitude would be at the origin at the beginning of the

4

60.0

Meters

fixed

0.0, 0.0, 5.0

50.0, 25.0, 5.050.0, 50.0, 5.0

4

60.0

Meters

relative

0.0, 0.0, 5.0

50.0, 25.0, 5.050.0, 50.0, 5.0

Examples of Relative and Absolute Trajectory Definitions in a Fixed-Interval Trajectory


42/60

376-Ntdef

Modeling Node and Subnetwork Movement 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 c

05 network domain

Documents