295-Nddef

Node Domain

Chapter 4

296-Nddef

Modeling Concepts

297-Nddef

Modeling Concepts

IntroductionN

od

e Do

main

Nddef.1 Introduction

Network models in OPNET are constructed from two broad classes ofcomponents:

communication nodes

and

communication links

. The internalstructure of these objects, for the most part, is not visible at the network level. Thischapter presents the methods used to specify the internal structure and thereforemuch of the capabilities of communication nodes. For a discussion ofcommunication links, refer to the

Communication Mechanisms

chapter in thismanual.

Both the structural complexity of network nodes and their scope of activity canvary greatly depending on the system which is modeled. On the low end ofcomplexity and function, simple terminals (connected to a host computer via serialconnections) can be considered nodes of a star network. On the other end of thecomplexity spectrum, the network management center of a nationwide publicpacket network can also be considered as a single “hub” node. The table belowpresents some typical examples of node models that can be built with OPNET.

Since the goal of using OPNET is to construct executable simulation models ofcommunication networks, internal node functions must be modeled sufficientlywell that the overall simulation of network behavior is accurate. The systemprovided by OPNET is powerful enough to specify virtually any form ofcommunication node. Moreover, it supports reusability of node substructures, andsharing of effort between various members of a design or development team.

OPNET’s node modeling system is based on a block-structured approach,which is familiar to most engineers and used extensively in modeling systemarchitectures. Some examples of other applications which use this approach aresignal processing, process control, and three-dimensional computer graphics. Inthese applications, the blocks operate respectively on analog or digital signals,fluids or other media, and polygons or vectors. Block-structuring is a naturaltechnique for describing hardware systems, and can also be an effective tool when

Typical Node Models

Node Type General Functions

Workstation Can generate and receive transfers of files or sparsepackets and manage several concurrent network con-nections.

Packet Switch Supports large numbers of incoming and outgoing datalinks and performs packet routing at high speeds.

Satellite Terminal Generates and receives packets according to a chan-nel access protocol. Acts as a multiplexor for many in-coming links.

Remote Data Sensor Acts as a simple source of packets, usually transmittingthem in bursts.

298-Nddef

Introduction

Modeling Concepts

describing the relationships between high-level software objects with well definedinterfaces. In fact, the International Standards Organization’s Open SystemsInterconnect (OSI) Reference Architecture for data communications networks isbased on a block-structured approach, where each block corresponds to a differentprotocol layer. Like the OSI architecture, OPNET’s node models contain blockswhich operate on packets, so it is well suited to modeling protocol layers. Thisaspect of OPNET is discussed in more detail in the section

Modeling LayeredProtocols

on page 328.

In OPNET, a node model is composed of a series of connected blocks called

modules

. Each module contains a set of inputs and outputs, some state memory,and a method for computing the module’s outputs from its inputs and its statememory. The manner in which this computation takes place depends upon the typeof module. Some modules have predefined behavior to accomplish a specificpurpose, while the behavior of other types of modules may be specified by themodel designer.

Node models specify the manner in which the inputs and outputs of variousmodules are connected using objects called

connections

. There are two types ofconnections, one to carry data packets, and one to transmit individual values. Amodule can send data packets over its

output packet streams

, and receive themfrom its

input packet streams

. It may also send individual values over

outputstatistics

, and receive them from

input statistics

. The connection from a sourcemodule’s output stream to a destination module’s input stream is called a

packetstream object

. Likewise, the connection between a source module’s output statisticand a destination module’s input statistic is called a

statistic wire object

. (theconnection objects are usually referred to as

packet streams

and

statistic wires

, orsimply

streams

and

statwires

, respectively). Other more abstract intermodulecommunication mechanisms are available. For more details, refer to

Communication Mechanisms

in this manual.

Modules represent the various functional areas of a node, whetherimplemented in hardware or software. In cases where portions of a node modelcorrespond to hardware structures, separate modules may correspond to specifichardware subsystems that physically exchange data via parallel buses or serial datalinks. For software structures, modules may correspond to software layers (orsublayers) that pass packets via function calls or shared memory. In some cases,modules might have no physical counterparts in the real node, but may be used toset up specific test cases or be dedicated to computing specialized statistics.

The next two sections of this chapter define the capabilities of the varioustypes of modules and connections, and illustrate their specific uses within nodemodels. The remaining sections describe the techniques used in creating certainspecific types of models, including layered protocols, queues, and sharedresources.

299-Nddef

Modeling Concepts

Module DefinitionsN

od

e Do

main

Nddef.2 Module Definitions

Modules represent those parts of a communication node within which data aregenerated, consumed, or processed. There are several different types of modules,distinguished by their function within a node:

processors

,

queues

,

generators

,

receivers

,

transmitters

, and (in OPNET Modeler/Radio)

antennas

. Some types ofmodules (processors, queues, and generators) have functions that are strictlyinternal to a node, while others (transmitters, receivers, and antennas) haveexternal connections to data transmission links. The behavior of processors andqueues can be specified in precise detail by means of user-specified processmodels; other modules have predefined behavior which can be modified only bysetting the values of their attributes. Some module types are limited in the way theycan be connected to other modules.

A module’s internal algorithm is invoked when an external event that willaffect the state of the module occurs. This is a consequence of OPNET’s event-driven simulation methodology. For example, a module’s process model is invokedwhen a packet arrives on one of its packet input streams, or a statistic to which it isconnected changes. Invocations can also be scheduled at regular intervals, or atspecific times by the module itself (to model a timer expiring, for instance).

The sections below describe each module type, giving an overview of itscapabilities and applications. For additional details concerning a particular type ofmodule, including its attributes and output statistics, refer to the correspondingsection of the

Node Reference

chapter in the

Modeling Reference

manual.

Nddef.2.1 Processor Modules

Processor modules are the primary general-purpose building blocks of nodemodels. Their behavior can be completely specified by setting their

process

model

attribute, which specifies the process model to be executed by the module.This process model can respond to external events or interrupts as desired in orderto model a specific function. Processors can be connected to other modules to sendand receive packets via any number of packet streams. For example, a moduledesigned to multiplex a number of data channels over a communications linkmight have several input packet streams and a single output packet stream.

Processor modules are used to perform general processing of data packets. Atypical processor might receive a packet on an input stream, perform someprocessing, and send the packet out again on an output stream. The output packetmight be delayed for a short time, or it might be modified with respect to the inputpacket. For example, a common use of processors is in modeling a layered

300-Nddef

Module Definitions

Modeling Concepts

protocol stack, where each layer provides a well-defined service to the adjacentlayer through a specific interface. In this case, a separate processor module istypically used to model each layer of the protocol, exchanging packets of data withthe modules that represent the next higher and lower layers.

Processor modules can act as traffic generators when you specify theappropriate process model for the module’s

model

attribute. When you specifysuch a model, attributes that configure traffic (interarrival times, packet size,probability density functions) are promoted and appear in the processor module’sattribute list. The standard model set includes process models implemented astraffic generators for several traffic types, including bursty traffic and self-similartraffic.

While processor modules are often connected to other modules via pairs ofstreams (input streams and output streams), this is not always the case. Forinstance, it is possible to use a processor module as a “controller” within a nodemodel. In such cases, the processor often communicates directly with othermodules through statistic wires or

remote interrupts

. In fact, it might not use anypacket streams at all. Processor modules can also be used as traffic sources(generators) or sinks, in which case they might have only output streams or onlyinput streams.

Node models may employ both processor modules and queue modules(described in the next section) to implement general processing of packets.Normally, a processor module would be used in cases where a packet can becompletely processed in response to the interrupt associated with its arrival orgeneration. If this is not the case, and it is necessary to buffer the packet whileawaiting a later event in order to complete processing, then a queue module, withits additional buffering resources, is likely to be more appropriate. This isparticularly true if multiple packets must be buffered simultaneously.

