Chapter 6 Communication Mechanisms

Transcription

1 Chapter 6 Communication Mechanisms 395-Comec

2 396-Comec Modeling Concepts

3 Modeling Concepts Introduction Comec.1 Introduction Most OPNET models can be classified as distributed systems composed of multiple subsystems that interact with each other. The subsystems interactions rely on communications resources to support exchanges such as commands, queries, and general information. Communication may be required between subsystems that are physically distinct as well as between those that are logically separated based on their functional areas. OPNET provides several communication mechanisms to address the range of needs required by sophisticated applications; this chapter discusses each of the supported forms of communication and their applicability to various modeling situations. Communication Mechanisms Comec.2 Comec.2.1 Packet-Based Communications The most prevalent form of communications in OPNET models is based on the general notion of messages that can carry information and be sent between subsystems. 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 general messages, or transfer of information. General Properties of Packets Packets are data structures defined by the OPNET environment in order to support message-oriented communications. Each packet exists as an individual structure 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 Packet Structure Each packet contains several information storage areas. The first and most frequently used area consists of a list of fields which provide storage for userdefined information. Packets may be formatted or unformatted. A formatted packet allows 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 a packet is formatted or unformatted, its fields may be used to store information of various types: integer and double fields store numerical data; packet fields allow the encapsulation of a packet within another; structure fields allow the inclusion of a user-defined data-structure within a packet. In addition to fields, all packets contain predefined information such as priority assignments, and time and place of creation. A third storage area is dedicated to storing information that supports the modeling of packet transmission over communication links. For a discussion of packet structure, refer to the Modeling Overview chapter of the Modeling Concepts manual. 397-Comec

4 Packet-Based Communications Modeling Concepts Comec Packet Size In addition to their information content, fields have an assigned size in terms of bits. The size of all the assigned fields in a packet plus a base value known as the packet s bulk data size determine the packet s overall size. This is not the size of the 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 Packet Ownership Packets are treated essentially as physical objects, which implies that each one can exist in only one location at a given time. Therefore when a packet is sent, the entity that sends it loses access to the packet. The entity that has control of a packet is referred to as the packet s owner. Generally, modules or packet streams are the owners 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 the KPs op_pk_nfd_get() or op_pk_fd_get() The packet may be received via an input stream and acquired with the KP op_pk_get() A packet stream simply obtains ownership of a packet when its source module uses 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(). Ownership is 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 Kernel when a packet is accessible to no simulation objects; and a special abstract form of ownership called universal is reserved for packets that have been affected by the mechanism 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 one physical or logical context. Instead, they are almost always created dynamically to allow information to be transferred between contexts. The OPNET Simulation Kernel offers several mechanisms to support packet-based communication. One or more of these mechanisms may be appropriate, depending upon the relationship 398-Comec

5 Modeling Concepts Packet-Based Communications Comec between the context that initiates the transfer and the context that receives the packet. Packet Streams Packet streams are physical connections that support the transfer of packets between modules within the same node. Packet streams are defined between an output port of a source module and an input port of a destination module. These ports are usually referred to as the source module s output stream and the destination module s input stream, respectively. Communication Mechanisms Each module may have an unlimited number of input streams and an unlimited number of output streams. Fan-in and fan-out are not allowed; that is, each input stream can be the recipient of only one packet stream object, and each output stream can be the source of only one packet stream object. However, any or all input and output streams may be left unconnected. Queuing at the Input Stream Each packet stream contains a single queue for packets; this queue is associated with the destination module s input stream in order to allow packets to wait 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 packet stream s queue can hold. The packets are maintained in the order in which they arrive, and since the destination module can only obtain the head of this queue (by calling the KP op_pk_get()), the queue can be considered first-in-first-out (FIFO). Queuing in Packet Streams Delays associated with packet transfer must elapse before packet enters input stream queue T source destination Each input stream queues arriving packets and releases them to the destination in FIFO order when op_pk_get() is called Interrupt Methods If a packet stream s source module is a processor or a queue, it may send packets that it owns to the packet stream s destination module by calling any of the four variants of the KP op_pk_send(). Each of these KPs implements the transfer with a slightly different behavior, as explained below. 399-Comec

6 Packet-Based Communications Modeling Concepts op_pk_send(): This form of packet transfer is referred to as standard packet sending, because it is the most commonly used. A call to op_pk_send() results in the scheduling of a stream event for the destination module in order to indicate the arrival of a new packet; the time of 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 the default), the stream event is scheduled for the current time. Note that module priorities throughout the system, and interrupt priorities at the destination module, affect the execution order of this event relative to others scheduled for the same time. Immediately prior to generating a stream interrupt for one of the processes in the destination module, the Simulation Kernel inserts the transferred packet at the tail of the input stream s queue. If there are no other packets queued at that time, then the destination process may obtain the packet with a single call to op_pk_get(); otherwise, multiple calls to this KP are required to obtain the packet. At its option, the destination process may also choose to ignore the new arrival and leave it in the input stream s queue. Note that if the interrupt cannot be delivered to a destination process, the packet is still queued, allowing it to be obtained at a later time. op_pk_send_delayed(): This form is similar to standard packet sending in that it also makes use of event scheduling and generates an interrupt for an appropriate process in the destination module. However, the KP op_pk_send_delayed() supports the specification of a positive delay value that postpones the arrival of the packet at the destination s input stream for an additional amount of time. The stream event representing the arrival of the transferred packet at the destination occurs at the current time added to the sum of the specified delay and the value of the packet stream s delay attribute. All other aspects of this form of packet transfer are identical to those obtained by using op_pk_send(). Note that since op_pk_send_delayed() allows the delay value to be set independently on each call, the order of packet arrivals at the destination of a given stream may not match the order in which packets are sent using this KP. op_pk_send_forced(): This form of packet transfer does not make use of event scheduling. Instead it causes the sending process to be suspended and immediately queues the packet in the input stream and generates an event for the destination module. The packet remains queued regardless of whether the event results in one of the destination module s processes receiving an interrupt. No delays are possible in forced packet transfers, so the packet stream s delay attribute is ignored. Note that the sending process resumes execution only after the destination process blocks. For a description of the general behavior of forced events, refer to the Modeling Framework chapter of Modeling Concepts. 400-Comec

7 Modeling Concepts Packet-Based Communications op_pk_send_quiet(): This form of packet transfer is used to avoid the generation 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 transferred packet at the end of the packet stream s queue. The packet is inserted into the queue on an immediate basis (i.e., this action is not scheduled and 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 access interrupt in order to immediately forward a packet in response. The KP op_pk_send_forced() cannot be used in this situation since it would result in a forced event feedback loop between the source and destination modules; this is due to the fact that access interrupts, generated by the KP op_strm_access(), are also forced interrupts. Communication Mechanisms This KP is also sometimes used as a device to reduce the total number of interrupts due to packet transfers. The general technique employed for 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 interrupted as a result of the last packet transfer then determines the number of packets contained in its input stream(s) by calling op_strm_empty() and op_strm_pksize(). This process can use this information to decide whether to extract some or all of the transferred packets. Each packet stream has an attribute called intrpt method that can affect the form of packet transfers that it supports. This attribute is only considered when the packet stream source is a module other than a processor or queue. The attribute can specify a scheduled, forced, or quiet interrupt method. If scheduled is selected, then packet transfers behave as in the case of op_pk_send() and op_pk_send_delayed(), with a possible delay value specified in the stream s delay attribute; if forced is selected, then the packet stream behaves as though a process were forwarding packets using op_pk_send_forced(). Finally, if the interrupt method is quiet, the packet stream behaves as though a process were forwarding packets using op_pk_send_quiet(). 401-Comec

8 Packet-Based Communications Modeling Concepts 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 Comec Packet Delivery Packet streams support communication only between modules within the same node. If modules use only this means of transferring packets then transmitters and receivers must be relied upon to convey packets between nodes. However, in some cases, it is not convenient to connect all nodes that directly transfer packets to each other. In addition, certain systems in which communicating nodes would rely on intermediate nodes to relay packets may sometimes be accurately and more simply modeled by abstractly allowing direct communications, even though no physical connections exist. In order to support modeling of such systems, OPNET provides a mechanism referred to as packet delivery, that allows any processor or queue module to directly transfer packets to any other processor or queue module, regardless of physical location. Packet Delivery Between Modules in Unconnected Nodes source Packets may be delivered to modules in other nodes without any physical connections existing between the nodes destination 402-Comec

9 Modeling Concepts Packet-Based Communications Packet Delivery Mechanics With respect to the destination side of the mechanism, packet delivery operates similarly to packet sending via streams. In other words, packets are inserted into the queue of an input stream of a destination module, and depending on the selected interrupt method, an event may be generated. In order to initiate a packet delivery, a process may call any of the KPs op_pk_deliver(), op_pk_deliver_delayed(), op_pk_deliver_forced(), and op_pk_deliver_quiet(). The desired interrupt method can be specified by using the appropriate KP. The four delivery KPs have the same behavior as the correspondingly named stream-based KPs discussed in the previous section. Communication Mechanisms Since the destination module is not implicitly related to the source module, as in the case of packet streams, it must be explicitly designated when a packet delivery is initiated. The destination module s object ID is therefore expected by each of the KPs that support packet delivery. A number of methods exist for determining the object ID s of destination modules; these methods are supported by the KPs of the Id and Topo packages of the Simulation Kernel. Similarly, the input stream to which a packet will be delivered must be specified explicitly at the time where the delivery is requested. Input streams are identified 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 highest connected input stream causes the allocation of memory for every intermediate index; while the amount of memory per index is small, the total allocation can be large 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, a single source may also deliver packets to multiple input streams. Fan-In and Fan-Out of Packet Delivery Mechanism dest0 source0 dest1 source1 dest2 Single input stream of a module may receive packet deliveries from multiple sources. 403-Comec

10 Packet-Based Communications Modeling Concepts Comec Communication Links Once a packet is created by a module, it may be transferred to another module in the same node; that module may in turn transfer it to a third module in the same node. In many cases however, the packet must ultimately be transmitted to modules in other nodes. The previous section described the use of packet delivery as a means of transferring packets between nodes. Packet delivery is an abstract representation of a physical link which may be useful when the existence of links cannot be known in advance or when actual physical characteristics of the links are not required for simulation accuracy. OPNET also supports a more direct representation of physical links with three types of communication link models referred 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 of nodes. 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 in another; and duplex point-to-point links, which connect a transmitter-receiver pair in one node to a transmitter-receiver pair in another. A duplex link acts as two simplex links that run in opposite directions. Equivalent Duplex and Simplex Point-to-Point Link Configurations Duplex Link Simplex Links For a point-to-point link to be operable, it must be attached to point-to-point transmitters and receivers in the nodes that it connects. The transmitter(s) and receiver(s) of a simplex point-to-point link are designated using its transmitter and receiver object attributes; for duplex links, four attributes, transmitter a, receiver a, transmitter b, and receiver b, serve to identify the modules within the nodes to which the link is attached. The transceiver modules are important from a modeling point-of-view because they represent the exit and entry points for packets in the transmitting and receiving nodes respectively. In other words, a transmitter module can be viewed as the gateway for packets departing to a remote node. In order to send a packet to a remote node attached by a point-topoint link, a module can simply send the packet the appropriate point-to-point transmitter module within its own node; the transmitter then provides the service 404-Comec

11 Modeling Concepts Packet-Based Communications of transporting the packet to the receiver at the other end of the attached point-topoint link. Transmitters and Receivers Act as Gateways to/from other Nodes Communication Mechanisms Each point-to-point link can be thought of as a bundle representing one or more communication channels between the transmitter(s) and receiver(s) that it connects. The number of channels in a link is determined by the channel count attributes of the connected transmitter and receiver objects. Each channel acts independently of the other channels in the same link, as though it were defined in a separate and parallel simplex link. However, the ability to bundle channels together is 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 a point-to-point transmitter in a source node and a port of a point-to-point receiver in a destination node. Ports are referenced by numerical index and correspond directly to the input streams and output streams for transmitters and receivers respectively. In other words, a packet can be transmitted using the n-th channel of a link by sending that packet into the n-th input stream of the transmitter at the link s source. At the link s destination, arriving packets are issued by the receiver on its n-th output stream. The following diagram illustrates the flow of packets. Correspondence between Input Streams, Channels, and Output Streams input stream 0 input stream 1 input stream 2 input stream 3 channel 0 channel 1 channel 2 channel 3 output stream 0 output stream 1 output stream 2 output stream 3 Each channel incorporates a simple first-in-first-out queue on its transmitting side. The purpose of the queue is to regulate transmissions in a channel so that the content of only one packet is being transmitted at any given time. Since a packet generally requires a nonzero amount of time to transmit, other packets that arrived 405-Comec

12 Packet-Based Communications Modeling Concepts later must wait until its transmission has completed before theirs can begin. Because the FIFO queue has no holding capacity limitation, this mechanism allows packets to be forwarded to a transmitter module s input stream at an arbitrary rate, while still respecting the proper timing for individual transmissions. Built-in Queuing of Transmitter Channels 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 Bus Links Both types of point-to-point links can be configured to affect packet transmission in several ways. Underlying each link is a series of user-definable models called pipeline stages. In general, the pipeline stages perform computations related to the transmission of a packet in order to decide the time of reception and whether or not a packet is received correctly. The complete operation and 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 in performing the computations that are required of them. In particular, most pipeline stage implementations use the point-to-point link attributes, ber and delay, which are defined to represent the probability of a bit being received in error, and the propagation delay for a signal on the link, respectively. In addition, the data rate attribute of a channel object is usually taken into account by one or more of the pipeline stages. Bus links allow a single packet transmission to automatically propagate to multiple destinations. These types of links are generally used to represent local area networks, computer busses, or other broadcast-based networks. In addition, because packet broadcasting can be constrained to a subset of the nodes attached to the bus, and even to a single destination, bus links can be used to represent networks with a high degree of connectivity or with a dynamic connectivity that would otherwise be difficult to represent using point-to-point links. As with point-to-point links, nodes attach to bus links via dedicated transmitter and receiver modules. In this case, bus transmitter and bus receiver modules must be used. Attachments are formed by using a third object, called a tap, to connect 406-Comec

13 Modeling Concepts Packet-Based Communications the node to the link. A tap has a transmitter attribute and a receiver attribute that must be used to designate the transceivers within the node. Most taps have both the transmitter and receiver attributes set to a nonempty 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 can actually be assigned) in order to create a unidirectional tap. If only the receiver name is assigned, the tap is referred to as receive-only; if only the transmitter name is assigned, the tap is called transmit-only. Receive-only taps are sometimes used to monitor the status of the bus link to learn about the activities of other nodes, or to collect results. Transmit-only taps can be used, for example, by a controller node that periodically emits a synchronization signal and has no need to receive information from other nodes. Communication Mechanisms Depending on whether taps are configured as receive-only, transmit-only, or bidirectional, they are drawn differently in the Network Editor where they are defined. The following diagrams depict the four possible representations (it is possible, though not useful, to have a tap with no transmit or receive capability). Bus Tap Configurations Unused Transmit-Only Receive-Only Duplex A transmitted packet can propagate simultaneously in both directions on a bus link. The physical distances between nodes may be factored into the computation of arrival times at the various receivers. This calculation is generally also based on the delay attribute of the bus link, which represents the time in seconds required for the signal to propagate a distance of one meter. Thus, a single packet transmission 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 separate channels, bus links can also act as many independent broadcast mediums. The number of channels in a bus link is determined by the channel count attributes of the attached bus transmitter and bus receiver modules. When a packet is transmitted on the n-th channel of a bus transmitter, it is received by all bus receivers attached to the bus that have a sufficient channel count (i.e., channel count > n, since channel indices begin at zero). Receivers that have an insufficient number of channels are not affected by the transmission. Those receivers that are affected and that receive the packet correctly issue the packet to a neighboring module via their n-th output stream. 407-Comec

