Int'l J. of Communications, Network and System Sciences
Vol.07 No.10(2014), Article ID:50525,9 pages

The COMMStellationTM Satellite Constellation for Broadband Communication System Model in NS-2

Anupon Boriboon1, Siriwhaddhanah Pongpadpinit2

1School of Science and Technology, Assumption University, Bangkok, Thailand

2Advanced Communications and Multimedia Research Laboratory (ACM), School of Science and Technology, Assumption University, Bangkok, Thailand


Copyright © 2014 by authors and Scientific Research Publishing Inc.

This work is licensed under the Creative Commons Attribution International License (CC BY).

Received 12 August 2014; revised 6 September 2014; accepted 5 October 2014


This paper presents the evaluation performance of a hybrid satellite constellation network which provides internet access based Transport Control Protocol (TCP). The evaluated satellite network uses the constellation topology operating on Low Earth Orbit (LEO). The COMMStellationTM satellite system implemented using network simulator 2 (NS-2). In this paper, we modified a congestion window control based on TCP Westwood. The results show that the proposed technique reduces end-to-end (E2E) delay of transmitting packets. Hence the number of retransmission packets reduced.


COMMStellationTM, NS-2, Satellite, TCP

1. Introduction

The trend of broadband Global Area Network (GAN) is a global satellite internet network. An internet over satellite has developed on each orbit such as Inmarsat providing three geostationary satellites, O3b networks launching eight satellites into medium earth orbit satellite constellation. But, the unsolvable issue of the round trip time (RTT) on a satellite link is very high. To challenge the lowest RTT, the Low Earth Orbit (LEO) satellite constellations for internet satellite have been proposed, using orbits much lower than the geostationary orbit.

Microsat Systems Canada Inc. (MSCI) [1] is being attempted to provide firmly global coverage communications to the public. The global backhaul issues are relieved by help of development in satellite communications constellation, also it connects rural and remote areas of the world where fiber infrastructure is cost limiting.

The initiative of the COMMStellationTM is to supply, produce, deploy and perform the COMMStellationTM constellation of satellites designed to prepare high speed network communications to global customers. It is designed to provide internet backhaul in an area where optical fiber networks do not exist. In this application typical customers consist of existing network of private customers. Each COMMStellationTM satellite will provide high-speed communication with wider-communication bandwidth. By using COMMStellation satellite, which provides high speed backhaul, each ISP only needs to connect their existing network to utilize the satellite system. Some potential use of the COMMStellationTM communications bandwidth includes: 1) Video conferencing and other corporate communications; 2) Strategic communications for government, military, or corporations; 3) Distance learning and telemedicine; 4) Remote environmental monitoring; 5) Distribution of cable television; 6) Arctic communication; 7) Special purpose low latency communications; 8) High bandwidth burst data transmissions form remote sensors, ships, or exploration vessels or sites and; 9) Other special purpose communications.

We study static dimensioning case for a COMMStellationTM of non geosynchronous earth orbit satellite network and show the feasible topology regions and effective cost comparisons are different various transport control protocols. The rest of this paper is organized as follow: Section 2 describes the constellation system. Section 3 is the proposed COMMStellationTM satellite system model. The proposed TCP protocol module is described in Section 4. Simulation results present in Section 5, whereas our conclusions are drawn in Section 6.

2. COMMStellationTM Satellite System

COMMStellationTM satellite system is an orbit with an altitude range around 1000 km. It consists of 72 microsatellites which are arranged in six orbital planes with an additional 2 redundant microsatellite in every orbit. Planes have a near-circular orbit, with co-rotating planes spaced 30 degree apart as shown in Figure 1. The minimum elevation angle for an earth station is 10 degree, which maximizes the coverage area of the satellite and improves the link quality when compares with to lower elevation angles. Lower elevations increase multipath fading and have a negative impact on link quality. Average satellite in view time is approximately 10 - 12 minutes, depending on latitude of ground station [1] [2] . The orbital parameters are show in Table 1.

The ground side of the link has two types of stations: 1) Trunk station that is connected to the high-speed Internet backbone and 2) user stations. A given user station is planned to be current or new Internet Service Provider (ISP), which allows individual clients to connect to its satellite link [1] . The COMMStellation satellite aims to provide its services to existing or new ISPs.

3. Proposed COMMStellationTM Satellite System in Network Simulation (NS-2)

