Ns2.35 satellite network simulation Learning

After reading so many papers, we should start the actual simulation now !!!

First, ns2.35 comes with the constellation configuration of iridium and Teledesic. In NS/Tcl/ex, let's take a look at the constellation configuration of iridium.

The following table lists the parameters of the Iridium constellation:

The interval between plane and adjacent orbital planes is 31.6 °, and the gap is 22 °, which is not even.

11 stars on each rail plane, so

The phase factor of different orbital planes is, 16.36/5.454545 = 3, which is exactlyHalf of the phase difference in the orbital plane

In the NS/Tcl/ex example, node and link are separated into two files separately. Part of the node file is as follows:

set plane 1set n0 [$ns node]; $n0 set-position $alt $inc 0 0 $planeset n1 [$ns node]; $n1 set-position $alt $inc 0 32.73 $plane set n2 [$ns node]; $n2 set-position $alt $inc 0 65.45 $plane set n3 [$ns node]; $n3 set-position $alt $inc 0 98.18 $planeincr plane  set n15 [$ns node]; $n15 set-position $alt $inc 31.6 16.36 $plane set n16 [$ns node]; $n16 set-position $alt $inc 31.6 49.09 $plane set n17 [$ns node]; $n17 set-position $alt $inc 31.6 81.82 $plane

In order to make the switchover better, the next satellite set in nodetcl is a satellite on the same orbital plane. It should be assumed that the satellite at the zero position is a rising orbit.

# By setting the next_ variable on polar sats; handoffs can be optimized$n0 set_next $n10; $n1 set_next $n0; $n2 set_next $n1; $n3 set_next $n2$n4 set_next $n3; $n5 set_next $n4; $n6 set_next $n5; $n7 set_next $n6$n8 set_next $n7; $n9 set_next $n8; $n10 set_next $n9$n15 set_next $n25; $n16 set_next $n15; $n17 set_next $n16; $n18 set_next $n17$n19 set_next $n18; $n20 set_next $n19; $n21 set_next $n20; $n22 set_next $n21$n23 set_next $n22; $n24 set_next $n23; $n25 set_next $n24

After the node is set, set the satellite link in linktcl, including the intra-orbital and inter-orbital links.

# Now that the positions are set up, configure the ISLs# Plane 1 intraplane$ns add-isl intraplane $n0 $n1 $opt(bw_isl) $opt(ifq) $opt(qlim)$ns add-isl intraplane $n1 $n2 $opt(bw_isl) $opt(ifq) $opt(qlim)$ns add-isl intraplane $n2 $n3 $opt(bw_isl) $opt(ifq) $opt(qlim)# Interplane ISLs# 2 interplane ISLs per satellite (one along the seam)# Plane 1-2$ns add-isl interplane $n0 $n15 $opt(bw_isl) $opt(ifq) $opt(qlim)$ns add-isl interplane $n1 $n16 $opt(bw_isl) $opt(ifq) $opt(qlim)$ns add-isl interplane $n2 $n17 $opt(bw_isl) $opt(ifq) $opt(qlim)

Set parameters in the master TCL file:

global optset opt(chan)           Channel/Satset opt(bw_down)        1.5Mb; # Downlink bandwidth (satellite to ground)set opt(bw_up)          1.5Mb; # Uplink bandwidthset opt(bw_isl)         25Mbset opt(phy)            Phy/Satset opt(mac)            Mac/Satset opt(ifq)            Queue/DropTailset opt(qlim)           50set opt(ll)             LL/Satset opt(wiredRouting) OFFset opt(alt)            780; # Polar satellite altitude (Iridium)set opt(inc)            86.4; # Orbit inclination w.r.t. equator

Set the ground terminal node:

# Set up terrestrial nodes$ns node-config -satNodeType terminalset n100 [$ns node]$n100 set-position 37.9 -122.3; # Berkeleyset n101 [$ns node]$n101 set-position 42.3 -71.1; # Boston

Add a star-to-ground link. The ground terminal node can be connected to the satellite node as needed, because the switch manager will reset it to the satellite node visible to the ground terminal.

# Add GSL links# It doesn't matter what the sat node is (handoff algorithm will reset it)$n100 add-gsl polar $opt(ll) $opt(ifq) $opt(qlim) $opt(mac) $opt(bw_up) \  $opt(phy) [$n0 set downlink_] [$n0 set uplink_]$n101 add-gsl polar $opt(ll) $opt(ifq) $opt(qlim) $opt(mac) $opt(bw_up) \  $opt(phy) [$n0 set downlink_] [$n0 set uplink_]

Configure the ground terminal for CBR-UDP traffic