14 Packet-Based Communications Modeling Concepts With respect to transmission of packets, bus link channels behave identically to point-to-point link channels. In other words, each channel incorporates an unlimited-capacity queue that can accept packets at any rate, and packets are then transmitted one at a time onto the bus link. When a packet is transmitted, each of the eligible receivers is sent a distinct copy of the packet. This allows each receiver to make an independent determination with regard to the correct reception of the packet. In addition, if the packets are received correctly by multiple receivers, then the distinct copies can be operated upon (e.g., modified, destroyed, resent) without affecting each other. The following diagram illustrates the packet replication associated with broadcasting on a bus link. Replication of Transmitted Packet on a Bus Link copy 4 copy 3 copy 2 copy 0 original transmitted packet copy 1 A packet will also be sent to the same node that transmitted the original packet, if the bus tap is duplex Bus links support the notion of a collision which corresponds to the simultaneous presence of two or more arriving packets at the same bus receiver and on the same channel. Since, in general, packets take a nonzero amount of time to transmit and to receive (i.e., time measured from the transmission of the first bit to the transmission of the last bit), a packet can be considered to be arriving at a receiver during a finite interval. If another packet begins arriving before the completion of another packet s reception interval, the two packets are considered to have collided. The bus receiver channel remains in a collided state until one of the packets completes its reception interval, leaving only one other packet present. Since packet collisions take place at the receiver, propagation delays and relative positions of nodes on the bus link can play a role in determining whether they 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 and collisions are only determined when packets arrive, not when they are sent. In general, collisions are considered as destructive events that prevent the correct reception of either packet involved. This is the default behavior provided 408-Comec

15 Modeling Concepts Packet-Based Communications for the bus link. However, like point-to-point links, the behavior of bus links can be customized by modifying the underlying models or pipeline stages. These can be configured to interpret collisions differently; for example, a collision may be considered to not have a destructive effect if its total duration is less than a defined threshold. The general theory and use of bus link pipeline stages are discussed in a later section of this chapter. Consistency of Physical Links Communication Mechanisms Not all links that are placed between nodes are necessarily valid. OPNET considers only certain links to be properly configured and usable for the transfer of packets. A valid point-to-point or bus link is said to be consistent; an invalid pointto-point or bus link is called inconsistent. Inconsistent links do not support packet flow during simulation. In order to determine consistency of each link, OPNET uses pre-defined criteria that are applied to the link object, and the transceiver objects that are assigned to the link, on each end if applicable. Consistency relates to compatibility of the components that form the connection: these include transmission data rate, supported protocols, and numbers of supported channels. For an in-depth explanation of how link consistency is evaluated, refer to the Network 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 type of 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 and point-to-point counterparts. This corresponds to the actual behavior of radio links where communication may be established between some or all of the parties in a system on a dynamic basis. The ability to dynamically create a link between a transmitter and a receiver may be dependent on many physical characteristics of the components involved, as well as time-varying parameters. In OPNET simulations, parameters such as frequency band, modulation type, transmitter power, distance, and antenna directionality are commonly factored into the determination of whether a link exists or not at a particular time. 409-Comec

16 Packet-Based Communications Modeling Concepts Dynamic Establishment of Radio Links between Mobile Nodes 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. From the perspective of the modules within a node, radio links are used in the same manner as point-to-point and bus links. In other words, if a module wishes to send a packet via a radio link, it must send the packet to one of the input streams of a radio transmitter. The radio transmitter is then responsible for sending the packet to radio receivers in remote nodes. These radio receivers in turn issue correctly received packets on appropriate output streams. Like a bus or point-to-point transmitter, a radio transmitter maintains a channel object for each of its input streams and each channel contains a queue where submitted packets wait for previous packets to complete transmission. However, whereas bus and point-to-point transmitter channels have primarily a logical significance, radio transmitter channels also have a physical significance that is described by an additional set of attributes. These additional attributes serve to characterize the radio channel in terms of the frequency band that it occupies, the power that is applied to transmissions, the data rate of transmission, and an optional code used to identify a spread spectrum sequence. Radio channels are referred to by integer indices in order to establish a correspondence 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, packets correctly received by a radio receiver on channel i are sent to a neighboring module using output stream i. However, the index-based correspondence does not necessarily hold across radio links. That is, a packet transmitted using channel i may be received on a channel with index other than i. This is due to the fact that radio links are established between channels based on their attributes as opposed to their logical index. The actual establishment of a link is decided upon by userdefinable radio link models and may be dependent upon a number of transmitter and receiver attributes as well as other factors. For example, a simple link model 410-Comec

17 Modeling Concepts Packet-Based Communications may require only that the frequency bands of a transmitter channel and receiver channel overlap in order to establish a link; a link would exist regardless of whether the channels had the same index. Radio Link Channel Correspondence Communication Mechanisms stream 0 stream 1 stream 2 channel 0 channel 1 channel 2 A link established by radio does not necessarily relate channels of equal index. channel 0 channel 1 channel 2 stream 0 stream 1 stream 2 Like bus transmitters, radio transmitters transmit packets by broadcasting them. Therefore, packets are replicated for each selected destination in order to allow 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 may affect multiple channels within a radio receiver. Again, this is due to the fact that channels are compared on the basis of their physical characteristics, rather than their logical index values. The eligible receivers of each radio transmitter are not necessarily known in advance, as in the usual case of a bus configuration. Instead, the existence and quality of each link is generally computed on a dynamic basis to reflect potentially changing conditions in the network. Important events, such as position changes and interference, may have a significant impact on the ability of a transmitter channel and a receiver channel to communicate, and these events may occur at any time. The detailed behavior and mechanics of radio transmissions are specified in a series of low-level radio models, referred to as pipeline stages. The theory and operation of radio pipeline stages are discussed in detail in a later section of this chapter. Comec Link Model Definition As discussed earlier in this chapter, OPNET provides several types of links, each supporting a fundamentally different form of communications between two or 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 large numbers of objects. Link models are specified using the Link Editor. For more information on the Link Editor, refer to the Link Editor chapter in Editor Reference. 411-Comec

18 Packet-Based Communications Modeling Concepts As explained in the Modeling Framework chapter of Modeling Concepts., a model is a class definition which can be used to create instances that conform to particular 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 the specifications for a link s behavior are contained within a set of attributes. Attributes can specify characteristics such as the link s propagation delay, error rate, and the transceivers that it attaches to, if any. In addition, attributes are used to select a series of underlying C language procedures, called pipeline stages, which implement most of the computations and decisions made by a link. While the pipeline architecture is fixed for each type of link, user-defined pipeline procedures may be inserted into it in order to achieve customized link behavior (refer to later sections of this chapter for a detailed discussion of how the transceiver pipeline works). In other words, a link object s specification is controlled entirely via attributes, and therefore, a link model consists primarily of defining how these attributes should be configured. This is done via a specification mechanism called attribute interfaces, similar to the specification included in a node model. Attribute interfaces are briefly discussed in a link-specific manner in the following section. Comec Link Attribute Interfaces and Derived Link Models In this section we will briefly discuss how link model developers can use a mechanism called model attribute interfaces to exercise control over built-in link attributes, as well as to specify a variety of aspects of a link model s interface presented to the model user. The concepts that are discussed in this section are discussed in a more general and complete fashion in the Modeling Framework chapter of Modeling Concepts. The role of link attribute interfaces is to specify how a link model appears from the 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 which is called attribute interface descriptions. These are discussed in the following subsection; 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 no object-promoted attributes that can be passed to the link objects in the Project Domain. The role of attribute interface descriptions is therefore simpler for links than for nodes. In the case of links, the interfaces descriptions apply only to the built-in attributes of link objects. In other words, attributes such as the delay or data rate of a link can be controlled via this mechanism. Pipeline stage attributes, such as the txdel model (transmission delay model) can also be affected. Using the attribute interface descriptions component of the attribute interfaces, the link model developer can apply the following types of changes to the attributes that the link model offers: 412-Comec

19 Modeling Concepts Packet-Based Communications Control Provided by Link Attribute Interface Descriptions Mechanism a Attribute Renaming Description Provide a new name for an attribute as it is appears from the link model user s point of view. This is the name of the attribute as it is seen on a link object in the Network Domain. Communication Mechanisms Attribute Merging Attribute Properties Changes Attribute Status Changes Attribute Specification Replace a set of attributes with a single new attribute. The underlying attributes are tied together in the sense that changes to the new attribute are propagated to each of them. Certain attribute properties, including range, symbol map, comments, and default value can be altered. An attribute can be given one of three status values: promoted, set, or hidden. Promoted attributes appear on a link object without a value. Set attributes appear on the link object with a value chosen in advance by the link model developer; they can be changed on a perlink basis, however. Hidden attributes have a specified value, but are not visible on the link object, and therefore cannot be changed. OPNET allows you to change the default behavior when a user changes a link s attribute settings. You can specify a custom ETS library and event handlers by clicking the ETS Handlers button. See Active Attributes in the Application Development Concepts chapter of the External Programming Interfaces manual for details. a. For an in-depth discussion of the mechanisms discussed in this table (except attribute specification), refer to the Modeling Framework chapter of Modeling Concepts. 413-Comec