The simulation tool which has been used in this research was based on Network Simulator (NS) version 2.34 [4] .

Figure 1. COMMStellationTM constellation layout [3] .

Table 1. Simulation parameters.

NS-2 is an open source software, which is available for public and can be obtained from the Information Sciences Institute (ISI) [5] .

3.1. Network Topology

Figure 2 illustrates the network topology which uses in this work. All the links between Trunk stations were setup as STM-4 transmission duplex into Internet backbone and STM-1 transmission duplex for Internet backbone communication links with propagation delay of 1 and 5 msec respectively. The DropTail queuing [4] is applied on the queuing system.

Recommended satellite constellation parameters [1] [2] are shown in Table 1. In our experiments, four user station links in different areas around South East Asia are chosen to observe network traffic. The source nodes are located in Bangkok-Thailand, Yangon-Myanmar, Vientiane-Laos, and Oil platform-Indian Ocean. The destination nodes are at Boston-Massachusetts, Tallahassee-Florida, Saint Paul-Minnesota, and Lincoln-Nebraska respectively. Then we will focus on the result of one pair from Bangkok to Boston in this paper.

3.2. Visualize NS Satellite Constellation Configurations

In this paper, we consider the topology of Walker [1] where to topology of LEO constellation similar to COMMStellationTM satellite system. We snapshot of satellite positions at a given one time to roll-out a feasible COMMStellationTM system in NS-2. Figure 3 illustrates the constellation satellite which surrounds the earth. It consists of 72 satellites for six orbital planes and the space between orbital planes is 30 degrees. This is a typical Walker constellation configuration.

In order to optimize the connection between satellite link, the trunk stations on mainland are assigned. We snapshot of trunk station positions to roll-out a feasible COMMStellationTM system. Figure 4 illustrates ground stations that function as dedicated trunk station [1] . The optimal location of non-existing trunk ground stations has been established through simulation to provide optimal overlap, i.e. full coverage with the minimum number of satellites to optimize cost. Simulations include existing ground assets to maximize use of those assets. Assuming that all ground stations contact are made at a minimum elevation of 10 degrees.

Figure 5 illustrates the Internet backbone topology which uses in this work. We assume that each continent has fiber link to connect together and with low latency delay between them. STM-1 assume to be the SDH ITU-T fiber optic network transmission standard with a bit rate of 155.52 Mbps. Due to complexity of the system parameters and to simplify the analysis we also assume that it has dividing the earth zones.

In this research, new and efficient of constellation satellite system mechanisms are proposed COMMStellationTM system into LEO orbital to presented feasible network topology in NS-2. Although more realistic scenarios could have been selected in the simulations, the potential of our model should remain the same. For propagation delays between satellites to ground stations and high altitude of the constellation, these can be considered the most important cost factor in next our satellite networks research.

Figure 2. Constellation hybrid satellite layout.

Figure 3. Constellation satellite layout.

3.3. Traffic Load: TCP in the Satellite Environment

The Transmission Control Protocol (TCP) is an important for transport layer, thus it is the major transport protocol to combine the TCP/IP protocol suite over satellite networks. Communication between sources to destinations has a comparative round-trip time (RTT). This means that considerable time is needed in slow start, on opening a new connection for TCP, to increase its throughput to what the link capacity will bear. After an errored packet is inferred as lost due to congestion, and the congestion window is reduced.

Given the widespread use of TCP/IP based applications and interconnection with the terrestrial Internet, it is likely that broadband satellite network will transport large amounts of traffic generated by TCP’s algorithms, even if the satellite networks are not themselves based on the IP packet structure [5] .

The desire to utilize satellite capacity efficiently has led to the development of a number of optimized for satellite TCP variants, with altered transmission control behavior. These run between ground terminals across the satellite link, while other TCP implementations complete the end-to-end (E2E) communication across the terre- strial Internet. The E2E TCP connection across the congestion but relatively link error free terrestrial Internet

Figure 4. Trunk stations layout.

Figure 5. Internet backbone layout.

and the less congestion but more error prone satellite link is split into individual TCP connections tailored to each environment; this is easy to do with a FTP.

Improvements in coding on satellite links have altered the link error characteristics to be in one of two states: either error free or extremely errored. With a correctly dimensioned satellite link, we can assume that the satellite link has packet error rate of 2% as destination terrestrial link [6] .

