Chapter 6 Communication Mechanisms - LUMSsuraj.lums.edu.pk/~te/simandmod/Opnet/06 Communication mechanisms.pdf · OPNET provides several communication mechanisms to address the range

395-Comec

Communication Mechanisms

Chapter 6

396-Comec

Modeling Concepts

397-Comec

Modeling Concepts

IntroductionC

om

mu

nicatio

n

Mech

anism

s

Comec.1 Introduction

Most OPNET models can be classified as distributed systems composed ofmultiple subsystems that interact with each other. The subsystems’ interactionsrely on communications resources to support exchanges such as commands,queries, and general information. Communication may be required betweensubsystems that are physically distinct as well as between those that are logicallyseparated based on their functional areas. OPNET provides several communicationmechanisms to address the range of needs required by sophisticated applications;this chapter discusses each of the supported forms of communication and theirapplicability to various modeling situations.

Comec.2 Packet-Based Communications

The most prevalent form of communications in OPNET models is based on thegeneral notion of messages that can carry information and be sent betweensubsystems. In the OPNET modeling environment, these messages are called

packets

, a term taken from the field of communications networks; however,packets may be used in many different types of applications to represent generalmessages, or transfer of information.

Comec.2.1 General Properties of Packets

Packets are data structures defined by the OPNET environment in order tosupport message-oriented communications. Each packet exists as an individualstructure that can be used to transfer information from one entity to another.Packets are treated as objects, which can be created, modified, examined, copied,sent, received, and destroyed.

Comec.2.1.1 Packet Structure

Each packet contains several information storage areas. The first and mostfrequently used area consists of a list of

fields

which provide storage for user-defined information. Packets may be

formatted

or

unformatted

. A formatted packetallows its fields to be accessed (both for setting and getting) by named reference,whereas an unformatted packet requires that its fields be specified by index. If apacket is formatted or unformatted, its fields may be used to store information ofvarious types: integer and double fields store numerical data; packet fields allowthe encapsulation of a packet within another; structure fields allow the inclusion ofa user-defined data-structure within a packet.

In addition to fields, all packets contain predefined information such as priorityassignments, and time and place of creation. A third storage area is dedicated tostoring information that supports the modeling of packet transmission overcommunication links. For a discussion of packet structure, refer to the

ModelingOverview

chapter of the

Modeling Concepts

manual.

398-Comec

Packet-Based Communications

Modeling Concepts

Comec.2.1.2 Packet Size

In addition to their information content, fields have an assigned size in terms ofbits. The size of all the assigned fields in a packet plus a base value known as thepacket’s

bulk data size

determine the packet’s overall size. This is not the size ofthe packet as stored in the host computer’s memory, but rather the modeled size,used in calculations of such values as transmission time, or error probability.

Comec.2.1.3 Packet Ownership

Packets are treated essentially as physical objects, which implies that each onecan exist in only one location at a given time. Therefore when a packet is sent, theentity that sends it loses access to the packet. The entity that has control of a packetis referred to as the packet’s

owner

. Generally, modules or packet streams are theowners of packets.

A module may obtain ownership of a packet in four ways:

• The packet may be created with the KPs

op_pk_create()

,

op_pk_create_fmt(),

or

op_pk_create_vvec()

• The packet may be created as a copy of an existing packet with the KP

op_pk_copy()

• The packet may be decapsulated from within another packet with theKPs

op_pk_nfd_get()

or

op_pk_fd_get()

• The packet may be received via an input stream and acquired with theKP

op_pk_get()

A packet stream simply obtains ownership of a packet when its source moduleuses it to send a packet to its destination module using the KPs

op_pk_send()

,

op_pk_send_delayed()

,

op_pk_send_quiet()

, or

op_pk_send_forced()

. Ownershipis retained until the destination module acquires the packet or the stream is flushed.In addition, the ownership of a packet can be conferred upon the Simulation Kernelwhen a packet is accessible to no simulation objects; and a special abstract form ofownership called universal is reserved for packets that have been affected by themechanism

op_pk_declare()

(typically used to allow operations on static packets).Universal ownership signifies that all entities may access a packet.

Comec.2.2 Packet Transmission Mechanisms

Packets are rarely used as static storage items that simply remain within onephysical or logical context. Instead, they are almost always created dynamically toallow information to be transferred between contexts. The OPNET SimulationKernel offers several mechanisms to support packet-based communication. One ormore of these mechanisms may be appropriate, depending upon the relationship

399-Comec

Modeling Concepts

Packet-Based CommunicationsC

om

mu

nicatio

n

Mech

anism

s

between the context that initiates the transfer and the context that receives thepacket.

Comec.2.2.1 Packet Streams

Packet streams are physical connections that support the transfer of packetsbetween modules within the same node. Packet streams are defined between anoutput port of a source module and an input port of a destination module. Theseports are usually referred to as the source module’s

output stream

and thedestination module’s

input stream

, respectively.

Each module may have an unlimited number of input streams and an unlimitednumber of output streams. “Fan-in” and “fan-out” are not allowed; that is, eachinput stream can be the recipient of only one packet stream object, and each outputstream can be the source of only one packet stream object. However, any or allinput and output streams may be left unconnected.

Queuing at the Input Stream

Each packet stream contains a single queue for packets; this queue isassociated with the destination module’s input stream in order to allow packets towait until the destination module is ready to acquire them by calling

op_pk_get()

.The Simulation Kernel does not place a limit on the number of packets a packetstream’s queue can hold. The packets are maintained in the order in which theyarrive, and since the destination module can only obtain the head of this queue (bycalling the KP

op_pk_get()

), the queue can be considered first-in-first-out (FIFO).

Interrupt Methods

If a packet stream’s source module is a processor or a queue, it may sendpackets that it owns to the packet stream’s destination module by calling any of thefour variants of the KP

op_pk_send()

. Each of these KPs implements the transferwith a slightly different behavior, as explained below.

source destination

Each input stream queues arriving packets and releases them to the destination in FIFO order when op_pk_get() is called

Queuing in Packet Streams

Delays associated with packet transfer must elapse be-fore packet enters input stream queue

∆T

400-Comec


Modeling Concepts

•

op_pk_send()

: This form of packet transfer is referred to as

standardpacket sending

, because it is the most commonly used. A call to

op_pk_send()

results in the scheduling of a stream event for the desti-nation module in order to indicate the arrival of a new packet; the timeof this event is the current time added to the value of the packet stream’s

delay

attribute. If the value of this attribute is zero (which is thedefault), the stream event is scheduled for the current time. Note thatmodule priorities throughout the system, and interrupt priorities at thedestination module, affect the execution order of this event relative toothers scheduled for the same time.

Immediately prior to generating a stream interrupt for one of the pro-cesses in the destination module, the Simulation Kernel inserts thetransferred packet at the tail of the input stream’s queue. If there are noother packets queued at that time, then the destination process may ob-tain the packet with a single call to

op_pk_get()

; otherwise, multiplecalls to this KP are required to obtain the packet. At its option, the des-tination process may also choose to ignore the new arrival and leave itin the input stream’s queue. Note that if the interrupt cannot be deliv-ered to a destination process, the packet is still queued, allowing it to beobtained at a later time.

•


: This form is similar to standard packet sendingin that it also makes use of event scheduling and generates an interruptfor an appropriate process in the destination module. However, the KP


supports the specification of a positive delayvalue that postpones the arrival of the packet at the destination’s inputstream for an additional amount of time. The stream event representingthe arrival of the transferred packet at the destination occurs at the cur-rent time added to the sum of the specified delay and the value of thepacket stream’s

delay

attribute. All other aspects of this form of packettransfer are identical to those obtained by using

op_pk_send()

.

Note that since


allows the delay value to be setindependently on each call, the order of packet arrivals at the destina-tion of a given stream may not match the order in which packets are sentusing this KP.

•

op_pk_send_forced()

: This form of packet transfer does not make useof event scheduling. Instead it causes the sending process to be sus-pended and immediately queues the packet in the input stream and gen-erates an event for the destination module. The packet remains queuedregardless of whether the event results in one of the destination mod-ule’s processes receiving an interrupt. No delays are possible in forcedpacket transfers, so the packet stream’s

delay

attribute is ignored.

Note that the sending process resumes execution only after the destinationprocess blocks. For a description of the general behavior of forced events, refer tothe

Modeling Framework

chapter of

Modeling Concepts

.

401-Comec

Modeling Concepts


om

mu

nicatio

n

Mech

anism

s

•

op_pk_send_quiet()

: This form of packet transfer is used to avoid thegeneration of an interrupt for any of the destination module’s processes.In other words, the only real effect of this KP is to place the transferredpacket at the end of the packet stream’s queue. The packet is insertedinto the queue on an immediate basis (i.e., this action is not scheduledand can be assumed to have completed by the time the KP call returns).

op_pk_send_quiet()

is most often used in conjunction with an

accessinterrupt

in order to immediately forward a packet in response. The KP

op_pk_send_forced()

cannot be used in this situation since it would re-sult in a forced event feedback loop between the source and destinationmodules; this is due to the fact that access interrupts, generated by theKP

op_strm_access()

, are also forced interrupts.

This KP is also sometimes used as a device to reduce the total numberof interrupts due to packet transfers. The general technique employedfor this purpose is to forward a large number of packets in a row using

op_pk_send_quiet()

followed by a single packet transfer using

op_pk_send()

, or

op_pk_send_forced()

. The process that is interruptedas a result of the last packet transfer then determines the number ofpackets contained in its input stream(s) by calling

op_strm_empty()

and

op_strm_pksize()

. This process can use this information to decidewhether to extract some or all of the transferred packets.

Each packet stream has an attribute called

intrpt

method

that can affect theform of packet transfers that it supports. This attribute is only considered when thepacket stream source is a module other than a processor or queue. The attribute canspecify a

scheduled

,

forced

, or

quiet

interrupt method. If

scheduled

isselected, then packet transfers behave as in the case of

op_pk_send()

and


, with a possible delay value specified in the stream’s

delay

attribute; if

forced

is selected, then the packet stream behaves as though a processwere forwarding packets using

op_pk_send_forced()

. Finally, if the interruptmethod is

quiet

, the packet stream behaves as though a process were forwardingpackets using

op_pk_send_quiet()

.

402-Comec


Modeling Concepts

Comec.2.2.2 Packet Delivery

Packet streams support communication only between modules within the samenode. If modules use only this means of transferring packets then transmitters andreceivers must be relied upon to convey packets between nodes. However, in somecases, it is not convenient to connect all nodes that directly transfer packets to eachother. In addition, certain systems in which communicating nodes would rely onintermediate nodes to relay packets may sometimes be accurately and more simplymodeled by abstractly allowing direct communications, even though no physicalconnections exist. In order to support modeling of such systems, OPNET providesa mechanism referred to as

packet delivery

, that allows any processor or queuemodule to directly transfer packets to any other processor or queue module,regardless of physical location.

Use of “intrpt method” Attribute for non-Processor/Queue Source

intrpt method is only relevant if packet stream’s source is not a queue or processor

Packets may be delivered to modules in other nodes without any physical connections existing between the nodes

source

destination

Packet Delivery Between Modules in Unconnected Nodes

403-Comec

Modeling Concepts


om

mu

nicatio

n

Mech

anism

s

Packet Delivery Mechanics

With respect to the destination side of the mechanism, packet delivery operatessimilarly to packet sending via streams. In other words, packets are inserted intothe queue of an input stream of a destination module, and depending on theselected interrupt method, an event may be generated.

In order to initiate a packet delivery, a process may call any of the KPsop_pk_deliver(), op_pk_deliver_delayed(), op_pk_deliver_forced(), andop_pk_deliver_quiet(). The desired interrupt method can be specified by using theappropriate KP. The four delivery KPs have the same behavior as thecorrespondingly named stream-based KPs discussed in the previous section.

Since the destination module is not implicitly related to the source module, asin the case of packet streams, it must be explicitly designated when a packetdelivery is initiated. The destination module’s object ID is therefore expected byeach of the KPs that support packet delivery. A number of methods exist fordetermining the object ID’s of destination modules; these methods are supported bythe KPs of the Id and Topo packages of the Simulation Kernel.

Similarly, the input stream to which a packet will be delivered must bespecified explicitly at the time where the delivery is requested. Input streams areidentified by integer index. Packets may be delivered to any input stream,including those that are connected to packet stream objects and those that are not.Note that delivery to an input stream whose index exceeds that of the highestconnected input stream causes the allocation of memory for every intermediateindex; while the amount of memory per index is small, the total allocation can belarge since it grows linearly with the maximum index.

Because packet delivery operations are independent of each other, there are no“fan-in” restrictions for the sources of a particular input stream. In other words,any number of sources may deliver packets to the same input stream. Of course, asingle source may also deliver packets to multiple input streams.

source0source1

dest0

dest1

dest2Single input stream of a module may receive packet deliveries from multiple sources.

Fan-In and Fan-Out of Packet Delivery Mechanism

404-Comec

Packet-Based Communications Modeling Concepts

Comec.2.2.3 Communication Links

Once a packet is created by a module, it may be transferred to another modulein the same node; that module may in turn transfer it to a third module in the samenode. In many cases however, the packet must ultimately be transmitted tomodules in other nodes. The previous section described the use of packet deliveryas a means of transferring packets between nodes. Packet delivery is an abstractrepresentation of a physical link which may be useful when the existence of linkscannot be known in advance or when actual physical characteristics of the links arenot required for simulation accuracy. OPNET also supports a more directrepresentation of physical links with three types of communication link modelsreferred to as point-to-point, bus, and radio.

Point-to-Point Links

Point-to-point links allow packets to be transmitted between a single pair ofnodes. Two types of point-to-point links are provided: simplex point-to-point links,which support the transfer of packets from a transmitter in one node to a receiver inanother; and duplex point-to-point links, which connect a transmitter-receiver pairin one node to a transmitter-receiver pair in another. A duplex link acts as twosimplex links that run in opposite directions.

For a point-to-point link to be operable, it must be attached to point-to-pointtransmitters and receivers in the nodes that it connects. The transmitter(s) andreceiver(s) of a simplex point-to-point link are designated using its transmitterand receiver object attributes; for duplex links, four attributes, transmitter a,receiver a, transmitter b, and receiver b, serve to identify the moduleswithin the nodes to which the link is attached. The transceiver modules areimportant from a modeling point-of-view because they represent the exit and entrypoints for packets in the transmitting and receiving nodes respectively. In otherwords, a transmitter module can be viewed as the “gateway” for packets departingto a remote node. In order to send a packet to a remote node attached by a point-to-point link, a module can simply send the packet the appropriate point-to-pointtransmitter module within its own node; the transmitter then provides the service

Equivalent Duplex and Simplex Point-to-Point Link Configurations

Duplex Link Simplex Links

405-Comec

Modeling Concepts Packet-Based CommunicationsC

om

mu

nicatio

n

Mech

anism

s

of transporting the packet to the receiver at the other end of the attached point-to-point link.

Each point-to-point link can be thought of as a “bundle” representing one ormore communication channels between the transmitter(s) and receiver(s) that itconnects. The number of channels in a link is determined by the channel countattributes of the connected transmitter and receiver objects. Each channel actsindependently of the other channels in the same link, as though it were defined in aseparate and parallel simplex link. However, the ability to bundle channels togetheris provided to improve the convenience of defining multichannel trunks.

Point-to-point link channels can be thought of as a pipe between a port of apoint-to-point transmitter in a source node and a port of a point-to-point receiver ina destination node. Ports are referenced by numerical index and corresponddirectly to the input streams and output streams for transmitters and receiversrespectively. In other words, a packet can be transmitted using the n-th channel of alink by sending that packet into the n-th input stream of the transmitter at the link’ssource. At the link’s destination, arriving packets are issued by the receiver on itsn-th output stream. The following diagram illustrates the flow of packets.