Like all objects, processors have a number of built-in attributes that configuretheir behavior. These attributes can be specified in the node domain, typicallyusing the graphical user interface of the Node Editor. However, processors are oneof the special OPNET objects that support a “model” attribute, in this case to selectthe processor’s root process model. When selecting a process model, a processor’sattributes may change: new attributes may appear, existing attributes may changevalues, and certain attributes may disappear. This depends on the process model’sdeclared model attributes and on its attribute interfaces. Process model attributeinterfaces allow the process model developer to specify values in advance forprocessor built-in attributes. At the same time, a processor attribute can be given astatus of hidden which means that it will exist and have a specified value, but willnot appear on the processor’s attribute list in the user interface. The processmodel’s model attributes allow new attributes to be invented and to automaticallybe appended to be inherited by the processor object. Refer to the

Process Domain

chapter for additional information on process model attributes and processattribute interfaces. Also, refer to the

Modeling Framework

chapter of this manualfor more information model attributes and attribute interfaces in general.

301-Nddef

Modeling Concepts

Module DefinitionsN

od

e Do

main

Nddef.2.2 Queue Modules

Queue modules provide a superset of the functionality of processor modules.Like processors, they can execute an arbitrary process model that describes thebehavior of a particular process or protocol, and can be connected via packetstreams to other modules, allowing them to send and receive data packets. Theprocess model can also affect the queue object’s list of attributes. The previoussection on the processor module provides information concerning the relationshipbetween process models and processors that is also applicable to queues.

The primary difference between processors and queue modules is that queuescontain additional internal resources called

subqueues

, as illustrated in the figurebelow. Subqueues facilitate buffering and managing a collection of data packets.While it is possible to implement this functionality with ordinary processormodules, the use of subqueues, together with the Kernel Procedures thatmanipulate them, provide greater flexibility and ease of implementation of avariety of queueing disciplines. Moreover, subqueues automatically compute anumber of statistics about their operation, which may be collected in astraightforward manner by using probes. For more details, see the

Probe Reference

chapter of the

Modeling Reference

manual.

packet n0 - 1 packet 1 packet n0 - 2 packet 0subqueue 0

subqueue 1

subqueue (k - 3)

Internal Structure of Queue with k Subqueues

packet n1 - 1 packet n1 - 2

packet nk-1 - 1 packet nk-1 - 2

packet nk-2 - 1 packet nk-2 - 2

packet nk-3 - 1 packet nk-3 - 2

subqueue (k - 2)

subqueue (k - 1)

packet 1 packet 0

packet 1 packet 0

packet 1 packet 0

packet 1 packet 0

tail of subqueue head of subqueue

302-Nddef

Module Definitions

Modeling Concepts

Each queue module contains a definable number of subqueues. A subqueue isan object which is subordinate to the queue object and which has its own attributesused to configure it. It is contained within the queue by means of the queue’s

subqueue

compound attribute. This attribute holds a compound-attribute objectwhich is the parent of one or more subqueues. Refer to the

Modeling Framework

chapter of this manual for more information on how subordinate objects are storedusing compound attributes.

The capacity of each subqueue to hold data is unlimited by default, but a limitmay be set on the number of packets or the total size of all packets (or both) withina subqueue. It is up to the processes in the queue to determine what action to takewhen subqueues become full: packets may be removed in order to create space fornew arrivals, or the new arrivals may be discarded. The Simulation Kernel merelyprovides notification that a subqueue can no longer accept additional packets whenan insertion is attempted.

Most of the Kernel Procedures related to queue modules operate directly on aspecified subqueue (for example, packet insertion and deletion, accessingstatistics, or flushing a subqueue). Some Kernel Procedures, however, accessproperties of the queue module as a whole (for example, obtaining aggregatestatistics or flushing the contents of an entire queue module), or of a packet withinthe queue module without regard to the particular subqueue which holds it (forexample, queue insertion time or waiting time). For more details on these KernelProcedures, refer to the descriptions in the

Queue Package

and

Subqueue Package

chapters of the

Simulation Kernel

manual

.

Since the user controls the process model executed by a queue, it is possible tomodel any queueing protocol by defining the manner in which the subqueues areaccessed and managed. Within a module, subqueues may be selected directly by aphysical index, or via

abstract indices

, which allow the process model to choose asubqueue based on its state relative to other subqueues. For example, the shortestsubqueue may be chosen, or the one with the largest queueing delay. Likewise,packets within a subqueue may be accessed directly by index number, or they maybe retrieved abstractly by requesting the packet at the head or the tail of thesubqueue, or the packet with the highest priority. For more details on how thesefeatures can be used to implement a particular queueing discipline, see

ModelingQueues

on page 324.

Nddef.2.3 Transmitter Modules

Point-to-point transmitter Bus transmitter Radio transmitter

303-Nddef

Modeling Concepts

Module DefinitionsN

od

e Do

main

Transmitter modules serve as the outbound interface between packet streamsinside a node and communication links outside the node. There are three types oftransmitter modules, corresponding to the different types of communication links:point-to-point, bus, and radio (Radio version only). Each of the transmitter moduletypes has essentially the same basic behavior, although there are some differencesrelated to the different communication mechanisms.

Transmitter modules can collect packets from one or more input packetstreams and relay them over corresponding

channels

within the communicationslink. A packet received on a given input stream is transmitted over the channel withthe same index number. Each channel may have its own data rate, which can beused with the size of the packet to determine the transmission time. Packetsarriving on an input stream while the corresponding channel is busy with aprevious packet are automatically queued in an infinite-sized buffer. Channels aresubordinate objects of transmitter modules. The transmitter contains them withinits

channel

attribute, which is a compound attribute. The

channel

attribute’s valueis a compound attribute object, which is the parent of all of the contained channels(refer to the

Modeling Framework

chapter of this manual for more information oncompound attributes and subordinate objects). Each channel maintains a set ofattributes that control various aspects of packet transmission. Some of theseattributes are also used to determine compatibility between transmitters, receivers,and link objects in order to form viable links in the Project Editor. Specifically the

data rate

and

packet formats

attributes of channels are used for point-to-pointand bus transceiver channels. For more information, refer to the

Network Domain

chapter’s discussion of link consistency.

Within a node model, a transmitter module is considered to be a data sink.Therefore, although they may have many input packet streams, transmittermodules do not have output packet streams. (An exception to this rule is made forradio transmitter modules, which may be connected to an antenna module via asingle output packet stream.) From the point of view of the network model, atransmitter module acts as the node’s output port, to which a communication linkof the corresponding type may be connected: simplex and duplex links to point-to-point transmitters, and bus links to bus transmitters. (There are no correspondingradio link objects. Instead, the Simulation Kernel determines which radio receivermodules are capable of receiving each packet transmitted by a radio transmittermodule, based on the attributes of those modules.) These relationships areillustrated in the following diagram.

304-Nddef

Module Definitions

Modeling Concepts

In the case of point-to-point and bus transmitter modules, several of theparameters controlling the transmission of packets are actually specified asattributes of the link (such as error rate and propagation delay). Since there is nocorresponding radio link object, transmission-related properties are specified asattributes of a radio transmitter module. For more details, see the description ofradio transmitter modules in Node Reference, and the discussion of the radiotransceiver pipeline in Communication Mechanisms.

Transmitter channel objects respond to an abort command, which causes themto abort the transmission of the current packet. The op_ima_obj_command() KernelProcedure is used for this purpose; for more details, see the description of thisprocedure in the Internal Model Access Package of the Simulation Kernel manual.

Transmitter channel objects calculate a number of statistics which can beusefully monitored by other modules via statistic wires, or collected through use ofa statistic probe. For example, the bit_thruput and pk_thruput statistics may beused to monitor the throughput of a specific transmitter channel, based on the totalsize or number of data packets, respectively. For more details on the statisticssupported by a particular transmitter channel object, see the corresponding sectionof Node Reference in this manual.

Relationship of Transmitter Modules to Network and Node Models

other modules in node model

other node(s) in network model

packet streams comm. link

node

305-Nddef