# Attach agentsset udp0 [new Agent/UDP]$ns attach-agent $n100 $udp0set cbr0 [new Application/Traffic/CBR]$cbr0 attach-agent $udp0$cbr0 set interval_ 60.01

This is the content of the generated trace file:

+ 1.00006626 CBR 210 ------- 0 66.0 67.0 00 37.90-122.30 48.90-120.94

-1.000066 26 CBR 210 ------- 0 66.0 67.0 0 37.90-122.30 48.90-120.94

R 1.006366 26 CBR 210 ------- 0 66.0 67.0 0 37.90-122.30 48.90-120.94

+ 1.0063 26 37 CBR 210 ------- 0 66.0 67.0 0 48.90-120.94 32.60-87.51

-1.0063 26 37 CBR 210 ------- 0 66.0 67.0 0 48.90-120.94 32.60-87.51

R 1.0186 26 37 CBR 210 ------- 0 66.0 67.0 0 48.90-120.94 32.60-87.51

+ 1.0186 37 48 CBR 210 ------- 0 66.0 67.0 0 32.60-87.51 48.90-57.74

-1.0186 37 48 CBR 210 ------- 0 66.0 67.0 0 32.60-87.51 48.90-57.74

R 1.0300 37 48 CBR 210 ------- 0 66.0 67.0 0 32.60-87.51 48.90-57.74

+ 1.0300 4867CBR 210 ------- 0 66.0 67.0 0 0 48.90-57.74 42.30-71.10

-1.0300 48 67 CBR 210 ------- 066.0 67.0 0 0 48.90-57.74 42.30-71.10

R1.036448 67 CBR 210 ------- 0 66.0 67.0 0 0 48.90-57.74 42.30-71.10

+31.010066 26 CBR 210 ------- 0 66.067.0 1 1 37.90-122.30 47.12-120.81

-31.0100 66 26cbr 210 ------- 0 66.0 67.0 1 1 37.90-122.30 47.12-120.81

R 31.0157 66 26cbr 210 ------- 0 66.0 67.0 1 1 37.90-122.30 47.12-120.81

+ 31.0157 26 37cbr 210 ------- 0 66.0 67.0 1 1 47.12-120.81 30.81-87.48

-31.0157 26 37cbr 210 ------- 0 66.0 67.0 1 1 47.12-120.81 30.81-87.48

R 31.0282 26 37cbr 210 ------- 0 66.0 67.0 1 1 47.11-120.81 30.81-87.48

Every time the path is 66-26-37-48-67, is a virtual node policy used? Not mentioned in the manual either?

 

 This is the drawing of latency, Which is cyclical. Why is the latency different at different times?

Next, let's take a look at the coordinate system of the satellite in NS2. in satgeometry. H,. CC, we first define some constants and computational macros.

// Various constants # define PI 3.1415926535897 # define Mu 398601.2 // Greek Mu (km ^ 3/s ^ 2) # define light 299793 // km/s # define earth_period 86164 // seconds # define earth_radius 6378 // km # define geo_altitude 35786 // km # define atmos_margin 150 // km # define deg_to_rad (x) (x) * PI/180) # define rad_to_deg (x) * 180/PI) # define distance (s_x, s_y, s_z, e_x, e_y, e_z) (SQRT (s_x-e_x) * (s_x-e_x) \ + (s_y-e_y) * (s_y-e_y) + (s_z-e_z) * (s_z-e_z) the coordinate system adopts the struct coordinate {Double R; // km double Theta; // radians double Phi; // radians // convert to Cartesian as follows: // X = rsin (theta) Cos (PHI) // y = rsin (theta) sin (PHI) // z = rcos (theta )};

There are two spherical coordinate systemsOne set is orbital-centered. Here Theta is 90-Theta, which is the real spherical coordinate system.

Satgeometry defines some methodsSuch as distance calculation, Polar Coordinate and Cartesian coordinate transformation, propagation delay calculation, obtaining latitude and longitude height, and verifying whether the elevation is above the lowest elevation, verify that two satellites of the same height are visible (taking into account the shielding of the earth's atmosphere for 150 km)

The command method is used to access the C ++ class from OTCL.

// Library of routines involving satellite geometryclass SatGeometry : public TclObject {public:SatGeometry() { printf("Started\n");}static double distance(coordinate, coordinate);              static void spherical_to_cartesian(double, double, double,    double &, double &, double &);static double propdelay(coordinate, coordinate);static double get_latitude(coordinate);static double get_longitude(coordinate);static double get_radius(coordinate a) { return a.r; }static double get_altitude(coordinate);static double check_elevation(coordinate, coordinate, double);static int are_satellites_mutually_visible(coordinate, coordinate);protected: // Define "command" appropriately if you want OTcl access to this class        int command(/*int argc, const char*const* argv */) { return 0; }};