Each channel incorporates a simple first-in-first-out queue on its transmittingside. The purpose of the queue is to regulate transmissions in a channel so that thecontent of only one packet is being transmitted at any given time. Since a packetgenerally requires a nonzero amount of time to transmit, other packets that arrived

Transmitters and Receivers Act as Gateways to/from other Nodes

channel 3channel 2

channel 0channel 1

input stream 0input stream 1input stream 2input stream 3

output stream 0output stream 1output stream 2output stream 3

Correspondence betweenInput Streams, Channels, and Output Streams

406-Comec


later must wait until its transmission has completed before theirs can begin.Because the FIFO queue has no holding capacity limitation, this mechanismallows packets to be forwarded to a transmitter module’s input stream at anarbitrary rate, while still respecting the proper timing for individual transmissions.

Both types of point-to-point links can be configured to affect packettransmission in several ways. Underlying each link is a series of user-definablemodels called pipeline stages. In general, the pipeline stages performcomputations related to the transmission of a packet in order to decide the time ofreception and whether or not a packet is received correctly. The complete operationand specification of pipeline stages is discussed in a later section of this chapter.However, in general, pipeline stages may make use of attributes of a link inperforming the computations that are required of them. In particular, most pipelinestage implementations use the point-to-point link attributes, ber and delay, whichare defined to represent the probability of a bit being received in error, and thepropagation delay for a signal on the link, respectively. In addition, the data rateattribute of a channel object is usually taken into account by one or more of thepipeline stages.

Bus Links

Bus links allow a single packet transmission to automatically propagate tomultiple destinations. These types of links are generally used to represent localarea networks, computer busses, or other broadcast-based networks. In addition,because packet broadcasting can be constrained to a subset of the nodes attached tothe bus, and even to a single destination, bus links can be used to representnetworks with a high degree of connectivity or with a dynamic connectivity thatwould otherwise be difficult to represent using point-to-point links.

As with point-to-point links, nodes attach to bus links via dedicated transmitterand receiver modules. In this case, bus transmitter and bus receiver modules mustbe used. Attachments are formed by using a third object, called a tap, to connect

stream i

stream j

stream k

channel i

channel j

channel k

Each channel maintains a separate queue

The packet at the head of each queue is the one currently undergoing transmission

Built-in Queuing of Transmitter Channels

407-Comec


om

mu

nicatio

n

Mech

anism

s

the node to the link. A tap has a transmitter attribute and a receiver attributethat must be used to designate the transceivers within the node.

Most taps have both the transmitter and receiver attributes set to a non-empty value, allowing packets to travel both to and from the bus into the node.However, it is possible to leave either of these attributes empty (the value NONE canactually be assigned) in order to create a unidirectional tap. If only the receivername is assigned, the tap is referred to as receive-only; if only the transmitter nameis assigned, the tap is called transmit-only. Receive-only taps are sometimes usedto monitor the status of the bus link to learn about the activities of other nodes, orto collect results. Transmit-only taps can be used, for example, by a controller nodethat periodically emits a synchronization signal and has no need to receiveinformation from other nodes.

Depending on whether taps are configured as receive-only, transmit-only, orbidirectional, they are drawn differently in the Network Editor where they aredefined. The following diagrams depict the four possible representations (it ispossible, though not useful, to have a tap with no transmit or receive capability).

A transmitted packet can propagate simultaneously in both directions on a buslink. The physical distances between nodes may be factored into the computationof arrival times at the various receivers. This calculation is generally also based onthe delay attribute of the bus link, which represents the time in seconds requiredfor the signal to propagate a distance of one meter. Thus, a single packettransmission can result in time-staggered arrivals at the various bus receivers.

In the same way that point-to-point links consist of a bundle of separatechannels, bus links can also act as many independent broadcast mediums. Thenumber of channels in a bus link is determined by the channel count attributes ofthe attached bus transmitter and bus receiver modules. When a packet istransmitted on the n-th channel of a bus transmitter, it is received by all busreceivers attached to the bus that have a sufficient channel count (i.e., channelcount > n, since channel indices begin at zero). Receivers that have an insufficientnumber of channels are not affected by the transmission. Those receivers that areaffected and that receive the packet correctly issue the packet to a neighboringmodule via their n-th output stream.

Unused Transmit-Only Receive-Only Duplex

Bus Tap Configurations

408-Comec


With respect to transmission of packets, bus link channels behave identically topoint-to-point link channels. In other words, each channel incorporates anunlimited-capacity queue that can accept packets at any rate, and packets are thentransmitted one at a time onto the bus link. When a packet is transmitted, each ofthe eligible receivers is sent a distinct copy of the packet. This allows each receiverto make an independent determination with regard to the correct reception of thepacket. In addition, if the packets are received correctly by multiple receivers, thenthe distinct copies can be operated upon (e.g., modified, destroyed, resent) withoutaffecting each other. The following diagram illustrates the packet replicationassociated with broadcasting on a bus link.

Bus links support the notion of a collision which corresponds to thesimultaneous presence of two or more arriving packets at the same bus receiverand on the same channel. Since, in general, packets take a nonzero amount of timeto transmit and to receive (i.e., time measured from the transmission of the first bitto the transmission of the last bit), a packet can be considered to be “arriving” at areceiver during a finite interval. If another packet begins arriving before thecompletion of another packet’s reception interval, the two packets are consideredto have collided. The bus receiver channel remains in a collided state until one ofthe packets completes its reception interval, leaving only one other packet present.

Since packet collisions take place at the receiver, propagation delays andrelative positions of nodes on the bus link can play a role in determining whetherthey occur. This effect is automatically taken into account by the bus link model,since the arrival of each packet is scheduled based on these parameters andcollisions are only determined when packets arrive, not when they are sent.

In general, collisions are considered as destructive events that prevent thecorrect reception of either packet involved. This is the default behavior provided

copy 0

copy 1

copy 2

copy 3

copy 4

originaltransmittedpacket

A packet will also be sent to the same node that transmitted the original packet, if the bus tap is duplex

Replication of Transmitted Packet on a Bus Link

409-Comec


om

mu

nicatio

n

Mech

anism

s

for the bus link. However, like point-to-point links, the behavior of bus links can becustomized by modifying the underlying models or pipeline stages. These can beconfigured to interpret collisions differently; for example, a collision may beconsidered to not have a destructive effect if its total duration is less than a definedthreshold. The general theory and use of bus link pipeline stages are discussed in alater section of this chapter.

Consistency of Physical Links

Not all links that are placed between nodes are necessarily valid. OPNETconsiders only certain links to be properly configured and usable for the transfer ofpackets. A valid point-to-point or bus link is said to be consistent; an invalid point-to-point or bus link is called inconsistent. Inconsistent links do not support packetflow during simulation. In order to determine consistency of each link, OPNETuses pre-defined criteria that are applied to the link object, and the transceiverobjects that are assigned to the link, on each end if applicable. Consistency relatesto compatibility of the components that form the connection: these includetransmission data rate, supported protocols, and numbers of supported channels.For an in-depth explanation of how link consistency is evaluated, refer to theNetwork Domain chapter of Modeling Concepts.

Radio Links

Point-to-point and bus links, presented in the previous sections of this chapter,are provided with all versions of the OPNET Modeler product. An additional typeof link, called radio link, is incorporated into the OPNET Modeler/Radio product,in order to provide direct support for a wider set of networking problems,including static and mobile radio, and satellite applications.

At the network level, radio links do not exist as objects as do their bus andpoint-to-point counterparts. This corresponds to the actual behavior of radio linkswhere communication may be established between some or all of the parties in asystem on a dynamic basis. The ability to dynamically “create” a link between atransmitter and a receiver may be dependent on many physical characteristics ofthe components involved, as well as time-varying parameters. In OPNETsimulations, parameters such as frequency band, modulation type, transmitterpower, distance, and antenna directionality are commonly factored into thedetermination of whether a link exists or not at a particular time.

410-Comec


From the perspective of the modules within a node, radio links are used in thesame manner as point-to-point and bus links. In other words, if a module wishes tosend a packet via a radio link, it must send the packet to one of the input streams ofa radio transmitter. The radio transmitter is then responsible for sending the packetto radio receivers in remote nodes. These radio receivers in turn issue correctlyreceived packets on appropriate output streams.

Like a bus or point-to-point transmitter, a radio transmitter maintains a channelobject for each of its input streams and each channel contains a queue wheresubmitted packets wait for previous packets to complete transmission. However,whereas bus and point-to-point transmitter channels have primarily a logicalsignificance, radio transmitter channels also have a physical significance that isdescribed by an additional set of attributes. These additional attributes serve tocharacterize the radio channel in terms of the frequency band that it occupies, thepower that is applied to transmissions, the data rate of transmission, and anoptional code used to identify a spread spectrum sequence.

Radio channels are referred to by integer indices in order to establish acorrespondence with the input and output streams that they use. In other words,packets should be sent to input stream i in order to use channel i; similarly, packetscorrectly received by a radio receiver on channel i are sent to a neighboring moduleusing output stream i. However, the index-based correspondence does notnecessarily hold across radio links. That is, a packet transmitted using channel imay be received on a channel with index other than i. This is due to the fact thatradio links are established between channels based on their attributes as opposed totheir logical index. The actual establishment of a link is decided upon by user-definable radio link models and may be dependent upon a number of transmitterand receiver attributes as well as other factors. For example, a simple link model

Distance is one possible factor preventing the establishment of links, as in the case of these two nodes and the air base; as the nodes move, this situation may change.

Dynamic Establishment of Radio Links between Mobile Nodes

411-Comec


om

mu

nicatio

n

Mech

anism

s

may require only that the frequency bands of a transmitter channel and receiverchannel overlap in order to establish a link; a link would exist regardless ofwhether the channels had the same index.

Like bus transmitters, radio transmitters transmit packets by broadcastingthem. Therefore, packets are replicated for each selected destination in order toallow them to be evaluated and modified independently. Note that, unlike bus links,replication is on a per-channel basis at the destination since a single packet mayaffect multiple channels within a radio receiver. Again, this is due to the fact thatchannels are compared on the basis of their physical characteristics, rather thantheir logical index values.

The eligible receivers of each radio transmitter are not necessarily known inadvance, as in the usual case of a bus configuration. Instead, the existence andquality of each link is generally computed on a dynamic basis to reflect potentiallychanging conditions in the network. Important events, such as position changesand interference, may have a significant impact on the ability of a transmitterchannel and a receiver channel to communicate, and these events may occur at anytime. The detailed behavior and mechanics of radio transmissions are specified in aseries of low-level radio models, referred to as pipeline stages. The theory andoperation of radio pipeline stages are discussed in detail in a later section of thischapter.

Comec.2.2.4 Link Model Definition

As discussed earlier in this chapter, OPNET provides several types of links,each supporting a fundamentally different form of communications between twoor more nodes. For those links that are represented as objects (i.e., point-to-point,bus, and bus tap), OPNET uses the notion of a model to better handle largenumbers of objects. Link models are specified using the Link Editor. For moreinformation on the Link Editor, refer to the Link Editor chapter in EditorReference.

channel 0

channel 2

channel 1

channel 0

channel 2

channel 1

stream 0

stream 2

stream 1

stream 0

stream 2

stream 1

A link established by radio does not necessarily relate channels of equal index.

Radio Link Channel Correspondence

412-Comec


As explained in the Modeling Framework chapter of Modeling Concepts., amodel is a class definition which can be used to create instances that conform toparticular specifications. In this case a link object is an instance of a link model.This is the same relationship that exists between nodes and node models. However,unlike a node, a link is not composed of underlying objects. All of thespecifications for a link’s behavior are contained within a set of attributes.Attributes can specify characteristics such as the link’s propagation delay, errorrate, and the transceivers that it attaches to, if any. In addition, attributes are used toselect a series of underlying C language procedures, called pipeline stages, whichimplement most of the computations and decisions made by a link. While thepipeline architecture is fixed for each type of link, user-defined pipeline proceduresmay be inserted into it in order to achieve customized link behavior (refer to latersections of this chapter for a detailed discussion of how the transceiver pipelineworks). In other words, a link object’s specification is controlled entirely viaattributes, and therefore, a link model consists primarily of defining how theseattributes should be configured. This is done via a specification mechanism calledattribute interfaces, similar to the specification included in a node model. Attributeinterfaces are briefly discussed in a link-specific manner in the following section.

Comec.2.2.4.1Link Attribute Interfaces and Derived Link Models

In this section we will briefly discuss how link model developers can use amechanism called model attribute interfaces to exercise control over built-in linkattributes, as well as to specify a variety of aspects of a link model’s interfacepresented to the model user. The concepts that are discussed in this section arediscussed in a more general and complete fashion in the Modeling Frameworkchapter of Modeling Concepts.

The role of link attribute interfaces is to specify how a link model appears fromthe point of view of a user who is working with the model in the Network Domain.The attribute interfaces contain several components, the most important of whichis called attribute interface descriptions. These are discussed in the following sub-section; a second sub-section provides a brief explanation of the other components.

Link Attribute Interface Descriptions

As mentioned above, link models contain no objects. There are therefore noobject-promoted attributes that can be passed to the link objects in the ProjectDomain. The role of attribute interface descriptions is therefore simpler for linksthan for nodes. In the case of links, the interfaces descriptions apply only to thebuilt-in attributes of link objects. In other words, attributes such as the delay ordata rate of a link can be controlled via this mechanism. Pipeline stageattributes, such as the txdel model (transmission delay model) can also beaffected. Using the attribute interface descriptions component of the attributeinterfaces, the link model developer can apply the following types of changes tothe attributes that the link model offers:

413-Comec


om

mu

nicatio

n

Mech

anism

s

Control Provided by Link Attribute Interface Descriptions

Mechanisma

a. For an in-depth discussion of the mechanisms discussed in this table (except attributespecification), refer to the Modeling Framework chapter of Modeling Concepts.

Description

Attribute Renaming Provide a new name for an attribute as it is appearsfrom the link model user’s point of view. This is thename of the attribute as it is seen on a link object in theNetwork Domain.

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.

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 link object without a value. Set attributes appearon the link object with a value chosen in advance by thelink model developer; they can be changed on a per-link basis, however. Hidden attributes have a specifiedvalue, but are not visible on the link object, and there-fore cannot be changed.

Attribute Specification OPNET allows you to change the default behaviorwhen a user changes a link’s attribute settings. You canspecify a custom ETS library and event handlers byclicking the ETS Handlers button. See “Active At-tributes” in the Application Development Conceptschapter of the External Programming Interfaces manu-al for details.

414-Comec


Additional Link Model Interfaces

The Link Model Attribute Interfaces also regroup several other parts of a link’sinterface, though these are unrelated to attributes. These are summarized in thefollowing table. For a detailed discussion, refer to the Modeling Frameworkchapter of Modeling Concepts.

Additional Link Model Interfaces

Interface Description

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

Attribute Interface Descriptions for a Link Model

Attributes have been renamed and set to reasonable initial values.

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

415-Comec


om

mu

nicatio

n

Mech

anism

s

Link Model Derivation

In certain cases, link model developers, or even model users, will find that anexisting link 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.

In these problem situations, users are seeking what we can refer to as aspecialization of the link model. A specialized version of the link model is lessgeneral and flexible, but is tailored to the needs of a particular application, or at

Comments A textual description of the link model allowing the linkmodel developer to provide any desired information tothe model user. Typically information in the commentsincludes: link model functionality (i.e., what sort of real-world link it represents); factors affecting link consisten-cy; significance of major attributes, etc.

Supported Link Type Specifies whether the model is capable of being usedfor simplex point-to-point, duplex point-to-point, bus,bus tap, or any combination of these.

Reasons to Specialize a Link 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 the linkmodel will be significantly easier to deploy at the net-work level.

Flexibility can permitinvalid configurations

The availability of many attributes may provide the op-portunity for the user to create a link configured in aninvalid manner.

End-user expectsparticular presenta-tion