4. Proposed TCP Protocol Module

Characteristics of satellite channel are long propagation delay, great bandwidth asymmetry, and high sporadic bit error rate. All these traits have significant impact on transmission performance of TCP satellite network. One of the most interesting aspects of TCP is a mechanism for congestion control. Recall that in the Internet, delay or packet loss is more likely to be caused by congestion than a hardware failure, and that retransmission can exacerbate the problem of congestion by injecting additional copies of a packet. To avoid congestion collapse, TCP uses changes in delay as a measure of congestion, and responds to congestion by reducing the rate at which it retransmits data. TCP’s four intertwined congestion control algorithms are slow start, congestion avoidance, fast retransmit, and fast recovery [7] .

TCP Westwood aims to limit the consequences of the losses introduced by a wireless channel. To this end, TCP Westwood introduces a modification of the fast recovery algorithm called faster recovery. Instead of halving the congestion window after three duplicate ACKs, and fixing the slow start threshold (ssthresh) to this value, TCP Westwood sets the ssthresh as a function of the estimated available bandwidth. In this way, channel losses do not cause the dramatic slow-down of the transmission rate typical of the standard versions [8] [9] .

This paper proposes a new technique which increases the congestion window value after the connection setup in transmission control protocol for suitable over satellite link. According to simulation and analysis, the new protocol not only can increase the throughput for the forward link, but also greatly reduces average end-to-end packet delay time rate of the link, compared with the traditional TCP protocols and transmission control protocol which is proposed according to traits of satellite links in recent year.

4.1. Slow Start Threshold and Congestion Window

Reference [10] TCP uses the slow start algorithm early in the connection lifetime to grow the amount of data that may be outstanding at a given time. Slow start increases the congestion window by the number of data segments acknowledged for each received acknowledgement. Thus the congestion window grow exponentially and increases in size until packet loss occurs, typically because of router buffer overflow, at which point the maximum capacity of the connection has been probed and the connection exits slow start to enter the congestion avoidance phase.

The aim of slow start algorithm is to probe the network to check the available capacity by gradually increasing the cwnd, instead of starting with a high fixed value that may cause congestion. Initial window, the initial value of cwnd, must be less than or equal to maximum segment size (MSS) bytes. The initial value of ssthresh may be arbitrarily high, but is immediately reduced in response to the first congestion episode. The slow start algorithm is used when cwnd < ssthresh. During slow start, a TCP increases cwnd by MSS bytes for each ACK received that acknowledges new data. The slow start phase terminates when the cwnd exceeds the ssthresh or when a packet is lost [8] [11] . Which increase the congestion window, as show in (1)


where c is congestion window, w is initial window for that times, t is smaller recorded round trip time estimate, r is exponential averaging coefficient.

4.2. Psedocode

The pseudocode of the algorithm is represented as


IF tcph-> seqno ( )>last ackTHEN

recvnewack helper (pkt)

IF lastack= 0 AND last ack =delay growth THEN

cwnd = ( cwnd + initial window ( ) )* ( smaller recorded rtt estimate

+ exponential averaging coefficient ) * 0.5

ELSE IF tcph-> seqno ( ) = last ack THEN

IF CONSTRUCTORhdr flags MEMBER access (pkt) ->eln AND eln THEN

tcpeln (pkt)

IF dupacks + dupacks = numdupacks THEN

dupack action ( )


From pseudo code, as well in the congestion window (cwnd) in TCP Westwood standard is cwnd = initial window ( ). But, the SS strategy has replaced the old configuration in TCP Westwood. Then we called TCP Westwood-SS, we modified congestion window to increase the value size itself. Thus, value size of cwnd in every update becomes cwnd = (cwnd + initial window ( )) * (smaller recorded rtt estimate + exponential averaging coefficient) * 0.5. The concept for modify for calculate the new congestion window size in every update was come from FAST TCP [12] and slow start for high speed networks [13] . The procedure of window initialize in TCP Westwood is when a new connection is established with a host on network, the congestion window is initialized into one segment. Each time an ACK is received the congestion window is increased by one segment. The sender from source node can transmit up to the minimum of the congestion window and the advertised window. The congestion window is flow control imposed by the sender, while the advertised window is flow control imposed by the reviver. After modified procedure of initial window for TCP Westwood into TCP Westwood-SS, each time an ACK is received the congestion window is an exponential increase, although it is not exactly exponential. The TCP Westwood is chosen to improve the congestion window in a wireless link, so causes of the oscillatory behaviour of TCP Westwood. It was make an unstable at large bandwidth delay. Even if our modification algorithm in the TCP Westwood, then we called TCP Westwood-SS make the congestion window can be stabilized or adjusted base on the estimated attempt to stabilize around slow start threshold value. This approach eliminates the oscillation due to low E2E delay.