Modeling Concepts Module DefinitionsN

od

e Do

main

Nddef.2.4 Receiver Modules

Receiver modules serve as the inbound interface between communication linksoutside a node and packet streams inside the node. As with transmitters, there arethree types of receiver modules, corresponding to the different models ofcommunication links: point-to-point, bus, and radio (available only in OPNETModeler/Radio). Each of the receiver module types has essentially the same basicbehavior, although there are some differences related to the differentcommunication mechanisms.

Receiver modules can distribute packets to one or more output packet streamsupon receiving them over corresponding channels within the communications link.A packet received on a given input channel is relayed to the output stream with thesame index number. Channels are subordinate objects of receiver modules. Thereceiver contains them within its channel attribute, which is a compound attribute.The channel attribute’s value is a compound attribute object, which is the parentof all of the contained channels (refer to the Modeling Framework chapter of thismanual for more information on compound attributes and subordinate objects).Each channel maintains a set of attributes that control various aspects of packetreception. Some of these attributes are also used to determine compatibilitybetween receivers, transmitters, and link objects in order to form viable links in theProject Editor. Specifically the data rate and packet formats attributes ofchannels are used for point-to-point and bus transceiver channels. For moreinformation, refer to the Network Domain chapter’s discussion of Link Consistency.

Within a node model, a receiver module is considered to be a data source.Therefore, although they may have many output packet streams, receiver modulesdo not have input packet streams. (An exception to this rule is made for radioreceiver module, which may be connected to an antenna module via a single inputpacket stream.) From the point of view of the network model, a receiver moduleacts as an input port, to which a communication link of the corresponding typemay be connected: simplex and duplex links to point-to-point receivers, and buslinks to bus receivers. (There are no corresponding radio link objects. Instead, theSimulation Kernel determines which radio receiver modules are capable ofreceiving each packet transmitted by a radio transmitter module, based on theattributes of those modules.) These relationships are illustrated in the followingdiagram.

Point-to-point receiver Bus receiver Radio receiver

306-Nddef

Module Definitions Modeling Concepts

In the case of point-to-point and bus receiver modules, many of the parameterscontrolling the transmission of packets are actually specified as attributes of thelink, such as error rate and propagation delay. Since there is no correspondingradio link object, reception-related properties are specified as attributes of a radioreceiver module. For more details, see the description of radio receiver modules inNode Reference, and the discussion of the radio Transceiver Pipeline inCommunication Mechanisms.

Radio receiver channel objects respond to a flush command, which causesthem to flush all packets currently being received. The op_ima_obj_command()Kernel Procedure is used for this purpose. For more details, see the description ofthis procedure in the Internal Model Access Package of the Simulation Kernelmanual.

Receiver channel objects calculate a number of statistics which can be usefullymonitored by other modules via statistic wires, or collected through use of astatistic probe. For example, the busy statistic may be used to perform carriersensing by indicating the receipt of a packet over the link associated with thereceiver. Likewise, the collision_status statistic of bus and radio receiverchannel objects may be used to detect the collision of multiple packets on aparticular bus or radio channel. For more details on the statistics supported by aparticular receiver channel object, see the corresponding section of NodeReference in this manual.

Relationship of Receiver Modules to Network and Node Models

other modules in node model

other node(s) in network model

packet streamscomm. link

node

307-Nddef

Modeling Concepts Module DefinitionsN

od

e Do

main

Nddef.2.5 Antenna Modules

Antenna modules, which are available only in OPNET Modeler/Radio, areused to specify the antenna properties for radio transmitter or receiver modules.The fact that these properties are specified externally to the transmitter or receivermodules makes it convenient to specify the same set of properties for multipletransmitters or receivers within a node. This corresponds, for example, to thecommon real-world case in which a transmitter and receiver share a commonantenna. Radio transmitter and receiver modules which are not connected to anantenna module behave as though they are connected to an antenna with equal gainin all directions.

Antennas are associated with radio transmitter and receiver modules by meansof packet streams. As described above, an antenna module may accept the outputstreams of one or more radio transmitter modules, and/or the input streams of oneor more radio receiver modules. A single antenna module may therefore havemultiple input and output stream connections. However, connections to modulesother than radio transmitters and receivers are not permitted. Sharing a singleantenna module among a number of radio transmitter and receiver modules isillustrated in the figure below.

The significance of antenna modules within a simulation is their effect on radiotransmission and reception of packets, as governed by the antenna’s directionalgain pattern and by its target, the point in space at which the antenna is to be

Sharing an Antenna Module

308-Nddef

Module Definitions Modeling Concepts

directed. An antenna pattern may be created by means of the Antenna PatternEditor, or by a program that uses the External Model Access (Ema) package. Thepattern is then associated with an antenna module by specifying its name as thevalue of the module’s pattern attribute. The antenna’s target is specified by threeother attributes, target latitude, target longitude, and target altitude.These attributes may be modified during the simulation in order to change thedirection in which the antenna is aimed. Two additional attributes, pointing ref.phi and pointing ref. theta, specify a pointing reference, which represents thepoint on the antenna pattern being aimed at the target. Normally, this specificationwill not be changed dynamically, as it usually represents the point of maximumgain of the antenna, called the boresight. However, it is possible to modify thepointing reference if desired by setting these two attributes to new values.

Antenna patterns consist of a set of gain values that vary as a function ofdirection in three dimensions. Thus, from the point of view of a source that istransmitting, its antenna provides a gain value with respect to every other point inspace. The same is true of a receiver’s antenna, and for a given transmission, thegains of both the transmitter and receiver antennas, with respect to each other, aretypically taken into account. Physically, an antenna pattern can be thought of as athree-dimensional object whose shape indicates the relative magnitudes of gain ineach direction. The simplest case is a sphere, which represents an antenna patternknown as isotropic. An isotropic pattern radiates (or captures) power equally in alldirections. Its gain is equal to 0 dB at all points.

Other patterns can be thought of as deformations of the sphere whichrepresents an isotropic pattern, with areas stretching further from the centercorresponding to directions of higher gain. Regions of the pattern that are relativemaxima of the gain function are called lobes. Likewise, other areas may becompressed toward the center of the sphere, indicating a gain less than unity.Where the gain reaches a relative minimum, the antenna pattern is said to have anull.

Isotropic Antenna Pattern

309-Nddef

Modeling Concepts Module DefinitionsN

od

e Do

main

Antenna patterns are defined in a context that is separate from the one in whichthey are deployed. This is due to the fact that a single pattern may be assigned tomultiple antennas in different subnets and with variable pointing requirements.Since a pattern maps gain to all directions in a three dimensional space, it can berepresented as a function of two angle variables called φ and θ (phi and theta). Asshown in the following diagram, the angle φ varies from 0 to 180 degrees and thevariable θ varies from 0 to 360 degrees. Together they uniquely specify alldirections in terms of vectors departing from the center of the pattern.

Antenna Pattern with Lobes

main lobe or“boresight”

side lobe

null”

Xθ = 0 deg.

θ = 270 deg.

φ = 0 deg.

φ = 90 deg.

θ+.φ+.

Y

Z

Note: The X, Y, and Z axes are provided in the Antenna Pattern Editor, and in this diagram, to support visualization of the three dimensional aspects of antenna patterns. However, they do not necessarily correspond to the axes with similar names used in OPNET’s subnet or geocentric coordinate systems

(φ, θ) Coordinate System used to Represent Antenna Patterns

φ = 180 deg.

310-Nddef

Connection Definitions Modeling Concepts

Rotating a pattern’s definition in the φ or θ direction, or some combination ofthe two, does not actually change the pattern’s shape, since there are no privilegeddirections in the pattern. In fact, it can be readily seen that such a change in thepattern’s definition merely corresponds to a substitution of variables for φ and θ,which may in turn result in different pointing specifications when aligning aparticular point of the antenna with a particular target point in space. In general,antenna pointing issues are not dealt with during the definition of an antennapattern. Instead, pointing is accomplished by specifying that the pointing referencemust be directed towards a specific point in space. Typically, this target locationcorresponds to the position of a node that is intended to receive a transmission, orfrom which a transmission is expected. The antenna pattern is treated as a rigidobject, so that orienting a particular part of the pattern in a given direction maysimultaneously affect the resulting gain for other directions.