The end-user of the link model typically expects a par-ticular interface that matches his experience with simi-lar real-world links or other models. If this interface canbe realized, the model will be much more “user-friend-ly”.

Additional Link Model Interfaces (Cont.)

Interface Description

416-Comec

Communicating with Interface Control Information Modeling Concepts

least a more specific application than the original model. In order to create aspecialization of a link model, OPNET provides a mechanism called ModelDerivation. Model Derivation allows the mechanisms that are available in the LinkModel Attribute Interfaces to be applied to an existing link model. The result ofthis operation is a new, more limited link model, called a derived model thatdepends on the original model, which is called the parent model. Refer to theModeling Framework chapter of Modeling Concepts for more information onmodel derivation.

Comec.3 Communicating with Interface Control Information

Interface Control Information structures or ICIs are data objects that resemblepackets in that they consist of a list of data items. However, ICIs are simpler datastructures than packets since they contain storage only for user-defined values. Inaddition, there is no notion of size or ownership for an ICI as there is for a packet.In fact it is common for ICIs to be concurrently shared and modified/examined bymultiple entities.

Comec.3.1 Applications of ICIs

In the broadest definition, an ICI is a list of user-defined data items that can beassociated with an event. This capability allows information to be transferred fromthe context where an event is generated to the context where it later occurs. Thetwo contexts may be distinct modules within the same node or in separate nodes,or the two contexts may be the same module executing two separate events atdifferent times. Thus, an ICI can be viewed as playing a role in a communicationmechanism between contexts, where an event provides the active notification, andthe ICI provides the data “payload” that is transferred.

For certain types of events that normally carry little or no user-definedinformation, ICIs provide an important enhancement in data transfer capability.These event types include:

• self: the only information inherently associated with this type of eventis an integer code specified at the time that the KPop_intrpt_schedule_self() is called. However, since the event occurs atthe same process that generates it, it is possible to store information instate variables for later retrieval.

• remote, process, and multicast: like the self interrupt, only an integercode is provided. In addition, state variables cannot be used since thedestination process is different than the source process.

• access: no accompanying information is directly provided with thistype of event.

• statistic: a single floating point value may be conveyed with this typeof interrupt.

417-Comec

Modeling Concepts Communicating with Interface Control InformationC

om

mu

nicatio

n

Mech

anism

s

Because the ICI mechanism is not specific to any particular event type, it canbe used in cases involving any of the above event types to transfer general amountsof user-defined data between contexts.

ICIs are also commonly used with stream events, even though such eventsinherently convey packets which can contain general, user-defined information.The purpose generally served by an ICI in such cases is to associate additionalparameters with a packet transfer while avoiding the use of the packet itself tocontain these parameter values. A common reason for avoiding the use of thepacket to carry such parameters is that the packet’s format would then depart froman actual specification. This situation typically arises when a packet-basedinterface models a service that operates on packets in a manner that is affected byassociated parameters; for instance, a packet may be submitted by a higher layerprotocol to the next service layer which may require the designation of serviceclass and destination.

Comec.3.2 ICI Content

When an ICI is created using the KP op_ici_create(), the name of an ICI formatmust be supplied. An ICI format defines the structure of an ICI in terms of theattributes that it contains. Each attribute definition has three components: a name, adatatype, and a default value, as shown in the following ICI editor screen:

Attribute names are used to make references to attributes within an ICI. Inother words, the name of an attribute plays the same role as the name of a field in a

ICI Format Specification

418-Comec


formatted packet. Operations that expect attribute names to be specified includesetting, getting, and testing for the existence of attributes.

An attribute’s datatype determines what sort of information it can store. Thesupported types are integer, double, and structure. Integer and doubledatatypes store whole numbers and floating-point decimal numbers, respectively.Structure attributes contain memory addresses to support the communication ofarbitrary user-defined data with ICIs. In general, these types of attributes areassigned memory addresses returned by the dynamic memory allocation KPop_prg_mem_alloc(), as shown in the example below. Note that, unlike structureaddresses embedded in packet fields, structure addresses in ICI attributes are notautomatically subjected to deallocation when their encompassing ICI is destroyed.Instead, deallocation, if appropriate, must be performed by user processes.

When an ICI is initially created, integer and double attributes contain defaultvalues as specified in the ICIs format definition. Structure fields cannot beassigned default values since memory addresses cannot be known in advance. ICIattribute values can then be assigned by calling the KP op_ici_attr_set() which isapplicable for all three types of attributes. Values for the three attribute types canalso be obtained using the KP op_ici_attr_get().

Comec.3.3 ICI Mechanics

In order to associate an ICI with an event, the Simulation Kernel relies on amechanism called ICI installation. Each process (a processor or queue modulemay contain multiple processes) has at most one installed ICI at any given time.Initially, a process is considered to have no ICI installed; subsequently the processmay install other ICIs by calling the KP op_ici_install() and passing the address ofthe ICI of interest. An ICI remains installed until another takes its place.

The Simulation Kernel automatically associates a process’ installed ICI withthe events that the process generates. Since an ICI can remain installed after it hasbeen associated with an event, it can also become associated with subsequent

/* Allocate a structure of type “Command” to pass within an ICI */command_ptr = (Command*) op_prg_mem_alloc (sizeof (Command));

/* Setup the command structure. */command_ptr->type = COMMAND_TYPE_A;command_ptr->priority = COMMAND_PRIORITY_LOW;command_ptr->request = SET_COMPRESSED_MODE;

/* Install the structure in “command” attribute of a new ICI. */ici_ptr = op_ici_create (“link_control”);op_ici_attr_set (ici_ptr, “command”, command_ptr);

Assignment of a Structure-Type ICI Attribute

419-Comec


om

mu

nicatio

n

Mech

anism

s

events. In fact, the same installed ICI address will be associated with every eventscheduled by a process, until it is replaced by another ICI. One way to avoidhaving unintended associations between ICIs and events is to restore the initialcondition (i.e., no ICI is installed) after each event-scheduling action; this can bedone by calling the KP op_ici_install() with the symbolic constant OPC_NIL.However, in general this is not necessary, because the mere association of an ICIwith an event that does not make use of it is of no consequence. In other words, ifthe destination context of an event does not make use of an ICI, no adverse effectcan result from the ICI simply being available.

Operations on ICIs

ICIs are dynamic objects that must be created by processes that wish toassociate information with events that they schedule. The KP op_ici_create()returns an ICI address (i.e., memory pointer) that can be stored in a process’ state,temporary, or other variables. All subsequent operations on ICIs must then refer tothe ICIs by address, rather than directly as data-structures.

A dedicated package of KPs supports operations on ICIs such as creation,setting and getting of attributes, destruction, installation, etc. The capabilitiesprovided by this package are summarized in the table below. In addition, a KPfrom the Intrpt package is used to obtain an ICI in an event’s destination context.Detailed explanations of each KP are provided in the Simulation Kernel manuals.

ICI-Related Kernel Procedures

Kernel Procedure Provided Capability

op_ici_attr_exists() determines if an attribute, specified by name, is defined within an ICI’s format

op_ici_attr_get() obtains the value of an ICI attribute, specified by name

op_ici_attr_set() assigns the value of an ICI attribute, specified by name

op_ici_create() creates a new ICI with a specified format; the ICI’s address is returned

op_ici_destroy() releases memory taken by an ICI

op_ici_format() obtains the name of an ICI’s format

op_ici_install() installs an ICI as “current” for a process such that the ICI becomes associated with events scheduled by the pro-cess

op_ici_print() prints the contents of an ICI to standard output

op_intrpt_ici() obtains the address of the ICI associated with the cur-rently executing event

op_pk_ici_get() obtains the pointer to the ICI that has been previously associated with the packet via the KP op_pk_ici_set().

420-Comec


Standard ICI Lifecycles

The principal events in an ICI’s existence are creation, destruction, andinstallation. These determine the times at which an ICI enters and exits circulation,and when it becomes eligible for association with an event. In addition,intermediate operations such as modification and extraction of attributes aretypically executed. Because there are no strict ownership controls on ICIs, as thereare on packets, any process that has access to an ICI’s address can perform theseoperations. For example, an ICI may be destroyed by the process that created it, orby one of the processes that have received it. Similarly, multiple processes canconcurrently have access to the same ICI and cause modifications that will bevisible to each other.

While the Simulation Kernel imposes no strict discipline on the usage of ICIs,certain standard patterns of creation, installation, and destruction arerecommended to avoid complicated interactions between processes that share ICIs.Each of these ICI lifecycles is applicable to different types of modeling situations.

• Instantiation on a per-use basis. This technique imposes the most rig-orous control on access to ICIs, since it treats them as though they werepackets, disallowing shared access by multiple processes. The commu-nication of information in association with an event is supported by thefollowing sequence of operations:

1) The source process creates an ICI by calling the KPop_ici_create().

2) The source process stores information in the ICI’s attributes bycalling op_ici_attr_set() for each relevant attribute.

3) The source process installs the ICI by calling op_ici_install().

4) The source process takes an action that generates an event (e.g,a packet is sent, or a self interrupt is scheduled).

5) When the event occurs and results in an interrupt, the interrupt-ed process obtains the ICI by calling op_intrpt_ici().

6) The interrupted process extracts information that it needs fromthe ICI by calling op_ici_attr_get().

op_pk_ici_set() creates an association between a packet and an ICI by storing the specified ICI pointer in the packet.

ICI-Related Kernel Procedures (Cont.)


421-Comec


om

mu

nicatio

n

Mech

anism

s

7) The interrupted process destroys the ICI by callingop_ici_destroy().

Note that when per-use instantiation is employed, the source process nolonger manipulates the ICI after having generated the event. The re-sponsibility for destroying the ICI and releasing memory associatedwith the ICI’s attributes therefore belongs to the destination process.

• Permanent ICIs. In certain situations, per-use instantiation results in analternating sequence of creation and destructions of ICIs of the sametype. A straightforward optimization therefore consists of creating theICI only once, and never destroying it; the source process need only up-date the ICI’s attribute values and install it before generating an event(the installation is still required, in case the process also makes use ofother ICIs). The sequence of operations for the source and destinationprocesses is as follows:

1) The source process creates an ICI at initialization (or perhapssome later time, but this should occur only once) by callingop_ici_create().

2) When the source process is about to take an action that will gen-erate an event and the ICI is to be associated with that event, itassigns appropriate values to the ICI’s attributes by callingop_ici_attr_set().

3) The source process installs the ICI by calling op_ici_install().

4) The source process takes an action that generates an event (e.g,a packet is sent, or a self interrupt is scheduled).

5) When the event occurs and results in an interrupt, the interrupt-ed process obtains the ICI by calling op_intrpt_ici().

6) The interrupted process extracts information that it needs fromthe ICI by calling op_ici_attr_get().

Note that under this scheme, the ICI is never destroyed. However, thisdoes not result in memory being wasted since the same ICI is continu-ally recycled.

Comec.3.4 Communicating with Statistics

Because packets can store general user-specified information, they can alwaysbe used to support the communication of data between processes. However, forcertain types of applications that communicate small amounts of information andwhich do not require the structure provided by a packet format, a packet interfacemay be overly complex.

422-Comec


One such application is the communication of a single numerical valuebetween modules. To accomplish this using packets as the communication vehicle,several steps are required each time a new value is transferred:

1) A packet is created.

2) The new value is placed in a packet field.

3) The packet is sent to the destination using a stream or packet delivery.

4) The packet is obtained by the destination module.

5) The field’s value is extracted by the destination module.

Because transfer of individual numerical values is commonly performedbetween modules, OPNET provides a simpler interface specifically for thispurpose. The interface is supported by a node domain object called a statistic wire,and the communicated values are referred to as statistics.

Comec.3.4.1 Statistic Wire Configuration

A statistic wire is a physical connection that attaches a source port of onemodule to a destination port of another module in the same node. Source ports forstatistic wires are referred to as output statistics, and destination ports are referredto as input statistics. The source module of a statistic wire can be any module thatgenerates statistics (currently, the only type of module that does not generate anystatistic is the antenna module provided with Radio versions). However, onlyprocessors and queue modules may act as the destinations of statistic wires sincethese are the only modules that can contain processes that would receive a statisticvalue.

Graphically, statistic wires are represented in a manner similar to packetstreams, but are distinguished by a dashed connection path (as opposed to the solidlines used to depict packet streams). Statistic wire input ports are referred to byinteger indices and can range from 0 to 99.

423-Comec


om

mu

nicatio

n

Mech

anism

s

Input statistics are capable of accepting multiple statistic wires in order toprovide the local module with a sequence of values that results from merging theindividual sequences of values sent via multiple output statistics, possibly fromdifferent modules.

Statistic wires may be used to transfer any of the values that constitute thepredefined output statistics known to the Simulation Kernel. These are the samevalues that can be collected in a simulation’s output vector file via statistic probes.For all modules except processors, output statistics can be predefined valuescomputed automatically by the Simulation Kernel, a new value being transferredwhenever a change occurs. For example, a queue module generates statistics suchas the number of packets it contains or the average amount of time a packetremains in the queue; and a receiver module generates statistics such as throughputand utilization for each of its channels. For a complete definition of availablepredefined statistics for each type of module, refer to the Node Domain chapter ofModeling Concepts.

Since the significance and behavior of queue and process modules can bespecified in a fully general manner by assigning user-defined process models,generic output statistics are provided for custom applications. For each queue orprocessor module, you can declare any number of output statistics. These outputstatistics can act as the source of a statistic wire in order to convey new values totheir destination at the request of processes within the source module. Processescan initiate the transfer of a new statistic value on a particular statistic wire bycalling the KP op_stat_write() and specifying the index of the output statistic towhich the statistic wire is attached. Any floating point number can be sent to astatistic wire destination in this manner.

Apart from the manner in which new values are generated, statistic wiresoperate identically, regardless of whether they are fed by predefined or genericstatistics. When a new value is generated at a statistic wire source, two possiblebehaviors may result, depending upon the value assigned to the intrpt methodattribute of the statistic wire. If the interrupt method is forced, then no delay is

input results

Statistic Wire Connections with Fan-Out and Fan-In

output resultsfan-out

fan-in

424-Comec


possible for the statistic transfer, and an immediate change occurs at thedestination module’s input statistic. However, if the interrupt method isscheduled, which is the default, then an arrival time at the destination module’sinput statistic is calculated based on the delay attribute of the statistic wire.

When a new statistic value arrives at the destination module, it is stored in theinput statistic, replacing the value that was there previously. The value maysubsequently be obtained at any time (until the next replacement) by any process inthe destination module using the KP op_stat_local_read(). The integer index of theinput statistic must be specified when calling this KP. Note that the previous valuecan no longer be obtained, since it has been overwritten.

In addition to making a new statistic value available to the destination moduleeach time that an update occurs, a statistic wire can provide active notification ofchanges. Notification takes the form of a statistic event that is generated for thedestination module if appropriate conditions are met. The statistic event may thenresult in an interrupt for one of the module’s processes if appropriate interrupts areenabled. For more information on restricting interrupts, refer to the ModelingFramework chapter of Modeling Concepts.

A statistic wire can be configured in such a way as to generate events onlywhen particular types of changes occur in the input statistic value at its destination.A set of criteria, called triggers, are used to determine when an event should begenerated. Triggers are specified as attributes of a statistic wire object thatcharacterize six types of changes in value. For an event to occur as a result of astatistic value change, the logical OR of the conditions represented by the statisticwire’s enabled triggers must be true; in other words, at least one of the triggerconditions detailed below must be satisfied, and the corresponding trigger attributemust not be set to the disabled value.

• rising edge trigger. The newly received value is strictly greater thanthe previously received value.

• falling edge trigger. The newly received value is strictly less thanthe previously received value.

• repeated value trigger. The newly received value and the previous-ly received value are identical.

• zero crossing trigger. The newly received value has the oppositesign of the previously received value, or the newly received value is ex-actly zero.

