•

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, 15­18 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):276­281 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):60­67

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

..