The five attributes which govern the position of the antenna provide amechanism for aiming one point of the antenna at a specific target. However, theyleave one angle of rotation in the antenna’s attitude unspecified. The antenna couldbe rotated arbitrarily about the axis of pointing, and still conform to a set ofassignments for the five pointing attributes. This looseness in the specification maybe relevant for antennas with side lobes that are asymmetric about the pointingaxis, since their pointing direction remains ambiguous. In such cases, the modeldesigner may wish to augment the specification of the antenna’s direction byappending additional attributes to the antenna object, and creating new radiopipeline stages which make use of their values. Refer to CommunicationMechanisms in this manual for details on the radio Transceiver Pipeline.

Nddef.3 Connection Definitions

Connections represent the communication paths and associations between thevarious modules in a node. There are three types of connections in OPNET nodemodels: packet streams, which support the flow of data packets between modules,statistic wires, which support the transmission of numerical state informationbetween modules, and logical associations, which indicate a binding between twomodules allowing certain pairs of modules to perform a function together. Notethat while connections are the most commonly used means of communicationbetween models, it is possible to transfer data between modules via other means.See Communication Mechanisms for more details.

The sections below describe each connection type, giving an overview of theircapabilities and applications. For a more detailed discussion of these connectionsand their attributes, refer to the corresponding sections of Node Reference.

311-Nddef

Modeling Concepts Connection DefinitionsN

od

e Do

main

Nddef.3.1 Packet Streams

Packet streams are connections that carry data packets from a source module toa destination module. They represent the flow of data across the hardware andsoftware interfaces within a communication node. They are also regarded ascompletely reliable (that is, no packets are lost and no errors are introduced) and ofpotentially infinite bandwidth (since an arbitrarily large packet can traverse astream with no delay). Furthermore, streams have an unlimited capacity to bufferdata packets at the destination module in the order of their arrival.

OPNET provides three different methods for transferring a packet over astream and notifying the destination module of its arrival: scheduled, forced, orquiet. In a scheduled arrival, a stream interrupt is scheduled for the destinationmodule, occurring after all other events of lower priority previously scheduled forthat time. In a forced arrival, the stream interrupt occurs immediately, before anyother scheduled events. Finally, with a quiet arrival, no stream interrupt occurs atall, and the packet remains buffered within the stream. The destination module canobtain the packet only if it explicitly checks for its presence when it responds tosome other event. (For a more detailed discussion of the various interrupt methods,see section Fram.4.2.5 Interrupt Methods of this manual. See also sectionComec.2.2.1 Packet Streams.)

Output streams of generators and receivers (that is, modules which have noprocess models) use the type of arrival specified by the intrpt method attribute ofthe stream. For output streams of processors or queues, the module’s processmodel overrides the value of this attribute by sending the packet to the outputstream using one of the Kernel Procedures op_pk_send(), op_pk_send_delayed(),op_pk_send_quiet(), or op_pk_send_forced(). Refer to the Packet Package chapterof the Simulation Kernel manual for more details on these procedures.

Packet streams support the introduction of a delay between the time a packet isplaced on a stream by the source module and the time it arrives at the destinationmodule. By default, this value is zero, and in many cases this is appropriate.However, a nonzero value may be used to model a constant processing time,propagation delay, or transfer rate. Furthermore, a process model executing in aprocessor or queue module may specify its own delay when it places a packet onan output stream. In this way the delay may be computed as a function of the sizeor contents of the transferred packet, for example.

Packet Stream

312-Nddef

Connection Definitions Modeling Concepts

Packet streams are normally used to carry the actual data packets that themodeled communication node is intended to process, rather than control datawhich represents communication between adjacent modules. While it is possible tosend such control data between processor modules over packet streams, it is oftenmore appropriate to use other mechanisms, such as statistic wires or ICIs (InterfaceControl Information structures). The use of ICIs to communicate control databetween layers of a protocol stack is illustrated in the section Modeling LayeredProtocols on page 328. For further discussion of communication betweenmodules, refer toCommunication Mechanisms in this manual.

Nddef.3.2 Statistic Wires

Statistic wires also carry data from a source module to a destination module.Unlike packet streams, which convey packets, statistic wires convey individualvalues. They are generally used as an interface by which the source module canshare certain values with the destination module, and thereby provide informationregarding its state. They are also used as a signalling mechanism, allowing thesource module to notify the destination module that a particular condition ofinterest has been reached.

Each module within a node has a set of local output statistics whose values areupdated at appropriate times during the simulation. It is this set of statistics whichcan act as the sources of statistic wires. Processor and queue modules, which canexecute user-defined process models, have a set of statistics whose computationand interpretation are defined by their process model. These statistics are updatedwhen the process model calls the Kernel Procedure op_stat_write() (refer to theProcess Domain chapter of this manual for more information on user-defined localoutput statistics). Other modules have a predetermined set of statistics that areupdated automatically by the Simulation Kernel at appropriate times. Each statisticwire can convey only one output statistic, which is specified in the src stat

attribute of the statistic wire, as shown in the following illustration.

Statistic Wire

313-Nddef

Modeling Concepts Connection DefinitionsN

od

e Do

main

Processor and queue modules also have a set of input statistics, which act asdestinations for statistic wires. Process models within these modules can access thecurrent value of a particular input statistic by calling the Kernel Procedureop_stat_local_read(). The statistic wire binds together an output statistic and aninput statistic, so that their values change in a linked manner. In this way the valuesharing described above is accomplished. Note that an output statistic can be thesource of many statistic wires, and similarly an input statistic can be thedestination of more than one statistic wire.

When the value of a statistic changes, the destination module can be notified bymeans of a statistic interrupt. The conditions under which this interrupt occurs canbe controlled by means of attributes of the statistic wire, called statistic triggers.For instance, a wire can be set to cause an interrupt when its statistic becomeslarger than a particular value, or when it becomes smaller than its previous value. Ifno triggers are enabled, then no statistic interrupts will occur, and the destinationmodule must poll the input statistic on its own in order to determine if its value haschanged.

Statistic wires are typically used in one of two ways within node models. First,they may be employed to dynamically monitor the state of another component of acommunication node. Often this is an “unintelligent” physical device like atransmitter or receiver, but it might also be a queue module, for example, if aprocessor needed to alter its behavior based on the size of a queue. In these cases,the statistics being monitored are computed automatically by the SimulationKernel. Second, statistic wires may be used to allow one module to signal another

Any of the local output statistics supported by the “Relay” module can be selected as sources for the statistic wire.

Statistic Wire Source Statistic Selection

314-Nddef

Connection Definitions Modeling Concepts

of a change in its state. Such uses are often called semaphores. In contrast to thefirst case, these values are computed by a process within a processor or queuemodule.

An example of both uses can be seen in the ethcoax_station_adv nodemodel, as illustrated in the following diagram. The defer module computes avariable called deference and supplies it to the mac module via a statistic wire, toinform it when it may transmit the next packet. The defer module computes thisvalue from two input statistics: one is a value supplied to defer by mac, indicatingwhether it has packets awaiting transmission, while the other is the value of thebusy statistic from the bus receiver module. Here the “deference” and “packetswaiting” statistic wires are used as semaphores, while the “busy” wire is used as amonitor.

Nddef.3.3 Logical Associations

Logical associations are special connections that to not actually carry databetween modules. In fact, logical associations do not exist during simulation, butare used purely as specification devices. The purpose of a logical association is toindicate that a relationship exists between two modules in a node model. Theexistence of this relationship is used by OPNET in order to interpret the nodemodel’s structure.