• low threshold trigger. The newly received value is less than orequal to a user specified low threshold value.

• high threshold trigger. The newly received value is greater than orequal to a user specified high threshold value.

425-Comec


om

mu

nicatio

n

Mech

anism

s

The default configuration for statistic wire triggers is to enable the rising edgeand falling edge triggers and to disable all others. This implies that a statistic eventwill be generated whenever any change occurs in the input statistic’s value;however no event will be generated if a statistic update is received that is the sameas the previous value. Another common configuration enables the repeated valuetrigger in addition to the falling and rising edge triggers in order to allow anyreceived statistic value to generate an active notification. Finally, a third commonconfiguration disables all triggers in order to implement a passive statistic transfer;in other words, the destination module can observe statistic values generated at thestatistic wire source, but no interrupts are ever received as a result.

Comec.3.4.2 Statistic Wire Applications

Because statistic wires are capable of transferring arbitrary values undercontrol of user-defined processes, they may be used for a wide range ofapplications requiring communication between modules in the same node. Twocommon ways of using statistic wires are described in this section:

Using Statistic Wires for Dynamic Monitoring

One of the most common applications of statistic wires is to provide user-defined processes with the ability to sense the state of other modules within thesame node. This can be a useful tool for developing adaptive models in whichdecisions to take particular actions are dependent upon dynamic operatingconditions of the surrounding node.

Statistic wires are particularly well-suited to the application of dynamicallymonitoring other modules due to their ability to provide active notification ofchanges. This improves efficiency relative to a polling strategy, whereby amonitoring process periodically examines an external condition to determinewhether to perform an action. In addition, accuracy is improved, since the processcan be notified immediately when a condition has changed. Finally, by configuringa statistic wire’s triggers, a monitoring process can be alerted to external changesonly when appropriate.

For modules other than processors or queues, statistic wires provide the onlymeans of monitoring activity during the simulation in order to feed past andpresent metrics back into the determination of future behavior. For example, byusing triggers, “alarms” can be generated for predefined module statistics whenthey reach particular thresholds. This is commonly done for statistics such as thenumber of packets held in a queue, the throughput of a receiver channel, or thesignal to noise ration of a radio receiver.

Using Statistic Wires as Semaphores

Due to the simplicity of the statistic interface from the perspective of processesthat use them, statistic wires are commonly used to implement low-level signallingmechanisms between processes in different modules. The term semaphore is used

426-Comec

Communication Link Models Modeling Concepts

to refer to a variable that is controlled by a source process and observed by adestination process. The destination process makes use of the variable value tocontrol its timing and decision making.

One common type of semaphore is a simple bivalued statistic (e.g., alternatingbetween zero and one) that act as a “lock”, allowing one process to prevent orallow the execution of certain actions by another process. By using the triggers ofthe statistic wire, semaphores can become active, allowing the destination processto block until a specific “release” signal has been generated by the source process.

Comec.4 Communication Link Models

In an earlier section of this chapter the basic operation of three types ofcommunication links was described. Each type of link provides a fundamentallydifferent type of connectivity: point-to-point links connect a single source node toa single destination node; bus links connect a fixed set of nodes to each other; andradio links potentially allow all nodes in a model to communicate with each other,based on a dynamic evaluation. While the general type of connectivity provided bythese links is predefined by OPNET, an open architecture is provided to allowdevelopers 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 conduit connecting a transmitter to one or more receivers.

Comec.4.1 Transceiver Pipeline Mechanics

The transceiver pipeline has a similar structure for each of the three supportedlink types. In each case, the Simulation Kernel manages the transfer of packets byimplementing a series of computations, each of which models particular aspects oflink behavior. The sequence of the computations and their interface arestandardized for each type of link. However each computation, referred to as apipeline stage, is performed outside the Simulation Kernel by a user-suppliedprocedure, called a pipeline procedure. In this manner, OPNET provides an openand modular architecture for implementing link behavior.

A link’s underlying implementation can generally be thought of as asequentially executed set of pipeline stages. The pipeline stage sequence of a linkis executed once for each packet transmission that is submitted at the source of thelink. In other words, when a packet is sent to a transmitter, the Simulation Kernelproceeds to call appropriate pipeline stages to process the packet. Certain pipelinestages are executed when the packet is transmitted, and others are executed laterdue to the delay associated with the traversal of the link and transmission of thepacket.

The principal objective of a transceiver pipeline is to determine whether or nota packet can be received at the link’s destination. This determination is usuallymade in the final stages of the pipeline based on information computed duringearlier stages. The primary vehicle used to convey information between the stagesis the packet itself, which is provided as an argument to each pipeline procedure.The packet is also used by the pipeline stages to return information to the

427-Comec

Modeling Concepts Communication Link ModelsC

om

mu

nicatio

n

Mech

anism

s

Simulation Kernel. A link model may also contain local statistics, which can alsobe used to convey information about a particular link object across differentpipeline stages.

In order to carry both user-defined and standard pipeline information, packetscontain a special storage area consisting of an array of values called transmissiondata attributes. Transmission data attributes (TDAs) are either integer or floating-point numerical values that are assigned to a particular location within the packet.TDA locations are specified by integer index, and the meaning of each location isdependent upon the particular type of link and the conventions agreed-upon by thepipeline stages.

At the time that a packet enters a pipeline (i.e., when it begins transmission), acertain number of TDAs are automatically assigned by the Simulation Kernel inorder to provide information to the pipeline stages concerning the context of thetransmission. For example, the object ID of the link, of the transceivers, and of thechannel objects, as well as certain relevant attributes of these objects, are generallyalready present in predefined TDAs of the packet by the time the first stage isexecuted. The particular set of TDAs that is automatically provided depends uponthe type of link, and is documented for each link type in later sections of thischapter.

The predefined TDAs that are set up prior to a pipeline execution are reservedfor the exclusive use of the Simulation Kernel. In addition, the Kernel reservescertain standard TDAs for the pipeline stages to communicate certain informationto it as well as to each other. For each of these TDAs, the Kernel defines a specialsymbolic constant to represent the TDA’s integer index. Refer to the SymbolicConstants chapter of Simulation Kernel.

In each set of predefined TDAs, a certain number are provided in advance orcomputed by the Kernel as the pipeline execution proceeds. These TDAs have afixed meaning and always serve to communicate information from the Kernel tothe stages, but not the reverse. As a result, these TDAs may not be used by pipelinestages for alternate purposes (simulation errors will result if this is attempted).However, the TDA array is extensible and allows any positive integer index to bespecified when assigning or obtaining an attribute value. Thus, custom pipelinedesigns may make use of any higher-numbered TDAs (above the highestpredefined TDA) that are not reserved by the Kernel in order to communicateadditional information between stages. Special symbolic constants representingthe highest reserved TDA index are provided to support this application. Theseconstants appear in the table below. For a given pipeline, the lowest unreservedTDA index is obtained by adding one to the appropriate constant.

Maximum Reserved TDA Indices

Link Type Constant Representing Maximum Reserved Index

Point-to-Point OPC_TDA_PT_MAX_INDEX

Bus OPC_TDA_BU_MAX_INDEX

428-Comec


In addition to supporting communication of information between pipelinestages and the Kernel, and between pipeline stages and each other, TDAs can beused to pass information from the pipeline stages to processes in a link’sdestination node. The information accumulated in a packet during its traversal of atransceiver pipeline is not stripped when the pipeline’s execution completes. Infact, it remains within the packet until the packet is transmitted again. As a result,any process within the destination node of a link may obtain information generatedby pipeline stages that processed the packet as the packet was transferred. Thiscapability may be useful to support implementation of sophisticated decisionmaking within link destination nodes based on conditions in the arriving links. Forexample, a node receiving packets transmitted by radio may make use of pipeline-generated information about interference to adjust its antenna orientation or itsreception frequency.

Note that while processes within nodes can obtain information from TDAs inpackets, they are not capable of modifying existing TDAs or extending the TDAarray to incorporate new values. Thus, TDAs cannot be used to communicateinformation from processes to the pipeline stages (this policy is due to the fact thatinformation inserted into the TDAs would be overwritten anyway at the time ofactual transmission). It is possible however to use ordinary packet fields for thispurpose, since pipeline stages are capable of accessing these values.

Radio OPC_TDA_RA_MAX_INDEX

Maximum Reserved TDA Indices

Link Type Constant Representing Maximum Reserved Index

429-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.2 Pipeline Stage Definition

Pipeline stages are implemented as C or C++ language procedures withpredefined argument and return-value interfaces. Almost all pipeline stages accepta packet address (Packet* datatype) as their sole argument. As mentioned earlier,the TDA fields of the packet that is passed in are used as a vehicle for conveyinginformation back to the Simulation Kernel as well as to subsequent pipeline stages.

Each pipeline stage has a user-provided name, usually selected to berepresentative of its features. For example, a pipeline stage responsible forcalculating the signal-to-noise ratio affecting radio transmissions may be calledradio_snr. The selected name must be used to name the pipeline stage procedureas well as the source code file that contains it. Pipeline stage object code files canonly be recognized by OPNET if they carry the suffix “.ps.o”; therefore pipelinestage source code files usually have the suffix “.ps.c” for C files and “.ps.cpp”for C++ files. Thus, the signal-to-noise ratio pipeline stage may be implemented bya C procedure defined as radio_snr() within a file called radio_snr.ps.c, whichwhen compiled generates the object code file radio_snr.ps.o. Custom pipelinestages may also be created by the user as C or C++ files and then compiled to“.ps.o” files with the op_mko utility. For further information on the op_mko utility,refer to the Program Descriptions chapter of External Interfaces.

TD0 TD1 TD2

Prior to reaching the transmitter, a packet’s TDAs are empty if this is its first transmission; otherwise they contain the values from the previous link traversal.

After passing the transmitter, the packet enters the pipeline with old TDA values erased. New information is inserted to re-flect the current link’s configuration.

If the packet completes the pipeline and is ac-cepted, the TDA values accumulated during the pipeline remain in the packet.

Transformation Phases for a Packet’s Transmission Data Attributes

430-Comec


The Simulation Kernel contains a package of procedures to support theassignment to and extraction from transmission data attributes. This package iscalled the Transmission Data package (Td) and the procedures that it includes aresummarized below. For detailed explanations of their capabilities and usages, referto the Transmission Data Package chapter of Simulation Kernel.

The top-level pipeline procedure may also make use of most OPNET KernelProcedures (KPs), user-defined or third-party procedures in other files, and thegeneral capabilities of the C language to implement the functionality required ofthem. Frequently, pipeline stages perform mathematical calculations that rely onthe availability of the C/C++ math library, and therefore include the definitions file

Transmission Data Package Kernel Procedures


op_td_set_dbl() assign a double-precision floating-point value to a speci-fied TDA of a packet, replacing the previous value (if any)

op_td_set_int() assign an integer value to a specified TDA of a packet, replacing the previous value (if any)

op_td_get_dbl() obtain a double-precision floating point value stored in a specified TDA of a packet

op_td_get_int() obtain an integer value stored in a specified TDA of a packet

op_td_is_set() determine if a specified TDA of a packet currently contains an assigned value

431-Comec


om

mu

nicatio

n

Mech

anism

s

math.h in their source code file. A C source code example for a simple pipelinestage procedure appears below:

In the case of a C++ pipeline stage file, the top-level pipeline procedure mustbe linked using the C linkage convention so that the Simulation Kernel cancorrectly access it. This is indicated by wrapping the prototype of the procedure inan ‘extern “C”’ linkage expression, such as:

OPNET provides default pipeline procedures to support each of the three typesof links. These pipeline stages appear as the default assignments when newtransceiver or link objects are created. The names of these stages are given below.Complete explanations of each default stage’s behavior and implementation are

Example of a C Pipeline Stage Procedure

/* transmission_delay.ps.c */

#include <opnet.h>#include <math.h>

voidtransmission_delay (Packet * pk)

