TECHGRAM

 The Pareto On/Off Traffic Generator (POO_Traffic) is a traffic generator (an application) embodied in the OTcl class Application/Traffic/Pareto. POO_Traffic generates traffic according to a Pareto On/Off distribution. Packets are sent at a fixed rate during on periods, and no packets are sent during off periods. Both on and off periods are taken from a Pareto distribution with constant size packets. These sources can be used to generate aggregate traffic that exhibits long range dependency. For other traffic generators, refer to the  NS manual . Usage Example A new Pareto On/Off traffic generator can be created as follows: set p [new Application/Traffic/Pareto] $p set burst_time_ 500ms $p set idle_time_ 500ms $p set rate_ 200k $p set packetSize_ 210 $p set shape_ 1.5 Detailed Explanation Input parameters: burst_time_ : Mean On (burst) time idle_time_ : Mean Off (idle) time rate_ : Send rate during burst packetSize...

To build a simple drop-tail router output queue that uses a round-robin dequeue scheduling for priority 15 packets (from a "MmApp" over "UDPmm") and the other packets in the queue. That is, while priority 15 packets and other packets coexist in the queue, it dequeues the oldest packets of each type one by one in turn. (Tested with ns-2.1b8a, ns-2.1b9a and ns-2.26) Design The queue has two logical FIFO queues, say LQ1 and LQ2, of which the total size is equal to the size of physical queue (PQ), i.e. LQ1 + LQ2 = PQ. To implement a normal drop-tail enqueue behavior, when a packet is to be enqueued, the enqueue manager checks if size of LQ1 + LQ2 is less than maximum allowed PQ size. If so, the packet will be enqueued to an appropriate logical queue. To implement the round-robin dequeue scheduling, the dequeue manager tries to dequeue one packet from a logical queue and the next one from the other logical queue in turn. I.e. packets in the two logical queues are dequeue...

  Here, we describe the necessary steps to include the new developed RTP/RTCP module with the other built-in NS-2 modules, without needing to replace the native implementation for these protocols. We assume the reader has successfully installed a current NS-2.XX version. This code has been developed and tested with NS-2.33 and NS-2.34.  In the legacy code, RTP and RTCP protocols are implemented as the RTP Agent and the RTCP Agent classes, respectively. These two classes are implemented in the rtp.cc (located in ~ns-2.XX/apps/rtp.cc) and rtcp.cc (located in ~ns-2.XX/tcp/rtcp.cc) files, as can be appreciated in Figure 1.  The RTP Agent holds all the functionalities for sending and receiving data packets, whereas the RTCP Agent is responsible for the control reports transmission and reception. The RTP Session class (implemented in ~ns-2.XX/common/session-rtp.cc) mainly deals with feedback report building and participant’s information tables maintenance, through the received ...