20 Packet-Based Communications Modeling Concepts 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. Additional Link Model Interfaces The Link Model Attribute Interfaces also regroup several other parts of a link s interface, though these are unrelated to attributes. These are summarized in the following table. For a detailed discussion, refer to the Modeling Framework chapter of Modeling Concepts. Additional Link Model Interfaces Keywords Interface Description Each link model can carry a set of keywords that are used to identify its relevance to particular network modeling efforts. Users of the Network Editor can specify keywords of interest in order to display only those models that are useful to them in the editor s Object Palette. 414-Comec

21 Modeling Concepts Packet-Based Communications Interface Comments Additional Link Model Interfaces (Cont.) Description A textual description of the link model allowing the link model developer to provide any desired information to the model user. Typically information in the comments includes: link model functionality (i.e., what sort of realworld link it represents); factors affecting link consistency; significance of major attributes, etc. Communication Mechanisms Supported Link Type Specifies whether the model is capable of being used for simplex point-to-point, duplex point-to-point, bus, bus tap, or any combination of these. Link Model Derivation In certain cases, link model developers, or even model users, will find that an existing link model has all of the capabilities that they require, but in addition provides too much flexibility to the model user. While providing extra capability may not seem like a problem, it may in fact be undesirable for a variety of reasons, which are presented in the following table. Reasons to Specialize a Link Model Problem Complexity can overwhelm end-user Flexibility can permit invalid configurations Details The more flexible and parameterized a model is, the more complex it is for an end-user to configure. In many cases, the parameters of a general model will not appear familiar to the end-user and the work required to configure it for each instance will exceed the end-user s knowledge. If attribute values can be specified in advance and match the user s requirements, then the link model will be significantly easier to deploy at the network level. The availability of many attributes may provide the opportunity for the user to create a link configured in an invalid manner. expects presenta- End-user particular tion The end-user of the link model typically expects a particular interface that matches his experience with similar real-world links or other models. If this interface can be realized, the model will be much more user-friendly. In these problem situations, users are seeking what we can refer to as a specialization of the link model. A specialized version of the link model is less general and flexible, but is tailored to the needs of a particular application, or at 415-Comec

22 Communicating with Interface Control Information Modeling Concepts least a more specific application than the original model. In order to create a specialization of a link model, OPNET provides a mechanism called Model Derivation. Model Derivation allows the mechanisms that are available in the Link Model Attribute Interfaces to be applied to an existing link model. The result of this operation is a new, more limited link model, called a derived model that depends on the original model, which is called the parent model. Refer to the Modeling Framework chapter of Modeling Concepts for more information on model derivation. Comec.3 Communicating with Interface Control Information Interface Control Information structures or ICIs are data objects that resemble packets in that they consist of a list of data items. However, ICIs are simpler data structures than packets since they contain storage only for user-defined values. In addition, 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 by multiple entities. Comec.3.1 Applications of ICIs In the broadest definition, an ICI is a list of user-defined data items that can be associated with an event. This capability allows information to be transferred from the context where an event is generated to the context where it later occurs. The two 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 at different times. Thus, an ICI can be viewed as playing a role in a communication mechanism between contexts, where an event provides the active notification, and the ICI provides the data payload that is transferred. For certain types of events that normally carry little or no user-defined information, ICIs provide an important enhancement in data transfer capability. These event types include: self: the only information inherently associated with this type of event is an integer code specified at the time that the KP op_intrpt_schedule_self() is called. However, since the event occurs at the same process that generates it, it is possible to store information in state variables for later retrieval. remote, process, and multicast: like the self interrupt, only an integer code is provided. In addition, state variables cannot be used since the destination process is different than the source process. access: no accompanying information is directly provided with this type of event. statistic: a single floating point value may be conveyed with this type of interrupt. 416-Comec

23 Modeling Concepts Communicating with Interface Control Information Because the ICI mechanism is not specific to any particular event type, it can be used in cases involving any of the above event types to transfer general amounts of user-defined data between contexts. ICIs are also commonly used with stream events, even though such events inherently convey packets which can contain general, user-defined information. The purpose generally served by an ICI in such cases is to associate additional parameters with a packet transfer while avoiding the use of the packet itself to contain these parameter values. A common reason for avoiding the use of the packet to carry such parameters is that the packet s format would then depart from an actual specification. This situation typically arises when a packet-based interface models a service that operates on packets in a manner that is affected by associated parameters; for instance, a packet may be submitted by a higher layer protocol to the next service layer which may require the designation of service class and destination. Communication Mechanisms Comec.3.2 ICI Content When an ICI is created using the KP op_ici_create(), the name of an ICI format must be supplied. An ICI format defines the structure of an ICI in terms of the attributes that it contains. Each attribute definition has three components: a name, a datatype, and a default value, as shown in the following ICI editor screen: ICI Format Specification Attribute names are used to make references to attributes within an ICI. In other words, the name of an attribute plays the same role as the name of a field in a 417-Comec