{/* Obtain the transmission data rate (supplied by the Kernel

*//* in the packet’s TDAs). */tx_data_rate = op_td_get_dbl (pk, OPC_TDA_RA_TX_DRATE);

/* Obtain the packet’s length (in bits). */pk_length = op_pk_total_size_get (pk);

/* Compute the transmission delay. */tx_delay = pk_length / tx_data_rate;

/* Place result in packet to return to Kernel. */op_td_set_dbl (pk, OPC_TDA_RA_TX_DELAY, tx_delay);

/* transmission_delay.ps.cpp */

#include <opnet.h>#include <math.h>

extern “C”{void closure_template (Packet *);

}

void closure_template (Packet * pk){

/* pipeline stage code */}

Example of a C++ Pipeline Stage Procedure

432-Comec


provided in General Models. These default stages may also serve as good startingpoints for developers wishing to create application-specific pipeline stages.

Default Point-to-Point Transceiver Pipeline

Pipeline Stage Attribute Name Default Stage Name

Transmission Delay txdel model dpt_txdel

Propagation Delay propdel model dpt_propdel

Error Allocation error model dpt_error

Error Correction ecc model dpt_ecc

Default Bus Transceiver Pipeline


Transmission Delay txdel model dbu_txdel

Link Closure closure model dbu_closure

Propagation Delay propdel model dbu_propdel

Collision coll model dbu_coll

Error Allocation error model dbu_error

Error Correction ecc model dbu_ecc

Default Radio Transceiver Pipeline


Receiver Group rxgroup model dra_rxgroup

Transmission Delay txdel model dra_txdel

Link Closure closure model dra_closure

Channel Match chanmatch model dra_chanmatch

Transmitter Antenna Gain tagain model dra_tagain

Propagation Delay propdel model dra_propdel

Receiver Antenna Gain ragain model dra_ragain

Received Power power model dra_power

Background Noise bkgnoise model dra_bkgnoise

Interference Noise inoise model dra_inoise

Signal-to-Noise Ratio snr model dra_snr

Bit-Error-Rate ber model dra_ber

Error Allocation error model dra_error

433-Comec


om

mu

nicatio

n

Mech

anism

sComec.4.3 The Point-to-Point Transceiver Pipeline

Point-to-point links are based on a simple four-stage pipeline that supports thetransfer of packets from a point-to-point transmitter to a point-to-point receiver.The structure of the bus transceiver pipeline is depicted in the following diagram.

Error Correction ecc model dra_ecc

Default Radio Transceiver Pipeline


transmission delay

errorallocation

errorcorrection

receiver

Point-to-Point Link Transceiver Pipeline Execution Sequencefor one Transmission

transmitter

propagation delay

0 1

23

434-Comec


The pipeline stages for a particular point-to-point link (simplex or duplex) canbe specified using the appropriate attributes of the link object, as shown below.

Comec.4.3.1 Reserved Transmission Data Attributes

The Simulation Kernel sets aside a number of TDAs to provide pipeline stageswith access to a minimum standard set of values, and to support communicationbetween itself and the pipeline stages as well as between the stages and each other.The TDAs reserved for these purposes are defined below. For compactness, thesymbolic constants that represent the TDA’s indices are shown in a short formwithout their common prefix. When actually used, each symbolic constant appearswith the character sequence “OPC_TDA_PT_” prepended to the names given below.The datatype of each TDA is identified in the table next to the symbolic constantname: “D” represents a double-precision floating-point attribute, and “I”represents an integer attribute.

Point-to-Point Pipeline: Reserved TDAs

Symbolic Constant Definition Assigned By

Modifiable by Stages

TX_OBJID (I) object ID of transmitter module Kernel No

RX_OBJID (I) object ID of receiver module Kernel No

LINK_OBJID (I) object ID of link Kernel No

TX_CH_OBJID (I) object ID of transmitter channel Kernel No

pipeline attributes

Point-to-Point Link Attributes for Specifying Pipeline Stages

435-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.3.2 Stage 0: Transmission Delay

The transmission delay stage is the first stage of the pipeline, and is specifiedby the txdel model attribute of the point-to-point link. It is invoked immediatelyupon beginning transmission of a packet, in order to calculate the amount of timerequired for the entire packet to complete transmission. This result can be thoughtof as the simulation time difference between the beginning of transmission of thefirst bit and the end of transmission of the last bit of the packet. The SimulationKernel uses the result provided by this stage to schedule an end-of-transmissionevent for the transmitter channel that is used to send the packet. When this eventoccurs, the transmitter may begin transmission of the next packet in the channel’sinternal queue, if any are present; otherwise the transmitter channel becomes idle.In addition, the transmission delay result is used in conjunction with the result ofthe propagation delay stage to compute the time at which the packet completesreception at the link’s destination (i.e., the time at which the last bit finishesarriving is the time at which it finishes transmitting added to the propagation delayon the link).

The Simulation Kernel requires that the transmission delay stage procedureaccept a packet address as its sole argument. The computed transmission delay isthen expected by the Kernel within the TDA represented by the symbolic constantOPC_TDA_PT_TX_DELAY. The assigned value should be a nonnegative double-

CH_INDEX (I) index of transmitting (and receiving) channel

Kernel No

TX_DELAY (D) packet transmission delay stage 0 Yes

PROP_DELAY (D) packet propagation delay stage 1 Yes

NUM_ERRORS (I) count of bit errors in packet stage 2 Yes

PK_ACCEPT (I) decision to accept/reject packet stage 3 Yes

ND_FAIL (D) earliest simulation time at which node failure occurred during reception of packet

Kernel (if failure occurs)

No

ND_RECOV (D) latest simulation time at which node recovery occurred during reception of packet

Kernel (if recovery occurs)

No

Point-to-Point Pipeline: Reserved TDAs



436-Comec


precision floating-point number. No other results are required. Interfacerequirements for this stage are specified by the following procedure template:

Comec.4.3.3 Stage 1: Propagation Delay

The propagation delay stage is the second stage of the pipeline, and is specifiedby the propdel model attribute of the point-to-point link. It is invoked after thereturn of the transmission delay stage with no simulation time elapsing in between.The purpose of this stage is to calculate the amount of time required for thepacket’s signal to travel from the link’s source to its destination. This result isgenerally dependent on parameters such as the type of physical medium, thedistance between the source and the destination, and the frequency of the signal.Regardless of the factors involved, the Simulation Kernel expects a double-precision floating-point value to be provided by this stage. The Kernel uses thisresult to schedule a beginning-of-reception event for the receiver channel that thepacket is destined for. In addition, the propagation delay result is used inconjunction with the result of the transmission delay stage to compute the time atwhich the packet completes reception (i.e., the time at which the last bit finishesarriving is the time at which the packet begins transmission added to the sum of thetransmission delay and the propagation delay).

The Simulation Kernel requires that the propagation delay stage procedureaccept a packet address as its sole argument. The computed propagation delay isthen expected by the Kernel within the TDA represented by the symbolic constantOPC_TDA_PT_PROP_DELAY. The assigned value should be a nonnegative double-precision floating-point number. No other results are required. Interfacerequirements for this stage are specified by the following procedure template:

voidtx_delay_template (Packet* pk)

{double result;/* extract required information from packet. */

/* perform calculation of transmission delay. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_dbl (pk, OPC_TDA_PT_TX_DELAY, result);}

Template for Point-to-Point Pipeline: Transmission Delay Stage

437-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.3.4 Stage 2: Error Allocation

The error allocation stage is the third stage of the pipeline, and is specified bythe error model attribute of the point-to-point link. It is invoked after the entirepacket has completed reception at the destination, in order to estimate the numberof bit errors that occurred. This is referred to as allocating errors to the packet.This result is generally dependent on a bit-error probability which reflects thequality of the link, and the packet length. The Kernel uses this result to report errorstatistics for the receiver channel object. In addition, this result is typically used bythe final stage of the point-to-point link pipeline in order to decide whether or notto accept the packet and subsequently forward it via the receiver channel’s outputstream.

The Simulation Kernel requires that the error allocation stage procedure accepta packet address as its sole argument. The computed number of errors affecting thepacket is then expected by the Kernel within the TDA represented by the symbolicconstant OPC_TDA_PT_NUM_ERRORS. The assigned value should be an integer valuebetween zero and the packet length (inclusive). No other results are required.Interface requirements for this stage are specified by the following proceduretemplate:

voidprop_delay_template (Packet* pk)


/* perform calculation of propagation delay. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_dbl (pk, OPC_TDA_PT_PROP_DELAY, result);}

Template for Point-to-Point Pipeline: Propagation Delay Stage

438-Comec


Comec.4.3.5 Stage 3: Error Correction

The error correction stage is the fourth and final stage of the pipeline, and isspecified by the ecc model attribute of the point-to-point link. It is invokedimmediately after the return of the error allocation stage, with no simulation timeelapsing in between. The purpose of this stage is to determine whether or not thearriving packet can be accepted and forwarded via the channel’s correspondingoutput stream to one of the receiver’s neighboring modules in the destination node.This is usually dependent upon the result computed in the error allocation stageand the ability of the receiver to correct the errors affecting the packet, hence thename of the stage. Based on the determination of this stage, the Kernel will eitherdestroy the packet, or allow it to proceed into the destination node. In addition, thisresult affects error and throughput statistics collected for the receiver channel.

The Simulation Kernel requires that the error correction stage procedure accepta packet address as its sole argument. The determination to accept or reject thepacket is then expected by the Kernel within the TDA represented by the symbolicconstant OPC_TDA_PT_PK_ACCEPT. The assigned value should be the integer valueOPC_TRUE to indicate acceptance; otherwise the integer value OPC_FALSE should beassigned. No other results are required. Interface requirements for this stage arespecified by the following procedure template:

voiderror_alloc_template (Packet* pk)

{int result;/* extract required information from packet. */

/* perform estimation of number of errors in packet. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_PT_NUM_ERRORS, result);}

Template for Point-to-Point Pipeline: Error Allocation Stage

439-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.4 The Bus Transceiver Pipeline

Because a bus link is a broadcast medium, each transmission can potentiallyaffect multiple receivers attached to the bus. In addition, when processing atransmission, a bus link may exhibit different behavior and timing with respect toeach receiver. As a result, a separate pipeline must be executed for each receiverattached to the bus.

The bus transceiver pipeline consists of six stages, most of which must beexecuted on a per-receiver basis whenever a transmission occurs. However, the firststage (transmission delay) is used to compute a result that is common to alldestinations, and therefore may be executed just once. In addition, each individualpipeline sequence may or may not fully complete, depending on the result of thesecond stage (closure), since this stage is responsible for determining ifcommunication between the transmitter and receiver is possible. Finally, the fourthstage (collision) may be executed multiple times for each transmitted packet, sinceit is possible for a packet to be involved in more than one collision. The structure ofthe bus transceiver pipeline is depicted in the following diagram.

voiderror_correction_template (Packet* pk)


/* determine if packet should be accepted or rejected. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_PT_PK_ACCEPT, result);}

Template for Point-to-Point Pipeline: Error Correction Stage

440-Comec


The pipeline stages for a particular bus link can be specified using theappropriate attributes of the bus link object, as shown below.


The Simulation Kernel sets aside a number of TDAs to provide pipeline stageswith access to a minimum standard set of values, and to support communicationbetween itself and the pipeline stages as well as between the stages and each other.The TDAs reserved for these purposes in packets transmitted over bus links are

transmission delay

closure propagation delayclosureclosureclosure

propagation delay

propagation delay

propagation delay

propagation delay

propagation delay

propagation delaycollision

propagation delay

propagation delay

propagation delay

errorallocation

propagation delay

propagation delay

propagation delay

errorcorrection

collision stage may be exe-cuted zero or more times

executed once per transmission

multiple receivers

Bus Link Transceiver Pipeline Execution Sequencefor one Transmission

transmitter

01 2

345

stages 2 and up are executed separately for each receiver

pipeline attributes

Bus Link Attributes for Specifying Pipeline Stages

441-Comec


om

mu

nicatio

n

Mech

anism

s

defined below. For compactness, the symbolic constants that represent the TDA’sindices are shown in a short form without their common prefix. When actuallyused, each symbolic constant appears with the character sequence “OPC_TDA_BU_”prepended to the names given below. The datatype of each TDA is identified in thetable next to the symbolic constant name: “D” represents a double-precisionfloating-point attribute, and “I” represents an integer attribute.

Bus Pipeline Reserved TDAs



TX_OBJID (I) object ID of bus transmitter Kernel no

LINK_OBJID (I) object ID of bus link Kernel no

TX_TAP_OBJID (I) object ID of transmitter’s tap Kernel no

TX_CH_OBJID (I) object ID of tx channel Kernel no

CH_INDEX (I) index of tx and rx channel Kernel no

RX_OBJID (I) object ID of bus receiver Kernel no

RX_TAP_OBJID (I) object ID of receiver’s tap Kernel no

DISTANCE (D) distance between rx and tx (in meters)

Kernel no

NUM_COLLS (I) number of collisions experienced by packet to date

Kernel, stage 3

yes

END_RX (D) time when reception will complete Kernel no

CLOSURE (I) capability of tx to reach rx stage 1 yes

TX_DELAY (D) time required to complete trans-mission on tx side

stage 0 yes

PROP_DELAY (D) time required for packet’s signal to travel from tx to rx

stage 2 yes

NUM_ERRORS (I) number of bit errors affecting packet

stage 4 yes

PK_ACCEPT (I) decision to accept/reject packet stage 5 yes

ND_FAIL (D) earliest simulation time at which node failure occurred during reception of packet


no

ND_RECOV (D) latest simulation time at which node recovery occurred during reception of packet


no

442-Comec



The transmission delay stage is the first stage of the pipeline, and is specifiedby the txdel model attribute of the bus link. It is invoked immediately uponbeginning transmission of a packet. This is the only stage for which a singleexecution is performed to support all pipelines that result from a new transmission(i.e., the computation is shared by all resulting pipelines).

This stage is invoked to calculate the amount of time required for the entirepacket to complete transmission. This result is the simulation time differencebetween the beginning of transmission of the first bit and the end of transmissionof the last bit of the packet. The Simulation Kernel uses the result provided by thisstage to schedule an end-of-transmission event for the transmitter channel that isused to send the packet. When this event occurs, the transmitter may begintransmission of the next packet in the channel’s internal queue, if any are present;otherwise the transmitter channel becomes idle. In addition, the transmission delayresult is used in conjunction with the result of the propagation delay stage tocompute the time at which the packet completes reception at the link’s destination(i.e., the time at which the last bit finishes arriving is the time at which it finishestransmitting added to the propagation delay on the link).

The Simulation Kernel requires that the transmission delay stage procedureaccept a packet address as its sole argument. The computed transmission delay isthen expected by the Kernel within the TDA represented by the symbolic constantOPC_TDA_BU_TX_DELAY. The assigned value should be a nonnegative double-precision floating-point number. No other results are required. Syntaxrequirements for this stage are specified by the following procedure template:

Comec.4.4.3 Stage 1: Closure

The closure stage is the second stage of the pipeline, and is specified by theclosure model attribute of the bus link. It is invoked once for each receiverattached to the bus. These invocations take place immediately after the return ofthe transmission delay stage, with no simulation time elapsing in between. Thepurpose of this stage is to determine whether a particular receiver is capable of




/* place result in TDA to return to Simulation Kernel. */op_td_set_dbl (pk, OPC_TDA_BU_TX_DELAY, result);}

Template for Bus Pipeline: Transmission Delay Stage

443-Comec


om

mu

nicatio

n

Mech

anism

s

receiving a transmission. The ability to receive a transmission is referred to asclosure between the transmitter and the receiver, hence the name of the stage.

The Simulation Kernel expects an integer value to be provided by this stage.The Kernel uses this result to determine whether to execute the remainder of thebus pipeline for the particular receiver in question. If the integer value is equal tothe symbolic constant OPC_TRUE then closure is established and communicationbetween the transmitter and receiver is possible; otherwise the value OPC_FALSEshould be used to indicate that communication is not possible.

The Simulation Kernel requires that the closure stage procedure accept apacket address as its sole argument. The closure indication is then expected by theKernel within the TDA represented by the symbolic constantOPC_TDA_BU_PROP_CLOSURE. No other results are required. Interface requirementsfor this stage are specified by the following procedure template:


The propagation delay stage is the third stage of the pipeline, and is specifiedby the propdel model attribute of the bus link. It is invoked for each receiver thatis attached to the bus; this invocation takes place after the return of the closurestage with no simulation time elapsing in between. The purpose of this stage is tocalculate the amount of time required for the packet’s signal to travel from the bustransmitter to the bus receiver. This result is generally dependent on factors such asthe type of physical medium, the distance between the source and the destination,and the frequency of the signal. Regardless of the factors involved, the SimulationKernel expects a double-precision floating-point value to be provided by this stage.The Kernel uses this result to schedule a beginning-of-reception event for thereceiver channel that the packet is destined for. In addition, the propagation delayresult is used in conjunction with the result of the transmission delay stage tocompute the time at which the packet completes reception (i.e., the time at whichthe last bit finishes arriving is the time at which the packet begins transmissionadded to the sum of the transmission delay and the propagation delay).

The Simulation Kernel requires that the propagation delay stage procedureaccept a packet address as its sole argument. The computed propagation delay is

voidclosure_template (Packet* pk)


/* perform calculation of closure indication. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_BU_CLOSURE, result);}

Template for Bus Pipeline: Closure Stage

444-Comec


then expected by the Kernel within the TDA represented by the symbolic constantOPC_TDA_BU_PROP_DELAY. The assigned value should be a nonnegative double-precision floating-point number. No other results are required. Interfacerequirements for this stage are specified by the following procedure template:

Comec.4.4.5 Stage 3: Collision

The collision stage occupies the fourth position in the bus transceiver pipeline,and is specified by the coll model attribute of the bus link. Unlike other pipelinestages, it may be executed multiple times or not at all within a given pipelinesequence. This stage is called each time that the packet of interest experiences anew collision; a collision is considered to occur when the packet of interestinitially arrives at the receiver and another packet has already begun arriving on thesame channel; or when the packet of interest has already begun arriving andanother packet begins. In other words, collisions are symmetric events experiencedby both packets involved. When a collision occurs, a single call to the collisionstage is generated in order to support both of the packets’ pipelines. Because anarbitrary number of transmissions may occur on the bus during the reception timeof a packet, a single packet may experience multiple collisions.

The purpose of the collision stage is to provide application-specific modelswith knowledge of collisions. The Simulation Kernel expects no particular resultsto be generated by the invoked pipeline procedure. However, the Kernel doesreserve a TDA to keep track of the number of collisions experienced by a packet,since this is a typical requirement of most pipelines, including the default stages.This TDA is represented by the symbolic constant OPC_TDA_BU_NUM_COLLS and isinitially set to zero when the packet is transmitted. Typically, if a collision isjudged to be relevant in the sense that it has a bearing on later processing of thepacket, then the logic in this stage increments the value of the TDAOPC_TDA_BU_NUM_COLLS.

The Simulation Kernel requires that the collision stage procedure accept twopacket addresses as arguments. The first packet address is that of the earlierarriving packet, and the second address is that of the later arriving packet that




/* place result in TDA to return to Simulation Kernel. */op_td_set_dbl (pk, OPC_TDA_BU_PROP_DELAY, result);}

Template for Bus Transceiver Pipeline: Propagation Delay Stage

445-Comec


om

mu

nicatio

n

Mech

anism

s

triggered the collision. Interface requirements for this stage are specified by thefollowing procedure template:


The error allocation stage is the fifth stage of the pipeline, and is specified bythe error model attribute of the bus link. It is invoked after the entire packet hascompleted reception at the destination, in order to estimate the number of bit errorsthat occurred. This is referred to as allocating errors to the packet. This result isgenerally dependent on a bit-error probability which reflects the quality of the link,and the packet length. This calculation usually does not include errors due tocollisions.