While logical associations rely on the general concept of establishing a bindingbetween two objects, they are currently only supported for creating associationsbetween particular types of transmitter and receiver modules. Specifically, a point-to-point transmitter and a point-to-point receiver may be logically associated, andso may a bus transmitter and bus receiver. No other modules support this type ofconnection. For this reason, logical associations are also called logical transceiverassociations.

ethcoax_station_adv Node Model

“deference” wire

“packets waiting” wire

“busy” wire

315-Nddef

Modeling Concepts Connection DefinitionsN

od

e Do

main

The role of the logical transceiver association is to indicate to OPNET that atransmitter and a receiver function as a pair. While the objects exist independently,OPNET must sometimes make choices of which transceivers to use whenattaching nodes to links in the Project Editor. Each duplex point-to-point link, forexample, makes use of one point-point transmitter and one point-to-point receiverin each of the nodes to which it is connected. Each node may contain multiplemodules that can act as these “termination points” for the link. If it is important tothe node modeler that a particular transmitter and receiver be used for the sameattached link, then this requirement can be expressed by creating a logicalassociation between them. This same capability can be used for bus transmittersand receivers, though it is only applicable on the end of the tap that attaches thenode to the bus. The following figure illustrates the effect of logical associationswhen creating point-point links in the Project Editor.

The transceiver selections made by OPNET can be manually overridden by theOPNET user. However, because IT DecisionGuru and Modeler XE users have novisibility into the structure of node models, the concept of transceivers is foreign tothem. Therefore the IT DecisionGuru and Modeler XE user interfaces do notpermit control of the transceiver selections, and all selections are automaticallyperformed by the tool. For this reason, use of transceiver logical associations is

Selection of Transceivers Using Logical Association

duplex point-to-point link

point-to-point link

Logical associations keep (Rx_0 and Tx0) and (Rx_1 and Tx_1) together in link attachments. (Rx_0, Tx_1) combination is prevented.

remote node

remote node

duplex

316-Nddef

Node Model Interfaces Modeling Concepts

particularly important when developing models to be delivered to IT DecisionGuruand Modeler XE end-users.

Nddef.4 Node Model Interfaces

Two different types of OPNET users work with node models: node modeldevelopers and node model users. Node model users have an external perspectiveof the node model, and are not necessarily cognizant of the model’s internalstructure. They are primarily concerned with two questions:

1) What is the model’s intended functionality?

2) What is the model’s interface?

The model’s interface dictates how one can use the model and control itexternally, without modifying any of its internal specifications.

Node model developers have a perspective that is the mirror-image of the nodemodel users. They are concerned with two questions as well:

1) What is the desired functionality, and how should it be achieved?

2) What aspects of this functionality should be presented and controllableby the user?

In other words, the developer must determine what the model’s interfaceshould offer to the model user. This section describes the various components thatmay constitute a node model’s interface. Many of the concepts that are discussedrely on the more general modeling approach of OPNET, which is explained indetail in the Modeling Framework chapter of this manual.

Nddef.4.1 Node Model Attributes

A developer may create any number of new attributes and associate them witha node model. These node model attributes belong to no particular object in theNode Domain, but to the model as a whole. When the node model is instantiated asa node object in the Project Editor, these attributes are inherited by the node object.Each separate instance of the model inherits its own private “copies” of theattributes. Node model attributes therefore provide a way of augmenting the set ofattributes supported by a class of node objects.

Node model attributes are generally used to provide additional means ofcontrol to node model users. By exposing a characteristic of a node model andallowing it to be modified externally (i.e., on a per-instance basis), the node modelgains generality and can be more broadly re-used in different modeling situations,a principle that is discussed in detail in the Modeling Framework chapter of thismanual. Note that this same approach is supported by process model attributes,which allow new attributes to be introduced for modules in the Node Domain. This

317-Nddef

Modeling Concepts Node Model InterfacesN

od

e Do

main

raises the question of when to employ node model attributes versus process modelattributes. In general, the answer is dependent on the “scope” of the attribute. Inother words, the question is: does the attribute rightfully belong to a particularobject in the node or does it belong to many objects in the node, or even to the nodeas a whole? For example, an attribute specifying the velocity of the node object istruly an attribute of the node rather than any particular object in the node. Incontrast, the processing speed of a packet-switch’s switching element is probably acharacteristic of the processor or queue that represents the switching element,rather than a characteristic of the node as a whole. Of course, the processing speedis still part of the description of the node as a whole since the node encompassesthe switching element. However, it is more closely associated with the processorand belongs to the node only by incorporation.

Another useful question which is more concrete and easier to answer is: whichobjects actually use the attribute during simulation? If the answer includes onlyone object, say a processor module, then in general it makes more sense to declarethat attribute in the process model that is associated with that processor. If on theother hand, many objects in the node model require access to the attribute, then themodel developer may consider defining the attribute as part of the node model.Because model attributes are user-defined, they must in all cases be interpreted byuser-defined logic embedded within process models, or in some rarer casestransceiver pipeline stages. Therefore, there is usually at least one process modelthat must have prior knowledge of the existence of a model attribute, regardless ofwhich level it is declared in. For this reason, there is a natural bias toward declaringmodel attributes at the process level rather than the node level. Another way tounderstand this bias is to realize that, if a model attribute is declared at the nodelevel and a process model expects to refer to that attribute, then problems can occurif the process model is used within a different node model which does not declarethe required attribute. This usually means that process models need to verify theexistence of a node model attribute by using the KP op_ima_obj_attr_exists() priorto accessing the attribute on the node object. For these reasons, model developersgenerally tend to use process model attributes for most applications

Node Model Attribute Declaration

318-Nddef

Node Model Interfaces Modeling Concepts

Node model attributes are declared using the Node Editor’s edit model

attributes operation, which supports attributes of several different data types,including compound attributes. The properties of each attribute can also be definedin order to control the attribute’s behavior when it appears in the Project Editor.Refer to the Modeling Framework chapter of this manual for an in-depthdiscussion of attribute data types and properties. Refer to the Editor Referencemanual for details on how to use the edit model attributes operation.

Nddef.4.2 Node Attribute Interfaces and Derived Node Models

The previous section discussed how model attributes provide the capability tocreate new attributes for a node model. In this section we will briefly discuss hownode model developers can use a separate mechanism called model attributeinterfaces to exercise control over existing attributes, as well as to specify avariety of aspects of a node model’s interface presented to the model user. Theconcepts that are discussed in this section are discussed in a more general andcomplete fashion in the Modeling Framework chapter of this manual.

Attribute Interface Descriptions

The primary capability of attribute interfaces is to support modification ofattributes that promote from objects within the node model. Attributes that aredeclared in the node model attributes are not dealt with in the attribute interfaces,since the model developer has full control over those at the definition stage.Object-promoted attributes can either be built-in attributes of modules andconnections, or process model attributes that have been appended to the attributelists of processors and queues. Using the attribute interface descriptionscomponent of the attribute interfaces, the node model developer can apply thefollowing types of changes to the attributes that the node model offers:

Control provided by Node Attribute Interface Descriptions

Mechanisma Description

Attribute Renaming Provide a new name for an attribute as it is appearsfrom the node model user’s point of view. This is thename of the attribute as it is seen on a node object inthe Project Editor.

Attribute Merging Replace a set of attributes with a single new attribute.The underlying attributes are tied together in the sensethat changes to the new attribute are propagated toeach of them.

319-Nddef

Modeling Concepts Node Model InterfacesN

od

e Do

main

Note that the mechanisms described in the table above apply to built-inattributes of node objects as well as to the object-promoted attributes originating inthe node model. For example, the condition attribute of a node object can berenamed, or hidden using a node model’s attribute interfaces. The following figureshows such a specification in the Node Editor’s Node Interfaces dialog box:

Attribute Properties Changes

Certain attribute properties, including range, symbolmap, comments, and default value can be altered.

Attribute Status Changes An attribute can be given one of three status values:promoted, set, or hidden. Promoted attributes appearon a node object without a value. Set attributes appearon the node object with a value chosen by the nodemodel developer. Hidden attributes have a specifiedvalue, but are not visible on the node object.