24 Communicating with Interface Control Information Modeling Concepts formatted packet. Operations that expect attribute names to be specified include setting, getting, and testing for the existence of attributes. An attribute s datatype determines what sort of information it can store. The supported types are integer, double, and structure. Integer and double datatypes store whole numbers and floating-point decimal numbers, respectively. Structure attributes contain memory addresses to support the communication of arbitrary user-defined data with ICIs. In general, these types of attributes are assigned memory addresses returned by the dynamic memory allocation KP op_prg_mem_alloc(), as shown in the example below. Note that, unlike structure addresses embedded in packet fields, structure addresses in ICI attributes are not automatically subjected to deallocation when their encompassing ICI is destroyed. Instead, deallocation, if appropriate, must be performed by user processes. Assignment of a Structure-Type ICI Attribute /* 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); When an ICI is initially created, integer and double attributes contain default values as specified in the ICIs format definition. Structure fields cannot be assigned default values since memory addresses cannot be known in advance. ICI attribute values can then be assigned by calling the KP op_ici_attr_set() which is applicable for all three types of attributes. Values for the three attribute types can also 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 a mechanism called ICI installation. Each process (a processor or queue module may 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 process may install other ICIs by calling the KP op_ici_install() and passing the address of the ICI of interest. An ICI remains installed until another takes its place. The Simulation Kernel automatically associates a process installed ICI with the events that the process generates. Since an ICI can remain installed after it has been associated with an event, it can also become associated with subsequent 418-Comec

25 Modeling Concepts Communicating with Interface Control Information events. In fact, the same installed ICI address will be associated with every event scheduled by a process, until it is replaced by another ICI. One way to avoid having unintended associations between ICIs and events is to restore the initial condition (i.e., no ICI is installed) after each event-scheduling action; this can be done 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 ICI with an event that does not make use of it is of no consequence. In other words, if the destination context of an event does not make use of an ICI, no adverse effect can result from the ICI simply being available. Communication Mechanisms Operations on ICIs ICIs are dynamic objects that must be created by processes that wish to associate 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 to the 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 capabilities provided by this package are summarized in the table below. In addition, a KP from 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 op_ici_attr_exists() op_ici_attr_get() op_ici_attr_set() op_ici_create() op_ici_destroy() op_ici_format() op_ici_install() op_ici_print() op_intrpt_ici() op_pk_ici_get() Provided Capability determines if an attribute, specified by name, is defined within an ICI s format obtains the value of an ICI attribute, specified by name assigns the value of an ICI attribute, specified by name creates a new ICI with a specified format; the ICI s address is returned releases memory taken by an ICI obtains the name of an ICI s format installs an ICI as current for a process such that the ICI becomes associated with events scheduled by the process prints the contents of an ICI to standard output obtains the address of the ICI associated with the currently executing event obtains the pointer to the ICI that has been previously associated with the packet via the KP op_pk_ici_set(). 419-Comec

26 Communicating with Interface Control Information Modeling Concepts ICI-Related Kernel Procedures (Cont.) Kernel Procedure op_pk_ici_set() Provided Capability creates an association between a packet and an ICI by storing the specified ICI pointer in the packet. Standard ICI Lifecycles The principal events in an ICI s existence are creation, destruction, and installation. 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 are typically executed. Because there are no strict ownership controls on ICIs, as there are on packets, any process that has access to an ICI s address can perform these operations. For example, an ICI may be destroyed by the process that created it, or by one of the processes that have received it. Similarly, multiple processes can concurrently have access to the same ICI and cause modifications that will be visible to each other. While the Simulation Kernel imposes no strict discipline on the usage of ICIs, certain standard patterns of creation, installation, and destruction are recommended 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 rigorous control on access to ICIs, since it treats them as though they were packets, disallowing shared access by multiple processes. The communication of information in association with an event is supported by the following sequence of operations: 1) The source process creates an ICI by calling the KP op_ici_create(). 2) The source process stores information in the ICI s attributes by calling 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 interrupted process obtains the ICI by calling op_intrpt_ici(). 6) The interrupted process extracts information that it needs from the ICI by calling op_ici_attr_get(). 420-Comec

27 Modeling Concepts Communicating with Interface Control Information 7) The interrupted process destroys the ICI by calling op_ici_destroy(). Note that when per-use instantiation is employed, the source process no longer manipulates the ICI after having generated the event. The responsibility for destroying the ICI and releasing memory associated with the ICI s attributes therefore belongs to the destination process. Communication Mechanisms Permanent ICIs. In certain situations, per-use instantiation results in an alternating sequence of creation and destructions of ICIs of the same type. A straightforward optimization therefore consists of creating the ICI only once, and never destroying it; the source process need only update the ICI s attribute values and install it before generating an event (the installation is still required, in case the process also makes use of other ICIs). The sequence of operations for the source and destination processes is as follows: 1) The source process creates an ICI at initialization (or perhaps some later time, but this should occur only once) by calling op_ici_create(). 2) When the source process is about to take an action that will generate an event and the ICI is to be associated with that event, it assigns appropriate values to the ICI s attributes by calling op_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 interrupted process obtains the ICI by calling op_intrpt_ici(). 6) The interrupted process extracts information that it needs from the ICI by calling op_ici_attr_get(). Note that under this scheme, the ICI is never destroyed. However, this does not result in memory being wasted since the same ICI is continually recycled. Comec.3.4 Communicating with Statistics Because packets can store general user-specified information, they can always be used to support the communication of data between processes. However, for certain types of applications that communicate small amounts of information and which do not require the structure provided by a packet format, a packet interface may be overly complex. 421-Comec

28 Communicating with Interface Control Information Modeling Concepts One such application is the communication of a single numerical value between 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 performed between modules, OPNET provides a simpler interface specifically for this purpose. The interface is supported by a node domain object called a statistic wire, and the communicated values are referred to as statistics. Comec Statistic Wire Configuration A statistic wire is a physical connection that attaches a source port of one module to a destination port of another module in the same node. Source ports for statistic wires are referred to as output statistics, and destination ports are referred to as input statistics. The source module of a statistic wire can be any module that generates statistics (currently, the only type of module that does not generate any statistic is the antenna module provided with Radio versions). However, only processors and queue modules may act as the destinations of statistic wires since these are the only modules that can contain processes that would receive a statistic value. Graphically, statistic wires are represented in a manner similar to packet streams, but are distinguished by a dashed connection path (as opposed to the solid lines used to depict packet streams). Statistic wire input ports are referred to by integer indices and can range from 0 to Comec

29 Modeling Concepts Communicating with Interface Control Information Statistic Wire Connections with Fan-Out and Fan-In output results input results fan-out Communication Mechanisms fan-in Input statistics are capable of accepting multiple statistic wires in order to provide the local module with a sequence of values that results from merging the individual sequences of values sent via multiple output statistics, possibly from different modules. Statistic wires may be used to transfer any of the values that constitute the predefined output statistics known to the Simulation Kernel. These are the same values that can be collected in a simulation s output vector file via statistic probes. For all modules except processors, output statistics can be predefined values computed automatically by the Simulation Kernel, a new value being transferred whenever a change occurs. For example, a queue module generates statistics such as the number of packets it contains or the average amount of time a packet remains in the queue; and a receiver module generates statistics such as throughput and utilization for each of its channels. For a complete definition of available predefined statistics for each type of module, refer to the Node Domain chapter of Modeling Concepts. Since the significance and behavior of queue and process modules can be specified in a fully general manner by assigning user-defined process models, generic output statistics are provided for custom applications. For each queue or processor module, you can declare any number of output statistics. These output statistics can act as the source of a statistic wire in order to convey new values to their destination at the request of processes within the source module. Processes can initiate the transfer of a new statistic value on a particular statistic wire by calling the KP op_stat_write() and specifying the index of the output statistic to which the statistic wire is attached. Any floating point number can be sent to a statistic wire destination in this manner. Apart from the manner in which new values are generated, statistic wires operate identically, regardless of whether they are fed by predefined or generic statistics. When a new value is generated at a statistic wire source, two possible behaviors may result, depending upon the value assigned to the intrpt method attribute of the statistic wire. If the interrupt method is forced, then no delay is 423-Comec

30 Communicating with Interface Control Information Modeling Concepts possible for the statistic transfer, and an immediate change occurs at the destination module s input statistic. However, if the interrupt method is scheduled, which is the default, then an arrival time at the destination module s input 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 the input statistic, replacing the value that was there previously. The value may subsequently be obtained at any time (until the next replacement) by any process in the destination module using the KP op_stat_local_read(). The integer index of the input statistic must be specified when calling this KP. Note that the previous value can no longer be obtained, since it has been overwritten. In addition to making a new statistic value available to the destination module each time that an update occurs, a statistic wire can provide active notification of changes. Notification takes the form of a statistic event that is generated for the destination module if appropriate conditions are met. The statistic event may then result in an interrupt for one of the module s processes if appropriate interrupts are enabled. For more information on restricting interrupts, refer to the Modeling Framework chapter of Modeling Concepts. A statistic wire can be configured in such a way as to generate events only when 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 be generated. Triggers are specified as attributes of a statistic wire object that characterize six types of changes in value. For an event to occur as a result of a statistic value change, the logical OR of the conditions represented by the statistic wire s enabled triggers must be true; in other words, at least one of the trigger conditions detailed below must be satisfied, and the corresponding trigger attribute must not be set to the disabled value. rising edge trigger. The newly received value is strictly greater than the previously received value. falling edge trigger. The newly received value is strictly less than the previously received value. repeated value trigger. The newly received value and the previously received value are identical. zero crossing trigger. The newly received value has the opposite sign of the previously received value, or the newly received value is exactly zero. low threshold trigger. The newly received value is less than or equal to a user specified low threshold value. high threshold trigger. The newly received value is greater than or equal to a user specified high threshold value. 424-Comec

31 Modeling Concepts Communicating with Interface Control Information The default configuration for statistic wire triggers is to enable the rising edge and falling edge triggers and to disable all others. This implies that a statistic event will 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 same as the previous value. Another common configuration enables the repeated value trigger in addition to the falling and rising edge triggers in order to allow any received statistic value to generate an active notification. Finally, a third common configuration disables all triggers in order to implement a passive statistic transfer; in other words, the destination module can observe statistic values generated at the statistic wire source, but no interrupts are ever received as a result. Communication Mechanisms Comec Statistic Wire Applications Because statistic wires are capable of transferring arbitrary values under control of user-defined processes, they may be used for a wide range of applications requiring communication between modules in the same node. Two common 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 userdefined processes with the ability to sense the state of other modules within the same node. This can be a useful tool for developing adaptive models in which decisions to take particular actions are dependent upon dynamic operating conditions of the surrounding node. Statistic wires are particularly well-suited to the application of dynamically monitoring other modules due to their ability to provide active notification of changes. This improves efficiency relative to a polling strategy, whereby a monitoring process periodically examines an external condition to determine whether to perform an action. In addition, accuracy is improved, since the process can be notified immediately when a condition has changed. Finally, by configuring a statistic wire s triggers, a monitoring process can be alerted to external changes only when appropriate. For modules other than processors or queues, statistic wires provide the only means of monitoring activity during the simulation in order to feed past and present metrics back into the determination of future behavior. For example, by using triggers, alarms can be generated for predefined module statistics when they reach particular thresholds. This is commonly done for statistics such as the number of packets held in a queue, the throughput of a receiver channel, or the signal to noise ration of a radio receiver. Using Statistic Wires as Semaphores Due to the simplicity of the statistic interface from the perspective of processes that use them, statistic wires are commonly used to implement low-level signalling mechanisms between processes in different modules. The term semaphore is used 425-Comec

32 Communication Link Models Modeling Concepts to refer to a variable that is controlled by a source process and observed by a destination process. The destination process makes use of the variable value to control its timing and decision making. One common type of semaphore is a simple bivalued statistic (e.g., alternating between zero and one) that act as a lock, allowing one process to prevent or allow the execution of certain actions by another process. By using the triggers of the statistic wire, semaphores can become active, allowing the destination process to 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 of communication links was described. Each type of link provides a fundamentally different type of connectivity: point-to-point links connect a single source node to a single destination node; bus links connect a fixed set of nodes to each other; and radio links potentially allow all nodes in a model to communicate with each other, based on a dynamic evaluation. While the general type of connectivity provided by these links is predefined by OPNET, an open architecture is provided to allow developers to specify customized behavior for each individual link and on a pertransmission basis. This architecture is referred to as the transceiver pipeline because 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 supported link types. In each case, the Simulation Kernel manages the transfer of packets by implementing a series of computations, each of which models particular aspects of link behavior. The sequence of the computations and their interface are standardized for each type of link. However each computation, referred to as a pipeline stage, is performed outside the Simulation Kernel by a user-supplied procedure, called a pipeline procedure. In this manner, OPNET provides an open and modular architecture for implementing link behavior. A link s underlying implementation can generally be thought of as a sequentially executed set of pipeline stages. The pipeline stage sequence of a link is executed once for each packet transmission that is submitted at the source of the link. In other words, when a packet is sent to a transmitter, the Simulation Kernel proceeds to call appropriate pipeline stages to process the packet. Certain pipeline stages are executed when the packet is transmitted, and others are executed later due to the delay associated with the traversal of the link and transmission of the packet. The principal objective of a transceiver pipeline is to determine whether or not a packet can be received at the link s destination. This determination is usually made in the final stages of the pipeline based on information computed during earlier stages. The primary vehicle used to convey information between the stages is 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 426-Comec

33 Modeling Concepts Communication Link Models Simulation Kernel. A link model may also contain local statistics, which can also be used to convey information about a particular link object across different pipeline stages. In order to carry both user-defined and standard pipeline information, packets contain a special storage area consisting of an array of values called transmission data attributes. Transmission data attributes (TDAs) are either integer or floatingpoint 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 is dependent upon the particular type of link and the conventions agreed-upon by the pipeline stages. Communication Mechanisms At the time that a packet enters a pipeline (i.e., when it begins transmission), a certain number of TDAs are automatically assigned by the Simulation Kernel in order to provide information to the pipeline stages concerning the context of the transmission. For example, the object ID of the link, of the transceivers, and of the channel objects, as well as certain relevant attributes of these objects, are generally already present in predefined TDAs of the packet by the time the first stage is executed. The particular set of TDAs that is automatically provided depends upon the type of link, and is documented for each link type in later sections of this chapter. The predefined TDAs that are set up prior to a pipeline execution are reserved for the exclusive use of the Simulation Kernel. In addition, the Kernel reserves certain standard TDAs for the pipeline stages to communicate certain information to it as well as to each other. For each of these TDAs, the Kernel defines a special symbolic constant to represent the TDA s integer index. Refer to the Symbolic Constants chapter of Simulation Kernel. In each set of predefined TDAs, a certain number are provided in advance or computed by the Kernel as the pipeline execution proceeds. These TDAs have a fixed meaning and always serve to communicate information from the Kernel to the stages, but not the reverse. As a result, these TDAs may not be used by pipeline stages for alternate purposes (simulation errors will result if this is attempted). However, the TDA array is extensible and allows any positive integer index to be specified when assigning or obtaining an attribute value. Thus, custom pipeline designs may make use of any higher-numbered TDAs (above the highest predefined TDA) that are not reserved by the Kernel in order to communicate additional information between stages. Special symbolic constants representing the highest reserved TDA index are provided to support this application. These constants appear in the table below. For a given pipeline, the lowest unreserved TDA index is obtained by adding one to the appropriate constant. Maximum Reserved TDA Indices Link Type Point-to-Point Bus Constant Representing Maximum Reserved Index OPC_TDA_PT_MAX_INDEX OPC_TDA_BU_MAX_INDEX 427-Comec

34 Communication Link Models Modeling Concepts Maximum Reserved TDA Indices Link Type Constant Representing Maximum Reserved Index Radio OPC_TDA_RA_MAX_INDEX In addition to supporting communication of information between pipeline stages and the Kernel, and between pipeline stages and each other, TDAs can be used to pass information from the pipeline stages to processes in a link s destination node. The information accumulated in a packet during its traversal of a transceiver pipeline is not stripped when the pipeline s execution completes. In fact, 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 generated by pipeline stages that processed the packet as the packet was transferred. This capability may be useful to support implementation of sophisticated decision making within link destination nodes based on conditions in the arriving links. For example, a node receiving packets transmitted by radio may make use of pipelinegenerated information about interference to adjust its antenna orientation or its reception frequency. Note that while processes within nodes can obtain information from TDAs in packets, they are not capable of modifying existing TDAs or extending the TDA array to incorporate new values. Thus, TDAs cannot be used to communicate information from processes to the pipeline stages (this policy is due to the fact that information inserted into the TDAs would be overwritten anyway at the time of actual transmission). It is possible however to use ordinary packet fields for this purpose, since pipeline stages are capable of accessing these values. 428-Comec

35 Modeling Concepts Communication Link Models Transformation Phases for a Packet s Transmission Data Attributes 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. If the packet completes the pipeline and is accepted, the TDA values accumulated during the pipeline remain in the packet. Communication Mechanisms TD0 TD1 TD2 After passing the transmitter, the packet enters the pipeline with old TDA values erased. New information is inserted to reflect the current link s configuration. Comec.4.2 Pipeline Stage Definition Pipeline stages are implemented as C or C++ language procedures with predefined argument and return-value interfaces. Almost all pipeline stages accept a 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 conveying information back to the Simulation Kernel as well as to subsequent pipeline stages. Each pipeline stage has a user-provided name, usually selected to be representative of its features. For example, a pipeline stage responsible for calculating the signal-to-noise ratio affecting radio transmissions may be called radio_snr. The selected name must be used to name the pipeline stage procedure as well as the source code file that contains it. Pipeline stage object code files can only be recognized by OPNET if they carry the suffix.ps.o ; therefore pipeline stage 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 by a C procedure defined as radio_snr() within a file called radio_snr.ps.c, which when compiled generates the object code file radio_snr.ps.o. Custom pipeline stages 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. 429-Comec

36 Communication Link Models Modeling Concepts The Simulation Kernel contains a package of procedures to support the assignment to and extraction from transmission data attributes. This package is called the Transmission Data package (Td) and the procedures that it includes are summarized below. For detailed explanations of their capabilities and usages, refer to the Transmission Data Package chapter of Simulation Kernel. Transmission Data Package Kernel Procedures Kernel Procedure op_td_set_dbl() op_td_set_int() op_td_get_dbl() op_td_get_int() op_td_is_set() Provided Capability assign a double-precision floating-point value to a specified TDA of a packet, replacing the previous value (if any) assign an integer value to a specified TDA of a packet, replacing the previous value (if any) obtain a double-precision floating point value stored in a specified TDA of a packet obtain an integer value stored in a specified TDA of a packet determine if a specified TDA of a packet currently contains an assigned value The top-level pipeline procedure may also make use of most OPNET Kernel Procedures (KPs), user-defined or third-party procedures in other files, and the general capabilities of the C language to implement the functionality required of them. Frequently, pipeline stages perform mathematical calculations that rely on the availability of the C/C++ math library, and therefore include the definitions file 430-Comec

37 Modeling Concepts Communication Link Models math.h in their source code file. A C source code example for a simple pipeline stage procedure appears below: Example of a C Pipeline Stage Procedure /* transmission_delay.ps.c */ #include <opnet.h> #include <math.h> Communication Mechanisms void transmission_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); In the case of a C++ pipeline stage file, the top-level pipeline procedure must be linked using the C linkage convention so that the Simulation Kernel can correctly access it. This is indicated by wrapping the prototype of the procedure in an extern C linkage expression, such as: Example of a C++ Pipeline Stage Procedure /* transmission_delay.ps.cpp */ #include <opnet.h> #include <math.h> extern C { void closure_template (Packet *); } void closure_template (Packet * pk) { /* pipeline stage code */ } OPNET provides default pipeline procedures to support each of the three types of links. These pipeline stages appear as the default assignments when new transceiver or link objects are created. The names of these stages are given below. Complete explanations of each default stage s behavior and implementation are 431-Comec

