robust header compression protocol enhancements for voice...
Post on 14-Mar-2020
6 Views
Preview:
TRANSCRIPT
•
Robust Header Compression Protocol Enhancementsfor Voice Multicast over Mobile Ad-Hoc Networks
By
Zhenhua Xiao
A PROJECT SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENT FOR THE DEGREE OF
MASTER OF ENGINEERING
In the School
of
Engineering Science
© Zhenhua Xiao 2009
Simon Fraser University
Fall, 2009
All rights reserved. This work may not be reproduced in whole or in part, by photocopy orother means, without permission of the author.
APPROVAL
Name:
Degree:
Title of Project:
Examining Committee:
Zhenhua Xiao
Master of Engineering
Robust Header Compression Protocol Enhancements forVoice Multicast over Mobile Ad-Hoc Networks
Approved:
Chair: Daniel LeeProfessor
Dr. R.H Stephen HardySenior SupervisorProfessor
Dr. Tejinder RandhawaSenior SupervisorAdjunct Professor
November 12, 2009
ii
SIMON FRASER UNIVERSITYLIBRARY
Declaration ofPartial Copyright LicenceThe author, whose copyright is declared on the title page of this work, has grantedto Simon Fraser University the right to lend this thesis, project or extended essayto users of the Simon Fraser University Library, and to make partial or singlecopies only for such users or in response to a request from the library of any otheruniversity, or other educational institution, on its own behalf or for one of its users.
The author has further granted permission to Simon Fraser University to keep ormake a digital copy for use in its circulating collection (currently available to thepublic at the Branches & Collections' "Institutional Repository" link of the SFULibrary website www.lib.sfu.ca). and, without changing the content, to translate thethesis/project or extended essays, if technically possible, to any medium or formatfor the purpose of preservation of the digital work.
The author has further agreed that permission for multiple copying of this work forscholarly purposes may be granted by either the author or the Dean of GraduateStudies.
It is understood that copying or publication of this work for financial gain shall notbe allowed without the author's written permission.
Permission for public performance, or limited permission for private scholarly use,of any multimedia materials forming part of this work, may have been granted bythe author. This information may be found on the separately cataloguedmultimedia material and in the signed Partial Copyright Licence.
While licensing SFU to permit the above uses, the author retains copyright in thethesis, project or extended essays, including the right to change the work forsubsequent purposes, including editing and publishing the work in whole or inpart, and licensing other parties, as the author may desire.
The original Partial Copyright Licence attesting to these terms, and signed by thisauthor, may be found in the original bound copy of this work, retained in theSimon Fraser University Archive.
Simon Fraser University LibraryBurnaby, BC, Canada
Revised: Spring 2009
ABSTRACT
Robust Header Compression (RoHC) is a protocol to compress the
headers in IP packets to reduce traffic. Particularly, in VolP (Voice over IP)
packets, the whole 40 bytes of RTP header section can potentially be
compressed to as small as 1 byte. In Mobile Ad-hoc Networks (MANETs), the
underlying wireless links between the compressor and the decompressor are
often not stable. Consequently the context between the compressor and
decompressor may be lost during communication. This makes the header
compression ineffective.
This paper proposes a technique that leverages the inherent broadcasting
characteristics of MANETs that allows mobiles to reinstate a new context by
sniffing the wireless medium and capturing packets from different compressors.
The proposed method improves the robustness of the protocol while retaining all
other benefits of the protocol. The viability and the performance of the approach
are demonstrated using an NS-2.
iii
DEDICATION
This work is dedicated to my wife and my kids
for the joy and happiness they bring
to my life
iv
ACKNOWLEGEMENTS
The author would like to express his gratitude and appreciation to Dr. Stephen
Hardy and Dr. Tejinder Randhawa for their support, understanding and
knowledge. Their supervisory roles throughout the execution of this project are
thankfully acknowledged.
v
TABLE OF CONTENTS
APPROVAL iiABSTRACT iiiDEDICATION ivACKNOWLEGEMENTS vTABLE OF CONTENTS viLIST OF FIGURES viiiLIST OF TABLES ixABBREVIATION AND ACRONyMS xINTRODUCTION 1
1.1 Problem Definition 11.2 Project Overview 2
2 SPECIFICATION BACKGROUND 42.1 IEEE 802.11 Wireless Ad-Hoc Network 42.2 Multicast 52.3 Voice over IP Packet Formats 6
2.3.1 IPv4 Header Format.. 72.3.2 UDP Header Format 82.3.3 RTP Packet Header Format.. 9
2.4 Compressed RTP Protocol (CRTP) 92.5 Enhanced Compressed RTP Protocol (ECRTP) 112.6 Robust Header Compression (ROHC) 12
2.6.1 Least Significant Bits (LSB) encoding 122.6.2 Window-based LSB encoding (W-LSB encoding) 132.6.3 States and Operations 152.6.4 Packet Format. 16
2.7 Current Work 163 ENHANCEMENTS TO ROHC PROTOCOL IN MANET. 17
3.1 Decompressor Context Comparison 183.2 IP Time to Live Field Derivation 193.3 Identifying the Right Data Stream 233.4 Block Diagrams for the Proposed Technique 243.5 User Scenarios for ROHC Enhancements 27
3.5.1 Hopping Scenario 273.5.2 Jamming Scenario 293.5.3 Roaming Scenario 29
3.6 Security Considerations 304 SIMULATIONS 31
4.1 ROHC RTP Profile Software Stack 314.2 NS-2 Simulation Software 324.3 Simulation Results 33
4.3.1 Simulation for Hopping Scenario 334.3.2 Simulation for Roaming Scenario 364.3.3 100 Node Simulation Results 37
vi
4.3.4 Running Simulation Using Random Seeds 395 CONCLUSION 40
5.1 Future Works 41REFERENCES 42
vii
LIST OF FIGURES
Figure 2-1 IPv4 Header Format.. 7Figure 2-2 UDP Header Format 8Figure 2-3 RTP Header Format.. 9Figure 2-4. ROHC State Transition Diagram 15Figure 3-1. Mobile Multicast Network 17Figure 3-2 TTL Value Decrement in MANET 20Figure 3-3 CRC-3 Differences for Adjacent TTL Values 21Figure 3-4 CRC-3 Differences for TTL Values of Offset 2 21Figure 3-5 Packet Stream Identification Diagram 25Figure 3-6 Intercepted Packet Decoding Process 26Figure 3-7 TTL Derivation Diagram 27Figure 3-8 Hopping Scenario 28Figure 3-9 Jamming Scenario 29Figure 3-10 Roaming Scenario 30Figure 4-1 Simulation Setup for Hopping Scenario 34Figure 4-2 Packet Intervals in Hopping Scenario 35Figure 4-3 Simulation Setup for Roaming Scenario 36Figure 4-4 Compressor Id for Node_6 36
viii
LIST OF TABLES
Table 3-1 Decompressor Context Comparison 18Table 4-1 Software Version Matrix ~ 32Table 4-2 Simulation Model and Value Matrix 33
ix
ABBREVIATION AND ACRONYMS
ACK Acknowledgement
CID Context 10
ROHC Robust Header Compression
CRTP Compressed RTP
ECRTP Enhanced CRTP
WLAN Wireless Local Area Network
MANET Mobile Ad-hoc Network
IP Internet Protocol
RTP Real-time Transport Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
MAC Media Access Control
RFC Request for Comments
VolP Voice over IP
x
INTRODUCTION
A typical voice over IP packet has 40 - 100 bytes of payload data depending
upon the coding rate. A RTP packet has 40 bytes in header section, which
includes IP header (20 bytes), UDP header (8 bytes) and RTP header (12 bytes).
Most of the fields in the header contain either known values such as source IP
address and destination IP address, or changes according to a known pattern
such as the sequence number in the RTP header. Only very few of them change
in a truly random fashion from packet to packet such as IP_ID field. It is then
possible to send only a small portion of the packet header from the transmitting
node (compressor) to the receiving node (decompressor) and the rest of the field
can be restored by calculation. In order to achieve this, the compressor and the
decompressor need to setup a Context that contains information necessary to
restore the entire packet header. The context between the compressor and the
decompressor always needs be up to date. If the context in the decompressor
side is not updated in real-time and then the packet restoration might not be
possible. Once the context is corrupted, all subsequent packets have to be
dropped until the context is refreshed by the compressor.
1.1 Problem Definition
Implementing the header compression protocols over the Wireless Ad-Hoc
network for Voice over IP applications represents both huge benefits as well as
big challenges. The benefits come from the savings in the headers, not only it
reduces the transmission time and traffic, but also it reduces the packet error
1
rate. However, because of the dynamic nature of the Wireless Ad-Hoc network,
the contexts are easier to get lost than wired networks. The reasons leading to
the lost context include packet error rate in air interfaces, voluntarily packet drops
in heavy traffics, compressor and decompressor moving away from each other,
and unexpected link disconnects etc. This problem becomes more challenging in
a multicast voice over IP environment. Because the feedback mechanism is
restricted in multicast protocol, even the compressor may periodically refresh the
context, there is a possibility that the context gets lost and the context refresh
packet never gets delivered to the target nodes.
1.2 Project Overview
This project proposes a technique to solve the above problem by sniffering the
air interface. In wireless ad-hoc networks, packets are relayed from one mobile
node to another, which means that essentially the same packet is transmitted in
the air at different location at different time or even at the same time. Depending
on the topology, there are nodes in the network which can capture the same
packet transmitted from different sources. The proposed technique is to utilize
the existing redundancy information to achieve more robust operation in header
compressions.
The project is organized in following sections. Section 2 gives specification
backgrounds and overview of the latest works. Section 3 proposes the technique
in RoHC protocol, and then investigates the feasibility of applying the same
technique in ECRTP protocol. Section 4 presents the simulation model, scenario
2
setup and underlying software stacks, the simulation results are revealed in
section 5.
The ROHC software stack used in the NS-2 simulation in this project is
developed by the author based on an existing open software base.
3
2 SPECIFICATION BACKGROUND
This section gives a brief overview of wireless ad-hoc network, multicast
operations, RoHC header compression protocol and CRTP protocols.
2. 1 IEEE 802.11 Wireless Ad-Hoc NetworkThe 802.11 wireless networks have 2 basic media access functions, called PCF
and DCF. In PCF, the access point will set up a contention free period, and poll
each mobile station; the polled mobile station has the opportunity to access the
wireless media and sends out packets. The DCF is the function where all mobile
stations need to contend for the media access. In order to avoid the hidden
terminal problem, mobile stations will first send out a RTS frame, if the
destination can hear this RTS clearly, then it can response back a CTS frame.
The source mobile station depends on the clear reception of the RTS frame to
determine whether it can access the media or not. If a CTS frame is received
clearly, then the mobile station will continue to send out packets to the
destination, if it couldn't get the expected response, then it will assume a collision
has occurred and a back-off algorithm will kick in, the back-off algorithm will
prevent too many mobile devices trying to access the media at the same time.
There are 4 inter-frame-spaces in IEEE 802.11 MAC layer; they are SIFS, PIFS,
DIFS and EIFS. Those inter-frame-spaces determine the sequence and priority
between workstations. PCF has higher priority than DCF, since it waits shorter
period of time before trying to access the media again. SIFS has the shortest
time, it is used between the RTS-CTS hand shaking and afterwards.
4
In normal operation, for every successful frame transmission, the receiver needs
to send an ACK packet back to the transmitter. Otherwise the transmitter will
assume the packet gets lost or corrupted.
2.2 Multicast
The 802.11 MAC layer supports multicast. Multicast doesn't have the RTS - CTS
sequence, it doesn't have the ACK packet response either. In general multicast is
an unreliable transmission mechanism, however, its one-to-many nature can also
save lots of bandwidth. In order to receive the multicast packets, nodes need to
participate in a multicast group.
The reliable multicast protocols are proposed as an addition to the existing MAC
protocol. One way to achieve this is the transmitter multicast the frame, and the
receiver will response back one by one. A sequence for response back is
contained in the header, so the receiver knows when to access the network to
avoid collision. If all receivers need to response with the ACK packet, then it'll
consume huge bandwidth; to solve this problem, one receiver can be elected as
a representative to response with the ACK - Lead Based Protocol. Other ways
are probability based feedback or delay-based protocol - the mobile devices will
wait a random period of time before sending the ACK or based on a probability.
The Leader Based Protocol performs better than other protocols, but it has major
drawback in that when the devices are becoming more mobile, the election
problem becomes prominent.
5
l
NACK tone is also proposed to make a reliable multicast. The NACK tone needs
a separate channel to send the tone. If the receiver finds error in the multicast
frame, it'll send a tone on that channel. The advantage of the tone is several
mobile stations can send the tone and the transmitter is still able to sense that
channel and find the tone since it's just a sin wave. If the transmitter senses the
tone, then it knows one of the receivers hasn't received the frame correctly.
Multicast protocol are very useful in certain applications, such as voice
conference, these applications are characterized by a few source of information
and large number of receivers.
2.3 Voice over IP Packet Formats
Voice over IP payload data is carried over RTP/UDPIIP packets; the
corresponding header formats are defined in [5], [6] and [RTP). The voice
payload data rate varies depending on which CODEC being used, as an
example; G.729A produces 8K bits per second data rate during conversation. If
the voice is sampled at every 30 milliseconds, then the voice payload data in
each packet is 30 bytes. Small packet size and short intervals between
subsequent packets are 2 main characteristics in the voice over IP packet
streams. In real-time environment, due to human ear sensitivity, large delays of
packets (> 200ms round trip) are not tolerated; this makes the late packets
virtually unusable and often simply discarded. Normal error recovery scheme
6
also faces this challenge, since it usually involves feedback and correction and
turn-around time may not be able to satisfy the strict timing requirements.
In a Wireless Ad-Hoc network, the error recovery scheme faces more challenges.
In addition to the feedback plus recovery turn-around time, the wireless mobile
station has to contend to access the medium every time; this could lead to back
off, increase in packet backlogs and packet drops. On-site packet error recovery
by the receiver is much preferred than going back to the transmitter.
2.3.1 IPv4 Header Format
Header checksum
Source IP address
Figure 2-1 IPv4 Header Format
In voice over IP packets, some fields remain unchanged during one session and
some are changed in a predictable way [3].Fields of interest to this project are
described below.
Time To Live (TIL): The value in TTL field will be decreased by 1 every time a
router or a relaying node forwards the packet. When TIL value reaches 0 then
the packet will be destroyed. TIL value determines the maximum hops a packet
can travel through the network, depending on which operating system is used in
7
the source, the TTL values are set differently, for example, Windows XP/2000
sets the TTL to be 128 by default, while the Linux system sets the TTL value to
64 by default. In wireless network, the TTL value for a specific mobile node
should remain the same if there is no change in the routing.
Identification Field (IP-ID): IP-ID usually starts with a random value on the source
and increased by 1 for every IP packet generated. If the VolP packets are the
only packets that's generated from the source, then the IP-ID for subsequent
packets are always increased by 1. If the source not only generate VolP packets
but also have other transactions such as email or control packets, then the IP-ID
value for the VolP packet stream will increase by more than 1 depending on how
many packets are sent in between.
Source IP Address is the IP address of the source, in voice conference
applications; it usually is the mixer computer. The destination IP address is the
target multicast IP address. These addresses remain the same for all forwarded
packets belonging to the same stream.
2.3.2 UDP Header Format
Figure 2-2 UDP Header Format
The UDP header checksum field is the 16-bit one's complement of the one's
complement sum of a pseudo header of information from the IP header, the UDP
8
•
header, and the data, padded with zero octets at the end (if necessary) to make
a multiple of two octets [6]. The pseudo IP header contains the source IP
address, Destination IP address, protocol and UDP length; this means.that IP-ID
is not protected by the UDP checksum field.
2.3.3 RTP Packet Header Format
Figure 2-3 RTP Header Format
The Timestamp reflects the sampling instant of the first octet in the RTP data
packet. For example, voice sampling rate is usually 8k Hz, when the packet is
generated every 20 ms, then the Timestamp in the consequent packet would be
the value in the preceding packet plus 160 (= 8 samples per millisecond * 20
millisecond).
The Sequence Number increments by one for every packet generated by the
source node with initial value set to a random number.
2.4 Compressed RTP Protocol (CRTP)
Compressed RTP Protocol is based on the observation that more than half of the
RTP/UDP/IP packet header fields are constant values over the life of the
connection [1]; some other fields are changing in a predictable way, more
specifically their first order difference being a constant, such as RTP Sequence
9
r
Number. When this is the case, a compressor and decompressor can negotiate
and maintain a context with these values, then the compressor doesn't need to
send these values over the link and decompressor can derive the value based on
the shared context. For example, if the delta value remains to be 1 between IP-ID
fields, then compressor wouldn't need to send the delta value of IP-ID and the
decompressor still able to restore the correct IP-ID value by incrementing the IP
ID value of the previous packet by one.
The compressor uses an 8 bit or 16 bit Context ID (CID) to identify the context
the decompressor should use. The compressor also sends a 4 bit link sequence
number for the decompressor to detect packet losses. When there is no UDP
checksum field exists, the RTP/UDPIIP packet header can be compressed to 2
bytes; 1 byte for the CID and 1 byte for the link sequence, if UDP checksum
exists then another 2 bytes are added.
When the decompressor detects that the link sequence number in the
compressed packet header is not sequential, then packets might be lost in
transmission. If the UDP checksum exists, then the decompressor may perform
"TWICE" algorithm, basically apply the delta value twice or multiple times,
depending on the differences in the link sequence number. Then it uses the UDP
checksum to validate the reconstructed packet. This technique won't work if there
is no UDP checksum exist, or the IP-ID is not incrementing by one as the case
10
-
when the source has other IP datagram sent out at the same time, since the
checksum wouldn't cover the IP-ID fields.
In the wireless ad-hoc network, although the source may always generate
packets with sequence number incremented by one, due to packet error rate,
some packets will be lost during transmission. If the receiving node has to
forward the packets to its downstream nodes, then it also needs to update the
delta value to reflect the missing packets. When these packets get lost, then the
context would be out of synchronization as well and the decompressor has to
wait for the context refresh packet to setup the correct context.
2.5 Enhanced Compressed RTP Protocol (ECRTP)
The Enhanced CRTP protocol is to solve the problem that context in CRTP
protocol is prone to corruption [2]. There are three major enhancements to the
CRTP protocol. First, it allows individual absolute values to be updated in the
compressed packets; this addresses the needs when some field is not following
the pattern, e.g. IP-ID not incr:emented by one, then absolute value for IP-ID can
be carried to the decompressor without full refreshments. Second, a
HDRCKSUM field is added to the compressed packet when the UDP header
checksum doesn't exist or being 0, the HDRCHKSUM is required to validate the
reconstructed packets after using TWICE algorithm, which is not possible if the
UDP Checksum field is o. The third enhancement is the robustness in
operations, it recommends the compressor to send N+1 times the absolute value
of pattern changed fields, value N is an implementation-detail parameter that it's
11
..
unlikely N consequent packets will get lost, this is so that at least one packet will
arrive the decompressor and get context updated.
The RFC 3545 introduced enhancements in the CRTP protocol after the Robust
Header Compression standards is published. Although Robust Header
Compressor protocol has better compression rate and more robust than both
CRTP and enhanced CRTP, CRTP protocol has its market place since it was
introduced earlier than ROHC and relatively simple to implement. The Enhanced
CRTP protocol and ROHC protocol are both proposed to be header suppression
protocol for the IEEE 802.16 convergence sub-layer.
2.6 Robust Header Compression (ROHC)
Robust Header Compression is designed with wireless communication into
consideration. Rather than applying the delta values to the field as CRTP
protocol, the ROHC protocol uses the following encoding methods [3]:
2.6.1 Least Significant Bits (LSB) encoding
LSB is used for header fields whose values are usually subject to small changes.
With LSB encoding, the k least significant bits of the field value are transmitted
instead of the original field value, where k is a positive integer. After receiving k
bits, the decompressor derives the original value using a previously received
value as reference (v_ref), and find out a value within the window [v_ref - p,
v_ref+(2Ak-1) - p] whose last k bits matches the received k bits from compressor.
12
The scheme is guaranteed to be correct if the compressor and the decompressor
each use interpretation intervals
1) in which the original value resides and
2) In which the original value is the only value that has the exact same k
least significant bits as those transmitted.
Since the LSB encoding doesn't rely on the first order difference being constant,
it doesn't need to update the context between compressor and decompressor
when the first order difference changes, this is an improvement over the CRTP
protocol. With less context updates, the probability for context being corrupted is
minimized.
2.6.2 Window-based LSB encoding (W-LSB encoding)
W-LSB encoding is a further modification of the LSB encoding to achieve
robustness. The compressor maintain a list of v_ref values that the
decompressor may have, then calculate out the number k so that when the
decompressor receives the transmitted k bits least significant bit for that field, it'll
be able to derive the right value no matter which v_ref the decompressor will use,
as long as the v_ref value is within the window in the compressor.
The RTP Sequence Number field is compressed using W-LSB encoding scheme.
The offset of the IP-ID and Sequence Number is also compressed using W-LSB
rather than the IP-ID itself gets compressed. This is because the variation of the
offset is smaller than the IP-ID itself, so it's more efficient to compress the offset
rather than the IP-ID. There are two ways of compressing the Timestamp field in
13
the ROHC protocol, one is scaled RTP Timestamp encoding, the Timestamp field
value gets divided by a time stamp stride, and the scaled down value will use the
W-LSB encoding method. The time stamp stride value is discussed as in 2.3.3.
The Timer-based compression requires the packet gets delivered to the
decompressor in a bounded period, then the decompressor first guess what the
Timestamp value would be and uses the transmitted field to finalize the value.
This scheme has several benefits over the scaled Timestamp compression,
however it requires the packet to be delivered within a bounded period and the
compressor also has to have knowledge of that period, usually from the feedback
from decompressor. In a wireless ad-hoc network, due to the network dynamics,
sometimes it's hard to have a bounded packet delivery time, so we think the
scaled Timestamp encoding is more suitable for the target application and we will
focus on the scaled Timestamp encoding method for the rest of the project.
14
2.6.3 States and Operations
The ROHC protocol has 3 modes for operations namely Unidirectional Mode,
Optimistic Mode and Reliable Mode. The Optimistic Mode and Reliable Mode
requires a bi-directional channel so that the decompressor can update the
compressor of the context status, and compressor will adjust packet content and
compression rate using these feedbacks; while in Unidirectional Mode the
compressor and decompressor working on a unidirectional channel which the
decompressor couldn't provide feedbacks to the compressor. The multicast
application in the ad-hoc wireless network has to use the unidirectional mode for
ROHC protocol. There are also 3 states in all 3 modes: Initialization and Refresh
(IR) state, First Order (FO) state and Second Order (SO) state. The compressor
always start with IR state to setup the context, then move to FO state with some
compression or SO state with the best compression rate. The switch from one
state to another is mainly based on feedbacks, when there is no feedback
available such as in unidirectional channel then up to the compressor to decide
when it feels confident that the decompressor have received all necessarily
information so it's implementation dependent.
+----------+ +----------+I IR State I <--------> I PO State I <-------->+ - -- - --- - - -+ +- - - - - - -- --+
Figure 2-4. ROHC State Transition Diagram
+----------+I so State I+----------+
In the unidirectional mode the compressor needs to switch back to IR state
periodically in case the decompressor loses its context.
15
..
2.6.4 Packet Format
The IR and IR-DYN packet are to establish the context between compressor and
decompressor. Both packet types have an 8-bit CRC field to protect the header.
In wireless multicast voice over IP application, the compressor need to be in the
Unidirectional Mode assuming the feedback from the decompressor are not
easily available, so the UO-O, UO-1, UO-1-ID, UO-1-TS, UOR-2, UOR-2-ID,
UOR-2-TS packet type and their extension formats will be used. The entire
Unidirectional Mode packet type °and 1 have a 3-bit CRC field, packet type 2
has a 7-bit CRC field. The CRC is calculated on the uncompressed packet
header so that the decompressor can validate the derived packet header.
2.7 Current Work
The ROHC protocol is to address the bandwidth problem in a wireless network
by compressing the headers. In the wired networks such as Internet, ROHC
protocol is not popular because 1) bandwidth is abundant 2) the error rate is very
low 3) it requires changes on the routers, so ROHC is rarely put into use. CRTP
protocol is supported by Linux, but there is no production-ready software stack
for ROHC protocol in open source community. Most of the research work with
regard to ROHC protocol is focusing on how to implement ROHC in different
networks, such as GSM, UMTS radio links and etc [19] [10] [12] [13]. [17] shows
an analytical model for the performance improvements on W-LSB algorithm. [21]
evaluates the voice quality using ROHC. Most of the papers are using NS-2 as
simulation software to validate their results.
16
-
3 ENHANCEMENTS TO ROHC PROTOCOL IN MANET
The aim of the enhancements to the ROHC protocol is mainly to find a way to
use the redundant packets in the wireless medium to increase the robustness of
the protocol. In the mobile ad-hoc network, depending on the position, some
mobile stations can hear the transmission from other mobile stations. In fact,
regardless whether the multicast structure is a tree structure, mesh based
structure or core based structure, since the wireless medium is broadcasting by
nature, so it's always possible for a mobile station to sniff a packet sent by
another mobile station. In some multicast protocol, this is a feature, for example
the mesh-based protocol; some are just the fact that the listening mobile station
is within the range of the transmitter.
I.~·/ \ /.~.. ~ ~
Figure 3-1. Mobile Multicast Network
Although conceptually it's the same voice over IP packet that's forwarded by the
relaying nodes, however, since each link has compression protocol running on it
and each link has a different characteristics such as error rate, different
17
c
compression packet types will be used, so the physical packet in binary format
are actually different from link to link.
The following sections present the analysis on the compressed packets and then
propose a technique as well as procedure to decompress the packets intercepted
from the air interface.
3. 1 Decompressor Context Comparison
The following table compares the contexts for the same voice over IP stream but
in different compressors:
Field Name Properties On differentcompressors
1 IP Header Fields: Version, IHL, These fields Same ValuesTOS, Flags, Fragment Offset, remain the sameProtocol, Source IP address value over theDestination IP address whole session
2 UDP Header Fields: These fields Same ValuesSource Port, Destination Port, remain the sameLength value over the
whole session3 RTP Header Fields: These fields Same Values
Ver., P, X remain the samevalue over thewhole session
4 RTP Time Stride Same5 RTP Timestamp Offset Same6 TTL Maybe different7 IP-Identification Used to calculate Maybe different
out the new IP-ID8 RTP Sequence Number Used to calculate Maybe different
out the new RTPSN
9 RTP Timestamp Used to calculate Maybe differentout the new RTPTS
Table 3-1 Decompressor Context Comparison
We have the following properties based on above table:
18
1. Fields in row 1, 2, 3 are common between contexts in different compressors
for the same voice over IP stream.
2. RTP Time Stride and RTP Timestamp Offset are the same value in different
contexts as well. This is because the RTP Time Stride is defined in the source
node; the RTP Timestamp Offset should be the same value as well.
RTP Timestamp Offset = RTP Timestamp modulo RTP Time Stride
3. TIL value could be different from link to link; each node will decrease the TTL
value by 1 when it forwards it. How to deal with TTL value is discussed in
following sections.
4. Every decompressor keep a reference IP-ID, RTP SN and RTP TS, if a
compressed packet has a eRe field, then a successful decompression
validated by the eRe will update the IP-ID, SN and TS value in the context as
reference value for the following decompressions. Since all links has packet
error rate associated the IP-ID, SN and TS value in contexts on different
compressors might be different. The impact of that will be analyzed in
following sections as well.
3.2 IP Time to Live Field Derivation
The Time to Live field value is decremented by 1 on every forwarding mobile
station (figure 3-2). When node-2 overhears the compressed packet from node-3
to node-4, the eRe value in the compressed packet is calculated using the
header with TIL= 58 instead of TIL = 60. Assuming the node-2 being able to
decompress all the remaining fields, when node-2 tries to validate the derived
packet by recalculate the eRe using TTL = 60, it will fail the validation.
19
..
o
,
1
/ .....•. ·\'.59 3~t:7'\ '- ,-,,-' \ ITL.=58ITL=60
... 2
4'Figure 3-2 TTL Value Decrement in MANET
To solve this problem, node-2 needs to obtain the TIL value on node-3 in
advance using following procedures:
1. Node 2 maintain a cache list of certain number of successfully
decompressed packets
2. Node 2 obtain a packet "p3" from node-3
3. Node 2 compare the p3 payload data with the packets in the cache list, if
the payload data matches (to packet p2), then proceed with step 4,
otherwise go back to step 2
4. Node 2 calculate the eRe using existing packet header in p2, compare
the eRe with the eRe in p3, if it matches then TTL value on node-3 is the
same value as the value in p2
5. Node 2 decrement or increment the TIL value in p2 and repeat step 4.
The number of times to repeat in step 4 and 5 are system dependant.
20
..
It's possible that by following the steps above lead to a false TTL value. Figure 3-
3 shows the differences between a CRC-3 for a given TTL value and a CRC-3 for
the give TTL - 1. TTL =64,63 and TTL =192, 191 will generate the same CRC-
3. Figure 3-4 shows the CRC difference between TTL and TTL - 2, and TTL =
129,127 has the same CRC-3 value. For CRC-7 though the smallest TTL
difference which can lead to same CRC-7 value is 13.
4
Figure 3-3 CRC-3 Differences for Adjacent TIL Values
I-series, I
~ '" ....
"' "' '"..... en " l() ('t) .....co <0 ,... co 0) 0..... ..... ..... .... ..... N
I-Series, I
Figure 3-4 CRC-3 Differences for TTL Values of Offset 2
The following conclusions can be drawn based on the analysis:
21
..
1. If the node-2 can overhear the IR or IR-DYN packet from node-3 sends out,
then node-2 can get the right TIL value.
2. Node-2 might able to derive the right TIL value if it can sniff a packet from
node-3 corresponding to a successfully decompressed packet in node-2.
3. If node-3 uses CRC-7 instead of CRC-3, i.e., it uses type 2 packet instead of
type 0,1, then node 2 can correctly derive the TIL value on node-3 as long as
the hope difference is less than 13.
4. If the source of the voice over IP application, e.g. the RTP mixer in voice
conference uses TIL starting from values other than 64 or 192, then the
probability for the node-2 to get a correct TIL value can be increased. As an
example, if the RTP mixer uses TIL = 63, then node-2 can calculate out the
TIL value on node-3 if the difference is no greater than 2.
5. If node-2 is a leaf node rather than a forwarding node, then node-2 can ignore
the whole TTL value calculation errors.
Using the procedures described above, node-2 can derive a TIL value,
depending on the CRC type node-3 uses the TIL value derived could be a wrong
value, however node-2 can always use the derived TIL value to do validation for
the decompression of the packets intercepted from node-3 and the validation
would have the same result.
Since the TIL value is the relatively constant comparing to other changing fields,
it's a low density task - once it's calculated it can be assumed that it'll stay the
22
..
same as long as routing doesn't change and CPU burden is low. However in a
high mobility network this value has to be constantly monitored.
3.3 Identifying the Right Data Stream
The same voice over IP data stream should carry the payload data when
forwarded by mobile stations. When a mobile station tries to identify the
intercepted packet, it should keep a cache for successfully decoded packets and
then compare the payload data of intercepted packet with the cached packets. If
it matches then it's a positive sign that the intercepted packet belongs to the
same stream. The intercepting node can also derive from this packet that how
long the intercepted node is behind the intercepting node with regard to the
packet stream. The intercepting node should also keep a cache list for those
intercepted packets as well if the intercepted node is actually ahead of the
intercepting node.
The number of the successfully decoded packets to put on the cache list and the
number of intercepted packets to put on the list will be a system specific setting,
normally the intercepting node should set it to a number bigger than the window
in the W-LSB, so that if they can be identified as the same stream, it's possible to
process or decode the intercepted packet. The more packets on the list provide
more capability to identify packet streams with other nodes, but it'll consume
more physical memory, more power consumption and more CPU cycles.
23
..
The stream identification is one time only process: once the intercepting node
identifies an intercepted packet belonging to the same voice over IP stream, it
should record the MAC address of the sending node and Context ID into the
memory for future reference. Every time when a packet is intercepted, the MAC
address and Context ID of the packet (if it's a compressed packet) should be
checked against that array in the memory first to see if it belongs to the same
data stream.
3.4 Block Diagrams for the Proposed Technique
The following 4 lists are referenced in the diagrams, their definitions are:
List A: A cache list for all successfully decoded packets. The numbers of packetson the list are defined by the system implementation.
List B: A cache list for all intercepted packets. If there is a payload data match inthe packet on this list to the packets on list A, then the MAC address andCID of the matching packet of list B will be stored on List C. The numberof cached packets is a system parameter.
List C: Maintains a list of MAC and CID pair for those matching packets in List B.There are one or more list items for a MAC and CID pair. If the number ofMAC and CID pair exceeds N then the specific MAC and CID pair ismoved to List D. N is a system parameter.
List D: Maintains a list for MAC and CID pair which carries the same voice datastream that the node is dealing with. If an intercepted packet has the MACand CID pair on this list, then it's a candidate to be decoded.
24
Start of Packet StreamIdentification Process
put packet on listB
N
intercepted packet
L------'j'-------1'---N----,
ntercepted packet orreal received packet
y
Payload datamatch?
y
Packetsuccessfullydecoded?
C1W many match habeen found for aMAC&CID pair?
Match no. > N
Move theMAC&CID pairtolist D, consider a Match no. < Ncomplete matchand no checkingfor that stream
anymore
y
Too manypackets on list
B?
Delete packet withearliest timestamp
End
Figure 3-5 Packet Stream Identification Diagram
25
Start of Interceptedpacket decoding
process
packet interceptedCRC passed?
is theMAC&CID in
the list D?forward the packetif the packet hasn't
been previouslydecoded
is the TILvalue derived?
derive the contextusing context inexisting stream
ma t e contextto be the reference
context for thenext acket
decode the packet
end
Figure 3-6 Intercepted Packet Decoding Process
26
Start of TTL derivationProcess
packet intercepted
MAC&CIDinlist D?
y
TTL derived?
N
set TTL value =TTL value in thereference packet
generate the CRCusing list A packet
header withcurrent TTL value
egenerated CRmatch the CRC in
. tercepted packe .
y
save the TTLvalue as
End
tried enough times?
increase the TTLvalue by 1 or
decrease by 1
y
Figure 3-7 TTL Derivation Diagram
3.5 User Scenarios for ROHC Enhancements
There are several scenarios that could benefit from applying the proposed
enhancements:
3.5.1 Hopping Scenario
27
In Figure 3-8, node-3 can both hear from node 1 and node 2 and the multicast
configures the node-2 being the parent of node-3.
,,,
o
,~I,
Figure 3-8 Hopping Scenario
Node-1 will multicast to node-5 and node-2 multicasts to node-3, 4. Node-3 might
receive duplicated packets from both node-1 and node-2. In this case, node-3
can frequently hop between node-1 and node-2 as the source of the data stream
compressor: if the packet comes from node-2 first, then node-3 will try to
decompress the packet from node-2, if it then intercepts a packet from node-1
earlier than from node-2, node-3 can create a context to decompress the packets
from node-2 from the context for node-2. Note this is different than node-3
decompressing every packet from node-1 and node-2 in two aspects: first, node-
3 doesn't need to decompress the duplicated packets, which saves power and
CPU cycle, second, most importantly, using the proposed technique, if the
context is corrupted for one node, node-3 can always use the context for the
other node to recover the corrupted context, as long as they don't corrupt at the
same time, the context will be valid one or the other. This is contrary to using the
28
existing RFC, where the context can go corrupted one after another and both
become unusable until the refreshment is done.
3.5.2 Jamming Scenario
In Figure 3-9, ndoe-3 is a decompressor of node-2 but can overhear the
transmission from node-5. Normally node-2 is always the compressor for node-3
since the packet from node-2 is ahead of node-5. Node-3 will keep a cache of
decoded packets in its cache list. When the link from node-2 is jammed or node-
2 goes down without notification, node-3 can use the new technique and create a
context for node-5 then decompress the packet from node-5.
Figure 3-9 Jamming Scenario
3.5.3 Roaming Scenario
In Figure 3-10, mobile station 6 is associated with node-4, when it's moving it'll
be able to hear packets from node-3. Node-6 can decide to decompress the
packets from node-3 instead of node-4. This would be a useful since the
multicast tree setup and update could take time and the ability that node-6
decompress packet before it's officially associated with node-3.
29
- ....
/~t~1
........
o
Figure 3-10 Roaming Scenario
3.6 Security Considerations
A malicious node can fake a compressor and make others to decompress the
packets from the attacking node and potentially changing contents. When a
regular decompressor moves to an intercepted compressor, care must be taken
if the intercepting node is also relaying the packets. The packets relayed by the
intercepting node may affect or lure other nodes to this compressor without
proper topology update protocol in place, which will affect all downstream nodes.
It's less of a concern if the intercepting node is a leaf-node only.
30
4 SIMULATIONS
This section will present the simulation environment including the software stack
development used to validate the project.
4. 1 ROHC RTP Profile Software Stack
The ROHC RTP profile software stack is developed by the author to validate
project proposal. The programming was based on an open source stack in [8]
archived in sourceforge.net. The original software stack was developed by
several students in Sweden and has IP, UDP and Uncompressed profile in it.
Since ROHC is not popular on Internet, there is no other complete open source
ROHC software stack available.
The RTP profile software stack developed by author supports Unidirectional
Mode and 3 states. The stack was designed to run in both kernel mode and user
mode as well, since it's easier to test the stack in user mode and don't crash the
kernel. The software testing environment for the software stack is using 4000
trace files; each trace file contains an RTP packet created by RTP application
and has 40 bytes payload data in it. The payload data are randomized so that the
UDP header checksum are different from packet to packet.
An extra layer on top of this software is created so that the software stack can be
used in a NS-2 simulation environment. The RTP software stack is compiled into
a library and used by the NS-2 simulation software.
31
4.2 NS-2 Simulation Software
The NS-2 simulation software is used to run the simulation. It's a C++ to run the
simulation with O-TCl as the front-end to setup the simulation environment. The
simulation uses a wireless extension created by Carnegie Mellon University, and
Wireless Multicast Extensions for ns-2.1 b8 version by Monarch Project. The
Wireless Multicast Extensions to ns-2 inelude implementations of the Adaptive
Demand-Driver Multicast Routing protocol (ADMR) and the On-Demand
Multicast Routing Protocol (ODMRP) for routing in wireless multi-hop ad hoc
networks. The ODMRP protocol is used in the simulation for the proposed
technique.
Following is the table of all software versions used for this project. The CVS
server is used to store all the changes and modifications to the stacks to support
ROHC simulation.
Software Package ....Fedora CoregccROHC software from sourceforQeNS-2TeltelelTel-debugO-TelTKCVS
Version23.3.31.02.1b88.4.51.162.01.98.4.51.11.15
Table 4-1 Software Version Matrix
32
The following models and values were applied in the simulation:
... .'....... < l'Jdl"o:>e «ii . !«.!Fi.i!<!. i< .:. i< ,.Channel Model ChannellWirelessChannelPropagation TwoRayGroundMac Layer Mac/802 11Queue Queue/DropTail/PriQueueAntenna Antenna/OmniAntennaAntenna location 0,0,1.5Antenna gain 1.0,1.0LL mindelay 25usLL maxdelay 50usPhysical layer PhylWirelessPhyPhy CPThresh 10.0Phy CSThresh 1.55ge-11Phy RXThresh 3.652e-10Phy Rb 2*1e6Phy Pt 0.2818Phy Freq 2400e+6Error model ErrorModel/UniformCBR Packet Size 40 bytesCBR Packet Interval 0.25 secondCBR random False
Table 4-2 Simulation Model and Value Matrix
4.3 Simulation Results
4.3.1 Simulation for Hopping Scenario
The simulation was setup as in Figure 4-1; node-O is the source of the voice
stream for the multicast tree. Node-1 and node-2 are the forwarding nodes and
node-3 is within the range of both node-1 and node-2. node-4 and node-5 are the
leaf nodes of node-2 and node-1 respectively. The distances are chosen such
that node-5 can only hear from node-1 instead of node-O, so that node-1 will
have a leaf node and continue to forward packets.
33
,,~I,
P ""', ...
Figure 4-1 Simulation Setup for Hopping Scenario
The simulation for the hopping scenario uses a packet error rate model which
applies for all links. The simulations were run using packet error rate from 5% to
25% to identify the gain from using the proposed technique versus none hopping
scenario.
34 j
Node-3 Overall Packet Error Rate
0.6--Packet Error Rate With
0.5 -- Interception--p /,/
~.4/
- - - Packet Error Rater / Without Interception--'
~0.3--/
........ -. _. Theoretical Packet~ ........ Error Rate With~0.2
........ Interception
0.1 ---- Theoretical PacketError Rate WithoutInterception
00.05 0.1 0.15 0.2 0.25
Link Error Rate
Figure 4-2 Packet Intervals in Hopping Scenario
As we can see in Figure 4-2, the top two lines are the average packet interval
with hopping enabled for node-3 and packet error rate without hopping enabled
on different error rates. As the error rates go higher, in both cases the end to end
packet error rate increases. However for any given link error rate, the packet loss
rate in hopping scenario is always lower than the packet error rate without
hopping capability.
It's also noted that in this scenario node-3 is a leaf node so it's not forwarding
packets actively to downstream nodes. If it's a forwarding node then the gains by
decoding the intercepted packets can be propagated to its downstream nodes as
well.
35
4.3.2 Simulation for Roaming Scenario
The simulation for the roaming scenario is setup as in Figure 4-3, node-6 ismoving from a location close to node-4 to node-1 .
o
Figure 4-3 Simulation Setup for Roaming Scenario
Roaming Simulations
4
3:E...oII)II)
l!! 2c.Eoo
a10 <0 0> N co co 10 ~ <0 co 10 10 l"'- e ("t) 10 10 10 10 ("t) ("t) CC! co...... -.i ...... e ("t) N co ...... -.i ("t) "<t ("t) cO 0> N 10 co -.i <0 0>...... N N N ("t) ("t) "<t "<t "<t 10 10 10 <0 <0 <0
Time
Figure 4-4 Compressor Id for Node_6
36
J
In Figure 4-4, we plot out the compressor id for the node_6 as it moves towards
node 2. It shows that the node starts with associating with node 1 and then at- -
the end it uses node_2 as its compressor. In the middle it's switching from node-
1 and node-2 quite often since the stack was setup that whenever it receives a
new packet it'll treat the sender as the main compressor without waiting for the its
primary compressor to timeout. So depending on whether node-1 sends out
packet earlier than node-2, it'll become the primary compressor for the moving
node. Node-3 has become a compressor for node-6 during a period, due to the
fact that node-3 has to send out the packet to detect whether it has leaf node or
not, regardless it doesn't have a leaf node in simulation.
4.3.3 100 Node Simulation Results
A 1DO-node simulation is done with nodes in random motion. The data points are
taken from different nodes to represent different topologies. The diagram bellows
show that:
1. Nodes can do context switches by sniffering the air interface. There are
often 5 - 6 transmitters that a node can overhear, on average a node can
expect to overheard transmissions from 2 to 3 nodes including the
designated transmitter.
2. The context switch frequency differs from one node to another. For
example, node_25 locks itself to node_O for a long time, since node_O is
the source of all transmissions, where node_3D gets signal from other
nodes.
37
Node_30 ROHC Sniffering Context Switch
120,.---- ,------------_-,
100 -r-------------------:---=---1
80 +----------Il---lIJ--t---t-I-------+tfft
'C
~ 60 t-~--it-~~~wAWttltt=_tHiH1ttttr~~rHHI-+-SerieS1 I
20 t-it-----------------.IlIr-.----tI~Ht
1 15 29 43 57 71 85 99 113127141 155169183197211225239253267
Packet Id
The 1DO-node simulation demonstrates the node's ability to switch and establish
context for different transmitters in a dynamic topology.
4.3.4 Running Simulation Using Random Seeds
The following chars are running the same 100 node simulation by using random
seeds. In NS-2, this is achieved using the following commands:
Global defaultRNG
$defaultRNG seed 0
The default seed value in NS-2 is set to 12345, by setting the seed value to 0 it'll
pick a random seed value when NS-2 starts. Following 2 graphs are the capture
of context switch for the node_3D in 2 different runs. It shows that node_3D is
39
120
100
80
~
~ 60oz
40
20
o
Node_25 ROHC Sniffering Context Switch
iIi
,:i' .111
"
15 29 43 57 71 85 99 113127141 155169183197211225239253267
Packet Id
38
I-+-- Series1 I
doing context switch by sniffering the packets when roaming through the
network.
Node_3D Context Switch Capture 1 (Random Seeded)
120
100
80
:5!~ 60oz
40
20
o
,,' ,', .. "\"
':!",i':d::' :' :"I"
::'Y,:,:'::!,,' ',',
- . j rn ' ]"" • 1
11 J.,==,J»l j "III Ii. ..
-IIWiIii
'" , " . ,.. , "... , , .. I" I ,.1, ".Il ", " .1"""., .."".a ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ N v m ro a N v m ro
~ N ~ v m ~ ro ~ ~ ~ ~ ~ ~ ~ ro ~ ~ N ~ ~ ~ ~ ~
Packet Id
5 CONCLUSION
In this project, the author has presented a new technique on ROHC over the
Mobile Ad-Hoc network. The technique involves intercepting the packets over the
air, identify that the packet is belonging to the same stream and restore the
context for future decoding. Simulation shows the improvements and validity of
the proposed technique. The proposed technique is implemented on a node-by-
node basis and serves as an enhancement to the existing protocol. The block
diagrams of how to implement the proposed technique are presented as well.
40
5. 1 Future Works
In the roaming scenario, the node-6 can decompress the packet from node-3
without any action from node-3 in advance. However the node-3 would still follow
standard procedure which sends out IR and IR-DYN packet to node-6 which
waste bandwidth. One solution would be node-6 sends out an explicit packet to
node-3 that it has all the contexts up to date. This would be a recommendation to
the IETF working group.
Another proposal to the IETF task force is to reduce the dependencies on the
context, for example, create a profile and transmit Sequence Number, Time
Stamp and IP-ID field all the time. This will reduce the probability for packets
being dropped because of context corruption, this will also enable the intercepted
packets easier to decode. The proposed RFC may also include TIL field in the
compressed packet since it's prone to change in a wireless network.
In merging stream scenario, it's obvious that by intercepting the streams node-3
is able to collect more data and generate more traffic. By simply applying the
ROHC protocol wouldn't affect the traffic pattern but by utilizing the intercepted
node it will increase the traffic flow on each node. In a multicast network this
increase in the up-stream node will also affect the traffic in the down stream
nodes as well. If the forwarding nodes are not using ROHC as the link layer
compression protocol but still trying to intercept the packets and make use of it,
the same traffic change would still occur.
41 Ii
j
REFERENCES
[1] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headersfor Low-Speed Serial Links", RFC 2508, February 1999.
[2] Koren, T., et ai, "Enhanced Compressed RTP (CRTP) for Links with HighDelay, Packet Loss and Reordering", RFC 3545, July 2003
[3] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H.,Jonsson, L., Hakenberg, R, Koren, T., Le, K., Liu, Z., Martensson, A,
• Miyazaki, A, Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng,"RObust Header Compression (ROHC): Framework and four profiles:RTP, UDP, ESP, and Uncompressed", RFC 3095, July 2001.
[4] Schulzrinne, H., Casner, S., Frederick, Rand V. Jacobson, "RTP: ATransport Protocol for Real-Time Applications", RFC 3550, July 2003.
[5] Postel, J., "Internet Protocol", RFC-791, USC/Information SciencesInstitute, September 1981.
[6] Postel, J., "User Datagram Protocol", RFC-768, USC/InformationSciences Institute, August 1980.
[7] Corson, S., Macker, J., "Mobile Ad hoc Networking (MANET): RoutingProtocol Performance Issues and Evaluation Considerations", RFC-2501,Naval Research Laboratory, January 1999
[8] http://sourceforge.netlprojects/rohc
[9] Jin, H.; Hsu, R; Jun Wang, "Performance comparison of headercompression schemes for RTP/UDP/IP packets", WirelessCommunications and Networking Conference, 2004. WCNC. 2004 IEEEVolume 3, 21-25 March 2004 Page(s):1691 - 1696 Vol.3
[10] Taylor, D.E.; Herkersdorf, A; Doring, A; Dittmann, G., "Robust HeaderCompression (ROHC) in Next-Generation Network Processors",Networking, IEEE/ACM Transactions, Volume 13, Issue 4, Aug. 2005Page(s):755 - 768
[11] Seeling, P.; Reisslein, M.; Fitzek, F.H.P.; Hendrata, S., "Video qualityevaluation for wireless transmission with robust header compression",Information, Communications and Signal Processing, 2003 and theFourth Pacific Rim Conference on Multimedia. Proceedings of the 2003Joint Conference of the Fourth International Conference, Volume 3, 1518 Dec. 2003 Page(s):1346 - 1350 vol.3
[12] Minaburo, AC.; Singh, K.D.; Toutain, L.; Nuaymi, L., "Proposed behaviorfor robust header compression over a radio link", Communications, 2004
42
IEEE International Conference, Volume 7, 20-24 June 2004Page(s):4222 - 4226 Vol.7
[13] Minaburo, A.; Nuaymi, L.; Kamal Deep Singh; Toutain, L., "Configurationand analysis of robust header compression in UMTS", Personal, Indoorand Mobile Radio Communications, 2003. PIMRC 2003. 14th IEEEProceedings, Volume 3, 7-10 Sept. 2003 Page(s):2402 - 2406 vol.3
[14] Hui Wang; Li, J.S.; Hong, P.L., "Performance analysis of ROHC U-modein wireless links", Communications, lEE Proceedings, Volume 151, Issue6, 24 Dec. 2004 Page(s):549 - 551
[15] Minaburo, A.; Toutain, L.; Nuaymi, L., "Deployment of IPv6 robust headercompression profiles 1 and 2", Computer Science, 2003. ENC 2003.Proceedings of the Fourth Mexican International Conference, 8-12 Sept.2003 Page(s):278 - 283
[16] Wang, B.; Schwefel, H.P.; Chua, K.C.; Kutka, R.; Schmidt, C., "Onimplementation and improvement of robust header compression inUMTS", Personal, Indoor and Mobile Radio Communications, 2002. The13th IEEE International Symposium, Volume 3, 15-18 Sept. 2002Page(s):1151 -1155 vol.3
[17] Wang, H.; Seah, K.G., "An analytical model for the ROHC RTP profile",Wireless Communications and Networking Conference, 2004. WCNC.2004 IEEE, Volume 1, 21-25 March 2004 Page(s):126 -131 Vol.1
[18] Zhanping Yin; Leung, V.C.M., "A proxy architecture to enhance theperformance ofWAP 2.0 by data compression", WirelessCommunications and Networking, 2003. WCNC 2003. 2003 IEEE,Volume 2, 16-20 March 2003 Page(s):1322 - 1327 vol.2
[19] Boggia, G.; Camarda, P.; Squeo, V.G., "ROHC+: a new headercompression scheme for TCP streams in 3G wireless systems",Communications, 2002. ICC 2002. IEEE International Conference,Volume 5, 28 April-2 May 2002 Page(s):3271 - 3278 vol.5
[20] Camarda, P.; Petrizzelli, S., "Performance analysis of a new headercompression scheme for TCP streams in IP based wireless networks",MILCOM 2002. Proceedings, Volume 1, 7-10 Oct. 2002 Page(s):276281 vol.1
[21] Rein, S.; Fitzek, F.H.P.; Reisslein, M., "Voice quality evaluation inwireless packet communication systems: a tutorial and performanceresults for RHC", Wireless Communications, IEEE [see also IEEEPersonal Communications], Volume 12, Issue 1, Feb. 2005 Page(s):6067
43
[22]
[23]
[24]
Giouroukos, N.; Orphanos, G., "An implementation of ROHC forTCPIIPv6", Wireless Ad-Hoc Networks, 2004 International Workshop onMay 31 - June 3, 2004 Page(s):16 -19
Chia Yuan Cho; Hazra, S.K.; Seah, W.K.G., "Exploiting inter-flowredundancy: context replication in ROHC-TCP", GlobalTelecommunications Conference, 2004. GLOBECOM '04. IEEE, Volume5, 29 Nov.-3 Dec. 2004 Page(s):2749 - 2753 Vol.5
West, M.A.; Conroy, L.W.; Hancock, R.E.; Price, R.; Surtees, A.H., "IPheader and signalling compression for 3G systems", 3G MobileCommunication Technologies, 2002. Third International Conference,(Conf. Pub!. No. 489) 8-10 May 2002 Page(s):102 -106
44
..
top related