a. See the Modeling Framework chapter for an in-depth discussion of the mechanisms dis-cussed in this table.

Control provided by Node Attribute Interface Descriptions

Mechanisma Description

Attribute Interface Descriptions for a Node Model

Attributes promoted from modules have been renamed and set to reasonable initial values.

Built-in attributes of the node object have been set to appropriate values and hidden. The user can no longer change these.

320-Nddef

Node Model Interfaces Modeling Concepts

Additional Node Model Interfaces

The Node Model Attribute Interfaces also regroup several other parts of anode’s interface, though these are unrelated to attributes. These are summarized inthe following table and discussed in detail in the Modeling Framework chapter ofthis manual.

Node Model Derivation

In certain cases, node model developers, or even model users, will find that anexisting node model has all of the capabilities that they require, but in additionprovides too much flexibility to the model user. While providing extra capabilitymay not seem like a problem, it may in fact be undesirable for a variety of reasons,which are presented in the following table.

Additional Node Model Interfaces

Interface Description

Keywords Each node model can carry a set of keywords that areused to identify its relevance to particular network mod-eling efforts. Users of the Project Editor can specifykeywords of interest in order to display only those mod-els that are useful to them in the editor’s Object Palette.

Comments A textual description of the node model allowing thenode model developer to provide any desired informa-tion to the model user. Typically information in the com-ments includes: node model functionality (i.e., whatsort of real-world device it represents); physical link in-terfaces; significance of major attributes; compatibilitywith other models; available statistics, etc.

Supported Node Type Specifies whether the model is capable of being usedby fixed, mobile, or satellite nodes, or any combinationof these.

321-Nddef

Modeling Concepts Node Model InterfacesN

od

e Do

main

In these problem situations, users are seeking what we can refer to as aspecialization of the node model. A specialized version of the node model is lessgeneral and flexible, but is tailored to the needs of a particular application, or atleast a more specific application than the original model. In order to create aspecialization of a node model, OPNET provides a mechanism called modelderivation. Model derivation allows the mechanisms that are available in the NodeModel Attribute Interfaces to be applied to an existing node model. The result ofthis operation is a new node model, called derived node model that depends on theoriginal model, which is called the parent node model. The parent node modelprovides all information that is structural, such as the node model diagram,including modules and connections.

For example, suppose we have a complex and general model R of a routercapable of handling several different protocols P0, P1, and P2, which processespackets at a selectable speed S, and which has a selectable buffer size B for holdingpackets awaiting processing. Now consider that we have an application thatrequires a router that can handle only protocol type P0, that has S = 5000 packets/sec., and B = 200 packets. By creating a model R' derived from R, we can quicklyachieve our goal. In the derivation of R' we can set appropriate attributes of R totheir required values (assuming an attribute exists to control the supportedprotocols) and we can set the status of these attributes to hidden to preventnetwork-level users from changing these settings.

The following figure illustrates the derivation that would be performed toobtain R' from R. Refer to the Modeling Framework chapter of this manual for anin-depth discussion of model derivation.

Reasons to Specialize a Node Model

Problem Details

Complexity can over-whelm end-user

The more flexible and parameterized a model is, themore complex it is for an end-user to configure. In manycases, the parameters of a general model will not ap-pear familiar to the end-user and the work required toconfigure it for each instance will exceed the end-user’sknowledge. If attribute values can be specified in ad-vance and match the user’s requirements, then thenode model will be significantly easier to deploy at thenetwork level.

Flexibility can permitinvalid configurations

The availability of many attributes may provide the op-portunity for the user to create an invalid or unintendednode configuration.

End-user expects particular presenta-tion

The end-user of the node model typically expects aparticular interface that matches his experience withsimilar real-world devices or other models. If this inter-face can be realized, the model will be much more “us-er-friendly”

322-Nddef

Node Model Interfaces Modeling Concepts

Nddef.4.3 Statistic Promotion

The issue of customization and control discussed in the previous section existsnot only for attributes of a node model, but for statistics as well. This sectiondiscusses the node developer’s mechanisms that allow control of the statistics thatare available to node model users.

Most modules at the node level offer a set of built-in statistics. There arestatistics that are computed automatically and made available by the SimulationKernel. In addition, process models are able to declare and compute application-specific statistics that appear as local output statistics of their encompassing queueand processor modules. These sources of statistics combine into a single list ofstatistics that a node model is capable of reporting.

In general, not all of the statistics of a node model are of interest to its users.Many built-in statistics of modules are not relevant or interesting for particularapplications. In addition, process models may compute specialized statistics thatare useful only in very particular situations. In order to avoid overwhelming thenode model user with the complexity of a large statistic set, the node modeldeveloper requires the ability to eliminate those statistics that he considersunimportant. In fact, because the majority of a node’s statistics are typically notwanted, OPNET by default assumes that each statistic should be prevented fromappearing in the node model’s interface. Explicit designation of the desiredstatistics is then required and OPNET provides this capability with a mechanism

Specialization of Model R to Generate Derived Model R’

Model R' has attributes “B”, “S”, and “Protocols” set to specific values and hidden.

323-Nddef

Modeling Concepts Node Model InterfacesN

od

e Do

main

called statistic promotion. Statistic promotion is simply an indication to OPNETthat a model should make a particular statistic available to its users. Promotedstatistics then become available to be assigned to node statistic probes for datacollection during simulation. Refer to the Simulation Design chapter of thismanual for more information on node statistic probes.

For each statistic that is promoted, the node model developer has theopportunity to make three changes to its presentation. First, the name of thestatistics can be changed to be more meaningful for particular applications. Inparticular, by default, each statistic name is prefixed with the name of the modulethat generates it. This is necessary to distinguish between identically namedstatistics associated with different modules. However, the module names canconfuse node model users, especially IT DecisionGuru and Modeler XE users whoare unaware of the internal architecture of the node. For this reason, in almost allcases, some adjustments to the statistic name are specified when the statistic ispromoted.

The second change that can be made is to the statistic’s group. Promotingstatistic groups allows the node model developer to organize statistics into logicalgroups, defined by the developer. This makes it easier for users to find and viewstatistics when they select Choose Results in the Project Editor. Arrangingstatistics in groups also enables the model developer to reuse descriptive names(such as “Throughput (bits/sec)”) for similar statistics in different contexts.

The third change that can be made is to replace the descriptive commentsassociated with the statistic. These comments serve as documentation for thestatistic and can be customized to be appropriate for the anticipated end user.

Node statistic promotion is performed using the promote node statisticsoperation of the Node Editor. The following figure shows the dialog box thatsupports statistic promotion.

324-Nddef

Modeling Queues Modeling Concepts

Nddef.5 Modeling Queues

OPNET’s queue modules are similar to ordinary processor modules, in thatthey can execute arbitrary process models. However, they have the additionalcapability to manage multiple subqueues of packets, as previously described. Thisarrangement allows greater flexibility than if queues were only available in special-purpose modules with predefined behavior. On the one hand, a general-purposeprocess model that also requires the ability to manage groups of packets cansimply be placed within a queue module, where it can take advantage of theadditional resources of subqueues which are not available in a processor module.On the other hand, a queue module can be made to execute any queueing disciplinesimply by changing its process model to one that implements the desired behavior.

Certain common queueing disciplines are needed in a wide variety of systemsand are provided as predefined base models. These models are divided into twobroad classes: active queues may forward packets to their output stream of theirown accord, whereas passive queues only forward packets in response to an accessinterrupt delivered by another module. The predefined queue process models arelisted in the following table, and are described more fully in the Queue Objectsection of the Node Reference chapter and in the Process Model/Queuing chapterof the General Models manual.

Specialization of Model R to Generate Derived Model R’

The new name of each statistic appears in this column. Units may be included if desired.

New descriptions for each statistic are provided in this column. These are the descriptions that can be seen in the Probe Editor.