38 Communication Link Models Modeling Concepts provided in General Models. These default stages may also serve as good starting points 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 Pipeline Stage Attribute Name Default Stage Name 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 Pipeline Stage Attribute Name Default Stage Name 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 432-Comec

39 Modeling Concepts Communication Link Models Comec.4.3 Default Radio Transceiver Pipeline Pipeline Stage Attribute Name Default Stage Name Error Correction ecc model dra_ecc The Point-to-Point Transceiver Pipeline Point-to-point links are based on a simple four-stage pipeline that supports the transfer 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. Communication Mechanisms Point-to-Point Link Transceiver Pipeline Execution Sequence for one Transmission transmitter transmission delay 0 1 propagation delay receiver 3 error correction 2 error allocation 433-Comec

40 Communication Link Models Modeling Concepts The pipeline stages for a particular point-to-point link (simplex or duplex) can be specified using the appropriate attributes of the link object, as shown below. Point-to-Point Link Attributes for Specifying Pipeline Stages pipeline attributes Comec Reserved Transmission Data Attributes The Simulation Kernel sets aside a number of TDAs to provide pipeline stages with access to a minimum standard set of values, and to support communication between 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, the symbolic constants that represent the TDA s indices are shown in a short form without their common prefix. When actually used, each symbolic constant appears with 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 constant name: 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 434-Comec

41 Modeling Concepts Communication Link Models CH_INDEX (I) Point-to-Point Pipeline: Reserved TDAs Symbolic Constant Definition Assigned By index of transmitting (and receiving) channel Kernel Modifiable by Stages TX_DELAY (D) packet transmission delay stage 0 Yes No Communication Mechanisms 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 Comec Stage 0: Transmission Delay The transmission delay stage is the first stage of the pipeline, and is specified by the txdel model attribute of the point-to-point link. It is invoked immediately upon beginning transmission of a packet, in order to calculate the amount of time required for the entire packet to complete transmission. This result can be thought of as the simulation time difference between the beginning of transmission of the first bit and the end of transmission of the last bit of the packet. The Simulation Kernel uses the result provided by this stage to schedule an end-of-transmission event for the transmitter channel that is used to send the packet. When this event occurs, the transmitter may begin transmission of the next packet in the channel s internal queue, if any are present; otherwise the transmitter channel becomes idle. In addition, the transmission delay result is used in conjunction with the result of the propagation delay stage to compute 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 finishes transmitting added to the propagation delay on the link). The Simulation Kernel requires that the transmission delay stage procedure accept a packet address as its sole argument. The computed transmission delay is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_PT_TX_DELAY. The assigned value should be a nonnegative double- 435-Comec

42 Communication Link Models Modeling Concepts precision floating-point number. No other results are required. Interface requirements for this stage are specified by the following procedure template: Template for Point-to-Point Pipeline: Transmission Delay Stage void tx_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); } Comec Stage 1: Propagation Delay The propagation delay stage is the second stage of the pipeline, and is specified by the propdel model attribute of the point-to-point link. It is invoked after the return 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 the packet s signal to travel from the link s source to its destination. This result is generally dependent on parameters such as the type of physical medium, the distance between the source and the destination, and the frequency of the signal. Regardless of the factors involved, the Simulation Kernel expects a doubleprecision floating-point value to be provided by this stage. The Kernel uses this result to schedule a beginning-of-reception event for the receiver channel that the packet is destined for. In addition, the propagation delay result is used in conjunction with the result of the transmission delay stage to compute the time at which the packet completes reception (i.e., the time at which the last bit finishes arriving is the time at which the packet begins transmission added to the sum of the transmission delay and the propagation delay). The Simulation Kernel requires that the propagation delay stage procedure accept a packet address as its sole argument. The computed propagation delay is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_PT_PROP_DELAY. The assigned value should be a nonnegative doubleprecision floating-point number. No other results are required. Interface requirements for this stage are specified by the following procedure template: 436-Comec

43 Modeling Concepts Communication Link Models Template for Point-to-Point Pipeline: Propagation Delay Stage void prop_delay_template (Packet* pk) { double result; /* extract required information from packet. */ Communication Mechanisms /* 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); } Comec Stage 2: Error Allocation The error allocation stage is the third stage of the pipeline, and is specified by the error model attribute of the point-to-point link. It is invoked after the entire packet has completed reception at the destination, in order to estimate the number of 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 the quality of the link, and the packet length. The Kernel uses this result to report error statistics for the receiver channel object. In addition, this result is typically used by the final stage of the point-to-point link pipeline in order to decide whether or not to accept the packet and subsequently forward it via the receiver channel s output stream. The Simulation Kernel requires that the error allocation stage procedure accept a packet address as its sole argument. The computed number of errors affecting the packet is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_PT_NUM_ERRORS. The assigned value should be an integer value between zero and the packet length (inclusive). No other results are required. Interface requirements for this stage are specified by the following procedure template: 437-Comec

44 Communication Link Models Modeling Concepts Template for Point-to-Point Pipeline: Error Allocation Stage void error_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); } Comec Stage 3: Error Correction The error correction stage is the fourth and final stage of the pipeline, and is specified by the ecc model attribute of the point-to-point link. It is invoked immediately after the return of the error allocation stage, with no simulation time elapsing in between. The purpose of this stage is to determine whether or not the arriving packet can be accepted and forwarded via the channel s corresponding output 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 stage and the ability of the receiver to correct the errors affecting the packet, hence the name of the stage. Based on the determination of this stage, the Kernel will either destroy the packet, or allow it to proceed into the destination node. In addition, this result affects error and throughput statistics collected for the receiver channel. The Simulation Kernel requires that the error correction stage procedure accept a packet address as its sole argument. The determination to accept or reject the packet is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_PT_PK_ACCEPT. The assigned value should be the integer value OPC_TRUE to indicate acceptance; otherwise the integer value OPC_FALSE should be assigned. No other results are required. Interface requirements for this stage are specified by the following procedure template: 438-Comec

45 Modeling Concepts Communication Link Models Template for Point-to-Point Pipeline: Error Correction Stage void error_correction_template (Packet* pk) { int result; /* extract required information from packet. */ Communication Mechanisms /* 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); } Comec.4.4 The Bus Transceiver Pipeline Because a bus link is a broadcast medium, each transmission can potentially affect multiple receivers attached to the bus. In addition, when processing a transmission, a bus link may exhibit different behavior and timing with respect to each receiver. As a result, a separate pipeline must be executed for each receiver attached to the bus. The bus transceiver pipeline consists of six stages, most of which must be executed on a per-receiver basis whenever a transmission occurs. However, the first stage (transmission delay) is used to compute a result that is common to all destinations, and therefore may be executed just once. In addition, each individual pipeline sequence may or may not fully complete, depending on the result of the second stage (closure), since this stage is responsible for determining if communication between the transmitter and receiver is possible. Finally, the fourth stage (collision) may be executed multiple times for each transmitted packet, since it is possible for a packet to be involved in more than one collision. The structure of the bus transceiver pipeline is depicted in the following diagram. 439-Comec

46 Communication Link Models Modeling Concepts Bus Link Transceiver Pipeline Execution Sequence for one Transmission transmitter stages 2 and up are executed separately for each receiver 0 transmission delay executed once per transmission closure propagation closure propagation closure delay propagation delay delay 1 2 propagation propagation propagation delay error delay correction delay 5 propagation propagation propagation delay error allocation delay delay 4 propagation propagation propagation delay delay collision delay 3 multiple receivers collision stage may be executed zero or more times The pipeline stages for a particular bus link can be specified using the appropriate attributes of the bus link object, as shown below. Bus Link Attributes for Specifying Pipeline Stages pipeline attributes Comec Reserved Transmission Data Attributes The Simulation Kernel sets aside a number of TDAs to provide pipeline stages with access to a minimum standard set of values, and to support communication between 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 440-Comec

47 Modeling Concepts Communication Link Models defined below. For compactness, the symbolic constants that represent the TDA s indices are shown in a short form without their common prefix. When actually used, 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 the table next to the symbolic constant name: D represents a double-precision floating-point attribute, and I represents an integer attribute. Bus Pipeline Reserved TDAs Communication Mechanisms Symbolic Constant Definition Assigned By Modifiable by Stages 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 transmission 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 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 441-Comec

48 Communication Link Models Modeling Concepts Comec Stage 0: Transmission Delay The transmission delay stage is the first stage of the pipeline, and is specified by the txdel model attribute of the bus link. It is invoked immediately upon beginning transmission of a packet. This is the only stage for which a single execution 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 entire packet to complete transmission. This result is the simulation time difference between the beginning of transmission of the first bit and the end of transmission of the last bit of the packet. The Simulation Kernel uses the result provided by this stage to schedule an end-of-transmission event for the transmitter channel that is used to send the packet. When this event occurs, the transmitter may begin transmission of the next packet in the channel s internal queue, if any are present; otherwise the transmitter channel becomes idle. In addition, the transmission delay result is used in conjunction with the result of the propagation delay stage to compute 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 finishes transmitting added to the propagation delay on the link). The Simulation Kernel requires that the transmission delay stage procedure accept a packet address as its sole argument. The computed transmission delay is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_BU_TX_DELAY. The assigned value should be a nonnegative doubleprecision floating-point number. No other results are required. Syntax requirements for this stage are specified by the following procedure template: Template for Bus Pipeline: Transmission Delay Stage void tx_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_BU_TX_DELAY, result); } Comec Stage 1: Closure The closure stage is the second stage of the pipeline, and is specified by the closure model attribute of the bus link. It is invoked once for each receiver attached to the bus. These invocations take place immediately after the return of the transmission delay stage, with no simulation time elapsing in between. The purpose of this stage is to determine whether a particular receiver is capable of 442-Comec

49 Modeling Concepts Communication Link Models receiving a transmission. The ability to receive a transmission is referred to as closure 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 the bus pipeline for the particular receiver in question. If the integer value is equal to the symbolic constant OPC_TRUE then closure is established and communication between the transmitter and receiver is possible; otherwise the value OPC_FALSE should be used to indicate that communication is not possible. Communication Mechanisms The Simulation Kernel requires that the closure stage procedure accept a packet address as its sole argument. The closure indication is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_BU_PROP_CLOSURE. No other results are required. Interface requirements for this stage are specified by the following procedure template: Template for Bus Pipeline: Closure Stage void closure_template (Packet* pk) { int result; /* extract required information from packet. */ /* perform calculation of closure indication. */ /* place result in TDA to return to Simulation Kernel. */ op_td_set_int (pk, OPC_TDA_BU_CLOSURE, result); } Comec Stage 2: Propagation Delay The propagation delay stage is the third stage of the pipeline, and is specified by the propdel model attribute of the bus link. It is invoked for each receiver that is attached to the bus; this invocation takes place after the return of the closure stage with no simulation time elapsing in between. The purpose of this stage is to calculate the amount of time required for the packet s signal to travel from the bus transmitter to the bus receiver. This result is generally dependent on factors such as the type of physical medium, the distance 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 this result to schedule a beginning-of-reception event for the receiver channel that the packet is destined for. In addition, the propagation delay result is used in conjunction with the result of the transmission delay stage to compute the time at which the packet completes reception (i.e., the time at which the last bit finishes arriving is the time at which the packet begins transmission added to the sum of the transmission delay and the propagation delay). The Simulation Kernel requires that the propagation delay stage procedure accept a packet address as its sole argument. The computed propagation delay is 443-Comec

50 Communication Link Models Modeling Concepts then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_BU_PROP_DELAY. The assigned value should be a nonnegative doubleprecision floating-point number. No other results are required. Interface requirements for this stage are specified by the following procedure template: Template for Bus Transceiver Pipeline: Propagation Delay Stage void prop_delay_template (Packet* pk) { double result; /* extract required information from packet. */ /* perform calculation of propagation delay. */ /* place result in TDA to return to Simulation Kernel. */ op_td_set_dbl (pk, OPC_TDA_BU_PROP_DELAY, result); } Comec 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 pipeline stages, it may be executed multiple times or not at all within a given pipeline sequence. This stage is called each time that the packet of interest experiences a new collision; a collision is considered to occur when the packet of interest initially arrives at the receiver and another packet has already begun arriving on the same channel; or when the packet of interest has already begun arriving and another packet begins. In other words, collisions are symmetric events experienced by both packets involved. When a collision occurs, a single call to the collision stage is generated in order to support both of the packets pipelines. Because an arbitrary number of transmissions may occur on the bus during the reception time of a packet, a single packet may experience multiple collisions. The purpose of the collision stage is to provide application-specific models with knowledge of collisions. The Simulation Kernel expects no particular results to be generated by the invoked pipeline procedure. However, the Kernel does reserve 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 is initially set to zero when the packet is transmitted. Typically, if a collision is judged to be relevant in the sense that it has a bearing on later processing of the packet, then the logic in this stage increments the value of the TDA OPC_TDA_BU_NUM_COLLS. The Simulation Kernel requires that the collision stage procedure accept two packet addresses as arguments. The first packet address is that of the earlier arriving packet, and the second address is that of the later arriving packet that 444-Comec