5. Simulation Results

In this section, we present the simulation results comparing with the TCP New Reno [4] , the TCP Westwood [9] , and the TCP Westwood-SS protocols. For simulation traffic, the source and destination is purely satellite connected network. Each user station has FTP service over different TCP various. We focus and consider two scenarios between Bangkok to Boston in testing our scheme. In the first scenario, all user stations start and stop at the same time. In the second scenario, all user stations start stop start at the same time. The two scenarios were different to improve the maximum of cwnd when it started to send the packet. Then, it has evaluated the performance in terms of congestion window (cwnd) and slow start threshold (ssthresh). In each TCP algorithms has different affect performance over non geosynchronous earth orbit satellite network. As a result, the TCP Westwood-SS protocol network performance evaluation criteria of the COMMStellationTM satellite system can be measured in term of cwnd, ssthresh, and end-to-end (E2E) delay [14] which are computed by the proposed TCP Westwood-SS, the TCP Westwood, and the TCP New Reno protocols. To assess TCP probe gain and its relation to the E2E propagation time, simulations with propagation error are used.

The first simulation results is window dynamics of the TCP Westwood-SS, the TCP Westwood, and the TCP New Reno for all user stations started ran simulations at the same time are presented in Figures 6-8. The graphs show the improved window dynamics in each TCP’s algorithms. The cwnd and ssthresh values are consistently the highest than the corresponding values in other TCPs, thus yielding decrease average E2E packet delay.

In Figures 6-8, it shows that the behaviors of each TCP protocols are the same user station when a segment loss occurs due to network congestion. The behavior of the congestion window (cwnd) dependent on RTT, when the TCP Westwood-SS (in Figure 6) sender detects a data segment loss and thus retransmits the lost segment,

Figure 6. TCP Westwood-SS, started all user stations at the same time.

Figure 7. TCP Westwood, started all user stations at the same time.

but in SS strategy does not decrease its congestion window, due to the slow start threshold. It can show sequence packet is continuously. Evidently, SS strategy of the TCP Westwood-SS can quickly increase transmitter’s congestion window.

Figures 9-11 show the simulation results of the second scenario in order to prove window dynamics of the TCP Westwood-SS, the TCP Westwood, and the TCP New Reno. The graphs show the improved window dynamics in each TCP’s algorithms. The cwnd and ssthresh values are consistently the highest than the corresponding values in other TCPs until break time before continuous to send the data again, even so yielding decrease average E2E packet delay.

In Figures 9-11, it shows that the behaviors of each TCP protocols are the same user station from Bangkok source node to Boston receiver node has start-stop-start at the same time to prove when a segment loss occurs due to network congestion. The behavior of the congestion window (cwnd) dependent on RTT, when the TCP Westwood-SS (in Figure 9) sender detects a data segment loss and thus retransmits the lost segment, but in SS

Figure 8. TCP New Reno, started all user stations at the same time.

Figure 9. TCP Westwood-SS, start-stop-start all user stations at the same time.

Figure 10. TCP Westwood, start-stop-start all user stations at the same time.

Figure 11. TCP New Reno, start-stop-start all user stations at the same time.

strategy does not decrease its congestion window, due to the slow start threshold. It can show sequence packet is continuously. Until a break time point, then start send packet into network again. This shows that the performance of the TCP Westwood-SS. Evidently, SS strategy of the TCP Westwood-SS can quickly increase transmitter’s congestion window.

Hence, the last result will show average end-to-end packet delay for each scenario as shown in the Figure 12 and Figure 13. The results show that the TCP Westwood-SS has lower E2E packet delay when compares with the TCP Westwood, and the TCP New Reno. Also, the total average E2E packet delay for the TCP Westwood- SS is 1025.654 packets in first scenario and the TCP Westwood is 1035.032 packets and the TCP New Reno is 784.6733 packets. For the second scenario, the TCP Westwood-SS has average E2E packet is 968.7916 packets. As for the TCP Westwood is 972.9704 packets. Last one protocol is the TCP New Reno is 700.0451 packets.

