PERFORMANCE CHARACTERIZATION OF
ROBUST HEADER COMPRESSION (ROHC) OVER
SATELLITE BASED UNIDIRECTIONAL LINK
(UDL)
ANG WAY CHUANG
UNIVERSITI SAINS MALAYSIA
2011
PERFORMANCE CHARACTERIZATION OF
ROBUST HEADER COMPRESSION (ROHC) OVER
SATELLITE BASED UNIDIRECTIONAL LINK
(UDL)
by
ANG WAY CHUANG
Thesis submitted in fulfilment of the requirements
for the degree of
Master of Science
ACKNOWLEDGEMENTS
I would like to extend my deepest gratitude to my supervisor, Dr. Wan Tat Chee, for his invaluable guidance. His intelligence, wisdom and patience command my deep respect.
My research would not persist without the companionship from my former and present colleagues, especially Teh Chee Hong, Chong Han Boon, and Yeong Shoa Yei. I can only imagine the burden of work load without their assistance.
I feel indebted to Imran Sarwar and Chong Yung Wei for their assistance and support in the development of the ROHC library. Their willingness to sacrifice their personal time to offload some of my work was beyond their call of duty.
The assistance provided by Kunalan and his NSST team is not taken for granted. I would like to thank the NSST team for their technical support.
I would also like to thank the AI3 project and staffs from Keio University especially Pak Achmad Basuki, Kotaro Kataoka, Pak Achmad Husni Thamrin, Haruhito Watanabe and Pak Dikshie. They were great hosts during my research internships in Japan and continue to be a great source of help when I stumble upon networking problem.
Implementation of the ROHC library presented in this thesis was initially based on the source code available at rohc.sourceforge.net. I would like to thank all programmers who contributed to that project.
Last but not least, I would like to thank my parents for being supportive throughout these years. Without them, none of these would have happened.
TABLE OF CONTENTS
Acknowledgements. . . ii
Table of Contents . . . iii
List of Tables . . . vii
List of Figures . . . viii
List of Abbreviations . . . xiii
Abstrak . . . xvi Abstract . . . xviii CHAPTER 1 – INTRODUCTION 1.1 Overview . . . 1 1.2 Problem Statement . . . 2 1.3 Research Objectives . . . 3 1.4 Scope of Research . . . 3
1.5 Outline of the Thesis . . . 4
CHAPTER 2 – LITERATURE REVIEW 2.1 Satellite Communication System . . . 6
2.2 Satellite Network Topologies. . . 7
2.2.1 Star Topology . . . 7
2.2.2 Point-to-Multipoint Mesh Topology . . . 8
2.3 IP over DVB-S . . . 9
2.3.1 Digital Video Broadcasting - Satellite (DVB-S) . . . 9
2.4 Frame Format . . . 10
2.4.1 Packing versus Padding . . . 11
2.4.2 Multiprotocol Encapsulation (MPE) . . . 12
2.4.4 DVB-S2 and GSE . . . 13
2.5 Header Compression . . . 15
2.6 Earlier Works on Header Compression Schemes. . . 16
2.6.1 Van Jacobson Header Compression (VJHC) . . . 16
2.6.2 IP Header Compression (IPHC) . . . 17
2.6.3 Compressed Realtime Transport Protocol (CRTP). . . 18
2.7 RObust Header Compression (ROHC). . . 18
2.7.1 Profile, Context and ROHC Versions . . . 19
2.7.2 Compressor States . . . 21
2.7.3 Decompressor States . . . 22
2.7.4 Modes . . . 23
2.7.5 Encoding Methods . . . 25
2.7.5(a) Least Significant Bits (LSB) . . . 25
2.7.5(b) Window-based Least Significant Bits (WLSB) . . . 27
2.7.5(c) Scaled RTP Timestamp Encoding . . . 28
2.7.5(d) Offset IP-ID Encoding. . . 29
2.7.5(e) Self-Describing Variable Length (SDVL) . . . 29
2.8 Justifications . . . 30
2.9 Summary . . . 30
CHAPTER 3 – SYSTEM ARCHITECTURE AND DESIGN 3.1 Introduction . . . 32
3.2 Overview of the System . . . 32
3.3 Design of the Packet Delivery System . . . 36
3.3.1 Padding Mode . . . 37
3.3.2 Packing Mode . . . 39
3.4 Design of ROHC Compressor . . . 41
3.5.1 Decoding of IR Packet . . . 48
3.5.2 Decoding of IR-DYN Packet . . . 50
3.5.3 Tasks Common to the Decoding of IR and IR-DYN Packets. . . 52
3.5.4 Decoding of Non-IR State Packet. . . 53
3.6 Summary . . . 56
CHAPTER 4 – EXPERIMENTAL DESIGN 4.1 Introduction . . . 57
4.2 Physical Environment . . . 57
4.3 Synthetic Testsuite . . . 58
4.4 Parameters . . . 60
4.4.1 System Parameters. . . 60
4.4.2 Parameters of ULE Encapsulator . . . 61
4.4.3 Parameters of ROHC Compressor and Decompressor . . . 62
4.5 RTP Benchmarking . . . 62
4.6 Summary . . . 67
CHAPTER 5 – RESULTS AND DISCUSSIONS 5.1 Introduction . . . 68
5.2 Average Length of Compressed Header . . . 68
5.3 Packing Thresholds . . . 72
5.4 Ideal (error free) Links . . . 77
5.4.1 UDP Tests . . . 77
5.4.2 RTP Tests . . . 81
5.5 Error Prone Satellite Links . . . 90
5.5.1 Impact of Refresh Intervals . . . 90
5.5.2 UDP Tests . . . 94
5.6 Summary . . . 107
CHAPTER 6 – CONCLUSION 6.1 Introduction . . . 110
6.2 Research Contributions . . . 110
6.3 Limitations of the Current System . . . 112
6.4 Future Work . . . 113
References . . . 115
APPENDICES . . . 118
APPENDIX A – GENERAL FORMAT OF ROHC PACKET . . . 119
APPENDIX B – SOCKET BUFFER AND ROHC BUFFER . . . 120
APPENDIX C – DATA STRUCTURE OF WLSB . . . 122
C.0.1 WLSB . . . 122
APPENDIX D – MAIN DATA STRUCTURES OF COMPRESSOR . . . 125
APPENDIX E – MAIN DATA STRUCTURES OF DECOMPRESSOR . . . 129
APPENDIX F – BUILDING UNCOMPRESSED HEADERS. . . 132
APPENDIX G – CRC COMPUTATION OF ROHC . . . 134
APPENDIX H – SOURCE CODE LISTINGS . . . 136
LIST OF TABLES
Page
Table 2.1 ROHC profiles (IANA, 2008) 20
Table 2.2 Self-describing variable length 30
Table 4.1 Average interarrival time and jitter of RTP streams over 100Mbps
Ethernet link 67
Table 5.1 Estimated number of parallel compressed RTP streams and observed
results 83
Table 5.2 Average interarrival time and jitter of RTP streams over DVB-S testbed 85 Table 5.3 Maximum number of RTP streams sustained on an ideal 8 Mbps
DVB-S link using refresh interval of 100 packets 105
Table 5.4 Percentage increase on the number of sustainable VoIP streams using
various compression profiles 107
Table 5.5 Highest data throughput gains of UDP streams using various
compression profiles 108
Table 5.6 Highest data throughput gains of UDP streams using various
LIST OF FIGURES
Page
Figure 2.1 Star configuration satellite network 7
Figure 2.2 Point-to-multipoint mesh satellite network 8
Figure 2.3 Structure of a MPEG2-TS frame 10
Figure 2.4 Packing multiple data packets into MPEG2-TS frames 11
Figure 2.5 Data framing with padding for MPEG2-TS frames 12
Figure 2.6 ULE packet format 13
Figure 2.7 Encapsulation of network packet within DVB-S2 stack using GSE 14 Figure 2.8 Delta encoding used by VJHC decompresses incorrectly when packet
loss occurs 16
Figure 2.9 Twice algorithm applies twice the delta to correct the decompression
when checksum fails 17
Figure 2.10 General format of IR packet (Jonsson et al., 2007) 21
Figure 2.11 ROHC compressor states (Borman et al., 2001) 21
Figure 2.12 ROHCv1 decompressor states (Borman et al., 2001) 23
Figure 2.13 ROHCv2 decompressor states (Pelletier and Sandlund, 2008) 24
Figure 2.14 Mode transitions (Borman et al., 2001) 25
Figure 2.15 Interpretation interval of a reference value using Least Significant
Bits encoding (Pelletier and Sandlund, 2008) 26
Figure 2.16 Interpretation intervals of various reference values required to be
inclusive of value of interest 27
Figure 3.1 A UDL mesh network consisting of three sites 32
Figure 3.2 Hardware configuration of a site 33
Figure 3.3 Software stacks on a UDL gateway 34
Figure 3.4 Detailed software components and its interaction with traffic 34 Figure 3.5 Format of a bridged frame ULE SNDU with ROHC compressed packet 35
Figure 3.7 Process flow when packet is received from the tun/tap network interface 38
Figure 3.8 Process flow of ULE packing mode 39
Figure 3.9 Computation of timeout value for ULE packing mode 40
Figure 3.10 Flowchart of ROHC compressor framework 42
Figure 3.11 Flowchart of header compression 44
Figure 3.12 Flowchart of ROHC Decompressor Framework 46
Figure 3.13 Flowchart of CID decoding 47
Figure 3.14 Flowchart of decompression of IR packet 49
Figure 3.15 Flowchart of decompression of IR-DYN packet 51
Figure 3.16 Steps common to IR and IR-DYN packets 52
Figure 3.17 Flowchart of decompression of non-IR state packets 54
Figure 4.1 Configuration of DVB-S testbed used for the experiment 58
Figure 4.2 Components in synthetic testsuite 59
Figure 4.3 Components of rtpfaker 63
Figure 5.1 Average compressed header length using IP profile for IPv4 and IPv6
traffic 69
Figure 5.2 Average compressed header length using UDP profile for UDP/IPv4
and UDP/IPv6 traffic 69
Figure 5.3 Average compressed header length using RTP profile for
RTP/UDP/IPv4 and RTP/UDP/IPv6 traffic 70
Figure 5.4 Average compressed header length for IPv4 stream using NS-2
simulation 71
Figure 5.5 Normalized data throughput of UDP/IPv4 stream with different
payload sizes over various packing thresholds 72
Figure 5.6 Comparison of average round trip time experienced by between
compressed and uncompressed streams over UDL mesh testbed 74 Figure 5.7 Measured transmission and processing round trip time over UDL
mesh testbed (excluding the propagation delay over geostationary
Figure 5.8 Comparison of normalized data throughput of compressed and uncompressed UDP streams with different payload sizes in padding
mode 76
Figure 5.9 Comparison of normalized data throughput of compressed UDP stream in padding mode and uncompressed UDP stream in packing
mode 76
Figure 5.10 Comparison of normalized data throughput of compressed IPv4/UDP
streams 78
Figure 5.11 Comparison of data throughput gain of compressed IPv4/UDP streams against uncompressed IPv4/UDP streams at different UDP
payload sizes 79
Figure 5.12 Comparison of normalized data throughput of compressed IPv6/UDP streams against uncompressed IPv6/UDP streams at different UDP
payload sizes 79
Figure 5.13 Comparison of data throughput gain of compressed IPv6/UDP streams against uncompressed IPv6/UDP streams at different UDP
payload sizes 80
Figure 5.14 The number of parallel RTP streams sustainable over 8Mbps DVB-S
link using different compression profile 81
Figure 5.15 Comparison of normalized aggregated UDP data throughput for maximum number of RTP streams supported by different
compression profiles 84
Figure 5.16 Traffic pattern of compressed RTP streams using IP profile 85 Figure 5.17 Traffic pattern of compressed and uncompressed RTP streams 86 Figure 5.18 Traffic pattern of compressed RTP streams with non-sequential
distribution of CID assignment 88
Figure 5.19 Comparison of CPU utilization compressing maximum number of
IPv4/UDP/RTP streams 89
Figure 5.20 Comparison of CPU utilization compressing maximum number of
IPv6/UDP/RTP streams 90
Figure 5.21 Comparison of packets loss ratio of IPv4 RTP streams against various BER over different refresh interval and compression profiles 91 Figure 5.22 Comparison of packets loss ratio of IPv6 RTP streams against various
BER over different refresh intervals and compression profiles 92 Figure 5.23 Packet drop rate of compressed streams over links with different
Figure 5.24 Comparison of normalized data throughput of IPv4 UDP streams over
link with BER of 10−4 95
Figure 5.25 Comparison of data throughput gain of compressed IPv4 UDP
streams against uncompressed IPv4 UDP stream over a link with BER
of 10−4 96
Figure 5.26 Comparison of normalized data throughput of IPv6 UDP streams over
a link with BER of 10−4 97
Figure 5.27 Comparison of data throughput gain of compressed IPv6 UDP streams against uncompressed IPv6 UDP stream over link with BER
of 10−4 98
Figure 5.28 Comparison of normalized data throughput of IPv4 UDP streams over
a link with BER of 10−5 99
Figure 5.29 Comparison of data throughput gain of compressed IPv4 UDP
streams against uncompressed IPv4 UDP stream over a link with BER
of 10−5 100
Figure 5.30 Comparison of normalized data throughput of IPv6 UDP streams over
a link with BER of 10−5 100
Figure 5.31 Comparison of data throughput gain of compressed IPv6 UDP
streams against uncompressed IPv6 UDP stream over a link with BER
of 10−5 101
Figure 5.32 Comparison of normalized data throughput of IPv4 UDP streams over
a link with BER of 10−6 101
Figure 5.33 Comparison of data throughput gain of compressed IPv4 UDP
streams against uncompressed IPv4 UDP stream over a link with BER
of 10−6 102
Figure 5.34 Comparison of normalized data throughput of IPv6 UDP streams over
a link with BER of 10−6 102
Figure 5.35 Comparison of data throughput gain of compressed IPv6 UDP
streams against uncompressed IPv6 UDP stream over a link with BER
of 10−6 103
Figure 5.36 Comparison of packet loss ratios of IPv4 RTP streams 106
Figure 5.37 Comparison of packet loss ratios of IPv6 RTP streams 106
Figure B.1 The interaction between socket buffer and rohc buffer for RTP header
compression 120
Figure B.2 The interaction between socket buffer and rohc buffer for RTP header
Figure C.1 Data structure of WLSB implementation 123
Figure D.1 The relationship between the data structures related to ROHC
compressor, profile and context 125
Figure D.2 The relationship between the data structures related to a compressor’s context, mini context and mini profile for RTP profile with
IPv4/UDP/RTP headers chain 126
Figure D.3 Association of the main data structures used by a compressor without
proper hashing 127
Figure D.4 Association of the main data structures used by a compressor hashed
using static information 128
Figure E.1 The relationship between the major data structures related to ROHC
decompressor, profile and context 129
Figure E.2 The relationship between the data structures related to a
decompressor’s context, mini context and mini profile for RTP profile
with IPv6/UDP/RTP headers chain 130
Figure E.3 Association of the main data structures used by a decompressor 131
Figure F.1 Relationship between mini contexts and uncompressed headers during the process of constructing uncompressed headers. RTP profile is
LIST OF ABBREVIATIONS
CBR Constant Bit Rate
CID Context Identifier
CRC Cylic Redundancy Check
CRTP Compressed Real Time Protocol
DVB Digital Video Broadcast
DVB-S Digital Video Broadcasting via Satellite
EBU European Broadcasting Union
ESP Encapsulating Security Payload
ETSI European Telecommunication Standards Institute
FC Full Context
FEC Forward Error Correction
FO First Order
HC Header Compression
I/F Intermediate Frequency
IETF Internet Engineering Task Force
IP Internet Protocol
IPv4 Internet Protocol version 4
IPHC Internet Protocol Header Compression
IR Initialization and Refresh
LSB Least Significant Bits
MPEG2-TS Moving Picture Experts Group 2 - Transport Stream
MLD Multicast Listener Discovery
MSN Master Sequence Number
PID Packet ID
RED Random Early Detection
ROHC RObust Header Compression
RTP Realtime Transport Protocol
RTT Round Trip Time
SC Static Context
SNDU SubNetwork Data Unit
SO Second Order
TCP Transmission Control Protocol
UDP User Datagram Protocol
UDL Unidirectional Link
ULE Unidirectional Lightweight Encapsulation
VJHC Van Jacobson Header Compression
WAN Wide Area Network
PENCIRIAN PRESTASI PEMAMPATAN TEGUH
KEPALA PAKET MELALUI PAUTAN SEHALA
BERDASARKAN SATELIT
ABSTRAK
Tesis ini menilai penggunaan Pemampatan Teguh Kepala Paket (RObust Header Compression (ROHC)) untuk trafik Pengkapsulan Ringan Sehala (Unidirectional Lightweight Encapsulation (ULE)) dari segi prestasi rangkaian serta implementasi praktikal dan reka bentuk sistem pe-mampat and penyahpe-mampat ROHC. Sistem yang disampaikan dalam tesis ini dinilai melalui tapak uji Penyiaran Video Digital melalui Satelit (Digital Video Broadcasting melalui Satellite (DVB-S)). Suatu model matematik sederhana dibentangkan terlebih dahulu untuk mengang-garkan sifat-sifat prestasi teori trafik yang dimampat dengan ROHC. Kemudian, keputusan teori dibandingkan dengan keputusan empirikal yang diperolehi melalui eksperimen tapak uji. Ini merupakan satu sumbangan yang penting kerana ketidakwujudan terbitan keputusan eksper-imen sebenar dalam penilaian protokol baru ini untuk sistem DVB-S
Melalui kajian, ROHC mampu menunjukkan peningkatan ketara dalam penggunaan mu-atan rangkaian untuk paket-paket yang bermumu-atan kecil dengan peningkmu-atan prestasi daya pem-prosesan sebanyak 86% apabila memampatkan trafik VoIP IPv6; manakala paket-paket yang bermuatan besar mempamerkan penurunan eksponen dalam kelebihan daya pemprosesan yang diperoleh melalui ROHC apabila saiz muatan meningkat. Penggunaan ROHC atas pautan tidak ideal menyajikan cabaran tersendiri kerana paket yang rosak akan diabaikan jika Semakan Lewah Kitar (Cyclic Redundancy Check (CRC)) yang dikesan dalam Unit Data Subrangkaian (Subnetwork Data Unit (SNDU)) ULE tidak berpadanan. Hal ini akan menyebabkan
kehilan-gan penyegerakan konteks dalam senario terburuk. Keberkesanan ROHC ke atas trafik IPv4 and IPv6 juga dinilai dalam tesis ini. Aliran trafik IPv6 mengecapi manfaat yang lebih besar dari ROHC berbanding dengan aliran trafik IPv4 walaupun pada pautan yang tidak ideal.
PERFORMANCE CHARACTERIZATION OF
ROBUST HEADER COMPRESSION (ROHC) OVER
SATELLITE BASED UNIDIRECTIONAL LINK
(UDL)
ABSTRACT
This thesis evaluates RObust Header Compression (ROHC) for Unidirectional Lightweight Encapsulation (ULE) in terms of network performance as well as the practical implementation and the design of ROHC compressor and ROHC decompressor system. The work presented in this thesis was conducted over a Digital Video Broadcasting via Satellite (DVB-S) testbed. A simple mathematical model was presented to estimate theoretical performance characteristics of ROHC compressed traffic. The theoretical results were then compared with the empirical results measured from the testbed. This is an important contribution due to the lack of published experimental results for evaluating the new protocol on a real DVB-S system.
ROHC delivered significant improvement in achieving better bandwidth utilization for packets with small payload sizes with up to 86% gain in throughput performance when com-pressing IPv6 VoIP traffic; whereas packets with larger payload sizes exhibited exponential decrease of throughput gain achievable through ROHC as the size of the payload increased. The application of ROHC over non-ideal links presented a different kind of challenges since erroneous packets are dropped if Cylic Redundancy Check (CRC) mismatched was detected in the ULE SubNetwork Data Unit (SNDU). This led to a loss of context synchronization in the worst case scenario. The effectiveness of ROHC for IPv4 versus IPv6 traffic was evaluated in this thesis as well. It was shown that IPv6 traffic streams benefited to a greater degree from ROHC than IPv4 traffic streams even on non-ideal links.
CHAPTER 1
INTRODUCTION
1.1 Overview
Satellite communication system plays a vital role in providing Wide Area Network (WAN) due to its broadcast nature and its wide geographical coverage, especially in areas where terrestrial link cannot reach.
Satellite communication system was developed for military purposes. But nowadays, its role expands to different fields. Naturally, with the exponential growth of the Internet, satel-lite communication takes on the role of providing Internet Protocol (IP) services. While the majority of IP services assume that the underlying transport medium is bidirectional in nature, satellite link itself is unidirectional. Thus, this presents a challenge to the provision of IP ser-vices over satellite communication system. For consumers who can afford to lease 2 frequency bands from satellite service provider, this problem is not an issue. Nevertheless, approach such as Link Layer Tunneling Mechanism (Izumiyama et al., 2001) was proposed to overcome this shortcoming of satellite communication system.
Digital Video Broadcasting via Satellite (DVB-S) system is a standard developed by the DVB project to deliver digital content over satellite link. It is more commonly used to deliver audio/video content. In order to deliver IP packets over DVB-S, Multi-protocol Encapsulation (MPE) was first developed to carry IP packet over the baseband of DVB-S system, MPEG2 Transport Stream (MPEG2-TS) frames. However, due to its complexity and its overhead, Uni-directional Lightweight Encapsulation (ULE) was later developed by the IETF as a better
al-ternative to deliver IP packets over MPEG2-TS frames.
1.2 Problem Statement
While satellite communication system is an ideal technology for WAN mainly because of its wide geographical coverage, it is not the mainstream technology due to its expensive opera-tional cost. Due to the expensive operaopera-tional cost, the available bandwidth must be efficiently utilized.
For end to end delivery of data over the Internet, IP header and higher layer headers are needed to ensure that the data are sent to its destined recipient. However, for delivery of packets from hop to hop, link layer addresses alone are sufficient. Thus, for the provision of IP services over satellite communication system, the overhead of MPEG2-TS frames, ULE, data link layer header, IP header as well as transport header leads to inefficient use of bandwidth. The wastage of bandwidth is more significant when the payload sizes are small. For a typical GSM encoded VoIP traffic over IPv6 network, the size of the audio data is less than the the total size of the headers in the RTP packet.
By applying header compression to the IP traffic, the incurred overhead can be reduced. Common to all wireless communication technology, satellite communication system is suscep-tible to noise introduced by the propagating medium. Although there are quite a number of header compression mechanisms that can be used to compress the headers of IP traffic, this thesis deals with RObust Header Compression (ROHC) exclusively because of its ability to tolerate losses and errors.
1.3 Research Objectives
The objectives of this research are as follows:
• To enhance the performance of ULE over DVB-S system using ROHC by designing and implementing a framework for ROHC to support IP, UDP and RTP profiles.
• To develop tools to properly evaluate the efficiency of ROHC framework for different types of traffic. In addition to that, evaluation framework must be able to cover the tests that cannot be produced reliably on a DVB-S testbed (i.e. introduction of errors).
• To conduct a comparative study on the performance characteristics of an actual ROHC over DVB-S testbed against the results obtained through simulation.
• To evaluate the performance characteristics of RTP, UDP and IP profiles on UDP streams as well as RTP streams. The evaluation will also emphasize on the differences between IPv4 streams and IPv6 streams when header compression is applied.
1.4 Scope of Research
Due to time constraint, the scope of this research was limited to unidirectional mode of ROHC. Of the 2 encapsulation formats to transport IP packets over MPEG2-TS frames, only ULE was evaluated as this encapsulation format has less overhead. The experiments were conducted over DVB-S testbed instead of a real satellite communication system. As such, some characteristics found in a real satellite communication system were not evaluated. For instance, the effect of propagation delay was not be evaluated. However, it is expected that, propagation delay will mostly impact the performance of ROHC channel operating in bidirectional optimistic mode and bidirectional reliable mode as the timely correction of Cylic Redundancy Check (CRC) error depends upon the timely arrival of ROHC feedback. In unidirectional mode, the
satellite propagation delay contributes a constant increase to the packet delays experienced over the link. Furthermore, the UDP traffic used in the work of this thesis did not rely upon acknowledgement and was not subject to the effect of bandwidth delay product. Thus, the propagation delay would not be a major concern for ROHC channel operating in unidirectional mode.
While the effect of propagation delay would not be investigated, errors were simulated over the DVB-S testbed to measure the effect of errors over ROHC channel. Due to time constraint, only 3 profiles of ROHC were supported, namely the IP, UDP and RTP profiles. The parameters of ROHC channel would be predetermined instead of being negotiated through a protocol.
1.5 Outline of the Thesis
This thesis is organized into 6 chapters. The outlines of each chapter are as follows:
Chapter 1 provides a brief introduction to the work planned for this thesis. Challenges of providing bandwidth efficient IP services over DVB-S system are summarized.
Chapter 2 provides the literature review on satellite communication systems. The encapsula-tion format used by DVB-S system is introduced. Past researches on header compression are briefly outlined at the end of this chapter. Based on these background studies, justi-fication of the choices that were adopted in this thesis is made.
Chapter 3 begins with an overall introduction to the software and hardware components used in the experiment. Detailed design of the ROHC software framework and the interaction of hardware and software components are given in the later part of this chapter.
Chapter 4 covers the methods used to evaluate the experimental results. The setup and con-figuration of the experiments are also outlined. The software used to conduct the
experi-ments is also introduced.
Chapter 5 presents the results and findings of the experiments. Based on the results, the performance characteristics of the system are evaluated. Conclusion is provided based on the evaluation.
Chapter 6 summarizes the work of this thesis and the limitation of the existing system. From there, future works are drawn based on the areas that are not covered in this thesis.
CHAPTER 2
LITERATURE REVIEW
This chapter discusses the pros and cons of satellite communication systems briefly. Following that, a comparison of two satellite network topologies will be covered. Later in this chapter, IP services over DVB-S will be outlined. The final section of this chapter presents header compression techniques proposed by other researchers.
2.1 Satellite Communication System
Satellite communication systems are used as Wide Area Network (WAN) links due to their ability to provide wide geographical coverage. A geostationary satellite can cover more than 30% of earth surface. A geostationary satellite has rotational period that is identical to rota-tional period of the earth (Clarke, 1945), thus rendering its position stationary to an observer on the earth. This characteristic of geostationary satellite makes it ideal to be deployed on many earth stations because it doesn’t require any expensive tracker components. For remote areas or during disaster recovery where terrestrial links are non-existent, satellite communication is one of the best solutions.
Nonetheless, satellite communication systems itself are not without disadvantages. The most obvious disadvantage of satellite communication systems is the cost. It requires a huge sum of money to launch a satellite into space. The equipment used for satellite communication is very expensive. These are non-recurring costs. For the users of such services, there are recurring costs of leasing bandwidth from the satellite communication provider. Apart from
that, satellite communication also incurs a long propagation delay due to the distance that the radio signal has to travel. For a geostationary satellite, a single hop between earth stations requires approximately 250ms. The 500ms round time trip (RTT) delay makes it unsuitable for most interactive applications. Transport protocols like TCP relies on acknowledgement for flow control. Since it is a network link with a high bandwidth delay product, the performance of TCP suffers when deployed in satellite networks. Although various techniques like TCP Hybla (Caini and Firrincieli, 2004) have been proposed to solve this issue, it still does not negate the fact that most of default implementations of TCP stacks are not using TCP Hybla. Thus, the end users must explicitly know TCP Hybla to utilize the available bandwidth more efficiently.
2.2 Satellite Network Topologies
2.2.1 Star Topology
Hub
a
b
c
Ta Ra Ta Ra Tb Rb Tc Rc Tc Rc Tb RbFigure 2.1: Star configuration satellite network
Star topology satellite networks as depicted in Figure 2.1 require a central hub for com-munication between all leaf sites. Point-to-Point links are established between leaf sites and hub. The central hub coordinates and relays traffic between leaf sites. Assuming that each leaf site requires channel spectrum of C for its channel where each channel transmits data in one
direction, the required spectrum usage for a bidirectional star topology with N leaf sites is 2N × C. Due to the requirement of a central hub, any communication between leaf sites requires 2 hops. Consequently, round trip time (RTT) between 2 leaf sites must be at least 1 second. Moreover, star topology relies solely on the central hub for communication between all leaf sites. A failure on the central hub will disrupt the whole network.
2.2.2 Point-to-Multipoint Mesh Topology
a
b
c
Ta Rb Rc
Tc Ra Rb
Tb Ra Rc
Figure 2.2: Point-to-multipoint mesh satellite network
Star configuration satellite networks do not take advantage of the broadcast nature of satel-lite links. Figure 2.2 shows the configuration of an equivalent of satelsatel-lite network using a point-to-multipoint mesh topology. This topology was discussed in (Wan, 2000). Point-to-multipoint links are established among all sites. For a network with N sites, each site has to install N - 1 receivers to receive the transmission from other sites. Spectrum requirement is significantly reduced because the signal from each site is broadcast to every other site. Using the same assumptions as outlined for star topology, the required spectrum usage for a point-to-multipoint mesh satellite network is N × C. However, this topology requires more receivers to be installed at each leaf site. Considering that the cost of a receiver is significantly cheaper than the cost of satellite bandwidth, it is still a good tradeoff. In addition, the round trip time for communication between leaf sites is reduced by half because only one hop is required.
2.3 IP over DVB-S
2.3.1 Digital Video Broadcasting - Satellite (DVB-S)
The DVB project is led by a consortium of industry players to standardize the delivery of digital video and data content. Several standards have been defined for different transmission media:
• Digital Video Broadcasting - Satellite (DVB-S)
• Digital Video Broadcasting - Satellite - Second Generation (DVB-S2)
• Digital Video Broadcasting - Terrestrial (DVB-T)
• Digital Video Broadcasting - Terrestrial - Second Generation (DVB-T2)
• Digital Video Broadcasting - Cable (DVB-C)
• Digital Video Broadcasting - Cable - Second Generation (DVB-C2)
• Digital Video Broadcasting - Handheld (DVB-H)
• Digital Video Broadcasting - Satellite services to Handhelds (DVB-SH)
The standards developed by the DVB project have been widely adopted in Europe and most Asian countries. Among the defined standards, DVB-S, DVB-S2 and DVB-SH are meant for satellite communication. DVB-S is the first generation of the standard supporting QPSK modulation. DVB-S2 is the second generation of the standard with support for more efficient modulation techniques to adapt to the condition of satellite links. DVB-SH was designed to support handheld terminal over hybrid satellite/terrestrial links. Since the focus of this work is limited to DVB-S, the other standards will not be discussed although the header compression technique can be adapted for the other standards as well. DVB-S (EBU and ETSI, 1997), which was standardized in 1997, was designed to carry video, audio and program data for
digital television. The data is inserted into fixed-length MPEG2 transport stream (MPEG2-TS) frames. At the physical layer, DVB-S appends a 16 bytes Reed-Solomon error correction code to every MPEG2-TS frame to make the data more resilient to an error prone medium. In addition, user selectable forward error code (FEC) is inserted into the data stream for better reliability.
2.4 Frame Format
MPEG2-TS frame which is used to deliver digital content on DVB-S system, has the following format as shown in Figure 2.3 (ISO and IEC, 2001).
Header Payload 184 bytes 4 bytes 0x47 PID CC Sync byte Transport Error Indicator
Payload Unit Star Indicator (PUSI) Transport Priority Trasnport Scrambling Control Adaptation Field Control Continuity Counter
Figure 2.3: Structure of a MPEG2-TS frame
Each MPEG2-TS frame is 188 bytes in length and usually made up of a 4-byte header and a 184-octet payload for carrying data. Depending on the option set in the header, some portion of the payload field may be used to carry information other than raw data. Every TS frame starts with a synchronization byte with the value of 0x47. The PID field is Program Identifier.
The PID is used to identify a stream of related MPEG2-TS frames, while the continuity counter (CC) is incremented for each frame belonging to a stream.
The PUSI flag is used to indicate the presence of a new data within the payload field. Whenever PUSI flag is marked, another 1 octet field called the payload pointer (PP) field will appear at the end the header. The payload pointer (PP) field will store the offset to new data in the payload field.
2.4.1 Packing versus Padding
The combination of PP and PUSI fields allow for new data to be packed into unused but other-wise wasted portion of the MPEG2-TS payload field. Contrary to packing, unused portion of a MPEG2-TS frame may also be padded with stuffing bytes. Figure 2.4 and 2.5 depict the dif-ference between packing and padding for 2 similar sample data. Packing data helps to achieve higher efficiency at the cost of additional delay. In packing mode, a MPEG2-TS frame will be sent when packing threshold expired even if there is an abundance of unused portion of the payload field. Under such circumstances, stuffing bytes will be appended to the unused portion.
Header Data A
Data A Data B
PP Header PP Data A Data B
Stuffing Bytes
Figure 2.4: Packing multiple data packets into MPEG2-TS frames
For DVB-S system, the transmission consists of streams of multiplexed MPEG2-TS frames transmitted at a constant rate. Thus, whenever the incoming rate of data to the system is less than the preset rate, DVB-S system must insert null frames to maintain the constant rate. The
Header Data A
Data A Data B
PP Header Data A Header PP Data B
Stuffing Bytes
Figure 2.5: Data framing with padding for MPEG2-TS frames
data inserted into MPEG2-TS frames usually consists of audio/video data. To deliver IP packets over MPEG2-TS frames, an additional layer of encapsulation is required.
2.4.2 Multiprotocol Encapsulation (MPE)
Multiprotocol Encapsulation (MPE) is a standard proposed by ETSI to carry network data over MPEG-2 TS frames (ETSI, 2004). MPE was optimized to transport IPv4 packet. No payload type field is present in the MPE header. If other type of payload like IPv6 needs to be encapsulated, additional headers will be needed. MPE also carries the destination MAC address. The format of MPE is complex and introduces significant amount of overhead for small payloads.
2.4.3 Unidirectional Lightweight Encapsulation (ULE)
Unidirectional Lightweight Encapsulation (ULE) (Fairhurst and Collini-Nocker, 2005) is a standard put forth by IP over DVB working group of the IETF to encapsulate network data over MPEG2-TS frames. The format of a ULE packet as depicted in Figure 2.6 is the simplest version that can be used.
The payload of ULE, called Protocol Data Unit (PDU), will be appended to the ULE header. A 32-bit cyclic redundancy check (CRC) will be calculated over the ULE header and the PDU. Then the CRC will be appended to the PDU to form the Subnetwork Network Unit (SNDU).
D Length Type Dest. MAC PDU CRC-32
Subnetwork Data Unit (SNDU) ULE Header
Destination Absent
Figure 2.6: ULE packet format
The basic ULE header only consists of a destination absent field, length field and a type field. Whenever the destination absent field is cleared, a 6-byte destination MAC will be appended after the type field. This 6-byte destination MAC is used to indicate the desired recipient. The type field indicates the type of payload carried in the PDU field. ULE defines several types of payload, namely, IPv4 packet, IPv6 packet and Ethernet bridge frame. In addition, the type field can also be used to indicate the presence of extension headers. The extension header formats defined for ULE is also usable by GSE (Fairhurst and Collini-Nocker, 2008). GSE will be discussed in the following section.
Several studies had been done to evaluate the performance characteristics of ULE (Sooriya-bandara, Fairhurst, Ang, Collini-Nocker, Linder and Stering, 2005) and compare it to the per-formance characteristics of MPE (Teh et al., 2005a), (Teh et al., 2005b) (Xilouris et al., 2006). The results from these studies showed that ULE is the more efficient encapsulation format because the overhead incurred by ULE is less than the overhead incurred by MPE.
2.4.4 DVB-S2 and GSE
DVB-S2 (EBU and ETSI, 2009) is the second generation DVB standard for satellite commu-nication. DVB-S only supports QPSK modulation which translates to only 2 bits per symbol, whereas DVB-S2 allows for 4 types of modulations, namely, QPSK, 8PSK, 16 APSK and 32 APSK. 32 APSK, which is the most efficient modulation, is capable of carrying 5 bits per sym-bol. This modulation should only be used on a link with the least amount of distortion. In addition, DVB-S2 system also employs Adaptive Coding and Modulation (ACM) technique to
improve bandwidth utilization. Using this technique, the receiver will send a feedback to the feed on the condition of the link. Based on the feedback, the feed will adjust the best coding and modulation type to maximize the bandwidth utilization. The improvements introduced into DVB-S2 give it a 30% performance gain over DVB-S (Morello and Mignone, 2004).
Instead of using MPEG2-TS frame to deliver data, DVB-S2 uses BaseBand frame (BBFrame). To ensure backward compatibility with the old system, MPEG2-TS frame can be encapsulated within BBFrame thus allowing MPE and ULE to be used for DVB-S2. However this approach is not optimal because an additional layer of encapsulation is required. Thus, Generic Stream Encapsulation (GSE) (DVB, 2007) was introduced to reduce the overhead. Figure 2.7 depicts the process of encapsulating a network datagram within DVB-S2 stack using GSE. A study was conducted to compare the efficiency of MPE, ULE and GSE encapsulation over DVB-S2 and the results showed that GSE is the most efficient encapsulation for DVB-S2 (Mayer et al., 2007). PDU PDU GSE Header PDU GSE Header BBFrame Header PDU PDU GSE Header PDU GSE Header
GSE Data GSE Data GSE Packet GSE Packet
BBFrame Data BBFrame Network Layer/ Link Layer Physical Layer GSE Encapsulation
Figure 2.7: Encapsulation of network packet within DVB-S2 stack using GSE
The scope of this thesis is limited to DVB-S only and support for GSE is part of future work for this research area. However, since DVB-S2 is related to DVB-S, it is mentioned here briefly for completeness.
2.5 Header Compression
Before data can be transferred through a network, several layers of encapsulations may have to be applied. At the end of this process, the data which is part of the payload is combined with the headers forming an IP packet. While headers such as the network header and the transport header are necessary for the delivery of the data, they inevitably introduce overhead. Header compression mitigates the wastage caused by such headers within IP packets. Header compres-sion works simply because there are significant amount of redundancies within headers. These redundancies can be classified under 2 categories:
• Intra-packet – Some of the fields in the headers are well known or could be deducted from other fields. Examples of such fields are the length within UDP header or IP version within IPv4 header.
• Inter-packet – Some of the fields in the headers of IP packets can be deduced using the knowledge of previous packets due to their incremental change. Timestamp of RTP header and IP-ID of IPv4 header are examples of the fields that exhibit this characteristic.
Assuming that the best header compression can completely eliminate all headers, the upper bound on the savings achievable by any header compression scheme, denoted by Si, for packet
iwith cumulative headers size of Headeri and payload size of Payloadi is then given in the
following equation (Fitzek et al., 2004):
Si≤
Headeri
Headeri+ Payloadi
Deducing from Equation 2.1, header compression works best with large headers size and small payload size. For RTP session using GSM coded audio, the payload is typically around 30 bytes while the headers account for 40 bytes when IPv4 is used and 60 bytes when IPv6 is used.
2.6 Earlier Works on Header Compression Schemes
2.6.1 Van Jacobson Header Compression (VJHC)
30 30 30 31 32 33 34 31 32 33 +1 +1 +1 +1
x
Original HC Decompressed Uncompressed Delta encoded+
+
+
Figure 2.8: Delta encoding used by VJHC decompresses incorrectly when packet loss occurs
The first header compression introduced by the IETF is Van Jacobson Header Compres-sion (Jacobson, 1990). VJHC can compress TCP and IP headers down to 4 bytes. VJHC works based on the principle of delta encoding. The compression process begins by sending a packet in uncompressed form. For subsequent packets, only the deltas are sent. However, delta encod-ing is susceptible to error. A loss of compressed packet or corrupted compressed packet will cause all subsequent packets to be decompressed incorrectly as shown in Figure 2.8. Because VJHC was initially targeted at low-speed serial link which is less error-prone, the
characteris-tics of delta encoding does not pose too much of a problem. However, for error-prone wireless link, it is unsuitable (Auge and Aspas, 1998) (Wang, 2004).
2.6.2 IP Header Compression (IPHC)
IPHC (Degermark et al., 1999) extended the work done by VJHC to include compression of UDP header, IPv6 header and extension headers. Like VJHC, IPHC uses delta encoding for compression. However, IPHC introduces 2 methods to mitigate the problem associated with delta encodings: 30 30 30 31 32 33 34 31 32 33 +1 +1 +1 +1
x
Original HC Decompressed Uncompressed Delta encoded + + + Checksum fails 34 + Reapply deltaFigure 2.9: Twice algorithm applies twice the delta to correct the decompression when check-sum fails
• Twice algorithm (Degermark et al., 1997) – this method helps to correct the problem caused by packet loss. When the checksum of a decompressed packet is incorrect, the delta is applied again to repair the packet. If the checksum of the repaired packet is still incorrect, the delta will be applied once more. Figure 2.9 shows a simplified example on the repair performed by the twice algorithm to correct the damage caused by packet loss.
• Header request – if the twice algorithm fails to repair a context, the decompressor may request for compressor to send complete header to update the damaged context.
2.6.3 Compressed Realtime Transport Protocol (CRTP)
CRTP (Casner and Jacobson, 1999), standardized as RFC 2508, can compress 40 bytes of IP/UDP/RTP header chains to 4 bytes if the UDP checksum is used, or to 2 bytes if the UDP checksum is not used. Like VJHC and IPHC, CRTP uses delta encoding. But for some fields in the RTP header, the changes from packet to packet are constant. If the changes remain constant, the compressor compresses away these fields.
Due to the fact that RTP cannot be reliably detected from the transport protocol, CRTP identify RTP using heuristics. Packet streams that fail to be compressed as RTP packets will be recorded in a "negative cache". Although failing to be compressed as RTP packets, the IP and UDP headers of these packets can still be compressed. CRTP relies on feedback for error correction, thus it does not perform well for links with long RTT (Degermark et al., 2000).
2.7 RObust Header Compression (ROHC)
RObust Header Compression is a header compression framework designed to work with error prone links with long delay. It was standardized by the ROHC Working Group (ROHC WG) of the IETF in RFC 3095 (Borman et al., 2001). The first standard introduces four profiles, namely, Real-time Transport Protocol (RTP), User Datagram Protocol (UDP), Encapsulating Security Payload (ESP) and uncompressed profiles. RTP, UDP and ESP profiles were defined to enable compression and decompression of their respective traffic type, while uncompressed profile is used to handle other types of traffic uncompressible using existing profiles. Since then, several other RFCs have been published by the same working group to deal with other
types of traffic. Viewed in this light, ROHC is a general protocol-independent framework that is used to enable compression and decompression of different types of traffic, while the profiles are a set of contract between compressor and decompressor on how to deal with a specific type of traffic. RFC 4995 (Jonsson et al., 2007) which was later defined provides a clear separation of the framework from the profiles.
When ROHC was first standardized, the design assumes that the underlying link carrying the compressed packets does not reorder packets, while packet reordering in pre-HC link is acceptable. Version 2 of ROHC (Pelletier and Sandlund, 2008) which is published as RFC 5225 is designed to address that deficiency.
2.7.1 Profile, Context and ROHC Versions
Data travelling through the network are interrelated and share some common properties and thus can be considered a flow. Taking advantage of these properties, compressor and decom-pressor maintain respective information of the flow in their respective context information.
Due to the fact that a typical network link is shared by many streams of traffic, thus more than one context may exist at any given time. The compressor and decompressor identify individual context through Context Identifier (CID). Since there is a finite number of allowable CID, when all of the available CIDs have been used, the compressor may decide to recycle and reinitialize one of the existing CIDs to associate it with a new context.
Every context is different from each other. For example, a context maintaining the states of an RTP stream is totally different from a context maintaining the states of a TCP stream. However, all contexts related to RTP stream share some similar characteristics like the com-pression mechanism and compressed packet types. Every context that shares such similarities is handled by a profile. Thus, context information of a flow contains the information regarding
the states of the context, the type of profile associated with the stream and the data of the flow. The states of context shall be discussed in detail later.
Table 2.1: ROHC profiles (IANA, 2008)
Profile Profile Identifier
RTP/UDP/IP version 1 0x0001 UDP/IP version 1 0x0002 ESP/IP version 1 0x0003 IP version 1 0x0004 UDP-Lite/IP version 1 0x0008 RTP/UDP/IP version 2 0x0101 UDP/IP version 2 0x0102 ESP/IP version 2 0x0103 IP version 2 0x0104 UDP-Lite/IP version 1 0x0008
Similar to context, a profile is identified by its profile identifier. ROHC WG has defined several profiles as shown in Table 2.1. The profile ID is 16 bits wide. Version 1 and version 2 of the profiles were defined by ROHCv1 and ROHCv2 respectively. Similar profile for version 1 and version 2 are capable of compressing similar type of traffic. In fact, the profiles of similar type are the same in the least significant octet of the profile ID, while the most significant octet of the profile ID is used to identify the version of the profile. However, as shown in Figure 2.10, the Initialization and Refresh (IR) packet which is used to establish a context with a profile only has 1 octet reserved for the profile identifier field. The profile identifier field contains the type of the profile (the least significant octet of profile identifier). Thus, to avoid ambiguity in the interpretation of a profile version, the compressor and decompressor must negotiate and agree upon all the profiles that are going to be used. Different profile versions for similar traffic types should not co-exist for a particular session.
1 1 1 1 1 1 0 D
0 1 2 3 4 5 6 7
Add-CID octet (small CIDs and CID != 0)
large CID (1-2 octets) Profile ID (1 octet)
CRC (1 octet)
Profile specific information (variable length)
Figure 2.10: General format of IR packet (Jonsson et al., 2007)
2.7.2 Compressor States
All references to the compressor states below actually refer to the state of individual context within the compressor. Likewise, when the decompressor states are discussed later, the states of individual context within the decompressor are implied.
FO
IR
SO
STATIC-NACK/Timeout STATIC-NACK/Timeout NACK/Update/Timeout ACK/Optimism ACK/Optimism ACK/Optimism ACKFigure 2.11: ROHC compressor states (Borman et al., 2001)
The three states of a compressor illustrated in Figure 2.11 are:
