Wnlab

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Author: [[mailto:raffaello.secchi@isti.cnr.it|Raffaello Secchi]]

Year: 2006 License: MIT

Realistic simulations of a satellite environment require to account for the effects of satellite medium access control behavior on networking layer and transport protocols. In particular, the technique employed to assign the time slots in a TDMA satellite frame may affect significantly the dynamic of TCP startup and its responsiveness to bandwidth changes. In order to evalutate the dynamic of TCP over satellite links, we realized a simulator of TDMA MAC into NS2 simulator that explicitly accounts for the Bandwidth-on-Demands mechanims used to share satellite bandwith among several ground terminals.
Incorporating the information acquired from long measurement sessions over satellite links, our tool try to accurately emulate the behavior of a satellite platform. Moreover, the simulator can be easily configured to include different algorithms for time-slot assignment/allocation.

==== Simulator Architecture and Internals ====

The NS2 support for satellite networking enables the simulation of both geo-stationary satellite (repeater or regenerative) and polar orbiting constellations. The supported MAC are Unslotted-Aloha (with or without collision detection) and TDMA. The figure below illustrates the main elements of a TDMA satellite node.

==== Proportional Allocator ====

The currently supported allocation algorithm is the proportional method. According to proportional scheme the bandwidth assigned to each active terminal is proportional to the submitted request. The Allocator agents computes the sum R of all elements of the request vector Ri and assign to traffic terminal a number time-slot equals to Ns*(Ri/R), where Ns is the number of slot per frame. Since Ns*(Ri/R) isn't generally an integer, the number of assigned slot is approximated to the smaller integer larger (or equal) than Ns*(Ri/R). Also, the Allocator store the extra fraction of slot assigned to every terminal in a vector, that must be subtracted from allocation in subsequent period.
==== Installation Instruction & Validation ====

This web page reports the instructions to install and configure simulation interface.

== For NS 2.33 ==

  - Download the package {{:tdmadama-ns-2.33.tar.bz2|tdmadama-ns-2.33}}
  - Read the README file included in the package and follow the instructions to install the module.
  - From the 'examples' directory, execute the script example-tdmadama.tcl and check the outputs, as in the examples, using the {{analy.c|analy}} utility source code.

The script simulates a single satellite terminal connected to an Internet host via a satellite gateway. The traffic offered to the terminal is a sequence of TCP Sack connections whose starting time is scheduled according to a Poisson process. The amount of data carried by each connection is variable and it is drawn from an exponential distribution. The traffic load offered to the terminal is a function of the average number of packets of individual connections ( $data(bunch) ),  the size in bytes of a TCP segment ( $data(packets) ),  the total transponder capacity in byte/s ( $capSaT ), and the average inter-arrival time between TCP connections. It is given by the following expression:

  set data(load)   [expr $data(bunch)*$data(packet)*8/($capSAT*$data(next))]

whose content is shown before the simulation is run. At the end of simulation an estimate of the average completion time of connection is provided together with its confidence interval. The script outputs four files tagged as -bod or -scpc depending on command line arguments. The file "event" is the TDMA-DAMA output whose format is described in the paper. The file "out" is the standard ns-2 output for queue tracing. The latter is processed at the end of simulation run to obtain the traces shown in the eps graphs. These graphs display the bandwidth allocated and the throughput of the terminal.
These graphs show the significant bandwidth saving of DVB-RCS (ETSI EN 301 790) DAMA when it is used to replace existing SCPC systems. The degradation in terms of completion time is instead minor.

== For NS 2.26, 2.28, and 2.29 (Discontinued) ==

1) Download the patch {{:ns-allinone-2.29-tdma.patch}} for NS-2.29 or {{:ns-allinone-2.28-tdma.patch}} for NS-2.28

2) Unpack ns-allinone-2.29.tar.gz and apply patch:

  tar xvzf ns-allinone-2.29.tar.gz
  patch -p0 < ns-allinone-2.29-tdma.patch

3) Install the package (possibly) using gcc version 3.3.6:

  cd ns-allinone-2.29
  ./install

The patch ns-allinone-2.28-tdma has been compiled and tested with gcc-4.0.4 and g++-4.0.4 by applying to ns-2.28 the patch ns228-gcc402.patch that you can download from [[https://www.ececs.uc.edu/~cdmc/ucbt/|here]] from download section.

A previous patch (no further developed) for simulator NS-2.26 is also available ns-allinone-2.26-tdma.patch. In order to apply this patch follow the above procedure substituting the tag 2.29 with 2.26.

Alternatively, the manual installation of simulator sources is also possible.

1) Download the tarball {{:sources-ns-2.29.tar.gz}} or {{:sources-ns-2.28.tar.gz}} and unpack to local directory:
  wget http://ala.isti.cnr.it/wnlab/_media/sources-ns-2.29.tar.gz
  tar xvzf sources-ns-2.29.tar.gz.

2) Copy (in case overwriting existing files) the files: "mac-tdma.cc", "mac-tdma.h" and "mac-bod.cc" in ns-2.29/mac directory; the file "Makefile.in" in ns-2.29 directory; and "ns-default.tcl" and "ns-sat.tcl" in ns-2.29/tcl/lib/