51 Modeling Concepts Communication Link Models triggered the collision. Interface requirements for this stage are specified by the following procedure template: Template for Bus Transceiver Pipeline: Collision Stage void collision_template (earlier_pk, later_pk) Packet* earlier_pk; Packet* later_pk; { } Communication Mechanisms Comec Stage 4: Error Allocation The error allocation stage is the fifth stage of the pipeline, and is specified by the error model attribute of the bus link. It is invoked after the entire packet has completed reception at the destination, in order to estimate the number of 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 the quality of the link, and the packet length. This calculation usually does not include errors due to collisions. The Kernel uses the result of this stage to report error statistics for the receiver channel object. In addition, this result is typically used by the final stage of the bus link pipeline in order to decide whether or not to accept the packet and subsequently forward it via the receiver channel s output stream. The Simulation Kernel requires that the error allocation stage procedure accept a packet address as its sole argument. The computed number of errors affecting the packet is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_BU_NUM_ERRORS. The assigned value should be an integer value between zero and the packet length (inclusive). No other results are required. Interface requirements for this stage are specified by the following procedure template: Template for Bus Pipeline: Error Allocation Stage void error_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_BU_NUM_ERRORS, result); } 445-Comec

52 Communication Link Models Modeling Concepts Comec Stage 5: Error Correction The error correction stage is the sixth and final stage of the pipeline, and is specified by the ecc model attribute of the bus link. It is invoked immediately after the return of the error allocation stage, with no simulation time elapsing in between. The purpose of this stage is to determine whether or not the arriving packet can be accepted and forwarded via the channel s corresponding output stream to one of the receiver s neighboring modules in the destination node. This is usually dependent upon whether the packet has experienced collisions, the result computed in the error allocation stage, and the ability of the receiver to correct the errors affecting the packet (hence the name of the stage). Based on the determination of this stage, the Kernel will either destroy the packet, or allow it to proceed into the destination node. In addition, this result affects error and throughput statistics collected for the receiver channel. The Simulation Kernel requires that the error correction stage procedure accept a packet address as its sole argument. The determination to accept or reject the packet is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_BU_PK_ACCEPT. The assigned value should be an integer equal to the constant OPC_TRUE to indicate acceptance; otherwise the integer value OPC_FALSE should be assigned. No other results are required. Interface requirements for this stage are specified by the following procedure template: Template for Bus Pipeline: Error Correction Stage void error_correction_template (Packet* pk) { int result; /* extract required information from packet. */ /* determine if packet should be accepted or rejected. */ /* place result in TDA to return to Simulation Kernel. */ op_td_set_int (pk, OPC_TDA_BU_PK_ACCEPT, result); } Comec.4.5 The Radio Transceiver Pipeline Because radio links provide a broadcast medium, each transmission can potentially affect multiple receivers throughout the network model. In addition, for a given transmission, the radio link to each receiver may exhibit different behavior and timing. As a result, a separate pipeline must be executed for each eligible receiver. The radio transceiver pipeline consists of fourteen stages, most of which must be executed on a per-receiver basis whenever a transmission occurs. However, the first stage (receiver group) is invoked only once for each pair of transmitter and receiver channels in the network, in order to establish a static binding between each transmitter channel and the set of receiver channels that it is allowed to 446-Comec

53 Modeling Concepts Communication Link Models communicate with. The second stage (transmission delay) is used to compute a result that is common to all destinations, and therefore may be executed just once per transmission. Finally, each individual pipeline sequence may or may not fully complete, depending on the result of the third stage (closure), since this stage is responsible for determining if communication between the transmitter and receiver is possible on a dynamic basis. Similarly, the fourth stage (channel match) may classify a transmission as irrelevant with regard to its effect on a particular receiver channel, thereby preventing the pipeline sequence from reaching the final stages. Communication Mechanisms Note from the following diagrams that several of the later stages of the radio pipeline may be executed multiple times for each receiver, due to interactions with multiple concurrent transmissions from other sources. In order to detect concurrent reception of multiple packets at the same receiver channel, the Simulation Kernel maintains two lists of current packets for each radio receiver channel object. The first list contains only packets that have been determined to be valid by the channel match stage; the second list contains invalid packets. Valid packets are those that meet the criteria of the channel for proper reception. Generally, this requires that the transmitter and receiver channels have matching characteristics, and possibly also that the receiver channel be able to synchronize to the packet s signal. The primary reason for maintaining invalid and valid packets in separate lists is that this allows the Simulation Kernel to execute certain pipeline stages or to compute certain channel statistics only for valid packets. For example, there is no need to calculate signal-to-noise ratio, bit error rate, or error allocations for packets that cannot be accepted by the receiver. In general, all of the stages following the received power stage are applicable only to valid packets. 447-Comec

54 Communication Link Models Modeling Concepts Radio Link Transceiver Pipeline Execution Sequence for one Transmission transmitter 0 receiver group Executed once at start of simulation for each pair of transmitter and receiver channels to determine feasibility of communication; not executed on a per-transmission basis 1 transmission delay executed once per transmission 2 link closure stages 2 and up are executed separately for each rx 3 channel match rx antenna gain propagation delay tx antenna gain received power 8 background noise 9 interference noise stage 9 may be executed zero or more times error allocation bit error rate signal to noise ratio error correction multiple receivers stages may be executed one or more times Stages 9 through 12 of the pipeline are invoked to evaluate a link s performance in response to changes in the signal condition. There is always at least one invocation of stages 10 through 12 in order to evaluate performance over the full duration of a valid packet. However, an additional invocation will occur for 448-Comec

55 Modeling Concepts Communication Link Models each of these stages (9-12) whenever an interfering packet arrives, in order to compute new signal conditions. Because radio links do not exist as physical objects, the pipeline stages used to support a particular radio transmission must be associated with the radio transmitter and radio receiver that form the link. Certain stages are associated with the transmitter and others with the receiver, as shown below: Communication Mechanisms Radio Transceiver Attributes for Specifying Pipeline Stages 6 Stages (0-5) associated with Radio Transmitter 8 Stages (6-13) associated with Radio Receiver Comec Reserved Transmission Data Attributes The Simulation Kernel sets aside a number of TDAs to provide pipeline stages with access to a minimum standard set of values, and to support communication between 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 are defined in the following table. For compactness, the symbolic constants that represent the TDA s indices are shown in a short form without their common prefix. When actually used, each symbolic constant appears with the character sequence OPC_TDA_RA_ prepended to the names given in the table below. The datatype 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 an integer attribute. 449-Comec