The Kernel uses the result of this stage to report error statistics for the receiverchannel object. In addition, this result is typically used by the final stage of the buslink pipeline in order to decide whether or not to accept the packet andsubsequently forward it via the receiver channel’s output stream.

The Simulation Kernel requires that the error allocation stage procedure accepta packet address as its sole argument. The computed number of errors affecting thepacket is then expected by the Kernel within the TDA represented by the symbolicconstant OPC_TDA_BU_NUM_ERRORS. The assigned value should be an integer valuebetween zero and the packet length (inclusive). No other results are required.Interface requirements for this stage are specified by the following proceduretemplate:

voidcollision_template (earlier_pk, later_pk)

Packet* earlier_pk;Packet* later_pk;{}

Template for Bus Transceiver Pipeline: Collision Stage

voiderror_alloc_template (Packet* pk)


/* perform estimation of number of errors in packet. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_BU_NUM_ERRORS, result);}

Template for Bus Pipeline: Error Allocation Stage

446-Comec



The error correction stage is the sixth and final stage of the pipeline, and isspecified by the ecc model attribute of the bus link. It is invoked immediately afterthe return of the error allocation stage, with no simulation time elapsing inbetween. The purpose of this stage is to determine whether or not the arrivingpacket can be accepted and forwarded via the channel’s corresponding outputstream to one of the receiver’s neighboring modules in the destination node. This isusually dependent upon whether the packet has experienced collisions, the resultcomputed in the error allocation stage, and the ability of the receiver to correct theerrors affecting the packet (hence the name of the stage). Based on thedetermination of this stage, the Kernel will either destroy the packet, or allow it toproceed into the destination node. In addition, this result affects error andthroughput statistics collected for the receiver channel.

The Simulation Kernel requires that the error correction stage procedure accepta packet address as its sole argument. The determination to accept or reject thepacket is then expected by the Kernel within the TDA represented by the symbolicconstant OPC_TDA_BU_PK_ACCEPT. The assigned value should be an integer equalto the constant OPC_TRUE to indicate acceptance; otherwise the integer valueOPC_FALSE should be assigned. No other results are required. Interfacerequirements for this stage are specified by the following procedure template:

Comec.4.5 The Radio Transceiver Pipeline

Because radio links provide a broadcast medium, each transmission canpotentially affect multiple receivers throughout the network model. In addition, fora given transmission, the radio link to each receiver may exhibit different behaviorand timing. As a result, a separate pipeline must be executed for each eligiblereceiver.

The radio transceiver pipeline consists of fourteen stages, most of which mustbe executed on a per-receiver basis whenever a transmission occurs. However, thefirst stage (receiver group) is invoked only once for each pair of transmitter andreceiver channels in the network, in order to establish a static binding betweeneach transmitter channel and the set of receiver channels that it is allowed to




/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_BU_PK_ACCEPT, result);}

Template for Bus Pipeline: Error Correction Stage

447-Comec


om

mu

nicatio

n

Mech

anism

s

communicate with. The second stage (transmission delay) is used to compute aresult that is common to all destinations, and therefore may be executed just onceper transmission. Finally, each individual pipeline sequence may or may not fullycomplete, depending on the result of the third stage (closure), since this stage isresponsible for determining if communication between the transmitter and receiveris possible on a dynamic basis. Similarly, the fourth stage (channel match) mayclassify a transmission as irrelevant with regard to its effect on a particular receiverchannel, thereby preventing the pipeline sequence from reaching the final stages.

Note from the following diagrams that several of the later stages of the radiopipeline may be executed multiple times for each receiver, due to interactions withmultiple concurrent transmissions from other sources. In order to detect concurrentreception of multiple packets at the same receiver channel, the Simulation Kernelmaintains two lists of “current” packets for each radio receiver channel object. Thefirst list contains only packets that have been determined to be valid by thechannel match stage; the second list contains invalid packets. Valid packets arethose that meet the criteria of the channel for proper reception. Generally, thisrequires that the transmitter and receiver channels have matching characteristics,and possibly also that the receiver channel be able to synchronize to the packet’ssignal. The primary reason for maintaining invalid and valid packets in separatelists is that this allows the Simulation Kernel to execute certain pipeline stages orto compute certain channel statistics only for valid packets. For example, there isno need to calculate signal-to-noise ratio, bit error rate, or error allocations forpackets that cannot be accepted by the receiver. In general, all of the stagesfollowing the received power stage are applicable only to valid packets.

448-Comec


Stages 9 through 12 of the pipeline are invoked to evaluate a link’sperformance in response to changes in the signal condition. There is always at leastone invocation of stages 10 through 12 in order to evaluate performance over thefull duration of a valid packet. However, an additional invocation will occur for

stages 2 and up are executed separately for each rx

errorcorrection

13

receivergroup

background noise

tx antennagain

propagationdelay

stage 9 may be executed zero or more times

executed once per transmission

multiple receivers

Radio Link Transceiver Pipeline Execution Sequencefor one Transmission

transmitter

0

45

transmission delay

1

linkclosure

2

8

signal to noise ratio

10

stages 10-12 may be executed one or more times

Executed once at start of sim-ulation for each pair of trans-mitter and receiver channels to determine feasibility of communication; not executed on a per-transmission basis

7

receivedpower

interference noise

9

rx antennagain

6

channelmatch

3

bit errorrate

11

errorallocation

12

449-Comec


om

mu

nicatio

n

Mech

anism

s

each of these stages (9-12) whenever an interfering packet arrives, in order tocompute new signal conditions.

Because radio links do not exist as physical objects, the pipeline stages used tosupport a particular radio transmission must be associated with the radiotransmitter and radio receiver that form the link. Certain stages are associated withthe transmitter and others with the receiver, as shown below:


The Simulation Kernel sets aside a number of TDAs to provide pipeline stageswith access to a minimum standard set of values, and to support communicationbetween itself and the pipeline stages as well as between the stages and each other.The TDAs reserved for these purposes in packets transmitted over radio links aredefined in the following table. For compactness, the symbolic constants thatrepresent the TDA’s indices are shown in a short form without their commonprefix. When actually used, each symbolic constant appears with the charactersequence “OPC_TDA_RA_” prepended to the names given in the table below. Thedatatype of each TDA is identified in the table next to the symbolic constant name:“D” represents a double-precision floating-point attribute, and “I” represents aninteger attribute.

Radio Transceiver Attributes for Specifying Pipeline Stages

8 Stages (6 -13) associated with Radio Receiver

6 Stages (0 -5) associatedwith Radio Transmitter

450-Comec


Radio Pipeline Reserved TDAs

Symbolic Constant and Datatype

Definition Assigned By


TX_OBJID (I) object ID of radio transmitter Kernel no

TX_CH_OBJID (I) object ID of radio tx channel Kernel no

TX_CH_INDEX (I) index of transmitter channel Kernel no

NUM_COLLS (I) number of collisions experi-enced by packet to date

reset by Kernel

yes

TX_DELAY (D) transmission delay of packet (in seconds)

stage 1 yes

RX_OBJID (I) object ID of radio receiver Kernel no

RX_CH_OBJID (I) object ID of radio rx channel Kernel no

START_DIST (D) distance between tx and rx at start of transmission (in meters)

Kernel no

CLOSURE (I) ability of tx channel to communi-cate with rx channel

stage 2 yes

START_PROPDEL (D) radio signal propagation time between tx and rx at start of transmission (in seconds)

stage 5 yes

START_RX(D) simulation time at which packetbegins reception

Kernel no

END_RX (D) simulation time at which packet completes reception

Kernel no

RCVD_POWER (D) in-band power of received radio signal (in watts)

stage 7 yes

TX_LAT, TX_LONG, TX_ALT (D)

latitude, longitude (in degrees), and altitude (in meters) of trans-mitting node

Kernel no

RX_LAT, RX_LONG, RX_ALT (D)

latitude, longitude (in degrees), and altitude (in meters) of receiving node

Kernel no

RX_CH_INDEX (I) index of receiver channel Kernel no

TX_FREQ (D) base frequency of transmitter channel (in Hz)

Kernel no

TX_BW (D) bandwidth of transmitter chan-nel (in Hz)

Kernel no

TX_DRATE (D) data rate of transmitter channel (in bits per second)

Kernel no

TX_POWER (D) power of transmission (in watts) Kernel no

451-Comec


om

mu

nicatio

n

Mech

anism

s

TX_CODE (D) code used to identify transmitter spreading technique and/or sequence

Kernel no

RX_FREQ (D) base frequency of receiver channel (in Hz)

Kernel no

RX_BW (D) bandwidth of receiver channel (in Hz)

Kernel no

RX_DRATE (D) data rate of receiver channel (in bits per second)

Kernel no

RX_CODE (D) code used to identify receiver spreading technique and/or sequence

Kernel no

TX_REL_X, TX_REL_Y (D)

transmitter node’s position in coordinate system of own sub-net

Kernel no

TX_GEO_X, TX_GEO_Y, TX_GEO_Z (D)

transmitter node’s geocentric Cartesian coordinates (in meters)

Kernel no

RX_REL_X, RX_REL_Y (D)

transmitter node’s position in coordinate system of own sub-net

Kernel no

RX_GEO_X, RX_GEO_Y, RX_GEO_Z (D)

transmitter node’s geocentric Cartesian coordinates (in meters)

Kernel no

END_TX (D) simulation time at which packet completes reception

Kernel no

START_TX (D) simulation time at which packet begins transmission

Kernel no

NUM_ERRORS (I) number of bit errors affecting packet to date

stage 12 and reset by Kernel

yes

PK_ACCEPT (I) decision to accept/reject packet stage 13 Yes

TX_MOD (I) identifier for transmitter’s modu-lation format

Kernel no

RX_MOD (I) identifier for transmitter’s modu-lation format

Kernel no

MATCH_STATUS (I) categorization of compatibility between tx and rx channels as valid, noise, or ignored

stage 3 yes

Radio Pipeline Reserved TDAs (Cont.)




452-Comec


RX_NOISEFIG (D) noise figure of receiver Kernel no

BKGNOISE (D) background noise due to other-wise unmodeled sources (in watts)

stage 8 yes

NOISE_ACCUM (D) accumulated noise power of interfering transmissions (in watts) for packet or segment thereof

stage 9 yes

SNR (D) ratio of signal power to noise power measured at receiver location (in dB) for packet or segment thereof

stage 10 yes

SNR_CALC_TIME (D) simulation time at which SNR was last calculated

stage 10 yes

PROC_GAIN (D) processing gain provided by receiver system (in dB); used to compute effective SNR

Kernel no

BER (D) expected bit error probability for packet or segment thereof

stage 11 yes

ECC_THRESH (D) maximum proportion of errone-ous bits that receiver can correct

Kernel no

ACTUAL_BER (D) proportion of erroneous bits in packet or segment thereof

stage 12 yes

END_DIST (D) distance between tx and rx at time when transmission com-pletes (in meters)

Kernel no

END_PROPDEL (D) radio signal propagation time between tx and rx at end of transmission (in seconds)

stage 5 yes

TX_PATTERN (I) identifier of transmitting antenna’s gain pattern

Kernel no

TX_GAIN (I) gain provided to signal by trans-mitter’s antenna

stage 4 yes

RX_PATTERN (I) identifier of receiving antenna’s gain pattern

Kernel no

RX_GAIN (D) gain provided to signal by receiver’s antenna

stage 6 yes

TX_PHI_POINT, TX_THETA_POINT (D)

pointing angles (in degrees) based on target attributes of transmitting antenna

Kernel no





453-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.5.2 Stage 0: Receiver Group

The receiver group stage is not actually part of the dynamic pipeline thatprocesses transmissions. However, it is considered part of the pipeline because itcomputes results that influence the behavior of radio transmissions. It is specifiedby the rxgroup model attribute of the radio transmitter.

When a radio transmission begins, the Simulation Kernel models the broadcastnature of radio by implementing multiple radio links between the transmittingchannel and a set of receiver channels. Every transmitter channel maintains its ownreceiver group of channels that are possible candidates for receiving transmissionsfrom that object. The purpose of the receiver group stage is to create an initialreceiver group for each transmitter channel. The Simulation Kernel checks everypossible transmitter-receiver channel pair, and creates a receiver group for eachtransmitter channel.

This presents a problem, however: since transceiver characteristics can changedynamically during a simulation, it is often difficult to determine at the outsetwhich receiver channels are appropriate destinations for a given transmitterchannel. Therefore, the receiver group stage includes a receiver channel unless itcan determine, in advance, that a receiver channel will never be an appropriatedestination for a transmitter channel. During a simulation, subsequent pipelinestages can use dynamic criteria to determine a receiver channel’s eligibility forreceiving a transmission. Possible reasons for disqualifying a receiver channelduring simulation (despite its membership in the transmitting channel’s receivergroup) include:

TX_BORESIGHT_PHI, TX_BORESIGHT_THETA (D)

reference point on transmitting antenna (in degrees); usually point of maximum gain

Kernel no

RX_PHI_POINT, RX_THETA_POINT (D)

pointing angles (in degrees) based on target attributes of receiving antenna

Kernel no

RX_BORESIGHT_PHI, RX_BORESIGHT_THETA (D)

reference point on receiving antenna (in degrees); usually point of maximum gain

Kernel no

ND_FAIL (D) earliest simulation time at which rx node failure occurred during reception of packet


no

ND_RECOV (D) latest simulation time at which rx node recovery occurred during reception of packet


no





454-Comec


• Disjunct frequency bands. A frequency band is defined by its basefrequency and its bandwidth. If a transmitter channel and receiver chan-nel’s frequency bands do not overlap, then the transmitter channel’stransmissions cannot affect the receiver channel–either as valid signalsor as noise.

• Physical separation. A transmitter channel and receiver channel maybe too far apart to establish a radio link with a sufficiently strong signal.Establishing a radio link also depends on factors like the elevation ofthe transmitter and receiver antennas and the transmission signal’spower and frequency.

• Antenna nulls. The pipeline models the gain patterns of transmitterand receiver antennas in pipeline stages 4 and 6, respectively. When di-rectional antennas are used, these stages’ computed results may reducethe signal power significantly–so significantly that a simulation canreasonably ignore the effect of transmissions on the receiver channel inquestion.

In some network models, the Simulation Kernel can determine that certaintransmitter-receiver channel pairs are absolutely unable to communicate. In suchcases removing the receiver channel from the transmitter channel’s receiver groupleads to faster simulations, since it eliminates the execution of pipeline stagesknown to have no effect. Because the receiver group stage is called before thesimulation begins, however, its results should not depend on factors that maychange during the simulation. Examples of such potentially “iffy” criteria are theinitial distance between two mobile nodes and the initial frequencies assigned totransmitter and receiver channels (assuming that a model can dynamically changethese frequencies). By default, OPNET includes the receiver channel in such cases,and all receiver groups remain static throughout the simulation; subsequentpipeline stages then use dynamic criteria to evaluate transmitter-receiver channelconnectivity.

The Simulation Kernel requires that the receiver group stage procedure acceptthe object IDs of a transmitter channel and a receiver channel, respectively. Theprocedure should return an integer value (OPC_TRUE or OPC_FALSE) to the Kernel;this value indicates whether the receiver channel is an eligible destination, andshould be included in the receiver group. Syntax requirements for this stage arespecified by the following procedure template:

455-Comec


om

mu

nicatio

n

Mech

anism

s

You can use the Radio package of Kernel Procedures to change the defaultreceiver-group-stage behavior, and dynamically change and recalculate receivergroups in response to simulation events. For example, you can remove a receiverchannel from a receiver group if the receiver’s node becomes disabled in the courseof a simulation. You can use the procedure op_radio_txch_rxgroup_compute() tocalculate or recalculate a given channel’s receiver group (in essence, re-invokingthe receiver group pipeline stage) at any time during a simulation. You can even“skip” the receiver group stage entirely, then create and update receiver groups asneeded. (Skipping this pipeline stage involves setting the rxgroup model attributeto dra_no_rxgroup instead of the default dra_rxgroup; this creates emptyreceiver groups for all transmitter channels.) Updating receiver groupsdynamically can result in faster simulations, especially in network models withhigh levels of radio traffic. “Skipping” the pipeline stage and creating receivergroups as needed can also speed up simulations in networks with large numbers oftransceiver channels.


The transmission delay stage is numerically the second stage of the radiopipeline, but is the first to be executed on a dynamic basis as the result of a newtransmission taking place. It is specified by the txdel model attribute of the radiotransmitter, and is invoked immediately upon beginning transmission of a packet.This is the only stage for which a single execution is performed to support allpipelines that result from a new transmission (i.e., the computation is shared by allresulting pipelines).

This stage is invoked to calculate the amount of time required for the entirepacket to complete transmission. This result is the simulation time differencebetween the beginning of transmission of the first bit and the end of transmissionof the last bit of the packet. The Simulation Kernel uses the result provided by thisstage to schedule an end-of-transmission event for the transmitter channel that isused to send the packet. When this event occurs, the transmitter may begintransmission of the next packet in the channel’s internal queue, if any are present;otherwise the transmitter channel becomes idle. In addition, the transmission delayresult is used in conjunction with the result of the propagation delay stage tocompute the time at which the packet completes reception at the link’s destination

intrx_group_template (tx_channel_objid, rx_channel_objid)

Objid tx_channel_objid;Objid rx_channel_objid;{int result;

return (result);}

Template for Radio Transceiver Pipeline: Receiver Group Stage

456-Comec


(i.e., the time at which the last bit finishes arriving is the time at which it finishestransmitting added to the propagation delay on the link).

The Simulation Kernel requires that the transmission delay stage procedureaccept a packet address as its sole argument. The computed transmission delay isthen expected by the Kernel within the TDA represented by the symbolic constantOPC_TDA_RA_TX_DELAY. The assigned value should be a nonnegative double-precision floating-point number. No other results are required. Syntaxrequirements for this stage are specified by the following procedure template:

Comec.4.5.4 Stage 2: Closure

The closure stage is the third stage of the pipeline, and is specified by theclosure model attribute of the radio transmitter. It is invoked once for eachreceiver channel referenced in the transmitting channel’s destination channel set(For information on destination channel sets, refer to section Comec.4.5.2 Stage 0:Receiver Group.) These invocations take place immediately after the return of thetransmission delay stage, with no simulation time elapsing in between. Thepurpose of this stage is to determine whether a particular receiver channel can beaffected by a transmission. The ability of the transmission to reach the receiverchannel is referred to as closure between the transmitter channel and the receiverchannel, hence the name of the stage.

Note that the goal of the closure stage is not to determine if a transmission isvalid or appropriate for a particular channel, but only if the transmitted signal canphysically attain the candidate receiver channel and affect it in any way; thus, thisstage applies to interfering transmissions (e.g., jamming) as well as to desiredones. Generally, the computations performed by this stage are based mostly onphysical considerations, such as occlusion by obstacles and/or the surface of theearth.

The Simulation Kernel expects an integer value to be provided by this stage.The Kernel uses this result to determine whether to execute the remainder of theradio pipeline for the receiver channel in question. If the integer value is equal tothe symbolic constant OPC_TRUE then closure is established and signal contact




/* place result in TDA to return to Simulation Kernel. */op_td_set_dbl (pk, OPC_TDA_RA_TX_DELAY, result);}

