Optimizing Communication Utility of Routing Protocol for Satellite IP Networks
by
Anupon Boriboon
Submitted in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in Telecommunications Science Assumption University of Thailand December, 2016
Vincent Mary School of Science and Technology Declaration This is to certify that the work presented in this dissertation was carried out by the author in the Department of Communication and Computer Network Technology at Assumption University of Thailand and is the result of the original research conducted by the author, except where formally acknowledged and/or referenced, and has not been submitted for a degree to any other university or institution.
____________________ (Anupon Boriboon)
TABLE OF CONTENTS ACKNOWLEDGMENTS
i
LIST OF FIGURES
ii
LIST OF TABLES
v
LIST OF ABBREVIATIONS
vi
ABSTRACT
xii
CHAPTER 1 INTRODUCTION 1.1 Introduction
1
1.2 Problem Statement
4
1.3 Scopes and Limitations
5
1.4 Objectives and Outcomes
6
1.5 Main Contributions
7
1.6 Dissertation Outline
11
CHAPTER 2 LITERATURE REVIEW AND RELATED WORKS 2.1 Satellite Communications
12
2.2 Satellite Constellation Topologies
17
2.2.1 Inter-satellite Links
18
2.2.2 The Ground-Based Constellation Network
20
2.2.3 The Space-Based Constellation Network
21
2.3 TCP/IP over Satellites
23
2.3.1 TCP Segment
25
2.3.2 TCP Conceptualization
26
2.3.3 IP-based Communication
30
2.3.3.1 IPv4 Datagram
30
2.3.3.2 IPv6 Datagram
32
2.3.4 IPv6 and Satellites 2.4 Integration of Satellite Communications and the Internet 2.4.1 Routing in Satellite IP Networks 2.4.1.1 Handling Dynamic Topology
34 35 36 37
2.4.1.2 Reducing Link Handover and Rerouting Issues 39 2.4.1.3 Path Minimization Algorithms
42
2.4.1.4 Load Balancing Algorithms
45
2.4.1.4.1
Source-based Load Balancing
45
2.4.1.4.2
Central Load Balancing
46
2.4.1.4.3
Distributed Load Balancing
48
2.4.1.4.4
Hierarchical Load Balancing
50
2.4.1.5 Traffic-based Routing
53
2.4.1.6 Routing Form Space-Ground Integration Point-of-View 2.4.1.7 Multicast Routing 2.4.2 Queue Systems in IP Networks
55 59 59
2.4.2.1 Congestion Metric without Information Flow 61 2.4.2.1.1
Queue-based AQM
61
2.4.2.1.2
Load-based AQM
68
2.4.2.1.3
Other Congestion Metrics
73
2.4.2.2 Congestion Metric with Information Flow
75
2.4.2.2.1
Queue-based Metric
75
2.4.2.2.2
Load-based Metric
78
2.4.2.2.3
Other Metrics
79
2.4.2.3 Information Flow Only
80
CHAPTER 3 BROADBAND HYBRID SATELLITE CONSTELLATION COMMUNICATION SYSTEM 3.1 Satellite Constellation Visualization
82
3.2 Network Simulator
84
3.3 Simulation Model and Parameters of Hybrid Satellite Communications 3.4 Proposed COMMStellationTM Satellite System in NS-2
89 91
3.4.1 Visualization of NS Hybrid Satellite Constellation Configurations
93
CHAPTER 4 OPTIMIZED ROUTING PROTOCOL 4.1
Background of Routing Protocols over Satellites
4.2
System Model of Hybrid Satellite Constellation Architecture 101
4.3
Triple-play Service Methodology
104
4.3.1 VoIP over IPv6
105
4.3.2 IPTV over IPv6
109
4.3.3 FTP over IPv6
113
Proposed Routing
114
4.4.1 Routing Metrics
117
4.4
4.4.1.1 End-to-End Delay Metric
118
4.4.1.2 Queuing Delay Metric
120
4.4.1.3 Hop Count Metric
124
4.4.1.4 Link Utilization Metric
125
4.4.1.5 Link Length Metric
126
4.4.2 Applying the Proposed Routing Technique 4.4.2.1 Weighted Graph Model 4.5
99
Routing Results
128 130 136
CHAPTER 5 QUEUE MANAGEMENT SYSTEM 5.1 Background of Queue Management
143
5.2 Active Queue Management
145
5.3 Proposed Hybrid Satellite – Blue Queue Algorithm
148
5.4 Implementation with Broadband Hybrid Satellite Networks
151
5.4.1 Voice in Traffic Loads
153
5.4.2 Video in Traffic Loads
156
5.4.3 Data in Traffic Loads
159
5.5 Simulation Results
162
CHAPTER 6 PERFORMANCE EVALUATION OF BHSCCS 6.1 Performance Evaluation of Various TCP Protocols over BHSCCS
177
6.1.1 Traffic Load: TCP in Satellite Environment
179
6.1.2 Broadband Hybrid Satellite Networks
182
6.1.3 Performance Evaluation Criteria
183
6.1.4 Simulation Results of Various TCP Protocols
185
6.2 Performance Evaluation of GridFTP over BHSCCS
194
6.2.1 Grid Environment
194
6.2.2 GridFTP
195
6.2.3 Traffic Scenarios
197
6.2.4 Simulation Results of GridFTP
198
6.3 Proposed TCP Protocol Module 6.3.1 Slow Start Threshold and Congestion Window
204 205
6.3.2 Simulation Results of Slow Start Threshold and Congestion Window
208
CHAPTER 7 CONCLUSIONS AND FUTURE RESEARCH 7.1 Research Contributions
217
7.2 Integration of Satellite Constellation IP Networks with the Internet
217
7.3 Presentation of COMMStellationTM Topology on NS-2
218
7.4 Routing in Broadband Hybrid Satellite Networks
219
7.5 Queue Management in Broadband Hybrid Satellite Networks
221
7.6 Performance Evaluation of Various TCP Protocols and GridFTP over Broadband Hybrid Satellite Networks 7.7 Future Research Directions
222 224
REFERENCES
225
VITA
246
APPENDIX A: List of Publications
247
APPENDIX B: Comparison of Differences between Costs in Each Metric
248
LIST OF FIGURES Figure 2-1
Orbit Altitudes for Existing Satellite Constellations and New Proposals
16
Figure 2-2
Example of Polar-orbiting Satellite Constellation
20
Figure 2-3
Repeating Satellite Approach, e.g. Globalstar, Skybridge
21
Figure 2-4
Full Networking and Routing Approach, e.g. Iridium, Teledesic
23
Figure 2-5
TCP Datagram Header
26
Figure 2-6
Comparison between IPv4 and IPv6 Datagram Headers
34
Figure 2-7
Classification of AQM Schemes
61
Figure 3-1
SaVi User Interface Program
84
Figure 3-2
Simplifed User‘s View of NS-2
85
Figure 3-3
C++ and OTcl: The Duality
87
Figure 3-4
Architectural View of NS-2
88
Figure 3-5
Global Coverage from a COMMStellationTM Model
91
Figure 3-6
Hybrid Satellite Constellation Layout
92
Figure 3-7
Satellite Constellation Layout
93
Figure 3-8
Trunk Stations Layout
94
Figure 3-9
Internet Backbone Layout
96
Figure 3-10
Internet Backbone Topology
98
Figure 4-1
Proposed Triple-play Services for Hybrid Satellite Networks Topology
Figure 4-2
102
Snapshots of COMMStellationTM over LEO Satellite Constellation, Trunk Station, and User Station
103
Figure 4-3
SIP over UDP
109
Figure 4-4
IPTV over UDP
112
Figure 4-5
FTP over TCP
114
Figure 4-6
Illustration of E1 to E5 delays
118
Figure 4-7
Finite Population Queuing Model
123
Figure 4-8
Three-Dimensional Coordination of a Satellite Orbit
127
Figure 4-9
Flowchart of the ORPHSN Protocol
136
Figure 4-10
End-to-End Delay versus Allowed Route Length
138
ii
Figure 4-11
End-to-End Delay versus Allowed Route Length with Different Application Loads
139
Figure 4-12
End-to-End Delay versus Terminal Bit Rate
140
Figure 4-13
End-to-End Delay versus Traffic Loads in the Network
141
Figure 4-14
Link Availability Bandwidths versus Terminal Bit Rates
142
Figure 5-1
Hybrid Satellite Constellation Layout
152
Figure 5-2
Model for VoIP Simulation in NS-2
156
Figure 5-3
Model for Video Simulation in NS-2
159
Figure 5-4
VoIP G.711 – Two Way Connection with DropTail Queue
163
Figure 5-5
VoIP G.711 – Two Way Connection with RED Queue
163
Figure 5-6
VoIP G.711 – Two Way Connection with BLUE Queue
164
Figure 5-7
VoIP G.711 – Two Way Connection with HSBQ Queue
164
Figure 5-8
IPTV H.264/SVC - 1920×1080 @30fps with DropTail Queue
165
Figure 5-9
IPTV H.264/SVC - 1920×1080 @30fps with RED Queue
166
Figure 5-10
IPTV H.264/SVC - 1920×1080 @30fps with BLUE Queue
166
Figure 5-11
IPTV H.264/SVC - 1920×1080 @30fps with HSBQ Queue
167
Figure 5-12
PSNR Values of IPTV with DropTail Queue
168
Figure 5-13
PSNR Values of IPTV with RED Queue
168
Figure 5-14
PSNR Values of IPTV with BLUE Queue
169
Figure 5-15
PSNR Values of IPTV with HSBQ Queue
169
Figure 5-16
Frame No. 41 of the Original Source IPTV File
170
Figure 5-17
Frame No. 41 of the Source IPTV File with DropTail Queue
170
Figure 5-18
Frame No. 41 of the Source IPTV File with RED Queue
171
Figure 5-19
Frame No. 41 of the Source IPTV File with BLUE Queue
171
Figure 5-20
Frame No. 41 of the Source IPTV File with HSBQ Queue
171
Figure 5-21
Queue Bandwidth of DropTail Queue
172
Figure 5-22
Queue Bandwidth of RED Queue
173
Figure 5-23
Queue Bandwidth of BLUE Queue
173
Figure 5-24
Queue Bandwidth of HSBQ Queue
174
Figure 5-25
Queue Length of DropTail Queue
175
Figure 5-26
Queue Length of RED Queue
175
Figure 5-27
Queue Length of BLUE Queue
176
Figure 5-28
Queue Length of HSBQ Queue
176
Figure 6-1
A Basic Network Model
181 iii
Figure 6-2
A Sample Network Topology in the Network Simulator
183
Figure 6-3
Throughput with PER = 2%
187
Figure 6-4
Throughput with PER = 4%
188
Figure 6-5
Throughput with PER = 6%
188
Figure 6-6
Measurement of the End-to-End Packet Delay with PER = 2%
189
Figure 6-7
Measurement of the End-to-End Packet Delay with PER = 4%
189
Figure 6-8
Measurement of the End-to-End Packet Delay with PER = 6%
190
Figure 6-9
Total Latency with PER = 2%
192
Figure 6-10
Total Latency with PER = 4%
192
Figure 6-11
Total Latency with PER = 6%
193
Figure 6-12
Network Infrastructure for Global Area Bulk Data Transfer
198
Figure 6-13
Throughput of GridFTP with the DropTail Queue over a BHSCCS 200
Figure 6-14
Throughput of GridFTP with the RED Queue over a BHSCCS
200
Figure 6-15
Throughput of GridFTP with the BLUE Queue over a BHSCCS
201
Figure 6-16
Average E2E Delay of GridFTP with the DropTail Queue over a BHSCCS
Figure 6-17
202
Average E2E Delay of GridFTP with the RED Queue over a BHSCCS
Figure 6-18
203
Average E2E Delay of GridFTP with the BLUE Queue over a BHSCCS
203
Figure 6-19
TCP New Reno – Start Same Time Scenario
210
Figure 6-20
TCP Westwood – Start Same Time Scenario
210
Figure 6-21
TCP Westwood-SS – Start Same Time Scenario
210
Figure 6-22
TCP New Reno – Start Stop Same Time Scenario
211
Figure 6-23
TCP Westwood – Start Stop Same Time Scenario
212
Figure 6-24
TCP Westwood-SS – Start Stop Same Time Scenario
212
Figure 6-25
ACKed – Start Same Time Scenario
213
Figure 6-26
ACKed – Start Stop Same Time Scenario
213
Figure 6-27
Average E2E Packet Delay for Start Same Time Scenario
214
Figure 6-28
Average E2E Packet Delay for Start Stop Same Time Scenario
214
Figure A-1
End-to-End Delay versus Allowed Route Length
249
Figure A-2
End-to-End Delay versus Allowed Route Length
252
Figure A-3
End-to-End Delay versus Allowed Route Length
254
iv
LIST OF TABLES Table 2-1
Parameters Describing Different Constellation Networks
18
Table 2-2
Comparison of Different Load Balancing Schemes
53
Table 2-3
Comparison of AQM Schemes Based on Performance Metrics
81
Table 3-1
Snapshot of the Proposed COMMStellationTM Satellite Constellation at a Single Time Point
95
Table 3-2
Snapshot of the Proposed COMMStellationTM Trunk Stations
97
Table 4-1
Comparison of Routing Metrics
115
Table 4-2
Mapping Function of Cd for a Given Delay
120
Table 4-3
Mapping Function of Cq for a Given Delay
124
Table 4-4
Mapping Function of Ch for a Given Hop Count
124
Table 4-5
Mapping Function of Cu for a Given Link Utilization
126
Table 4-6
Mapping Function of Cl for a Given Delay
128
Table 5-1
Simulated Traffic of Triple-play Services over IPv6
162
Table 6-1
Dropped Packets for Different Network Traffic
190
Table 6-2
Total Jitter Time during the Network Transmission
190
Table A-1
Sample Routing Path
248
Table A-2
Comparison of Different in Each Metrics Cost
250
Table A-3
Each Metric has Maximum Cost of 200
250
Table A-4
Each Metric has Maximum Cost of 50
251
Table A-5
Each Metric has Different Maximum Costs
251
Table A-6
Mapping Table of Cost to be More Frequent and Narrower
253
Table A-7
Sample Routing Path
253
v
LIST OF ABBREVIATIONS ACK
Acknowledgement
ACO
Ant Colony Optimization
ARED
Adaptive Random Early Detection
AQM
Active Queue Management
AVQ
Adaptive Virtual Queue
ARPA
Advanced Research Project Agency
AS
Autonomous System
ATM
Asynchronous Transfer Mode
AVC
Advanced Video Coding
BDP
Bandwidth-Delay Products
BDSR
Bandwidth-Delay Satellite Routing
BER
Bit Error Rate
BG
Border Gateway
BGP
Border Gateway Protocol
BGP-S
Border Gateway Protocol – Satellite version
BHSCCS
Broadband Hybrid Satellite Constellation Communication System
B-ISDN
Broadband Integrated Services Digital Network
CBR
Constant Bit Rate
CHOKe
CHOose and Keep for Responsive Flow
CSFQ
Core Stateless Fair Queuing
CWND
Congestion Window
DARPA
The U.S. Defense Advanced Research Project Agency
DCLT
Delay Constrained Longest life Time
DRA
Datagram Routing Algorithm
DSP
Digital Signal Processing
DT-DVTR
Discrete Time Dynamic Virtual Topology Routing
DTX
Discontinuous Transmission
DVB
Digital Video Broadcasting
DVB-RCS
Digital Video Broadcasting – Return Channel via Satellite
DVB-S2
Digital Video Broadcasting – Second
DVMRP
Distance Vector Multicast Routing Protocol vi
DVTR
Dynamic Virtual Topology Routing
E2E
End-to-End
EAVQ
Enhanced Adaptive Virtual Queue
ELB
Explicit Load Balancing
EWMA
Exponential Weighted Moving Average
FABA
Fair Adaptive Bandwidth Allocation
FAR
Fixed Adaptive Routing
FCFS
First Come First Serve
FD
Flow Deviation algorithm
FHRP
Footprint Handover Re-routing Protocol
FIN
Finished
FQ
Fair Queuing
FR
Footprint Rerouting
FRED
Flow Random Early Drop
FSA
Finite State Automation
FTP
File Transfer Protocol
FV
Fitness Value
GAN
Global Area Network
GEO
Geosynchronous Earth Orbit
GRI
Global Routing Information
GSE
Generic Stream Encapsulation
GSLs
Ground-to-Satellite Links
GTR
Graph Topology Representation
HAPs
High Altitude Platforms
HD
High Definition
HDTV
High Definition Television
HEO
Highly Elliptical Orbit
HRED
Hyperbola Random Early Detection
HSBQ
Hybrid Satellite – Blue Queue
IB
InfiniBand
IOLs
Inter-Orbital Links
IP
Internet Protocol
IPv4
Internet Protocol version 4
IPv6
Internet Protocol version 6 vii
IPTV
Internet Protocol Television
IPHL
Internet Protocol Header Length
ISI
Information Sciences Institute
ISLs
Inter-Satellite Links
ISP
Internet Service Provider
ITU
International Telecommunication Union
ITU-T
Telecommunication Standardization Sector of ITU
JSVM
Joint Scalable Video Model
LEO
Low Earth Orbit
LER
Label Edge Routers
LLC
Logical Link Control
LRED
Loss ratio based Random Early Detection
LRI
Local Routing Information
LSP
Label Switching Path
LUBA
Link Utilization Based Approach
MAC
Medium Access Control
MCOP
Multi-Constrained Optimization Problem
MEO
Medium Earth Orbit
MGCP
Media Gateway Control Protocol
MOS
Mean Opinion Score
MOSPF
Multicast routing extensions for OSPF
MPE
Multi-Protocol Encapsulation
MPEG
Moving Picture Experts Group
MPLS
Multi-protocol Label Switching
MSCI
Microsat Systems Canada Inc.
MSS
Maximum Segment Size
NAL
Network Abstraction Layer
NCC
Network Control Centers
NGEO
Non-Geostationary Earth Orbit
NNI
Network-to-Network Interface
NS
Network Simulator
NS-2
Network Simulator version 2
OBP
On-board Processing
OBR
On-board Routing viii
OBS
On-board Switching
OCRW
Open/Close/Read/Write
ORPHSN
Optimized Routing Protocol for Hybrid Satellite Network
OSPF
Open Shortest Path First
PCM
Pulse Code Modulation
PD
Proportional Derivative
PDF
Probability Density Function
PER
Packet Error Rate
PRP
Probabilistic Routing Protocol
PSNR
Peak Signal to Noise Ratio
PSTN
Public Switching Telephone Network
QCF
Queue Control Function
QoS
Quality of Service
QRA
QoS-based Routing Algorithm
RAR
Random Adaptive Routing
RDMA
Remote Direct Memory Access
RED
Random Early Detection
RED-PD
Random Early Detection with Preferential Dropping
REM
Random Exponential Marking
RIP
Routing Information Protocol
RTP
Real Time Protocol
RTT
Round-Trip Time
RVM
Reverse-path Multicast
SAVQ
Stabilized Adaptive Virtual Queue
SCTP
Stream Control Transmission Protocol
SD
Standard Definition
SDH
Synchronous Digital Hierarchy
SFB
Stochastic Fair BLUE
SFED
Selective Fair Early Detection
SGRP
Satellite Grouping and Routing Protocol
SHRED
Short-lived flow friendly Random Early Detection
SIP
Session Initiation Protocol
SNR
Signal-to-noise ratio
SoS
Satellite-over-Satellite ix
SRED
Satellite Routing for End-to-End Delay
SRED
Stabilized Random Early Detection
SSH
Secure Shell
ssthresh
Slow Start Threshold
STM-1
Synchronous Transfer Module level-1
STM-4
Synchronous Transfer Module level-4
SVB
Stabilized Virtual Buffer
SVC
Scalable Video Coding
SVEF
Scalable Video-streaming Evaluation Framework
SYN
Synchronize
TCD
Traffic Class Dependent
TCP
Transmission Control Protocol
TCPHL
Transmission Control Protocol Header Length
TCR
Traffic Classification Routing
TT&C
Telemetry, Tracking and Control
TTL
Time to Live
UA
User Agent
UAC
User Agent Caller
UAS
User Agent Server
UDL
User Data Link, Up/Down Link
UDP
User Datagram Protocol
ULE
Unidirectional Lightweight Encapsulation
UNI
User Network Interface
URI
Uniform Resource Identifications
VBR
Variable Bit Rate
VCEG
Video Coding Experts Group
VCL
Video Coding Layer
VCs
Virtual Channels
VERS
Version fields
VINT
Virtual InterNetwork Testbed
VN
Virtual Node
VoD
Video on Demand
VoIP
Voice over Internet Protocol
VP
Virtual Path x
VPC
Virtual Path Connection
VSAT
Very Small Aperture Terminal
WAN
Wide Area Network
xi
ABSTRACT
The advantages of broadband satellite systems are a coverage which goes over the worldwide areas, and also provides a better result of hi-speed Internet access to the end users. By the installation of the small satellite interfaces, everyone can easily connect communications via Low Earth Orbit (LEO) in everywhere on this planet such as terrestrials, ocean liners, airplanes, oil platforms, and island geographic areas. With these property broadband satellite systems is very significant to connect people from every corner of the world together in the era of the global Internet network which supported by the triple-play (Voice, Video, and Data) services application. And, the key issue is the routing in the satellite network, which communicates via broadband satellite systems integrated with global networks.
The unique
characteristics posed by Broadband Hybrid Satellite Constellation Communication System (BHSCCS) call for different research approaches from those in terrestrial networks.
The purpose of this research is to develop BHSCCS networks with
advanced architectures, and implementation over COMMStellationTM topology and efficient routing protocols on IPv6 for BHSCCS networks to support the triple-play services traffic type and heterogeneous quality of service (QoS) requirements. Specifically, a new QoS-based routing algorithm is Optimized Routing Protocol for Hybrid Satellite Network (ORPHSN).
The ORPHSN protocol incorporates both
inherent dynamics of BHSCCS within to support the triple-play services application in satellite networks. Finally, a new routing framework, called the ORPHSN provides a self-contained and scalable solution to supporting different traffic types through the broadband Internet. Moreover, the dissertation found out that this algorithm has the most optimization end-to-end QoS performance of the whole communication xii
network. In addition, the queuing systems have to maintain high link utilization with a low loss rate and queuing delay in BHSCCS environment. A stable operation and quick response to load changes are also desirable. The Hybrid Satellite – Blue Queue (HSBQ) algorithm provides control of queue delay to develop algorithm, which aids the HSBQ to have a low loss rate and a highly stable operation of the queuing system. Also, the performance evaluation of various TCP protocols and GridFTP over broadband hybrid satellite constellation network system shows high performance data transfer in such networks.
xiii
CHAPTER 1 INTRODUCTION
1.1 Introduction Nowadays, satellite communication network technologies play a significant role in the industrial sector. Both public and private sectors have been aware of the importance of the satellite communication network technologies for the development of organizational efficiency and capability.
This greatly contributes to the
development of the most important infrastructure. Satellite communication systems have the advantage of world-wide coverage areas and offer many solutions to providing Internet broadband access to end users. The terrestrial networks can be connected to the rest of the globe over Low Earth Orbit (LEO) satellite network completely. The satellite communication systems play an important role in the global Internet to support real-time and non real-time applications. At the beginning, the satellite networking used an individual satellite in a geostationary orbit. The uplink and downlink signals were usage amplified, of which the frequency was shifted to broadcast (spot beam) to target an area on the ground. That is a conceptualization of bent-pipe repeaters in satellites. The establishment of more complex media access control (MAC) designs was sharing of the physical and data link layer. The most remarkable thing is slotted Aloha, different for use with Very Small Aperture Terminal (VSAT) networks. The evolution for multiple spot beams per satellite valid is essential for on-board switching with MAC, to control and design the capacity in circuits with a logical link control (LLC) sub-layer. The LEO using orbits are lower than the geostationary orbit. These grant fully global targeted 1
spot beams for coverage on Earth.
The satellite constellations produce feasible
greater reuse of frequencies limited to and available in ground-space communication, serving a higher capacity in the networks [1]. In the last few decades, the communication and networking technologies have experienced a revolution.
Packet switching based on Internet Protocol (IP)
communication systems has challenged the traditional circuit switching systems. People want to use all types of high speed services anywhere and anytime. The wireless and satellite communication technologies make this a reality.
As an
important supplement to the terrestrial network infrastructure, a satellite communication network is of many advantages, including global coverage, flexible networking capability, inherent ability to support broadcasting or multicasting services, bandwidth-on-demand capability, etc.
Thus, regardless of the type of
aeronautical, maritime, disaster relief, military and those in rural areas lacking terrestrial communication infrastructure, satellite communication technologies are an attractive solution to provision of various communication services. The integration of satellite communication systems and IP networking technology is the trend in the satellite industry because most of triple-play services (voice, video and data) have been shifted from analog to digital technology. The IPbased satellite technology fastens the process of digital media deployment and will play an important role in the future global communication infrastructure.
As a
combination of digital media, broadcasting capability and the Internet, a satellite can provide a network platform for various broadband real-time services. They are able to use satellite networks to access all types of data or multimedia services, such as digital TV, streaming media, long distance education, web caching, software distribution, etc. The interactive services also become possible via satellite networks, 2
such as Video on Demand (VoD), online gaming, video conference, etc. For the enterprise and business sectors, they can use satellite networks to create their own Global Area Networks (GANs), Wide Area Networks (WANs), and Virtual Private Networks (VPNs). Various satellite networks have been proposed to provide broadband services, for example, Teledesic, SpaceWay, SkyBridge, etc. For commercial reasons, some of them have been suspended, e.g., Teledesic and SkyBridge, while these of them are still on track, e.g., SpaceWay. Besides, some other experiments have been carried out on various IP applications over satellites. The Cisco systems (CISCOTM) has done some experiments using an onboard mobile router to test multimedia applications. But, with the special characteristics of satellite networks, there are many technological challenges to face on the part of the engineers and the researchers in the design and implementation of the IP-based satellite networks [2]. From the above paragraphs, it means network traffic over broadband satellite has many utilities over there, so many researchers have developed and proved a lot of techniques for packet going to a destination to be faster and reliable. There are many factors on networks such as link length, link delay, path and bandwidth. Performance metrics are the key issues to support these services of routing algorithm. Some benefits decrease in propagation delay of End-to-End (E2E) in broadband hybrid satellite constellation, which is a bonus for delay budgets. In this chapter, the author briefly describes the scope and the objective of the research problems and my contributions to solve the problems in this research work. Finally the structure of this dissertation is outlined.
3
In this work, the author is to clarify the features of the satellite communication systems which are assumed to be equipped with software On-board Processing (OBP) modules for differentiating them from their terrestrial counterparts and propose a novel optimized routing protocol on over satellite IP networks technique in hybrid satellites over LEO networks. The hybrid satellite communication network topology makes use of routing metrics.
This is to support triple-play services payload
applications, enforce strict delay bounds, and be sensitive to delay variations. It can satisfy the triple-play service payload for Quality of Service (QoS) requirements of real time and non-real time applications over the satellite routing protocol. It should come in low propagation delay, with low rerouting frequency, and a low rerouting processing overhead.
1.2 Problem Statement Long and varying delays in triple-play services over hybrid satellite networks are constraints leading to Quality of Service (QoS) from the source to the destination; it is an origin of jitter to make such obstacles as motion freezes and block artifacts in video. Routing is a basic but important issue in the hybrid satellite networks. QoS and QoS routing algorithms have been extensively investigated in terrestrial networks. Most of them use a randomized topology to evaluate the algorithms performance. Considering the typical topology and dynamic nature of hybrid satellite over LEO networks, the author can design efficient algorithms for this specific network environment. Metric cost system performance is another interesting topic for satellite IP networks. Most of the existing work concentrates on modifying the current routing 4
protocol on the basis of metrics and passive triple-play services (voice, video and data). In recent years, researchers have begun to improve this way, using more information and optimizing the system performance.
This seems to be another
feasible way to enhance metrics routing with triple-play services performance in some sense. In the research, triple-play services on hybrid satellite network is an active queue management (AQM) algorithm, which is ordered to avoid high packet loss rates and control a stable stream queue. To adjust the queue weight, is to estimate the average queue length, based on the rate; moreover it uses the change of the average queue length to adjust the amount by which the mark probability is changed. It seems that the proposed queue system is essential for efficiency algorithm for triple-play service applications over the broadband hybrid satellite network system.
1.3 Scopes and Limitations The scopes of this dissertation are to develop advanced architectures and efficient routing protocols for satellite networks to support triple-play service applications with different traffic types and quality of service (QoS) requirements. 1.
A weighted graph model is used to analyze the QoS routing problem in hybrid satellites over LEO networks. From the weighted graph model, the author proposes routing metrics for delivery of triple-play services over the broadband satellite constellation network.
2. The first novelty is that the proposed algorithm tries to find the optimizing paths using heuristic methodology and at the same time, it tries to reduce routing. 5
3. The second novelty is that the COMMStellationTM satellite model and snapshot point view on network simulator (NS-2) are presented. As for the limitations of simulating the most realistic satellite network, the author also prove the proposed of algorithm based on the network simulator version 2.34 by including modules of wireless satellite networks. The LEO satellite networks with COMMStellationTM satellites are considered in the simulation. 1.
IPv4 on NS-2: The configuration of a raw IP network object is
comparatively simple.
The object is not associated with any particular physical
network interface; the packet payload capability will be used to emit the specified datagram whichever interface is required to reach the destination address contained in the IP header [1], [3]. 2. IPv6 on NS-2: It has developed a set of NS agents that simulate the IPv6 protocols. This is going to be extended to support the research. The author has not implemented all the proper IPv6 features as it was not necessary for the simulations (e.g. DHCPv6, Neighbor Discovery, etc). The only concern is to modify the header size, to add into any packet payload between source and destination, and to make sense of the routing extension header processings [4 - 10].
1.4 Objectives and Outcomes The challenges of broadband hybrid satellite IP network communication in such a network may include substantial delays resulting from physical link properties or extended periods of network partitioning, low routing efficiently, high link error rates, and opportunistic link availability.
6
In this dissertation, optimizing
communication utility of routing protocols has been developed for the satellite IP network to support a new real-time payload application with improvement in tripleplay services for QoS requirements. Research contributions have been made in the following areas: 1. Implementation of the COMMStellationTM topology on a network simulator. 2. Improvement in connection routing in triple-play services over satellite IP networks. 3. Improvement in routing metrics for routing algorithm in the hybrid satellite. 4. Improvement in active queue management in the hybrid satellite. 5. Improvement of TCP westwood protocol in the hybrid satellite. 6. Performance evaluation of the broadband hybrid satellite network system.
1.5 Main Contributions The future communication systems are unable to live without satellite networks because it is a necessary part of future communications systems. The global network structure has integrated the satellite IP networks to become a part of the greatest communication systems. Thus, satellite services can be covering all of the global areas. A hybrid satellite over LEO constellation communication IP networks system can act as a safety valve for high-speed global area networks (GANs). Fiber optic on the main land network will fulfill routing traffic through a satellite channel. Hence, GAN networks can be connected to the rest of the world over hybrid satellite constellation IP networks. Routing in hybrid satellite networks, the unification of
7
satellite networks and the terrestrial hi-speed Internet are the significant issues to support the triple-play service application. For successful transfer of triple-play data messaging communications, satellite operators have outlined significant challenges for development and design of deep next generation hybrid satellite IP network architectures. An important advantage is that users living anywhere can get access to the best possible access resources from across the world at a very affordable communication. In underdeveloped and developing countries, the satellite system raises the level of the next-generation networks, and digital economic development. This is especially true for countries where a technical satellite system is expensive, opportunities are limited, and economic disparities exist. Regarding the dissertation objective and outcomes an identified above, the author has made a number of contributions.
The author have summarized the
contributions in a detailed discussion presented as a remainder of the Optimizing Communication Utility of Routing Protocol for Satellite IP Network providing communication services for satellite operator data delivery services. Firstly, new and efficient Broadband Hybrid Satellite Constellation Communication
System
(BHSCCS)
mechanisms
are
proposed
shifting
COMMStellationTM satellite system into Low Earth Orbit (LEO) to present a feasible network simulator (NS-2). This satellite topology consists of 72 satellites in 6 orbital planes and the space between the orbital planes is 30 degrees. It is a typical Walker constellation configuration. The 35 trunk stations on the mainland are assigned and the snapshot of trunk station positions can optimize the connections between satellite links of the BHSCCS model. The latitude, longitude, and plane of the constellation satellite system and trunk stations are shown in the dissertation.
8
Secondly, a novel QoS routing algorithm is proposed for hybrid satellite like a BHSCCS. A weighted graph model is used to analyze the QoS routing problem in BHSCCS networks. Based on the weighted graph model, the author has proposed the Optimized Routing Protocol for Hybrid Satellite Network (ORPHSN) routing algorithm to the hybrid satellites. Therefore, the ORPHSN is proposed based on a weighted graph model to solve the QoS routing problem in BHSCCS. The metric selection of the proposed technique based on optimization with the ratio relationship of QoS metric for triple-play services which have strict requirements on bandwidth, delay variations, and availability.
Hence, five significant dynamic parameter
functions are considered. The first metric is the propagation link delay, which is determined by an advanced propagation delay model from the source to the destination. The second metric is the queuing delay. It is affected by the traffic load on each particular satellite and its outgoing links as the packet traverses varying traffic gateways. The third metric is link hop count. The fourth metric is link utilization in which the throughput part of all the subsequent neighborhood nodes confirms the best path. The fifth metric is link length that chooses the shortest link between user/trunk stations to both satellites. The five matrices are used to reduce the end-to-end link delays, deteriorate the rerouting frequency, and choose the best route path in the routing table. Thirdly, a new technique of active queue management is the proposed Hybrid Satellite – Blue Queue (HSBQ) algorithm in BHSCCS networks.
The HSBQ
algorithm classified based on congestion metrics and without the flow information, which is ordered to avoid high packet loss rates and control stable stream queue. That is the problem of calculation of the drop probability for both queue length stability and bandwidth fairness. The proposed HSBQ, which drops the packets before the 9
queues overflow at the gateways, so that the end nodes can respond to the congestion before queue overflow. This algorithm uses the change of the average queue length to adjust the amount by which the mark or drop probability is changed. Moreover, it adjusts the queue weight, which is used to estimate the average queue length based on the rate. Finally, the performance evaluation of BHSCCS networks provides File Transfer Protocol (FTP) access based on a different Transport Control Protocol (TCP). The performance evaluation criteria which are throughput, the percentage of dropped packets, mean end-to-end delay, and jitter time of traffic of each various TCP protocol. Then, high performance data transfer as a GridFTP is an extension, FTP and it has been used to manage large data transfer across computational grids. The GridFTP load has been implemented for traffic load of a grid network to investigate efficient ways of dynamically changing in BHSCCS networks.
The evaluated
BHSCCS networks use GridFTP to improve the grid network performance, with different conditions such as queue management, transport control protocols, and packet error rates. In addition, a novel TCP Westwood-SS is proposed. By fixing the slow start threshold value, TCP Westwood-SS can modify the congestion window and slow down the start threshold algorithm to improve performance and to decrease the average end-to-end packet delay and therefore the sequence packet is continuous and smooth.
10
1.6 Dissertation Outline The remainder of this dissertation is organized as follows. In Chapter 2, the survey goes deeply into the background materials related to the problems addressed in this work, which include satellite technologies, TCP/IP performance enhanced over satellite channels, routing algorithms for satellite networks, and queue management in satellite networks. In Chapter 3, a SaVi is introduced for showing global coverage from the COMMStellationTM satellite model. The simulation tool is a Network Simulator version 2 (NS-2) described briefly for research in satellite communication networks. The simulation model in NS-2 is presented with COMMStellationTM satellite system model. It is proposed that a novel model the COMMStellationTM is possible in NS-2. In Chapter 4, a novel QoS routing algorithm is proposed to find a best path with
a
weighted
graph
model.
The
hybrid
satellite
characteristic
of
COMMStellationTM is used to enhance the proposed ORPHSN algorithm performance. The triple-play services over IPv6 application are traffic loads over BHSCCS. Mathematical routing metrics modeling, extensive simulation results, and discussions are included. In Chapter 5, the author extends the active queue management system concept to a hybrid satellite network. A proposed HSBQ algorithm is applied to avoid high packet loss rates, and control stable stream queue in the hybrid satellite network system.
The triple-play services over IPv6 application are traffic loads over
BHSCCS.
11
In Chapter 6, the performance evaluation of BHSCCS networks, which provides various TCP protocols, is showing the performance network criteria. Another one is the GridFTP performance with an application layer mechanism is also studied. Next, TCP Westwood-SS will make the congestion window adjustable based on the estimated attempt to stabilize around the slow start threshold value. Finally, in Chapter 7, this dissertation is concluded by summarizing my work, the optimizing communication utility of the routing protocol for satellite IP networks, which are the main advantages and contributions of the work presented in this dissertation. And, the direction for future works in the once of the hybrid satellite network is discussed.
12
CHAPTER 2 LITERATURE REVIEW AND RELATED WORKS
2.1 Satellite Communications In 1965, the first commercial satellite called INTELSAT was launched with the aim of providing overseas telephony services.
Many other communication
satellites have been launched since then. In the 1970s and 1980s, satellite networks also began to provide data services and video-broadcasting services. The use of the Very Small Aperture Terminal (VSAT) satellite system in 1980s enabled a wide range of services, such as broadcast and distribution services for data, audio, and video applications. However, after the arrival of high speed optical fiber technology in the 1990s, many services were shifted from satellites to optical fiber.
Meanwhile,
satellite communication technology continued to develop at a fast pace. The usage of Ka band (20 – 30 GHz) and Low Earth Orbit (LEO) satellite constellation technologies made it possible to provide global broadband services to people. Together with the use of small sized antennae, it offers duplex, mobile communications all round the world. All of the new technologies make the satellite communication technology competitive [2]. Both a space segment and a ground segment constitute for a satellite system. On the ground section is the place where the gateway stations and control centers are located. The control centers have a main function to control the satellite operation and orbiting control for overall network resource management. The gateway stations have their duty to communicate with another network and satellite network. They have a principal function to process communication of protocol and exchange the 13
address translation. satellite system.
The constellations are composed of the space sector of the
This chapter introduces the satellite systems and some related
network technologies. Satellites can be classified according to the types of their orbits. Circular orbits are used in most proposed satellite communication systems and the center of the circle is located on Earth. The satellite is moving in circular orbit, which means it guarantees that constant speed and time interval remain constant. Their altitudes can classify satellites in circular orbits [1], and [11]. The equator is located 35,786 kilometers under the Geosynchronous Earth Orbit (GEO) satellites. The angular rate of rotation of the Earth is matched with the angular velocity of satellite in this orbit. This point makes a satellite appear stationary when the surface satellite dish in the gateway on the Earth is observed.
This
beneficial property has ensured the geosynchronous orbit is suitable and extremely popular. Very large areas can be served by this system. A minimum of three GEO satellites can cover much of the Earth.
The propagation delay between a GEO
satellite and the gateway station on Earth is different in position, in longitude and in latitude, but is around 125 – 250 milliseconds between Earth stations. This leads to the widely quoted half second round trip time delay for communications via a GEO satellite. The single hop network with or without advanced on-board processing usually uses GEO satellites. GEO satellites are being used in the VSAT network, which is an example of satellite communication networks. Medium Earth Orbit (MEO) satellites are located at altitudes of between 9,000 – 11,000 kilometers. This system appears in motion when an eye is kept from the globe, in an around 10 minute observation. This orbit has an average propagation delay range of between 110 – 130 milliseconds. For global coverage of Earth, 10 – 15 satellites are needed. They rotate around the Earth in approximately 4 – 6 hours. 14
Visibility time of a MEO satellite to a ground station is in an order of tens of minutes before a handover must take place. An example of a MEO satellite network is the ICO system [12]. Low Earth Orbit (LEO) satellites are of lower altitudes than the MEO and GEO satellites, regularly between 500 – 2,000 kilometers.
The global coverage
requires a substantial number of satellite constellations to provide coexistence. The demand for coverage areas and a minimum elevation angle is used in the actual number of satellites. Constellation satellites have small footprint and small spot-beam coverage areas; the Earth reuses frequency in large amounts of possibility across. The surface of the Earth is relative with LEO satellites by moving rapidly, at a speed of over 25,000 km/hour. This rapid speed is to observe an LEO satellite in a few minutes. The LEO satellites have propagation delay often of under 15 milliseconds. LEO satellites are extra suitable for the communications in real-time by low delay attributes in addition to low power necessities for end stations. Iridium, Teledesic, and Globalstar are examples of LEO satellite networks. Highly Elliptical Orbit (HEO) use of an elliptical orbit differs from the continuous-though-moving coverage of a circular orbit. For elliptical orbit to cover area services, the satellite is moving slowly towards the ground section while at apogee, with Kepler‘s third law when the satellite moves from near high apogee to low perigee and back at a varying speed, its coverage area zooming in size, and service disabled. Apogee in their own orbit is being neared by other satellites in the constellation providing service coverage in its place as the Earth rotates. The Molniya and Tundra systems are examples of HEO satellite networks. For example, satellite television services of the former Soviet Republic are at high latitudes [13].
15
GEO, MEO, LEO and HEO have been proposed as broadband satellite constellation networks. They are being enhanced to deliver high-speed broadband satellite services. The high capacity of the satellite links will provide the medium, and the existing global networks will be interconnected by these systems.
The
Internet via satellite used in the TCP/IP protocol suite has such a methodology as computer network communication to transport significant volumes of TCP/IP traffic. Broadband satellite constellation networks such as Teledesic, Spaceway, and SkyBridge are, therefore, proposed. However, broadband IP satellite constellations are new but have already been in use for many services [1]. Satellite constellation networks, namely LEO, MEO, GEO and HEO, can be categorized based on orbital altitude. A brief depiction of the existing and proposed satellite constellations is given in Figure 2-1 [14], [15].
Figure 2-1 Orbital Altitudes for Existing Satellite Constellations and New Proposals [14] 16
2.2 Satellite Constellation Topologies A regular Non-Geostationary Earth Orbit (NGEO) satellite constellation is characterized by a number of system parameters: number and altitude of satellites, number of orbits and satellites per orbit, how to deploy the orbits, and how to interconnect the satellites. According to the way the orbits are deployed, different types of constellations are obtained. In case that every orbital planes are installed along a semi-circle (when viewed from the pole), the so-called -constellation is a resulting constellation. In the -constellations, there are two extreme orbits which are adjacent, but whose satellites move in opposite directions. As a result, a seam appears between these two orbital planes and potential inter-plane ISLs passing over the seam must handover frequently. Moreover, usually -constellations suffer from extensive polar coverage, and do not provide dual satellite visibility in low latitudes.
In order to avoid this kind of
problems, 2-constellations are proposed. In 2-constellations, ascending nodes are equally spaced along the full 360 of the equatorial plane. Another important parameter of a satellite constellation is the orbital inclination angle, which is defined as the angle between the orbital plane and the equatorial plane. If the inclination angle of an orbit is close to 90, satellites pass over the polar region and the orbit is called a polar orbit. Usually, -constellations use polar orbits for coverage reasons, and they are called polar constellations. (Note that they are also named Walker star constellations, since the orbital pattern appears as a star ‗*‘ in polar view). On the other hand, inclined orbits (orbits with low inclination angles) are better suited for 2-constellations. 2-constellations with inclined orbits are called shortly inclined constellations (or Walker delta constellations, since the 17
orbital pattern appears as a delta ‗‘ in polar view). While Iridium system and Teledesic system designs have a polar constellation topology, Globalstar and ICO systems are inclined constellations. The system characteristics of these major satellite constellation systems are summarized in Table 2-1 [1], [12], [3], [16], and [17].
Table 2-1 Parameters Describing Different Constellation Networks LEO constellation
Iridium
Teledesic
COMMStellation
Altitude (km)
780
1375
1000
Number of orbits
6
12
6
Satellites per plane
11
24
12
Inclination angle (deg)
86.4
84.7
90
Satellite visibility time (min)
11.1
2.32
~15
40
10
Minimum elevation angle from a ground terminal for a link (deg) 8.2 Spacing between planes (deg)
31.6
15
30
Seam separation (deg)
22
15
45
ISLs per satellite
4
8
-
ISL / Satellite bandwidth
25 Mbps
155 Mbps
8.8 Gbps
Up / Down link bandwidth
1.5 Mbps
1.5 Mbps
1.1 Gbps
2.2.1 Inter-satellite Links As stated by Henderson and Katz, ―In LEO systems that provide complete global coverage, a network of inter-satellite links (ISLs) connects via satellites. Typically, a satellite will have a given ISLs of between four and eight of its nearest neighbors - payload constraints will appropriately interdict the use of more than eight ISLs. High capacity for high frequency (HF) or optical links are projected ISLs.
18
Therefore, in this type of system, the bottleneck links will be the ground-to-satellite links (GSLs), due to the limited radio frequency (RF) spectrum available for such links. It is of two types of ISLs. Intra-plane, which connects a satellite to two or four of its nearest neighbors within the same plane, can be treated as fixed links in the topology – always in connection with the nearest neighbor satellite nodes. The interplanes connect a satellite to their nearest neighbor satellite nodes in adjacent, corotating planes, and time-varying links for a number of reasons. First, a function of latitude is changed according to the distance between satellites planes. Second, the planes may not maintain phasing, causing the satellites of different planes to slowly drift with respect to one another. Third, the vicinity of the poles switches off the inter-plane because the antenna pointing mechanism cannot track the rapidly changing angle between the satellites fast enough. Finally, note that in a polar constellation (Figure 2-2), there are two regions in which the planes are counter-rotating, thereby forming a ―seam‖ in the topology. Cross-seam is a special case of inter-planes. Cross-seams existing, the next satellite rapidly hands off them. If cross-seams do not exist, over a pole, there must be route communication between two locations on the opposite sides of the seam. The Iridium system does not support Cross-seam, while it is planned to support Teledesic system. The problem of Cross-seam in the Iridium system has been analyzed and it has been concluded that no special antenna steering requirements are necessary by Keller and Salzwedel, although link acquisition may be challenging. Two inter-planes per satellite is planned to use by Teledesic, but at the seam, only one ISL will be active; the other will be used to acquire the next (crossseam) satellite‖ [16].
19
Figure 2-2 Example of Polar-orbiting Satellite Constellation [16]
2.2.2 The Ground-Based Constellation Network The satellite in space has retransmitted signals with the bent-pipe concept by frequency shifting via amplification mechanism or using digital signal processing (DSP) for signal regeneration with baseband for traffic arriving from the gateway/user terminal under it over the ground base, thus returning the traffic to the ground section. The traffic is sent or received by the separation of user terminals through neighbor gateways into the global network infrastructure by this means. A satellite last hop is provided to a wide ground network base. This model is challenging in a space section: medium access control (MAC), logical link control (LLC), and handover are from a networking viewpoint.
The last hop network connection by satellite
commercial systems is provided through the use of the ground-based section for satellite constellation networks.
As a result, the location of terrestrial gateway
stations which share information about the state of the satellite constellation, it can be assumed that all satellite telemetry, tracking and control (TT&C) ground stations will 20
be networked.
Nevertheless, it is possible for a large satellite constellation and
gateway networking to join the global network toward the backbone Internet. As a result, the ground-based section is arbitrary to control whose satellite system [1], [15], and [18]. This approach can be used to implement networking by simpler approaches that have separate heterogenous ground networks using passing satellites to complete their radio links as shown in Figure 2-3. The ground-based Globalstar and Skybridge satellite networks are such examples of design approaches which are fundamental in satellite networking.
Figure 2-3 Repeating Satellite Approach, e.g. Globalstar, Skybridge [1]
2.2.3 The Space-Based Constellation Network In the space section of satellite networks, the on-board processing (OBP) which looks like a network router in OSI layer 3, is used by the satellite node to communicate with neighboring satellites in the same orbit. Data from the gateways to
21
the global Internet or in connection to rural terminals are sent and received through a user terminal. With inter-satellite link (ISL) mechanism, the routing in space section has been achieved. Such routing is the most challenging issue among satellites in different orbit. For example, both OBP routing and OBP switching must be supported by the satellite constellations. More complex OBP technologies have been introduced to support IP over satellite networks [2]. In combination with the ground section like the gateway system, it adopts an autonomous system (AS). This is divergence to the ground based access, where it is probable that each global gateway can be an entirely separate AS. As stated by Wood, ―For the case of orbital satellite, it is possible to use fixed ‗fore‘ (ahead) and ‗aft‘ (behind) inter-satellite link equipment for intra-plane communication with satellites holding stationary relative positions within the sample plane. Fixed equipment between satellites on different orbits cannot be used by the inter-plane communication as line-of-sight paths between angle and length will change these satellites which have different orbits and converges between crossings, and may cause Doppler shift, and challenges for tracking control; for example, antennas must slew around, and there are high relative velocities between the satellites‖ [1]. As a result, the relative positions of the satellites that are altered need tracking. The feasibility and the range of slewing angles of ISL in LEO constellation and rosette and MEO constellations require tracking. In elliptical orbits, considerably throughout the orbit and controlled vertical pointing of the fore, and aft, intra-plane link antennas are required to compensate this.
However, there is little value in
implementing intra-plane ISL since elliptical orbits are only useful for large area coverage at a slow moving apogee. Although the distances between satellites are extremely large [1], [2], [15], and [18], inter-plane crosslinks between quasi22
stationary apogees (as proposed for Virtual GEO) appear straightforward to maintain from a tracking viewpoint. It can take the approach to implement networking. The approaches can be used to implement the networking range from simple to complex. A more complex homogenous autonomous system built from a space-based network using inter-satellite links and smart switching satellites, may peer with terrestrial autonomous systems. This is fundamental in satellite network design approaches in the space-based Iridium and Teledesic proposals satellites. Figure 2-4 shows the classical network layering.
Figure 2-4 Full Networking and Routing Approach, e.g. Iridium, Teledesic [1]
2.3 TCP/IP over Satellites As stated by Farserotu and Prasad, ―The Internet has rapidly evolved as both a means of data exchange and commerce. The origins of the Internet can be traced back to the U.S. ARPANET project in the 1960s. ARPANET was created by the U.S. Advanced Research Project Agency (ARPA), now known as the U.S. Defense 23
Advanced Research Projects Agency (DARPA). DARPA began working on the Internet technology in the 1970s. Initially conceived for computer networks, the Internet has become an information highway capable of supporting a vast array of information services between interconnected and potentially mobile information devices and end-systems. Satellite networks, especially LEO constellations with dynamic inter satellite links, have led to the need for dynamic adaptive routing. As a result, satellites must support onboard routing (OBR) and onboard switching (OBS). This is perhaps most especially relevant to LEO satellites. The development of spot beams and beamforming was also a significant factor in the introduction of OBS and more sophisticated medium access protocols (MAC).
Complex MAC techniques are
increasingly employed to use capacity efficiently. Capacity is allocated via circuits and a logical link control (LLC) layer. Today, the trend is toward increasingly complex satellite systems that support advanced OBS and OBR over ISLs and OBP for beam-forming and enhanced performance in support of broadband satellites [13]. Nowadays, the information exchange over the Internet is governed by the Transmission Control Protocol (TCP) and the Internet Protocol Suite (IP) which are packet-based protocols designed to support communication over data networks. TCP/IP corresponds to the transport layer and network layer of the ISO/OSI reference models‖ [2], [13].
24
2.3.1 TCP Segment TCP is the most important transport protocol in the TCP/IP protocol suite. A reliable data transfer over the unreliable datagram service provided by IP is implemented by TCP. The implemented TCP is responsible for information flow and is a congestion control mechanism: a rate of consistent transmission ensuring that data are with the capacities of both the receiver and the intermediate links in the network path. There are many TCPs in a network link; TCP is responsible for ensuring that it responsibly shares a link‘s capacity among the connections being used. As a result, TCP is the root of most throughput issues [19]. TCP provides a reliable stream delivery service. The basic protocol data unit is the segment. The segment is employed to exchange data and control information (e.g., to open or close a connection, to advertise the window size), as well as to carry acknowledgments (e.g., piggybacked with the data) over TCP connections. Each TCP segment is divided into fields, as shown in Figure 2-5. The source port and destination port fields are used to identify the application programs at the end of the TCP connection. The sequence number identifies the data, contained in a segment, within the sender byte stream. The TCP header length (TCPHL) field is used to identify the header length. Code bit flags are used to indicate the purpose and type of a segment (e.g., data, acknowledgment, and control). As stated by Farserotu and Prasad, ―The acknowledgment number field identifies the next byte that the source expects to be acknowledged. As in the case of the IP header, the TCP header is of variable length. TCP employs a sliding window acknowledgment mechanism. As the receipt of data is acknowledged by the receiver, the transmitter slides the transmitting window forward. 25
However, if a negative
acknowledgment is received, the transmission is stopped. The window field is used to advertise the number of additional bytes that the receiver is ready to receive. The window size is variable and may be adjusted during the course of a connection (e.g., dependent on congestion). The checksum field is used to validate both the TCP header and data. The urgent pointer field indicates the location of urgent data (e.g., interrupts) as a byte offset relative to the current sequence number.
The options field is used for
miscellaneous purposes, such as negotiating the maximum segment size (MSS) over a connection‖ [13].
Figure 2-5 TCP Datagram Header [20]
2.3.2 TCP Conceptualization As stated by Luo, ―TCP is the most widely used transport layer protocol in the Internet to provide reliable data transmissions. When TCP was first released, it only defined the procedure of establishing and disconnecting connections, the packet sequencing functionality and basic retransmission mechanism based on the timeout 26
settings. There was no congestion control mechanism in the first TCP version. In order to deliver the data from a sender to a receiver, a connection must be established via a procedure called the three-way handshake.
The steps of the three-way
handshake are that the sender utilizes the synchronization (SYN) control flag to request a connection to the receiver and records the sequence number. The receiver utilizes the acknowledgement (ACK) control flag to acknowledge the request, and the SYN control flag to request the connection to the sender and record the sequence number; the sender utilizes the ACK to acknowledge the request for the connection from the receiver. When the three-way handshake has finished, the data transmission procedure can be started. After all, the data have been transmitted, and the sender and the receiver need to send the finished (FIN) control flag to close the connection. The reliability provided by TCP is implemented by the sequence numbering mechanism. The sender marks every packet sent with a sequence number and the receiver acknowledges every packet received. If the sender does not receiver the ACK of a certain packet within a particular period of time, the packet is deemed lost and is consequently retransmitted. A flow control mechanism is also described in the original TCP. The ACK packet has a receiver-advise-window that defines the buffer size that is preferred by the receiver. With the receiver-advise-window, the receiver can prevent the sender from sending more packets than can be handled by the receiver. Several versions of TCP have appeared since the first one was designed. TCP Tahoe was added for the lack of congestion control mechanism in the TCP. TCP Tahoe has three basic congestion control mechanisms: slow start, congestion control, and fast retransmission. Congestion window (cwnd) and receiver-advise-window (rwnd) are used to control the packets injected into the networks. Another important 27
metric, the slow start threshold (ssthresh), has been used to control the stage of slow start. In the slow start phase, the cwnd increases exponentially. When the cwnd reaches the value of ssthresh, TCP enters the congestion control stage and the cwnd only increases 1/cwnd for every ACK received on the sender side. In other words, when the receiver acknowledges each incoming segment, congestion avoidance algorithm increases cwnd by roughly 1 segment per round trip time (RTT). When the sender receives several duplex ACK‘s (default 3) from the receiver side, it uses the fast retransmission mechanism to retransmit the lost packet instead of waiting until the expiry of a retransmission timer. When a retransmission timer expires, TCP reenters the slow start phase. The ssthresh is set to the half value of the cwnd and the cwnd is set to 1. The most widely used TCP version in the Internet is TCP Reno, which is based on TCP Tahoe, but adds the fast recovery mechanism to this TCP version. Like TCP Tahoe, the TCP connection firstly enters the slow start phase and the cwnd grows exponentially till it reaches the ssthresh; after this, the connection is in the congestion control stage. When the TCP is in the congestion control phase, the cwnd only increases 1/cwnd when the sender receivers one ACK. If the sender receivers duplex ACK, it is assumed that there is some congestion in the networks, hence triggering the fast retransmission mechanism like in TCP Tahoe. When the sender completes the fast retransmission, the ssthresh is set to the half the previous value of the cwnd, and the cwnd is set to the current ssthresh plus 3. TCP Vegas uses the measured RTT to calculate the exact packet numbers that can be sent by the sender. The sender records the RTT, the sending time of every packet and the minimum RTT, base_rtt. TCP Vegas adopts a new congestion control algorithm. There are two throughput values used in the algorithm, the expected 28
throughput and the actual throughput. The expected throughput is equal to (cwnd / base_rtt) and the actual throughput equals (cwnd / average measured RTT). In the slow start phase, TCP Vegas increases cwnd every two RTT‘s instead of every RTT. TCP NewReno modifies the congestion control and retransmission mechanism of TCP Reno. It extends the TCP Reno‘s fast recovery mechanism. When some packet losses are detected, the sender records the highest sequence number, and then it enters the fast recovery phase. Partial acknowledgements are used to detect the packet losses in the fast recovery phase. When using this mechanism, the sender does not need to wait for the retransmission timeout; it can recover the lost packets in every congestion window, thus increasing the TCP throughput. TCP-Peach includes two new algorithms, sudden start and rapid recovery. It uses dummy segments to detect the bandwidth available in the networks. When the sender is in the sudden start phase, it sends one data segment and one dummy segment. If there is no congestion on the path, the acknowledgement of the dummy segment is used to increase the congestion window size to the size of the rwnd. If there are one or more routers congested on the path to the receiver, then it discards the segment. Rapid recovery uses the same idea to distinguish the link errors from congestion. If the lost segment is caused by corrupted data, then most of the dummy segments should arrive at the receiver and the acknowledgments are used to increase the cwnd. If the lost segment is caused by congestion, and then the sender uses the fast recovery mechanism‖ [2]. As the stated by Mascolo, Casetti, Gerla, Sanadidi, and Wang, ―TCP Westwood enhances the window control and backoff process. Concisely, the TCP Westwood sender monitors the acknowledgment reception rate and from it estimates
29
the data packet rate currently achieved by the connection.
Whenever a sender
perceives a packet loss (i.e. a timeout occurs or 3 duplicate ACK are received), the sender uses the bandwidth estimate to properly set the congestion window (cwnd) and the slow start threshold (ssthresh). By backing off to cwin and ssthresh values that are based on the estimated available bandwidth (rather than simply halving the current values as Reno does), TCP Westwood avoids overly conservative reductions of cwin and ssthresh; and thus it ensures a faster recovery‖ [21].
2.3.3 IP-based Communication As stated in [22], ―An Internet Protocol (IP) is the principal communication protocol in the Internet protocol suite for relaying datagrams across network boundaries. Its routing function enables internetworking, and essentially the Internet. IP, as the primary protocol in the Internet layer of the Internet protocol suite, has the task of delivering packet headers. For this purpose, IP defines packet structures that encapsulate the data to be delivered. It also defines addressing methods that are used to label the datagram with source and destination information. The first major version of IP, Internet Protocol version 4 (IPv4), is the dominant protocol of the internet. Its successor is Internet Protocol version 6 (IPv6)‖.
2.3.3.1 IPv4 Datagram As stated by Farserotu and Prasad, ―IP provides an unreliable, connectionless, best-effort packet delivery service. The basic protocol data unit is the datagram, which consists of a header followed by data. As seen in Figure 2-6, the IP
30
header is divided into multiple fields. The version fields (VERS) field indicates the version of the protocol in use, which is important to ensure that datagrams from different versions of IP are not misinterpreted. The IP header length (IPHL) field specifies the length of the IP header in 32bit words, which is necessary because the IP options and padding fields are not fixed in length.
The option field may be used for miscellaneous communication of
information, such as buffer sizes during setup, error reporting, and time-stamping. The length of the IP header is typically 20 bytes. This occurs when the IP options and padding fields are 0. However, the IPHL must be specified because the options and padding fields are not fixed in size and the maximum header length is 32 bytes. The service type field specifies the datagram precedence, as well as the type of transport required (e.g., low delay, high throughput, high reliability).
The
identification field enables the destination host to identify the datagram to which the received fragments belong. The fragment offset field indicates the location of the arriving fragments in the current datagram. The time to live (TTL) field specifies the length of time in seconds that a datagram may live within the network. The protocol field provides an indication as to the protocol that was used to create the message. IP datagram header checksum is used to verify the header, which may change at a gateway due to fragmentation of the datagram. The IP source address and IP destination address fields indicate the network and host number of the communicating processes, respectively‖ [13].
31
2.3.3.2 IPv6 Datagram As stated by National Electronics and Computer Technology, ―The header of the new protocol IPv6 has been designed to be much simpler than IPv4, which has several fields including a variable length options field as shown in Figure 2-6. The 4bit Version field contains number 6. This field is the same size as the IPv4 version field that contains number 4. Nevertheless, the use of this field is limited because IPv4 and IPv6 packets are not distinguished on the basis of the value contained in there, but as a function of a different protocol type present in the layer 2 envelope (for example, Ethernet or PPP).
The 8-bit Traffic class field in the IPv6 header is
available for use by originating nodes and/or forwarding routers to identify and distinguish between different classes or priorities of IPv6 packets. At the point in time at which this specification is being written, there are a number of experiments underway in the use of the IPv4 Type of Service and/or Precedence bits to provide various forms of ―differentiated service‖ for IP packets, other than through the use of explicit flow set-up. The Traffic Class field in the IPv6 header is intended to allow similar functionality to be supported in IPv6. The 20-bit Flow Label field in the IPv6 header may be used by a source to label a set of packets belonging to the same flow. A flow is uniquely identified by the combination of the source address and of a nonzero Flow Label. Multiple active flows may exist from a source to a destination (with the same source address but with nonzero and different Flow Labels) as well as traffic that is not associated with any flow (carrying a Flow Label of zero). The Flow label assigned to a flow is a numeric value randomly chosen by the source node from range 1 to FFFFFF (hexadecimal). This value must be different from Flow Labels in use on the source node or used in the recent past. All packets belonging to the same
32
flow must be sent with the same source address, destination address, priority, and Flow Label. The 16-bit Payload Length field contains the payload length—that is, the length of the data field following the IPv6 header, in octets. Because it is a 16-bit field, the maximum length of an IPv6 packet payload is 64 Kbytes. If a wider data field is needed, a Jumbo Payload extension header can be used. The presence of a Jumbo Payload is indicated by value zero in the Payload Length field. The 8-bit Next Header field identifies the type of header immediately following the IPv6 header and located at the beginning of the data field (payload) of the IPv6 packet. The two most common kinds of Next Headers are clearly TCP and UDP, but many other headers are possible. The format adopted for this field which is the one proposed for IPv4 by RFC 1700 appropriate integration for IPv6 has been inserted. The Next Header field is generally the same as the IPv4 Protocol field.
The 8-bit Hop Limit field is
decremented by one by each node that forwards a packet. If the Hop Limit field is decremented to zero, the packet is discarded. The main function of the field is to identify and to discard packets that are looping because of erroneous routing information. The 128-bit Source Address field contains the IPv6 address of the node originating the packet. The IPv6 address a format is specified by RFC 1884. The 128-bit Destination Address field contains the IPv6 address of the node recipient of the packet. If a Routing header is present, the address is not that of the ultimate recipient‖ [23].
33
Figure 2-6 Comparison between IPv4 and IPv6 Datagram Headers [20]
2.3.4 IPv6 and Satellites As stated by Ali, Liang, Sun, and Cruickshank, ―As for the next generation network protocol in the satellite systems, some shortcomings of IPv4 are emerging to be overcome by IPv6, and the most important drawback is the shortage of address space. IPv6 service has been offered to several Internet Service Providers (ISPs) in North America, Europe, and Japan. Mobile and vehicular networks will adapt it due to its huge IP address network space.
The existing networks which are being
proliferated and integrated by IPv6 have to coexist with IPv4 using dual-stack, protocol translation and tunneling approaches for a long transitional period. A trial deployment has demonstrated IPv6 that can be used over satellites. Digital Video Broadcast (DVB) standards do not document many current satellites for 34
IPv6. The default Multi-Protocol Encapsulation (MPE) does not deploy IPv6 due to lack of MAC source address, and a payload Type fields. Tunnel mode (e.g. IPv6 over IPv4), or a link layer encapsulation (LLC) can be used in absence of IPv6 support. Extra processing time is added to these schemes. An IPv6 friendly encapsulation scheme like Unidirectional Lightweight Encapsulation (ULE) encapsulates the MPEG-2 Transport Stream. DVB-S2 makes necessary a new encapsulation to the introduction of Generic Stream; some fundamental design choice of ULE relies on the Generic Stream Encapsulation (GSE). For the next generation satellite system design choices of ULE, the satellite system design should be as far as compatible with GSE/ULE. However, of the vast majority of existing satellite systems that use MPE, the transition uses a long time. IPv6 is not fully supported by the commercial twoway DVB-RCS terminals. IPv6 over DVB-RCS has been tested by some projects (e.g. the EC SATSIX Project). An upgrade to IPv6 needs some amendments in the standards, especially to ensure that IPv6 enables control and management of planes‖ [24].
2.4 Integration of Satellite Communication and Internet As stated by Luo, ―There has been a lot of debate on the possibility of using IP in satellite communications for a quite long time. The main objective of designing IP is to provide a methodology to inter-connect exiting different networks.
By
introducing IP, different data networks can be connected at the network layer. The integration of IP and satellite communication technology requires IP to meet the demands of space communication.
Though IP was designed for the terrestrial
networking environment instead of satellite applications, researchers try to apply IP
35
into different networking situations due to its natural simplicity and efficiency of TCP/IP. They proposed various protocols to be combined with IP for use in different scenarios. Nonetheless, there are some key issues with respect to the suitability of TCP/IP over satellite links, which have large and variable transmission delays. Generally speaking, TCP/IP is challenging for carrying real-time, interactive, and constant bit rate (CBR) servicers, e.g., voice in satellite networks. In comparison with terrestrial networks, some special issues concerning TCP/IP implementation and performance are summarized as follows‖ [2].
2.4.1 Routing in Satellite IP Networks As stated by Korçak and Luo, ―In contrast to terrestrial networks, LEO satellite networks are fast changing networks.
The topologies of LEO satellite
networks change constantly because LEO satellites move along their own orbits all the time, thus making routing a challenging problem. Researchers have done lots of work to solve the routing problem in LEO satellite networks.
Many
algorithms/protocols have been proposed [2]. The performance of routing algorithms in IP satellite networks get highly affected by some intrinsic features of LEO satellite communication systems. Especially, both adopting traffic and topology dynamics can receive a major broadcast in the resources of utilizing the satellite procedure. Diverse routing algorithms have been presented to satellite networks for the purpose of solving this defect.
In this chapter, these algorithms have been classified and
described as interrelated technical sues for practicing the satellite networks in the next generation. Although a practical problem for the next generation can still be caused by some algorithms, minimum broadcasting will improve resource utilization. The
36
formidable tasks in satellite networks remain with QoS and multicast routing algorithms in addition to the arrival of elaborate satellite network architectures such as new space technologies and multilayered systems‖ [12].
2.4.1.1 Handling Dynamic Topology A dynamic topology of satellite network status for links and positions is considered as actively changing. Conventional routing techniques (Open Shortest Path First - OSPF and Routing Information Protocol - RIP) are widely used in terrestrial networks. Satellite networking is impossible since these protocols depend on the negotiated topology information that is regular by being refreshed. Nevertheless, the satellite networks, which instantly change are able to predict and are periodical in accordance with the orbital movement of the satellites. As a result, this periodicity feature is presented utilizing some routing techniques. A Finite State Automation (FSA) is modeled in a LEO satellite network. The prepared multiple orbitals of satellite layers is placed in the system period, and the gateway term is split for each state. The ISL connectivity data are obtained with the states to have a fixed topology by the network in each state. A stated finite number is according to the regularity in the satellite constellation networks. Afterwards, each of these fixed topologies gets proposed to perform optimal routing for the best utilization of ISLs in the system. Wener [25] proposes Dynamic Virtual Topology Routing (DVTR) for ATM-based satellite networks, which works in the same way as the FSA algorithm. Again, the system period is divided into a time interval schedule, and then the topology remains constant over each interval. For each interval, the best path is found by the totally off-line optimization procedure, or selected from a set of alternative
37
paths depending on the on-line traffic information. In these FSA-based techniques, the quantities of routing tables are collected on-board. They are retrieved by the change in topology.
However, the messaging broadcast and computational
complication got reduced.
The satellites need a large storage space valence to
decrease the requirement of on-board storage and an appropriate quantity of Network Control Centers (NCC) even though the messaging broadcast and computational complication get reduced. NCCs are placed on the ground which could be utilized using a technique proposed by Gounder, Prakash, and Abu-Amara technique [26]. In additional to the concept of appropriate referring, it can be repairable to accomplish satellite constellation which is the concept of Virtual Node (VN), by Mauger and Rosenberg [27]. A logical address assigns the Earth‘s surface with the fixed sections. A satellite gathers the VN above the footprint of fixed Earth for a period of time to serve the footprint. Each VN is gathered by a certain physical satellite at any given time. A satellite disappears due to Earth‘s rotation. Therefore, with the next satellite passing, the state information is transferred to it, which causes VN to become represented. The virtual topology is firmly stable because handovers between VNs and physical satellites are synchronously performed. A routing decision is based on a fixed virtual topology, and the satellite constellation dynamics is separate from the network layer. Nowadays, a lot of routing protocols are proposed based on the VN concept. IP-Multicast is presented in Wood, Clerget, Andrikopoulos, Pavlou and Dabbous [28]. for the algorithm to adopt IP routing at the VNs in order to seamlessly integrate the space network with the global Internet and provide direct support for IP-QoS. A distributed datagram routing algorithm, and a multicast routing algorithm for satellite networks with a mesh topology consisting of fixed logical locations (virtual nodes) 38
are introduced in Ekici, Akyildiz, and Bender [29] respectively. In addition, some hierarchical routing mechanisms are developed for integrated satellite networks consisting between LEOs and MEOs by Ekici, Akyildiz, and Bender [29] and Bayhan, Gur, and Alagoz [30] techniques or HAPs, LEOs and GEOs by Dash, Durresi, and Jain [31] technique to clarify LEO orbit by modeling it as a fixed virtual network. Although the VN topology is vastly accepted, it has some insufficiencies, which come from the fact that the VN topology necessitates one-to-one correspondence between physical satellites and virtual nodes and it could not be applied for systems where more than one satellite can serve for a single footprint area [12].
2.4.1.2 Reducing Link Handovers and Rerouting Issues When a connection is broken, the issue of reconnection setup overhead is very important for satellite networks. It is based on the network topology which is highly dynamic in nature. The maintenance of the active connections is necessary as needed by handover during some of ISLs being turned off or the up/down link (UDL) between the matching of the primary satellite being broken and the global node being broken. The delay jitter and signaling overhead can be introduced by rerouting efforts during link handovers. Nevertheless, because the resource unavailability possibility in interchange paths and the rerouting cause delay, the forced extinction possibility of ongoing connection is greater than before. Therefore, the possibility of rerouting for the reason of handover should be minimized. It is necessary for real-time applications of multimedia service which is maintaining QoS warranty using connection-oriented routing protocol. Hence, the connection handover minimizing number is a vital issue.
39
In order to reduce link-handovers, Werner [24] proposes an optimization procedure for their system based on DVTR as mentioned in the previous paragraph. While delay and/or delay jitter are being kept minimal, minimization of the number of handovers in the whole system period is taken into account for the selection of the most appropriate path between a satellite pair for each time interval to be calculated. An optimization procedure results in a unique route for all connections between a satellite pair during a time interval. The algorithm in Werner [24] is improved in A Dynamic Routing Concept for ATM Based Satellite Personal Communication Networks, and the optimization is done over a sliding time window, rather than the whole system period.
In other words, handover rate and hand-over delay jitter
determine the routes, occurring when a time window is minimized. New routes are determined after each topology change by sliding the window.
The relative
magnitude of call duration to the window size has an important effect on the performance of the algorithm. It is stated that the window size is fixed, and it should be around the average call duration to achieve better performance. Ercetin, Krishnamurthy, Dao and Tassiulas [32] propose a predictive routing protocol (PRP), which aims to reduce handover probability in an online fashion while taking PRP‘s characteristics into account. In this approach, the deterministic natures of the satellite topology and user location information are used to predict traffic loads on the ISLs up to a short time in the future. Then, for each connection, k ordered paths are obtained depending on the residual bandwidth information. This operation is done for l short intervals up to a time that the footprint of a satellite completely changes. Then, an appropriate path is selected among k paths for each interval; for example, link changes are reduced (hence overhead due to the fact that handovers are
40
decreased), and the user traffic is balanced. The computational overhead of this algorithm is quite high, especially for a large number of k values. Nguyen and Jukan [33] give a suggestion about higher lifetime favoring ISLs to decrease the handover ratio. The request packets are flooded to the destination in each requested connection. These packets collect the lifetime information while they traverse along the route. The destination node uses intermediate satellites and lifetime information for deciding on the most suitable path. In their projected adaptive routing system, Chen and Jamalipour [34] also consider minimizing a number of handovers between the paths set which persuades the requirements of QoS. So, the ability of a path is minimizing the possible numeral of handovers and is also greater than the great probable path with a predefined degree of top quality. The schemes that were mentioned make optimization among satellite nodes. Therefore, an ISL handover to a neighbor is the only one to consider. Nevertheless, the connection time for handovers should build up the up/down link among the foundations of gateways on the ground to access the satellites. Some among the last hop on the ground are broken out of the satellites. The handover technique is used for an inter satellite link between plane and/or orbit for the best optimization link. Because the satellites group with respect to user stations tends to decrease inter satellite handovers.
A Probabilistic Routing Protocol (PRP) is introduced by
Uzunalioglu [35]. PRP is called statistics of satellite constellation topology dynamics attempting to decrease rerouting among ground end-users.
Mainly because the
algorithm can turn off the connection before the mechanism finishes, it avoids using ISLs. The Probability Density Function (PDF) for the time period in which the call uses the instituted route is used. The connection routes are established by using the determined PDF, such as a call extinction event from the routes being ended or an 41
inter-satellite handover instead of a connection of handover with a target possibility. Among route computations for newly appearing calls and inter-satellite handover calls is a distinction as dropping a continuing call. It practices an inter-satellite handover which is more irritating than blocking a new call. It is a distinction to drop an ongoing call between routes calculated for newly arriving calls among inter satellite handovers.
It is known that an inter-satellite handover is more annoying than
blocking a new call. Using PRP is suggested only for calculating the routes for newly arriving calls since PRP increases the call dropping rate. Uzunalioglu, Akyildiz, Yesha, and Yen [36] use Footprint Handover Rerouting Protocol (FHRP) for intersatellite handover calls. FHRP balances the simplicity of route augmentation and optimality of complete rerouting.
It has two phases: augmentation phase and
Footprint Rerouting (FR) phase. A route between new end satellite and the original route is established and the unused portion is removed when either source or destination satellite goes out of visibility region of ground terminals. This is called augmentation. The connection is rerouted, using the original routing algorithm if it is not possible to do so. FR in only possible when new end satellites are the successors of the end satellites in the original route. FR is applied and the connection route changes completely when both ends experience a handover [12].
2.4.1.3 Path Minimization Algorithms The propagation and processing delay on the satellites are intended cost of a path in a satellite network. Compared to terrestrial networks, the propagation delay is more significant in space networks because of the height of the satellites, and because the distances between the nodes are long. An increase in satellite hops is traversed,
42
and suspends the total propagation and processing. Decreasing the processing delay has some useful side effects like decreasing the power consumption and data blocking probability in satellites. Hence, path minimization is an important task in satellite networks. In some research, it is supposed that ISLs have fixed lengths in the network topology. Different researchers claim that this hypothesis is rational because the length change is low in most of the satellite constellation topologies, particularly for regions which are close to the equatorial region. In addition, it is also requested that minimizing the hop count metric should be more critical for the best performance of the system, and hence it is rational to disregard dynamic length changes of ISLs. By the way, numerous researchers think that the governing determinant for accomplishment is the propagation delay, and they intend to find a minimum propagation delay path mechanism with the minimal hop count surrounding the paths. Since ISL lengths have changed in accordance with time scheduled to the dynamism of the satellite topology, this involves the duty.
The summarization of satellite
topology changes and the realized evidence about the nature of satellite network systems (e.g. links over the polar region are shorter than links over the equatorial region) can be used to clarify this duty. Nonetheless, to study the propagation delays, more storage and processing complicacy are required. Sun and Modiano [37] handle static routing in a constant LEO satellite network, which is a limitation a limitation of two dimensional N-ary hypercube. Dijkstra‘s algorithm establishes the minimum-hope path, and some argument resolution themes are examined for maximizing the performance in terms of throughput. It is presented validating and analyzing base the simulation affecting a timetable theme supporting packets closest to their destinations outcomes in 43
supremacy system throughput, at the cost of demoted system fairness. Truly, there could be numerous minimum hop paths in a satellite constellation, caused by its balanced and similar nature. Hence, it is proposed in some research to value the one with the minimum propagation delay. The greatest trivial ways to do via N-ary hypercube are to store the length information of all links for a system phase in each satellite (also, in ground stations that execute routing) and to utilize a shortest path algorithm utilizing this information. This requires a high storage capacity in the buffer of the satellite node. Algorithms are offered by Henderson and Katz [38] and Ekici, Akyildiz, and Bender [39] to minimize the propagation delay. The geographybased algorithm of Henderson and Katz [38] is based on the hypothesis that the series of locally optimal forwarding decisions will yield a route that is close to the optimal route. Namely, depending on the geographic information planted in the residences, each satellite node forwards the information packet to its neighbor satellite nodes that most decrease the length to the destination.
By the way, the datagram routing
algorithm (DRA) is presented by Ekici, Akyildiz, and Bender [39] on behalf of an interested polar satellite constellation. It considers the satellite network as a mesh topology consisting of logical locations (virtual nodes). The data packets are routed in a propagating shape in a fixed topology. DRA is composed of two steps: at a given satellite hop, first it discovers all the neighboring satellites that can move the packet one hop closer to the destination.
Afterwards, from the candidate next hops, it
chooses the one which most decreases the surviving length to the destination [12].
44
2.4.1.4 Load Balancing Algorithms Network traffic requirements are unstable in a LEO network since the group distribution on the Earth surface is highly non-pattern. This may cause congestion in some resources in the system, while others are below utilization. To solve this problem, the routing algorithm should propagate the information flow packets in a balanced way over suitable ISLs between the communicating satellite nodes.
2.4.1.4.1 Source-based Load Balancing In source-based load balancing algorithms, the ingress node is calculated by the route to a given destination node. The entrance nodes could be a global node or a satellite node. If it is located on the ground, more signaling propagation delay is put in. Though, in the second case, computational and storage essentials to execute route calculation can surpass the ability limits of a satellite node. Lin and Keller [40] assort source-based load balancing algorithms further as separate and non-separate algorithms. Only information local to the node is routed by a separate algorithm. Traffic information is collected from the whole network by nonseparate algorithms. Authors advise a non-separate algorithm as follows: each node retains the graph structure of the whole network. When routing is executed, all satellite nodes and edges that are near a fullness point are intersected. Also, a shortest path algorithm is then executed considering the propagation delay as well as the constant transit delay per hop. Chen and Jamalipour [34] present an alternative adaptive routing algorithm that uses the information about the average and the minimum number of engaged channels per route. Initially, the algorithm discovers a set of competitor minimum 45
delay paths that likewise minimize the delay jitter and handover probability. Afterwards, surrounding these diversified paths is the one with a minimum traffic weight in the route, which is based on a weighted mixture of an average, and a minimum number of engaged channels over the route are chosen. An inseparate routing mechanism extends the signaling complexity and computation of the routing architecture, but since it studies traffic adaptively in the whole network, it is better to separate the algorithms. Otherwise, there is a capability drawback of non-separate algorithms; the collector that gathers traffic flow information may not return the real condition because it takes time for the information to be offered in the satellite constellation (causing high propagation delays), and in order to keep away from immoderate signaling, state changes in the network are not always announced [12].
2.4.1.4.2 Central Load Balancing In a central node and satellite nodes, routing tables are analyzed and stored, which occurs in central load balancing algorithms. This central node can be a terrestrial node or a satellite. In this context, it can consider the optimal routing algorithms.
Algorithms are network-oriented.
They are supplying better load
balancing by aiming at minimizing the mean blocking possibility in the network. According to the aforementioned FSA-based algorithm of Change et al. [41], which is offline, density for each node and distances between the nodes on statistical information about potential requirements, involve expected traffic loads to links. For each state, it intends to maximize the residual capacity in the minimum network. Since this is an NP-complete mixed-digit optimization problem, optimal routing 46
requests provide some heuristics in use. The author compares this optimal routing algorithm with a dynamic routing approach, which is based on shortest path algorithm.
In an optimal routing algorithm, routing tables are updated as states
change, whereas dynamic routing updates routes in every broadcasting period, using the obtained link status information. The authors summarize through simulation results that optimal routing is better in phases of recently introduced and ongoing call blocking probability. Papaetrou and Pavlidou [42] present how to execute the flow deviation (FD) algorithm, which is an optimal routing algorithm that plans to discover a routing design that minimizes the mean network propagation delay.
Depending on the
network information grouped from the whole network, a schemed center node executes the FD algorithm. The load is divided by the FD algorithm to separate paths according to path lengths, which are determined by a flow dependent metric mechanism. As the lengths of the paths change, the FD algorithm uninterruptedly accommodates these changes by departing traffic from one path to another, so that the determined cost metric is minimized. The authors show via simulation results that an FD algorithm is better than to Dijkstra algorithm for minimizing of the propagation delay and Adaptive Dijkstra algorithm for discovering the path minimizing a flow metric mechanism. By executing routing in a center node, superior traffic engineering could be sustained using the worldwide view of the network. However, central load balancing algorithms share the same problems with inseparate source-based routing algorithms. Calculation complexity can be shifted to a ground node area that does not endure much from power signal radio frequency limits, but the high signaling radio frequency necessity, and the trouble of correctly exchanging traffic information are 47
the most challenging problems. In addition, the advanced centralized routing may show exact scalable problems in terms of the performance related to capacity limits of the center node and the extensive increment in the calculation complexity with an increase in the network size [12].
2.4.1.4.3 Distributed Load Balancing There can be a lot of minimum-hop paths between neighbor satellites, and routing can presumably be done proficiently because of the extremely balanced layout of the satellite constellations. Providing a static network connection between two satellite nodes may lead to pitiful utilization of every other path. In addition, as it noticed before, the connection-oriented advance may be sustained in reaching path connectivity by satellite handover mechanisms. Preferably, a propagated next hop routing procedure appears to be simpler.
Each satellite autonomously makes a
decision on the good next hop to forward the traffic. Ekici, Akyildiz and Bender [39] develop this advance in the aforementioned datagram routing algorithm. The major purpose of the algorithm is minimizing the propagation delay, but a satellite may vary its determination if the output queue in the buffer for the ISL over the rule of minimum propagation delay path is congested. Taleb, Mashimo, Jamalipour, Kato, and Nemoto [43] show that load balancing might be completed, and present that a satellite is aware of the network traffic restrictions at the next hop satellite. They show an Explicit Load Balancing (ELB) theme, where a congested satellite sends packet information to its neighboring satellites to reduce their sending rate, and its neighbors discover it for every other path. This way can decrease the broadcast packet dropping probability but it is not secure from signaling congestion directly to
48
reaction packets (moreover signaling packets are sent only when it is essential, and they could be required very regularly in some restrictions). The algorithm in Ekici, Akyildiz and Bender [39] and Taleb, Mashimo, Jamalipour, Kato, and Nemoto [43] do not execute any operation for load balancing until some satellite nodes experience a confident level of congestion, (i.e. they are not proactive). From the comparison between the source-based and centralized load balancing algorithms, the distributed load balancing algorithms noticed above grant fast response to traffic variations. Though, they use only the local traffic information, which might not indicate the whole traffic load distribution. Certainly, it is feasible to propagate the local information to the entire network and use it in local next-hop decisions, but this will cause extensive signaling overhead. Another approach that could be considered in the context of distributed load balancing is applying Ant Colony Optimization (ACO) algorithm in an LEO satellite network proposed by Sigel, Denby, and Mascle [44]. In the ACO algorithm, simple agents (called ants) are emitted by satellite nodes within a given period. Information along paths through the system is gathered by these ants, and stored within the routing nodes on its return to its source node. Ants visit nodes on good paths frequently by reporting small trip times, thus reinforcing routing table entries for links contained in those paths, and diminishing those of the other links. Ants on poorer paths will arrive later and report larger delays, causing routing table entries for such links largely unchanged. In an ACO algorithm, there is a trade-off between emitting frequency of ants and signaling overhead. Emitting ants more frequently yields a better adaptation to traffic changes, but may congest the traffic [12].
49
2.4.1.4.4 Hierarchical Load Balancing A hierarchical (multilayered) satellite architecture system within Inter-Orbital Links (IOLs) between layers of satellite constellations are of much concern as they may result in better performance than private layers. When compared with inseparate algorithms, while empowered to improve an adaptation of traffic variations, there is a hierarchical advance objective to decrease the calculation complexity on the satellite nodes and the communication load traffic on the whole network. Lee and Kang [45] present a Satellite-over-Satellite (SoS) topology, where the satellite topology is made up between LEO and MEO layers. LEO satellites send ISL state information to an upper layer. The upper layer is an MEO satellite using this state message in command to obtain some Local Routing Information (LRI) about the LEO satellites which are in its spot beam area (these are changed with scheduled time which is dependent on the change of LEO satellites with consideration of MEO satellites). This message information is also transferred between MEO satellites. Moreover, MEO satellites obtain Global Routing Information (GRI) containing all routing message information of the LEO and MEO layer satellites by using this transferred state message information and react by sending it through IOL to all LEO layer satellites that are within their spot beam areas. In the present routing algorithm, the shortest distance dependent traffic is transmitted straight through lower layer satellites, but long distance dependent traffic is transmitted straight through IOL up to the MEO layer in command to reduce the average number of satellite hops and resource consumption. The Satellite Grouping and Routing Protocol (SGRP) presented by Chen and Ekici [46] is another hierarchical algorithm where LEO satellites are split into
50
divisions agreeing to the footprint area of the MEO satellites in each snapshot period. Each LEO group is encompassed by a MEO group. Related to the proposal in Lee and Kang [45], MEO satellite measures the minimum delay paths for its LEO elements, depending on the link state information reached from the LEOs. The authors grant a detailed analysis of their offered system. Dash, Durresi, and Jain [47] study a three-layered architecture including GEOs, LEOs, and HAPs, a solution to Voice over IP (VoIP) applications. GEOs perform as backbone routers, LEOs as the second layer and HAPs to cover unique areas with sensitive and heavy traffic such as disaster and battlefield areas. LEO layer satellites are supposed to be Earth-fixed and modeled as VNs; therefore, GEO satellites cover logically fixed LEO layouts.
The LEO satellites transfer their
information of routing tables as their footprint area variations.
This structure
empowers all of the satellites to cover other layer stations. LEO satellites and HAPs measure the remaining bandwidth on their departing links and send the message information to the GEO layer with a given season.
This link state message
information can go to the fixed global gateways for processing because the GEO satellites have restricted on-board processing capacities.
Then, organizing intra-
domain routing tables, gateways will upload these tables to the GEO satellites, and the GEO satellites also cover them to the LEO satellites and HAP that are in their spot beam area. Also, a whole routing table for each territory is organized, which consists of the maximum leftover bandwidth paths between separate border satellite nodes of the territory. These routing tables are then exchanged between GEOs and transferred to the LEOs and HAPs. NGEO satellite networks integrated with HAPs may have great potential in the next generation telecommunication services. In Dash, Durresi, and Jain [47], the 51
mobility of the LEO layer is simplified on the assumption that the physical LEO satellite network can be reduced to a fixed logical topology. As the authors indicate, this assumption is valid for a satellite system with Earth-fixed footprints. However, this is impractical in most satellite systems and the mobility of the satellites should be handled in more realistic ways. The coming of hierarchical architectures implies intensive redundancy and routing choices in satellites systems. To empower the greatest use of broadband satellite technologies in the next generation communication systems, a collection of topological layouts and routing topics should be researched. Then, it can be categorized based on the fact that these routing algorithms agree to the place where the routing is executed: source-based, central, distributed, and hierarchical load balancing algorithms, as shown in Table 2-2 [12].
52
Table 2-2 Comparison of Different Load Balancing Schemes [12] Load Balancing Scheme
Advantages Simple
Isolated
Source-based Non-isolated
Central
Distributed
Hierarchical
Global view of the network Good traffic adaptiveness Global view of the network Whole information can be used for an overall optimization procedure Computational complexity is carried from satellites to a central node Each node uses up-todate local information Low signaling overhead No rerouting issues Fast adaptation to traffic changes More routing choices Better adaptation to traffic changes with less computational and signaling cost
Disadvantages No global view of the network Low utilization Difficult to guarantee up-todateness of the traffic information High signaling overhead Difficult to guarantee up-todateness of the traffic information High signaling overhead Scalability problem No global view of the traffic load distribution Utilization is somewhat low Physical challenges in providing interorbital satellite communications Increased system complexity
2.4.1.5 Traffic-based Routing The satellite systems should be able to propose QoS guarantees to maintain the rapidly-growing real-time multimedia services, which are complicated in networking with less connection, owing to the difficulties in accounting for the interruption aspects of QoS and sequencing.
Normally, QoS guarantees are offered through
53
connection-orientation. However, because satellites in NGEO systems have a high mobility, it is difficult to reach path connectivity. Hence, because of handovers during calculating the routes, some of the algorithms explained above plan to reduce the rerouting probability. Therefore, offering QoS guarantees without reducing the rerouting possibility to extremely low in levels is not easy. However, this advance is also not completely perfect. It has its own problems, as defined before. One more aspect point in providing QoS guarantees is to decrease the propagation delay jitter that happens directly to path rerouting. In an LEO satellite constellation system, the movement of satellites creates variations in the relative positions in the middle of any neighbor satellite that belongs to separate orbits. The result is unacceptable steadiness of delay jitters.
Hence, a traffic-based routing
algorithm has to try to decrease the propagation delay jitters for finer QoS conditions while retaining the delay itself as low as possible at the same time. This point is determined in the environment of different proposed algorithms in the literature Werner [25] and Chen and Jamalipour [34]. Regarding handovers, it is estimated to select a new path that is not significantly different from the prior one in its distance, while sometimes the chosen path is not the shortest one. Nguyen and Jukan [33] present a propagated QoS-routing advance. The root node floods connection request packets towards the target. At each mediator node, the QoS parameters (delay, lifetime of ISLs, etc.) are updated. When connection request packets contact the destination node, the target node takes out the paths which do not satisfy the QoS requirements. In the middle of all possible paths, the one network path with a minimum number of hops and maximal lifetime is selected.
54
Mohorcic, Svigelj and Kandus [48] present a traffic-class-dependent (TCD) routing algorithm. Triple levels of traffic are determined: A: traffic delay sensitive; B: traffic throughput sensitive; and C: traffic best effort. The routing algorithm performs variously for each level of traffic. Each satellite node has three parts of outgoing queues (one part for each traffic class) supporting each outgoing satellite link. A scheduler must be executed, which explains the exact transmission sequence of packets in the outgoing queues buffer. Certainly, the selection of the time able policy has a big effect on the traffic-based routing performance of the particular traffic class.
The TCD routing algorithm endeavors to guarantee the quality of
various traffic levels. Although, it shall appoint the only route for a definite level with huge data network traffic and shall heavily overhead the selected path. This might adversely affect the network traffic load balancing over the whole satellite constellation [12].
2.4.1.6 Routing Form Space-Ground Integration Point-of-view The problem of how to combine space-networks with global networks originates from the mission of using satellite systems as a part of a Global Area Network (GAN). Generally, there are two trends in this environment: agreeable to the first trend, the objective of which is to utilize the existent algorithms as vastly as feasible and furnish interfaces with global networks as clearly as feasible; whereas, there is a second trend to use a discretionary routing algorithm in the space section. The satellite constellation network can be created and performed autonomously in the global network. The defect of the later trend is that there is a need of an address
55
resolution algorithm and some involved interworking mechanisms. Though, it is still a better advance than the former trend in intervals of scalability. Presently, IP protocols dominate the end systems added to the ground satellite terminals. Hence, the research that investigates how to utilize IP routing exactly to satellite systems could be discussed in the environment of the first trend. A procedure is inspected by Wood, Clerget, Andrikopoulos, Pavlou and Dabbous [28]. based on the VN topology that is proposed to affirm IP routing into the satellites.
This
procedure supports IP-QoS and IP-multicast which combine and discriminate service models.
Although, there are some challenging problems with these techniques.
Initially, the variable-length IP packets must fit into a fixed-length frame layout in the space section. The authors have to complete this by using either obvious IP-level fragmentation or implied lower-level fragmentation in command to break packets; for example, they can fulfill the frame structures, by using stuffing in command to fill up the frame structures. The next significance is scalability. An enormous sum of routing message information must be updated for both the ground and space sections when the global network extends in size. However, this is not possible for satellites, since the capacity of satellites is limited and cannot be upgraded once they are launched. Hence, it is best to divide and detach satellites and Internet routing updates. At last, since IP-routing is slow and requires high processing power, it is not proper for satellite systems which are provided with limited on-board processing capacity. The authors explain that the IP-routing performance is uninterruptedly enhanced and by using some shortcut IP-switching mechanisms, such as Multi-Protocol Label Switching (MPLS), it appears feasible to defeat this problem. While IP protocols are dominant in terrestrial nodes, the majority of the proposed satellite systems (e.g. Spaceway, Astrolink, Skyway, and Cyberstar) plan to 56
use ATM as the link layer technology for interconnecting the satellite terminals by the Kota [49] technique. This is partly due to the fact that, at the time of designing these systems, ATM was seen as the dominant future network technology. In between the design and the prepared stages of a satellite system there is an important time gap. This time delay causes a difficulty in the state-of-the-art technology in orbit to be controlled and utilized. In addition, the next generation of satellite networks should provide and support the manifold types of services. It should be able to interwork with different terrestrial networks, such as B-ISDN, the Internet, etc. Therefore, it is reasonable to do the isolating of routing in the space segment from the terrestrial networks. For this purpose, the satellite network gets suggested to monitor as an Autonomous System (AS) with a dissimilar addressing system. An IP address of the exit node is translated to a network address via an address resolution protocol in order to integrate a satellite constellation in the Internet at a Border Gateway (BG). In order to communicate with terrestrial ASs, an external routing protocol (such as Border Gateway Protocol: BGP) could be run on the BG of this AS. It is more advantageous to implement BGs in a dedicated ground station to reduce the load on the satellites. In terrestrial networks, the cost metric among different ASs is the controlling factor when creating a route between nodes form different ASs. This occurs by the shorter internal paths in a terrestrial AS when compared with inter-AS paths. Rather, this is not the case for a satellite network, since an internal path can be easily as long as an external path. So, in the satellite environment, the routing protocol should consider the internal cost metric to be as important as the external one. Wood, Clerget, Andrikopoulos, Pavlou and Dabbous [28] mention that in the next generation, broadband satellite constellations can carry IP traffic by handling a 57
union of tunneling, network address translation, border routing protocols, and MPLS. MPLS allows affirming new prototypes for traditional IP traffic by decoupling packet forwarding from the message information carried in the IP header. This is completed by offering the routing message information to the essential routers and appointing short labels to the packets at the entrance place. MPLS has some engaging algorithms substantially supporting the combination of the IP global with QoS and traffic engineering functions. Donner and Berioli [50] handle apply naturalized MPLS over a satellite constellation. Satellite constellation topologies that do not have any seam (inclined Walker constellations) are known as the powerful candidates to host MPLS, directly to their durable nature. However, the fundamental and regular handovers between satellite and ground stations in which topology dynamics are scheduled to changing ISL distances continue a challenge. At the entrance place of an MPLS network, there are Label Edge Routers (LER) which manage the label distribution. The authors present locating LERs on the ground to keep away from i) costly and complicated on-board processing in the satellites, and ii) more signaling overhead required for restarting QoS negotiation or acceptance control for rerouting of a Label Switching Path (LSP).
Various schemes for route calculation (consisting of
intelligence in phases of network traffic engineering, adaptiveness, and/or optimization) and LSP administration (verifying the outcome of route calculation in the satellite network) are researched. Centralized routing advances are inspected as more hopeful for usage inside the MPLS framework. Further information related to the Donner and Berioli algorithm can be found in [50]. MPLS-based networking in satellite constellations is an alluring advance. Nevertheless, some significant practical problems connected to maintenance and rerouting overhead are still unsolved and earn further research [12].
58
2.4.1.7 Multicast Routing Thanks to the capability of satellites provided to broadcast a large amount data over a huge area, the multicast routing over satellites has turned into an extremely hot topic for research.
Ekici, Akyildiz and Bender [29] show none of the existent
multicast routing protocols such as Reverse-path Multicast (RVM) by proposed Deering and Cheriton [51], Distance Vector Multicast Routing Protocol (DVMRP) by Korcak [12] or Multicast Routing Extensions for OSPF (MOSPF) with Moy [52], these techniques are proper for satellite networks, whereas they use some types of seasonal message information exchanges to form and/or maintain multicast trees, and this is absolutely not satisfactory due to the physical restrictions of satellites. To fulfill the gap, the authors develop a multicast routing protocol for LEO satellite IP networks, where multicast trees are structured based on the datagram routing algorithm proposed by technique Ekici, Akyildiz and Bender [39]. The prototype intends to minimize the number of branches going out of a satellite at each step. The authors summarize that their algorithm performs better than the existing multicast routing algorithms in terms of E2E delay. However, multicast routing algorithms for multilayered satellite networks remain an appealing research area [12].
2.4.2 Queue System in IP Networks In the past, the decentralized and fast-changing evolution of the Internet architecture worked reasonably well.
However, nowadays, the integration of
enormous networks is more vulnerable to frequent congestion, and the network failure is increasing exponentially caused by the network traffic. Congestion occurs when the total demand exceeds the bandwidth that the available resources can provide. 59
In light of observation, researchers began to consider congestion control at gateways.
Congestion contents for considering the mechanisms at gateways are
queue management algorithms and scheduling algorithms. Each of the mechanisms is inefficient in certain circumstances, especially in heavy traffic network research, which has become a continuous process in identifying the best Active Queue Management (AQM) algorithm. Congestion in gateways results in a high packet loss, causing the various existing AQM schemes to reduce their high cost. Various factors or metrics are used to detect congestion by the existing schemes. These factors are used to estimate congestion in the queue, based on various AQM algorithms which have been proposed in the past few years.
Congestion
metrics are based on the schemes like Queue-length, Load, both Queue and Load, and others like Loss rate. Further, some of these congestion metrics analyze and control the congestion in gateways more accurately. Congestion metrics can be categorized based on these factors: AQM schemes without information flow and with information flow as shown in Figure 2-7 [53]. The system characteristics of these major AQM schemes are comparison based on performance metrics in Table 2-3 [53].
60
Figure 2-7 Classification of AQM Schemes [53]
2.4.2.1 Congestion Metric without Information Flow It is the first category of congestion metrics that are considered by classification and are not the information flow. Nevertheless, it can classify the congestion metric further. Various congestion metrics like queue length load and utilization are the contributors to the congestion in gateways by AQMs.
2.4.2.1.1 Queue-based AQM a) RED: Random Early Drop is the first well-known proposed AQM scheme. It is one of the popular algorithms.
It tries to avoid problems like global
61
synchronization, lock-out, bursty drops, and queuing delay that exist in the traditional passive queue management, i.e. Drop Tail scheme. As stated by Floyd and Jacobson, ―A moving average of the queue length to manage congestion is maintained by RED discipline. It either marks or drops the packet with a probability when the moving average of the queue length lies between a minimum threshold value and a maximum threshold value. Then, the packet is dropped if the moving average of the queue length is greater than or equal to a maximum threshold. Even though it tries to avoid global synchronization and has the ability to accommodate transient bursts, in order to be efficient, RED must have sufficient buffer spaces and must be correctly parameterized‖ [54]. Computing the average queue size,
, as given below detects a congestion
in the RED algorithm. To calculate an average queue size, an exponential weighted moving average (EWMA) uses a low pass filter. Two thresholds are compared with the average queue size: a minimum threshold
and a maximum threshold
. It drops the packet with a probability if the average queue size is between a minimum and maximum threshold. Then, it drops the incoming packets if it exceeds a maximum threshold. The packet drop probability is a linear function of queue length. So, various parameters are dependent on the dropping probability like ,
, and
,
. These parameters must turn the RED well to perform better.
However, it faces weaknesses such as accurate parameter configuration and tuning. It is becoming a major disadvantage of the RED algorithm.
Typically, a global
synchronization is avoided by the RED algorithm, however it will fail when there is an unreasonable change in the load. Minimum information is given regarding the severity of congestion by Queue length. The packet is not considered arrivals from
62
the various sources, which is also a very important measure for the congestion indication by RED [53]. The pseudo-code of RED is For every packet arrival { Calculate Qave if (Qave maxth) { drop the packet } else if (Qave minth) { calculate the dropping probability pa drop the packet with probability pa otherwise forward it } else { forward the packet } }
63
Variables: Qave
: average queue size
pa
: current packet marking probability
q
: current queue size
pb
: temporary marking or dropping probability
Fixed parameters: wq
: queue weight = 0.1 0.0001
maxth : maximum threshold for queue minth : minimum threshold for queue maxp
: maximum dropping probability
The congestion remains as an inherent problem since RED considers only the queue length and not inter-packet arrivals. In case the number of users increases, the performance of the RED queue degrades. According to queuing theory, it is only when packet inter-arrivals have a Poisson distribution that the number of active sources is directly related to queue length, thus indicating the true level of congestion. However, non-Poisson decides in network gateways packet inter-arrival times, which clearly does not indicate the severity of congestion [53].
64
The network load variation is based on the packet lost, and the utilization at the link varies as RED is sensitive to parameter configuration. In case of accurate tuning of parameter
, high utilization and low packet drop at the link can be
achieved. In case of poor
, value results in a large packet drop [53].
b) DSRED [55]: RED uses a single linear drop function to calculate the drop probability of a packet, and uses four parameters and average queue to regulate its performance. RED suffers from unfairness and low throughput. Two segments are used by DSRED to drop the function which provides much more flexible dropoperation than RED. However, DSRED is similar to RED in some aspects. Both use linear drop functions to give smoothly increasing drop action based on average queue length. Next, the average queue length is calculated by them by using the same definition. The function of DSRED is dropped by the two segments to use the average queue length, which is related to a long term congestion level. As the congestion increases, the higher rate will increase with drop instead of constant rate. As a result, it will relieve congestion and the throughput will be increased. This results in a low packet drop probability at a low congestion level and gives on an early warning for long term congestion. A better packet drop performance result was shown by DSRED in higher normalized throughput than RED in both the heavy load and low load. It has lower average queuing delay and queue size than RED [53]. c) MRED [56]: To overcome problems faced in RED, the packet drop probability is computed by MRED based on a heuristic method rather than the simple method used in RED. In this scheme, a simple EWMA estimates the average queue size used in the forward or backward path. To determine how frequently the gateway drops packets, it calculates the packet drop probability at the current level of
65
congestion. The step form computes in MRED the packet drop probability by using packet loss and link utilization history. MRED is able to improve fairness; RED is compared by throughput and delay [53]. d) Adaptive RED [57]: The Adaptive RED uses the congestion indicator as the queue length, the drawback is overcome that exists in RED that requires constant tuning of parameters depending on the traffic condition in the network. Dependency is removed by Adaptive RED by auto-tuning the parameters
and
. The value
of these parameters varies, based on the network condition and keeps the average queue size within a target range halfway between the thresholds The general design of this algorithm is capacity and
and
.
is automatically set based on the network
the measured queue length adapts based on the
.
The
average queue size is maintained by this algorithm within a predetermined range by adapting slowly and infrequently using the Additive Increase Multiplicative Decrease policy. The main problem of RED is parameter tuning to adapt to suit the network condition. This is automatically done in ARED by adapting
and
, and the
performance of network is improved by varying network conditions. The queue utilization and packet loss rate are regulated by influencing the values of
and
. This gives a better result than RED with increased throughput, reduced packet loss and a predictable queuing delay [53]. e) PD-RED [58]: The PD-RED scheme is introduced to improve the performance of the Adaptive RED scheme. This scheme is based on the proportional derivative (PD) control principle. A
was called by including the control theory
and adapts the maximal drop rate parameter to RED to stabilize the queue length. In the scheme, a typical control system considers AQM. Two parts, which are a new PD 66
controller and the original RED AQM algorithm, constitutes a PD-RED algorithm. Adaptive RED compares the variation of queue length and the drop probability is smaller in PD-RED. Better performance in terms of mean queue length and standard deviation of the queue length is shown by PD-RED [53]. f) LRED [59]: The AQM scheme Loss Ratio based RED, measures the latest packet loss ratio, and uses it as a complement to queue length in order to dynamically adjust packet drop probability. So, in this scheme, the packet loss ratio is a clear indication of severe congestion occurrence. Queue length is also used in a small time scale to make the scheme more responsive in regulating the length to an expected value. LRED tries to decouple the response time and packet drop probability, thereby making its response time almost independent of the network status [53]. g) HRED [60]: In RED, the drop probability curve is linear to the change of the average queue size. But in this paper [59], the drop probability curve is a hyperbola curve. As a result, this algorithm regulates the queue size close to the reference queue value. This makes the algorithm no longer sensitive to the level of network load, and less dependent on the parameter settings. It also achieves higher network utilization. Since HRED is insensitive to the network load, and queue size does not vary much with the level of congestion, the queuing delay is less unpredictable.
It rapidly reaches and keeps around its reference queue length,
irrespective of the increase or decrease in queue length. Hyperbola RED tries to provide the highest network utilization because it strives to maintain a larger queue size [53]. h) ARED [61]: This is an adaptive RED controller designed to offer better performance, and adopt a self-tuning structure to try to keep the average queue length
67
of the RED gateway around the target value. The maximum drop probability is adaptively adjusted using the gradient descent method based on a discrete deterministic mathematical model of TCP RED.
When the queue length in the
gateway buffer exceeds a minimum threshold of ARED, the self-tuning function is used to adjust the maximum drop probability. It behaves well under light and heavy as well as changing network load conditions. When the queue size is stabilized around the optimal value, a good tradeoff between throughput and delay is achieved [53]. i) AutoRED [62]: The AutoRED feature takes care of the traffic properties, congestion characteristics and the buffer size. In AutoRED, the calculation of the average queue size using EWMA model is modified and redefined. Therefore
is
a combination of the three main network characteristics such as traffic properties, congestion characteristics and the queue normalization. In the above technique, the is written as a product of the three network characteristics. The AutoRED with RED performs better than the RED scheme.
This model reduces the queue
oscillations appropriately in the RED based algorithms. The AutoRED uses the strength of both the burstiness and the transient congestion [53].
2.4.2.1.2 Load-based AQM a) AVQ [63], [64]: It updates the virtual queue when a packet arrives at the real queue to indicate the new arrival of a packet. As in the Pseudo-code of AVQ, as given below, it marks the dropped packets when the virtual queue or buffer overflows. The total flow entering each link achieves a desired utilization of the link modifying the virtual capacity of the link. This is done by aggressive marking when the link 68
utilization exceeds the desired utilization and by less aggressiveness when marking the link utilization is below the desired utilization. As a result, this provides early feedback rather than the RED [53]. The AVQ pseudo-code is At each packet the arrival epoch does VQ = max (VQ – Ĉ(t – s), 0)
/* update Virtual queue size
if VQ + b B
/* mark or drop a packet in the real queue
else VQ = VQ + b
/* update Virtual queue size
end if Ĉ = max (min (Ĉ + * * C * (t – s), C) – * b, 0) S=t
Constant: C
: capacity of a link
B
: buffer size
b
: number of bytes in current packet
: smoothing parameter
: desired utilization of the link
69
Other: Ĉ
: Virtual queue capacity
t
: current time
s
: arrival time of previous packet
VQ
: number of bytes currently in the virtual queue
b) Yellow [65]: In this scheme, the queue length periodically monitors its load on each link, and the gateways determine the available capacity of a load factor. Identifying the incipient congestion helps in advancing and calculating the packet marking probability. Yellow improves the robust performance with respect to boundtrip propagation delay by introducing the early queue controlling function.
So,
Yellow uses the load factor (link utilization) as a main merit to manage congestion. A secondary merit is introduced to improve the congestion control performance of a queue control function (QCF). Lyapunov theory is presented based on the sufficient condition for globally asymptotic stability. Furthermore, the bonded stable conditions are given based on the principle of parameter settings [53]. c) SAVQ [66]: The desired utilization parameter in the AVQ algorithm observes that it has an influence on the dynamics of queue and link utilization. It is difficult to achieve a fast system response and high link utilization while simultaneously using a constant value . The instantaneous queue size proposes an adaptive setting method for and the given reference queue value. Stabilized AVQ (SAVQ), as called by this new algorithm, stabilizes the dynamics of queue maintaining high link utilization [53]. 70
d) EAVQ [67]: It is a rate-based stable enhanced adaptive virtual queue. The arrival rate at the network link is maintained as a principal measure of congestion. A subordinate measure is used as the desired link utilization to solve the problems such as hardness of parameter setting, poor ability of anti-disturbance and a little low link capacity. The EVAQ proved the transit performance of the system and assured the entire utilization of link capacity. Based on linearization, the local stability conditions of the TCP EAVQ system were presented. The simulation results show the excellent performances of EAVQ such as the higher utilization, the lower link loss rate, the more stable queue length, and the faster system dynamic response than AVQ [53]. e) REM [68]: Random Exponential Marking (REM) achieves high utilization with negligible loss or queuing delay even if the load increases. Both the input rate around link capacity is stabilized by this scheme and the queue around a small target is independent of the number of users sharing the link. A congestion measure price is used to determine the marking probability. The rate mismatches updates based on the congestion measure price and gives low queue mismatch. When the number of users in the network increases, the queue mismatch and rate mismatch increase, thus increasing the price value. An increase in price value results in increased marking probability. This, in turn, reduces the source rate of the user input. When the source rates are too small, the mismatch is negative, decreasing the price and marking probability value that increases the source rate. The price adjustment rule tries to regulate user rates with network capacity and controls queue length around a target value. RED tries to couple the congestion measure and the performance measure, but REM decouples the congestion measure and the performance measure shows a better performance than the earlier scheme [53].
71
The congestion measure price pseudo-code is
Pl (k + 1) = [Pl (k) + (l (bl (k) – bl) + xl (k) – cl (k))]
Constants:
>0 l > 0 bl
: target queue length
bl (k) : aggregate buffer occupancy cl (k)
: available bandwidth
f) SVB [69]: To detect arrivals by the SVB scheme, the packet scheme, and the packet arrival rate and queue length information, congestion in an Internet gateway is used.
AVQ maintains a virtual queue and responds to the traffic
dynamically. The virtual queue considered reflects a new packet arrival in both the queue length and the arrival rate. The most striking feature of the proposed scheme is its robustness to workload fluctuations in maintaining a stable queue for different workload mixes (short and long flows) and parameter settings. The link capacity of the real queue fixes the service rate of the virtual queue and adapts the limit of the virtual buffer to the packet arrival rate. Both the current virtual buffer limit and the queue occupancy marks with a probability are calculated based on the incoming 72
packets. The simulation results have shown that it provides a lower loss rate, good stability and more throughput in dynamic workload than the other AQM schemes like RED, REM and AVQ [53].
2.4.2.1.3 Other Congestion Metrics a) BLUE [70]: Some of the problems of RED are resolved by the BLUE algorithm by employing two factors, which are packet loss from queue congestion and link utilization. So, BLUE performs queue management based on a packet loss and link utilization as given below. To mark or drop packets, BLUE maintains a single probability
.
If the buffer overflows, BLUE increases
to increase the
congestion notification and is decreased to reduce the congestion notification rate in case of buffer emptiness. To control the congestion by this scheme, link history is used. The parameters of BLUE are
and freeze time. The minimum time period
is determined by the freeze time between two consecutive updates of
. Minimum
packet loss rates are maintained by BLUE and marking probability over varying queue size and the number of connections compared to RED. In case of large queue, RED has a continuous packet loss, followed by lower load that leads to reduced link utilization. In BLUE, the queue length is stable, compared to RED, which has a large varying queue length. This ensures that the marking probability of BLUE converges to a value that results in a reduced packet loss and high link utilization [53]. The pseudo-code of the BLUE algorithm is given below. Upon packet loss (Qlen > L) event: if ( ( now – last_update) > freeze_time )
73
Pm = Pm +
1
last_update = now
Upon link idle event: if ( ( now – last_update) > freeze_time) Pm = Pm -
2
last_update = now Constant: freeze_time
: minimum time period between two consecutive updates of pm
It maintains a marking probability Pm to either mark or drop the packets. If the queue is continually dropping the packets, Pm is incremented by a factor queue is empty or the link is idle, Pm is decremented by factor must be set significantly larger than
2.
2.
1.
If the
The value of
1
This is because the link is underutilized when
the congestion management is either too aggressive or too conservative, but a packet loss occurs only when the congestion mechanism is too conservative. BLUE uses one more parameter freeze_time, which determines the time interval between two successive updates of freeze_time. It allows the changes in the marking probability to take effect before the value is updated again [70].
74
The marking probability, Pm is also updated when the queue length exceeds a certain value in order to allow room to be left for transient bursts and to control the queuing delay when the size of the buffer being used is large.
2.4.2.2 Congestion Metric with Information Flow AQM also belongs to this category using both congestion metric and the information flow to detect congestion in gateways. AQMs that use only congestion metric, but not information flow face the problem of unfairness in handling the different types of traffic. The congestion metric being considered can be further classified as queue-based or load-based and others [53].
2.4.2.2.1 Queue-based Metric a) FRED [71]: This is based on instantaneous queue occupancy of a given flow. The unfairness effects, which are found in RED, are eliminated in FRED. Selective feedback is generated by FRED to a filtered set of connections having a large number of packet queues rather than choosing connections randomly to drop packets proportionally. It provides better protection than RED for adaptive flows and in isolating non-adaptive greedy flows [53]. b) CHOKe [72]: CHOKe (CHOose and Keep for responsive flow, and CHOose and Kill for unresponsive flows) algorithm penalizes misbehaving flows by dropping more of their packets. So, CHOKe tries to bring fairness to the flows that pass through a congested gateway. The pseudo-code of CHOKe is given below, and calculates the average occupancy of the buffer as in RED using EWMA. If the 75
average queue is greater than
, comes the flow id of each arriving packet and
compare a randomly selected packet called drop candidate packet. If the packets are of the same flow, then drop both of the packets. Otherwise, if the average queue is greater than
, then drop the new packet elsewhere in the buffer and admit the
new packet with a probability
[53].
The pseudo-code of CHOKe algorithm is given by Calculating Qave If (Qave minth) { To admit new packet } Else { Draw a drop candidate packet randomized from buffer If flow id of the arriving packet and the drop candidate is the same Drop both packets Else If (Qave maxth) Admit the packet with probability p Else Drop the new packet } 76
c) SHRED [73]: Short-lived flow friendly RED (SHRED), an AQM mechanism improved response time for short lived Web traffic. It uses a from a TCP source to compute the
hint
ratio of an arriving packet to the
average and reduces the probability of dropping packets during the sensitive period when a flow‘s
is small. Sources mark each packet with its current window
size, allowing SHRED to drop packets from flows with TCP windows with a lower probability. Small TCP windows sizes can significantly affect short-lived flows. Small TCP windows result in a lower transmission rate and short-lived flows are more sensitive to packet drops. SHRED provides improvement in web response time and web traffic performance improvements are achieved without negatively impacting long-lived FRP traffic [53]. d) Stochastic RED [74]: To handle the tremendous growth of the unresponsive traffic Internet. Stochastic RED was introduced. Basically, Stochastic RED tunes the packet drop probability of RED for all of the flows by taking into consideration the bandwidth shares obtained by the flows. The dropping probability is adjusted. For example, the packets of the flow at a high transmission rate are more likely to be dropped than flows at a lower rate. This algorithm distinguishes individual flows without requiring per-flow state information at the gateways. It is called stochastic because it does not really distinguish the flows accurately. The arriving traffic is divided by the gateway into a limited number of counting bins using a hashing algorithm. On the arrival of each packet at the queue, a hash function is used to assign the packet to one of the bins based on the flow information. It dispatches the packets of the different flows to the set of bins. With a given hash function, packets of the same flow are mapped to the same bin. unresponsive, the bin load increases dramatically. 77
Therefore, when the flow is
Stochastic RED estimates the bin loads and uses these loads to penalize flows mapped to each bin according to the load of the associated bin. Thus, unresponsive flows experience a large drop probability.
The Stochastic RED is effective in
disciplining misbehaving flows, making unresponsive flows TCP friendly and improving the response time of web transfers without degrading the link utilization [53].
2.4.2.2.2 Load-based Metric a) SFED [75]: SFED is a rate control based AQM discipline which is coupled with any scheduling discipline.
It maintains a token bucket for every flow or
aggregate flows. The token-filling is rated in proportion to the permitted bandwidths. When a packet is en-queued, tokens are removed from the corresponding bucket. The decision to en-queue or de-queue a packet of any flow depends on the occupancy of its bucket at that time. A token bucket serves as a control on the bandwidth consumed by a flow. SFED ensures are early detection and a congestion notification of the adaptive source. The token bucket also keeps records of the bandwidth used by its corresponding flow in the recent past [53]. b) FABA [76]: The AQM scheme fair bandwidth allocation provides fairness amongst competing flows even in the presence of the non-adaptive flows. It is a rate control based AQM algorithm. It offers congestion avoidance by an early detection and a notification with low implementation complexity. It maintains a per active-flow state with scalable implementation.
It performs better than RED and CHOKe. In
case of buffer size constraints, it performs significantly better than FRED. It gives high values of fairness for diverse applications such as FTP, Telnet, and HTTP. 78
Performance is superior even for a large number of connections passing though the gateways. It is a scalable algorithm [53]. c) LUBA [77]: LUBA is link utilization-based AQM algorithm.
In this
algorithm, malicious flows are identified, which causes congestion at the gateway, and assigned them drop rates in proportion to their abuse of the network. A malicious flow continuously hogs more than its fair share of link bandwidth. So, LUBA assigns the drop probability to a malicious flow so that it does not get more than its fair shares of the network. LubaInterval. B. is the byte-count of total packets received by the congested gateway during an interval to measure whether a flow is hogging more than its fair shares. Overload-factor (U) is computed by B bytes arriving at the gateway. If the overload-factor U is below the target link utilization, the gateway is noncongested and packets are not marked or dropped; otherwise, all arriving packets are monitored while a flow id is assigned to each ingress flow at the gateway. A history table is maintained to monitor flows, which takes more than their fair shares of the bandwidth in a LubaInterval. It disciplines malicious flows in proportion to their excess inflow.
It offers high throughput and avoids global synchronization of
responsive flows.
LUBA works well in different network conditions and the
complexity of the algorithm does not increase even when there is a large number of non-responsive flows [53].
2.4.2.2.3 Other Metrics a) SFB [78]: It is a FIFO queuing algorithm that identifies and rate-limits nonresponsive flows based on accounting mechanisms. A track of queue occupancy statistics of packets is used to keep the accounting bins belonging to a particular bin. 79
A dropping probability
is kept by each bin which is updated based on bin
occupancy. As a packet arrives at the queue, one of the N bins in each of the levels hashes it. If the number of packets mapped to a bin goes above the certain threshold, it increases
for the bin. If the number of packets drops to zero, it decreases
.
SFB is highly scalable and enforces fairness using an extreme amount of states and a small amount of buffer space [53].
2.4.2.3 Information Flow Only The third category of AQMs uses only the information flow and does not identify the congestion metric to control the congestion. a) Stabilized RED [79]: SRED pre-emptively discards packets with a loaddependent probability when it congests a buffer in a gateway. It stabilizes its buffer occupancy at a level independent of the number of the active connections. SRED does this by estimating the number of active connections. It obtains the estimate without collecting or analyzing state information. Whenever a packet arrives at the buffer, the arriving packet with a randomly chosen packet that recently preceded it into the buffer is compared. The information about the arriving packets is augmented with a ―Zombie list‖. As packets arrive, as long as the list is not full, for every packet the packet flow identifier is added to the list. Once the zombie is full, whenever a packet arrives, it is compared with a randomly chosen zombie on the zombie list. If the arriving packet‘s flow matches the zombie, it is declared ‗hit‘. If the two are not of the same flow, it is declared ‗no hit‘. The drop probability depends on whether there was a hit or not. This identifies the number of active flows and finds candidates for misbehaving flows. The buffer occupancy is kept by SRED close to a specific 80
target and away from overflow or underflow.
The number of connections is
independent in SRED buffer occupancy while the number of connections is increased with RED buffer occupancy.
Misbehaving flows are used to identify the hit
mechanism without keeping per-flow state. The scalability problem is overcome by SRED but suffers from low throughput [53]. b) GREEN [80]:
Flow parameters and the knowledge of TCP end-host
behavior are used by this algorithm to intelligently mark packets to prevent a queue build up, and prevent congestion from occurring. High utilization and low packet losses are offered by GREEN. An improvement of this algorithm is that there are no parameters that need to be tuned to achieve optimal performance in a given scenario. In this algorithm, the congestion-notification probabilities are taken into consideration to calculate both the number of flows and the Round Trip Time of each flow. The marking probability in GREEN is generally different for each flow because characteristics that are flow specific depend on it [53].
Table 2-3 Comparison of AQM Schemes Based on Performance Metrics [53]
AQM RED ARED REM Yellow LRED AVQ BLUE FRED CHOKe StoRED SFB FABA GREEN
Link Utilization High High High Very High High Very High High High Moderate High High Very High Very Low
Throughput
Loss Rate
Low Moderate Very Low Low Moderate High Very High High Moderate High Moderate Very High Moderate
High Moderate Low Very Low Moderate Low Moderate Low Moderate Low Moderate Low High
81
Queue Stability Moderate High Very Low High High Moderate Low Moderate Moderate Moderate Moderate High High
Fairness Low Low Low Low Low Low Low High Moderate Very High Moderate Very High Low
Complexity, Computation High High High High High High Moderate Very High Moderate High High Very High Very High
CHAPTER 3 BROADBAND HYBRID SATELLITE CONSTELLATION COMMUNICATION SYSTEM
This chapter describes extensions that enable the simulation of satellite networks in NS-2. constellations.
In particular, these extensions enable polar orbiting of LEO
In this work, the author considers a broadband hybrid satellite
constellation communication over LEO similar to COMMStellationTM to evaluate the algorithm performance. The detailed design of the simulator and parameter settings are described in the following subsections, which is proposed with respect to the structure of a broadband hybrid satellite constellation communication system (BHSCCS).
3.1 Satellite Constellation Visualization As stated by Wood, ―SaVi, the Satellite Visualization tool, is a computer program for visualizing and animating the movement of satellites and their coverage. SaVi exists as a standalone program that can also be run as a module that interfaces with and controls the Geomview program. Geomview is a general purpose rendering program useful to mathematicians; SaVi leverages Geomview for simple threedimensional rendering and OpenGL texture mapping, while ignoring Geomview‘s ability to render higher dimensions of interest to mathematicians. SaVi is implemented as a satellite orbit simulator, written in ANSI C, which is driven by commands added to the higher level Tool Command Language (Tcl). This 82
two-pronged approach allows SaVi to be scriptable.
Simple, short, Tcl scripts
generating satellite constellations and driving the underlying simulator are written in a similar manner to the scripts of the network simulator (NS-2), which also relies on Tcl.
Many scripts, simulating, illustrating and animating proposed and existing
satellite constellations are included with SaVi. SaVi‘s user interface is presented in Tcl‘s Toolkit, Tk, which complements Tcl and allows for a relatively straightforward creation of a graphical dialog and window driven system as shown in Figure 3-1. See and animate a complex satellite constellation of COMMStellationTM system to run the associated script in Figure 3-5. As SaVi relies only on Tcl/Tk and standard Unix POSIX libraries with continued maintenance it remains portable across a wide range of Unix-compatible systems, including Linux, FreeBSD, and Debian package for Ubuntu. SaVi shows satellite coverage areas on a number of different map projections. A fisheye view of the sky is also available to examine how satellites pass over different points on the Earth. SaVi shows satellite coverage as either a minimum elevation angle or as half-angle beam width, and indicates how that coverage moves over time. Graphical output can be recorded and saved. Satellite and constellation properties can be edited‖ [80], [82], [1].
83
Figure 3-1 SaVi User Interface Program
3.2 Network Simulator As stated by Chung and Claypool, ―Network Simulator (NS) is an event driven network simulator developed at UC Berkeley that simulated a variety of IP networks. It implements network protocols such as TCP and UDP, traffic source behavior such as FTP, Telnet, Web, CBR and VBR, router queue management mechanism such as DropTail, RED and CBQ, and routing algorithms such as Dijkstra, and more. NS also implements multicasting and some of the MAC layer protocols for LAN simulations. The NS project is now a part of the VINT project that develops tools for simulation result displays, analyses and converters that convert network topologies generated by well-known generators to NS formats. Currently, NS (version 2) written in C++ and OTcl (Tcl script language with Object-oriented 84
extensions developed at MIT) is available. The author summarizes the basic structure and network components of NS-2. As shown in Figure 3-2, in a simplified user‘s view, NS-2 is an object-oriented Tcl (OTcl) script interpreter that has a simulation event scheduler and network component object libraries, and network setup module libraries. In other words, are use NS-2, with the program in OTcl script language. To setup and run a simulation network, a user should write an OTcl script that initiates an event scheduler, sets up the network topology using the network objects and the plumbing functions in the library, and tells traffic sources when to start and stop transmitting packets through the event scheduler. The term plumbing is used for a network setup, because setting up a network is plumbing possible data paths among network objects by setting the neighbor pointer of an object to the address of an appropriate object. When users want to make a new network object, they can easily make an object either by writing a new object or by making a compound object from the object library, and plumb the data path through the object.
Figure 3-2 Simplifed User‘s View of NS-2 [83]
85
Another major component of NS-2 besides network objects is an event scheduler. An event in NS-2 is a packet ID that is unique for a packet with scheduled time and the pointer to an object that handles the event. In NS-2, an event scheduler keeps track of simulation time and fires all the events in the event queue scheduled for the current time by invoking appropriate network components, which usually are the ones who issued the events, and let them do the appropriate action associated with the packet pointed by the event. Network components communicate with one another passing packets; however, this does not consume actual simulation time. All the network components that need to spend some simulation time handling a packet (i.e. need a delay) use the event scheduler by issuing an event for the packet and waiting for the event to be fired to itself before doing further action in handling the packet. For example, a network switch component that simulates a switch with 20 microseconds of switching delay issues an event for a packet to be switched to the scheduler as an event 20 microsecond later. The scheduler after 20 microsecond dequeues the event and fires it to the switch component, which then passes the packet to an appropriate output link component. Another use of an event scheduler is a timer. For example, TCP needs a timer to keep track of a packet transmission time out for retransmission (transmission of a packet with the same TCP packet number but with a different NS packet ID). Timers use event schedulers in a similar manner that a delay does.
The only differences is that a timer measures a time value
associated with a packet and does an appropriate action related to that packet after a certain time goes by, and does not simulate a delay. NS-2 is written not only in OTcl but in C++ also. For efficiency reason, NS-2 separates the data path implementation from control path implementation. In order to reduce packet and event processing time (not simulation time), an event scheduler and 86
the basic network component objects in the data path are written and compiled using C++. These compiled objects are made available to an OTcl interpreter through an OTcl linkage that creates a matching OTcl object for each of the C++ objects and makes the control functions and the configurable variable specified by the C++ object act as member functions and member variables of the corresponding OTcl object. In this way, the controls of the C++ objects are given to OTcl. It is also possible to add member functions and variables to a C++ linked OTcl object. The objects in C++ that do not need to be controlled in a simulation or internally used by another object do not need to be linked to OTcl. Likewise, an object (not in the data path) can be entirely implemented in OTcl. Figure 3-3 shows an object hierarchy example in C++ and OTcl. One thing to note in the figure is that for C++ objects that have an OTcl linkage forming a hierarchy, there is a matching OTcl object hierarchy very similar to that of C++.
Figure 3-3 C++ and OTcl: The Duality [3], [84]
87
Figure 3-4 shows the general architecture of NS-2. In this figure a general user (not an NS developer) can be thought of standing at the left bottom corner, designing and running simulations in Tcl using the simulator objects in the OTcl library. The event schedulers and most of the networks components are implemented in C++ and available to OTcl through an OTcl linkage that is implemented using Tcl. This section briefly examines the general structure and architecture of NS-2. At this point, one might be wondering how to obtain NS-2 simulation results. As shown in Figure 3-2, when a simulation is finished, NS-2 produces one or more textbased output files that contain detailed simulation data, if specified to do so in the input Tcl (or more specifically, OTcl) script. The data can be used for a simulation analysis or as an input to a graphical simulation display tool called NAM‖ [83], [3], [84].
Figure 3-4 Architectural View of NS-2 [3], [84]
88
3.3 Simulation Model and Parameters of Hybrid Satellite Communications As stated by Wells et al., ―Microsat Systems Canada Inc. (MSCI) is attempting to provide firmly global coverage communications to the public. The global backhaul issues are relieved via development in satellite communication constellations; also it connects rural and remote areas of the world where fiber infrastructure is cost prohibitive. The initiative of the COMMStellationTM is to supply, produce, deploy and perform the COMMStellationTM constellations of satellites designed to prepare business communications on a high speed level to global customers. The Internet backhaul for areas of the world further the reach of the fiber optic network will be providing the initial market applications as planned. customers
consist
COMMStellationTM
of
existing
satellite
networks
will
provide
of
In this application, typical
private
customers.
high-speed,
high
Each bandwidth
communications. Some potential uses of the COMMStellationTM communications bandwidth include a) Video conferencing and other corporate communications; b) Strategic communications for government, military, or corporations; c) Distance learning and telemedicine; d) Remote environmental monitoring; e) Distribution of cable television; f) Arctic communication; g) Special purpose low latency communications; h) High bandwidth burst data transmissions from remote sensors, ships, or exploration vessels or sites; and i) Other special purpose communications‖ [85]. Next, the author study a static dimensioning case for a general nongeosynchronous Earth orbit satellite network and show the feasible topology regions as well as effective cost comparisons for different various transport control protocols.
89
Before the computer simulations, the author makes a simple estimation. As it is known, a COMMStellationTM system consists of a constellation of communication satellites in a low Earth orbit. The author has extended the VINT network simulator (ns-2.34) [84].
A LEO satellite network with 72 satellites is considered in the
simulations. There are 6 orbital planes with 12 satellites in each plane. The planes have a near-circular orbit, with co-rotating planes spaced 30 apart. The satellite orbits are 1,000 km in altitude with an orbit inclination angle of 90. The minimum elevation angle of the ground stations is 10, which maximizes the coverage area of the satellites and improves the link quality compared to lower elevation angles. Lower elevations increase fading due to multi-path propagation and have a negative impact on link quality.
The orbital parameters are shown in Table 2-1.
The
COMMStellationTM model is used in the simulation. Figure 3-5 is plotted using the Savi [82] program. The satellites will essentially travel, co-rotating, up one side of the Earth, cross over at the pole and come down the other side of the Earth. There is an area between the first and the last planes where the satellites are counter-rotating, which is called a counter-rotating ―seam‖.
The satellites in the six orbits will
converge as they approach the poles, and their beams will overlap. Some of the outer beams will be turned off to eliminate the overlap and to converse power. The orbital parameters of every satellite in the COMMStellationTM system at a time point are obtained via NS-2.
90
Figure 3-5 Global Coverage from the COMMStellationTM Model [86]
3.4 Proposed COMMStellationTM Satellite System in NS-2 The simulation tool which has been used in this research work is based on the Network Simulator (NS) version 2.34 [3]. NS-2 is an open source software, which is available for the public and can be obtained from the Information Sciences Institute (ISI). The NS-2 network simulator is implemented in C++, OTcl, and Tcl. C++ objects mainly serve for data processing, while the OTcl plane has control functionality and binds all C++ objects into a common structure. Simulation scripts are specified in Tcl [87]. The ground side of the link has two types of stations: i) Trunk station that is connected to the high-speed Internet backbone, and ii) User Stations. A given User Station is planned to be a current or new Internet Service Provider (ISP), allowing individual clients to connect to its satellite link [85]. 91
Figure 3-6 illustrates the
network topology which has been used in this work. All the links between Trunk stations were set up as STM-4 transmission duplex into Internet backbone and STM-1 transmission duplex for Internet backbone communication links, arranged with 1 and 5 millisecond propagation delays using DropTail queuing system, which serves packets on a First-Come First-Serve (FCFS) basis [86]. In the conducted computer simulations, four user station links in different areas around South East Asia are chosen to observe the assignments to global traffic. The source nodes are located in Bangkok-Thailand, Yangon-Myanmar, VientianeLaos, and Oil platform-the Indian Ocean. The destination nodes are at BostonMassachusetts, Tallahassee-Florida, Saint Paul-Minnesota, and Lincoln-Nebraska [86].
Figure 3-6 Hybrid Satellite Constellation Layout
92
3.4.1 Visualization of NS Hybrid Satellite Constellation Configurations In this work, the author considers a polar LEO constellation similar to the COMMStellationTM satellite system. The author snapshot of satellite positions at a given time to roll-out a feasible COMMStellationTM system in NS-2. Figure 3-7 illustrates the satellite constellation surrounding the Earth [85]. 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. The latitudes, longitudes, and planes of the COMMStellationTM satellite system are shown in Table 3-1.
Figure 3-7 Satellite Constellation Layout [86]
After that, the author supposes that the trunk stations are given assignments on the mainland to optimize connections between satellite links. Figure 3-8 illustrates that ground stations as each satellite must be communicating with a dedicated trunk 93
station for operations at all times. The optimal location [85] of non-existing trunk ground stations has been established through the simulation to provide an optimal overlap, i.e. full coverage with a minimum number of satellites to optimize the cost. The simulations include existing ground assets to maximize the use of those assets. It is assumed that all ground station contacts are made at a minimum elevation of 10 degrees. In Table 3-2, the author has assumed the longitude and latitude for each trunk station to be realistic enough in correspond to the actual satellite constellation [86].
Figure 3-8 Trunk Stations Layout [86]
94
Table 3-1 Snapshot of the Proposed COMMStellationTM Satellite Constellation at a Single Time Point Satellite Longitude Latitude Plane No. () ()
Satellite Longitude Latitude Plane No. () ()
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71
0.06 30.06 60.06 89.94 59.94 29.94 -0.06 -30.06 -60.06 -89.94 -59.94 -29.94 15.06 45.06 75.06 74.94 44.94 14.94 -15.06 -45.06 -75.06 -74.94 -44.94 -14.94 0.06 30.06 60.06 89.94 59.94 29.94 -0.06 -30.06 -60.06 -89.94 -59.94 -29.94
0.00 0.00 0.00 180.00 180.00 180.00 180.00 180.00 180.00 0.00 0.00 0.00 30.00 30.00 30.00 -150.00 -150.00 -150.00 -150.00 -150.00 -150.00 30.00 30.00 30.00 60.00 60.00 60.00 -120.00 -120.00 -120.00 -120.00 -120.00 -120.00 60.00 60.00 60.00
1 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 95
15.06 45.06 75.06 74.94 44.94 14.94 -15.06 -45.06 -75.06 -74.94 -44.94 -14.94 0.06 30.06 60.06 89.94 59.94 29.94 -0.06 -30.06 -60.06 -89.94 -59.94 -29.94 15.06 45.06 75.06 74.94 44.94 14.94 -15.06 -45.06 -75.06 -74.94 -44.94 -14.94
90.00 90.00 90.00 -90.00 -90.00 -90.00 -90.00 -90.00 -90.00 90.00 90.00 90.00 120.00 120.00 120.00 -60.00 -60.00 -60.00 -60.00 -60.00 -60.00 120.00 120.00 120.00 150.00 150.00 150.00 -30.00 -30.00 -30.00 -30.00 -30.00 -30.00 150.00 150.00 150.00
4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 6
Figure 3-9 illustrates the Internet backbone topology which has been used in this section. The author supposes that each continent has fiber links to connect each other and there are low latency delays between them. The author chooses STM-1 to be the SDH ITU-T fiber optic network transmission standard. It has a bit rate of 155.52 Mbps. Due to the complexity of the system parameters and the simplistic analysis, the author also assumes that it is dividing the Earth zones. Figure 3-10 illustrates the network topology of the Internet backbone. It is a full-mesh topology, which established connections from each node to every other node. It makes the system become stable and credible, with each link connected via fiber optic cable by applying the standard of STM-1 as mentioned above [86].
Figure 3-9 Internet Backbone Layout [86]
96
Table 3-2 Snapshot of the Proposed COMMStellationTM Trunk Stations Trunk station No.
Longitude ()
Latitude ()
1 2 3 4 5 6 7 8
70.00 70.00 60.00 60.00 70.00 30.00 30.00 45.00
-160.00 -140.00 -130.00 -110.00 -100.00 -110.00 -100.00 -80.00
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
65.00 -10.00 -30.00 -25.00 -10.00 15.00 15.00 50.00 50.00 10.00 -10.00 55.00 65.00 10.00 35.00 60.00 70.00 40.00 20.00 45.00 50.00 10.00 30.00 60.00 70.00 -25.00 -35.00
-70.00 -80.00 -70.00 -50.00 -40.00 -20.00 -10.00 10.00 20.00 10.00 20.00 35.00 50.00 40.00 50.00 70.00 85.00 70.00 80.00 95.00 110.00 100.00 110.00 130.00 140.00 130.00 140.00
97
Figure 3-10 Internet Backbone Topology
In this section, new and efficient satellite constellation system mechanisms are proposed to address challenges in LEO orbits and present a feasible network topology in NS-2.
Although more realistic scenarios could have been selected in the
simulations, the potential of the proposed model should remain the same.
The
propagation delays between satellites and ground stations and the high altitude of the constellation can be considered the most important cost factors in the satellite network which is further investigated in Chapter 4.
98
CHAPTER 4 OPTIMIZED ROUTING PROTOCOL
This chapter describes a selection of factors that greatly influence the cost of the broadband hybrid satellite networks over LEO systems. The author implements a routing technique that has been proposed in the previous chapter. In this work, the author considers five metrics for characterizing routes in hybrid networks.
4.1 Background of Routing Protocols over Satellites A broadband satellite on a low Earth orbit (LEO) satellite network system provides connectivity to cover global users far beyond time and space limitations. To respond to global customers, the broadband data satellite networks comprise an integration of terrestrial network, satellite network topology, link capacity, and routing which have major impacts on the cost of a network [88], [89]. A satellite network is able not only to provide high bandwidth with global coverage but also to support flexible network configuration expansion [90]. The network combines dynamic interconnected backbones of a transport network in order to exchange transmitted information. In the telecommunication industry, a triple-play encompasses the provisioning of three services: (1) Voice over Internet Protocol (VoIP) through the use of a broadband connection, (2) Video on Demand (VoD) to broadcast television, and (3) high-speed Internet with high-performance data transfers.
The triple-play service architectures are based on the most popular
99
technology of each standard codec to evaluate the performance over broadband hybrid satellite networks [88]. Hybrid networks have both wireless and wired components. A wide variety of networks can be treated according to this framework, including multi-satellite constellation networks with optical fiber crosslinks [88], [91]. The interconnection to the global communication grid requires the installation of a backhaul cable, and fiber optics. Most infrastructure-based hybrid networks require significant efforts, time, and capital to build and deploy. However, the tremendous adoption of some of these networks is a great testament to their usefulness and commercial viability. There are numerous other communication demands to serve such as temporary events, battlefield communications, remote sensing, and robotic networks [88], [92]. A LEO satellite constellation consists of a set of satellites orbiting the Earth at a high constant speed at a relatively low altitude, using orbits much lower than the geostationary orbit, in order to give global coverage, more frequency reuse, and higher system capacity as a result of this frequency reuse. With the LEO satellite system, each satellite is equipped with a fixed number of antennas that allow it to communicate with terrestrial networks and with other satellites. Routing algorithms are needed to determine the best way to traverse the mesh; a flexible packet-based, rather than static circuit-based, routing approach can take advantage of the redundancy inherent in this mesh [28], [88], [93]. The most straightforward hybrid architecture envisaged is based upon a highspeed forward link using a lower broadcast satellite, whereas the return link takes benefit of the already existing, high bandwidth network architectures such as the synchronous transport module connections. This also enables the seamless migration 100
of broadband satellite constellation systems providing triple-play services into hybrid systems. Such hybrid systems already exist. One can quote, for instance, that the AstraNet system providing IP telecommunication services uses an ASTRA satellite in the forward link and a terrestrial telephone line in the return link. Satellite/terrestrial LTE networks are integrated for IP service delivery, for instance, in the SkyTerra/LightSquared with an LTE/satellite network system [88], [94].
4.2 System Model of Hybrid Satellite Constellation Architecture The COMMStellationTM satellite network [17], [85] occupies orbits with at altitudes around 1,000 km. It consists of 72 satellites which are arranged in 6 orbital planes with 2 additional redundant satellites in every orbit. The planes have a nearcircular orbit, with co-rotating planes spaced 30 degrees apart.
The minimum
elevation angle for an Earth station is 10 degrees, which maximizes the coverage area of the satellite and improves the link quality when compared with lower elevation angles. Lower elevations increase the multipath fading and have a negative impact on link quality.
An average satellite in-view time is approximately 10-12 minutes,
depending on the latitude of the ground stations. The capacity of a satellite node is 8.8 Gigabit/s and the satellite link bandwidth is 1.1 Gigabit/s (both uplink and downlink). The ground side of the link has two types of stations: i) Trunk Station that is connected to the high-speed Internet backbone (it has 35 trunk stations); and ii) User Station that is planned to be a current or new Internet Service Provider (ISP), which allows individual clients to connect to its satellite link. The Internet backbones of trunk stations include a setup link such as STM-4 transmission duplex and STM-1 transmission duplex for the communication link between Internet backbones. 101
The network topology scenario is shown in Figure 4-1. The network topology components are considered here as a part of hybrid satellite network, which consists of four user stations for sources and destinations.
There are triple-play service
applications for all pairs. The source nodes are in different areas around South East Asia such as Bangkok-Thailand, Yangon-Myanmar, Vientiane-Laos, and Oil platform-the Indian Ocean. The destination nodes are in North America such as Boston-Massachusetts, Tallahassee-Florida, Saint Paul-Minnesota, and LincolnNebraska [86]. The error model used two loss links among both the wired and wireless network links to be the worst-condition scenario [95], [1]. The plots were generated by outputting satellite position information as shown in Figure 4-2, which illustrates the snapshots of satellite positions, trunk station positions, and user station positions for the COMMStellationTM satellite system [86], [88] with NS-2 satellite plot scripts [88], [96].
Table 2-1 summarizes key properties of the present
COMMStellationTM satellite system used throughout the simulations. The Internet backbone traffic density model is similar to the model considered in [12].
Figure 4-1 Proposed Triple-play Services for Hybrid Satellite Network Topology 102
Figure 4-2 Snapshots of COMMStellationTM over LEO Satellite Constellation, Trunk Stations, and User Stations [88]
For simplicity, all satellite nodes are assumed to be identical in terms of eight metrics. The traffic load is converged voice, video, and data services over a common IP network, known as triple-play services. Satellite delivery can be an enabling technology for deploying this broadband service, particularly to coverage the globe. In supporting ‗triple-play‘, the satellite system needs to be integrated with the Internet to provide appropriate performance across a range of applications that require high capacity, maximum jitter, maximum delay, etc. This is a challenge that requires careful consideration of the QoS in the satellite system and coordination with an IPbased network and transport protocols that control sharing of capacity along the endto-end (E2E) Internet paths. The application traffic load in the simulations is voice telephony using G.711 codec, video streaming using H.264 part 10 codec, and large file transfer using FTP. To evaluate the routing metrics, the path metrics (i.e., link length, link delay, link loss, etc.) of a connection between a pair of source node and a destination node 103
are monitored. The source is located at coordinates (13.75, 100.63) in Assumption University of Thailand, and the destination is at coordinates (42.3, -71.1) in Boston, United States of America.
4.3 Triple-play Service Methodology This part describes the extensions of the transport layer protocol. Nowadays, the use of the Internet becomes more complex. Every year, the global satellite network becomes bigger and there are also many services, offered on the Internet, which become more challenging.
There has been an exponential growth in
multimedia applications within the Internet as a whole, with an increasing desire to combine voice, video and data services over a common IP network, known as ‗tripleplay bundling‘. This is seen by many operators as a potential ‗killer application‘. Satellite delivery can be an enabling technology for deploying this broadband service, particularly to small rural communities or peripheral regions, where it provides an alternative to wired connections. In supporting ‗triple-play‘, satellite systems need to be integrated with the Internet to provide appropriate performance across a range of applications (in term of required capacity, maximum jitter, maximum delay, etc.). This task is a challenge that requires careful consideration of the routing metrics and QoS functions in the satellites connected to an IP-based network using a transport layer protocol that controls the sharing of capacity along the end-to-end Internet paths [97], [98].
104
4.3.1 VoIP over IPv6 As stated by Ali, Liang, Sun and Cruickshank, ―Voice over IP, being a realtime application, is intolerant to long delays.
Originally, H.323 was the key
architecture that provided signaling service for VoIP and replaced the initial proprietary solutions. Meanwhile, other VoIP signaling protocols, Media Gateway Control Protocol (MGCP), H.248 or Megaco and Session Initiation Protocol (SIP) were developed.
After its standardization, SIP has become very popular in IP
telephony. SIP can interoperate with other signaling protocols, like MGCP and also interoperate with PSTN. It is dominating the signaling the protocols in both terrestrial and wireless networks and is also deployed in the integration of terrestrial and wireless networks. The Session Initiation Protocol (SIP) is a signaling protocol. It is used in call setup, tear down and management of session parameters. Its architecture consists of User Agents (UA), registrar, location, proxy, and redirect servers. A user agent supports telephony as an application. A registrar server offers registration services and it updates its database as a new user arrives. A location server keeps track of the location of the users. It is updated by the registrar server on a new registration. A proxy server forwards the requests and responses from the user agents. A redirect server forwards the requests to possible proxy servers or user agents if the requested URI is not in its database. Most often the registrar, proxy and redirect servers are available in one software package. SIP signaling comprises exchange of request and response messages among the user agents through one or more SIP servers. The request messages are known as methods. There are six methods: INVITE, REGISTER, BYE, ACK, CANCEL, and
105
OPTIONS. The response messages are 100 Trying, 180 Ringing, 200 OK and many others. The sequence of messages to set up a call is INVITE - 200 OK – ACK. The voice data are carried by the Real-Time Protocol (RTP) and they are exchanged between the caller and callee directly.
In the same way, BYE – 200 OK are
exchanged to tear down a session. The User Datagram Protocol (UDP) is an unreliable and connectionless protocol. The connection establishment time does not affect SIP signaling as the protocol is connectionless. In applications that use UDP at the transport layer, the application layer is responsible for detecting and recovering from, a packet loss. The flow of messages during call setup over UDP is as shown in Figure 4-3.
A
retransmission policy is defined by SIP to guarantee the delivery of SIP messages. Several two-way handshakes are involved by SIP transactions: INVITE – 100 Trying, 200 OK – ACK, and BYE – ACK. There are two types of retransmission – one is for INVITE transactions and the other is for non-INVITE transactions. An INVITE message from the client is started with the INVITE transaction. 100 Tryings in response are handled by the server. The retransmission is managed by the client of the INVITE with a timer. T1 is started by this timer, doubling after every retransmission. The retransmission of INVITE messages from a client transaction, is stopped after receving 100 Trying responses or after a time period of 64*T1 seconds, since the first INVITE transmission. The timer T1 has a default value of 500 ms; therefore, intervals of 0.5, 1, 2, 4, 8, and 16 seconds occur during the retransmission of an INVITE message. If a client does not respond after 32 seconds, a server stops the retransmission.
106
The retransmission for the non-INVITE transaction is basically the same. A new timer T2 is introduced. The retransmission of 200 OK or BYE starts at T1. After every retransmission, the time is doubled, until it reaches T2.
The
retransmission of 200 OK and BYE occurs at intervals of 0.5, 1, 2, 4, 4, 4, … seconds, as T2 has a default value of 4 seconds. The retransmission stops after 32 (64*T1) seconds. SIP has a modular design, and hence, is independent of the transport layer. Therefore, it can use either the unreliable User Datagram Protocol (UDP), the reliable Transmission Control Protocol (TCP) or the recently emerged Stream Control Transmission Protocol (SCTP).
In this research, the author has discussed SIP
signaling over UDP and other QoS parameters of VoIP over an IPv6 satellite environment ‖ [8], [24]. The amount of bandwidth required to carry a VoIP network is dependent upon a number of factors. Among the most important are: -
Codec (coder / decoder) and sample period;
-
IP header;
-
Transmission medium; and
-
Silence suppression.
The codec determines the actual amount of bandwidth that the voice data will occupy. It also determines the rate at which the voice is sampled. The IP / UDP / RTP header can generally be thought of as a fixed overhead of 40 octets per packet, though on point-to-point links RTP header compression can reduce this to 2 to 4 octets (RFC 2508).
107
In the following paragraphs, the author will discuss the principle components of the VoIP system, which covers the end-to-end transmission of voice. As stated by Hoene, Karl and Wolisz, ―Digitized human speech is encoded. Encoding algorithms compress the audio signal. Most speech encoding schemes compress segments of speech and generate frames. The common, standardized encoding algorithms (G.711, G.723.1, G.726, G.729, GSM, AMR, and AMR-WB) differ in their coding rate (bits/s), frame rate (frames/s), algorithmic latency (ms), complexity and speech quality (MOS). An important optimization opportunity for speech codecs is the fact that human speech consists of periods of voice activities and silence. Some coding schemes lower the packet rate during silence to send only background noise descriptions (SID). This operating mode is called discontinuous transmission (DTX). One or multiple speech frames are concatenated in one packet. That packet in the VoIP payload is typically encapsulated into RTP, UDP, and IP packet headers are added to the speech segments before the packets are sent to the receiver‖ [99]. The IP / UDP / RTP header can generally be thought of as a fixed overhead of 40 bytes per packets, though on point-to-point links. The VoIP application is used between the UDP‘s two communicating network elements in the research. At both sides, the VoIP encoder uses G.711 codec for encoding. G.711 is the international standard for encoding telephone audio on a 64 kbps channel [100]. It is a pulse code modulation (PCM) scheme, operating at an 8 kHz sample rate. Here is the VoIP CODEC of G.711 to be run in this research work. Coding speed is 64 Kbps. Frame size is 20 ms. Processing delay is 20 ms. DSP MIPS is 0.34. IPv6 is 40 bytes. UDP is 8 bytes. RTP is 12 bytes. Payload is 160 bytes. The
108
number of flows is 7. The subscribing rate packet time is 20 ms, which affects the quality of voice.
Figure 4-3 SIP over UDP
4.3.2 IPTV over IPv6 The Internet becomes a part of the daily life. Multimedia services over the Internet such as the IPTV service are getting more popular. The multimedia services belong to one type of real-time service, which processes and receives data on the fly, strictly requiring digital data arrival in time.
If a network is congested, the
multimedia delivery may suffer from quality of service (QoS) problems, such as the end-to-end delay, packet jitter, and packet loss [101]. As stated by Scientific-Atlanta, ―The advent of H.264 (MPEG-4 part 10) video encoding standard has been met with great enthusiasm in the video industry. H.264 has video quality similar to that of MPEG-2, but is more economical with its use of 109
bandwidth.
Being less expensive to distribute, H.264 is a natural choice for
broadcasters who are trying to find cost- effective ways of distributing High Definition Television (HDTV) channels and reducing the cost of carrying conventional Standard Definition channels. In fact, the use of bandwidth has been reduced to the point that it has captured the interest of telephone and data service providers, whose bandwidth has limited links to the subscribers and had previously not allowed for delivery of bandwidth thirsty IPTV services. H.264 has the potential to revolutionize the industry as it eases the bandwidth burden of service delivery and opens the service provider market to new players‖ [102], [103].
As stated by
Sotiropoulos, Styliaras, Kosmatos, Papagianni, Tselikas and Venieris, ―The H.264 or MPEG-4 part 10, also named Advanced Video Coding (AVC), is a digital video codec standard, noted for achieving very high data compression, jointly developed by ITU Video Coding Experts Group (VCEG) and ISO Moving Picture Experts Group (MPEG). The H.264 is divided into distinct layers: a Video Coding Layer (VCL) and a Network Abstraction Layer (NAL).
In short, the VCL generates an efficient
representation of the video data, providing header information in a manner appropriate for conveyance by particular transport layer (such as the Real-Time Protocol). On the other hand, NAL deals with the appropriate packaging of the coded data, based on the underlying network characteristics. H.264 is used in fixed and wireless network environments. H.264 has proven to be more resilient to error prone networks through the use of flexible macroblock ordering, slice interleaving and data partitioning. Moreover, in order to prevent error propagation through inter prediction, H.264 provides mechanisms, such as redundant slice and spare macroblocks, which carry duplicate information to be used when an error in transmission occurs. H.264 is relatively simple in its implementation. In addition, it attains enhanced compression
110
performance, and therefore is a ―network-friendly‖ standard.
It is capable of
providing good video quality at substantially lower bit rates than other standards. H.264 part 10, also named Advanced Video Coding (AVC), is a digital video codec standard, noted for achieving very high data compression. It is used in wired and wireless network environments. It has proven to be more resilient to error prone networks through the use of flexible macroblock ordering, slice interleaving and data partitioning. Moreover, in order to prevent error propagation through inter prediction, H.264 provides mechanisms, such as redundant slice and spare macroblocks that carry duplicate information to be used when an error in transmission occurs. It is relatively simple in its implementation.
In addition, it attains enhanced compression
performance and therefore is a ―network-friendly‖ standard. It is capable of providing good video quality at substantially lower bit rates than other standards‖ [100]. The UDP is a connectionless protocol. It is suitable for unreliable connection such video streaming.
The connection establishment time does not affect IPTV
signaling as the protocol is connectionless, which application use UDP at the transport layer. The flow of messages during video setup over UDP is as shown in Figure 4-4. The Internet Protocol Television (IPTV) streaming uses H.264 part 10 video codec and the used streaming bit rate is usually IPTV = 1 Mbps for Standard Definition (SD) with 640x480, 24 fps and IPTV = 8.6 - 10 Mbps for High Definition (HD) with resolution and frame rate 1920x1080, 24fps [104], [105], [106].
In
addition, the overheads of various protocol layers are: RTP header size 12 bytes, UDP header size 8 bytes, IPv6 header size 40 bytes, and MAC + PHY header size 14 bytes [100]. For IPTV, the author uses the H.264 Part 10 Advanced Video Coding standard with its scalable video coding extensions. The bandwidth required depends on the 111
resolution, quality and frame rate. The author has selected maximum payload bit rate; this is, the bit rate that the network simulator endpoint will be used for resolution at a maximum frame rate supported for this resolution. This value is interesting because it allows the highest quality and frame rate video. The resolution and aspect ratio is 1920×1080 (16:9), and its maximum video payload bit rate is 4000 kbps.
Figure 4-4 IPTV over UDP
112
4.3.3 FTP over IPv6 As stated by Narravula, Lai, Subramoni, Mamidala and Panda, ―The File Transfer Protocol (FTP) was initially proposed to promote file sharing and the implicit use of remote computers. It is an application level protocol used to copy files between the local machine (user) and the remote machine (server) over the network, and fundamentally relies on the TCP/IP protocol. The typical FTP model includes control connection and data connection between the user and the server FTP processes for communicating the control commands and the data (file), respectively. The FTP server plays a passive role of listening on the specific port when started, and the user initiates a connection which may involve negotiation of authentication and certification with the server. After that, control commands can be transferred over the connection. The data connections are established as needed for the data transfers‖ [107], [108]. The TCP is a reliable and connection-oriented protocol service.
The
connection establishing an end-to-end connection before any data sent to the destination because it is guaranteed that data will arrive in the proper sequence. The flow of messages during a FTP over TCP is as shown in Figure 4-5. The FTP application used in this research is for the Internet large file transfer with TCP Westwood as the underlying transport protocol. The data segment size used is 512 bytes (i.e. 512 bytes payload + 40 bytes header + 20 bytes IPv6 header). An FTP server and a client were also added to create background traffic and to utilize the free capacity of the network. The maximum bit rate of the FTP servers was regulated in the scenarios to see how the amount of background traffic influences the QoS services.
113
Figure 4-5 FTP over TCP
4.4 Proposed Routing The optimized routing path is one solution to a routing technique in hybrid satellite constellation networks; it is the most important challenge to the implementation of hybrid satellite model in the previous chapter. The Optimized Routing Protocol for Hybrid Satellite Network (ORPHSN) [88] algorithm is proposed in this chapter.
Then, it will be considered as a multi-constrained optimization
problem (MCOP) problem, which has one constraint and more than one metric to be optimized. For the problem defined, an approximation algorithm is proposed to solve it. Instead of using a fixed approximation method as other proposed techniques, it uses a dynamic approximation method according to the specific characteristics of hybrid satellites over low Earth orbit networks. The exact approximation parameter range is defined to reduce the computational complexity, as shown in Table 4-1. 114
Table 4-1 Comparison of Routing Metrics Prob. delay
Lifetime
DCLT‘s Zongyang [2]
/
/
SRED‘s Qijie [109]
/
TCR‘s Jiang [110]
/
BDSR‘s Deng-yin [90]
/
FV‘s Derya [111]
/
Cruz-Sanchez [112]
/
Proposed Algorithm
/
Technique / Metrics
Bandwidth or Utilization
Queuing delay
Handover
Hop count
Jitter
/
/
Length
/ / / / /
/ /
/
/
/
As stated by Cruz-Sanchez, Franck and Beylot, ―In the deterministic case, the routes are optimized against an end-to-end delay or any other linear cost. Some of these techniques come from the transport optimization filed. For non-deterministic networks, most of the early routing algorithms target delivery ratio as the premier objective, and metrics such as delay, message size or network load which are secondary. This situation is similar to the best effort case in classical networks except that the reference performance indicator is not an end-to-end delay but a delivery ratio‖ [112]. The objective of the contribution is to propose multi-metrics tailored to the specifics of a satellite constellation. The author expected those five metrics to go farther than the common delay and delivery ration approach.
It will find the
optimized routing paths from source to destination by using the said five metrics. The algorithm is more complex and uses performance but the author has considered throughput, probability delay, link length, queuing delay, and hop count. There are three metrics from Table 4-1 which are not applied in the algorithm, such as jitter, handover, and lifetime. There are reasons for excluding each of them as 115
follows: 1) Jitter, because of the structure of the COMMStellationTM satellite system which is created for presenting a low latency and jitter satellite constellation for broadband communications to the public. One of the nine objectives in previous publications specifies ―special purpose low latency and jitter communications‖ [17], [85]. The bandwidth among satellites is 8.8 Gbps, and in the part of uplink/downlink is 1.1 Gbps, which is a huge bandwidth compared with the research of Cruz Sanchez. Previous research uses satellite bandwidth equal to 19.2 kbps [112]. Therefore, the jitter is not decent to be considered in the algorithm. Also, there is latency which is used to calculate the propagation delay. It is used in a metric which is known as Endto-End delay metric. 2) Handover metric, because the COMMStellationTM satellite system designed for each Trunk station and User station will have two antennas: one to stay in touch with its current linking satellite and the second antenna for hand over to the next satellite before it loses contact with the current one [85]. Therefore, the handover metric of the COMMStellationTM satellite system is worthless to apply in the algorithm. 3) Lifetime, because in each Trunk station and User station there are two antennas. Both antennas communicate with two different satellites. Hence, the COMMStellationTM satellites system must have on-board software to process the time-tagged commands and then determine which antenna will be used for a given target. If an attempted link fails or sees a station return peer local conditions, a secondary satellite target may be selected for approving the corresponding ground station to be ready for the link [85]. Therefore, it is unnecessary to observe the lifetime metric of the COMMStellationTM satellite system in the algorithm.
116
4.4.1 Routing Metrics Route computation relies on the definition of performance indicators called routing metrics. Popular metrics are the number of hops, throughput, end-to-end delay, and jitter. However, routing consists in computing a path from a source to a (set of) destination(s). Each path is evaluated according to characteristics called metrics. During route computation, the ‗optimization‘ paths are selected to fulfill the requirements of the supportive services. In today‘s networks, the metrics considered are mainly the end-to-end delay metric, queuing delay, the route length expressed as a number of hops, link utilization, link loss, link availability, link length, and jitter. The routing algorithm for hybrid satellite networks is proposed based on a weighted graph model to solve the QoS routing problem in BHSCCS. The metric selection of the proposed technique is based on optimization with the relationship ratio of QoS metrics for triple-play services which have strict requirements on bandwidth, delay variations, and availability.
Hence, five significant dynamic
parameter functions are considered. The first metric is the propagation link delay, which is determined by an advanced propagation delay model from the source to the destination. The second metric is the queuing delay. It is affected by the traffic load on a particular satellite and its outgoing links, as the packet traverses varying traffic gateways. The third metric is link hop count. The fourth metric is link utilization in which the throughput part of all the next neighborhood nodes confirms the best path. The fifth metric is link length that chooses the shortest link between user/trunk stations to both satellites. The five metrics are used to reduce the end-to-end link delays, deteriorate the rerouting frequency, and choose the best route path in the routing table.
117
4.4.1.1 End-to-End Delay Metric The end-to-end (E2E) delay [112], [113], [114] measures the time taken for a message to journey from the source to the destination. In a network, variations of the end-to-end delay are bounded by the variations of the propagation, processing, and transmission delays.
It also impacts the experience for triple-play services.
Therefore, it will calculate the total delay over both the wired and wireless networks. Figure 4-6 illustrates the end-to-end delay of the simulation model. propagation delay for a source uplink into a satellite node. delay for a source downlink into a source trunk station. for a high-speed Internet backbone. destination uplink into a satellite node.
is the
is the propagation
is the propagation delay
is the trunk station propagation delay for a is the propagation delay for a destination
downlink into a destination node. Then, the overall E2E propagation delay (
) can
be calculated using the following Equation (4.8) derived below.
Figure 4-6 Illustration of E1 to E5 delays
The E2E delay (
) is calculated as follows:
,
118
(4.1)
)
√(
(
)
(
) ,
(4.2)
,
)
√(
(
)
)
((
)
(4.3)
(
) ,
(
(4.4)
),
(4.5)
,
(4.6)
,
(
)
(
(4.7)
),
(4.8)
where: (
)
,
,
(
)
,
,
(
)
,
,
,
(
, (
),
(
, ),
(
),
,
),
,
(
), ,
, ,
. 119
According to the approximated end-to-end delay, the link metric cost (Cd) will be referred to in Table 4-2 as a function of Pd.
Table 4-2 Mapping Function of Cd for a Given Delay Pd (millisecond) Cd (cost)
0 – 60 100
60 – 70 50
70 – 80 33
80 – 25
4.4.1.2 Queuing Delay Metric In a BHSCCS over a LEO satellite network, each link can be modeled as a finite capacity queue. The decentralized and fast-changing evolution of broadband high-speed Internet architecture has worked reasonably well. Moreover, the network traffic is increasing exponentially due to the integration of large networks with many different factors.
Under this situation, it will be more vulnerable to frequent
congestion and collapse. Congestion occurs when the total demand exceeds the bandwidth that the available resources can provide [113]. A traffic load generating method depends on traffic density. It depends on the statistics about the user density levels per zone [12], [115]. Thus, all the traffic user nodes are sent appropriately with a traffic generating module built in each node to simulate the traffic generated by users. The open Jackson queuing network is used to analyze of the queuing delay. Figure 4-7 shows a stationary open Jackson queuing network for the analysis of the queuing delay. The arrival is assumed to follow a Poisson Process with rate . The
120
service time of node i may be exponentially distributed with service rate
. The term
in Equation (4.9) is the routing probability from node i to j [110]:
∑
,
where d is the destination,
(4.9)
. In hybrid satellite networks, some of
is
probably valued as zero, which means that no packet enters the queue. The term is the sum of the arrival rates into node link i from all sources and can be computed by Equation (4.10):
where s is the source and
∑
,
is the arrival from the source. The term
(4.10)
is the
utilization of the node link i and directly reflects the traffic load on the link:
.
(4.11)
The Equations (4.10) and (4.11) show the rate relationships in node links in the network.
121
Based on the queuing theory and Little‘s equation, the queuing delay and some parameters of node state information can be deduced by the following equations. The average service rate of node i can be written as follows:
,
where
(4.12)
is the node link capacity and L is the average packet length. The service
delay is calculated by
.
(4.13)
The pending delay in a M/M/1 queue is given by
(
.
(4.14)
)
Finally, the queuing delay of a node link can be obtained as follows:
122
,
(4.15)
where:
= arrival rate,
= server utilization,
= service rate,
L = average packet size,
ts = average service time in server per packet, and tp = average waiting time in queue per packet.
In the queuing delay metrics, it can make a calculation by using the following equation [110]. So, it can calculate the E2E queuing delay over BHSCCS with the following Equation (4.16):
( )
∑
.
Figure 4-7 Finite Population Queuing Model [110]
123
(4.16)
According to the approximated queuing delay, the link metric cost (Cq) will be referred to in Table 4-3 as a function of Pq. Table 4-3 Mapping Function of Cq for a Given Delay Pq (millisecond) Cq (cost)
0 – 0.015 100
0.015 – 0.025 50
0.025 – 0.035 33
0.035 – 25
4.4.1.3 Hop Count Metric This metric provides a minimum hop count routing. The link quality for this metric is a binary term; either the link exists or it does not. The primary advantage of this metric is its simplicity. The number of hops, which is the number of links on a path from the source to the destination, is often considered as a good optimization criteria to achieve routes with a low E2E delay and resource usage. In addition, the computing of hop count requires no additional measurements, unlike the other metrics. In wireless sensor networks, using routes with a low hop count helps to reduce the power dedicated to packet forwarding, thus prolonging the network life [112]. The hop count metric cost is given by the following Equation (4.17):
(
where
)
∑
,
(4.17)
is a total amount of link hop count on the reachable path.
According to the approximated hop count, the metric cost (Ch) will be referred to in Table 4-4 as a function of Ph. Table 4-4 Mapping Function of Ch for a Given Hop Count Ph (counts) Ch (cost)
0–5 100
5 – 10 50
124
10 – 15 33
15 – 25
4.4.1.4 Link Utilization Metric The link utilization metric denotes the number of bytes transported from the source to the destination per unit of time. It depends on the throughput offered by the least capable link [112]. Suppose that the source node is m1, the destination node is mk, and (m1, mk) represents the reachable path from m1 to mk. Between the two nodes, there are n reachable existing paths, such as: (m1, m11, m12, …, m1j, …, mk), (m1, m21, m22, …, m2j, …, mk), …, (m1, mn1, mn2, …, mnj, …, mk). The term mnj means the jth hop node of the nth reachable path. Among the n paths, the optimal path must exist, and can be obtained using Equation (4.18). This equation shows the utilization of the n paths (m1, mn1, mn2, …, mnj, …, mk). It gives the minimum available utilization among hops from the source node to the destination node, where hopn means the total amount of hops on the nth reachable path [90]. A traffic generating method is related to the queuing delay metric. All the nodes have a provided traffic load in order to simulate the traffic generated by users. The performance of link utilization is measured by its efficiency as stated in [116]. The goal of this metric is maximum efficiency link utilization from m1 to mk. The link utilization cost is defined as [98], [90]:
( )(
) [
{
(
)
(
(
))
(
(
)
)}
(
]
)
where uz is the utilization of hopn computed as the billing efficiency of data that can be sent between nodes.
125
According to the approximated link utilization, the metric cost (Cu) will be referred to in Table 4-5 as a function of Pu.
Table 4-5 Mapping Function of Cu for a Given Link Utilization Pu (%) Cu (cost)
100 – 75 100
75 – 50 50
50 – 25 33
25 – 0 25
4.4.1.5 Link Length Metric A COMMStellationTM model is used in the simulations and only the topology information of the COMMStellationTM system is considered. The orbital parameters of every satellite in the COMMStellationTM system at a time point are obtained via NS-2. Different snapshots of the constellation are chosen at different time points. In Table 3-1, it can see the satellite orbital parameters, which will be used to calculate the link parameters [1], [2], [90]. From the satellite orbital parameters, the topology parameters need to be calculated. For example, Figure 4-8 shows three-dimensional coordination of satellite orbits if it want to calculate the link length between satellite node A and satellite node B, and each satellite‘s orbital parameters are known. It is only needed to find the central angle, .
With the equation of distance between two nodes in three-
dimensional geometry, the haversine formula given by Equation (4.19) can be derived. Hence, this metric will find the shortest link length between a satellite and a ground station using the haversine formula for any two points on a sphere:
126
,
(4.19)
where: and
are the latitudes of satellites A and B; and
and
are the longitudes of satellites A and B.
From Equation (4.19), the value of can be obtained. So, the link distance between satellite nodes A and B is
( )
,
(4.20)
where R is assumed to be the distance between the core of the Earth and the satellite.
Figure 4-8 Three-Dimensional Coordination of a Satellite Orbit [2], [90]
127
The needed topology can be created at any time point and the data be obtained. According to the approximated link length, the metric cost (Cl) will be referred to in Table 4-6 as a function of Pl.
Table 4-6 Mapping Function of Cl for a Given Delay Pl (millisecond) Cl (cost)
0 – 0.015 100
0.015 – 0.025 50
0.025 – 0.035 33
0.035 – 25
4.4.2 Applying the Proposed Routing Technique As mentioned above, the simulation topology has been set up. Then, the performance of the algorithm can be simulated based on the weight graph model and the performance analysis. In the deterministic case, the routes are optimized against the E2E delay or any other linear cost. Some of these techniques come from the transport optimization field. For non-deterministic networks, most of the early routing algorithms target the delivery ratio as the premier objective, and metrics such as delay, message size or network load are secondary. This is equivalent to choosing as the best performance indicator not the E2E delay but the delivery ratio [106].
The objective of the
contribution is to propose multi metrics tailored to the specifics of a hybrid satellite constellation. The author expects those five metrics to go farther than the common delay and delivery ration approach. It will find the best routing paths from source to destination by those five metrics. The algorithm is more complex and evaluates the
128
performance by considering the propagation E2E delay, queuing delay, link hop count, link utilization, and link length of each node. Based on the metrics description above, the author has implemented the Optimized Routing Protocol for Hybrid Satellite Network (ORPHSN) [88] algorithm into a Broadband Hybrid Satellite Constellation Communication System (BHSCCS) [86], [116]. The ORPHSN algorithm incorporates both the inherent dynamics of the hybrid satellite network topology and the triple-play services of the traffic load in a COMMStellationTM system.
Moreover, it is applied perfectly to take into
consideration five metrics for characterizing routes in a hybrid network, while at the same time satisfying the Quality of Service (QoS) requirements.
Finally, the link cost metrics can be calculated as follows:
.
(4.21)
where Cd denotes the propagation end-to-end delay cost, Cq denotes a predicted value of the queuing delay cost, Ch denotes the hop count cost in a path, Cu denotes the link utilization cost value for each link delay, and Cl denotes the link length cost between satellite and ground. The maximum total cost is the total sum of the maximum cost value for each metric.
129
4.4.2.1 Weighted Graph Model This algorithm is based on the Dijkstra‘s algorithm [117]. In the ORPHSN algorithm, the shortest part is defined as the minimum-delay path. The grid-like network graph structure is used to represent the physical network topology. It is modeled on the directed graph
(
where
),
(4.22)
represents the comprising set of nodes, and
represents the set of all
existing connection links (edges) [33]. Also, it is clear that the size of
| |
where
is
,
(4.23)
is the number of the routes for a packet passing throughout a plane that the
system is comprised of, and
is the number of nodes per route plane.
By numbering the route planes and the nodes within a system, it can define a pair of numbers ( Clearly, (
(
), called virtual coordinates, which uniquely identify a node. ) identifies the position of a node within a route plane, while
) identifies the route plane. Based on the system model described by the weight graph methodology, [118]
an efficient method to route a packet from a source node, destination node,
(
(
) , to a
), is the hop-by-hop approach [118]. The possible
next hop is chosen if the Linkcost between end-to-end of the virtual node in vertical and
130
horizontal directions, approaches 1. A neighboring node
will be selected as the
possible next hop if:
|
|
|
| or |
|
|
|
.
(4.24)
This process guarantees that the chosen paths are in the set of the minimum hop paths. An optimized routing algorithm capitalizes on the system deterministic dynamics to tackle the problem of reaching a routing metric in a realistic satellite system. At the same time, it takes into account the loading of a hybrid satellite to route packets efficiently. The protocol consists of two phases. In the first phase, all possible next hops are determined, while in the second phase the most suitable one is chosen. Before describing the proposed protocol in the context of the routing metrics, the author provides some useful definitions [2]. Definition 1: Horizontal Path to a Destination. A path originating at the current satellite
involves only hops in the x-direction and at the same time its
size in
|
where
is the destination satellite.
131
|,
(4.25)
More formally, the horizontal path from
(
)
to destination
*
is denoted by
+,
(4.26)
such that
.
(4.27)
Definition 2: Next Horizontal Path to a Destination. The horizontal path to a destination originates from the satellite next to the current one (in the same orbital plane towards the destination). More formally,
(
)
(4.28)
such that
|
|
|
132
|
(4.29)
and
.
(4.30)
Definition 3: The Last Horizontal Path to a Destination is
(
The origin from satellite
)
.
(4.31)
, in the current orbital plane, such that
|
|
0
(4.32)
and
|
|
Definition 4: Vertical Path. A path is
133
0.
(4.33)
*
+
(4.34)
so that
.
(4.35)
Thus, given a graph G (V, E) constructed in this way, and a call request between source and destination, the routing is to find a feasible path. The ORPHSN algorithm considers a feasible path as a path that satisfies bounded requirements for each cost metric. As for a connection request with a source to destination vertex pair, the routing is to find the optimized cost path. Here, the optimized weight path from source to destination in the graph made by Graph Topology Representation (GTR) [117] corresponds to the optimized cost path in the network graph. This process guarantees that the chosen paths are in the set of optimization paths. It is used to specify an identification method into the
value to the
nearest one. Each metric has a different cost value. Also, the Graph Topology Representation (GTR) is described as follows: 1) Construct a directed graph like structure with
(
) and arrange the vertices to form a grid-
rows and
(4.23) can be derived.
134
columns so that Equations (4.22) and
2) Use the initial link assignment for the routing table. In a topological estimation stage, all nodes and links in the network will be traversed; it has to gain cumulative cost values from nodes. 3) Process each metric by using Equations (4.8), (4.16), (4.17), (4.18), and (4.20) into mapping tables of each corresponding metric value. 4) Process
following Equation (4.24) with all paths in the routing
table. Then, compare the cost of the link in the routing table valued nearest one to set a path list for traveler information. After the source node has all listed paths from source to destination, the five metrics are calculated into a mapping table for each metric. For instance, a link utilization metric is considered for the maximum utilization based on end-to-end nodes which is processed by Equation (4.18) and takes the
into a mapping table of
versus link utilization. After that, the process will have the mapping tables of each metric. To complete this, Equation (4.24) makes a calculation for all path lists in the routing table. As a result, each path has it own
.
The ORPHSN algorithm includes the calculations into a routing table. For every call request from source to destination, the
(
) will be constructed in order
to find the feasible path. The ORPHSN algorithm considers a feasible path as the path that satisfies bounded requirements for each cost metric. The optimized path weight from source to destination in the graph made by GTR corresponds to the optimized path cost in the network graph. Figure 4-9 illustrates the flowchart of the ORPHSN protocol.
135
Figure 4-9 Flowchart of the ORPHSN Protocol
4.5 Routing Results The author has implemented all routing techniques based on the described network topology and the traffic model given above. The author has developed the coding program of the proposed ORPHSN algorithm in C++ and the compiled code on a NS-2 version 2.34 simulation platform. The author limits the simulation scope on score simulation to two error percentages, which is a practical error percentage as 136
described in [1]. The author has tested the network performance of the routing algorithms by doing the simulations based on the observation of the end-to-end (E2E) delay for each given pair of source and destination nodes. Independently of the user type, there is an emphasis on showing the results from Bangkok to Boston in this study. In the conducted computer simulations, the source node is located in BangkokThailand. The destination node is in Boston-Massachusetts-United States of America [88]. The simulation results are compared with the conventional algorithms. The author managed to simulate the proposed ORPHSN, FAR, and RAR algorithms with triple-play service loads in the developed model of the BHSCCS network topology. As for the computer simulations, the instantaneous end-to-end delay associated with a route length for a given hop count of the proposed OPRHSN is illustrated in Figure 4-10. The algorithm optimizes the paths in the routing table. Thus, all neighboring nodes know each other. When a packet is received by one of these neighboring nodes and is destined to fail, it is deflected to another direction.
137
Figure 4-10 End-to-End Delay versus Allowed Route Length
The end-to-end delays of triple-play service traffic between two user terminals in Bangkok and Boston is obtained. The most important metric of the satellite network is the end-to-end propagation delay. Figure 4-10 illustrates the simulation results of the proposed ORPHSN, FAR, and RAR algorithms. It plots the path delay versus the route length from the source to the destination.
The end-to-end
propagation delay for the proposed ORPHSN is 81.66 ms for 10 hops, whereas it is 86.66 ms for 11 hops and 91.66 ms for 12 hops for FAR and RAR, respectively. This is because the proposed ORPHSN in BHSCCS is compared during route intervals in a routing table with a hybrid network system. The results show that the proposed technique chose the optimized route by having the least number of hops when compared with the conventional techniques.
138
Figure 4-11 End-to-End Delay versus Allowed Route Length with Different Application Loads
In order to see fair results in terms of the end-to-end delay ratio of the proposed ORPHSN algorithm, the author has performed simulations for three different traffic loads which are triple-play services with variable bit rate for voice and video loads, bulk transfer data with constant bit rate 2048 kbps, and reliable messaging data with constant bit rate 512 kbps. The results of these simulations are presented in Figure 4-11. The highest end-to-end propagation delay is for triple-play services in the proposed ORPHSN, 81.66 ms in the triple-play services, whereas it is 72.02 ms and 64.46 ms for bulk transfer and reliable messaging, respectively. It is also observed that the proposed ORPHSN has optimized performance for triple-play services, in terms of propagation delay in the hybrid network system. In addition, when the traffic loads have increased their size, the end-to-end delay has increased, as well.
139
Figure 4-12 End-to-End Delay versus Terminal Bit Rate
As shown in Figure 4-12, the proposed ORPHSN has a lower end-to-end delay when compared with the FAR and RAR algorithms. Thus, the probability of packet traversing the whole BHSCCS network is lower.
Figure 4-12 illustrates the
comparison of user station bit rate versus end-to-end delay. This figure shows that the user station bandwidth capability started from 100 Mbps until reaching a maximum bit rate of 1.1 Gbps. It is notable that the user station has more uplink and downlink bandwidth, so the end-to-end delay in the network is lower. Although this is achieved with an occasional terminal bit rate increase 10% during intervals, these algorithms reduce the end-to-end propagation delays by handling the statistical fluctuations more effectively. When the author compared these algorithms for the triple-play services presented in Figure 4-12, the author observes that they are close to each other and have tendencies in the same direction. However, the proposed ORPHSN algorithm outperform FAR and RAR with respect to the end-to-end propagation delay in BHSCCS environment. 140
Figure 4-13 End-to-End Delay versus Traffic Loads in the Network
The proposed ORPHSN is implemented on the BHSCCS model, and each node connection in the network topology is assumed to have traffic loads constrained within an increasing traffic load to 20%. The simulation assumes that the connections are of identical traffic characteristics. Figure 4-13 shows the comparison of the endto-end delay from the source to the destination when different percentages of traffic loads are applied. Moreover, the average traffic loads in the hybrid network system values for this simulation are around 1% during intervals, which are due to the initially assigned traffic loads. The impact of traffic load rates on the hybrid network system for the proposed ORPHSN, FAR, and RAR algorithms concerned with the increase of the end-to-end propagation delay.
The figure shows that ORPHSN
outperforms FAR and RAR by having the lowest delay. This is because the proposed algorithm used multi-metrics to optimize in that period of lifetime satellite connections for more information in the hybrid network system optimization. 141
Figure 4-14 Link Availability Bandwidths versus Terminal Bit Rates
The last figure is a comparison of link availability bandwidth versus terminal node bit rate after the routing algorithm utilizes the network traffic. Figure 4-14 shows that ORPHSN has less availability bandwidth size.
The availability of
bandwidth can be calculated from the throughput for each bit rate period of a terminal node. The satellite routing algorithm based on the optimized paths considers many factors, such as the minimum propagation E2E delay, the minimum queuing delay, and the optimal link utilization. This chapter puts forward an ORPHSN routing technique with optimization metric cost.
142
CHAPTER 5 QUEUE MANAGEMENT SYSTEM
In coherence to other research, the author has implemented queue management technique to study the most usual type of hybrid satellite constellations based on the described network topology and the traffic model given in the previous chapter. The author has tested the performance of a new queue algorithm in terms of drop ratio and average queue length per link. A drop ratio is defined as a ratio of dropped packets to the sum of dropped and successfully transmitted packets; and an average queue length is the sum of the average number of packets in bottleneck gateways.
5.1 Background for Queue Management In the next-generation Global Area Network (GAN), satellite networks are expected to complement the coverage of the global networks in instances where they best serve the communication needs of users. In recent years, Micro Systems Canada, Inc., (MSCI) [17] has been deployed to provide firmly global coverage communications to the public. To increase the feasibility of success, commercial high-speed broadband data satellite networks are important for the designers to consider, both wired and wireless techniques to be integrated. The initiative of the COMMStellationTM by MSCI is to supply, produce, deploy, and perform the COMMStellationTM system on a satellite constellation topology over Low Earth Orbit (LEO) satellites. The concept is providing global backhaul and connects rural areas.
143
Each COMMStellationTM [85] satellite will provide high-speed, high-bandwidth communications to four individual user service provider terminals, with each satellite supporting a total data throughput of up to 8.8 Gbps (1.1 Gbps per user service, both uplink and downlink) over 1.6 GHz of bandwidth. For the ground side of the link, there are Trunk Stations and User Stations.
The Trunk Stations, which always
connect to fiber infrastructures, will transfer data Internet services with a mission concept which is bent-pipe configuration. The User Stations are aiming to be the new high-bandwidth Internet Service Providers (ISPs), allowing individual clients to connect to their satellite links on the globe. Along with the wide application of the Internet and the rapid development of the satellite techniques, the concept of a hybrid satellite network has been an area of research focus. Due to challenges, the efficient utilization of the capital investment in the face of high uncertainty in traffic demand needs to be considered during the hybrid satellite network design stage. Then, the queue will suffer from a large range of queue size oscillations, which will make an early congestion notification hard and finally lead to congestion [119]. Recent research activities have placed a lot of emphasis on various queue weight techniques for the active queue management over the satellite segment assuming that the bottleneck links are known. A variety of Hybrid Satellite – Blue Queue (HSBQ) [120] algorithms for hybrid satellite constellation systems have been proposed. This chapter proposes a rate-based stabilization for HSBQ. This algorithm adjusts the queue weight, which is used to estimate the average queue length, based on the rate; moreover, it uses the changes of the average queue length to adjust the amount by the mark or drop of probability which is changed.
144
5.2 Active Queue Management (AQM) The two main objectives of queue management are high link utilization with a low packet loss and a low packet queuing delay. These objectives conflict with each other. A small buffer can guarantee a low queuing delay but it suffers from a high packet loss and low link utilization. Hence, a problem arises as to how to manage the queue in a gateway. Queue management is strongly associated with packet drops. So, the expected objective that arises is when to drop a packet and which one to drop. The traditional scheme used for queue management is the passive queue management that is based on a congestion control approach. Drop Tail [79] is one of the traditional schemes for passive queue management. With passive queue management, packets are dropped only when the buffer is full. This scheme results in a high packet loss and a long queuing delay. synchronization.
It also introduces a lock out problem and global
The congestion control approach is not suited for interactive
network applications such as voice, video sessions and data transfers requiring a low end-to-end delay and jitter because the Drop Tail queue is always full or close to full for long periods of time and packets are continuously dropped when the queue reaches its maximum length. So, the delay will be large, which will make interactive applications unsustainable. The second major disadvantage of Drop Tail is the global synchronization problem, which arises because the full queue length is unable to absorb burst packet arrivals, and thus many of them are dropped, resulting in global synchronization. Thus, global synchronization causes all the sources to slow down, at the same time resulting in long periods of low link utilization. Moreover, another main reason for global synchronization is the lockout behavior of Drop Tail where the queue is monopolized by some flows and other connections may not easily use the queue. 145
To eliminate such problems, Active Queue Management (AQM) has been introduced in recent years, which is a congestion avoidance preventive approach. The first AQM algorithm RED detects congestion by observing the queue state. In RED [54], a packet drop probability is linearly proportional to the queue length. The AQM algorithm RED drops packets before a queue becomes full. This reduces the number of packets being dropped. RED and its variants use the queue length as a congestion indicator that results in certain drawbacks. In order to overcome the difficulty of relying only on queue length to identify the level of congestion, various other AQMs with different congestion indicators are introduced. To overcome the problems with RED, REM [68] was proposed. This AQM scheme attempts to make the user input rates equal to the network capacity. In case of high congestion, the sources are notified to reduce their rates. In contrast to RED, REM decouples congestion measures from performance measures which stabilizes the queue around its target irrespective of the traffic loads, leading to high utilization and a low delay. AQM schemes like GREEN [80] and AVQ [63] also depend on the arrival rate to control the congestion in the gateway. AVQ uses only the input traffic rate for the measure of congestion. This provides early feedback of congestion. It provides a better control than a number of other well-known AQM schemes. Another AQM scheme, BLUE [70], does not use the queue length as a congestion metric. BLUE uses the packet loss and link utilization as a congestion indicator. BLUE improves RED‘s performance in all aspects. It is extremely simple and provides a significant performance improvement over the RED queue. This AQM maximizes the link utilization but suffers from large queuing delays. In LRED [59], the packet loss ratio is used to design a more adaptive and robust AQM. It uses
146
the instantaneous queue length and packet loss ratio to calculate the packet drop probability. As stated by Das, Dutta, Helmy, Goel and Heidemann, ―A successful AQM algorithm must provide simple, intuitive means of configuring parameters to achieve a stable operation under a steady load and rapid adaption to changes in loads. Large oscillations in queue length, for instance, typically result in periods during which the queue is empty, reducing the utilization of the link. Similarly, an algorithm that fails to adapt to changes in traffic loads or adapts too slowly may perform poorly in the Internet environment, which is highly dynamic. Numerous AQM algorithms have been proposed to eliminate the drawbacks associated with Random Early Detection (RED) while retaining their advantages.
For example, Fair Queueing (FQ) at a
gateway provides local fairness among all the flows that enter that gateway. However, this requires us to maintain a per-flow state.
A good scheme to
approximate FQ has been the Core Stateless Fair Queueing architecture (CSFQ), which uses flow rates embedded in packet headers. CHOKe (CHOose and Keep for responsive flows, CHOose and Kill for unresponsive flows) is another stateless AQM, which uses random sampling of packet queues.
Fair Random Early Detection
(FRED) is an enhancement to RED to ensure fair buffer sharing by maintaining state for active flows at the gateway. Stabilized RED (SRED) identifies candidates for high bandwidth flows from a cache of recently seen flows. RED with Preferential Dropping (RED-PD) uses a list of previous RED packet drops to identify misbehaving flows and control them using different drop probabilities‖ [121], [122].
147
5.3 Proposed Hybrid Satellite – Blue Queue Algorithm The proposal of an AQM algorithm has to maintain high link utilization at a low loss rate and with a queuing delay in a wide range of network environments. A stable operation and quick response to changes in load are also desirable. This section outlines a proposed algorithm and explains its design in terms of these attributes. The author begins with a general discussion on how the proposed algorithm provides & controls queuing delays, and then provides a description of the adjustment of the algorithm when adapting to changes. BLUE [123] uses packet losses and links idle events to manage the congestion in order to give a very high throughput and high utilization with low queue length stability. For higher link utilization and better throughput, it should be accessible by Load-based AQMs instead of Queue-based AQMs. The conducted research indicates that it is unnecessary to give attention to the additional information flow. In the routers, the congestion is bringing awareness to get a better strength by Load-based AQMs.
Meanwhile, the congestion comparison indicates that the design of the
Queue-based AQMs is simple when compared with other AQMs, except in some cases the parameter tuning to suit each individual problem is required. In terms of satellite high throughput and utilization, the Load-based AQMs performed better than Queue-based AQMs regarding the information flow in AQMs. In AQM schemes, the comparison is based on the performance metrics given in [53]. It appears as a moderate loss rate and low queue stability for the BLUE queue. Hence, the author has to modify it to improve the BLUE algorithm and make it better for the broadband hybrid satellite network system. Also, the loss rates are
148
low, and the queue stability is higher. It aids to support higher link utilization, and the throughputs are also very high. Generally, there is a probability of dropping packets before the queues overflow at the space nodes and/or ground nodes in the system. An HSBQ (Hybrid Satellite – Blue Queue) is an active queue management algorithm for the broadband hybrid satellite network system, which is ordered to avoid high packet loss rates and control stable stream queues. The by-product from this modification is a reduced queue length. The motivations for removing unfairness while maintaining queue length stability is that the HSBQ scheme decides to discard packets in order to decrease the input traffic before the queues overflow [120]. The author adopts the Z parameter from the Yellow queue [65] to be implemented in this proposal; the load factor Z will be calculated during each averaging interval as follows:
,
(5.1)
The Virtual Available Capacity function ĉ, can be updated based on the queue control function, following [65] the Yellow algorithm. The smoothing parameter (α) and the desired utilization parameter (δ) are adopted from the AVQ algorithm [64], which means a modified theorem is obtained to be implemented in this proposal.
149
Also, the HSBQ proposal is based on the BLUE active queue management algorithm by further combining a smoothing parameter, desired utilization parameter, and a load factor. HSBQ maintains a single probability Pm to identify or drop packets, where the buffer continues to overflow in the HSBQ algorithm, that is to increase Pm to increase the congestion notification ( 1) and decrease Pm value to reduce the congestion notification rate ( 2) in case of buffer emptiness. Hence, the pseudo-code of HSBQ is
Upon a packet loss (Qlen > L) event: if ( ( ( ( current – recent_update ) × β × δ × α ) / C ) > hold_time ) Pm = Pm +
1
×Z
recent_update = current
Upon a link idle event: if ( ( ( ( current – recent_update ) × β × δ × α ) / C ) > hold_time ) Pm = Pm -
2
/Z
recent_update = current
where the following constants are used: hold_time : minimum time period between two consecutive updates of pm; Pm
: to either mark or drop the packets; 150
1
: incremented;
2
: decremented;
β
: buffer size;
δ
: desired utilization of the link;
α
: smoothing parameter;
C
: capacity of link; and
Z
: load factor.
5.4 Implementation with Broadband Hybrid Satellite Networks In hybrid satellite communication networks, different restrictions and requirements on different links have to be taken into account. Thus, the author has selected a typical representative of LEO Walker-type satellite constellations with global area networks, the COMMStellationTM satellite constellation [85], [86], [96], and [97] composed of 72 operational satellites plus spares divided into 6 polar orbital planes at an altitude of 1,000 km and an inclination angle of 90. There are 35 Trunk Stations on the ground to communicate with the satellites all the time. The satellite constellation parameters are shown in Table 2-1. The satellite system can be linked with the high-speed Internet and other networks by using suitable gateways. Figure 5-1 shows the network architecture of the hybrid satellite system with its three segments: space, ground, and user segments.
There are two gateways
connected through a North America and Asia links. Each User Station pair sends triple-play service packets to the destinations.
151
Figure 5-1 illustrates the hybrid
satellite network topology which is used in this work. The RED, Blue, Droptail, and proposed HSBQ queuing techniques are applied separately on the queuing system. The topology in this chapter is different from that of the previous chapter, because the proposed HSBQ queue is proposed for evaluating the bottleneck links in BHSCCS networks.
Therefore, the network topology needs a modification for
obtaining better results after running the simulations, in order to achieve a complete resolution of the bottleneck link problem [119], [122], [123].
Figure 5-1 Hybrid Satellite Constellation Layout [120]
The recommended hybrid satellite constellation parameters are shown in Table 2-1. In the computer simulations, four source user station links in different areas around South East Asia are chosen to observe the network traffic. The four receiving nodes are in North America. The author assumes the satellite and link bandwidths to be 90.112 Mbps and 11.264 Mbps, respectively. The link capacity of the trunk station 152
is 6.22 Mbps with 1 ms.
Within the Internet backbone, the author adapted to 1.55
Mbps with 5 ms. These bandwidths are 10 percent of the maximum bandwidth. The bottleneck link queue operates in a byte mode with a buffer size of 400 KB [59], [70], [122]. In addition, the author assigns an error model at 2% [124]. The author limits the scope of the computer simulations on score simulation to two error percentages, and one rigid practical error percentage [1]. The author uses the bottleneck queue size as an indication of the queuing delay in the bottleneck. In this research, new efficient active queue management for constellation satellite system mechanism is proposed into BHSCCS over LEO orbitals and studied with network simulations. As for traffic loads, the author evaluates the proposed scheme with more realistic traffic. The generated traffic load in the simulations is [100], [125] tripleplay which encompasses the provisioning of three services: high-speed Internet, television (Video on Demand or broadcasting video), and Voice over IP through the use of a single broadband connection. Key factors in the triple-play service delivery constitute the technological advances derived from the development of appropriate equipment described in the subsections below.
5.4.1 Voice in Traffic Loads VOICE: as stated by Hoene, Karl and Wolisz, ―Internet Telephony allows offering telephony services across networks using the Internet protocols and is an alternative to the classic telephone system (PSTN). signaling and transmission protocols.
IP Telephony consists of
The signaling protocols (H.323 or SIP)
establish, control and terminate a telephone call. Digitized human speech is encoded. 153
Encoding algorithms compress the audio signal. Most speech encoding schemes compress segments of speech and generate frames.
The common, standardized
encoding algorithms (G.711, G.723.1, G.726, G.729, GSM, AMR, and AMR-WB) differ in their coding rate (bits/s), frame rate (frames/s), algorithmic latency (ms), complexity and speech quality (MOS). An important optimization opportunity for speech codecs is the fact that human speech consists of periods of voice activities and silence. Some coding schemes lower the packet rate during silence to send only background noise descriptions (SID). This operating mode is called discontinuous transmission (DTX).
One or multiple speech frames are concatenated in one packet.
That packet which is the VoIP payload is typically encapsulated into RTP, UDP, and IP packet headers which are added to the speech segments before the packets are sent to the receiver‖ [99], [126]. The IP / UDP / RTP header can generally be thought of as a fixed overhead of 40 bytes per packet, though on point-to-point links. The VoIP application is used between the two UDP communicating network elements in the research. At both sides, the VoIP encoder uses a G.711 codec for encoding and decoding [100].
G.711 is the international standard for encoding
telephone audio on a 64 kbps channel. It is a pulse code modulation (PCM) scheme, operating at a 8 kHz sample rate. The VoIP CODEC of G.711 is described to run in the research. The coding speed is 64 Kbps. The frame size is 20 ms. The processing delay is 20 ms. DSP MIPS is 0.34. IPv6 is 40 bytes. UDP is 8 bytes. RTP is 12 bytes. The payload is 160 bytes. The number of flows is 7. The subscription rate packet time is 20 ms, which affects the quality of the voice.
154
In this sub-section, the author has adopted a VoIP application model [116] and implemented it in the network simulation.
This model contains all the relevant
features of a VoIP application as described in [126]. More specifically, it keeps modeling the sender and the receiver sides separately. As stated by Bacioccola, Cicconetti and Stea, ―The sender side includes the following: -
A customizable codec, which generates generic speech frames (the latter being either voice samples of voice frames, depending on the codec), and
-
A multiplexer, which aggregates several speech frames into one payload.
The receiver side, instead, includes the following: -
A customizable playout buffer algorithm, and
-
A demultiplexer.
Moreover, a user activity is modeled as a series of talkspurt/silence commands given to the sender. This allows for an easy integration of one-way and two-way (coordinated) user activity models. Finally, as far as data modeling is concerned, this model is of a speech frame by storing its size, its generation timestamp, the talkspurt the frame is associated to, and its position within the talkspurt‖ [126]. The NS-2 implementation of the above model includes several inter-operable modules, which are depicted separately in the following Figure 5-2 illustrates all the functional modules.
155
Figure 5-2 Model for VoIP Simulation in NS-2 [126]
5.4.2 Video in Traffic Loads VIDEO: as stated by Sotiropoulos, Styliaras, Kosmatos, Papagianni, Tselikas and Venieris, ―H.264 part 10, also named Advanced Video Coding (AVC), is a digital video codec standard, noted for achieving very high data compression. It is used in wired and wireless network environments. It has proven to be more resilient to error prone networks through the use of flexible macroblock ordering, slice interleaving and data partitioning. Moreover, in order to prevent error propagation through inter prediction, H.264 provides mechanisms, such as redundant slice and spare macroblocks, which carry duplicate information to be used when an error in transmission occurs. It is relatively simple in its implementation. In addition, it attains enhanced compression performance and is therefore a ―network friendly‖ 156
standard. It is capable of providing good video quality at substantially lower bit rates than other standards‖ [100]. The Internet Protocol Television (IPTV) streaming used H.264 part 10 video codec. The streaming bit rate is usually IPTV = 1 Mbps for Standard Definition (SD) with 640x480, 24 fps, and IPTV = 8.6 - 10 Mbps for High Definition (HD) with resolution and frame rate 1920x1080, 30fps [104], [105], [106]. In addition, the overheads of various protocol layers are: RTP header size = 12 bytes, UDP header size = 8 bytes, IPv6 header size = 40 bytes, and MAC + PHY header size = 14 bytes. For IPTV, the author uses the H.264 Part 10 Advanced Video Coding standard with its scalable video coding extensions. The bandwidth required depends on the resolution, quality, and frame rate. It has selected the maximum payload bit rate; this is the bit rate that the network simulator endpoint will use for resolution at the maximum frame rate in support of this resolution. This value is interesting because it allows for the highest quality and frame rate video. The resolution and aspect ratio are 1920×1080 (16:9), and its maximum video payload bit rate is 4,000 kbps. For video traffic, the author adopted a standard video file, which is a foreman with Siemens logo. It contains 30 frames per second. The length of the video is about 30 seconds, so it repeats this video three times into one video file and converts it to a high definition of 1920×1080. Based on SVEF (Scalable Video-streaming Evaluation Framework), this module framework converts to NS-2 simulation environment. Therefore, users can evaluate their proposed network architectures or protocols for H.264 SVC more realistic transmission in NS-2. As stated by Ke, ―Users can start by encoding a raw YUV video with different encoding parameters (temporal encoding, spatial encoding,
157
SNR encoding, or combined encoding). After that, BitStreamExtractor (provided in JSVM) and F-N Stamp (provided in SVEF) are used to generate an original NALU Trace file.
This file is then converted to NS-2 send trace file via
prepare_sendtrace.awk (provided by C. H. Ke). In NS-2, an agent which is modified is used to read the converted NS-2 send trace file and generate the corresponding packets in the designated time. Users can design their network architectures or protocols in NS-2 and evaluate the performance of SVC transmission.
On the
receiver side, an agent sink which is modified is used to receive the SVC packets and record the related information, such as receiving time, packet size, frame number, and so on. This receiver trace file can be handled by Pe2edelay (provided by C. H. Ke) to calculate the packet level end-to-end delay or to calculate the packet loss rate. This receiver trace file is also handled by prepare_receivedtrace1.awk (provided by C. H. Ke) and prepare_receivedtrace2.exe (provided by C. H. Ke) to generate the needed file format required by SVEF. This processed file is then fed into NALU FILTER (provided by SVEF) to generate the Filtered NALU Trace. In this process, too late frames or frames that cannot be decoded are eliminated. Subsequently, the Filtered NALU Trace is sent to BitStreamExtractor (provided by JSVM) to generate the Filtered H.264 Video (Users can think that this file is corresponding to the real data gathered by the receiver side). Finally, this Filtered H.264 Video is decoded by a JSVM Decoder to generate the Filtered YUV Video‖ [127]. The NS-2 implementation of the above model includes several inter-operable modules, which are depicted separately in the following Figure 5-3 illustrating all the functional modules.
158
Figure 5-3 Model for Video Simulation in NS-2 [127]
5.4.3 Data in Traffic Loads DATA: as stated by Narravula, Lai, Subramoni, Mamidala and Panda, ―The File Transfer Protocol (FTP) was initially proposed to promote file sharing and the implicit use of remote computers. It is an application level protocol used to copy files between the local machine (user) and the remote machine (server) over the network, and fundamentally relies on the TCP/IP protocol. The typical FTP model includes control connection and data connection between the user and the server FTP processes for communicating the control commands and the data (file), respectively. The FTP server plays a passive role of listening on the specific port when started, and the user initiates a connection which may involve negotiation of authentication and
159
certification with the server. After that, control commands can be transferred over the connection. The data connections are established as needed for the data transfers‖ [107]. The FTP application used in this research is for the Internet large file transfer with TCP Westwood as the underlying transport protocol. The data segment size used is 512 bytes (i.e. 512 bytes payload + 40 bytes header + 20 bytes IPv6 header). The FTP server and client were also added to create background traffic and to utilize the free capacity of the network. The maximum bit rate of the FTP servers was regulated in the different scenarios to see how the amount of background traffic influences the QoS services. As stated by Caini et al., ―TCP Westwood was introduced for the purpose of limiting 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 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 version. The bandwidth is estimated by measuring and averaging the rate of returning ACKs. In particular, the reception of an ACK at the time
implies that an amount of data
has been received by the TCP receiver. Therefore, the
sample of bandwidth used by
a given connection is measured as
,
160
(5.2)
where
is the arrival time of the previous ACK. Finally, TCP Westwood makes
use of a discrete-time smoothing filter to perform the estimate of the available bandwidth; the value of the filtered available bandwidth
(
where
(
) (
at time
)(
, is given by
),
(5.3)
) depends on the inter-arrival time (
) which is variable, and
is the cut-off frequency of the filter. Then, after loss
detection, TCP Westwood sets the ssthresh and cwnd as follows:
,
{
.
(5.4)
Nevertheless, in case of ‗drop-tail‘ routers, where ‗bursty‘ traffic can be observed, such a bandwidth estimation method tends to over-estimate the connection fair share. To achieve high link utilization and, at the same time, guarantee friendliness, TCP Westwood implements a novel congestion control mechanism based on eligible rate estimation (RE) rather than bandwidth estimation‖ [128]. The summarized triple-play services over IPv6 parameters with standard codec are shown in Table 5-1.
161
Table 5-1 Simulated Traffic of Triple-play Services over IPv6 Traffic VoIP with G.711 IPTV with H.264/SVC FTP with TCP Westwood
Packet-size 220 Bytes 1540 Bytes 540 Bytes
5.5 Simulation Results In coherence to other research, the author implements a queue management technique to study the most usual type of hybrid satellite constellations based on the BHSCCS network topology for triple-play service applications. The simulations monitor the average queue length, queue bandwidth, and packet end-to-end delays over a period of 100 seconds. The load consists of a combination of VoIP G.711 codec, IPTV H.264/SVC, and FTP over TCP Westwood. The simulation results are obtained from different AQMs loadings such as BLUE, RED, DropTail and the proposed HSBQ, in which the loss rate ranges within 2%. Voice and video traffics are different in packet sizes.
However, their
performance in each AQMs is affected by packet end-to-end delays at packet rate in the same way as a predefined delay threshold. So, Figure 5-4 (DropTail), Figure 5-5 (RED), Figure 5-6 (BLUE), and Figure 5-7 (proposed HSBQ) show packet end-to-end delays of VoIP G.711 with two-way connections. The author also run simulations in comparison with other AQMs. The results show that RED suffers from continual instability of packet arrival time because it randomly drops packets in the queue due to the deterministic packet marking behavior. The proposed HSBQ queue has the lowest packet end-to-end delay compared to the BLUE and DropTail queues. That means that the propagation delay of VoIP G.711 with two-way connections from
162
source to destination for the proposal over a broadband hybrid satellite network is the lowest. It has shown the communication by voice is a rather smooth traffic voice because there are lower propagation delays in the end-to-end communication than with DropTail and BLUE queues.
Figure 5-4 VoIP G.711 – Two Way Connection with DropTail Queue
Figure 5-5 VoIP G.711 – Two Way Connection with RED Queue 163
Figure 5-6 VoIP G.711 – Two Way Connection with BLUE Queue
Figure 5-7 VoIP G.711 – Two Way Connection with HSBQ Queue
Figures 5-8 – 5-11 show the packet end-to-end delays of IPTV H.264/SVC with 1920×1080-pixel resolutions at 30 frames per second. The author also run simulations in comparison with other AQMs. The graphs show that the proposed
164
HSBQ queue has lower packet end-to-end delays than BLUE and DropTail queues, but it is higher than RED because RED has randomly dropped packets in its queue behavior. That means that the propagation delays from source to destination the proposed HSBQ queue over a broadband hybrid satellite network are the lowest. The proposed HSBQ queue has lower packet end-to-end delays than the BLUE and DropTail queues. That means that the propagation delays of IPTV H.264/SVC from source to destination the proposed HSBQ queue over a broadband hybrid satellite network are the lowest. It has been shown that the communication by IPTV has smoother voice traffic because there are lower than propagation delays in the end-toend communication than with DropTail and BLUE queues.
Figure 5-8 IPTV H.264/SVC - 1920×1080 @30fps with DropTail Queue
165
Figure 5-9 IPTV H.264/SVC - 1920×1080 @30fps with RED Queue
Figure 5-10 IPTV H.264/SVC - 1920×1080 @30fps with BLUE Queue
166
Figure 5-11 IPTV H.264/SVC - 1920×1080 @30fps with HSBQ Queue
As for Figures 5-12 – 5-15, the author has shown that the PSNR results to reflect the frame number of the video depending on each AQMs. The PSNR is an approximation to the human perception of the image reconstruction quality; however, a higher PSNR generally indicates that the reconstruction is of higher quality but in some image reconstruction attempts it may not be the case. The resultant PSNR values for IPTV in different AQMs from simulations using a foreman with Siemens logo are shown in Figures 5-12 - 5-15 respectively. Figures 5-12 – 5-15 of PSNR values of IPTV shows along the x-axis, the frame number of the videos that were received in the destination node. The DropTail queue had a lower frame number of the videos than other queues in the set of simulations, which means that the image reconstruction quality of the videos was lower. But the RED queue had the highest frame number of the videos among other queues in the set of simulations, which means that there was a high image
167
reconstruction quality. However the higher number of the RED queue does not prove smoother video frames as shown in Figure 5-18 of IPTV in different queues. Next, is the proposed HSBQ queue is showing a higher frame number of videos than the DropTail and BLUE queues. The smoother video frames resulting from the image reconstruction quality of the HSBQ queue is shown in Figure 5-20 of IPTV in different queues.
Figure 5-12 PSNR Values of IPTV with DropTail Queue
Figure 5-13 PSNR Values of IPTV with RED Queue 168
Figure 5-14 PSNR Values of IPTV with BLUE Queue
Figure 5-15 PSNR Values of IPTV with HSBQ Queue
As a result, the frame number 41 of video traffic is chosen to visually compare the performance for each AQM. Figure 5-16 shows the original frame number 41 of the source file at resolution 1920 × 1080 over codec H.264/SVC. Figure 5-17 - 5-20
169
show the results for the DropTail, RED, BLUE, and HSBQ queues, respectively. The illustrations show the smooth motion of the video. In this research, the DropTail and RED algorithms are suffering smooth IPTV H.264/SVC over the broadband hybrid satellite communication networks. On the contrary, the BLUE and HSBQ algorithms are very smooth. The proposed HSBQ queue has a lower number of dropped packets in the videos than the BLUE queue, and also the HSBQ queue has a greater frame number than the BLUE queue.
Figure 5-16 Frame no. 41 of the Original Source IPTV File
Figure 5-17 Frame no. 41 of the Source IPTV File with DropTail Queue 170
Figure 5-18 Frame no. 41 of the Source IPTV File with RED Queue
Figure 5-19 Frame no. 41 of the Source IPTV File with BLUE Queue
Figure 5-20 Frame no. 41 of the Source IPTV File with HSBQ Queue 171
In Figures 5-21 - 5-24, the queue bandwidth of triple-play service flows are presented. It is related queue length, and it should be matched up with queue length. These figures show that the proposed HSBQ queue has the lowest use of queue bandwidth in the simulated traffic networks. Therefore, more bandwidth in such hybrid satellite networks will be allocated for other applications.
Figure 5-21 Queue Bandwidth of DropTail Queue
172
Figure 5-22 Queue Bandwidth of RED Queue
Figure 5-23 Queue Bandwidth of BLUE Queue
173
Figure 5-24 Queue Bandwidth of HSBQ Queue
Figures 5-25 - 5-28 present the queue length with respect to time. These figures illustrate instantaneous queue length of the simulations with 400 KB buffer size in triple-play service traffic loads. In the proposed HSBQ queue, the queue length decreases to reduce the congestion and also reduces oscillatory behaviors. It is clearly shown that the proposed scheme effectively maintains queue length stability around the target queue length whereas the queue length in the BLUE queue oscillates more periodically when compared with the proposed HSBQ queue. When the RED queue is used, the queue length is too low, and it is easy for it to be empty, which causes underutilization. Using the DropTail queue results in almost full queue length during the entire of simulation and hardly increases over 400 KB. They vary the bottleneck queue length. This affects the simulations when the simulation parameters in triple-play service traffic loads are varied.
174
Figure 5-25 Queue Length of DropTail Queue
Figure 5-26 Queue Length of RED Queue
175
Figure 5-27 Queue Length of BLUE Queue
Figure 5-28 Queue Length of HSBQ Queue
176
CHAPTER 6 PERFORMANCE EVALUATION OF BHSCCS
In Chapter 3, BHSCCS networks have been proposed and in this Chapter the author extends the BHSCCS networks to improve the network performance of broadband hybrid satellite constellation communication systems is evaluated using TCP/IP, Queue, PER, and GridFTP. The proposed TCP design is done to provide a methodology for BHSCCS networks.
6.1 Performance Evaluation of Various TCP Protocols over BHSCCS As stated by Jamalipour et al. and Boriboon et al., ―Satellite communication technology systems have been an important element of telecommunications networks for many years serving, in particular, long distance telephony, data, and television broadcasting.
Therefore, satellite systems become increasingly competitive
commercially in service and growth. This is to give the service provider a capability to combine the best features of each to achieve the most cost effective system. An example is the involvement of satellites in Internet protocol (IP) networks which is a direct result of new trends in global telecommunications, where Internet traffic will hold a dominant share in the total network traffic. The Internet has been one the fastest growing technologies within the telecommunications industry in recent years and it is expected to continue as the most important technology for years to come. For the future generations of the Internet,
177
broadband access, and Quality of Services (QoS) are among the most significant issues to be solved‖ [129], [116]. The economics of the satellite environment has also created opportunities for data communication users. However, the protocols that govern data communications, both for data exchange and for error control, have largely been developed for connections that have different delays. Most applications may use the Internet‘s Transmission Control Protocol (TCP) which requires a reliable transport service over a packet-switched communication network. Matching applications that use TCP with the advantages offered by satellites is, therefore, important. It is natural to think of TCP-based applications over satellite networks because the widespread diffusion of TCP applications makes it difficult to think of another protocols architectures nontransparent to the user, dedicated to the satellite links. As stated by Jamalipour et al. and Boriboon et al., ―The round-trip delay and the general characteristics (e.g., fading, interference) of the links heavily affect the performance of the protocols at every functional level: physical and data link protocol; IP layer; transport and application protocols. Resource allocation and fading countermeasures are issues of particular importance in this environment. Different from cabled and terrestrial networks for personal communications, satellite channels characteristics vary depending on the weather and the effect of fading that heavily affects the performance of the access system and the whole system. So, the solutions concerning network architectures and each protocol layer which allow the efficient transport of TCP applications through satellite networks, transparently to the final user, should be the goal of Broadband Hybrid Satellite Constellation Communication System (BHSCCS) networks‖ [129], [116].
178
The analytical study of the performance of data communications protocols and applications in BHSCCS networks is often made very difficult by the complexity and time-varying nature of the network topology.
Therefore, it is helpful to study
simulation models of such systems. This research is an extended version of a paper that appeared in a previous research work [84] and contributes to previous findings in the development of the COMMStellationTM satellite system model in the network simulator NS-2. The author adopted [3] the TCP Tahoe, the TCP New Reno, the TCP Sack, and the TCP Vegas to evaluate the network performance over BHSCCS by a COMMStellationTM satellite model in NS-2.
6.1.1 Traffic Load: TCP in Satellite Environment As stated by Henderson et al., Boriboon et al., ―The Transmission Control Protocol (TCP) is important to the transport layers, thus it is a major transport protocol in the TCP/IP protocol suite.
Communication between sources and
destinations has a comparative round-trip time (RTT). This means that considerable time is needed in slowstart, on opening a new connection for TCP, to increase its throughput to what the link capacity will bear. After an error packet is inferred as lost due to congestion, 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 around the IP packet structure. The desire to utilize satellite capacity efficiently has led to the development of a number of optimized satellite TCP variants, with altered transmission control 179
behavior. These run between ground terminals across the satellite link, while other TCP implementations complete the E2E communication across the terrestrial Internet. The E2E TCP connections are made across the congested, but relative link error free terrestrial Internet and the less congested but more error prone satellite link is split into individual TCP connections tailored to each environment; this is easy to do with a FTP. Thus, the Transmission Control Protocol (TCP) provides a reliable, end-toend, streaming data service to applications. A transmitting TCP accepts data from an application in arbitrarily-sized chunks and packages it in variable length segments, each indexed by a sequence number, for transmission in IP datagrams. The TCP receiver responds to the successful reception of data by returning an acknowledgement to the sender, and by delivering the data to the receiving application; the transmitter can use these acknowledgments to determine if any segment requires retransmission.
If the sending side of the connection closes
normally, the sending application can be almost certain that the peer receiving application successfully received all of the data‖ [87], [86], [130]. The main characteristics of all TCP protocol variants which are analyzed in the computer simulations are further discussed. An overview is provided about their main mechanisms of operation action with basic discussions about their major features which affect the performance [124], [128], [131]. TCP Tahoe [132], [133] is the first implementation of TCP to involve a few new algorithms in early TCP implementations like Slow Start, Congestion Avoidance, and Fast Retransmit.
180
TCP New Reno [132], [133] includes a change to the Reno algorithm at the sender end with a view to eliminate Reno‘s wait for a retransmit time-out whenever multiple packets are lost from a window. This change modifies the sender‘s behavior during fast recovery. TCP Sack [132], [133] is an extension of Reno and New Reno. It intends to detect a multiple packet loss and retransmit more than one lost packet per round-triptime. TCP Vegas [132], [133] extends the Reno retransmission strategy, especially in the way the Fast Retransmit is handled with the congestion avoidance algorithm. Bulk data transfer within hybrid satellites has been an inescapable factor for the use of scientific data sets distributions, content replication, remote data backup, etc. Generally, the File Transfer Protocol (FTP) [134] is used for handling bulk data transfers. Figure 6-1 shows the TCP flow data transfer of packets into clients. The network consists of a queue model and an error model for a more realistic scenario. The author has used this figure to implement the simulation in a broadband hybrid satellite network model in a computer simulation.
Figure 6-1 A Basic Network Model 181
6.1.2 Broadband Hybrid Satellite Networks As stated by Jamalipour, Marchese, Cruickshank, Neale and Verma, ―Broadband
satellite
systems
have
been
an
important
component
of
telecommunications networks for many years serving, in particular, long distance telephony, data, and television broadcasting. The involvement of broadband satellite in Internet protocol (IP) networks is a direct result of new trends in global telecommunications, where Internet traffic will hold a dominant share in the total network traffic. The large geographical coverage of the satellite footprint and its unique broadcasting capabilities, as well as its high-capacity channel combined with readily available Ka-band spectrum will retain broadband satellite systems as an irreplaceable part of communications systems‖ [129]. COMMStellationTM [17] is adopted for implementation in this study part of Chapter 3. The COMMStellationTM group deploys and operates a constellation of 72 satellites plus spares ones divided into six polar, low Earth orbit (LEO) orbital planes at an altitude of 1,000 km designed to provide high-speed, global business communications. The key parameter concept for implementation into a network simulator is given in [86]. The COMMStellationTM will be capable of providing highspeed data communications for many applications. Some potential uses of this system for communications include a) Strategic communications for government, military, or corporations b) Special purpose low latency communications, and c) High bandwidth burst data transmission from remote sensors, ships, exploration vessels, sites. For more information, see the earlier description in Chapter 3. Figure 6-2 illustrates the network topology which uses in this study.
182
Figure 6-2 A Sample Network Topology in the Network Simulator
6.1.3 Performance Evaluation Criteria A general discussion of network performance evaluation criteria is provided below to clarify this part of the study. The performance of the BHSCCS on the COMMStellationTM satellite system can be measured in terms of throughput, dropped packets, end-to-end (E2E) delay, and jitter [7]. The
is defined in Eq. (6.1),
(
)
where: is the number of packets received at the destination, 183
,
(6.1)
is the packet size (bytes), is the stop time of each traffic flow, and is the start time of each traffic flow.
The
are given by Eq. (6.2),
( )
,
(6.2)
where: is the number of packets generated at the source, and is the number of packets received at the destination.
The
(
)
is defined in Eq. (6.3),
∑
Average
,
(6.3)
where: is the end-to-end delay of packet ―i‖
,
i is defined of packet unit uses extending real number system to a complex system, is the time of packet ―i‖ en-queued at the source, is the time of packet ―i‖ received at the destination, and is the number of packets received at the destination.
184
The
is defined in Eq. (6.4),
) (
( (
)
)
,
(6.4)
where: is the time of the packet sequence number en-queued at the source, is the time of the packet sequence number en-queued as received at the destination, is the current packet sequence number, and is the previous sequence number.
6.1.4 Simulation Results of Various TCP Protocols In this section, the author presents the simulation results. For the traffic simulation, the sources and the destinations are in a purely satellite-based connected network. Each user station has its own FTP service over different TCPs. The author considered three scenarios in testing the proposed scheme for different packet error rates (PER) of 2%, 4%, and 6%, respectively. It means that there are four selected protocols, each of which is tested with packet error rates of 2%, 4%, and 6%. It was found out that different TCP algorithms affect differently the performance over broadband hybrid satellite constellation communication system (BHSCCS) networks [116]. Regarding the network performance evaluation criteria of the computer simulations, the author compares the performance of the hybrid satellites which is computed by a throughput criterion. There are four different TCP services while FTP application is running such as the TCP Tahoe, the TCP New Reno, the TCP Sack, and 185
the TCP Vegas. Figures 6-3, 6-4, and 6-5 illustrate the throughput with PER of 2%, 4%, and 6%, respectively. The throughput shows that the TCP Vegas has the highest throughput when compared to other TCPs. However, when the satellite link has an error, TCP Vegas shows unstable throughput as presented in Figure 6-5. This figure shows the best stable variable length for TCP New Reno. Firstly, the throughput under a PER limit of 2% is 1.2130 Mbps, 1.5718 Mbps, 0.8767 Mbps, and 2.0557 Mbps (for TCP Tahoe, TCP New Reno, TCP Sack, and TCP Vegas, respectively). Secondly, the throughput under a PER limit of 4% is 0.8384 Mbps, 1.0081 Mbps, 0.5653 Mbps, and 1.1351 Mbps (for TCP Tahoe, TCP New Reno, TCP Sack, and TCP Vegas, respectively). Finally, the throughput under a PER limit of 6% is 0.6304 Mbps, 0.7485 Mbps, 0.4590 Mbps, and 0.8992 Mbps (for TCP Tahoe, TCP New Reno, TCP Sack, and TCP Vegas, respectively). The results show the throughput of various TCP protocols over BHSCCS networks. The average throughput depends on the performance of the algorithms in each protocol for the variable PER factor. The dropped packets for different network traffic are compared in Table 6-1, which is computed by Equation (6.2). Certainly, the dropped packets have are of importance for the evaluation of the mechanisms of various TCP modules. For instance, in this table there is a simulation with PER = 6%. The TCP protocols that had a percentage lower than 6% are the TCP Vegas, TCP Sack, and TCP New Reno. The TCP protocol that had the lowest dropped packets under PER = 2% is TCP New Reno, and TCP Vegas had the lowest dropped packets while PER = 4%. Therefore, the mechanism of each TCP has an effect on the dropped packets due to the different ways of retransmission of packets in the network traffic. The network performance evaluation criteria of the computer simulations are considered starting with the measurements of the end-to-end packet delays which are 186
computed in accordance with the previous section. The four distinct TCP protocols are analyzed for different PERs as shown in Figures 6-6, 6-7, and 6-8. The average end-to-end packet delays of TCP Tahoe are 2.9914 ms, 2.0895 ms, and 1.5548 ms, respectively for PER = 2%, 4%, and 6%. The TCP New Reno delays are 3.8862 ms, 2.4935 ms, and 1.8650 ms, respectively for PER = 2%, 4%, and 6%. The TCP Sack delays are 2.1674 ms, 1.3867 ms, and 1.1404 ms, respectively for PER = 2%, 4%, and 6%. The last protocol is TCP Vegas, and its delays are 5.2254 ms, 2.8647 ms, and 2.2693 ms, respectively for PER = 2%, 4%, and 6%. The average end-to-end packet delay depends on the performance of the algorithm in each protocol as a function of the variable PER factor.
Figure 6-3 Throughput with PER = 2%.
187
Figure 6-4 Throughput with PER = 4%.
Figure 6-5 Throughput with PER = 6%.
188
Figure 6-6 Measurement of the End-to-End Packet Delay with PER = 2%.
Figure 6-7 Measurement of the End-to-End Packet Delay with PER = 4%.
189
Figure 6-8 Measurement of the End-to-End Packet Delay with PER = 6%.
Table 6-1 Dropped Packets for Different Network Traffic (%) TCP Module
PER 2%
PER 4%
PER 6%
Tahoe
2.234
4.238
6.465
New Reno
1.913
4.004
5.905
Sack
2.060
4.104
5.581
Vegas
2.002
3.689
5.574
Table 6-2 Total Jitter Time during the Network Transmission (unit: ms) TCP Module
PER 2%
PER 4%
PER 6%
Tahoe
0.47523
0.46333
0.41204
New Reno
0.38954
0.38195
0.37466
Sack
0.36531
0.33497
0.30275
Vegas
0.32836
0.33610
0.29915
190
The obtained jitter values have also been compared. The computed jitter is defined in the previous section in Equation (6.4). The jitter is shown in Table 6-2 for different PERs and four TCP protocols. Table 6-2 shows the computed results of total jitter time from the beginning till the end of the simulation time. There are four protocols, and each protocol was tested for PER = 2%, 4%, and 6%, respectively. TCP Tahoe has a total jitter time of 0.47523 ms, 0.46333 ms, and 0.41204 ms for PER = 2%, 4%, and 6%, respectively. TCP New Reno has a total jitter time of 0.38954 ms, 0.38195 ms, and 0.37466 ms for PER = 2%, 4%, and 6%, respectively.
TCP Sack has a total jitter time of 0.36531
ms, 0.33497 ms, and 0.30275 ms for PER = 2%, 4%, and 6%, respectively. Finally, TCP Vegas has a total jitter time of 0.32836 ms, 0.33610, and 0.29915 ms for PER = 2%, 4%, and 6%, respectively. Before ending this section, the author compares the latency of the different TCPs and PERs to determine the main feature of the performance of the various TCPs. These results are shown in Figures 6-9, 6-10, and 6-11.
191
Figure 6-9 Total Latency with PER = 2%.
Figure 6-10 Total Latency with PER = 4%.
192
Figure 6-11 Total Latency with PER = 6%.
In this subsection, various TCP protocols over broadband hybrid satellite constellation communication system (BHSCCS) networks have been compared by using the network simulation tool (NS-2). Throughput, dropped packets, mean endto-end (E2E) delay, jitter, and latency for different types of traffic sources are considered as evaluation criteria. The performance evaluation of BHSCCS networks on the COMMStellationTM model in NS-2 was done with recent TCP protocol modules in NS-2. Finally, the author has evaluated the network performance of the distinct TCPs for different PERs. The simulation results give an expression of the most view points of the TCP protocols on BHSCCS networks.
193
6.2 Performance Evaluation of GridFTP over BHSCCS In coherence to other research, the author has implemented GridFTP to study high-speed broadband hybrid satellite constellations based on the BHSCCS network topology. In this section, the author gives some brief background information on the topics covering the performance evaluation of high performance data transfer in a grid environment [135].
6.2.1 Grid Environment Satellites are the only choice for long-haul wireless broadband global area network communication. Some countries with large and/or island geographic areas and/or hard-to-reach areas, such as China, India, Indonesia, are likely to benefit the most from broadband satellite communications.
There are substantial big data
Internet accesses by users. As stated by Subramoni, Lai, Kettimuthu and Panda, ―Ever-increasing demands in high-end computing and intensive data exchange, together with the cost effectiveness of high performance commodity systems, have led to massive deployment of computing and storage systems on a global scale. In such Grid-based scenarios, bulk data transfers within and across physically separate clusters or data centers have become an inescapable requirement for scientific data set distribution, content replication, remote data backup, and so forth. Generally, File Transfer Protocol (FTP) is used for handling bulk data transfers. Since the earliest FTP implementation based on TCP/IP, many efforts have been undertaken to improve and extend it.
GridFTP, designed specifically for high-bandwidth wide area
networks, has appeared as the most popular FTP implementation in the Grid environment. 194
On the other hand, high-performance interconnections such as InfiniBand and Gigabit Ethernet/iWARP are rapidly gaining momentum for designing high-end clusters and data centers. In addition to providing high bandwidth and low latency, they provide advanced features, such as zero-copy communication and Remote Direct Memory Access (RDMA), which enable the design of novel communication protocols and libraries. The recent introduction of IB WAN router allows us to extend these capabilities across multiple campuses or even across WAN distances‖ [134], [136]. Hence, it is most challenging to implement high performance data transfers in the Grid environment over a BHSCCS networks. For the future generations of the Internet, broadband hybrid satellite access and QoS are surrounded by the most significant issues to be solved.
6.2.2 GridFTP As stated by Boriboon et al., Subramoni et al. and Thulasidasan et al., ―GridFTP is a protocol extension of FTP and its existing extensions are used to manage large data transfers across computational grids. GridFTP adds useful new features to the FTP specification that include secure transfers, third-party managed transfers, parallel and striped data transfers (where data are partitioned across multiple nodes) and partial file transfers among others. Presently, they have been implemented as part of the GridFTP module of the Globus Toolkit v2.0. The term ―GridFTP‖ is used to refer to the protocol and the GridFTP family of tools that are distributed with the Globus Toolkit e.g., the GridFTP server, client tools and the client and control libraries.
195
GridFTP relies on TCP, the most widely used transport protocols for the Internet as well as computational grids.
Such grids are often characterized by
networks with large bandwidth-delay products (BDP).
Currently, however, the
default flow-control parameters in TCP are statically tuned to suit networks with small BDPs, and thus perform abysmally over today‘s grid networks with large BDPs. Tuning of buffer sizes is necessary for maximizing throughput with TCP. For any given connection, the optimal TCP buffer size is equal to the BDP of the connection.
Often, grid researchers manually tune the buffer sizes to keep the
network pipe full by using diagnostic tools to determine the round-trip time (RTT) and bandwidth of the connections. Such tools include ipef, nettimer, and nettest among others. Because all these tools require a certain level of expertise to install and use, they are often not used by application end users. GridFTP is a high-performance, secure, reliable extension of the standard FTP data transfer protocol, optimized for high-bandwidth, wide area networks.
The
Globus implementation of GridFTP provides a software suite optimized for a broad range of data access applications, including bulk file transfers and data extractions from complex storage systems. The following are some of the key advantages of GridFTP, which are a) Performance: enhanced performance through use of parallel streams and coordinated data transfers b) Security: PKI/X.509 and SSH-based Grid security c) Robustness: restart markers allowing interrupted transfers to restart with minimal delay overhead and d) Extensibility: easy-to-use OCRW interface to users and applications. In addition to GridFTP, to simulate bulk data transfers, the three major parameters defined for the GridFTP simulator are Bandwidth, Parallel, and Ratio.
196
The Bandwidth is used to set the total bandwidth of the satellite link. The Parallel is used to set the parallel GridFTP steams. It is set to 4. The Ratio is used to set the throughput ratio among the parallel streams. By default, it is set to 1:1:1:1, which means that each GridFTP stream will transmit packets at an equal speed‖ [135], [136], [137].
6.2.3 Traffic Scenarios Traffic analysis and modeling are integral parts of engineering broadband telecommunications networks, including broadband hybrid satellite network systems. The analysis is related to the evaluation of the statistical properties of the traffic and the creation of systematical solutions for evaluating the performance of the networks in terms of different measures such as packet delays. The author has also established the presence of self-similarity in many scenarios, which is important for predicting network behavior. The complexity and dynamics of hybrid satellite networks prevent the performance evaluation of the GridFTP algorithm using a high performance data transfer analytic expression. For testing and analyzing various different packet error rates, various different TCPs protocols, and various different queuing algorithms, the author has, therefore, developed the GridFTP simulation over a broadband hybrid satellite network as schematically illustrated in Figure 6-12. In conducted computer simulations, four user station links in different areas around Asia are chosen to observe their network traffic. The packet size of GridFTP is 1,514 bytes excluding the header size. The author run the simulation for 100 seconds for all scenarios, and
197
has a full run of GridFTP with a maximum number of user stations of both sources and destinations. As for the simulation based on the grid traffic model, the author is able to build a simulator using NS-2 to accurately replicate the characteristics of the applications under consideration. This simulator is useful in validating the network traffic models and is available publicly, so interested parties are able to evaluate different types of grid traffic in BHSCCS [86] networks.
Figure 6-12 Network Infrastructure for Global Area Bulk Data Transfer [135]
6.2.4 Simulation Results of GridFTP The simulations which are used to evaluate the efficiency of the GridFTP are based on the network performance evaluation criteria. They consist of TCP, Queue, and PER.
Each of them can specify TCP Tahoe, TCP New Reno, and TCP
Westwood. The AQM queue that is used in these simulations consists of DropTail, RED, and BLUE queues. Finally, PER should have a packet error from 1% to 10%, and all the entire whole is running on a BHSCCS system [135].
198
Throughput is the main performance measure characteristic, which is most widely used. It measures how soon the receiver is able to get a certain amount of data sent by the sender. It is determined as the ratio of the total data received to the endto-end delay. Throughput is sometimes different from goodput, because goodput consists solely of useful transmitted traffic, whereas a throughput may also include retransmitted traffic. Throughput is an important factor which directly impacts the network performance. The term throughput is defined in Equation (6.1). As stated by Boriboon and Pongpadpinit, ―End-to-End delay is the time elapsing while a packet travels from source to destination. The larger a value of delay, the more difficult it is for transport layer protocols to maintain high bandwidths. This characteristic can be specified in a number of different ways, including average delay, variance of delay (jitter), and delay bound‖ [135]. This study has found out that a principal reason for such high expectations from user stations is the amount of throughput for the provided simulation time. The total simulation time is 100 seconds. For the completed simulations, the throughput results are shown in Figures 6-13, 6-14, and 6-15 (DropTail, RED, and BLUE), respectively; these figures show the comparison of the TCP variants‘ performance. Each TCP variant has its own advantages or disadvantages. But in this study, the author will focus on the most balanced GridFTP for network performance tradeoffs in the BHSCSS scenario. The computer simulations allow the comparison of the throughput for different AQMs, TCPs, and PERs over time. The TCP scheme results show an average throughput performance. The throughputs in Figure 6-13 of the TCP Westwood case with the DropTail queue are the highest compared to TCP New Reno and TCP Tahoe
199
for any PER. However, the average throughput performance with the RED queue in Figure 6-14 is the lowest in all dimensions when compared with the DropTail queue and the BLUE queue as shown in Figure 6-15. Thus, the results from the analysis of the GridFTP application in the computer simulations show the highest average throughput with the BLUE queue with TCP Westwood for all PERs.
Figure 6-13 Throughput of GridFTP with the DropTail Queue over a BHSCCS
Figure 6-14 Throughput of GridFTP with the RED Queue over a BHSCCS 200
Figure 6-15 Throughput of GridFTP with the BLUE Queue over a BHSCCS
The total simulation time of this research is 100 seconds. It has 3 TCP flows which start at the beginning of the simulation. A comparison of the TCP variant‘s performance with different AQMs, and PERs, is illustrated in Figures 6-16, 6-17, and 6-18. The end-to-end delay is direct proportional to the throughput; it means the higher the throughput, the higher the end-to-end packet delay will be. The results below show the average end-to-end packet delay for different TCPs and PERs over the DropTail, RED, and BLUE queues, respectively. Figures 6-16 – 6-18 show that TCP Westwood has higher end-to-end packet delay than others protocols, but it also has the highest throughput as shown in Figure 6-16 – 6-18. Figures 6-16 – 6-18 show the network performance with respect to different PERs. The results are analyzed and a comparison of the graphs shows all the transmitted packets being received successfully, the throughput and end-to-end delay being much affected by the rapid change in queuing of the packets during a fast data transfer. The GridFTP packet 201
transmission has a positive impact on the throughput but a negative impact on the delay. In addition, an average end-to-end delay is calculated from the median point in increasing the errors in the scenario. It has counted the total number of packets that arrive at the destination and successfully transfer bulk data. And, the author has used the same method with the throughput for the median point, too.
Figure 6-16 Average E2E Delay of GridFTP with the DropTail Queue over a BHSCCS
202
Figure 6-17 Average E2E Delay of GridFTP with the RED Queue over a BHSCCS
Figure 6-18 Average E2E Delay of GridFTP with the BLUE Queue over a BHSCCS
203
6.3 Proposed TCP Protocol Module As stated by Boriboon and Pongpadpinit, ―Most satellite channels have the following characteristics such as a long propagation delay, great bandwidth asymmetry, and a high sporadic bit error rate. All these traits have a serious impact on the transmission performance of TCP satellite networks.
One of the most
interesting aspects of TCP is a mechanism for congestion control. Recall that in the Internet, a 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 delays 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. TCP Westwood was introduced for the purpose of limiting 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‖ [86], [21], [128], [138]. As stated by Boriboon and Pongpadpinit, ―The TCP section has proposed a new technique to improve the congestion window value after the connection setup in the transmission control protocol for suitable over satellite links. According to the simulation and analysis, the new protocol not only can increase the throughput for the
204
forward links, but also can greatly reduce the average end-to-end packet delay time rate of the link, compared with the traditional TCP protocols and transmission control protocol which have been proposed according to traits of satellite links in recent years‖ [86].
6.3.1 Slow Start Threshold and Congestion Window As stated by Boriboon et al. and Dukkipati et al., ―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 grows exponentially and increases in size until a 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 a slow start to enter the congestion avoidance phase‖ [86], [139]. As stated by Boriboon et al., Caini et al. and Liu et al., ―The aim of slow start algorithm is to probe the network to check the available capacity by gradually increasing the congestion window (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 the 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
205
packet is lost, which increases the congestion window [86], [128], [140], as shown below:
∑(
)(
) ,
(6.1)
where c is congestion window, w is initial window for that time, t is smaller recorded round-trip time estimate, and r is exponential averaging coefficient.
The pseudo-code of the algorithm is BEGIN Pseudo code for growing cwnd IF tcph-> seqno ( ) > last ack THEN recv newack helper (pkt) IF last ack = 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 CONSTRUCTOR hdr flags MEMBER access (pkt) -> eln AND eln THEN tcp eln (pkt)
206
IF dupacks + dupacks = numdupacks THEN dupack action ( ) END
From the pseudo-code, as well as in the congestion window (cwnd) in the TCP Westwood standard is, cwnd = initial window ( ). However, the SS strategy has replaced the old configuration in TCP Westwood protocol. Then, the author called it TCP Westwood-SS, and has modified it to increase the size of the congestion window itself. Thus, the size of cwnd in every update is cwnd = (cwnd + initial window ( )) * (smaller recorded rtt estimate + exponential averaging coefficient) * 0.5.
The
motivations for the protocol to calculate the new congestion window size in every update come from FAST TCP [141] and a slow start for high speed networks [142]. The procedure of the initial window in TCP Westwood is activated when a new connection is established with a host on the network. The congestion window is initialized to one segment. Each time an ACK is received, the congestion window is increased by one segment.
The sender 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 the procedure of the initial window for TCP Westwood is modified into TCP Westwood-SS, each time an ACK is received the congestion window is increased by its algorithm for the optimized segment. The author has selected TCP Westwood to improve the congestion window in wireless links, thus causing the oscillatory behaviour of TCP Westwood. It was made an unstable for large bandwidth delay.
The so-called TCP Westwood-SS makes the congestion 207
window stabilized or adjusted, based on the estimated attempt to stabilize it around a slow start threshold value. This approach eliminates the oscillation due to low E2E delay.
6.3.2 Simulation Results of Slow Start Threshold and Congestion Window In this section, the simulation results comparing TCP New Reno, TCP Westwood, and TCP Westwood-SS protocols [86] are presented. The author limits the simulation scope on score simulation to two error percentages, and one rigid practical error percentage [1]. The author takes an advantage of the current popular NS-2 network simulation software to do computer simulations according to the simulation topology of BHSCCS networks in a model where a user station connects to synchronous satellites through a trunk station.
As for the simulated traffic, the
sources and the destinations are in a purely satellite-based connected network. Each user station has FTP service over different TCPs.
The author focuses on and
considers two scenarios between Bangkok and Boston to test the scheme. In the first scenario, all user stations start and stop at the same time. In the second scenario, all user stations start, stop, and start at the same time. Then comes the performance evaluation in terms of congestion window (cwnd) and slow start threshold (ssthresh) in the TCP algorithms, which affect the performance over the non-geosynchronous Earth orbit satellite network. As a result, the TCP Westwood-SS protocol network performance evaluation criteria for the COMMStellationTM satellite system can be considered in terms of cwnd, ssthresh, and end-to-end (E2E) delays [7]. They are computed by the proposed TCP Westwood-SS protocol and also by the TCP Westwood, and TCP New Reno protocols. To assess the TCP probe gain and its
208
relation to the E2E propagation time, the author ran simulations with a propagation error.
Improvements in the coding on satellite links have altered the link error
characteristics to be in one of two states: either error free or extremely error. With a correctly dimensioned satellite link, one can assume that the satellite link has packet error rate (PER) equal to 2% as destination terrestrial link [124]. The window dynamics of TCP Westwood-SS, TCP Westwood, and TCP New Reno for all user stations which started to run simulations at the same time are presented in Figures 6-19, 6-20, and 6-21 below. The graphs show the improved window dynamics in each TCP‘s algorithm.
The cwnd and ssthresh values are
consistently higher than the corresponding values in other TCPs, thus yielding a decrease in the average E2E packet delay. Figures 6-19, 6-20, and 6-21 show that the behaviors of the TCP protocols are the same at the User Stations when a segment loss occurs due to network congestion. The behavior of the congestion window (cwnd) depends on RTT, when the TCP Westwood-SS sender detects a data segment loss and thus retransmits the lost segment, but the SS strategy does not decrease its congestion window, due to the slow start threshold. It can be shown that the packet sequence is continuous. Evidently, the SS strategy of TCP Westwood-SS can quickly increase the transmitter‘s congestion window.
209
Figure 6-19 TCP New Reno – Start Same Time Scenario
Figure 6-20 TCP Westwood – Start Same Time Scenario
Figure 6-21 TCP Westwood-SS – Start Same Time Scenario
210
The second scenario is that all user stations run start-stop-start at the same time to evaluate the window dynamics of TCP Westwood-SS, TCP Westwood, and TCP New Reno as presented in Figures 6-22, 6-23, and 6-24 below. The graphs show the start of the simulations at one second, the stop of the simulations at ten seconds, and the start of the simulations again at eleven seconds. These figures show the improved window dynamics in each TCP‘s algorithm. The cwnd and ssthresh values are consistently higher than the corresponding values in other TCPs, thus meaning that TCP Westwood-SS does not decrease its congestion window. It can be shown that the packet sequence is continuous. Figures 6-22, 6-23, and 6-24 show that the behaviors of the TCP protocol are the same: the user station has started, stopped, and stopped at the same time to react that a segment loss occurs due to network congestion.
Figure 6-22 TCP New Reno – Start Stop Same Time Scenario
211
Figure 6-23 TCP Westwood– Start Stop Same Time Scenario
Figure 6-24 TCP Westwood-SS – Start Stop Same Time Scenario
The receiver on either side of TCP session uses to keep track of how much data it has sent, which the acknowledged segment to inform the sending host the transmitted data was received successfully or to indicate some kind of error. Hence, to understand acknowledgement segments are used throughout, Figures 6-25 and 6-26 show the acknowledgement segments have been sent by the receiver.
212
Figure 6-25 ACKed – Start Same Time Scenario
Figure 6-26 ACKed – Start Stop Same Time Scenario
213
Figure 6-27 Average E2E Packet Delay for Start Same Time Scenario
Figure 6-28 Average E2E Packet Delay for Start Stop Same Time Scenario
214
The last results show the average end-to-end packet delay for each scenario in Figures 6-27 and 6-28. The results show that the TCP Westwood-SS has lower endto-end packet delay when compared with the TCP Westwood, but higher than TCP New Reno. Also, the average end-to-end packet delay for the TCP Westwood-SS is 51.47 ms, with 1,025 packets in the first scenario, for the TCP Westwood is 54.52 ms, with 1,035 packets and for the TCP New Reno is 41.36 ms, with 784 packets. For the second scenario, the TCP Westwood-SS has an average end-to-end packet delay of 49.86 ms, with 968 packets. With regard to the TCP Westwood is 50.68 ms, with 972 packets. The last protocol is the TCP New Reno, the delay is 36.84 ms, with 700 packets. The graphs in Figures 6-27 and 6-28 also show the corresponding values for the other TCPs in the list of the average end-to-end packet delay for each scenario. In other words, the TCP Westwood-SS has improved the windows dynamics value to smoothen the transmission of information and it is more continuance than the TCP Westwood. In this chapter of the study, the author proposed the implementation of a feasible topology within the COMMStellationTM constellation network using Network Simulator 2. A new congestion control scheme is evaluated, designed to improve the performance under sporadic losses in satellite networks. The TCP Westwood-SS has been thoroughly tested throughout the computer simulations. Code modifications are required for the implementation over TCP WestwoodSS as compared to the ones implemented in the transition from TCP New Reno to TCP Westwood. To improve the congestion window and slow start threshold in TCP Westwood-SS algorithms has an effect on performance to decrease the average endto-end packet delay over a low Earth orbit satellite network to reduce retransmissions. Because of the oscillatory behavior of TCP Westwood was making an unstable at 215
large bandwidth delay.
Even the modification 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 end-to-end packet delay. Therefore, in order to improve the network bandwidth utilization and to decrease the latency, the TCP Westwood-SS protocol is able to estimate the end-to-end available high speed bandwidth from the response information.
216
CHAPTER 7 CONCLUSION AND FUTURE RESEARCH
7.1 Research Contributions In this dissertation, the optimizing communication utility of a routing protocol for satellite IP networks has been developed for a broadband hybrid satellite constellation communication IP network system to support triple-play service applications with QoS requirements. Research contributions have been made in the following areas: 1. Integration of satellite constellation IP networks and the terrestrial Internet; 2. Presentation of the COMMStellationTM topology on a network simulator; 3. Routing in broadband hybrid satellite constellation communication system networks; 4. Queue management of triple-play services over broadband hybrid satellite constellation communication system networks; and 5. Performance evaluation of various TCP protocols and GridFTP over broadband hybrid satellite constellation communication system networks.
7.2 Integration of Satellite Constellation IP Networks with the Internet Satellite networks are regarded as important parts of future communications systems. Especially for global coverage, the satellite IP networks are integral parts of the global network structure because the satellite services can be provided over a wide 217
geographical area, including remote, rural, urban, and inaccessible terrains. The use of the IP-based satellite networks as a part of the Internet cannot be accomplished only by solving the routing problem of the satellite networks. To accomplish network layer integration of terrestrial and satellite IP networks, new users should easily be added to the system by simply installing satellite interfaces at customer premises. Broadband hybrid satellites over LEO constellation communication IP networks systems can act as a safety valve for high-speed global area networks (GANs). Fiber optic cables within the main land network will assist the routing of traffic through satellite channels. Hence, the proposed BHSCCS is similar GAN networks and can be connected to the rest of the world over hybrid satellite constellation IP networks, simply by installing small satellite interfaces. With these properties, satellite systems play a crucial role in the global Internet by supporting the payload of any application over IP-based networks. BHSCCS network integration of satellite networks and the terrestrial Internet are the key issues to support these services. Satellite operators are very significant for developing and scheme for architectures of broadband hybrid satellite IP network in the next generation which will use in transferring the scientific data and directional communications. The Optimizing Communication Utility of Routing Protocol for Satellite IP Network is able to provide communication services for satellite operator data delivery services.
7.3 Presentation of the COMMStellationTM Topology on NS-2 In Chapter 3 of this dissertation, the author has proposed implementation of a feasible topology within the COMMStellationTM constellation network on the network simulator 2 (NS 2.34) as the new model to be studied in this research. Snapshots of
218
the COMMStellationTM satellite constellation at a single time point are shown in Table 3-1. The table shows the satellite longitudes, latitudes, and planes for all 72 satellites in the constellation system. Figure 3-7 shows a COMMStellationTM satellite constellation layout represented by a NS-2 script. This figure shows the position of all constellation satellites around the globe of the COMMStellationTM model. Trunk Stations on Earth with their longitudes and latitudes are shown in Table 3-2. Figure 3-8 is concerned with the trunk station layout represented by a NS-2 script. This figure shows all trunk stations on the globe of the COMMStellationTM model. The Internet backbone layout is shown in Figure 3-9. Also, this research has presented the performance evaluation of BHSCCS network on the COMMStellationTM model in NS-2.
7.4 Routing in Broadband Hybrid Satellite Networks In Chapter 4, an optimizing communication routing metric protocol problem was considered in terms of graph theory, which maps multi-constraints parameters into one optimized parameter. It is feasible to add more parameters to this problem, such as link length, link delay, link loss, link utilization, and link lifetime. This results in the definition of a multi-constrained optimization problem (MCOP) problem, which has one constraint and more than one metric to be optimized. The author uses a dynamic approximation method according to the specific characteristics of hybrid satellites over LEO networks. The exact approximation parameter range is defined to reduce the computational complexity. A weighted graph model is used to analyze the QoS routing problem in hybrid satellites over LEO networks.
Based on the weighted graph model, the author 219
proposes a routing metric for the delivery of triple-play services over broadband satellite constellation networks. Then, the author proposes that the route algorithm computation rely on the definition of performance indicators called routing metrics. The metrics are the Endto-End Delay, Queuing Delay, Hop Count, Link Utilization, Link Error, Link Availability, Link Length, and Link Jitter.
However, in a BHSCCS network,
displaying link is dynamic nature for this orbital. These metrics are considered to design an efficient algorithm for this specific network environment. This contribution defines eight metrics for characterizing routes in hybrid satellite IP networks. This research introduces new architectural components to support advanced Internet protocol (IP) - oriented multimedia and the integration of satellite networks with triple-play services that simultaneously support VoIP, IPTV, and broadband data transfers.
These types of services are particularly suited to the next generation
satellite systems.
The simulation for routing is ORPHSN (Optimized Routing
Protocol for Hybrid Satellite Network) in the satellite constellation, showing that these metrics help improve the routing decisions for optimized triple-play services. The simulation results show that the performance of the proposed algorithm is better than other conventional algorithms. The ORPHSN algorithm was investigated with different routing metrics that impact the route computation in hybrid satellite networks. Specially, this study has presented computer simulation-based research comparing routing protocols for hybrid satellite systems with triple-play service applications for end-to-end QoS performance evaluation. The ORPHSN algorithm has lower transmission delay, which is most important for satellite links. Moreover, this study has found out that the ORPHSN algorithm has the most optimized end-toend QoS performance for triple-play service applications compared to previous 220
algorithms. In summary, the ORPHSN algorithm can influence the performance of the whole communication network and the overall quality of communication in the BHSCCS network.
7.5 Queue Management in Broadband Hybrid Satellite Networks In Chapter 5, a proposed queue system is shown to be coherent to other research. Hence, the author implementd a queue management technique to suit tripleplay service application traffic loads in a broadband hybrid satellite constellation communication system (BHSCCS). The triple-play services contain voice (G.711 codec – two way connection), video (H.264/SVC), and data (FTP over TCP Westwood). The proposed HSBQ algorithm is an example of an active queue management algorithm, based on congestion metrics and excluding from consideration the information flow, which is designed to avoid high packet loss rates and control stable stream queue. It addresses the problem of calculation of the drop probability for both queue length stability and bandwidth fairness.
The HSBQ algorithm drops the
packets before the queues overflow at the gateways, so the end nodes can respond to the congestion before such queue overflow. This algorithm uses the change in the average queue length to adjust the amount by which the mark (or drop) probability is changed. Moreover, it adjusts the queue weight, which is used to estimate the average queue length, based on the rate.
The performance of different active queue
management algorithms is evaluated in terms of drop ratio and average queue length per link. The results show that the HSBQ algorithm can maintain control over a stable stream queue better than a group of congestion metrics without an information
221
flow algorithm as the rate of the hybrid satellite network changes dramatically. For a sample video file, the HSBQ algorithm shows a smooth video and does not freeze frames. However, the HSBQ queue does not have a reduced queue length like the RED queue but it has a stable stream queue and low jitter in the queue system. The empirical evidence demonstrates that the use of the HSBQ algorithm offers a better quality of service than the traditional queue control mechanisms used in hybrid satellite networks.
7.6 Performance Evaluation of Various TCP Protocols and GridFTP over Broadband Hybrid Satellite Networks In this dissertation, the author has evaluated the network performance with various TCPs protocols, various typical AQMs, and various PERs over broadband hybrid satellite network systems. The author has made a performance evaluation of various TCP protocols over a broadband hybrid satellite constellation communication system (BHSCCS) such as TCP Tahoe, TCP New Reno, TCP Sack, and TCP Vegas that are adopted from a default VINT project. The criteria for network performance proved optimization of throughput, dropped packets, end-to-end delays, and jitter.
The simulation has
different PERs for different schemes to prove the networks. Also, the author has made a performance evaluation of high performance data transfers in grid environment over broadband hybrid satellite network systems. The developed GridFTP BHSCCS networks management mechanisms can optimize the Grid applications.
222
The captured network traffic data have been extensively analyzed and compared to known mathematical distributions to provide a significant new understanding of the characteristics of grid applications.
The author has also
established the presence of self-similarity in many scenarios, which is important to the prediction of the network behavior. After the TCP protocol performance had been evaluated, it showed a best result for TCP New Reno compared with TCP protocols in other groups, such as TCP Sack, TCP Vegas, and TCP Tahoe, which have a packet error rate range within 2%. Therefore, the author developed TCP Westwood-SS to introduce a new congestion control scheme improving the performance under sporadic losses in satellite networks.
The TCP Westwood-SS has been tested throughout the computer
simulations. The code modifications required to implement TCP Westwood-SS are comparable to the ones made in the transition from TCP New Reno to TCP Westwood. The improvement of the congestion window and slow start threshold in TCP Westwood-SS algorithms has affected the performance by decreasing the average end-to-end packet delays over the low Earth orbit satellite network and reducing the retransmissions. Therefore, in order to improve the network bandwidth utilization and decrease the latency, the TCP Westwood-SS protocol is able to estimate the end-to-end response information about the available high speed bandwidth. Thus, TCP Westwood-SS has better efficiency than TCP Westwood and TCP New Reno.
223
7.7 Future Research Directions Some possible future work within this scope is to develop load-balancing routing, which still is a challenging problem in hybrid satellite network system for both the academia and the industries.
This dissertation has not presented such
technique. A load-balancing technique with a combination of the characteristics of hybrid satellites over low Earth orbit constellations is considered promising, thus aiming at increasing the network performance and reducing the propagation delays over satellites. Also, the next generation networks are driving the emergence of complex communication networks, which have a highly dynamic behavior.
Hence, it is
essential to construct a dynamic network bandwidth for the behavior of dynamic users such as Internet service providers, military, governments, etc. So far, little work has been done in this area although some models, algorithms, and data structures for dynamic load-balancing routing in communication networks have been proposed [143], [144], [145]. Another issue which needs to be considered is the effect on link layer protocol performance from the jumbo frame packets over IPv4/IPv6 [146], [147] to support the huge data transfers from one to many. Designing a link layer to support such transfer is a challenge in hybrid satellites for the next generation networks. Finally, it is hoped that this dissertation will be beneficial to other researchers in the field of the broadband hybrid satellite constellation communication systems.
224
REFERENCES
[1]
L. Wood, Internetworking with Satellite Constellations, doctoral diss., University of Surrey, Guildford, United Kingdom, 2001.
[2]
Z. Luo, Routing and End-to-End Quality of Service in Satellite IP Networks, doctoral diss., University of Surrey, Guildford, United Kingdom, 2008.
[3]
K. Fall & K. Varadhan, The ns Manual (The VINT Project, A collaboration between researchers at UC Berkeley, LBL, USC/ISI, and Xerox PARC: 2009)
[4]
T. Ernst, MobiWan: A NS-2.1b6 simulation platform for Mobile IPv6 in Wide Area Networks, [World Wide Web page]. Available: http://www.inrialpes.fr / planete / pub / mobiwan (23 Jan 2010).
[5]
T. Sanguankotchakorn & P. Jaiton, Effect of Triangular Routing in Mixed IPv4/IPv6 Networks, Proc. 7th IEEE International Conf. on Networking (ICN’08), 2008, 357-362.
[6]
K. Nisar, A. M. Said & H. Hasbullah, Enhanced Performance of IPv6 Packet Transmission over VoIP Network, Proc. 2nd IEEE International Conf. on Computer Science and Information Technology (ICCSIT), 2009, 500-504.
[7]
T. Sanguankotchakorn & M. Somrobru, Performance Evaluation of IPv6/IPv4 Deployment over Dedicated Data Links, Proc. 5th IEEE International Conf. on Information, Communications and Signal Processing (ICICS 2005), 2005, 244-248.
225
[8]
M. Ali, L. Liang, Z. Sun & H. Cruickshank, Evaluation of Transport Protocols for SIP Signaling over IPv6 DVB-RCS Satellite Networks, Proc. 7th IEEE International Symposium on Wireless Communication Systems (ISWCS), 2010, 800-804.
[9]
M. M. Hassan & P. K. Hoong, Performance Simulation and Analysis of Video Transmission over Proxy Mobile IPv6 in a Micro mobility domain, Proc. International Conf. on Telecommunication Technology and Applications, 2011, 229-235.
[10]
W. Qu, Y. Qin, H. Zhou & H. Zhang, Simulation-based Performance Comparison of Video Transmission over MIPv6, FMIPv6, HMIPv6, and FHMIPv6, Proc. IET International Conf. on Wireless, Mobile and Multimedia Network (ICWMMN 2006), 2006, 1-4.
[11]
C. Chen, Advanced Routing Protocol for Satellite and Space Networks, doctoral diss., Georgia Institute of Technology, Atlanta, GA, 2005.
[12]
Ö. Korçak, Routing and Network Mobility Management in Next Generation Satellite Networks, doctoral diss., Boğaziçi University, Istanbul, Turkey, 2004.
[13]
J. Farserotu & R. Prasad, IP/ATM Mobile Satellite Networks (Norwood, MA: Artech House, 2001).
[14]
Y. He, Integrating LEO Satellite Constellations into Internet Backbone, doctoral diss., University of Pisa, Pisa, Italy, 2007.
[15]
Y. Zhang, Internetworking and Computing over Satellite Networks (Norwell, MA: Kluwer Academic Press, 2003).
226
[16]
T. R. Henderson & R. H. Katz, Network Simulation for LEO Satellite Networks, Proc. 18th AIAA International Communications Satellite Systems Conference (ICSSC), 2000, 1-11.
[17]
G. J. Wells & D. Cooper, COMMStellationTM Implementations for Northern Broadband Communications, Proc. 30th AIAA International Communications Satellite System Conference (ICSSC), 2012, 830-839.
[18]
R. Conte, Satellite Rural Telephone Network Design: A Methodology for Performance Optimization, doctoral diss., Virginia Polytechnic Institute and State University, Blacksburg, VA, USA, 2000.
[19]
C. Partidge & T. J. Shepard, TCP/IP Performance over Satellite Links, IEEE Journal Network, 11(5), 1997, 44-49.
[20]
L. S. Boon. (2010, December 30). IPv6 header. Serial Communication [online]. Available e-mail:
[email protected] (30 Dec 2010).
[21]
S. Mascolo, C. Casetti, M. Gerla, M. Y. Sanadidi & R. Wang, TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links, Proc. 7th ACM SIGMOBILE International Conf. on mobile computing and networking (MobiCom), 2001, 287-297.
[22]
Wikipedia, http://en.wikipedia.org / wiki / Internet_Protocol
[23]
National Electronics and Computer Technology Center (1986). Internet Protocol version 6 (IPv6) specification [RFC 2460]. [World Wide Web page]. Available: http://www.ipv6.nectec.or.th / rfc2460.txt (4 March 2008).
227
[24]
M. Ali, L. Liang, Z. Sun & H. Cruickshank, SIP Signaling and QoS for VoIP IPv6 DVB-RCS Satellite Networks, Proc. IEEE International Workshop on Satellite and Space Communications (IWSSC), 2009, 419-423.
[25]
M. Werner, A dynamic routing concept for ATM-based satellite personal communication
networks,
IEEE
Journal
on
Selected
Areas
in
Communications, 15(8), 1997, 1363-1648. [26]
V. Gounder, R. Prakash & H. Abu-Amara, Routing in LEO-based satellite networks, Wireless Communications and Systems, Emerging Technologies Symposium, 1999, 509-518.
[27]
R. Mauger & C. Rosenberg, QoS guarantees for multimedia services on a TDMA-based satellite network, IEEE Communication Magazine, 35(7), 1997, 56-65.
[28]
L. Wood, A. Clerget, I. Andrikopoulos, G. Pavlou, & W. Dabbous, IP routing issues in satellite constellation networks, International Journal of Satellite Communications and Networking, 19(1), 2001, 69-92.
[29]
E. Ekici, I. F. Akyildiz & M. D. Bender, A distributed routing algorithm for datagram traffic in LEO satellite networks, IEEE/ACM Transactions on Networking, 9(2), 2001, 134-147.
[30]
S. Bayhan, G. Gur & F. Alagoz, Adpative Routing Protocol for QoS TwoLayered Satellite IP Networks, Proc. 2nd International Workshop in Satellite and Space Communications, 2006, 63-67.
228
[31]
D. Dash, A. Durresi & R. Jain, Routing of VoIP Traffic in Multi-layered Satellite Networks, Proc. Performance and Control of Next-Generation Communications Networks, 2003, 65-75.
[32]
O. Ercetin, S. Krishnamurthy, S. Dao & L. Tassiulas, A predictive QoS routing scheme for broadband low Earth orbit satellite networks, Proc. 11th International
Symposium
on
Personal
Indoor
and
Mobile
Radio
Communications (PIMRC), 2000, 1064-1074. [33]
H. N. Nguyen & A. Jukan, An Approach to QoS-based Routing for Low Earth Orbit Satellite Networks, Proc. IEEE Global Telecommunication Conference (G
[34]
LOBECOM ’00), 2000, 1114-1118.
J. Chen & A. Jamalipour, An adaptive path routing scheme for satellite IP networks, International Journal of Communication Systems, 16(1), 2003, 521.
[35]
H. Uzunalioglu, Probabilistic routing protocol for low Earth orbit satellite networks, Proc. International Conf. on Communications (ICC), 1998, 89-93.
[36]
H. Uzunalioglu, I. F. Akyildiz, Y. Yesha & W. C. Yen, Footprint handover rerouting protocol for low Earth orbit satellite networks, Journal of Wireless Networks, 5(5), 1999, 327-337.
[37]
J. Sun & E. Modiano, Routing strategies for maximizing throughput in LEO satellite networks, IEEE Journal on Selected Areas in Communications, 22(2), 2004, 273-286.
229
[38]
T. R. Henderson & R. H. Katz, On distributed, geographic-based packet routing for LEO satellite networks, Proc. IEEE International Conf. on Global Telecommunications (GLOBECOM), 2000, 119-123.
[39]
E. Ekici, I. F. Akyildiz & M. D. Bender, Datagram routing algorithm for LEO satellite networks, Proc. 19th Annual Joint of the IEEE Conf. on Computer Communications Societies (INFOCOM), 2000, 500-508.
[40]
F. C. H. Lin & R. M. Keller, The Gradient Model Load Balancing Method, IEEE Transactions on Software Engineering, 13(1), 1987, 32-38.
[41]
H. S. Change & el al., FSA-based link assignment and routing in low-Earth orbit satellite networks, IEEE Transactions on Vehicular Technology, 47(3), 1988, 1037-1048.
[42]
E. Papapetrou & F. N. Pavlidou, Various Routing Techniques for non-GEO Satellite Constellations, Proc. International Conf. on Telecommunications (ICT), 2000, 1-5.
[43]
T. Taleb, D. Mashimo, A. Jamalipour, N. Kato & Y. Nemoto, Explicit Load Balancing Technique for NGEO Satellite IP Networks With On-Board Processing Capabilities, IEEE/ACM Transactions on Networking, 17(1), 2009, 281-293.
[44]
E. Sigel, B. Denby & S. L. Hegarat-Mascle, Application of ant colony optimization to adaptive routing in a LEO telecommunications satellite network, Annals of Telecommunications, 57(5), 2002, 520-539.
230
[45]
J. Lee & S. Kang, Satellite over satellite (SOS) network: a novel architecture for satellite network, Proc. 19th Annual Joint of the IEEE Conf. on Computer Communications Societies (INFOCOM), 2000, 315-321.
[46]
C. Chen & E. Ekici, A Routing Protocol for Hierarchical LEO/MEO Satellite IP Networks, Journal Wireless Networks – Special issue, 11(4), 2005, 507521.
[47]
D. S. Dash, A. Durresi & R. Jain, Routing of VoIP traffic in multi-layered Satellite Networks, Proc. of SPIE on Performance and Control of NextGeneration Communications Networks (SPIE), 2003, 65-75.
[48]
M. Mohorcic, A. Svigelj & G. Kandus, Traffic class dependent routing in ISL networks, IEEE Transactions on Aerospace and Electronic Systems, 40(4), 2004, 1160-1172.
[49]
S. L. Kota, Quality of Service for Broadband Satellite Internet – ATM and IP Services, doctoral diss., University of Oulu, Finland, 2002.
[50]
A. Donner & M. Berioli, MPLS-Based Satellite Constellation Networks, IEEE Journal on Selected Areas in Communications, 22(3), 2004, 438-448.
[51]
S. Deering & D. Cheriton, Multicast Routing in Datagram Internetworks and Extened LANs, ACM Transactions on Computer Systems, 8(2), 1990, 85-110.
[52]
J. Moy, Multicast Routing Extensions for OSPF, ACM Magazine Communications, 37(8), 1994, 61-67.
231
[53].
K. Chitra & G. Padamavathi, Classification and Performance of AQM-Based Schemes for Congestion Avoidance, International Journal of Computer Science and Information Security, 8(1), 2010, 331-340.
[54]
S. Floyd & V. Jacobson, Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, 1(4), 1993, 397-413.
[55]
B. Zheng & M. Atiquzzaman, DSRED: an active queue management scheme for next generation networks, Proc. 25th Annual IEEE Conference on Local Computer Networks (LCN 2000), 2000, 242-251.
[56]
J. Koo, B. Song, K. Chung, H. Lee & H. Kahng, MRED: a new approach to random early detection, Proc. 15th International Conference on Information Networking, 2001, 347-352.
[57]
S. Floyd, R. Gummadi & S. Shenker. Adaptive RED: An Algorithm for Increasing the Robustness of RED‘s Active Queue Management [online]. [World Wide Web page]. Available: http://citeseerx.ist.psu.edu / viewdoc / summary?doi=10.1.1.29.2841 (1 July 2014).
[58]
J. Sun, K. Ko, G. Chen, S. Chan & M. Zukerman, PD-RED: to improve the performance of RED, IEEE Communications Letters, 7(8), 2003, 406-408.
[59]
C. Wang, B. Li, T. Hou, K. Sohraby & Y. Lin, LRED: A Robust Active Queue Management Scheme Based on Packet Loss Ratio, Proc. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies (INFOCOM 2004), 2004, 12-23.
232
[60]
L. Hu & A. D. Kshemkalyani, HRED: a simple and efficient active queue management algorithm, Proc. 13th International Conference on Computer Communications and Networks (ICCCN 2004), 2004, 387-393.
[61]
Y. Xu, Z. Wang & H. Wang, ARED: a novel adaptive congestion controller, Proc. of 2005 International Conference on Machine Learning and Cybernetics, 2005, 708-714.
[62]
S. Suthaharan, Reduction of queue oscillation in the next generation Internet routers, Journal of Computer Communications, 30(18), 2007, 3881-3891.
[63]
S. Kunniyur & R. Srikant, Analysis and Design of an Adaptive Virtual Queue (AVQ) Algorithm for Active Queue Management, Proc. ACM SIGCOMM, 2001, 123-134.
[64]
S. S. Kunniyur & R. Srikant, An Adaptive Virtual Queue (AVQ) Algorithm for Active Queue Management, IEEE/ACM Transactions on Networking, 12(2), 2004, 286-299.
[65]
C. Long, B. Zhao, X. Guan & J. Yang, The Yellow active queue management algorithm, Journal of Computer Networks and ISDN Systems, 47(4), 2005, 525-550.
[66]
C. Long, B. Zhao & X. Guan, SAVQ: stabilized adaptive virtual queue management algorithm, IEEE Communications Letters, 9(1), 2005, 78-80.
[67]
Q. Yanping, L. Xiangze, L. Qi & J. Wei, A Stable Enhanced Adaptive Virtual Queue Management Algorithm for TCP Networks, Proc. IEEE International Conf. on Control and Automation (ICCA 2007), 2007, 360-365.
233
[68]
S. Athuraliya, S. H. Low, V. H. Li & Q. Yin, REM: Active Queue Management, IEEE Network: The Magazine of Global Internetworking, 15(3), 2001, 48-53.
[69]
X. Deng, S. Yi, G. Kesidis & C. R. Das, Stabilized virtual buffer (SVB) – an active queue management scheme for Internet quality-of-service, Proc. IEEE Global Telecommunications Conference (GLOBECOM ’02), 2002, 16281632.
[70]
W. Feng, K. Shin, D. Kandlur & D. Saha, The Blue Active Queue Management Algorithms, IEEE/ACM Transactions on Networking, 10(4), 2002, 513-528.
[71]
D. Lin & R. Morris, Dynamics of Random Early Detection, Proc. of the ACM SIGCOMM ’97 conference on Applications, technologies, architectures, and protocols for computer communication (SIGCOMM ’97), 1997, 127-137.
[72]
R. Pan, B. Prabhakar & K. Psounis, CHOKe – a stateless active queue management scheme for approximating fair bandwidth allocation, Proc. IEEE 19th Annual Joint Conference of the IEEE Computer and Communications Soieties (INFOCOM 2000), 2000, 942-951.
[73]
M. Claypool, R. Kinicki & M. Hartling, Active queue management for Web traffic, Proc. 2004 IEEE International Conf. on Performance, Computing, and Communications, 2004, 531-538.
[74]
S. Chen, Z. Zhou & B. Bensaou, Stochastic RED and Its Applications, Proc. IEEE International Conf. on Communications (ICC ’07), 2007, 6362-6367.
234
[75]
A. Kamra, S. Kapila, V. Khurana, V. Yadav, R. Shorey, H. Saran & S. Juneja. SFED: A Rate Control Based Active Queue Management Discipline [online]. [World Wide Web page]. Available: http://www.cse.iitd.ernet.in / ~srajeev / SFED.pdf (1 July 2014).
[76]
A. Kamra, H. Saran, S. Sen & R. Shorey, Fair adaptive bandwidth allocation: a rate control based active queue management discipline, Computer Networks Journal, 44(2), 2004, 135-152.
[77]
M. Agarwal, R. Gupta & V. Kargaonkar, Link utilization based AQM and its performance,
Proc.
IEEE
Global
Telecommunications
Conference
(GLOBECOM ’04), 2004, 713-718. [78]
W. Feng, D. D. Kandlur, D. Saha & K. G. Shin, Stochastic fair blue: a queue management algorithm for enforcing fairness, Proc. IEEE 20th Annual Joint Conference of the IEEE Computer and Communications Societies (INFOCOM 2001), 2001, 1520-1529.
[79]
T. J. Ott, T. V. Lakshman & L. H. Wong, SRED: stabilized RED, Proc. IEEE INFOCOM ’99. Eighteenth Annual Joint Conference of the IEEE Computer and Communications Societies, 1999, 1346-1355.
[80]
W. Feng, A. Kapadia & S. Thulasidasan, GREEN: Proactive Queue Management
over
a
Best-Effort
Network,
Proc.
IEEE
Global
Telecommunications Conference (GLOBECOM ’02), 2002, 1774-1778. [81]
L. Wood, SaVi: satellite constellation visualization, First Annual Centre for Communication Systems Research Symposium (CSSR), 2001, 1-2.
[82]
Savi, http://savi.sourceforge.net/ 235
[83]
J. Chung & M. Claypool, NS by Example, [World Wide Web Page]. Available: http://www.nile.wpi.edu / NS / (29 Jan 2010).
[84]
T. Issariyakul & E. Hossain, Introduction to Network Simulator NS2 (New York, NY: Springer, 2009).
[85]
G. J. Wells, D. Cooper, P. Sekhavat, S. Engleson, P. Takats, Y. Demers & A. H. Kwon, COMMStellationTM – A Low Latency Satellite Constellation for Broadband Communications, Proc. 30th AIAA International Communications Satellite System Conference (ICSSC), 2012, 858-871.
[86]
A. Boriboon & S. Pongpadpinit, The COMMStellationTM Satellite Constellation for Broadband Communication System Model in NS-2, International Journal of Communications, Network and System Sciences, 7(10), 2014, 430-439.
[87]
T. R. Henderson & R. H. Katz, Transport Protocols for Internet-Compatible Satellite Networks, IEEE Journal on Selected Areas of Communications, 17(2), 1999, 326-344.
[88]
A. Boriboon & S. Pongpadpinit, Optimized routing protocol for broadband hybrid satellite constellation communication IP network system, EURASIP Journal on Wireless Communications and Networking, 2016(1), 2016, 120130.
[89]
H. Tsunoda, K. Ohta, N. Kato & Y. Nemoto, Supporting IP/LEO Satellite Networks by Handover-Independent IP Mobility Management, IEEE Journal on Selected Areas in Communications, 22(2), 2004, 300-307.
236
[90]
D. Zhang, S. Liu & M. Yin, A Satellite Routing Algorithm Based on Optimization of Both Delay and Bandwidth, Proc. 7th IEEE International Conf. on Wireless Communications Networking and Mobile Computing (WiCOM), 2011, 1-4.
[91]
M. J. Neely, Dynamic Power Allocation and Routing for Satellite and Wireless Networks with Time Varying Channels, doctoral diss., Massachusetts Institute of Technology, United States of America, 2003.
[92]
L. L. Dai, Proactive Mobile Wireless Networks: An Infrastructureless Wireless Network Architecture for Delay-Sensitive Applications, doctoral diss., Massachusetts Institute of Technology, United States of America, 2008.
[93]
J. Lloret, J. R. Diaz, F. Boronat & M. Esteve, A Satellite Connections Approach Based on Spatial Footprints, Proc. 3rd IEEE International Symposium on Wireless Communications Systems (ISWCS ’06), 2006, 719723.
[94]
N. Courville, H. Bischl, E. Lutz, A. Svigelj, P. Chan, E. Papapetrou & R. Asorey-Cacheda, Hybrid Satellite/Terrestrial Networks: State of the Art and Future Perspectives, Proc. QShine 2007 Workshop: Satellite/Terrestrial Internetworking (IWSTI ‘07), 2007, 1-7.
[95]
L. Audah, Z. Sun & H. Cruickshank, End-to-End QoS Evaulations of IPDiffserv Network over LEO Satellite Constellation, Proc. 2nd International ICST Conf. on Personal Satellite Services (PSATS), 2010, 99-113.
237
[96]
T. R. Henderson & L. Wood (2000). ns-2 satellite plot scripts. [World Wide Web page]. Available: http://personal.ee.surrey.ac.uk / Personal / L.Wood / ns / sat-plot-scripts / (21 June 2010).
[97]
G. Fairhurst, A. Sathiaseelan, C. Baudoin & E.Callejo, Delivery of triple-play services over broadband satellite networks, IET Communications, 4(13), 2010, 1544-1555.
[98]
R. Yuan & W. Ruchuan, Multi-path QoS Routing Using Genetic Algorithm for LEO Satellite Networks, Chinese Journal of Electronics, 20(1), 2011, 1720.
[99]
C. Hoene, H. Karl & A. Wolisz, A Perceptual Quality Model for Adaptive VoIP Applications, Proc. International Symposium on Performance Evaluation of Computer and Telecommunication System (SPECTS’04), 2004, 1-11.
[100] G. P. Sotiropoulos D.K. Styliaras, E.A. Kosmatos, C.A. Papagianni, N.D. Tselikas, & I.S. Venieris, Triple Play Service Simulation and Packet Scheduling Performance Evaluation, Proc. IEEE International Conf. on Digital Telecommunications (ICDT’06), 2006, 54-59. [101] T. Kuo, Y. Lo & W. Chan, QoS Improvement for H.264 Video Transmission based on Structural Similarity, Proc. IEEE International Conf. on P2P, Parallel, Grid, Cloud and Internet Computing (3GPCIC), 2010, 85-89. [102] Scientific-Atlanta, Inc. (2005). MPEG-4 Part 10 AVC (H.264) Video Encoding.
[World
Wide
238
Web
page].
Available:
http://www.scientificatlanta.com / products / customers / white-papers / 7007887b.pdf (23 July 2013). [103] T. Wiegand & G. J. Sullivan, The H.264/AVC Video Coding Standard, IEEE Signal processing magazine, 24(2), 2007, 148-153. [104] I. Papapanagiotou & M Devetsikiotis, Aggregation Network Design Methodologies for Triple Play Services, Proc. 7th Consumer Communications and Networking Conference (CCNC), 2010, 1-5. [105] G. Gardikis & A. Kourtis, Using DVB-S2 adaptive coding and modulation for the provision of satellite triple play services, IEEE Communications Magazine, 46(12), 2008, 128-135. [106] P. J. Sims, A Study on Video Over IP and the Effects on FTTx Architectures, Proc. IEEE Globecom Workshops, 2007, 1-4. [107] S. Narravula, P. Lai, H. Subramoni, A. Mamidala & D. K. Panda. Designing Zero-Copy FTP Mechanisms to Achieve High Performance Data-Transfer over InfiniBand WAN. Technical Report OSU-CISRC-4/08-TR18 [online]. [World Wide Web page]. Available: http://www.cse.ohio-state.edu / ~subramon / Tech-Reports / ftp08-tr.pdf (15 Aug 2013). [108] P. Lai, H. Subramoni, S. Narravula, A. Mamidala & D. K. Panda, Designing Efficient FTP Mechanisms for High Performance Data-Transfer over InfiniBand, Proc. IEEE International Conf. on Parallel Processing (ICPP’09), 2009, 156-163. [109] Q. Huang, B. S. Yeo & P. Kong, A routing algorithm to provide end-to-end delay guarantee in low Earth orbit satellite networks, Proc. 56th IEEE 239
International Conf. on Vehicular Technology Conference (VTC 2004-Spring), 2004, 2911-2915. [110] W. Jiang & P. Zong, A Discrete-Time Traffic and Topology Adaptive Routing Algorithm
for
LEO
Satellite
Networks,
International
Journal
of
Communications Networks and System Sciences, 4(1), 2011, 42-52. [111] D. Yiltas, An Effective Routing Algorithm for Low Earth Orbit Satellite Networks, Journal of Electrical & Electronics Engineering, 8(1), 2008, 491502. [112] H. Cruz-Sanchez, L. Franck & L. Beylot, Routing metrics for store and forward satellite constellations, IET Communications, 4(13), 2010, 1563-1572. [113] S.A.M. Makki, N. Pissinou & P. Daroux, A New Routing Algorithm for Low Earth Orbit Satellite Networks, Proc. 10th IEEE International Conf. on Computer Communications and Networks (ICCCN), 2001, 555-561. [114] G. McMahon, R. Septiawan & S. Sugden, A Multiservice Traffic Allocation Model for LEO Satellite Communication Networks, IEEE Journal on Selected Areas in Communications, 22(3), 2004, 501-507. [115] Y. Jian, Z. Yuan & C. Zhigang, Reverse Detection Based QoS Routing Algorithm for LEO Satellite Constellation Networks, TSINGHUA SCIENCE AND TECHNOLOGY, 16(4), 2011, 358-363. [116] A. Boriboon & S. Pongpadpinit, Performance Evaluation of Various TCP Protocol over Broadband Hybrid Satellite Constellation Communication System, International Journal of Computer Science and Telecommunications, 5(12), 2014, 1-6. 240
[117] R. Sedgewick, Algorithms in C, Part 5 Graph Algorithms 3rd (Canada, Addison-Wesley, 2002). [118] E. Papapetrou & F. Pavlidou, Distributed Load-Aware Routing in LEO Satellite Networks, Proc. IEEE on Global Telecommunications Conference (GLOBECOM), 2008, 2946-2950. [119] Y. Ma, T. Zhang & J. Zhang, An AQM Algorithm for LEO Satellite Network, Proc. 4th IEEE International Symposium on Microwave, Antenna, Propagation, and EMC Technologies for wireless communications (MAPE), 2011, 615-618. [120] A. Boriboon & S. Pongpadpinit, The HSBQ Algorithm with Triple-play Serivces for Broadband Hybrid Satellite Constellation Communication System,
International
Journal
of
Advances
in
Telecommunications,
Electrotecnics, Signals and Systems, 5(2), 2016, 108-115. [121] A. Das, D. Dutta, A. Helmy, A. Goel & J. Heidemann, Low-state fairness: lower bounds and practical enforcement, Proc. IEEE 24th Annual Joint Conference of the IEEE Computer and Communications Societies, 2005, 2436-2446. [122] C. Joo, S. Bahk & S. S. Lumetta, A Hybrid Active Queue Management for Stability and Fast Adaptation, Journal of Communications and Networks, 8(1), 2006, 93-105. [123] J. Kim, H. Yoon & I. Yeom, Active Queue Management for Flow Fairness and Stable Queue Length, IEEE Transactions on Parallel and Distributed System, 22(4), 2011, 571-579. 241
[124] L. Wood, G. Pavlou & B. Evans, Effects on TCP of Routing Strategies in Satellite Constellations, IEEE Communications Magazine, 39(3), 2001, 172181. [125] W. Yasin & H. Ibrahim, Improving Triple Play Services Using Multi Protocol Label Switching Technology, Journal of Computer Science, 6(3), 2010, 269278. [126] A. Bacioccola, C. Cicconetti & G. Stea, User-level Performance Evaluation of VoIP Using ns-2, Proc. Of the 2nd International Conf. on Performance Evaluation Methodologies and Tools (ValueTools ’07), 2007, 20. [127] C. H. Ke, myEvalSVC: an Integrated Simulation Framework for Evaluation of H.264/SVC Transmission, KSII Transactions on Internet and Information Systems, 6(1), 2012, 379-394. [128] C. Caini, R. Firrincieli, M. Marchese, T. Cola, M. Luglio, C. Roseti, N. Celandroni & F. Potorti, Transport layer protocols and architectures for satellite networks, International Journal of Satellite Communications and Networking, 25(1), 2007, 1-26. [129] A. Jamalipour, M. Marchese, H. S. Cruickshank, J. Neale & S. N. Verma, Guest Editorial Broadband IP Networks via Satellites---Part I, IEEE Journal on Selected Areas in Communications, 22(2), 2004, 213-214. [130] T. R. Henderson, Networking over Next-Generation Satellite Systems, doctoral diss., University of California at Berkeley, Berkeley, CA, 1999.
242
[131] T. Mahmoodi, Transport Layer Performance Enhancements over Wireless Networks, doctoral diss., King‘s College London, University of London, London, England, 2009. [132] K. I. Oyeyinka, A. O. Oluwatope, A. T. Akinwale, O. Folorunso, G. A. Aderounmu & O. O. Abiona, TCP Window Based Congestion Control SlowStart Approach, Journal of Communications and Network, 3(2), 2011, 85-98. [133] M. Sarkar, K. K. Shukla & K. S. Dasgupta, Modified TCP Peach Protocol for Satellite based Networks, International Journal of Electronics and Electrial Engineering, 1(1), 2011, 1-19. [134] P. Lai, H. Subramoni, S. Narravula, A. Mamidala & D. K. Panda, Designing Efficient FTP Mechanisms for High Performance Data-Transfer over InfiniBand, Proc. IEEE International Conference on Parallel Processing (ICPP ’09), 2009, 156-163. [135] A. Boriboon & S. Pongpadpinit, Performance Evaluation of High Performance Data Transfer in Grid Environment over Broadband Hybrid Satellite Constellation Communication System, International Journal of Computer Science and Information Security, 14(6), 2016, 275-279. [136] H. Subramoni, P. Lai, R Kettimuthu & D. K. Panda, High Performance Data Transfer in Grid Environment Using GridFTP over InfiniBand, Proc. 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing (CCGrid), 2010, 557-564.
243
[137] S. Thulasidasan, W. Feng & M. K. Gardner, Optimizing GridFTP through Dynamic Right-Sizing, Proc. 12th IEEE International Symposium on High Performance Distributed Computing, 2003, 14-23. [138] L. Yu & G. Zhou, A New Transmission Control Protocol for Satellite Networks, International Journal of Communications, Network and System Sciences, 4(4), 2011, 256-265. [139] N. Dukkipati, T. Refice, Y. Cheng, J. Chu, T. Herbert, A. Agarwal, A. Jain & N. Sutin, An argument for increasing TCP‘s initial congestion window, ACM SIGCOMM Computer Communication Review, 40(3), 2010, 26-33. [140] D. Q. Liu & W. J Baptiste, On Approaches to Congestion Control over Wireless Networks, International Journal of Communications, Network and System Sciences, 2(3), 2009, 222-228. [141] C. Jin, D. Wei, S. Low, J. Bunn, H. Choe, J. Doyle, H. Newman, S. Ravot & S. Singh, FAST TCP: From Theory to Experiments, IEEE Network, 19(1), 2005, 4-11. [142]. D. Cavendish, K. Kumazoe, M. Tsuru, Y. Oie & M. Gerla, CapStart: A Path Capacity Adaptive TCP Slow Start for High Speed Networks, Proc. 1st IEEE Conf. on Evolving Internet (INTERNET ’09), 2009, 15-20. [143] J. Zhu, Y. Rao, L. Fu, W. Chen & X. Shao, Load Balancing Routing Based on Agent for Polar-orbit LEO Satellite Networks, Journal of Information & Computational Science, 9(5), 2012, 1373-1384. [144] J. Yuan, P. Chen & Q. Liu, A Load-Balanced On-Demand Routing for LEO Satellite Networks, Journal of Networks, 9(12), 2014, 3305-3312. 244
[145] Y. Rao & R. Wang, Agent-based load balancing routing for LEO satellite networks, Computer Networks: The International Journal of Computer and Telecommunications Networking, 54(17), 2010, 3187-3195. [146] S. Narayan & P. R. Lutui, Impact on network performance of jumbo-frames on IPv4/IPv6 network infrastructure: An empirical test-bed analysis, Proc. 2010 IEEE 4th International Conf. on Internet Multimedia Services Architecture and Application (IMSAA), 2010, 1-4. [147] A. Das & S. Debbarma, Performance of Jumbo Sized Data on Jumbo Frame and Ethernet Frame Using UDP over IPv4/IPv6, Proc. 2013 2nd International Conf. on Advanced Computing Networking and Security (ADCONS), 2013, 204-207.
245
VITA
Anupon Boriboon was born in Saraburi, Thailand. He received a Bachelor of Business Administration degree in Business Computer from the School of Business Administration, Bangkok University, in 2002, and a Master of Science degree in Telecommunications and Computer Networks from the College of Engineering, Rangsit University, in 2006, respectively. He attended the doctoral degree program in Telecommunications Science (Ph.D. TS), study plan A (pure research) at Vincent Mary School of Science and Technology, Assumption University of Thailand, from December 2010 to December 2016. At the same time, he was an industry consultant in the Information and Communication Technology field. He was also Business Development, Computer Specialist, and Network Administrator Specialist in the computer industry.
Also, he had been a Wireless Trainer (regional) in the
telecommunication industry. He published a peer-reviewed article in an International Journal as a part of the doctoral degree graduation requirements. He received a Doctor of Philosophy degree in Telecommunications Science from Assumption University of Thailand in December 2016.
246
APPENDIX A: List of Publications
This research includes 5 research papers describing research results at a higher layer of the network. The topic includes system architecture, system management, quality of service, queue, routing, and transport protocol techniques. A. Boriboon & S. Pongpadpinit, The COMMStellationTM Satellite Constellation for Broadband Communication System Model in NS-2, International Journal of Communications, Network and System Sciences, 7(10), 2014, 430-439. A. Boriboon & S. Pongpadpinit, Performance Evaluation of Various TCP Protocol over Broadband Hybrid Satellite Constellation Communication System, International Journal of Computer Science and Telecommunications, 5(12), 2014, 1-6. A. Boriboon & S. Pongpadpinit, Optimized Routing Protocol for Broadband Hybrid Satellite Constellation Communication IP Network System, EURASIP Journal on Wireless Communications and Networking, 2016(1), 2016, 120-130. A. Boriboon & S. Pongpadpinit, The HSBQ Algorithm with Triple-play Serivces for
Broadband
Hybrid
Satellite
Constellation
Communication
System,
International Journal of Advances in Telecommunications, Electrotecnics, Signals and Systems, 5(2), 2016, 108-115. A. Boriboon & S. Pongpadpinit, Performance Evaluation of High Performance Data Transfer in Grid Environment over Broadband Hybrid Satellite Constellation Communication System, International Journal of Computer Science and Information Security, 14(6), 2016, 275-279.
The author hopes that the readers will find it interesting and consider it as a useful guide to researching and development of activities with respect to realization of the global satellite system. The author is confident that many of the papers included in this dissertation will become long-term references for future works in this emerging field. 247
APPENDIX B: Comparison of Differences between Costs in Each Metric
The cost values in each metric are maintained at 100 as shown in the Table A1, which is the highest value of it, according to the calculation which is used in Chapter 4. It has demonstrated the result in Figure 4-10, as path delay versus allowed route length. Then, the author has demonstrated them again below.
Table A-1 Sample Routing Path
248
Figure A-1 End-to-End Delay versus Allowed Route Length
Therefore, to get rid of the concern about cost values in each metric, the author demonstrated the results of cost value either more or less in each metric, which are already added together and divided with the maximum cost. The values in the results are not higher than 1, which is not significant. In the Table A-3, A-4, and A-5 as shown below, the cost values in each metric is maintained in the highest value at 200. Each Table of cost values in each metric is maintained with a highest value of 50, and then each table of cost values in each metric maintains different values, respectively. The result is demonstrated in Figure 4-10 as shown in the Figure A-1, as end-to-end delay versus allowed route length.
249
Table A-2 Comparison of Differences in Each Metrics Cost
Table A-3 Each Metric Has Maximum Cost of 200
250
Table A-4 Each Metric Has Maximum Cost of 50
Table A-5 Each Metric has Different Maximum Costs
251
Figure A-2 End-to-End Delay versus Allowed Route Length
The comparison in the Table A-2, which has shown the difference between the costs in each metric, represents high or low levels of cost values in the scale of each metric, which is not causing any difference in calculating the Linkcost because the equation will add the highest cost values in each metric to be the base number. And each metric will calculate the values in each path Equations (4.8), (4.16), (4.19), (4.18), and (4.20). The next step is taking the results to compare the cost values in the table of each metric. One can add all the results of the cost values in each metric gives the total cost value by Equation (4.21). The final step is dividing the total cost value with the cost base number, and the result should not be higher than 1.
252
Next, the author had a modification to the scale of the cost values table in each metric to be narrower and more frequent. It is demonstrated in the Table A-6 and Table A-7 below, which demonstrates in the results of cost values either more or less in each metric after adding them together and dividing them with the maximum cost. It is not significant because the values in the results are not higher than 1.
Table A-6 Mapping Table of Cost to be More Frequent and Narrower
+ Table A-7 Sample Routing Path
253
Figure A-3 End-to-End Delay versus Allowed Route Length
However, the cost is modified to be more frequent and narrower as shown in Table A-6, which is not causing any difference in the path selection of the ORPHSN algorithm because each metric maintains the same calculation format by Equations (4.8), (4.16), (4.19), (4.18), and (4.20). Therefore, the cost in each metric yields a similar result as shown in the Table A-7. Hence, one can add all the cost values in each metric, and divide the results by the base number to retain every total cost of each path in the network system, making them equal to 1 or below as shown in the Figure A-3.
254