3) Compile ns-2.29 following standard procedure.

In order to validate the compiled simulator download and run the script file {{test-tdma.tcl}}. This script file generate a scenario with two satellite terminals (ter(0) and ter(1)) and a geostationary bent pipe satellitar node. It then schedule a TCP Sack connection with source on ter(0) and receiver on ter(1). The simulation outputs two trace files: __event.tr__ and __out.tr__. While the out.tr is the trace of terminal queues in ns-2 format, the event.tr dumps all the events that occur in MAC layer, such as marking the beginning of a frame or the complete delivery of a packet from the terminal.

==== Simulator Interface & Configuration ====

The TDMA simulator is provided with a TCL interface that allows the configuration of TDMA frame and the definition of the allocation mechanism. The following table reports the TDMA parameters together with their meaning:

  * ''max_slot_num'': number of slots per frame (excluded preamble)
  * ''slot_packet_len'': size of a slot (bytes)
  * ''num_frame_'': number of frames between successive bandwidth requests
  * ''bandwidth_'': overall satellite link capacity

Thus, we could introduce the following positions at the beginning of simulation script in order to correctly configure the terminals and satellite objects

  Mac/Tdma set max_slot_num_ 47
  Mac/Tdma set slot_packet_len_ 1504
  Mac/Tdma set num_frame_ 3
  Mac/Tdma set bandwidth_ 2112Kb
  global opt
  set opt(chan) Channel/Sat
  set opt(bw_up) 2.112Mb ;# uplink bandwidth
  set opt(bw_down) 38.016Mb ;# downlink bandwidth
  set opt(phy) Phy/Sat
  set opt(mac) Mac/Tdma
  set opt(ifq) Queue/DropTail
  set opt(qlim) 1500 ;# queue size (pkts)
  set opt(ll) LL/Sat
  set opt(wiredRouting) OFF

Specifically, the array opt defines the type of the objects that make up a terminal node and configure their attributes. Then, satellite object and terminals are instatiated using the following procedure:

  ;# configure and create the satellite node "sat"
  node-config -satNodeType geo-repeater \
  -phyType Phy/Repeater \
  -channelType $opt(chan) \
  -downlinkBW $opt(bw_down) \
  -wiredRouting $opt(wiredRouting)
  set sat [$ns node]
  
  ;# configure and create the terminal node "ter"
  $ns node-config -satNodeType terminal \
  -llType $opt(ll) \
  -ifqType $opt(ifq) \
  -ifqLen $opt(qlim) \
  -macType $opt(mac) \
  -phyType $opt(phy) \
  -channelType $opt(chan) \
  -downlinkBW $opt(bw_down) \
  -wiredRouting $opt(wiredRouting)
  
  set ter [$ns node]
  $ter add-gsl geo $opt(ll) $opt(ifq) $opt(qlim) $opt(mac) \
  $opt(bw_up) $opt(phy) [$sat set downlink_] [$sat set uplink_]


The last command setups a bidirectional connection between satellite node and the terminal node using parameters previously indicated opt. Once that the sat and ter objects have been created and connected, the Allocator and Requester objects must be installed into terminals. Note that a Requester object is needed for each terminal, but only one Allocator object for the whole satellite network is needed.

  set alc [$ter install-requester Allocator/Proportional]
  set req [$ter install-requester Requester/Constant]


The definition of Requester and Allocator must specify the subclass of the objects. The object name can be used during simulation run-time to dynamically change the properties of Allocator and Requester. In particular, the request_ internal variable of Requester object gives the possibility to dinamically modify the request submitted by terminal to allocator and and to define a customized allocation algorithm via TCL. The simulator is endowed with a tracing support, which can be enabled through the following commands:

  set ev_file [open event.tr w]
  $ter trace-event $ev_file

Packets coming from upper layers are first processed by a link layer (LL) agent, which is responsible for packet filtering and collision detection, then enqueued into IFq queue.
When is time to trasmit, the Mac/Tdma agent deques a packet (if any) from IFq and forwards it to the physical layer. At the end of transmission packet the Mac/Tdma agent will deliver another packet if the time-slot is not yet finished. Furthermore, partial transmission of packets is supported. This means that, if at the end of time-slot the transmission of packet is not finished, the remaing amount of data will be delivered in the next slot.
The requester/allocator blocks take part in the time-slot assignment procedure. Every predetermined number of frames each node's Requester submits a request to the master controller. Various mechanism of request computation are supported based on the monitoring of the amount of data enqueued in IFq during the previous allocation period.
The Allocator reads the vector of requests of all traffic terminal and generates a vector of allocations, which is scheduled delay_ seconds (configurable parameter) in the future in order to account for allocation delay.
Note that, while a different Requester is installed for every terminal (which in case could have different behaviors), only one terminal is chosen as Allocator.

==== History ====

==== Add ons ====
Wnlab

User Tools

Site Tools

Page Tools