Template for Radio Transceiver Pipeline: Transmission Delay Stage

457-Comec


om

mu

nicatio

n

Mech

anism

s

between the transmitter and receiver channels is possible; otherwise the valueOPC_FALSE should be used to indicate that contact is not possible.

The Simulation Kernel requires that the closure stage procedure accept apacket address as its sole argument. The closure indication is then expected by theKernel within the TDA represented by the symbolic constantOPC_TDA_RA_PROP_CLOSURE. No other results are required. Syntax requirementsfor this stage are specified by the following procedure template:

Comec.4.5.5 Stage 3: Channel Match

The channel match stage is the fourth stage of the pipeline, and is specified bythe chanmatch model attribute of the radio transmitter. It is invoked once for eachreceiver channel that satisfies the criteria of the link closure stage. Theseinvocations take place immediately after the return of the link closure stage, withno simulation time elapsing in between. The purpose of this stage is to classify thetransmission with respect to the receiver channel. One of three possible categoriesmust be assigned to the packet, as defined below:

• Valid. Packets in this category are considered compatible with the re-ceiver channel and will possibly be accepted and forwarded to othermodules in the receiving node, provided that they are not affected by anexcessive number of errors. Classification as a valid packet usually de-pends at least on agreement between transmitter and receiver channelsconcerning the values of certain key attributes.

• Noise. This classification is used to identify packets whose data contentcannot be received, but that have an impact on the receiver channel’sperformance by generating interference. Packets are generally classi-fied as noise as a result of incompatibilities between the transmitter andreceiver channel configurations.

voidclosure_template (Packet* pk)


/* perform calculation of closure indication. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_RA_CLOSURE, result);}

Template for Radio Transceiver Pipeline: Closure Stage

458-Comec


• Ignored. If a transmission is determined to have no effect whatsoeveron a receiver channel’s state or performance, then it should be identi-fied using this classification. The Simulation Kernel will then discon-tinue the pipeline execution between the transmitter and receiverchannels for this particular transmission (future transmissions betweenthe channels are not prevented).

The Simulation Kernel requires that the channel match stage procedure accepta packet address as its sole argument. The classification is then expected by theKernel within the integer TDA represented by the symbolic constantOPC_TDA_RA_MATCH_STATUS. One of the symbolic constantsOPC_TDA_RA_MATCH_VALID, OPC_TDA_RA_MATCH_NOISE, orOPC_TDA_RA_MATCH_IGNORE should be used to represent the valid, noise, andignored categories, respectively. No other results are required. Syntaxrequirements for this stage are specified by the following procedure template:

Comec.4.5.6 Stage 4: Transmitter Antenna Gain

The transmitter antenna gain stage is the fifth stage of the radio transceiverpipeline, and is specified by the tagain model attribute of the radio transmitter. Itis executed separately for each destination channel, except those that failed the linkclosure stage and those with respect to which the channel match stage hasclassified the transmission as “ignored”. Invocation of the transmitter antenna gainstage takes place immediately after return from the channel match stage with nosimulation time elapsing in between. The purpose of the transmitter antenna gainstage is to compute the gain provided by the transmitter’s associated antenna,based on the direction of the vector leading from the transmitter to the receiver.The Simulation Kernel does not itself use this result, but it is typically factored intothe received power computation of stage 7.

Antenna gain characterizes the phenomenon of magnification or reduction ofthe transmitted signal energy in a manner which depends on the direction of the

voidchannel_match_template (Packet* pk)


/* perform calculation of channel match classification. */

/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_RA_MATCH_STATUS, result);}

Template for Radio Transceiver Pipeline: Channel Match Stage

459-Comec


om

mu

nicatio

n

Mech

anism

s

signal path. This “shaping” of the transmitted energy is due to the physicalcharacteristics of the antenna structure and possible phase manipulations of thesignal in certain antennas consisting of multiple radiating elements.

Antennas that provide no gain to a transmitted signal in any direction arereferred to as isotropic, since they have a perfectly symmetric behavior withrespect to all possible signal paths. The gain of an antenna in a particular directionis measured in comparison to an isotropic antenna. It is defined as the ratio ofsignal power produced by the antenna at a given distance and the isotropic powerthat would be measured at the same distance. Gain is a unitless quantity that isusually given in decibels (dB).

By measuring or computing gain over a range of directions, a threedimensional antenna pattern can be constructed that characterizes the antenna’seffect with respect to the various directions of transmission. OPNET does notprovide tools for calculation of antenna patterns but the Antenna Editor supportsthe capture of antenna pattern data in an empirical form (i.e., the pattern mustalready be known and can be entered in numerical form). In addition, the Emaprogrammatic interface supports specification of antenna pattern data by a Clanguage program, allowing patterns to be formed by analytical techniques, ordatabase retrieval (i.e., other antenna-specific applications can be used to generatepattern data, and this data can be utilized by OPNET simulations). Regardless ofthe method used to capture antenna pattern data, the Antenna Editor displays thepattern in 3_d, as shown in the example below. Refer to Antenna Pattern Editor inEditor Reference for details on the Antenna Editor.

Three-Dimensional Antenna-Gain Pattern

460-Comec


In general, the transmitter antenna gain stage first calculates the directionvector separating the transmitter and the receiver and then uses knowledge of theantenna pattern to determine the antenna gain provided to the transmission.Pointing of the antenna is typically also accounted for by this pipeline stage (referto the Node Domain chapter of Modeling Concepts). Pointing is controlled by a setof antenna attributes. These include pointing ref. phi and pointing ref.theta, which designate a particular part of the antenna pattern which is to bedirected at a selected point in space. Pipeline stages may obtain these attributes ofthe transmitter antenna via the TDAs OPC_TDA_RA_TX_BORESIGHT_PHI andOPC_TDA_RA_TX_BORESIGHT_THETA. In addition, the antenna attributes targetlatitude, target longitude, and target altitude define a location in space atwhich the antenna’s reference point is to be directed. Pipeline stages may obtainthe values of these attributes directly from the antenna object, if necessary.However, the Simulation Kernel provides information derived from theseattributes, which is in many cases sufficient for antenna gain calculations; thisinformation is contained in the TDAs OPC_TDA_RA_TX_PHI_POINT andOPC_TDA_RA_TX_THETA_POINT, which represent the direction angles φ and θ of thevector separating the transmitter and the target location. These angles are not to beconfused with the φ and θ angles used to define the antenna pattern. Rather, thesetarget pointing angles are defined relative to the geocentric Cartesian coordinatesystem (refer to the Network Domain chapter of Modeling Concepts). Thefollowing figure illustrates the meaning of these angles within this coordinatesystem.

The Simulation Kernel reserves a TDA, represented by the symbolic constantOPC_TDA_RA_TX_GAIN, to store the result of the transmitter antenna gain stage andto make it available to later stages of the pipeline. The Simulation Kernel requires

Xθ = 0 deg.

θ = 270 deg.

φ = 90 deg.

φ = 0 deg.

θ+.

φ+.

Y

Z

Relationship of Pointing Angles φ and θ to Geocentric Cartesian Coordinate System

φ = -90 deg.

461-Comec


om

mu

nicatio

n

Mech

anism

s

that the stage’s procedure accept a packet address as its sole argument. Syntaxrequirements for this stage are specified by the following procedure template:


The propagation delay stage is the sixth stage of the radio transceiver pipeline,and is specified by the propdel model attribute of the radio transmitter. It isinvoked for each receiver channel that successfully passed both the link closureand channel match stages. This invocation takes place after the return of thetransmitter antenna gain stage with no simulation time elapsing in between. Thepurpose of this stage is to calculate the amount of time required for the packet’ssignal to travel from the radio transmitter to the radio receiver. This result isgenerally dependent on the distance between the source and the destination. TheKernel uses this result to schedule a beginning-of-reception event for the receiverchannel that the packet is destined for. In addition, the propagation delay result isused in conjunction with the result of the transmission delay stage to compute thetime at which the packet completes reception (i.e., the time at which the last bitfinishes arriving is the time at which the packet begins transmission added to thesum of the transmission delay and the propagation delay).

The Simulation Kernel requires that the propagation delay stage procedureaccept a packet address as its sole argument. The computed propagation delay isthen expected by the Kernel within the TDA represented by the symbolic constantsOPC_TDA_RA_START_PROPDEL and OPC_TDA_RA_END_PROPDEL. The assignedvalues should be nonnegative double-precision floating-point numbers. No otherresults are required. Syntax requirements for this stage are specified by thefollowing procedure template:

voidtx_antenna_gain_template (Packet* pk)


/* perform calculation of tx antenna gain. */

/* place result in TDA to make available for later stages. */op_td_set_dbl (pk, OPC_TDA_RA_TX_GAIN, result);}

Template for Radio Transceiver Pipeline: Transmitter Antenna Gain Stage

462-Comec


Comec.4.5.8 Stage 6: Receiver Antenna Gain

The receiver antenna gain stage is the seventh stage of the radio transceiverpipeline. It is the earliest stage associated with the radio receiver rather than thetransmitter, being specified by the receiver’s ragain model attribute. It is executedseparately for each eligible destination channel, and its invocation takes place atthe time that the leading edge of the packet arrives at the receiver location (i.e.,after the propagation delay has elapsed).

The purpose of the receiver antenna gain stage is to compute the gain providedby the receiver’s associated antenna, based on the direction of the vector leadingfrom the receiver to the transmitter. The Simulation Kernel does not itself use thisresult, but it is typically factored into the received power computation of stage 7.

The concept of receiver antenna gain is identical to that of transmitter antennagain, except that it is due to the physical configuration and implementation of theantenna associated with the receiver object. For information on antenna gain andantenna patterns, refer to section Comec.4.5.6 Stage 4: Transmitter Antenna Gain.

The Simulation Kernel reserves a TDA, represented by the symbolic constantOPC_TDA_RA_RX_GAIN, to store the result of this stage and to make it available tolater stages of the pipeline. The Simulation Kernel requires that the stage’sprocedure accept a packet address as its sole argument. Syntax requirements forthis stage are specified by the following procedure template:


{double start_prop_delay, end_prop_delay;/* extract required information from packet. */


/* place result in TDA to return to Simulation Kernel. */op_td_set_dbl (pk, OPC_TDA_RA_START_PROPDEL,

start_prop_delay);op_td_set_dbl (pk, OPC_TDA_RA_END_PROPDEL, end_prop_delay);}

Template for Radio Transceiver Pipeline: Propagation Delay Stage

463-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.5.9 Stage 7: Receiver Power

The receiver power stage is the eighth stage of the radio transceiver pipeline,and is specified by the power model attribute of the radio receiver. It is executedseparately for each eligible destination channel; invocation takes placeimmediately after return of the receiver antenna gain model, with no simulationtime elapsing in between. The purpose of this stage is to compute the receivedpower of the arriving packet’s signal (in watts).

For packets that are classified as valid, the received power result is a key factorin determining the ability of the receiver to correctly capture the information in thepacket (For information on the channel match model, refer to sectionComec.4.5.5 Stage 3: Channel Match.)For packets that are classified as noise,received power must usually still be evaluated in order to support calculation ofrelative strengths of valid and noise packets.

In general, the calculation of received power is based on factors such as thepower of the transmitter, the distance separating the transmitter and the receiver,the transmission frequency, and transmitter and receiver antenna gains. TheSimulation Kernel requires that the received power stage procedure accept a packetaddress as its sole argument. The computed received power is then expected by theKernel within the TDA represented by the symbolic constantOPC_TDA_RA_RCVD_POWER. The assigned value should be a nonnegative double-precision floating-point number. No other results are required. Syntaxrequirements for this stage are specified by the following procedure template:

voidrx_antenna_gain_template (Packet* pk)


/* perform calculation of rx antenna gain. */

/* place result in TDA to make available for later stages. */op_td_set_dbl (pk, OPC_TDA_RA_RX_GAIN, result);}

Template for Radio Transceiver Pipeline: Receiver Antenna Gain Stage

464-Comec


Comec.4.5.10 Stage 8: Background Noise

The background noise stage is the ninth stage of the radio transceiver pipeline,and is specified by the bkgnoise model attribute of the radio receiver. It isexecuted immediately after return of the received power stage, with no simulationtime elapsing in between. The purpose of this stage is to represent the effect of allnoise sources, except for other concurrently arriving transmissions, since these areaccounted for by the interference noise stage. The expected result is the sum of thepower of other noise sources, measured at the receiver’s location and in thereceiver channel’s band. Typical background noise sources include thermal orgalactic noise, emissions from neighboring electronics, and otherwise unmodeledradio transmissions (e.g., commercial radio, amateur radio, television, dependingon frequency).