56 Communication Link Models Modeling Concepts Radio Pipeline Reserved TDAs Symbolic Constant and Datatype Definition Assigned By Modifiable by Stages 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 experienced 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 communicate 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 packet begins 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 transmitting 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 channel (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 450-Comec

57 Modeling Concepts Communication Link Models Symbolic Constant and Datatype TX_CODE (D) Radio Pipeline Reserved TDAs (Cont.) Definition code used to identify transmitter spreading technique and/or sequence Assigned By Kernel Modifiable by Stages no Communication Mechanisms 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 subnet 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 subnet 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 modulation format Kernel no RX_MOD (I) identifier for transmitter s modulation format Kernel no MATCH_STATUS (I) categorization of compatibility between tx and rx channels as valid, noise, or ignored stage 3 yes 451-Comec

58 Communication Link Models Modeling Concepts Radio Pipeline Reserved TDAs (Cont.) Symbolic Constant and Datatype Definition Assigned By Modifiable by Stages RX_NOISEFIG (D) noise figure of receiver Kernel no BKGNOISE (D) background noise due to otherwise 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 erroneous 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 completes (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 transmitter 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 452-Comec

59 Modeling Concepts Communication Link Models Symbolic Constant and Datatype TX_BORESIGHT_PHI, TX_BORESIGHT_THETA (D) Radio Pipeline Reserved TDAs (Cont.) Definition reference point on transmitting antenna (in degrees); usually point of maximum gain Assigned By Kernel Modifiable by Stages no Communication Mechanisms 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 Kernel (if failure occurs) no ND_RECOV (D) latest simulation time at which rx node recovery occurred during reception of packet Kernel (if recovery occurs) no Comec Stage 0: Receiver Group The receiver group stage is not actually part of the dynamic pipeline that processes transmissions. However, it is considered part of the pipeline because it computes results that influence the behavior of radio transmissions. It is specified by the rxgroup model attribute of the radio transmitter. When a radio transmission begins, the Simulation Kernel models the broadcast nature of radio by implementing multiple radio links between the transmitting channel and a set of receiver channels. Every transmitter channel maintains its own receiver group of channels that are possible candidates for receiving transmissions from that object. The purpose of the receiver group stage is to create an initial receiver group for each transmitter channel. The Simulation Kernel checks every possible transmitter-receiver channel pair, and creates a receiver group for each transmitter channel. This presents a problem, however: since transceiver characteristics can change dynamically during a simulation, it is often difficult to determine at the outset which receiver channels are appropriate destinations for a given transmitter channel. Therefore, the receiver group stage includes a receiver channel unless it can determine, in advance, that a receiver channel will never be an appropriate destination for a transmitter channel. During a simulation, subsequent pipeline stages can use dynamic criteria to determine a receiver channel s eligibility for receiving a transmission. Possible reasons for disqualifying a receiver channel during simulation (despite its membership in the transmitting channel s receiver group) include: 453-Comec

60 Communication Link Models Modeling Concepts Disjunct frequency bands. A frequency band is defined by its base frequency and its bandwidth. If a transmitter channel and receiver channel s frequency bands do not overlap, then the transmitter channel s transmissions cannot affect the receiver channel either as valid signals or as noise. Physical separation. A transmitter channel and receiver channel may be too far apart to establish a radio link with a sufficiently strong signal. Establishing a radio link also depends on factors like the elevation of the transmitter and receiver antennas and the transmission signal s power and frequency. Antenna nulls. The pipeline models the gain patterns of transmitter and receiver antennas in pipeline stages 4 and 6, respectively. When directional antennas are used, these stages computed results may reduce the signal power significantly so significantly that a simulation can reasonably ignore the effect of transmissions on the receiver channel in question. In some network models, the Simulation Kernel can determine that certain transmitter-receiver channel pairs are absolutely unable to communicate. In such cases removing the receiver channel from the transmitter channel s receiver group leads to faster simulations, since it eliminates the execution of pipeline stages known to have no effect. Because the receiver group stage is called before the simulation begins, however, its results should not depend on factors that may change during the simulation. Examples of such potentially iffy criteria are the initial distance between two mobile nodes and the initial frequencies assigned to transmitter and receiver channels (assuming that a model can dynamically change these frequencies). By default, OPNET includes the receiver channel in such cases, and all receiver groups remain static throughout the simulation; subsequent pipeline stages then use dynamic criteria to evaluate transmitter-receiver channel connectivity. The Simulation Kernel requires that the receiver group stage procedure accept the object IDs of a transmitter channel and a receiver channel, respectively. The procedure should return an integer value (OPC_TRUE or OPC_FALSE) to the Kernel; this value indicates whether the receiver channel is an eligible destination, and should be included in the receiver group. Syntax requirements for this stage are specified by the following procedure template: 454-Comec

61 Modeling Concepts Communication Link Models Template for Radio Transceiver Pipeline: Receiver Group Stage int rx_group_template (tx_channel_objid, rx_channel_objid) Objid tx_channel_objid; Objid rx_channel_objid; { int result; Communication Mechanisms return (result); } You can use the Radio package of Kernel Procedures to change the default receiver-group-stage behavior, and dynamically change and recalculate receiver groups in response to simulation events. For example, you can remove a receiver channel from a receiver group if the receiver s node becomes disabled in the course of a simulation. You can use the procedure op_radio_txch_rxgroup_compute() to calculate or recalculate a given channel s receiver group (in essence, re-invoking the 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 as needed. (Skipping this pipeline stage involves setting the rxgroup model attribute to dra_no_rxgroup instead of the default dra_rxgroup; this creates empty receiver groups for all transmitter channels.) Updating receiver groups dynamically can result in faster simulations, especially in network models with high levels of radio traffic. Skipping the pipeline stage and creating receiver groups as needed can also speed up simulations in networks with large numbers of transceiver channels. Comec Stage 1: Transmission Delay The transmission delay stage is numerically the second stage of the radio pipeline, but is the first to be executed on a dynamic basis as the result of a new transmission taking place. It is specified by the txdel model attribute of the radio transmitter, and is invoked immediately upon beginning transmission of a packet. This is the only stage for which a single execution 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 entire packet to complete transmission. This result is the simulation time difference between the beginning of transmission of the first bit and the end of transmission of the last bit of the packet. The Simulation Kernel uses the result provided by this stage to schedule an end-of-transmission event for the transmitter channel that is used to send the packet. When this event occurs, the transmitter may begin transmission of the next packet in the channel s internal queue, if any are present; otherwise the transmitter channel becomes idle. In addition, the transmission delay result is used in conjunction with the result of the propagation delay stage to compute the time at which the packet completes reception at the link s destination 455-Comec

62 Communication Link Models Modeling Concepts (i.e., the time at which the last bit finishes arriving is the time at which it finishes transmitting added to the propagation delay on the link). The Simulation Kernel requires that the transmission delay stage procedure accept a packet address as its sole argument. The computed transmission delay is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_RA_TX_DELAY. The assigned value should be a nonnegative doubleprecision floating-point number. No other results are required. Syntax requirements for this stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Transmission Delay Stage void tx_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_RA_TX_DELAY, result); } Comec Stage 2: Closure The closure stage is the third stage of the pipeline, and is specified by the closure model attribute of the radio transmitter. It is invoked once for each receiver channel referenced in the transmitting channel s destination channel set (For information on destination channel sets, refer to section Comec Stage 0: Receiver Group.) These invocations take place immediately after the return of the transmission delay stage, with no simulation time elapsing in between. The purpose of this stage is to determine whether a particular receiver channel can be affected by a transmission. The ability of the transmission to reach the receiver channel is referred to as closure between the transmitter channel and the receiver channel, hence the name of the stage. Note that the goal of the closure stage is not to determine if a transmission is valid or appropriate for a particular channel, but only if the transmitted signal can physically attain the candidate receiver channel and affect it in any way; thus, this stage applies to interfering transmissions (e.g., jamming) as well as to desired ones. Generally, the computations performed by this stage are based mostly on physical considerations, such as occlusion by obstacles and/or the surface of the earth. 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 the radio pipeline for the receiver channel in question. If the integer value is equal to the symbolic constant OPC_TRUE then closure is established and signal contact 456-Comec

63 Modeling Concepts Communication Link Models between the transmitter and receiver channels is possible; otherwise the value OPC_FALSE should be used to indicate that contact is not possible. The Simulation Kernel requires that the closure stage procedure accept a packet address as its sole argument. The closure indication is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_RA_PROP_CLOSURE. No other results are required. Syntax requirements for this stage are specified by the following procedure template: Communication Mechanisms Template for Radio Transceiver Pipeline: Closure Stage void closure_template (Packet* pk) { int result; /* extract required information from packet. */ /* perform calculation of closure indication. */ /* place result in TDA to return to Simulation Kernel. */ op_td_set_int (pk, OPC_TDA_RA_CLOSURE, result); } Comec Stage 3: Channel Match The channel match stage is the fourth stage of the pipeline, and is specified by the chanmatch model attribute of the radio transmitter. It is invoked once for each receiver channel that satisfies the criteria of the link closure stage. These invocations take place immediately after the return of the link closure stage, with no simulation time elapsing in between. The purpose of this stage is to classify the transmission with respect to the receiver channel. One of three possible categories must be assigned to the packet, as defined below: Valid. Packets in this category are considered compatible with the receiver channel and will possibly be accepted and forwarded to other modules in the receiving node, provided that they are not affected by an excessive number of errors. Classification as a valid packet usually depends at least on agreement between transmitter and receiver channels concerning the values of certain key attributes. Noise. This classification is used to identify packets whose data content cannot be received, but that have an impact on the receiver channel s performance by generating interference. Packets are generally classified as noise as a result of incompatibilities between the transmitter and receiver channel configurations. 457-Comec

64 Communication Link Models Modeling Concepts Ignored. If a transmission is determined to have no effect whatsoever on a receiver channel s state or performance, then it should be identified using this classification. The Simulation Kernel will then discontinue the pipeline execution between the transmitter and receiver channels for this particular transmission (future transmissions between the channels are not prevented). The Simulation Kernel requires that the channel match stage procedure accept a packet address as its sole argument. The classification is then expected by the Kernel within the integer TDA represented by the symbolic constant OPC_TDA_RA_MATCH_STATUS. One of the symbolic constants OPC_TDA_RA_MATCH_VALID, OPC_TDA_RA_MATCH_NOISE, or OPC_TDA_RA_MATCH_IGNORE should be used to represent the valid, noise, and ignored categories, respectively. No other results are required. Syntax requirements for this stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Channel Match Stage void channel_match_template (Packet* pk) { int result; /* extract required information from packet. */ /* 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); } Comec Stage 4: Transmitter Antenna Gain The transmitter antenna gain stage is the fifth stage of the radio transceiver pipeline, and is specified by the tagain model attribute of the radio transmitter. It is executed separately for each destination channel, except those that failed the link closure stage and those with respect to which the channel match stage has classified the transmission as ignored. Invocation of the transmitter antenna gain stage takes place immediately after return from the channel match stage with no simulation time elapsing in between. The purpose of the transmitter antenna gain stage 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 into the received power computation of stage 7. Antenna gain characterizes the phenomenon of magnification or reduction of the transmitted signal energy in a manner which depends on the direction of the 458-Comec

65 Modeling Concepts Communication Link Models signal path. This shaping of the transmitted energy is due to the physical characteristics of the antenna structure and possible phase manipulations of the signal in certain antennas consisting of multiple radiating elements. Antennas that provide no gain to a transmitted signal in any direction are referred to as isotropic, since they have a perfectly symmetric behavior with respect to all possible signal paths. The gain of an antenna in a particular direction is measured in comparison to an isotropic antenna. It is defined as the ratio of signal power produced by the antenna at a given distance and the isotropic power that would be measured at the same distance. Gain is a unitless quantity that is usually given in decibels (db). Communication Mechanisms By measuring or computing gain over a range of directions, a three dimensional antenna pattern can be constructed that characterizes the antenna s effect with respect to the various directions of transmission. OPNET does not provide tools for calculation of antenna patterns but the Antenna Editor supports the capture of antenna pattern data in an empirical form (i.e., the pattern must already be known and can be entered in numerical form). In addition, the Ema programmatic interface supports specification of antenna pattern data by a C language program, allowing patterns to be formed by analytical techniques, or database retrieval (i.e., other antenna-specific applications can be used to generate pattern data, and this data can be utilized by OPNET simulations). Regardless of the method used to capture antenna pattern data, the Antenna Editor displays the pattern in 3_d, as shown in the example below. Refer to Antenna Pattern Editor in Editor Reference for details on the Antenna Editor. Three-Dimensional Antenna-Gain Pattern 459-Comec

66 Communication Link Models Modeling Concepts In general, the transmitter antenna gain stage first calculates the direction vector separating the transmitter and the receiver and then uses knowledge of the antenna pattern to determine the antenna gain provided to the transmission. Pointing of the antenna is typically also accounted for by this pipeline stage (refer to the Node Domain chapter of Modeling Concepts). Pointing is controlled by a set of antenna attributes. These include pointing ref. phi and pointing ref. theta, which designate a particular part of the antenna pattern which is to be directed at a selected point in space. Pipeline stages may obtain these attributes of the transmitter antenna via the TDAs OPC_TDA_RA_TX_BORESIGHT_PHI and OPC_TDA_RA_TX_BORESIGHT_THETA. In addition, the antenna attributes target latitude, target longitude, and target altitude define a location in space at which the antenna s reference point is to be directed. Pipeline stages may obtain the values of these attributes directly from the antenna object, if necessary. However, the Simulation Kernel provides information derived from these attributes, which is in many cases sufficient for antenna gain calculations; this information is contained in the TDAs OPC_TDA_RA_TX_PHI_POINT and OPC_TDA_RA_TX_THETA_POINT, which represent the direction angles φ and θ of the vector separating the transmitter and the target location. These angles are not to be confused with the φ and θ angles used to define the antenna pattern. Rather, these target pointing angles are defined relative to the geocentric Cartesian coordinate system (refer to the Network Domain chapter of Modeling Concepts). The following figure illustrates the meaning of these angles within this coordinate system. Relationship of Pointing Angles φ and θ to Geocentric Cartesian Coordinate System φ = 90 deg. Z φ+. θ+. X θ = 0 deg. φ = 0 deg. θ = 270 deg. Y φ = -90 deg. The Simulation Kernel reserves a TDA, represented by the symbolic constant OPC_TDA_RA_TX_GAIN, to store the result of the transmitter antenna gain stage and to make it available to later stages of the pipeline. The Simulation Kernel requires 460-Comec

67 Modeling Concepts Communication Link Models that the stage s procedure accept a packet address as its sole argument. Syntax requirements for this stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Transmitter Antenna Gain Stage void tx_antenna_gain_template (Packet* pk) { double result; /* extract required information from packet. */ Communication Mechanisms /* 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); } Comec Stage 5: Propagation Delay 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 is invoked for each receiver channel that successfully passed both the link closure and channel match stages. This invocation takes place after the return of the transmitter antenna gain stage with no simulation time elapsing in between. The purpose of this stage is to calculate the amount of time required for the packet s signal to travel from the radio transmitter to the radio receiver. This result is generally dependent on the distance between the source and the destination. The Kernel uses this result to schedule a beginning-of-reception event for the receiver channel that the packet is destined for. In addition, the propagation delay result is used in conjunction with the result of the transmission delay stage to compute the time at which the packet completes reception (i.e., the time at which the last bit finishes arriving is the time at which the packet begins transmission added to the sum of the transmission delay and the propagation delay). The Simulation Kernel requires that the propagation delay stage procedure accept a packet address as its sole argument. The computed propagation delay is then expected by the Kernel within the TDA represented by the symbolic constants OPC_TDA_RA_START_PROPDEL and OPC_TDA_RA_END_PROPDEL. The assigned values should be nonnegative double-precision floating-point numbers. No other results are required. Syntax requirements for this stage are specified by the following procedure template: 461-Comec

68 Communication Link Models Modeling Concepts Template for Radio Transceiver Pipeline: Propagation Delay Stage void prop_delay_template (Packet* pk) { double start_prop_delay, end_prop_delay; /* extract required information from packet. */ /* perform calculation of propagation delay. */ /* 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); } Comec Stage 6: Receiver Antenna Gain The receiver antenna gain stage is the seventh stage of the radio transceiver pipeline. It is the earliest stage associated with the radio receiver rather than the transmitter, being specified by the receiver s ragain model attribute. It is executed separately for each eligible destination channel, and its invocation takes place at the 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 provided by the receiver s associated antenna, based on the direction of the vector leading from the receiver to the transmitter. The Simulation Kernel does not itself use this result, 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 antenna gain, except that it is due to the physical configuration and implementation of the antenna associated with the receiver object. For information on antenna gain and antenna patterns, refer to section Comec Stage 4: Transmitter Antenna Gain. The Simulation Kernel reserves a TDA, represented by the symbolic constant OPC_TDA_RA_RX_GAIN, to store the result of this stage and to make it available to later stages of the pipeline. The Simulation Kernel requires that the stage s procedure accept a packet address as its sole argument. Syntax requirements for this stage are specified by the following procedure template: 462-Comec

69 Modeling Concepts Communication Link Models Template for Radio Transceiver Pipeline: Receiver Antenna Gain Stage void rx_antenna_gain_template (Packet* pk) { double result; /* extract required information from packet. */ Communication Mechanisms /* 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); } Comec 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 executed separately for each eligible destination channel; invocation takes place immediately after return of the receiver antenna gain model, with no simulation time elapsing in between. The purpose of this stage is to compute the received power of the arriving packet s signal (in watts). For packets that are classified as valid, the received power result is a key factor in determining the ability of the receiver to correctly capture the information in the packet (For information on the channel match model, refer to section Comec Stage 3: Channel Match.)For packets that are classified as noise, received power must usually still be evaluated in order to support calculation of relative strengths of valid and noise packets. In general, the calculation of received power is based on factors such as the power of the transmitter, the distance separating the transmitter and the receiver, the transmission frequency, and transmitter and receiver antenna gains. The Simulation Kernel requires that the received power stage procedure accept a packet address as its sole argument. The computed received power is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_RA_RCVD_POWER. The assigned value should be a nonnegative doubleprecision floating-point number. No other results are required. Syntax requirements for this stage are specified by the following procedure template: 463-Comec

70 Communication Link Models Modeling Concepts Template for Radio Transceiver Pipeline: Received Power Stage void received_power (Packet* pk) { double result; /* extract required information from packet. */ /* 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); } Comec 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 is executed immediately after return of the received power stage, with no simulation time elapsing in between. The purpose of this stage is to represent the effect of all noise sources, except for other concurrently arriving transmissions, since these are accounted for by the interference noise stage. The expected result is the sum of the power of other noise sources, measured at the receiver s location and in the receiver channel s band. Typical background noise sources include thermal or galactic noise, emissions from neighboring electronics, and otherwise unmodeled radio transmissions (e.g., commercial radio, amateur radio, television, depending on frequency). The Simulation Kernel does not itself make use of the result of this stage, but it does 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 to compute a total noise level in the signal-to-noise ratio stage. The Kernel requires that the background noise stage procedure accept a packet address as its sole argument. Syntax requirements for this stage are specified by the following procedure template: 464-Comec

71 Modeling Concepts Communication Link Models Template for Radio Transceiver Pipeline: Background Noise Stage void bkg_noise_template (Packet* pk) { double result; /* extract required information from packet. */ Communication Mechanisms /* 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); } Comec 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 be executed for a packet under two circumstances: the packet is valid and arrives at its destination channel while another packet is already being received; or the packet is valid and already being received when another packet (valid or invalid) arrives. Clearly, the first circumstance can occur at most once for each packet, and the second may occur any number of times depending upon the transmission activities of other transmitters in the model. Note that a single invocation of this stage can be shared by the pipelines of the two packets if both are valid (the call syntax appearing below provides the addresses of both packets to the interference stage so that mutual effects can be evaluated). The purpose of this stage is to account for the interactions between transmissions that arrive concurrently at the same receiver channel. The Simulation Kernel reserves a TDA, represented by the symbolic constant OPC_TDA_RA_NOISE_ACCUM, for the purpose of storing the current level of noise from all interfering transmissions. This accumulator is maintained only for valid packets (as determined by the channel match stage) since there is generally no need to evaluate link quality for noise packets. Thus, the interference noise stage is expected to augment the value of this accumulator in each valid packet by the received power of the interfering packet. When a packet (valid or invalid) completes reception, the Kernel automatically subtracts its received power from the noise accumulator of all valid packets that are still arriving at the channel. In this manner, the accumulator reflects only the current noise level. The Kernel requires that the interference noise stage procedure accept two packet addresses as arguments. The first packet address represents the packet that arrived earliest, and the second represents the new arrival that caused the stage to be invoked. Syntax requirements for this stage are specified by the following procedure template: 465-Comec

72 Communication Link Models Modeling Concepts Template for Radio Transceiver Pipeline: Interference Noise Stage void interference_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); } In addition to the OPC_TDA_RA_NOISE_ACCUM TDA, the Kernel provides a TDA to keep track of the number of collisions experienced by each packet. This TDA is represented by the symbolic constant OPC_TDA_RA_NUM_COLLS and is provided for convenience in developing application-specific pipeline stages that may have a need for this result when deciding whether to accept or reject a packet in the final stages of the pipeline. Although the interference stage is an appropriate location to update this TDA s value, the Kernel makes no use of this TDA and it is therefore not mandatory to maintain its accuracy. Comec Stage 10: Signal-to-Noise Ratio The signal-to-noise ratio (SNR) stage is the eleventh stage of the radio transceiver pipeline, and is specified by the snr model attribute of the radio receiver. It may be executed for a valid packet (as determined by the channel match stage) 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 or invalid) completes reception. Clearly, the first circumstance occurs exactly once for each packet, and the second and third may occur any number of times depending upon the transmission activities of other transmitters in the model. The three types of invocations define intervals over which a packet s average power 466-Comec

73 Modeling Concepts Communication Link Models SNR is taken to be constant (of course, this is an approximation when mobility is involved, since SNR would be continuously varying). The purpose of SNR stage is to compute the current average power SNR result for the arriving packet. This calculation is usually based on values obtained during earlier stages, including received power, background noise, and interference noise. The SNR of the packet is an important performance measure that supports determination of the receiver s ability to correctly receive the packet s content. The result computed by this stage is used by the Kernel to update standard output results of receiver channels and usually also by later stages of the pipeline. Communication Mechanisms The Simulation Kernel requires that the SNR stage procedure accept a packet address as its sole argument. The computed SNR is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_RA_SNR. The assigned value should be a double-precision floating-point number expressed in decibels (db). No other results are required. Syntax requirements for this stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Signal-to-Noise Ratio Stage void snr_template (Packet* pk) { double result; /* extract required information from packet. */ /* 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); } Comec Stage 11: Bit Error Rate The bit error rate (BER) stage is the twelfth stage of the radio transceiver pipeline, and is specified by the ber model attribute of the radio receiver. It may be executed for a valid packet (as determined by the channel match stage) under three circumstances: (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 or invalid) completes reception. These circumstances correspond to the ends of periods during which the packet s SNR is taken to be constant. (For more information on constant-snr intervals, refer to section Comec Stage 10: Signal-to-Noise Ratio.) The purpose of the BER stage is to derive the probability of bit errors during the past interval of constant SNR. This is not the empirical rate of bit errors, but the 467-Comec

74 Communication Link Models Modeling Concepts expected rate, usually based on the SNR. In general, the bit error rate provided by this stage is also a function of the type of modulation used for the transmitted signal. The Simulation Kernel requires that the BER stage procedure accept a packet address as its sole argument. The computed BER is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_RA_BER. The assigned value should double-precision floating-point number between zero and one (inclusive). No other results are required. Syntax requirements for this stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Bit-Error-Rate Stage void ber_template (Packet* pk) { double result; /* extract required information from packet. */ /* perform calculation of bit-error-rate. */ /* place result in TDA for Kernel & later stages. */ op_td_set_dbl (pk, OPC_TDA_RA_BER, result); } Comec Stage 12: Error Allocation The error allocation stage is the thirteenth stage of the radio transceiver pipeline, and is specified by the error model attribute of the radio receiver. It is always executed immediately upon return from the bit error rate stage. The purpose of the error allocation stage is to estimate the number of bit errors in a packet 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 occur over the course of the packet s reception. Bit error count estimation is usually based on the bit error probability (obtained from stage 11) and the length of the affected segment. The Simulation Kernel requires that the error allocation stage procedure accept a packet address as its sole argument. The Kernel maintains only a bit error accumulator TDA within the packet; therefore, the pipeline stage is expected to add the number of new errors into the existing value found in the integer TDA represented by the symbolic constant OPC_TDA_RA_NUM_ERRORS. The added value should be between zero and the number of bits in the affected packet segment. In addition, the Kernel expects the error allocation stage to provide the empirical biterror-rate over the packet segment; this value is obtained by dividing the number of bit errors in the segment by the size of the segment. The empirical bit error rate should be placed in the double-precision TDA represented by the symbolic 468-Comec

75 Modeling Concepts Communication Link Models constant OPC_TDA_RA_ACTUAL_BER. The Kernel uses this value to update the bit error rate result of the receiver channel object. Syntax requirements for the error allocations stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Error Allocation Stage void err_alloc_template (Packet* pk) { int num_added_errs, segment_length; double empirical_ber; Communication Mechanisms /* 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); } Comec Stage 13: Error Correction The error correction stage is the fourteenth and final stage of the pipeline, and is specified by the ecc model attribute of the radio receiver. It is invoked when a packet completes reception, immediately after the final return of the error allocation stage, with no simulation time elapsing in between. Exactly one invocation of this stage occurs for each packet that is considered valid (as determined by the channel match stage). The purpose of this stage is to determine whether or not the arriving packet can be accepted and forwarded via the channel s corresponding output stream to one of the receiver s neighboring modules in the destination node. This is usually dependent upon whether the packet has experienced collisions, the result computed in the error allocation stage, and the ability of the receiver to correct the errors affecting the packet (hence the name of the stage). Based on the determination of this stage, the Kernel will either destroy the packet, or allow it to proceed into the destination node. In addition, this result affects error and throughput results collected for the receiver channel. The Simulation Kernel requires that the error correction stage procedure accept a packet address as its sole argument. The determination to accept or reject the packet is then expected by the Kernel within the TDA represented by the symbolic constant OPC_TDA_RA_PK_ACCEPT. The assigned value should be an integer equal to the constant OPC_TRUE to indicate acceptance; otherwise the integer value OPC_FALSE should be assigned to indicate rejection. No other results are required. 469-Comec

76 Using Paths to Represent Virtual Circuits Modeling Concepts Interface requirements for this stage are specified by the following procedure template: Template for Radio Transceiver Pipeline: Error Correction Stage void error_correction_template (Packet* pk) { int result; /* extract required information from packet. */ /* determine if packet should be accepted or rejected. */ /* place result in TDA to return to Simulation Kernel. */ op_td_set_int (pk, OPC_TDA_RA_PK_ACCEPT, result); } 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 protocol models determine exactly when and how to use a particular path. Refer to the relevant model documentation for information on how particular models utilize paths. A path is a defined route between two sites; a site can be either a fixed node object or subnetwork. The process of defining a path is similar though not identical to defining a link. First you configure an object palette to include the path models you want (as described the System Menus chapter of the Editor Reference manual), then you select a model and click on objects in the Project Editor workspace to connect them. Comec.5.1 Path Model Options Each path model has a set of options that determine the path connectivity requirements and the types of objects that you can include in a path definition. You can view a model s options in the Path Model Description dialog box, which you open by right-clicking on a model in the object palette. You should verify that the underlying model s options allow you to create the type of path you want. If you cannot find a path model whose options exactly match the type of path you want to create, you may want to derive a new model from an existing one. 470-Comec

77 Modeling Concepts Using Paths to Represent Virtual Circuits Path Model Description Dialog Box Communication Mechanisms path options Path Connectivity A path object defines, at the very least, two end sites. It may also define a partial or complete path (that is, a set of connecting sites and links) between these sites. The Path Connectivity option defines the extent to which you can define this intermediate path. The three possible settings are: Links Required In a required-link path, you must specify a simplex or duplex point-to-point link between every site included in the path; all such links are included in the path definition. Links Ignored In an ignored-link path, you can only include sites in the path definition. The underlying models fully determine routes between the included sites. Links Optional This is a combination of the required-link and ignored-link types. You must define the head, tail and any intermediate sites, but defining any connecting links between sites is optional. The following diagram shows a router network connecting a site in Canada to one in Texas. Traffic constrained by the required-link path (left) always follows the exact 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. The optional-link path (right) defines a partial route that includes the link between Canada and router E; the underlying models route the traffic between router E and Texas. 471-Comec

78 Using Paths to Represent Virtual Circuits Modeling Concepts Keep in mind that in a situation like this, with multiple paths defined between the same two sites, the underlying models choose the actual path taken by a packet. Other Path Options Other path options are: Packet Formats Each path has a defined set of supported packet formats. You cannot define a link as part of a path unless that link supports all formats included in the path model s Packet Formats field. (Note that if a path supports no packet formats, you can include any link in the path definition.) Two Endpoints Only If this option is set to Yes, you can only create single-segment paths. Subnets Ignored If this option is set to Yes, you cannot include a subnetwork object in a path definition. (However, you can still include nodes from different subnets in the same path.) Allow Cycles If this option is set to No, you can only include each link 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 models you want. 2) Left-click on a path model in the object palette to select it. The cursor changes appearance to indicate that you are in path-creation mode. 472-Comec

79 Modeling Concepts Using Paths to Represent Virtual Circuits A path object s underlying options (described in Path Model Options on page 470) determine the objects you can and cannot include in your path definition. Once you are in path-creation mode, OPNET Modeler provides extensive visual feedback to indicate valid and invalid additions to your path. If you move the cursor over an invalid link or site, the cursor changes appearance and a tooltip appears to indicate why that choice is invalid. Communication Mechanisms Visual Feedback in Path-Creation Mode Feedback for valid objects Feedback for invalid objects 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 links that 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 sites that have multiple links connecting them. 5) Repeat step 4 until you have clicked on the tail site and the path definition is complete. 6) Right-click in the project workspace and choose Finish Path Definition from the pop-up menu. OPNET Modeler auto-assigns a unique name to the new path. 473-Comec