The new group names of promoted statistics appear in this column. Statistic names appear within these groups in the Statistic Browser.

325-Nddef

Modeling Concepts Modeling QueuesN

od

e Do

main

Nddef.5.1 Abstract Subqueue and Packet Indices

When using a Kernel Procedure in the Subq package to operate on a subqueue,an index is used to specify the desired subqueue. Alternatively, special constantsmay be used for the index parameter to select a subqueue according to someproperty other than its index number. For instance, a constant may be used to selectthe smallest subqueue, or the one with the highest mean packet waiting time. Theseconstants are defined in the following table.

Predefined Queue Process Models

Model Name Description

acb_fifo active, concentrating, bit-oriented, first-in first-out

acb_fifo_ms active, concentrating, bit-oriented, first-in first-out, multi-server

acp_fifo active, concentrating, packet-oriented, first-in first-out

pc_fifo passive, concentrating, first-in first-out

pc_lifo passive, concentrating, last-in first-out

pc_prio passive, concentrating, priority

pf_fifo passive, flowthrough, first-in first-out

prq_fifo passive, requeueing, first-in first-out

Subqueue Selection Index Symbolic Constants

Constant Description

OPC_QSEL_MAX_PKSIZEOPC_QSEL_MIN_PKSIZE

subqueue with the maximum/minimumcurrent number of packets

OPC_QSEL_MAX_AVG_PKSIZEOPC_QSEL_MIN_AVG_PKSIZE

subqueue with the maximum/minimumaverage number of packets

OPC_QSEL_MAX_AVGI_PKSIZEOPC_QSEL_MIN_AVGI_PKSIZE

subqueue with the maximum/minimumaverage number of packets, as seen byincoming packets

OPC_QSEL_MAX_AVG_DELAYOPC_QSEL_MIN_AVG_DELAY

subqueue with the maximum/minimumaverage queueing delay on packets

OPC_QSEL_MAX_BITSIZEOPC_QSEL_MIN_BITSIZE

subqueue with the maximum/minimumcurrent number of bits

OPC_QSEL_MAX_AVG_BITSIZEOPC_QSEL_MIN_AVG_BITSIZE

subqueue with the maximum/minimumaverage number of bits

326-Nddef

Modeling Queues Modeling Concepts

Similarly, a packet position for extraction or insertion may be specified to aSimulation Kernel procedure either with a physical index (that is, 0 for the firstpacket in the queue, 1 for the second, etc.), or with a special constant that selectsthe packet at the head or tail of the subqueue, or the packet with the highest priorityas indicated by its priority attribute. These constants are listed in the followingtable.

Nddef.5.2 Implementing Priority Queues

Frequently models will require the implementation of priority queueingsystems, in which different types of packets are accorded precedence over otherswhile waiting to be forwarded to another module. In some cases, packets may beclassified into a discrete set of priority levels. For example, a system might supportjust two priorities, high and low. In other cases, a continuous range of prioritiesmay be needed. This might occur, for example, in a system which gives higherpriority to queued packets the longer they have been in existence.

OPC_QSEL_MAX_AVGI_BITSIZEOPC_QSEL_MIN_AVGI_BITSIZE

subqueue with the maximum/minimumaverage number of bits, as seen by in-coming packets

OPC_QSEL_MAX_OVERFLOWSOPC_QSEL_MIN_OVERFLOWS

subqueue with the maximum/minimumnumber of space overflows

OPC_QSEL_MAX_FREE_PKSIZEOPC_QSEL_MIN_FREE_PKSIZE

subqueue with the maximum/minimumcurrent number of free packet slots

OPC_QSEL_MAX_AVG_FREE_PKSIZEOPC_QSEL_MIN_AVG_FREE_PKSIZE

subqueue with the maximum/minimumaverage number of free packet slots

OPC_QSEL_MAX_FREE_BITSIZEOPC_QSEL_MIN_FREE_BITSIZE

subqueue with the maximum/minimumcurrent number of free bits

OPC_QSEL_MAX_AVG_FREE_BITSIZEOPC_QSEL_MIN_AVG_FREE_BITSIZE

subqueue with the maximum/minimumaverage number of free bits

Packet Position Index Symbolic Constants

Constant Description

OPC_QPOS_HEAD head position of subqueue

OPC_QPOS_TAIL tail position of subqueue

OPC_QPOS_PRIO priority-derived position of subqueue

Subqueue Selection Index Symbolic Constants (Cont.)

Constant Description

327-Nddef

Modeling Concepts Modeling QueuesN

od

e Do

main

In either case, priority schemes create an ordering of packets in the queue. Thecontinuous priority range model is used within OPNET subqueues, since a discretepriority classification can be regarded as a special case of the continuous system.However, the collection of subqueues within the queue can also be used as amechanism to represent discrete priorities. This is done by creating one subqueueper priority level, and inserting packets into the appropriate subqueue based upontheir priorities. When a packet is removed from the queue, the subqueues arescanned in priority order until a non-empty subqueue is found, thus guaranteeingthat the highest priority packet available is always removed first. This technique isillustrated by the following code fragments.

Within individual subqueues, the abstract subqueue position index constantOPC_QPOS_PRIO provides a convenient method for inserting or extracting packetswhile respecting priority ordering. For this purpose, the priority of a packet isspecified by its priority attribute, which can be set with the Kernel Procedure

/* Insert an arriving packet into the appropriate subqueue. *//* The "get_prio()" function returns the priority, which *//* may be derived from a packet field, or from the packet's *//* "priority" attribute, and is an integer between 0 and *//* NUM_PRIOS - 1, where NUM_PRIOS is the number of priority *//* levels (and also of subqueues). 0 is the highest priority. */

prio = get_prio (pk_ptr);op_subq_pk_insert (prio, pk_ptr, OPC_QPOS_TAIL);

Using Subqueues to Implement Discrete Priorities

/* Extract the packet with the highest priority, that is, *//* the packet at the head of the lowest-numbered subqueue *//* that contains packets. As before, NUM_PRIOS is the *//* number of priority levels and subqueues. */

pk_ptr = OPC_NIL;for (i = 0; i < NUM_PRIOS; i++)

{if (op_subq_empty (i) == OPC_FALSE)

{pk_ptr = op_subq_pk_remove (i, OPC_QPOS_HEAD);break;}

}

if (pk_ptr != OPC_NIL)op_pk_send (pk_ptr, OUT_STRM);

Using Subqueues to Implement Discrete Priorities (Continued)

328-Nddef

Modeling Layered Protocols Modeling Concepts

op_pk_priority_set(). If the OPC_QPOS_PRIO constant is passed as the packetposition to the Kernel Procedure op_subq_pk_insert(), the packet of interest will beinserted ahead of all packets of lower priority and behind all packets of higher orequal priority. Similarly, if this constant is passed to op_subq_pk_access() orop_subq_pk_remove(), these procedures will operate on the highest priority packetpresent in the subqueue. Refer to the Subqueue Package in the Simulation Kernelmanual for more information on these procedures.

A simple priority queueing process model called pc_prio (passiveconcentrating priority queue) is included with OPNET as part of the standardmodels library. This process model operates only on a single subqueue, using thepriority attribute of packets to order them. It can be employed in its default formfor many priority queueing applications, or modified as desired, and serves as abasic example of a priority queue implementation.

Nddef.5.3 Implementing Finite Queues

Limitations in buffer space can be modeled by specifying the maximumnumber of packets or bits that can be held by each subqueue of a queue module.Usually, either a packet limit or a bit limit is set. However, if both are used, they areapplied as separate criteria, so that if either limit is reached, further insertions intothe subqueue will be prevented. These limits are set with the pk capacity and bitcapacity attributes of subqueues. The default value for these attributes is infinite.