The graphs from Figure 12 and Figure 13 show the corresponding values in other TCPs for average E2E packet delay for each scenario.

Figure 12. The comparison average E2E packet delay in started all user stations at the same time.

Figure 13. The comparison average E2E packet delay in start-stop-start all user stations at the same time.

6. Conclusions

In this paper, we proposed implementation of feasible topology within the COMMStellationTM constellation network using network simulator 2. In second part of the paper, we show a new congestion control scheme improving the performance under sporadic losses in satellite networks. The TCP Westwood-SS has been tested through simulation.

The code modifications required to implement over TCP Westwood-SS are comparable to the ones implemented in the transition from TCP New Reno to TCP Westwood. To improve congestion window and slow start threshold in TCP Westwood-SS algorithms has affected performance to decrease average E2E packet delay over low earth orbit satellite network to reduce retransmissions. Therefore, in order to improve the network bandwidth utilization and decrease low latency time, TCP Westwood-SS protocol achieves to estimate E2E available high speed bandwidth of the response information.


  1. James, W., David, C., Pooya, S., Stuart, E., Peter, T. and Yves, D. (2012) COMMStellationTM—A Low Latency Satellite Constellation for Broadband Communications. Proceedings of the 30th AIAA International Communications Satellite System Conference (ICSSC), Ottawa, 24-27 September 2012, 858-871.
  2. (2014) The COMMStellation Website.
  3. (2013) The SaVi Website.
  4. Kevin, F. and Kannan, V. (2009) The ns Manual (Formerly ns Notes and Documentation), UC Berkeley, LBL, USC/ISI, and Xerox PARC.
  5. Henderson, T.R. and Katz, R.H. (1999) Transport Protocols for Internet-Compatible Satellite Networks. IEEE Journal on Selected Areas in Communications, 17, 326-344.
  6. Wood, L., Pavlou, G. and Evans, B. (2001) Effects of TCP of Routing Strategies in Satellites Constellations. IEEE Communications Magazine, 39, 172-181.
  7. Liang, Y. and Gang, Z. (2011) A New Transmission Control Protocol for Satellite Networks. Int. J. Communications, Network and System Sciences, 4, 256-265.
  8. Cario, C., Rosario, F., Mario, M., Tomaso, C., Michele, L., Cesare, R., Nedo, C. and Francesco P. (2007) Transport Layer Protocols and Architectures for Satellite Networks. International Journal of Satellite Communications and Networking, 25, 1-26.
  9. Saverio, M., Claudio, C., Mario, G., Sanadidi, M.Y. and Ren, W. (2001) TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links. Proceedings of the 7th Annual International Conference on Mobile Computing and Networking (MobiCom ’01), Rome, 16-21 July 2001, 287-297.
  10. Nandita, D., Tiziana, R., Yuchung, C., Tom, H., Amit, A., Arvind, J. and Natalia, S. (2010) An Argument for Increasing TCP’s Initial Congestion Window. ACM SIGCOMM Computer Communication Review, 40, 26-33.
  11. David, Q.L. and Williana, J.B. (2009) On Approaches to Congestion Control over Wireless Networks. Int. J. Communications, Network and System Sciences, 2, 222-228.
  12. Cheng, J., Wei, D., Low, S.H., Bunn, J., Choe, H.D., Doylle, J.C., Newman, H., Ravot, S., Singh, S., Paganini, F., Buhrmaster, G., Cottrell, L., Martin, O. and Wu-Chun, F. (2005) FAST TCP: From Theory to Experiments. IEEE Network, 19, 4-11.
  13. Cavendish, D., Kumazoe, K., Tsuru, M., Oie, Y. and Gerla, M. (2009) CapStart: An Adaptive TCP Slow Start for High Speed Networks. Proceedings of the First International Conference on Evolving Internet (INTERNET ’09), Cannes/La Bocca, 23-29 August 2009, 15-20.
  14. Sanguankotchakorn, T. and Somrobru, M. (2004) Performance Evaluation of IPv6/IPv4 Deployment over Dedicated Data Links. Proceedings of the 5th International Conference on Information, Communications and Signal Processing (ICICS’05), Bangkok, 6-9 December 2005, 244-248.