The Simulation Kernel does not itself make use of the result of this stage, but itdoes reserve a TDA, represented by the symbolic constant OPC_TDA_RA_BKGNOISE,for the purpose of storing the result and communicating it to later pipeline stages.Normally, the background noise value is later added to other noise sources tocompute a total noise level in the signal-to-noise ratio stage. The Kernel requiresthat the background noise stage procedure accept a packet address as its soleargument. Syntax requirements for this stage are specified by the followingprocedure template:

voidreceived_power (Packet* pk)


/* perform calculation of received power (in watts). */

/* place result in TDA for Kernel & later stages. */op_td_set_dbl (pk, OPC_TDA_RA_RCVD_POWER, result);}

Template for Radio Transceiver Pipeline: Received Power Stage

465-Comec


om

mu

nicatio

n

Mech

anism

s

Comec.4.5.11 Stage 9: Interference Noise

The interference noise stage is the tenth stage of the radio transceiver pipeline,and is specified by the inoise model attribute of the radio receiver. It may beexecuted for a packet under two circumstances: the packet is valid and arrives at itsdestination channel while another packet is already being received; or the packet isvalid and already being received when another packet (valid or invalid) arrives.Clearly, the first circumstance can occur at most once for each packet, and thesecond may occur any number of times depending upon the transmission activitiesof other transmitters in the model. Note that a single invocation of this stage can beshared by the pipelines of the two packets if both are valid (the call syntaxappearing below provides the addresses of both packets to the interference stage sothat mutual effects can be evaluated).

The purpose of this stage is to account for the interactions betweentransmissions that arrive concurrently at the same receiver channel. The SimulationKernel reserves a TDA, represented by the symbolic constantOPC_TDA_RA_NOISE_ACCUM, for the purpose of storing the current level of noisefrom all interfering transmissions. This accumulator is maintained only for validpackets (as determined by the channel match stage) since there is generally noneed to evaluate link quality for noise packets. Thus, the interference noise stage isexpected to augment the value of this accumulator in each valid packet by thereceived power of the interfering packet. When a packet (valid or invalid)completes reception, the Kernel automatically subtracts its received power fromthe noise accumulator of all valid packets that are still arriving at the channel. Inthis manner, the accumulator reflects only the current noise level.

The Kernel requires that the interference noise stage procedure accept twopacket addresses as arguments. The first packet address represents the packet thatarrived earliest, and the second represents the new arrival that caused the stage tobe invoked. Syntax requirements for this stage are specified by the followingprocedure template:

voidbkg_noise_template (Packet* pk)


/* perform calculation of background noise power (in watts). */

/* place result in TDA to make available to later stages. */op_td_set_dbl (pk, OPC_TDA_RA_BKGNOISE, result);}

Template for Radio Transceiver Pipeline: Background Noise Stage

466-Comec


In addition to the OPC_TDA_RA_NOISE_ACCUM TDA, the Kernel provides a TDAto keep track of the number of collisions experienced by each packet. This TDA isrepresented by the symbolic constant OPC_TDA_RA_NUM_COLLS and is provided forconvenience in developing application-specific pipeline stages that may have aneed for this result when deciding whether to accept or reject a packet in the finalstages of the pipeline. Although the interference stage is an appropriate location toupdate this TDA’s value, the Kernel makes no use of this TDA and it is thereforenot mandatory to maintain its accuracy.

Comec.4.5.12 Stage 10: Signal-to-Noise Ratio

The signal-to-noise ratio (SNR) stage is the eleventh stage of the radiotransceiver pipeline, and is specified by the snr model attribute of the radioreceiver. It may be executed for a valid packet (as determined by the channel matchstage) under three circumstances: (1) the packet arrives at its destination channel;or (2) the packet is already being received and another packet (valid or invalid)arrives; or (3) the packet is already being received and another packet (valid orinvalid) completes reception. Clearly, the first circumstance occurs exactly oncefor each packet, and the second and third may occur any number of timesdepending upon the transmission activities of other transmitters in the model. Thethree types of invocations define intervals over which a packet’s average power

voidinterference_noise_template (Packet* earlier_pk, Packet* later_pk)

{int e_status, l_status;double e_power, l_power;

/* extract match status and received power from each packet */e_status = op_td_get_int (earlier_pk, OPC_TDA_RA_MATCH_STATUS);e_power = op_td_get_dbl (earlier_pk, OPC_TDA_RCVD_POWER);l_status = op_td_get_int (later_pk, OPC_TDA_RA_MATCH_STATUS);l_power = op_td_get_dbl (later_pk, OPC_TDA_RCVD_POWER);

/* if earlier packet is valid, augment noise accumulator */if (e_status == OPC_TDA_RA_MATCH_VALID)

op_td_set_dbl (earlier_pk, OPC_TDA_RA_NOISE_ACCUM,op_td_get_dbl (earlier_pk, OPC_TDA_RA_NOISE_ACCUM) + l_power);

/* Similarly, if earlier packet is valid, *//* augment its noise accumulator */if (l_status == OPC_TDA_RA_MATCH_VALID)

op_td_set_dbl (later_pk, OPC_TDA_RA_NOISE_ACCUM,op_td_get_dbl (later_pk, OPC_TDA_RA_NOISE_ACCUM) +

e_power);}

Template for Radio Transceiver Pipeline: Interference Noise Stage

467-Comec


om

mu

nicatio

n

Mech

anism

s

SNR is taken to be constant (of course, this is an approximation when mobility isinvolved, since SNR would be continuously varying).

The purpose of SNR stage is to compute the current average power SNR resultfor the arriving packet. This calculation is usually based on values obtained duringearlier stages, including received power, background noise, and interference noise.The SNR of the packet is an important performance measure that supportsdetermination of the receiver’s ability to correctly receive the packet’s content. Theresult computed by this stage is used by the Kernel to update standard outputresults of receiver channels and usually also by later stages of the pipeline.

The Simulation Kernel requires that the SNR stage procedure accept a packetaddress as its sole argument. The computed SNR is then expected by the Kernelwithin the TDA represented by the symbolic constant OPC_TDA_RA_SNR. Theassigned value should be a double-precision floating-point number expressed indecibels (dB). No other results are required. Syntax requirements for this stage arespecified by the following procedure template:

Comec.4.5.13 Stage 11: Bit Error Rate

The bit error rate (BER) stage is the twelfth stage of the radio transceiverpipeline, and is specified by the ber model attribute of the radio receiver. It may beexecuted for a valid packet (as determined by the channel match stage) under threecircumstances: (1) the packet completes reception at its destination channel, or(2) the packet is already being received and another packet (valid or invalid)arrives, or (3) the packet is already being received and another packet (valid orinvalid) completes reception. These circumstances correspond to the ends ofperiods during which the packet’s SNR is taken to be constant. (For moreinformation on constant-SNR intervals, refer to section Comec.4.5.12 Stage 10:Signal-to-Noise Ratio.)

The purpose of the BER stage is to derive the probability of bit errors duringthe past interval of constant SNR. This is not the empirical rate of bit errors, but the

voidsnr_template (Packet* pk)


/* perform calculation of average-power SNR (in dB). */

/* place result in TDA to make available to Kernel & later stages. */op_td_set_dbl (pk, OPC_TDA_RA_SNR, result);}

Template for Radio Transceiver Pipeline: Signal-to-Noise Ratio Stage

468-Comec


expected rate, usually based on the SNR. In general, the bit error rate provided bythis stage is also a function of the type of modulation used for the transmittedsignal.

The Simulation Kernel requires that the BER stage procedure accept a packetaddress as its sole argument. The computed BER is then expected by the Kernelwithin the TDA represented by the symbolic constant OPC_TDA_RA_BER. Theassigned value should double-precision floating-point number between zero andone (inclusive). No other results are required. Syntax requirements for this stageare specified by the following procedure template:


The error allocation stage is the thirteenth stage of the radio transceiverpipeline, and is specified by the error model attribute of the radio receiver. It isalways executed immediately upon return from the bit error rate stage. Thepurpose of the error allocation stage is to estimate the number of bit errors in apacket segment where the bit error probability has been calculated and is constant.This segment may be the entire packet, if no changes in bit error probability occurover the course of the packet’s reception. Bit error count estimation is usuallybased on the bit error probability (obtained from stage 11) and the length of theaffected segment.

The Simulation Kernel requires that the error allocation stage procedure accepta packet address as its sole argument. The Kernel maintains only a bit erroraccumulator TDA within the packet; therefore, the pipeline stage is expected toadd the number of new errors into the existing value found in the integer TDArepresented by the symbolic constant OPC_TDA_RA_NUM_ERRORS. The added valueshould be between zero and the number of bits in the affected packet segment. Inaddition, the Kernel expects the error allocation stage to provide the empirical bit-error-rate over the packet segment; this value is obtained by dividing the number ofbit errors in the segment by the size of the segment. The empirical bit error rateshould be placed in the double-precision TDA represented by the symbolic

voidber_template (Packet* pk)


/* perform calculation of bit-error-rate. */

/* place result in TDA for Kernel & later stages. */op_td_set_dbl (pk, OPC_TDA_RA_BER, result);}

Template for Radio Transceiver Pipeline: Bit-Error-Rate Stage

469-Comec


om

mu

nicatio

n

Mech

anism

s

constant OPC_TDA_RA_ACTUAL_BER. The Kernel uses this value to update the biterror rate result of the receiver channel object. Syntax requirements for the errorallocations stage are specified by the following procedure template:


The error correction stage is the fourteenth and final stage of the pipeline, andis specified by the ecc model attribute of the radio receiver. It is invoked when apacket completes reception, immediately after the final return of the errorallocation stage, with no simulation time elapsing in between. Exactly oneinvocation of this stage occurs for each packet that is considered valid (asdetermined by the channel match stage). The purpose of this stage is to determinewhether or not the arriving packet can be accepted and forwarded via the channel’scorresponding output stream to one of the receiver’s neighboring modules in thedestination node. This is usually dependent upon whether the packet hasexperienced collisions, the result computed in the error allocation stage, and theability of the receiver to correct the errors affecting the packet (hence the name ofthe stage). Based on the determination of this stage, the Kernel will either destroythe packet, or allow it to proceed into the destination node. In addition, this resultaffects error and throughput results collected for the receiver channel.

The Simulation Kernel requires that the error correction stage procedure accepta packet address as its sole argument. The determination to accept or reject thepacket is then expected by the Kernel within the TDA represented by the symbolicconstant OPC_TDA_RA_PK_ACCEPT. The assigned value should be an integer equalto the constant OPC_TRUE to indicate acceptance; otherwise the integer valueOPC_FALSE should be assigned to indicate rejection. No other results are required.

voiderr_alloc_template (Packet* pk)

{int num_added_errs, segment_length;double empirical_ber;

/* extract required information from packet. */

/* perform calculation of number of bit errors in segment. */

/* Add errors to bit-error accumulator. */op_td_set_int (pk, OPC_TDA_RA_NUM_ERRORS,

op_td_get_int (pk, OPC_TDA_RA_NUM_ERRORS) + num_added_errs);

op_td_set_dbl (pk, OPC_TDA_RA_ACTUAL_BER,num_added_errs / segment_length);

}

Template for Radio Transceiver Pipeline: Error Allocation Stage

470-Comec

Using Paths to Represent Virtual Circuits Modeling Concepts

Interface requirements for this stage are specified by the following proceduretemplate:

Comec.5 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 protocolmodels determine exactly when and how to use a particular path. Refer to therelevant model documentation for information on how particular models utilizepaths.

A path is a defined route between two sites; a site can be either a fixed nodeobject or subnetwork. The process of defining a path is similar—though notidentical—to defining a link. First you configure an object palette to include thepath models you want (as described the System Menus chapter of the EditorReference manual), then you select a model and click on objects in the ProjectEditor workspace to connect them.

Comec.5.1 Path Model Options

Each path model has a set of options that determine the path connectivityrequirements and the types of objects that you can include in a path definition. Youcan view a model’s options in the Path Model Description dialog box, which youopen by right-clicking on a model in the object palette. You should verify that theunderlying model’s options allow you to create the type of path you want. If youcannot find a path model whose options exactly match the type of path you want tocreate, you may want to derive a new model from an existing one.




/* place result in TDA to return to Simulation Kernel. */op_td_set_int (pk, OPC_TDA_RA_PK_ACCEPT, result);}

Template for Radio Transceiver Pipeline: Error Correction Stage

471-Comec

Modeling Concepts Using Paths to Represent Virtual CircuitsC

om

mu

nicatio

n

Mech

anism

s

Path Connectivity

A path object defines, at the very least, two end sites. It may also define apartial or complete path (that is, a set of connecting sites and links) between thesesites. The Path Connectivity option defines the extent to which you can define thisintermediate path. The three possible settings are:

• Links Required—In a required-link path, you must specify a simplexor duplex point-to-point link between every site included in the path; allsuch links are included in the path definition.

• Links Ignored—In an ignored-link path, you can only include sites inthe path definition. The underlying models fully determine routes be-tween the included sites.

• Links Optional—This is a combination of the required-link and ig-nored-link types. You must define the head, tail and any intermediatesites, but defining any connecting links between sites is optional.

The following diagram shows a router network connecting a site in Canada toone in Texas. Traffic constrained by the required-link path (left) always follows theexact route defined between Canada and Texas. If the ignored-link path (center)defines a route, the underlying models fully route any traffic using this path. Theoptional-link path (right) defines a partial route that includes the link betweenCanada and router E; the underlying models route the traffic between router E andTexas.

path options

Path Model Description Dialog Box

472-Comec


Keep in mind that in a situation like this, with multiple paths defined betweenthe same two sites, the underlying models choose the actual path taken by a packet.

Other Path Options

Other 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 that link supportsall formats included in the path model’s Packet Formats field. (Note thatif a path supports no packet formats, you can include any link in thepath definition.)

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

• Subnets Ignored—If this option is set to Yes, you cannot include a sub-network object in a path definition. (However, you can still includenodes from different subnets in the same path.)

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

Creating a Path Object

To create a path between two sites...

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

473-Comec

Modeling Concepts Using Paths to Represent Virtual CircuitsC

om

mu

nicatio

n

Mech

anism

s

A path object’s underlying options (described in Path Model Options onpage 470) determine the objects you can and cannot include in your pathdefinition. Once you are in path-creation mode, OPNET Modeler providesextensive visual feedback to indicate valid and invalid additions to yourpath. If you move the cursor over an invalid link or site, the cursor changesappearance and a tooltip appears to indicate why that choice is invalid.

3) Left-click on the site you want to define as the head of your path.

4) (Required-link and optional-link paths only): Left-click on any sites and linksthat you want to include in your path.

Note that you must click on a link to include it in the path definition if

• You are defining an links-optional path;

• You are defining a links-required path, and want to include two sitesthat have multiple links connecting them.

5) Repeat step 4 until you have clicked on the tail site and the path definition iscomplete.

6) Right-click in the project workspace and choose Finish Path Definition fromthe pop-up menu. OPNET Modeler auto-assigns a unique name to the newpath.

Feedback for invalid objects

Visual Feedback in Path-Creation Mode

Feedback for valid objects

474-Comec


Note: When you finish defining a path, you are still in path-definition mode.You can create another path (based on the same underlying model) by repeat-ing steps 3 through 7. To exit path-definition node, right-click and choose AbortPath Definition from the pop-up menu.

Documents

Chapter 6 Communication Mechanisms - LUMSsuraj.lums.edu.pk/~te/simandmod/Opnet/06 Communication mechanisms.pdf · OPNET provides several communication mechanisms to address the range