Limitations imposed on subqueue sizes have no effect on queueing behavioruntil a packet insertion is attempted that would cause the limits to be exceeded. Forexample, if a subqueue with a capacity of fifty packets already contains fiftypackets, then calling the Kernel Procedure op_subq_pk_insert() to insert anadditional packet results in a failure: instead of returning the status flagOPC_QINS_OK as usual, the procedure returns OPC_QINS_FAIL, indicating that thequeue insertion was not successful. The Simulation Kernel does not resolve thecontention for buffer space. Instead, the process model must take some explicitaction. Depending on the nature of the process being modeled, it might choose toinsert the new packet at the expense of a packet already in the queue, which wouldfirst have to be removed from the queue in order to permit a successful insertion, orit might choose to discard the newly arriving packet instead.

Each time an insertion fails due to lack of capacity in a subqueue, a queuestatistic called overflows is increased by one. This statistic can be written to thesimulation output file and viewed in the Analysis Tool, or used dynamically byprocess models as the simulation progresses, to monitor and/or modify thebehavior of the queue.

Nddef.6 Modeling Layered Protocols

Layered protocols are used in many communications networks to decomposean otherwise complex system into more manageable parts. Each of these parts, orlayers, has a well-defined interface to the adjacent layers, offering a specific set ofservices to the higher layer while acting as a client of the services provided by the

329-Nddef

Modeling Concepts Modeling Layered ProtocolsN

od

e Do

main

lower layer. As discussed previously, OPNET’s block-structured approach tomodeling is well-suited to modeling layered protocols. Each layer in a protocol canbe modeled by a processor or queue module. In some cases, it might be appropriateto further decompose each layer into multiple modules.

The following diagram illustrates the concept of a layered protocol asdescribed by the ISO OSI Model, and an analogous layered OPNET node model.Each layer of the OSI Model has a corresponding processor module in the nodemodel, and these modules exchange data over packet streams only with themodules that represent the adjacent layers. Just as each layer of the OSI Model istypically specified individually, so each layer of the node model can beimplemented by a processor module executing a process developed separatelyfrom the others.

330-Nddef

Modeling Layered Protocols Modeling Concepts

A number of the example models supplied with OPNET are designed in thismanner. For example, the X.25 node model, which is supplied in the models/std/x25 directory, incorporates an application processor, the X.25 DCE or DTEmodule (which implements the network layer), and the LAPB module (whichimplements the data link layer). The X.25 DTE node model is illustrated in thefigure below. (For more details on the implementation of these models, refer to thecorresponding chapters of the Protocol Models manual.

ApplicationLayer

PresentationLayer

SessionLayer

TransportLayer

NetworkLayer

Data LinkLayer

PhysicalLayer

OSI Model OPNET Process Stack

OSI / OPNET Layering Analogy

331-Nddef

Modeling Concepts Modeling Layered ProtocolsN

od

e Do

main

Interfaces between adjacent layers generally involve the transfer of controlinformation, such as a command value or an address, in addition to the actual datapacket. OPNET provides the ICI (Interface Control Information block) to passsuch parameters between layers. This encourages modularity between differentprotocols, as it allows the control information to remain separate from the datapacket. Most protocol layers will not need to examine a data packet passed by ahigher layer at all, but can use the information in the ICI to control its processing.In particular, the format of the data packet remains local to a particular interface,and does not depend on the packet format at higher or lower layers of the protocolstack. Instead, a layer will combine information from an ICI with the higher layerdata packet into a packet format suitable for the lower layer (or unpack the lowerlayer’s packet, packaging information from the packet header into an ICI for thehigher layer). The process of combining data into lower-level packets is illustratedin the diagram below. For more examples of this strategy, refer to the x25 model,the process models in the standard model directories, and to the correspondingchapters of the Protocol Models manual.

x25_dte_adv Node Model

Examples of a Layered Protocol Model

332-Nddef

Modeling Shared Resources Modeling Concepts

Nddef.7 Modeling Shared Resources

In general terms, a shared resource is an entity that provides a service to anumber of competing clients, whose access to the resource is limited. Typically, aclient will request access to the resource, and depending on the availability of theresource, access may be granted immediately, or the client may have to wait. Whenaccess is granted, the client maintains access to the resource for a period of time,while the task that required the resource is being executed. When the task iscompleted, the resource is released, so that other competing clients may access it.Real world examples of shared resources include the CPU of a computer system(or one of the CPUs in a multiprocessor system), a printer or other output device, acommunications channel, a bus for peripheral devices or expansion cards, or apage of shared random-access memory.

Since it is not always possible for a request to be serviced immediately upon itsarrival, there must be some provision for buffering requests until the resourcebecomes available. A variety of schemes for managing these requests is possible,depending upon the desired performance goals, such as maximizing throughput,minimizing delay, minimizing the variation in delay (a property called fairness), orproviding prioritized access to the resource.

An OPNET queue module is well suited to address these issues, as its built-insubqueues provide the necessary facilities for buffering requests (implemented aspackets), and the ability to execute arbitrary process models allows different accessdisciplines to be implemented and compared. The process model managing ashared resource controls the manner in which requests are queued when the

Level 3 Processor

Level 2 Processor

Level 1 Processor

Level 3 Packet

Level 2 Packet (with encapsulated data from Level 3 ICI)

Level 2 ICI (with control information for level 1)

Level 3 ICI (with control information for level 2)

Interfacing Adjacent Layers of Protocol Stack

333-Nddef

Modeling Concepts Modeling Shared ResourcesN

od

e Do

main

resource is not available, as well as the method by which the client actuallycontrols the resource once access has been granted.

When a packet representing a request is received, the process model mustdetermine whether the corresponding resource is available. If not, the request mustbe queued according to the chosen discipline. The queue models described inModeling Queues on page 324 can serve as a basis for implementation. When theresource becomes available, the requesting process can be notified in one of twoways, according to the requirements of the simulation:

• The resource manager can return the request packet to the requestingclient, setting a field to indicate that the request was granted and the cli-ent now has access to the resource. The client then begins the processfor which the resource was needed. When it is done with the resource,it notifies the resource manager (which can be done either by a remoteinterrupt or by sending another packet), so that other requests can beserviced.

This approach is called an allocation-oriented scheme, because it mod-els the case where a resource is allocated by a process for its exclusiveuse. An example of this might be a tape drive allocated by a user of acomputing facility in order to read data from a tape, as no other userscan access the tape drive until the first user releases it (after finishingwith the tape).

• Alternatively, the resource manager can retain the request for a specificlength of time (the service time), which may be computed according toparameters specified in the request packet. In this case, the processingis modeled within the resource manager, instead of within the client. Atthe end of the service period, the manager returns the request packet tothe client, thereby notifying it that the requested processing has beencompleted.

This approach is called a job-oriented scheme, because it models thecase where clients submit jobs or tasks to be performed using a re-source, and are notified when their job is completed. To continue theprevious example, users of the computer facility may submit print jobscontaining files to be printed. These jobs may be buffered in a queueand are serviced when the printer becomes available, at which point theusers are notified that their documents are available. Another exampleis the facility’s time-sharing computer system, in which users’ compu-tation tasks are serviced in a time-sliced fashion. In this manner manyjobs are able to use the shared resource simultaneously (or at least ap-parently so).

Each approach has its advantages and disadvantages. The allocation-orientedscheme requires the cooperation of the client processes to notify the resourcemanager when they release the resource so that other clients may gain access,which the job-oriented scheme avoids. Moreover, the allocation-oriented scheme

334-Nddef

Modeling Shared Resources Modeling Concepts

provides total control of the resource to the client. While this is occasionallydesirable, it precludes the use of “round-robin” or other scheduling strategiesproviding shared access to the resource, which is supported by the job-orientedscheme. On the other hand, it is possible with the allocation-oriented scheme tomodel cases in which a client must reserve a number of separately managedresources in order to perform a given task.

OPNET provides a group of standard resource manager models, known as theJob Service Discipline (Jsd) models, in the models/std/jsd directory. As thename suggests, they use a job-oriented scheme. These models can be used as theyare, or treated as examples upon which to build other resource managementschemes. They are described in the Job Service Discipline Model Description.