ICT- 619555 RESCUE D3.2 Version 2 - CORDIS...RESCUE D3.2 Version 2.0 Page 1 (79) ICT- 619555 RESCUE D3.2 Version 2.0 Report on revised WP3 architecture including simulation results

RESCUE D3.2 Version 2.0

Page 1 (79)

ICT- 619555 RESCUE

D3.2 Version 2.0

Report on revised WP3 architecture including simulation results

Contractual Date of Delivery to the CEC: 15 July 2015

Actual Date of Delivery to the CEC: 17 July 2015

Delivery of Revised Version to CEC: 18 December 2015

Editor: Olayinka Adigun

Author(s): Marek Natkaniec, Marek Sikora, Katarzyna Kosek-Szott, Szymon Szott,

Łukasz Prasnal, Andrzej R. Pach, Olayinka Adigun, Nikos Karanastasis,

Nikos Pavlatos, Sebastian Kühlmorgen, Andreas Festag, Hicham Khalife,

Jawad Seddar, Matias Brulatout, Ade Irawan, Valtteri Tervo

Participant(s): AGH, UbiTech, TUD, TCS, JAIST, UOULU

Work package: WP3 – Message Transfer

Security: PU

Nature: R

Version: 2.0

Total number of pages: 79

Abstract: This deliverable reports the updates to the RESCUE message transfer architecture and presents

the results of the simulation-based performance evaluation of developed protocols in lossy link

environments. The contributions contained in this deliverable are updates to D3.1 and new simulation

results for three complementary medium access protocols for centralized and distributed networks, two

routing protocols (R-OLSR and geo-routing protocols), two complementary error control methods and a

multirate algorithm.

Keyword list: unpredictable environments, lossy links, medium access, routing, error control, cross-layer

design, rate adaptation

Disclaimer:


Page 2 (79)

Executive Summary

This deliverable reports the updates to the RESCUE message transfer architecture (including MAC and

routing protocols) and presents the design updates with respect to D3.1. It also presents the results of the

simulation-based performance evaluation of the protocols in lossy link environments. The contributions

contained in this deliverable are updates and new simulation results for the following:

Three complementary medium access protocols (one for centralized and two for distributed

networks).

Two complementary routing protocols (based on multipath, link quality and geographical routing).

Two complementary error control methods: for ensuring end-to-end reliability and efficient

retransmissions.

Partial hybrid ARQ with BPSK modulation.

A multirate algorithm for providing improved performance by adapting to channel conditions.

The design details presented in this deliverable will serve as a basis for the implementation and performance

analysis of each component to be reported in D3.3 as well as the implementation and validation of the

integrated components to be performed in WP4.


Page 3 (79)

Authors

Partner Name Phone / Fax / e-mail

AGH University of Science Marek Natkaniec [email protected]

and Technology Marek Sikora [email protected]

Katarzyna Kosek-Szott [email protected]

Szymon Szott [email protected]

Łukasz Prasnal [email protected]

Andrzej R. Pach [email protected]

UbiTech Olayinka Adigun [email protected]

Nikos Karanastasis [email protected]

Nikos Pavlatos [email protected]

Technical University Dresden Sebastian Kühlmorgen [email protected]

(TUD) Andreas Festag [email protected]

Thales Communications & Hicham Khalife [email protected]

Security SAS (TCS) Jawad Seddar [email protected]

Mathias Brulatout [email protected]

Japan Advanced Institute Ade Irawan [email protected]

of Science and Technology

(JAIST)

University of Oulu Valtteri Tervo [email protected]

(UOULU)


Page 4 (79)

Table of Contents

Executive Summary ......................................................................................... 2

Authors.............................................................................................................. 3

List of Acronyms and Abbreviations .............................................................. 6

1. Introduction ................................................................................................. 7

2. Background ................................................................................................. 8

2.1 Design basics ............................................................................................................................... 8 2.2 Frame format ............................................................................................................................... 9 2.3 Toy scenarios ............................................................................................................................. 10 2.4 Large scale scenarios ................................................................................................................. 11

2.4.1 V2V ................................................................................................................................... 11 2.4.2 Public safety ...................................................................................................................... 12

2.5 PHY Black Box ......................................................................................................................... 13 2.5.1 Technical details ............................................................................................................... 14

2.6 Baselines for comparison........................................................................................................... 15 2.7 Simulation parameters ............................................................................................................... 16

3. MAC ............................................................................................................ 18

3.1 SimpleMAC ............................................................................................................................... 18 3.1.1 Protocol overview & design update .................................................................................. 18 3.1.2 Simulation results .............................................................................................................. 19

3.2 Distributed MAC ....................................................................................................................... 24 3.2.1 Protocol overview & design update .................................................................................. 24 3.2.2 Simulation results .............................................................................................................. 26

3.3 Centralized MAC....................................................................................................................... 28 3.3.1 Protocol overview & design update .................................................................................. 28 3.3.2 Simulation results .............................................................................................................. 29

4. Routing ...................................................................................................... 35

4.1 RESCUE Multipath Routing Protocol ....................................................................................... 35 4.1.1 RESCUE Routing Relay approaches ................................................................................ 35 4.1.2 Protocol overview & design update .................................................................................. 35 4.1.3 Simulation results and Performance Analysis ................................................................... 39 4.1.4 Convergence Time ............................................................................................................ 43 4.1.5 Conclusion ........................................................................................................................ 44

4.2 Geo-routing ............................................................................................................................... 44 4.2.1 Services ............................................................................................................................. 45 4.2.2 Protocol overview & design update .................................................................................. 45 4.2.3 Simulation results .............................................................................................................. 47

5. Error control .............................................................................................. 51

5.1 End-to-end ARQ ........................................................................................................................ 51 5.1.1 Protocol overview & design update .................................................................................. 51 5.1.2 Simulation results .............................................................................................................. 52

5.2 Partial ARQ ............................................................................................................................... 58 5.2.1 Protocol overview and design update ................................................................................ 59 5.2.2 Simulation Setup ............................................................................................................... 60 5.2.3 Simulation Results ............................................................................................................ 63

6. Multirate ..................................................................................................... 65

7. Conclusion ................................................................................................ 74

Appendix A. Forwarding Threshold Optimization ....................................... 75


Page 5 (79)

Toy Scenarios ...................................................................................................................................... 75 V2V Scenario ...................................................................................................................................... 77 Summary ............................................................................................................................................. 78

References ...................................................................................................... 79


Page 6 (79)

List of Acronyms and Abbreviations

Term Description

ACK End-to-end acknowledgement

AODV Ad-hoc on-demand distance vector routing

AP Access point

ARQ Automatic repeat request

ARR Advanced relay routing

AWGN Additive white Gaussian noise

B Beacon

BR Beacon repetition

BS Base station

CBF Contention-based forwarding

CC Control channel

CFP Contention free period

CI Confidence indicator

CP Contention period

CW Contention window

CRC Cyclic redundancy check

CSMA Carrier sense multiple access

CSMA/CA Carrier sense multiple access with collision avoidance

D Destination

DC Data channel

ETX Expected Transmission Count

Geo Geographic

GF Greedy forwarding

ID Identifier

IL Interleaver index

LIFS Long interframe space

LLR Log likelihood ratio

LOS Line of sight

LOTF Links on the fly

MAC Medium Access Control

MCS Modulation and coding scheme

MIC Message integrity check

MPR Multi Point Relay

NET Network

OLSR Optimized link state routing

PDR Packet delivery Ratio

PHY Physical

PT Processing time

QoS Quality of service

R Relay

R-OLSR RESCUE-OLSR

RR Resource reservation

RREQ Route request

RTS Routing Toy Scenario

S Sender

SDR Software Defined Radio

SFD Start Frame Delimiter

SGB Simple geo-broadcast

SIFS Short interframe space

SMS Short Message Service

SRR Simple Relay Routing

SSR Source Suggested Routing

STA Station

TC Topology control

TDMA Time division multiple access

TX Transmission


Page 7 (79)

1. Introduction

The RESCUE project focuses on research and innovation regarding the “links on the fly” (LOTF) concept

in wireless networks. The core idea is the utilisation of diversity in communication channels and paths

between communicating devices. This takes advantage of the inherent broadcast nature of the radio

channels and the multi-route diversity of multi-hop ad-hoc networks that have the potential to increase

communication reliability and decrease outage probabilities. The RESCUE project's advancement of the

physical layer technologies and mechanisms requires modification of the message transfer methods, i.e.,

protocols and functionalities provided by the data link and network layers. The goal of WP3 is to provide

a message transfer architecture which allows the use of lossy links and the two characteristics which follow

from this idea: (i) frames with errors are not discarded but should be processed (forwarded) and (ii) due to

these errors, the information stored in typical headers (e.g., the IP destination address) cannot be trusted

(the errors may have occurred there).

In the first WP3 deliverable (D3.1), we presented the initial design of a RESCUE data link and network

architecture which can leverage the gains from using lossy links in communication taking into consideration

the two imminent characteristics above. In this deliverable (D3.2), we present a revised data link and

network layer design and provide simulation results for the proposed protocols and mechanisms. During

the design process, it became clearly evident that the LOTF concept impacts all OSI layers and an integrated

cross-layer design approach is required. However, to maintain compatibility with existing networks we

limit the required revolutionary changes to the two lowest layers (physical and data link). At the network

layer, we have opted to provide a modified routing protocol but otherwise maintain full IP compatibility.

The transport and higher layers remain intact as they are out of the scope of the project.

With these constraints in mind, this deliverable reports the updated protocol designs and architectures with

simulation based performance evaluation. The evaluations presented for the MAC protocols, routing

protocols, error control mechanisms and rate adaptation in this deliverable are all performed using a

harmonised key parameter table with their justifications in section 2.7 and simulations are all performed

using NS3. RESCUE’s modified NS3 platform used in the simulations integrates an abstraction of the

physical layer (an input from WP2), the MAC protocols and Automatic Repeat reQuest (ARQ) or routing

protocols in order to properly access the concept of RECUE’s lossy forwarding. Section 2 provides a

background and overview of fundamentals required to understand the basics of message transfer in a lossy-

link network. Section 3 presents details of the Simple MAC, Distributed MAC and Centralised MAC with

their respective simulation-based performance evaluation. Section 4 provides details of RESCUE's routing

protocols: RESCUE-OLSR (R-OLSR), based on a multipath link-quality approach using the Expected

Transmission Count (ETX) as a link quality metric, and Georouting, based on a geographical routing

approach, with their performance evaluations. Section 5 provides details of the error control mechanisms

with the end-to-end ARQ (Automatic Repeat reQuest) and the Partial ARQ with their evaluations using

simulations. In Section 6, we describe another mechanism for improving performance based on appropriate

data rate selection. Finally, Section 7 provides a conclusion and summary for deliverable D3.2.


Page 8 (79)

2. Background

In this section we concisely report on the basics of message transfer in RESCUE, the established frame

format, the consolidated toy scenarios, the large-scale scenarios, the physical layer abstraction, and the

baselines for comparison. The information provided in this section serves as a basis for understanding the

protocol designs provided in the subsequent sections.

2.1 Design basics

As explained in D3.1, the RESCUE message transfer design considers packet-based channel access in the

form of carrier sense multiple access with collision avoidance (CSMA/CA). Since even the most basic

RESCUE scenario (TS1 in Figure 2.4) involves three communicating stations where messages are received

simultaneously, we assume that from a MAC-layer perspective all frames are broadcast. Upon message

reception, it is each station’s task to decide if they are relays, i.e., if they should decode and forward the

message. This decision is based on two factors: the quality of the received frame and the placement of the

potential relay on a path towards the destination as determined by the routing protocol. Furthermore, in

order for a message to be properly processed, it has to include error-free meta-data. We store the minimum

required amount of information in the PHY header, which is protected against errors (Section 2.2).

Figure 2.1 presents the cross-layer data flow for a single message transmission in the simplest RESCUE

toy scenario (TS1 in Figure 2.4). At the source, this message is passed down through all the OSI layers with

each layer adding its own header. In RESCUE, we define new data link and physical layers maintaining

full compatibility with existing higher layer protocols (including the Internet protocol, IP).

Figure 2.1: Cross-layer data flow in the first toy scenario. Colour coding: green – message without

errors, red – message as received by destination (with errors), blue – message as received and

forwarded by relay (with errors), grey – control messages.

We assume that the message is then received with errors at the relay and destination. Upon message

reception, two message checks are performed. First, a PHY header integrity check to determine that the

control information (meta-data) is without errors. Then, the quality of the decoded message is checked. If

it does not exceed a certain threshold, the message is dropped. Otherwise, it is provided to the higher layers.

Then, at the relay, the routing protocol performs a forwarding decision based on the addresses contained in

the PHY header. If this decision is positive, the message is passed to the lower layers and transmitted.

In parallel, the destination processes the first received message. After a successful PHY header integrity

check and distortion check, it concludes that it is the final destination. Therefore, an end-to-end message

integrity check (MIC) is performed1. We assume that in the analysed case the test fails and the message is

stored in a repository while the destination awaits further copies to arrive. When such a copy arrives from

the relay, it is processed as the first message. Since the end-to-end MIC fails for this copy as well, it is again

stored in the repository. A new message in the repository triggers an iterative decoding procedure. Based

on their PHY headers, both messages are identified as copies of the same message so joint decoding is

performed on both of them. The output message is again verified in the end-to-end message integrity check.

We assume that now this check is positive and the message itself can be provided to the higher layers. The

positive integrity check also triggers an end-to-end acknowledgement (ACK) to inform the source that this

message has been received correctly. The ACK frame is a short message which can be identified and

1 Note that intermediate relays do not need to perform this check.

Physical

Data Link

Network

Application

Laye

rs

Source Relay

Forwarding decision

Destination

Repository & Iterative decoding

AC

KMessage checks Message checks

End-to-end MIC

fail

pass


Page 9 (79)

associated with the DATA frame that it acknowledges. To avoid the problem of flooding, the ACK frame

is sent to the source along a single best path as determined by routing.

2.2 Frame format

As specified in D3.1, each RESCUE message requires a mandatory set of meta-data attached to each

message and guaranteed to be error-free. After a RESCUE message is concatenated with a header and/or

footer at each level of the OSI model, the resultant MAC frame becomes the PHY payload. This is then

preceded by the PHY header which stores the abovementioned meta-data.

Typ

e

Dat

aR

ate

3 2

Sen

d W

indo

w

4

Blo

ck A

CK

Con

t. A

CK

1 1Bits:

MA

C

Pro

toco

l

1

Synchronization

SFD CTRL

Du

ratio

n

Source AddressSender Address

Destination Address

SEQ.

Inte

rle

aver Header

checksumMAC Frame

Preamble PHY Header

2 2 6 6 6 2 1 4Bytes:

Type: 000 (DATA); Other types: 001 (e2e ACK); 010 (partial ACK); 011 (Beacon); 100 (Resource Reservation)DataRate: MSC used;Send Window: how many unACKed frames the station can send;Block ACK: 1 – requested/supported, 0 – not allowed;Continous ACK: 1 – requested/supported, 0 – not allowed;QoS: 1 – supported, 0 – not supportedMAC Protocol: 0 – distributed, 1 – centralizedRetransmission: 0 – false, 1 – trueReserved: for future use

FCS

42324

1

Qo

S

MBF

2

Ret

ran

sm

issi

on

1

Res

erv

ed

2

Figure 2.2: The DATA frame format.

Figure 2.2 provides a description of each of the fields in the RESCUE DATA frame. The frame begins with

a preamble to facilitate asynchronous transmission. Within the preamble, the synchronization field

(containing alternating 0s and 1s) is followed by the Start Frame Delimiter (SFD) (containing a predefined

bit sequence, e.g., 0000 1100 1011 1101). The PHY header begins with a 2-byte control (CTRL) field

within which are encoded: the frame type (3 bits), the data rate used when transmitting the PHY payload

(2 bits), the Send Window, Block ACK, and Continuous ACK fields related to the end-to-end ARQ

mechanism (Section 5.1), one bit indicating support for QoS, one bit indicating the RESCUE MAC type

(distributed or centralized), one bit indicating whether the frame is being retransmitted, and 2 bits reserved

for future use.

The CTRL field is followed by the length (duration) of the PHY payload (2 bytes). Then, there are three

addresses (source, sender, and destination) – each 6 bytes long and corresponding to the MAC addresses of

the stations. This length was chosen to ensure simplify the addressing, although in practice shorter addresses

may also be used. The source and destination are the end-to-end stations of the message; the sender is the

station which has transmitted this particular frame (either the source or one of the relays). The 2-byte

sequence (SEQ) field is used to distinguish consecutive frames. The 2-byte multi-bit field (MBF) was added

as a requirement from WP1 and WP2. It describes the “frame quality” in the form of a confidence indicator

which we define as the bit error probability after decoding. It can be obtained by measuring the mutual

information (MI) of the output LLRs from the decoder. Next is a byte-long field containing the interleaver

index necessary for the operation of the decoder. The final field is the 4-byte header checksum which

ensures that the PHY header has been decoded correctly.

The PHY payload contains the MAC frame. Since we cannot guarantee that the PHY payload is error-free,

we do not specify any relevant information within the MAC frame. The last part of the MAC frame contains

a frame check-sequence (FCS) field which allows the destination to confirm that the outcome of the joint

decoding is successful and that the frame can be passed to higher layers.

The format of the end-to-end (e2e) ACK frame (Figure 2.3) is based on the previously described DATA

frame format. The frame is made as short as possible: it consists only of the PHY header from which

information describing the non-existing payload has been removed. Other unnecessary fields (such as the

sender address) have also been removed. The ACK frame is mapped to the DATA frame which it

acknowledges based on the 3-tuple of (source address, destination address, sequence number). The fields

related to the end-to-end ARQ mechanism are described in Section 5.1.


Page 10 (79)

Synchronization

SFD CTRL Source AddressDestination

AddressSEQ.

Header checksum

Preamble PHY Header

2 6 6 2 4Bytes:

Block ACK

2

Con

t. A

CK

1

Typ

e

3Se

nd

Win

dow

4

Blo

ck A

CK

Con

t. A

CK

1 1Bits:

NACKed Frames

5N

AC

K/A

CK

1

Res

erv

ed

1

Type: 001 (e2e ACK);NACK/ACK: 1 – ACK, 0 - NACK;Send Window: number of received frames since last transmitted (N)ACK;Block ACK: 1 – used, 0 – not used;Continous ACK: 1 – used, 0 – not used;NACKed Frames: How many frames are missed (to notify when Block ACK cannot inform about all missed frames – for proper non-continous send window operation);Reserved: for future use

Figure 2.3: The ACK frame format.

2.3 Toy scenarios

S D

R

S D

R2

R1

S D

R2

R1

TS1 TS2

TS3

S1

D

S2

R

TS4

Figure 2.4: The four basic network topologies (toy scenarios, TS1-TS4) considered in the RESCUE

project.

To harmonise the analysis of basic network topologies among WP1, WP2, WP3, and WP4, we have

consolidated the four toy scenarios (TSs) which are the subject of our initial investigation (Figure 2.4). This

constitutes an update from what was presented in D3.1. The first scenario (TS1) is the simplest case of

relay-assisted message transfer and consists of only three stations: the source (S), relay (R), and destination

(D). In the second toy scenario (TS2) we add an additional relay station. Both relays (R1 and R2)

simultaneously receive the message transmission from S. The third toy scenario (TS3) is a combination of

TS1 and TS2. This scenario requires that routing addresses the issue of multiple paths to the destination.

Finally, TS4 contains two source stations (S1 and S2). Their message is combined at R before it retransmits

to D. Due to the high complexity of the relay in TS4, this scenario is not considered in WP3 and remains

defined for the theoretical work of WP1 and WP2.


Page 11 (79)

S D

R2

R1

R3

Figure 2.5: The basic network topology considered for demonstrating routing in the RESCUE

project.

Additionally, for the purpose of demonstrating the RESCUE routing protocols, we have defined a routing

toy scenario (RTS) as shown in Figure 2.5. This topology is an extension of TS3 with the addition of an

extra relay (R3). Therefore, there are three paths between S and D, each with an increasing number of hops

(from one to three). In this scenario we expect the routing protocol to limit the transmission to the two paths

with the lowest number of hops. The routing toy scenario will be used to demonstrate the RESCUE routing

protocols in the next phase of the project when we move with the implementation to SDR devices.

2.4 Large scale scenarios

For more advanced analysis we define two large scale scenarios (V2V and public safety) relevant to the

application of the LOTF concept in practice.

2.4.1 V2V

The “links-on-the-fly” concept has been theoretically well investigated in toy scenarios in D1.2.1, D2.1.1

and D2.2.1 [4], [5], [11]. In order to validate the functionality and assess the performance, the system needs

to be considered in more realistic scenarios including multi-hop dissemination. In such multi-hop scenarios

with “links-on-the-fly” it is necessary to have lossy links, i.e., the received packets have errors after channel

decoding. With the absence of errors at the destination the LOTF scheme is not necessary anymore.

Therefore a scenario is selected where vehicles move in small groups to ensure lossy links among them and

the destination has a large distance to the last-hop relays in order to have a low reception SNR (see Figure

2.6, dashed line indicates a lossy link).

We consider a typical highway scenario with a sparse density of nodes. With a high number of nodes many

links would be available for redundant packet re-transmissions and these decrease the number of lossy

links. To show the best gain of LOTF, a representative scenario with two small groups of four vehicles are

chosen, which have at least three disjoint paths in parallel. Four vehicles are necessary following the

assumed statistical channel model, i.e., Nakagami, where the reception probability beyond a configurable

distance is less than 100%. For simplicity the vehicles drive in one direction. The source sends 1,000

packets with a size of 8,000 bits each to a destination, which is out of communication range of the source

such that the relays need to forward the packet towards the destination. The transmissions among the

vehicles can be lossy due to the distance between them. When all three parallel links are lossy it is not

possible to recover the packet without joint decoding since the packet are received corrupted in the relays.

For the simulations the RESCUE protocol stack with the Black Box abstraction for the PHY (Section 2.5),

the functionality of the MAC and NET layers was implemented. Furthermore, a facility layer is used to

send event-triggered safety messages, i.e., DENMs [2]. The parameters for the simulation are shown in

Table 2.1.

Table 2.1: Parameters for the large scale scenario for V2V communication

Parameter Values

Number of Vehicles 10

PHY/MAC/NET RESCUE PHY abstraction, RESCUE MAC, RESCUE CBF

Data Rate 6 Mbit/s

Tx Power 5 – 35 dBm

Channel Bandwidth 10 MHz at 5.9 GHz

DENM interval / size 0.5 s / 1000 bytes

Total DENMs sent 1000


Page 12 (79)

Figure 2.6: Large scale scenario for vehicle-to-vehicle communication

2.4.2 Public safety

In order to apply the links-on-the-fly concept in a public safety deployment the following conditions should

be gathered. First, the network should be dense in terms of the number of participating nodes. This is

particularly the case in a disaster relief operation where often a large number of rescuers are deployed.

These rescuers are equipped with relaying-capable devices able to establish a dynamic multihop network.

Second, in such extreme situations the network can be partially destroyed forcing nodes to establish longer

range communications thus over less reliable and potentially lossy links. In these relatively large and dense

networks, more than a single route can exist from the source to the destination. More importantly, in such

an uncoordinated environment a decentralized MAC requiring a minimal synchronization is required.

Furthermore, the intrinsic properties of public safety traffic force these networks to support point to

multipoint communication patterns and also favour downlink traffic over uplink.

To assess the gains expected by the LOTF, we investigate a representative public safety scenario composed

of around 20 nodes operating in an outdoor relatively small area, i.e., dense outdoor scenario. For simplicity

reasons, already deployed base stations (BS) and users devices are considered to operate in the same

manner, undergoing the same relaying functions. Such public safety deployment is also characterized by

specific traffic requirements such as broadcasting regularly positions and locations as well as short message

exchanges. These traffic patterns require relatively low throughput (64 kbit/s), but demands are expected

to grow with the emergence of high resolution video applications and interactive voice communications.

We rely in these public safety simulations, as in all our ns-3 [12] simulations, on the physical layer

abstraction model called the PHY Black Box (Section 2.5). The considered simulation parameters are

shown in Table 2.2.

Table 2.2: Parameters for the large scale scenario for the public safety scenario

Parameter Values

Number of nodes (BS and devices) > 6

PHY/MAC/NET RESCUE PHY abstraction, RESCUE MAC, RESCUE

R-OLSR

Data Rate 64 kbits/s to 6 Mbits/s (future apps)

Tx Power Up to 40 dBm

Node distribution Uniformly inside cells

Traffic pattern Downlink (SMS or video stream)

Message size Short to medium

Simulation duration Few minutes

1 1 1

1

1

1

1

1

Distance to achieve lossy links

S D


Page 13 (79)

Figure 2.7: Large scale scenario for Public safety

Note that the topology presented in Figure 2.7 is the simplest topology possible, overlapping paths can be

available offering multiple variants of the same considered topology.

2.5 PHY Black Box

In order to test the performance of the message transfer protocols designed by WP3, it became apparent

that an abstraction of the physical layer was required. With the help of other WPs, a model of the joint

decoding process, named the PHY Black Box, was created (Figure 2.). This abstraction was first

implemented in Matlab and then ported to C++ to be used in ns-3 simulations as reported in this deliverable.

A separate C++ port for GNU Radio is being implemented to facilitate SDR tests of WP3 protocols to be

reported in D3.3.

Theoreticalresults

Coding/decodingscheme design

Message transferrequirements

Abstraction

Implementations

PHY Black Box

WP1 WP2 WP3

Input

Matlab

C++(ns-3)

WP3 Simulations

(D3.2)

WP3 SDR Implementation

(D3.3)

Application

C++(GNU Radio)

Figure 2.8: The cross-WP cooperation in providing a physical layer abstraction and outcome

implementations.

Zone with

low SNR

Destination

source

relay

Lossy link

BS can be

considered as

standard relays

Path1


Page 14 (79)

2.5.1 Technical details

The RESCUE PHY Black Box is an error rate model based on a semi-analytical approach where theoretical

results are also used to avoid an excessive amount of simulations. Figure 2.9 divides the abstraction model

into black box #1 and black box #2, which illustrate the deterministic and stochastic parts,

respectively. The idea is to match the theoretical results given by black box #1 to simulation based

results stored in black box #2. In the following we will describe the content of both parts of the

abstraction model.

Figure 2.9: The two components of the PHY Black Box abstraction model.

Black box #1 was originally described in D2.1.1. The bit error rate (BER) after joint decoding at the

destination depends on the bit error probability (BEP) at the relay i, ip , the signal to interference plus noise

ratio (SINR) of the link between relay i and the destination, iSINR , and the used modulation and coding

scheme (MCS). The sum of MIs over the parallel incoming links is calculated as i

iMM for

0,1,1min

0,

iibiib

iii

ppHRpH

pRM

where iR is the normalized channel constellation constrained capacity of the parallel link i and ib pH

denotes the binary entropy associated with probability ip . In case of TS2 (the CEO problem), an error

floor occurs. Black box #1 calculates the error floor by using the method described in Section 4.1.4.1

of D1.2.1.

It is well known that in block codes, the number of errors in the packets is not uniformly distributed. Black

box #2 is needed to produce more realistic error distributions. In the following, we will describe the

construction of simulation tables used in Black box #2 for N parallel links.

Since the BEP at the relay is already taken into account in Black box #1, we can set 0ip for all i.

Furthermore, since the simulation results and the theoretical results are compared only in terms of the sum

of the MIs over the links, we can set ̂iSINR , and sweep ̂ through an appropriate SINR range. The

simulations have to be performed separately for all MCSs considered.

Simulations were performed by sending 10000 packets (8000 bits each) through the channel of each parallel

link. The output of the simulations was the number of errors in each packet. Empirically, it was found that

the errors are distributed according to a distribution defined as 2,10 , where is the

probability that the number of errors in a packet is zero, 0 is the Dirac delta function, and 2,

denotes the normal distribution with mean and variance 2 .

The parameters 0ip and ̂iSINR are given to Black box #1 which outputs MI. Now we can fit

the simulation data to the distribution given above, resulting in numerical values of parameters , , and

2 corresponding to a value of MI given by Black box #1. As a result, we can construct a table which

contains the numerical values for MI and the distribution parameters.

Since the resolution for the MI values listed in the table is finite, linear interpolation can be used to obtain

numerical values for the distribution parameters between the quantized points. For TS1 and TS3, errors can


Page 15 (79)

be generated directly from the distribution defined above. In the case of TS2, there exists an error floor

which is composed of evenly distributed errors. Let L be the length of the packet and let )( floorp denote

the probability of errors induced by error floor. The number of bit errors N can be generated as follows:

1. Input parameters Kppp ,...,, 21

, KSINRSINRSINR ,...,, 21

2. Calculate MI using black box #1

3. Find 2,, matching the values on the tables with MI using linear interpolation

4. Generate random number 1,0

5. if then

1. Generate N from 2,

6. else 1. N=0

7. end if 8. Calculate p(floor) using black box #1

9. if 0)( floorp then

1. )( floorpLNN

10. end if

11. end

2.6 Baselines for comparison

The MAC and routing message transfer baselines were defined in D1.2.1. Here, we briefly summarize the

choices, discuss necessary changes where applicable, and add baselines for additional protocols developed

within WP3.

For the MAC protocol baseline, IEEE 802.11 was chosen because of its widespread adoption, packet-based

operation and use of unlicensed frequency bands. The 802.11 standard defines multiple medium access

functions but the two basic ones are the distributed coordination function (DCF) and the point coordination

function (PCF). DCF is the fundamental uncoordinated MAC technique in 802.11, available in both

software and hardware implementations, and relatively simple (being based on CSMA/CA). It was used as

the baseline for the distributed MAC protocols developed in RESCUE. For the centralized MAC (Section

3.3), we adopted a coordination procedure which shares some similarities to the PCF of 802.11. However,

since PCF-compliant implementations are not commonly available, without loss of generality and to

provide a fair comparison, we used as a baseline the proposed centralized MAC but with all RESCUE

functionality turned off. As key performance indicators (KPIs), in all cases, we consider the following

metrics: throughput, delay, jitter, and packet loss.

As the baseline for the RESCUE geographic routing we consider the ETSI GeoNetworking protocol, which

provides single-hop and multi-hop communication in vehicular ad-hoc networks based on IEEE

802.11p/ITS-G5. The following metrics are used as KPIs: packet success rate2, end-to-end delay, and data

traffic overhead.

As the baseline for the RESCUE multi-path routing (R-OLSR) we consider an implementation based on

OLSR with link quality metric ETX (Expected Transmission Count) [8] [16] as the baseline. Previously,

we planned to consider multi-path OLSR (MP-OLSR) [9]. However, it is not available in ns-3 and its

implementation would reduce our focus on developing R-OLSR. We consider the following KPIs:

throughput, packet loss rate, end-to-end delay, routing overhead, and the cold start convergence time.

Regarding the RESCUE end-to-end ARQ protocol, the goal of the simulations was to show that a RESCUE

network can observe a performance gain from advanced MAC-layer end-to-end ARQ. Since the concept

of lossy forwarding is a paradigm shift with respect to message transfer design, an ARQ protocol in this

case cannot be decoupled from the underlying MAC. With this in mind, and to achieve the goal of the

simulations, we used SimpleMAC as a baseline which is based on the Stop-and-Wait (SaW) approach

similarly to other computer network standards (e.g., IEEE 802.11, IEEE 802.15.1, IEEE 802.15.4) although

with significant modifications related to ACK handling as necessitated by the specific RESCUE case. As

2 This metric was mistakenly labelled as throughput in D1.2.1, although the equation (1.1) in that deliverable does in

fact measure the packet success rate.


Page 16 (79)

KPIs we consider throughput, end-to-end delay, and jitter (ARQ guarantees transmission without packet

loss).

In case of partial ARQ, our contribution is that of adding Forward Error Correction (FEC) on top of the

ARQ protocol, which is referred to as Partial Hybrid-ARQ (P-HARQ) in this document. Accordingly, the

main focus is not only the ARQ protocol itself, but also the design of encoding and decoding for the FEC.

Hence, we consider the following KPIs: bit-error-rate (BER), packet-error-rate (PER), and e2e throughput.

As the baseline, we consider Smart Hybrid-ARQ (SHARQ) [13].

Finally, for the multirate algorithm, we conclude that using existing algorithms as a baseline for comparison

is not applicable in the RESCUE case because existing rate selection algorithms:

have been only prepared for single input single output transmission systems and did not take

cooperative transmission into account,

have been designed for the existing 802.11 standard which does not have the constraints that

RESCUE has,

assume access to data link layer parameters,

have mostly been prepared for nomadic Wi-Fi mobility and, consequently, they assume a slow

fading channel.

As KPIs for the RESCUE rate selection we consider throughput, delay, and jitter.

2.7 Simulation parameters

To ensure good comparability between all WP3 algorithms and protocols, in addition to the common set of

scenarios (Section 2.3 and 2.4) as well as the baselines and metrics (Section 0), the simulation parameters

were set to common values. In this section, we explain the parameters and give a short justification of the

configured values.

The data rate is set to 6 Mbit/s, which is a common value in car-to-car communication and fits to the low

rate capabilities of the SDR platforms. The restriction in LOTF is that the PHY header has to be error free.

Additionally, in harsh channel conditions the whole packet should be relatively small. Therefore, we

decided to configure 1000 byte packets to have an optimal trade-off between a small packet size and a good

payload to PHY header ratio.

An appropriate channel model is a further important point for gathering realistic simulation results. In our

simulations we set a Nakagami fading model with log-distance path loss and a channel exponent of 3, which

best fits the empirical data. In some simulations we also use a fixed model, where the reception probability

is deterministic and depends on the distance among two nodes. This is done in order to simulate the specific

toy scenarios TS1 to TS3, which would be difficult with the unexpected reception behaviour of nodes in

case of a Nakagami channel. Additionally, we used the BPSK modulation because it is robust against the

assumed poor channel conditions.

The PHY Black Box operates (depending of the number of message copies) down to -6 dB of SNR. To

cover the whole working range the Frame Receive Power Threshold is decreased to -105 dBm and a

common value for the Carrier Sense Power Threshold is the half of it (-108 dBm ≙ -3dB less than the

receive power threshold).

The 2.4 GHz frequency band is most frequently used by current 802.11 networks and, therefore, it is very

crowded. For this reason we choose the 5 GHz frequency band in the majority of our simulations and the

5.9 GHz band for the car-to-car communication (as it is standardized in ITS/G5, 802.11p).

In all simulations the designed algorithms are compared with their baselines or with the LOTF functionality

turned off. The main variable in the simulations is the channel quality (SNR) which was varied by changing

either the noise level, distance or the TX power.

The used simulator is ns-3, which is an open source network simulator, accepted by the scientific

community. The common simulation parameters and their justification are summarized in Table 2.3.


Page 17 (79)

Table 2.3: Common simulation parameters for all partners

Parameter Common value Justification

Data rate 6 Mbit/s Low rate in line with SDR device capabilities, default for car to

car communication

Packet size 1000 Byte Typical large packet size in wireless research, good PHY

payload to PHY header ratio

Path loss model LogDistance Default model in wireless communications

Fading model Fixed Nakagami Realistic model which fits empirical data, suitable model to

simulate particular toy scenarios

Path loss

exponent

3 Simulation of unpredictable environments to show the gain of

RESCUE

Modulation

scheme

BPSK Modulation robust to poor channel conditions, supported by

PHY Blackbox

Carrier Sense

Power

Threshold

-108 dBm Half (3 dB) less than the receive power threshold

Frame Receive

Power

Threshold

-105 dBm Guarantees at least -10 dB of SNR to work in the whole range

of PHY BlackBox operation

Frequency 5 GHz/5.9 GHz Transmission frequency for 802.11 and ITS/G5 (802.11p),

license-free band, less congested than the 2.4 GHz band

Forwarding

threshold

0.2 Based on WP2 results; it represents the maximum allowable

BER of a received message which is to be processed by the

receiver (the optimization of this parameter is discussed in

Appendix A).


Page 18 (79)

3. MAC

3.1 SimpleMAC

3.1.1 Protocol overview & design update

SimpleMAC is the implementation of the basic RESCUE principles. Its design allows basic message

transfer in a RESCUE network, i.e., in a network in which at least one link on each path between the source

and the destination stations is lossy. By taking into account the RESCUE assumptions and requirements

described in D3.1, SimpleMAC defines:

the basic cross-layer data flow at the source, relay, and destination stations,

rules for medium access based on CSMA/CA,

a method for ensuring reliable end-to-end delivery of messages including

o handling transmission of acknowledgement frames over multi-hop links,

o handling DATA frame retransmissions,

methods for storing multiple copies of messages for joint decoding.

Therefore, SimpleMAC serves as

a starting point for the development of more advanced MAC protocols,

a reference for measuring improvements in the RESCUE cross-layer design,

an abstraction of the MAC layer basics to be used in the analysis of other protocols.

MA

C

PHY

TDMA MAC

AP

SimpleMAC (CSMA)

STA ADHOC

HIGHER LAYERS

CHANNEL

REM

OTE

ST

ATI

ON

M

AN

AG

ER

MULITRATE CONTROL

ARQ

CONTENTION WINDOW CONTROL

Figure 3.1: The RESCUE simulation model architecture.

Figure 3.1 illustrates the implementation of the RESCUE architecture in ns-3. SimpleMAC is the core MAC

module which can operate in a simple network without any additional mechanisms. However, it is designed

in such a way that cooperation with additional control mechanisms (e.g., multi-rate control algorithms,

advanced ARQ methods, routing protocols) is possible. These additional mechanisms are intended to

improve RESCUE performance especially in large-scale scenarios. SimpleMAC may also be used by the

Centralized MAC protocol (cf. Section 3.3) during the Contention Period. Additionally, it is also the basis

for the advanced Distributed MAC Protocol (cf. Section 3.2).

The SimpleMAC protocol is based on the CSMA/CA protocol for medium access. If a dedicated routing

protocol is not used, SimpleMAC resorts to a flooding mechanism for multipath frame transmission.

Additionally, multipath ACK forwarding is performed to provide basic end-to-end reliability. The

implemented SimpleMAC behaviour is the following:

1. All stations receiving frames with correct PHY headers provide them to the MAC layer. Based on

the addresses in the frame header, the decision about taking part in the pending transmission is

made. If routing is not configured, the flooding mechanism is used which means that all stations

which are not the source or the destination of the given transmission become relays.

2. Relays forward frames even if the frame payload is corrupted. However, frames of which BER

exceeds a specified threshold are dropped. The BER estimation is performed by the underlying

PHY layer.


Page 19 (79)

3. The destination accumulates all corrupted frame copies until the joint decoder is able to restore

the original data. In the RESCUE ns-3 implementation the information about a frame’s quality is

based on the PER derived from the abstraction of the joint decoder (i.e., the PHY Black Box,

Section 2.5) implementation. Currently up to three frame copies can be used by the PHY Black

Box, thus up to three frame copies with the lowest BER are be stored by the destination.

4. After the reception of a correct frame, SimpleMAC may transmit an ACK frame after the SIFS

period without performing any backoff procedure. The presence of the ACK transmission depends

on the ARQ configuration (cf. Section 5.1).

5. Acknowledgment frames may be forwarded by relays. In this situation the backoff procedure is

obligatory to reduce the risk of collisions.

6. If an additional routing mechanism is not configured, a particular station tries to forward the ACK

frame only if it transmitted a copy of the DATA frame which is being acknowledged.

7. To further reduce the intensity of frame transmissions, the following additional rules of relay

behaviour are used:

a. Only one copy of a given frame is forwarded (with the exception of a DATA frame

retransmission).

b. All DATA frame copies waiting for possible transmission are deleted from the stations’

transmission queue upon receiving the ACK frame for the stored data frame.

c. Any given ACK frame is forwarded only once.

d. The forwarded ACK frames are stored by the relays. If the station receives a frame copy

coming from the retransmission of any DATA frame which should be acknowledged, it

responds with sending the stored ACK frame and drops the retransmitted DATA frame.

8. A simple ARQ protocol is implemented as part of SimpleMAC. It provides the end-to-end

acknowledgments with a configurable ACK waiting time. This mechanism does not allow for a

new data frame transmission if the ACK frame for the previous data frame is waiting for

transmission. As this behaviour may significantly reduce network performance, more advanced

ARQ protocols described in Section 5.1 can be used instead.

9. The following four independent transmit queues are used (starting from the highest priority):

a. ACK – for ACK forwarding

b. CTRL – for transmission of control frames (e.g., routing messages)

c. RELAY – for forwarding of frame copies by the relays

d. DATA – for transmission of data frames originated by a given station

10. Frames are selected with strict priority, which means that the ACK transmission always has

priority over all other frame types, which helps in fast ACK forwarding and thus is important for

the reduction of network traffic. Moreover, control frames are transmitted before the relayed

frames and frame relaying always has priority over transmission of a locally-generated DATA

frame.

11. The contention window (CW) size used by the backoff procedure may be controlled by an external

mechanism (e.g., the multi-rate control algorithm). Otherwise, CW remains constant.

The RESCUE SimpleMAC module for ns-3.21 was created on the basis of the “Simple CSMA/CA protocol

for ns-3” (available online: http://www2.engr.arizona.edu/~junseok/simple_wireless.html). Additionally,

the RESCUE frame formats, transmission modes, and multi-rate control mechanisms were implemented on

the basis of the corresponding implementations imported from the ns-3 Wi-Fi module.

3.1.2 Simulation results

The simulation analysis was performed using the parameters listed in Table 3.1. The initial study, to validate

the successful operation of SimpleMAC, was done with a fixed propagation loss model (the

MatrixPropagationLossModel in ns-3). In this model, the propagation loss is fixed for each pair of nodes

and does not depend on their relative positions. Subsequent analyses were done with a more advanced

model (the NakagamiPropagationLossModel in ns-3).

Table 3.1: Simulation parameters

Parameter Value

Warmup time 25 s

Simulation time 200 s (600 s for unsaturated

Nakagami case)

Propagation loss model Fixed or Nakagami

Path loss exponent 3.0

Reference loss (for distance = 1m) 46.667 dB

http://www2.engr.arizona.edu/~junseok/simple_wireless.html


Page 20 (79)

Nakagami shape factor 1 (for distance <

177.3)

1.0

Nakagami shape factor 2 (for distance >

177.3)

0.85

Noise level 92.515 dBm

Carrier Sense Power Threshold 108 dBm

Frame Receive Power Threshold 105 dBm

TX Power 20 dBm

PHY Data Rate 6 Mbit/s

PHY Basic Rate 3 Mbit/s

BER threshold 0.2

CW 16

Slot time 15 µs

SIFS time 30 µs

LIFS time 60 µs

Queue length 100 frames

Retry Limit under non-saturation 6

Retry Limit under saturation 2

ACK Timeout

(Baseline CSMA/CA, TS-1, stop and wait

ARQ)

3500 µs

ACK Timeout

(TS-2, TS-3, stop and wait ARQ)

7000 µs

Traffic load under non-saturation 0.16 Mbit/s

Traffic load under saturation 15 Mbit/s

Packet Size 1000 bytes

Figure 3.2: Throughput comparison between CSMA/CA (baseline) and RESCUE (SimpleMAC) for

the three toy scenarios: TS1, TS2, and TS3. The link between the R and D stations is lossless. The S-

R and S-D links are lossy and their SNR varies from -1.5 dB to -7 dB.

We begin by comparing the performance of RESCUE SimpleMAC and CSMA/CA (the baseline) when the

channel model uses the fixed propagation loss model. In the most interesting case, presented in Figure 3.2,

the link between R and D is lossless while the links between S and R as well as between S and D are lossy

and their SNR varies from -1.5 dB to -7 dB. There are two baseline results: for TS1/TS3 and for TS2. For

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

-7-6-5-4-3-2

Thro

ugh

pu

t [M

b/s

]

SNR [dB]

TS1/TS3 CSMA/CA TS2 CSMA/CA TS1 RESCUE TS2 RESCUE TS3 RESCUE


Page 21 (79)

TS1/TS3 the baseline throughput values are calculated on the S-D link3. In TS2 there is no direct link

between the S and D stations and, therefore, even the baseline transmission is realized through relays. In

all considered cases, the performance of RESCUE SimpleMAC is the same as or much better than that of

CSMA/CA. For each toy scenario, when SNR drops below -2.35 dB, transmission with CSMA/CA

becomes impossible but with SimpleMAC non-zero throughput is achieved up to an SNR value of -5.5 dB

(TS1), -6 dB (TS3), or -7 dB (TS2).

(a) (b)

(c) (d)

Figure 3.3: Comparison of RESCUE SimpleMAC with CSMA/CA for TS1 under non-saturation: (a)

throughput, (b) FLR, (c) delay, (d) jitter. The distances of the S-D and S-R links

In the next scenario, we replace the fixed propagation loss model with the Nakagami model. For the TS1

topology, we configure the station placement so that S and D as well as S and R are placed 300 meters

apart. We measure the SimpleMAC performance over varying distances of the R-D link. Figure 3.3 presents

the values of the different KPIs (throughput, FLR, delay, and jitter) obtained for RESCUE (Simple MAC)

in comparison with the baseline (CSMA/CA) for the TS1 under non-saturation. For small R-D distances,

the throughput improvement is up to 250%. For distances exceeding 350 meters, the RESCUE improvement

is about 150% while the FLR is improved between 15 and 50 percentage points. The delay and jitter values

are comparable for both protocols with SimpleMAC achieving a slightly higher (but slightly more stable)

delay.

3 In the considered case, adding the S-R-D link to the baseline calculation does not impact the results. This is because

of the selected channel model and the propagation loss configuration.

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

50 100 150 200 250 300 350 400 450 500

Thro

ugh

pu

t [M

b/s

]

Distance [m]

CSMA/CA RESCUE

0

10

20

30

40

50

60

70

80

90

100

50 100 150 200 250 300 350 400 450 500

FLR

[%

]

Distance [m]

CSMA/CA RESCUE

12

12.5

13

13.5

14

14.5

15

15.5

50 100 150 200 250 300 350 400 450 500

De

lay

[ms]

Distance [m]

CSMA/CA RESCUE

7.4

7.6

7.8

8

8.2

8.4

8.6

8.8

9

50 100 150 200 250 300 350 400 450 500

Jitt

er

[ms]

Distance [m]

CSMA/CA RESCUE


Page 22 (79)

(a) (b)

(c) (d)

Figure 3.4: Comparison of the RESCUE SimpleMAC with CSMA/CA for TS1 under saturation: (a)

throughput, (b) FLR, (c) delay, (d) jitter. The distances of the S-D and S-R links and S-R links

are set to 300 m. The distance of the R-D link is variable.

Figure 3.4 presents the same results as in the previous scenario but under saturation conditions. The

throughput improvement from using SimpleMAC in this case varies from 100% (at 300 m) to 350% (at 50

m). The saturation conditions are evident in the elevated FLR and delay values although the jitter remains

low. In all cases, RESCUE is equal to or outperforms the baseline.

(a) (b)

0

0.05

0.1

0.15

0.2

0.25

0.3

50 100 150 200 250 300

Thro

ugh

pu

t [M

b/s

]

Distance [m]

CSMA/CA RESCUE

0

10

20

30

40

50

60

70

80

90

100

50 100 150 200 250 300

FLR

[%

]

Distance [m]

CSMA/CA RESCUE

990

1000

1010

1020

1030

1040

1050

1060

1070

1080

1090

50 100 150 200 250 300

De

lay

[ms]

Distance [m]

CSMA/CA RESCUE

0

1

2

3

4

5

6

7

8

50 100 150 200 250 300

Jitt

er

[ms]

Distance [m]

CSMA/CA RESCUE

0

0.02

0.04

0.06

0.08

0.1

0.12

0.14

0.16

0.18

50 100 150 200 250 300 350 400 450 500

Thro

ugh

pu

t [M

b/s

]

Distance [m]

CSMA/CA RESCUE

0

20

40

60

80

100

120

50 100 150 200 250 300 350 400 450 500

FLR

[%

]

Distance [m]

CSMA/CA RESCUE


Page 23 (79)

(c) (d)

Figure 3.5: Comparison of RESCUE SimpleMAC with CSMA/CA for TS2/3 under non-saturation:

(a) throughput, (b) FLR, (c) delay, (d) jitter. The length of each link (S-D, S-R1/R2, R1/R2-D) is the

single variable.

In the next analysed case we considered TS2 and TS3 jointly. This is because the difference between them

is the existence or lack of the direct S-D link. As we increase the distance between all stations this link

becomes increasingly unreliable until it ceases to exist and all traffic goes through the two relays. Thus,

TS2 changes into TS3. We consider stations to be placed equidistantly from each other with the distance

between them being the single variable of the analysis. For the unsaturated case (Figure 3.5), RESCUE is

able to provide up to a 75% throughput increase (at 250 m), which corresponds with a similar decrease in

the frame loss ratio. The delay and jitter values remain low up to a distance of 300 m. Afterwards, the

number of successfully delivered messages is close to zero which causes the large increase and variation of

these metrics.

(a) (b)

(c) (d)

Figure 3.6: Comparison of RESCUE SimpleMAC with CSMA/CA for TS2/3 under saturation: (a)

throughput, (b) FLR, (c) delay, (d) jitter. The length of each link (S-D, S-R1/R2, R1/R2-D) is the

single variable.

For the saturated case of the TS2/TS3 analysis (Figure 3.6), the throughput increase is moderate – up to

50% (at 200 m) along with the FLR decrease (up to 75% improvement at 200 m). The delay and jitter values

become increasingly large for this network – saturation conditions coupled with lack of flow rate control

are the result of this. Nonetheless, the RESCUE approach brings improvements – up to 21% decreased

delay and up to 25% decreased jitter (at 200 m).

0

200

400

600

800

1000

1200

50 100 150 200 250 300 350 400 450 500

De

lay

[ms]

Distance [m]

CSMA/CA RESCUE

0

100

200

300

400

500

600

50 100 150 200 250 300 350 400 450 500

Jitt

er

[ms]

Distance [m]

CSMA/CA RESCUE

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

0 50 100 150 200 250 300 350 400

Thro

ugh

pu

t [M

b/s

]

Distance [m]

CSMA/CA RESCUE (TS2/TS3)

0

20

40

60

80

100

120

0 50 100 150 200 250 300 350 400

FLR

[%

]

Distance [m]


0

500

1000

1500

2000

2500

0 50 100 150 200 250 300 350 400

De

lay

[ms]

Distance [m]


0

100

200

300

400

500

600

0 50 100 150 200 250 300 350 400

Jitt

er

[ms]

Distance [m]



Page 24 (79)

The conclusions drawn from the implementation and simulation results of SimpleMAC are the following.

1. SimpleMAC is equal to or outperforms the baseline in the considered scenarios.

2. The improvements provided by SimpleMAC are higher in non-saturation scenarios than in saturation

scenarios. This is in line with the traffic requirements specified for both public safety and V2V

communications as defined in D1.1.

3. The demonstrated SimpleMAC performance and improvement gains over the baseline (CSMA/CA)

can be further increased by optimizing for the following criteria:

optimal PHY header size,

optimal placement of relays,

optimal values of offered loads,

optimal retry limits and timeouts.

4. SimpleMAC can serve as a good baseline for comparison of further WP3 message transfer protocols.

Indeed, as the first complete cross-layer solution for lossy link communications it opens a new field of

research. With respect to the other protocols developed within WP3, further performance

improvements can be expected from the following protocols:

centralized MAC,

distributed MAC,

end-to-end ARQ,

partial ARQ,

rate adaptation algorithm.

5. The presented results are upper bound by the limitations of the PHY Black Box. This, together with

the promising results, makes SimpleMAC a good candidate for implementation and validation in SDR

devices.

3.2 Distributed MAC

In addition to the basic MAC mechanisms essential to implementing the links of the fly concept (i.e., no

CRC check and corrupted frames buffering), managing the access and controlling the level of errors in a

large ad-hoc network requires novel and advanced functionalities. For this reason, we propose in RESCUE

a distributed MAC protocol capable to schedule transmissions and ensure controllable reliability in large

ad-hoc topologies. We give a brief overview of our distributed MAC protocol in the following section. For

additional details, please refer to the D3.1 deliverable.


As thoroughly described in D3.1, in order to handle the challenges imposed by the RESCUE lossy

forwarding paradigm, the RESCUE distributed MAC protocol offers three essential features:

A busy tone control channel: This low data rate channel is used to announce an activity by a

node receiving a frame in order to extend the traditional wireless MAC carrier sensing (refer to

Figure 3.7). Indeed, this mechanism increases the reliability of the MAC protocol in an attempt to

replace the classical MAC layer acknowledgment deemed useless with our paradigm. Clearly in

this case acknowledging packets that can be corrupted makes no sense in a lossy forwarding

context. However, using a busy tone control channel does not guarantee the frame reception nor

an accepted level of distortion in the received information.

Replacing ACK by overhearing since the full reliability of frames transmission is not required.

Indeed, many researchers have advocated to alleviate the MAC layer process by making nodes

listening after transmission to detect if neighbours are forwarding the received frame. However,

their proposals did not meet the expected success for efficiency and reliability limitation. In the

case of RESCUE lossy forwarding, receiving corrupted frames can be mitigated by having

multiple copies of the message reach the final destination. Nevertheless, in order to make this

overhearing possible we also introduce the third feature of our distributed MAC detailed hereafter.

Fostering relaying over new transmissions by setting shorter timers for relayed frames

compared to those arriving from higher layers. This feature completes the overhearing process by

forcing neighbours to relay as fast as possible making it easy to the source to identify successful

transmissions. Additionally, our protocol propagates messages in the network closer to the

destination thus creating more diversity and avoiding bottlenecks close to the source node.


Page 25 (79)

S

R1

R2

Transmission

DCCC

CC

CC

DC

DCDC: Data Channel

CC: Control Channel

Figure 3.7: Control channel and data channel interaction in the RESCUE distributed MAC.

Figure 3.8 shows the operating mode of our distributed MAC protocol through a detailed state diagram. In

summary, one can extract the following main characteristics of our mechanism:

The use of a busy control channel (CC) before any transmission in order to detect the activity of

2-hop neighbours.

The exploitation of different timer values in order to favour relaying over new transmissions.

Indeed, T_Short is employed whenever the information comes from lower layers (relayed).

The establishment of controllable reliability through neighbourhood management when CC is

occupied. In fact, a sender can decide to transmit or not when the control channel is busy depending

on the number of neighbours it possess. In practice, such decisions have a direct impact on the

reliability of the mechanism. More precisely, a source can decide to transmit when the CC is busy

while having more than N neighbours. This means that in the case that one of the neighbours is

already receiving, our distributed MAC can tolerate some losses that will be corrected with the

joint decoding mechanism. A more conservative approach would prevent transmission whenever

the CC is busy or, in other words, when N ≥ 1.

Figure 3.8: Distributed MAC state diagram


Page 26 (79)

In summary, our MAC protocol allows to dynamically optimize the reliability based on the number of

neighbours when the CC is busy. In fact, allowing transmissions when many neighbours are available

reduces delay at the price of increasing losses, whereas forbidding any transmission whenever the CC is

busy constructs a conservative approach that increases the reliability of our protocol. Note that this

configurable reliability feature was not initially proposed in D3.1 but is now added as a system

enhancement.


In order to validate the distributed MAC protocol and characterize its key performance parameters, we have

simulated our solution (the distributed ad-hoc MAC) using the ns-3 simulator with the physical layer

abstraction designed for RESCUE. Our simulations extend the simple MAC as shown in Figure 3.1 by

adding the control channel functionality, adapted timers to favor relaying and controllable reliability.

The simulation analysis was performed using the parameters listed in Table 3.2. In order to control distances

and losses in the considered topologies we consider the simple ThreeLogDistance loss model in ns-3. The

objective here is to have multi-hop topologies with SNR decreasing with distance.

Table 3.2: Distributed (ad-hoc) MAC ns3 simulation parameters

Parameter Value

Warmup time 10 s (margin for neighbourhood

discovery)

Simulation time 15 s

Simulation runs 10

Loss model ThreeLogDistance

Path loss exponent 3

Reference loss (for distance = 1m) 46.667 dB

Carrier Sense Power Threshold -108 dBm

Frame Receive Power Threshold -105 dBm

TX Power Variable to change received SNR

PHY Data Rate 6 Mb/s

Slot time 15 µs

SIFS time 30 µs

LIFS time 60 µs

Queue length 100 frames


N value 1 (conservative approach)

We first focus on a simple topology shown in Figure 3.9 below in order to compare the distributed MAC

to the basic MAC functionalities required for joint decoding that we called simple MAC. Note that in this

simple topology, no joint decoding is invoked since a single route exists between the sender and the

receiver. Furthermore, no ARQ protocol is implemented in our simulations. This was done in order to

isolate the MAC layer and investigate its parameters and their interplay. In fact, the main objective of these

simulations is to investigate whether the added complexity and overhead of the distributed MAC affect

negatively the performance of the system. We want to quantify in particular the impact of the added features

in the distributed MAC mainly the busy tone channel as well as the modified timer values that favor relaying

over new transmissions.

Figure 3.9: Simple topology for characterizing the overhead of the distributed MAC

Destination

source

relayPath1


Page 27 (79)

The obtained simulation results are shown in Figure 3.10 and Figure 3.11 below.

Figure 3.10: Throughput comparison between

simple and distributed MAC for 2 input rates

Figure 3.11: Frame loss rate comparison

between simple and distributed MAC for 2

input rates

Figure 3.10 shows that at relatively high SNR (higher than 0), the simple MAC outperforms the distributed

MAC in terms of throughput when the input rate is high (3 Mbits/s). We believe that this advantage is due

to the aggressive scheduling method of the simple MAC that relies only on CSMA/CA mechanism unlike

the ad hoc MAC that implements a busy tone channel to reduce collisions. However, even if the throughput

is high, the transmissions of the simple MAC encounters losses even at high SNR as highlighted in Figure

3.11. When reducing the SNR value, we notice a decrease in the throughput of the simple MAC caused by

a high frame error rate. On the contrary, the distributed MAC is able to keep the throughput stable and the

frame loss ratio very low (almost 0) until reaching an SNR of around -2.4. Note after this value, the receiver

is not able to retrieve the initial information hence the collapse of the performance. Note here, that at low

input rate (1 Mbits/s), the load of the system is low that both MAC protocols are able to schedule their

transmissions easily (few nodes competing for resources), thus simple and distributed MAC offer similar

performance. The system continues to operate without errors until reaching the reception breaking point

(SNR of -2.4).

We now consider a more complex topology, offering multiple routes i.e. a scenario where the RESCUE

joint decoding applies. In our particular case we have considered two routes with different lengths to

increase the diversity. Note that during these simulations, no ARQ mechanism is implemented. This is done

in order to allow fair comparisons between the considered protocols. The simulated topologies simplify the

general public safety scenario described previously and are shown in Figure 3.12.

Figure 3.12: Simulated assymetric multi-route topology that simplifies the public safety scenario

As stated earlier, our objective is to characterize the influence of the added features of the ad hoc MAC on

the performance in a multihop topology. For this reason, we investigate again in our comparisons on the

two main studied metrics in this document i.e. the end-to-end throughput observed at the destination as well

as the Frame Loss Ratio (FLR). We derive these two metrics for different input application rates at the

Destination

source

relayPath1


Page 28 (79)

source and also while varying the minimum SNR in our topology. Indeed, since we consider a multihop

topology, we plot the observed throughput and loss ratio function of the bottleneck SNR over the path. Note

that the effective total SNR obtained at the destination is higher than the one we use as it considers all the

SNRs on the route. Note also, that in order to explore different SNR values, we modified the nodes

transmission power. We have again run these simulations for 2 different input (application) rates.

Figure 3.13: Throughput comparison over mult-

route topology

Figure 3.14: Frame loss ratio over the multi-route

topology

Looking at the throughput curves, they highlight 2 important results. First, the distributed MAC

outperforms the simple MAC. Indeed, regardless of the input rate 1Mbits/s or 3 Mbits/s, the added

mechanisms in the ad hoc MAC help alleviate the collisions thus increase the throughput. In particular, the

busy tone control channel is able to extend the carrier sensing one additional hop and eliminate in some

cases the hidden node problem. Second, one can find surprising that for 6Mbits/s capacity link, the observed

throughput is higher for 1 Mbits/s input rate than for 3 Mbits/s for the simple MAC protocol. However, this

result is somehow classical in multihop wireless network using CSMA based access techniques. More

precisely, with these access methods the wireless resource is shared evenly between competing nodes,

hence the “real” capacity observed by users shall be roughly divided by 4 in the considered line topology

in our simulations. These observations were already proven and demonstrated in the literature [14] [15].

Therefore, the communication capacity cannot exceed 2Mbits/s in our topology when the theoretical link

capacity is 6 Mbits/s using classical CSMA access technique (simple MAC). For this reason in our

simulations, the throughput completely collapses for input the 3 Mbits/s input rate causing congestion and

retransmissions and yielding lower throughput than 1 Mbits/s input rate. With the help of the receiving busy

tone channel and adapted inter frame timers that favor relaying over new frames from the source, the

distributed MAC can increase the capacity for communications thus allowing higher input rates and

throughputs.

Similar conclusions can be made for the Frame Loss Ratio (FLR) curve. In particular, the simple MAC

suffers from higher losses than the proposed distributed MAC. Moreover, an input rate of 1 Mbits/s offers

better performance than 3 Mbits/s with this simple MAC strategy due to reasons detailed earlier. Besides,

the distributed MAC can maintain a low level of errors until an SNR of -4.9 dB. Note that this breaking

point is the same for simple and distributed MAC meaning that it constitutes a limit for the joint decoding

of RESCUE.

3.3 Centralized MAC


The RESCUE Centralized MAC protocol described in D3.1 is a coordinated medium access method which

was designed to minimize collisions. It works in networks consisting of an access point (AP) and user

stations (STAs) being one-hop neighbours of the AP. The operation of Centralized MAC is based on a

super-frame consisting of a contention free period (CFP) and a contention period (CP). Channel access is

realized using CSMA/CA in the CP (in which stations send resource reservation requests) and using TDMA

in the CFP. The AP sends a beacon (B) frame at the beginning of each CFP in order to inform STAs about

transmissions scheduled for the next CFP. The AP also decides which STAs should act as relays and


Page 29 (79)

therefore no routing mechanism is required by the centralized MAC. Additionally, the source nodes reserve

TDMA slots for the planned uplink transmission in the CFP using the resource reservation (RR) frames

transmitted in the CP.

The DATA frame specific to the RESCUE Centralized MAC is similar to the one presented for the

Distributed MAC in Section 3.2, however, the MAC Protocol subfield of the CTRL field is set to 1 instead

of 0.

Figure 3.18: The Resource Reservation frame format.

Figure 3.18 provides a description of each of the fields in the RESCUE Resource Reservation frame. The

frame begins with a preamble followed by a 2-byte control (CTRL) field within which the Data Rate Next

field specifies information regarding the MCS used to transmit the next data frame. The Frame Length Next

field informs about the length of the planned DATA frame transmission. The CTRL field is followed by

the Duration Next field, which informs about the duration of the transmission of the next data frame. The

source Address is the PHY address of the sender S. The destination Address is the PHY address of the

destination. Other fields are the same as specified in Section 2.2.

Figure 3.19: The Beacon frame format.

Figure 3.19 provides a description of each of the fields in the Beacon frame. The 2-byte CTRL field includes

information on the supported data rates, QoS capability, configured channel number, assumed transmission

(TX) power and the number of entries in the scheduled list. The Timestamp field is used for network

synchronization. The source address field is the address of the AP. The beacon interval is the time duration

between two beacon frames. The length of the CFP period is specified in the 4-byte CFP period field. The

4-byte TDMA timeslot field indicates the length of a single TDMA slot. The scheduled list field has a

dynamic length and it contains the list of reserved uplink transmissions.


The simulations of the RESCUE Centralized MAC were performed for the network topology presented in

Figure 3.20 with one to 25 stations sending data to the AP. Each sending station Si had a dedicated relay

Ri, placed in the middle of the distance between the sending station Si and the destination (D) station (i.e.,

the AP).

Typ

e

Dat

aR

ate

3 2

Sen

d W

indo

w

4

Blo

ck A

CK

Con

t. A

CK

1 1Bits:

Dat

aR

ate

Nex

t

2

Synchronization

SFD CTRL Source AddressDestination

AddressSEQ.

Inte

rle

aver Header

checksum

Preamble PHY Header

2 6 6 2 1 4Bytes:

Type: 100 (Resource Reservation)DataRate: MSC used;Send Window: how many unACKed frames the station can send;Block ACK: 1 – requested/supported, 0 – not allowed;Continous ACK: 1 – requested/supported, 0 – not allowed;QoS: 1 – supported, 0 – not supportedData Rate Next: the frame length of the planned DATA transmissionReserved: for future use

1

Qo

S

MBF

2

Du

ratio

nN

ext

2

Res

erv

ed

2

Typ

e

Supp

.D

ata

Rat

es

3 2 1Bits:

Synchronization

SFD CTRLSource

Address

Preamble PHY Header

2 6Bytes:

Qo

SC

apa

bilit

y

Cha

nn

el Type: 011 (Beacon)Supp. Data Rate: Supported Data Rates;QoS Capability: 1 – supported, 0 – not supported;Channel: Channel numberTX Power: The assumed TX powerSched. list size – the numer of entries in the schedules list

Header checksum

4

2

Timestamp

4

TX P

ower

Sch

ed.

list

size

3 5

Beacon Interval

4

Scheduled list

CFP period

Dynamic4

TDMA timeslot

4


Page 30 (79)

Figure 3.20: Network topology scenarios used for the RESCUE Centralized MAC validation.

The parameters listed in Table 3.1 were used for the simulation with the following exceptions:

Propagation loss model: fixed

Traffic load: 15 Mb/s (saturation)

Throughput improvement of the Centralized MAC over the baseline (as described in Section 2.6) is visible

when the link quality deteriorates for different metrics (throughput, FLR, delay, jitter), regardless of the

number of stations transmitting to the AP (Figures 3.213.24). In Figures 3.21-3.24 the throughput and

FLR values are similar for each configuration. For the Centralized MAC, the throughput is about 4 Mb/s at

higher SNR (from -1.5 dB down to -1.8 dB), 2 Mb/s at lower SNR (from -2.1 dB down to -5 dB), and it

drops to zero under SNR lower than -6.2 dB. For the baseline the throughput drops to zero when SNR is

lower than -2.4 dB. FLR for the Centralized MAC is 0% for SNR in the range (-1.5 dB, -5.7 dB) and for

the baseline it is 0% for SNR in the range (-1.5 dB, -1.8 dB). For the Centralized MAC and the baseline

delay and jitter values increase when the number of sending stations increases because each sender has to

wait longer for accessing the wireless channel.

(a) (b)

(c) (d)

Figure 3.21: Performance results of Centralized MAC with one sender for four metrics: (a)

throughput, (b) FLR, (c) delay, and (d) jitter under saturation.

S1R1 D

S2

R2

S3

R3

SN

RN

RiSi

0

0.5

1

1.5

2

2.5

3

3.5

4

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]

Baseline Centralized MAC

0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

200

400

600

800

1000

1200

1400

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

100

200

300

400

500

600

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

Title



Page 31 (79)

(a) (b)

(c) (d)

Figure 3.22: Performance results of Centralized MAC for five sending stations in the network for

four metrics: (a) throughput, (b) FLR, (c) delay, and (d) jitter under saturation.

(a) (b)

(c) (d)

Figure 3.23: Performance results of Centralized MAC for 10 sending stations in the network for four

metrics: (a) throughput, (b) FLR, (c) delay, and (d) jitter under saturation.

0

0.5

1

1.5

2

2.5

3

3.5

4

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]


0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

500

1000

1500

2000

2500

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]


0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]


0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]



Page 32 (79)

(a) (b)

(c) (d)



(a) (b)

(c) (d)



0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]


0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

2000

4000

6000

8000

10000

12000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

500

1000

1500

2000

2500

3000

3500

4000

4500

5000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]


0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]


0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

500

1000

1500

2000

2500

3000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]



Page 33 (79)

(a) (b)

(c) (d)



When all stations around the AP are within interference range, the distributed approach (Simple MAC)

slightly outperforms the centralized approach for all metrics except PLR, regardless of the number of

stations (Figure 3.27).

(a) (b)

(c) (d)

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]


0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

2000

4000

6000

8000

10000

12000

14000

16000

18000

20000

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]


0

0.5

1

1.5

2

2.5

0 5 10 15 20 25 30

Thro

ugh

pu

t [M

b/s

]

No of STAs

Centralized MAC Simple MAC

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

0 5 10 15 20 25 30

FLR

[%

]

No of STAs


0

2000

4000

6000

8000

10000

12000

0 5 10 15 20 25 30

Jitt

er

[ms]

No of STAs


0

2000

4000

6000

8000

10000

12000

0 5 10 15 20 25 30

De

lay

[ms]

No of STAs



Page 34 (79)

Figure 3.27: Performance comparison of Centralized MAC and Simple MAC for variable number of

sending stations in the network for four metrics: (a) throughput, (b) FLR, (c) delay, and (d) jitter

under saturation.

However, in the presence of hidden nodes, the coordinated channel access of the Centralized MAC is

superior to Simple MAC since it allows avoiding collisions between data transmitted by nodes hidden from

each other. Figure 3.28 presents the results for a network composed of an AP, five senders, and five relays

(all five Sx-Rx pairs are hidden from each other).

(a) (b)

(c) (d)

Figure 3.28: Performance comparison of Centralized MAC and Simple MAC for a five STA network

with hidden nodes for four metrics: (a) throughput, (b) FLR, (c) delay, and (d) jitter under saturation.

The conclusions drawn from the implementation and simulation results of RESCUE Centralized MAC are

the following.

1. The Centralized MAC outperforms the baseline (described in Section 2.6) under all key

performance indicators (throughput, delay, jitter, and FLR).

2. The performance of the Centralized MAC is worse than the performance of the Simple MAC for

infrastructure networks if hidden nodes are not present in the network. However, for a network

with hidden nodes the performance of Simple MAC is unsatisfactory while the performance of

Centralized MAC is much better than the baseline.

0

0.5

1

1.5

2

2.5

3

3.5

-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]

Simple MAC Baseline Centralized MAC

0

20

40

60

80

100

120

-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]


0

1000

2000

3000

4000

5000

-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]


0

100

200

300

400

500

600

700

-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]



Page 35 (79)

4. Routing

Routing protocols are fundamental to the determination of the appropriate paths over which data are

transmitted in ad-hoc networks. Ad-hoc networks are established by a group of nodes that communicate

with each other to form a multi-hop radio networks. Their autonomous topology allows the creation of non-

permanent purpose-built networks, that can be set up without infrastructure constraints and operate under

dense conditions. Current routing protocols inherently trust all participants being cooperative by nature and

depend on neighbouring nodes to route packets to the destination. Depending on their route discovery

mechanisms ad hoc routing protocols are classified into three discrete categories named proactive, reactive

and hybrid. Proactive protocols maintain all possible routes throughout the routing operation by exchanging

control messages on a regular basis, whereas reactive protocols remain in a “sleep” mode, until triggered

by a transmission request. To address the challenges that arise from the performance trade-offs, hybrid

protocols combine both approaches with the view to increase the overall routing performance.

4.1 RESCUE Multipath Routing Protocol

This section introduces a multipath routing protocol based on the Expected Transmitted Count (ETX)

instead of the traditional hop count, proposed for the purposes of the RESCUE project. RESCUE routing

protocol called RESCUE OLSR (R-OLSR), adopts the proactive routing which allows topology awareness

through the periodic exchange of control messages. The designed protocol considers a multipath approach

for the route calculation, aiming to increase throughput and transmission reliability. In addition, it utilizes

a link metric called ETX which estimates the number of successful transmission required for a packet to

traverse a path. Two variants of the routing protocol (R1-OLSR and R2-OLSR) have been designed

following different relay approaches described below and taking into account the RESCUE MAC layer

capability to perform joint decoding of the received packets via different transmission paths.

4.1.1 RESCUE Routing Relay approaches

In the RESCUE project, considering the scenarios described and plans for extending the described

implementations in dense deployments, the following two relay approaches have been considered and

adopted in the design of R-OLSR. In particular, R1-OLSR has been designed to be in line with the simple

relay routing approach while R2-OLSR follows the characteristics of the advanced relay routing approach.

Simple Relay Routing (SRR): each node upon receiving a packet performs a simple “sanity” check to

determine whether there is an available path to the destination that does not include the message sender. In

the case where no available path exists, the message is discarded. In any other case, the message is

forwarded to all available paths, regardless the quality of the link or the number of hops required to be

transmitted.

Advanced Relay Routing (ARR): each node with paths towards the destination upon receiving a packet

takes a binary decision on whether to drop or forward the received data towards the destination based on

the available paths. The ARR approach instead of flooding the network with redundant information,

forwards data to a predefined number of paths originating after a node with disjoint paths. R2-OLSR which

corresponds to the ARR approach sets a transmission path limit based on the minimum (optimal) ETX

values towards the destination.


This section presents the fundamental concepts on which the R-OLSR lays its foundation. It introduces the

theoretical concepts by discussing the multipath approach as an efficient routing solution to provide

improved performance resiliency, and outlines the theoretical foundation of the ETX link metric.

4.1.2.1 R-OLSR Specification and Design R-OLSR is a proactive OLSR based routing protocol, extended to calculate multiple routing paths based

on the ETX link metric instead of the traditional hop count. The hop count's attribute to calculate routes

based on the minimum hops increases the probability of broken links, since other parameters such as

distance, BER or bandwidth are not evaluated. The ETX metric has emerged in recent years as a promising

and intelligent alternative, which calculates the estimated number of transmissions required for a node to

successfully transmit a single packet using a link. Loss rates are calculated in both directions as illustrated

in Figure 4.1. In particular, node A to B calculates the direct link quality (dlq) as the probability of a

successful transmission within a window period. Similarly, node B to A calculates the probability of a


Page 36 (79)

successful transmission on the reception (rlq). The ETX function used for the purposes of R-OLSR for a

single link equals to:

ETX = dlq * rlq (4.1)

Within this context, the ETX value of an investigating path equals to the sum of the ETX values

corresponding to the links of this path.

Figure 4.1: Representation of ETX functionality

The operation of R-OLSR is similar to that of OLSR, adopting the periodic exchange of control messages

named HELLO and Topology Control (TC) messages. HELLO messages are generated and transmitted to

1-hop neighbour and are not any further relayed to the rest of network nodes. The periodic exchange of

HELLO messages offers a convenient mechanism to calculate the ETX, simplifying the link quality

evaluation of the path. In the example of Figure 4.1, node A is not aware of the number of packets node B

wants to transmit. However, it is able to estimate the total number of HELLO messages through node’s B

HELLO time interval. The main tasks of HELLO messages based on the original OLSR protocol involve

the link sensing, the neighbour detection and the MPR selection. R-OLSR follows these principals and

extends them so as to include the ETX calculation. The link sensing process is responsible for the

maintenance of the node's local link information base, which stores information about the node's links to

its neighbours. In R-OLSR, the ETX computation is incorporated inside the link sensing process so as to

allow the link tuples to store information about the ETX value attributed to the link. The neighbour detection

offers 2 hop neighbours identification where addresses are stored within the 2-hop neighbour set. Similar

to the link set, the 2-hop neighbours set maintains information of the ETX corresponding to the link quality

of the 2-hop neighbour.

R-OLSR adopts the MPR computation approach of OLSR, via the periodic exchange of HELLO messages.

Unlike common flooding mechanisms where each node of the network retransmits the received

information, MPRs are composed by a set of nodes which are efficiently segmented throughout the network.

The MPR flooding procedure reduces the improvident emission of routing messages allowing elimination

of redundant transmissions. TC messages as part of the flooding procedure send diffused information

globally in the network and are used for the calculation of the routing table through the topology sensing

process. Initially, TC messages offer nodes the ability to obtain the ETX value corresponding to the

generator of the message and its own MPR selectors. The reason the TC messages are carrying the ETX

value is to offer link information to the topology set. Each time a TC message is received, the topology set

is updated. Similarly to the link set and the 2-hop neighbour set, an ETX value is added in each of the

topology tuples. It essentially evaluates the quality of the link between the MPR selector and the message

generator.

The multipath approach in R-OLSR includes two discrete parts. The first part is the topology sensing which

involves the topology awareness through the exchange of topology information by the MPRs. The second

part is the route computation, including the multi-path calculations through the use of the information

obtained during the topology sensing. Nodes determine the number and size of routes through the periodic

exchange of HELLO and TC messages. During the multipath approach, destinations utilise multiple

available routes which may result to extra computational costs that impact the energy resources of the

protocol. In the traditional OLSR, only one path is used for packet delivery between source and destination

nodes and packets are lost when nodes in the paths to destination go out of range. The path to destination

is also embedded onto the packet. In R-OLSR, R1-OLSR has been developed using the SRR approach

while R2-OLSR has been developed using the ARR approach. In both approaches, multiple paths are used

in data delivery between source and destination. There is no limit on the number of paths for concurrent


Page 37 (79)

data transmission using the SRR while the ARR approach introduces a limit on the number of concurrent

transmissions between source and destination. To achieve that goal, disjoint paths corresponding to a

particular destination within the routing table, are sorted in an ascending order based on the minimum ETX

value, to offer efficient transmission to the two most optimal paths. At the destination, the RESCUE MAC

layer functionality of joint decoding is applied on received packets in order to increase the integrity of the

message delivery process and recover erroneous packets delivered over lossy links.

4.1.2.1 Route computation

R1-OLSR Route Computation: The route is computed following the SRR approach. In order to deliver a

packet from the source to the destination, all nodes upon receiving a packet check whether they have a path

to the destination or not. The path must not include the message sender and if so, the packet is forwarded.

Figure 4.2 shows the routing decision diagram for the SRR approach.

Figure 4.2: R1-OLSR Routing Decision Diagram for SRR Approach

On the other hand side, the ARR approach may be considered as an advancement of the SRR. According

to this approach, each node upon receiving a packet checks to see if paths for transmission towards the

destination exists. The node will decide to forward the packet or not, based on its knowledge of the global

topology. In order to reduce flooding, the number of paths to which packets are forwarded can be varied

within the ARR approach. As previously explained, for evaluation purposes in RESCUE, R2-OLSR has

limited the set of transmissions arising from disjoint nodes to two minimum (optimal) ETX values

corresponding towards the destination. In the case of having a number of paths to a destination with the

same ETX values, then a random selector is used to determine the path. Figure 4.3 presents the routing

decision diagram for the ARR approach.

Source Node

Identify all the

reachable

nodes in the

network

Identify Node A

Does Node A have a path to

the detination?

Do nothingForward the

packet to the

next node(s)

No Yes

Repeat process for next nodes


Page 38 (79)

Figure 4.3: R2-OLSR Routing Decision Diagram for ARR Approach

Figure 4.4 presents an extension of the toy scenario for a better understanding of the SRR and ARR

approaches. For the SRR, let’s assume that the source node has to send a packet to the destination node.

The source node is aware of the topology information of the network through the topology sensing process.

Hence, it sends the packet to node 2, which has a path to the destination, and then node 2 sends the packet

to node 3. Node 3 has 5 available paths towards the destination, so it sends the packet through 5 different

routes. This process is repeated as long as the node has a path to the destination. At the destination,

RESCUE MAC layer functionality of joint decoding is applied on the packets received from different paths.

Figure 4.4: A multi-hop extension of the toy scenario

For the ARR approach, in the case that the source node has to send a packet to the destination node with

the source node being aware of the topology information of the network through the topology sensing

process, it sends the packet to node 2, which has a path to the destination, and then node 2 sends the packet

to node 3. Node 3 will as well broadcast the packet to nodes 4, 5, 6, 7 and 8. Each of these nodes upon

receiving the packets will decide whether to forward packets or not based on the two most optimal ETX

values. At the destination, RESCUE’s MAC layer joint decoding is thereafter applied and packets (either

erroneous or not) are combined as required.


Page 39 (79)

4.1.3 Simulation results and Performance Analysis

4.1.3.1 Simulation Parameter

The proposed routing protocols following the SRR and ARR approaches are developed and simulated in

the NS-3 environment and compared with the OLSR-ETX. The project experimental setup is implemented

within a 800m by 800m area in which nodes are randomly installed with a transmission power of 20dBm.

The following table describes the overview of the simulation characteristics.

Table 4.1: Simulation Parameter for Multipath Routing Protocol

Parameter Value

Data Rate 6Mbit/s


Topology Dimension 800m x 800m

Mobility Model Random Waypoint

Transmission Power 20dBm

Path Loss Model LogDistance

Fading Model Nakagami

Path Loss Exponent 3

Modulation Scheme BPSK

Simulation time 100sec

4.1.3.2 Evaluation Criteria

The objective of the simulations with the network simulator NS-3 is to validate our proposed routing

algorithms based on the two stated approaches by analysing the following performance metrics:

Throughput: the amount of traffic received in Mbps

Packet Loss: describes the percentage of packets that failed to arrive to the destination. Average End-to-End Delay: represents the average time required for the data packets from the

source to arrive at the destination. This includes the transmission and propagation delays and it

reflects the effectiveness of the routes. Routing Overhead: The number of routing messages generated per simulation, used for the

purposes of route discovery and maintenance. Convergence Time: the time it takes for nodes to fully populate their routing tables until stability

is reached for the first time.

4.1.3.3 Simulation Results

There are two implemented scenarios with the view to validate the performance of the proposed protocols.

In the first scenario we evaluate the effect of node mobility on the performance of the two proposed routing

protocols. The total number of nodes within the investigating topology are 15. Among them, there are 2

pairs of nodes which act as sources and destinations, while the rest of nodes are used as intermediate nodes.

Figure 4.5: Throughput versus node speed

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

4 8 12 16 20 24 28 32

Th

rou

gh

pu

t (

Mb

ps)

Speed of nodes (m/sec)

R1 OLSR

R2 OLSR

OLSR ETX


Page 40 (79)

Figure 4.5 illustrates the throughput as the node speed increases. In each run for this scenario, the node

speeds have been set to be constant throughout the simulation period. The graph shows that all protocols

have a similar behaviour while operating between 4m/s and 8m/s. Beyond that point, throughput gradually

decreases due to the complexity of the topology. The graph shows that the R1-OLSR through its ability to

identify and transmit data via unlimited multiple paths, achieves the largest amount of data transfer

compared to the rest of the protocols. R2-OLSR also achieves better throughput throughout the range of

compared speed than OLSR-ETX. It can be deduced that both routing protocols utilizing multiple paths

provide higher throughput values when compared to OLSR-ETX with a single path between Source and

Destination.

Figure 4.6: End-to-end delay versus node speed

Figure 4.6 presents the end-to-end delay as the speed of nodes vary from 4m/s to 32m/s. OLSR ETX has

the highest end-to-end delay, followed by the two proposed RESCUE routing protocol. In particular, the

R2-OLSR experiences the least end-to-end delay while operating between 16m/s to 24m/s, whereas the R1-

OLSR gains leverage compared to R2-OLSR while operating at 12m/s, 28m/s and 32m/s. The superior

performance of the RESCUE protocols can be attributed to the fact that they efficiently distribute packets

to different paths restricting the effects of queue delay therefore they could be more suited to satisfy QoS

requirements.

Figure 4.7: Packet loss versus node speed

Similar to throughput and end-to-end delay, the RESCUE routing protocols achieves lesser packet loss as

shown in figure 4.7. It is evident that the packet loss of the two multipath routing protocol is reduced

because of the availability and usage of multiple paths from source to destination. The R1-OLSR and R2-

OLSR work in similar manner by forwarding packets to next hop nodes with paths towards destinations. In

0

10

20

30

40

50

60

70

4 8 12 16 20 24 28 32

En

d-t

o-e

nd

del

ay

(m

sec)

Speed of Nodes (m/sec)

R1 OLSR

R2 OLSR

OLSR ETX

0

2

4

6

8

10

12

14

4 8 12 16 20 24 28 32

Pa

cket

lo

ss (

%)


R1 OLSR

R2 OLSR

OLSR ETX


Page 41 (79)

the case of OLSR ETX, packets are lost once the singular path towards the destination fails. The results

also shows that the packet loss increases as the mobility of the nodes increase.

Figure 4.8: Routing overhead versus node speed

Figure 4.8 shows the number of routing messages generated for the purposes of route discovery and

maintenance for each routing protocol while increasing the speed of nodes. R1-OLSR generates the least

routing messages compared to R2-OLSR and OLSR ETX. As nodes constantly move in different directions

within the investigating area, the routing overhead is seen to gradually increase as the speed of the nodes

increase.

In the second scenario, we evaluate the effects of varying the network size on the performances of the

routing protocols. In this case the node speed remains constant (6m/s) while the network size increases

from 4 nodes to 40 nodes. The rest of the simulation parameters follow the attributes described in Table

4.1.

Figure 4.9: Throughput versus number of nodes

Figure 4.9 shows the throughput as the network size varies. R1-OLSR and R2-OLSR achieve similar

performance in terms of throughput, thereby presenting stability as the network size increases. The

multipath attribute of the R-OLSR approaches retain a more resilient behavior during operation by

maintaining multiple paths within the routing table compare to the OLSR ETX.

13050

13100

13150

13200

13250

13300

13350

13400

13450

13500

4 8 12 16 20 24 28 32

Ro

uti

ng

Ov

erh

ead


R1 OLSR

R2 OLSR

OLSR ETX

0.4

0.5

0.6

0.7

0.8

0.9

1

1.1

4 8 12 16 20 24 28 32 36 40

Th

rou

gh

pu

t (

Mb

ps)

Number of nodes

R1 OLSR

R2 OLSR

OLSR ETX


Page 42 (79)

Figure 4.10: End-to-end delay versus number of nodes

Figure 4.10 shows the end-to-end delay as the number of nodes increase in the network, Similar to the

previous scenario, the R-OLSR approaches provide significant lesser end-to-end delay compared to the

OLSR ETX. In particular, R2-OLSR which utilises the two most optimal paths for transmission generally

achieves the least end-to-end delay compared to the simple relay routing approach of R1-OLSR and OLSR

ETX. Both R-OLSR approaches indicate a higher robustness and resilience while operating in scalable

networks compared to the single path approach. This figure essentially indicates that the ETX metric

combined with the multipath approach reduces the propagation delay by allowing transmission via higher

quality paths thereby reducing the queue delay.

Figure 4.11: Packet loss versus number of nodes

In figure 4.11, the packet loss rate as the network size increases is shown. R-OLSR multipath approaches

are able to achieve lower packet loss compared to the single path approach of OLSR ETX which has only

one single path which can fail. Broken paths have usually being identified as a major cause of packet loss

in single path transmission and typical necessitate the need for a route recovery. As shown in figure 4.11,

both R1-OLSR and R2-OLSR are able to achieve significantly low packet loss in small networks (4-12

nodes) by using multiple paths, whereas in larger networks, the packet loss are still significantly lower than

that achievable by a single path routing protocol.

0

10

20

30

40

50

60

70

80

4 8 12 16 20 24 28 32 36 40

En

d-t

o-e

nd

del

ay

(m

sec)

Number of nodes

R1 OLSR

R2 OLSR

OLSR ETX

0

2

4

6

8

10

12

14

4 8 12 16 20 24 28 32 36 40

Pac

ket

loss

(%

)

Number of nodes

R1 OLSR

R2 OLSR

OLSR ETX


Page 43 (79)

Figure 4.12: Routing Overhead versus number of nodes

Figure 4.12 shows the number of routing messages generated for the purposes of route allocation and

maintenance for each routing protocol while increasing the number of nodes. The figure introduces a trend,

where the routing overhead gradually increases as the number of nodes increase. The number of the

produced routing messages for all approaches is almost identical, with a small leverage for R1-OLSR which

manages to generate less redundant information.

4.1.4 Convergence Time

Despite the fact that topology loops provide alternative routes to destinations or concurrent alternative

routes in the case of multipath routing protocols, the Counting-to-Infinity (CTI) problem which occurs in

topology loops has to be mitigated. Topology loops are the main reason why routing loops occur and routing

protocols should be able to deal with topology and routing loops in an efficient manner in order to provide

improved convergence time and stability for the network. In the design of R1-OLSR and R2-OLSR, routing

loops are minimised by making sure that packets are not sent back to its originating node. In R-OLSR (R1-

OLSR and R2-OLSR), we do not consider recovery time after a link failure. The concept and design of R1-

OLSR and R2-OLSR are based on broadcast of data packets. Convergence time is dependent on network

topology diameter and the number of nodes. In order to compare the convergence time of routing protocols,

according to the approach in [10], coldstart tests are used to measure the convergence time from the point

when all routers are started until the network reaches a convergence state for the first time. In this case, no

CTI is incited in the network. This specific test scenario can provide the propagation speed for the routing

updates. R1-OLSR and R2-OLSR have been developed based on standard OLSR, the control messages and

message structure used by all three protocols are similar and the frequent neighbour discovery help to speed

up the coldstart convergence time. The approximated convergence time from coldstart is calculated as:

𝑇𝑎𝑝𝑝𝑟𝑜𝑥 = 2.5𝑑 + 0.16𝑛 − 5 ± 1.89 (4.2)

Where Tapprox is the convergence time, d is the diameter of network topology and n is the number of nodes

in the network topology.

Figure 4.13 shows the convergence time for the three routing protocols. It shows that OLSR ETX, R1-

OLSR and R2-OLSR all have the same coldstart convergence time for the topology considered as the

number of nodes varies. This can be associated with the fact that OLSR ETX, R1-OLSR and R2-OLSR are

built on OLSR and the control message (Hello and TC messages) all function the same with the same

frequency. Figure 4.13 also show that the convergence time increases gradually as the number of nodes in

the network increases.

0

10000

20000

30000

40000

50000

60000

70000

80000

90000

4 8 12 16 20 24 28 32 36 40

Ro

uti

ng

Ove

rhea

d

Number of nodes

R1 OLSR

R2 OLSR

OLSR ETX


Page 44 (79)

Figure 4.13: Convergence time

4.1.5 Conclusion

This section discusses the results regarding the performance of RESCUE multipath routing protocol which

utilizes the ETX as link metric instead of the tradition hop count, based on two different relay approaches

(R1-OLSR and R2-OLSR). The designed protocols were compared with the single path OLSR ETX. The

simulation affirmed that the use of multipath for transmission of data packet improves the robustness and

increases the resilient of performance against lossy links. Simulations were carried out on the basis of two

main scenarios within a MANET. The first simulation scenario used a fixed number of nodes to assess the

R-OLSR behaviour under a series of experiments with increasing node mobility. The second scenario

investigated the routing protocol scalability by measuring its efficiency in a series of experiments with

increasing set of nodes, constantly moving within a fixed area. For the purposes of the experimentation, the

NS-3 simulator was used for the design, implementation and evaluation of the protocol's performance.

As described in section 4.1.3.2, the acquired results in both scenarios proved that R1-OLSR and R2-OLSR

multipath routing approaches combined with an intelligent link metric such as the ETX, offered a significant

reduction of end-to-end delay. In addition, more packets were able to successfully reach the destination

compared to the single path approach of OLSR ETX, increasing throughput and reducing the packet losses.

R-OLSR offered improved performance in scenarios with high mobility, eliminating the effects of link

instabilities while operating in unreliable and lossy environments. Furthermore, the performance of R-

OLSR under heavy network load scenarios indicated that the multipath approach combined with an

intelligent link metric can efficiently address scalability issues that occur during transmission, increasing

the protocol's robustness.

However, a set of issues need to be taken into consideration. The use of ETX within the routing messages

increases the protocol's complexity which can result to extra bandwidth utilization by increasing the size of

control messages. In addition, both relay routing mechanisms introduced for the purposes of R-OLSR

consequently transmit multiple copies of the same packet towards the destination. This specific attribute

more inherent in the simple relay approach (R1-OLSR) lead to heavy transmission of redundant

information. In this light, the advanced relay routing approach aims to alleviate this phenomenon by

reducing the number of transmission paths originating after nodes with disjoint paths by the continued

forwarding of packets from nodes with the two most optimal ETX values. In any case, both SRR and ARR

generate duplicate packets that negatively affect the bandwidth utilization and energy consumption of the

network.

4.2 Geo-routing

This section describes the concept and advantage of geographic routing (geo-routing) in unpredictable and

harsh radio environments, in particular systems such as vehicle-to-vehicle networks. Geo-routing is a

network-layer protocol for mobile ad-hoc networks, which are characterized by a decentralized

organization of the network without the need of an infrastructure to manage the communication resources

and the reachability among the nodes to distribute packets in the network.

1995.641996.28

1996.921997.56

1998.21998.84

1999.482000.12

2000.762001.4

1995.641996.28

1996.921997.56

1998.21998.84

1999.482000.12

2000.762001.4

1995.641996.28

1996.921997.56

1998.21998.84

1999.482000.12

2000.762001.4

4 8 1 2 1 6 2 0 2 4 2 8 3 2 3 6 4 0

CO

NV

ERG

ENC

E TI

ME

IN M

SEC

NUMBER OF NODES

R2-OLSR R1-OLSR OLSR ETX


Page 45 (79)

Geo-routing supports unicast (point-to-point) and broadcast (point-to-multipoint) communication. For

unicast geo-routing, the source sends a packet to a geographic position, which may need to be acquired

from a location service (such as based on a location request/reply scheme or a database that maintains

position information). For broadcast geo-routing, which is the more relevant scenario for vehicular safety

applications as well as disaster recovery scenarios, geo-routing can send a packet to a geographical region

to reach all nodes located inside the area. Due to the knowledge of the destination node or area position and

the fact that every node also knows its own position, the network topology does not to be known a priori,

which represents an important difference to existing routing protocols. There is no complete route needed

before the packet is sent, hence the network is robust against failing nodes while the packet is forwarded

through the network.

In CBF the decision whether a packet is forwarded or not is made by the relay, using its own geographic

position, the position of the sender, and the position of the destination. The node with the most progress to

the destination forwards it. If this node fails the second one takes on this part and so on, therefore it has an

intrinsic reliability if the network topology changes and some nodes fail to forward a packet.

4.2.1 Services

For the RESCUE extensions of geo-routing, the RESCUE physical layer offers a function that provides a

confidence value of the packet quality to the network layer. This value is used in the calculation for the

timeout of the forwarding algorithm.


4.2.2.1 Normal CBF

CBF is used to forward a packet to a dedicated destination or to a geographic area. It is a receiver-based

forwarding algorithm where the source broadcasts the packet to all neighbours and they decide to forward

the packet or not. Those receivers with a positive geographical progress of the packet towards the

destination buffer the packet in a buffer and start a timer with a timeout value that depends on the distance

to the destination (see (4.3) and Table 4.2). The position of the destination is obtained from a location

service. A node with a shorter distance has a shorter timer. When the timer expires the packet is re-

broadcasted to all neighbours. If a node receives the same packet a second time before the timer expires, it

removes this packet from the buffer and stops the timer.

𝑡𝑡𝑖𝑚𝑒𝑟 = 𝑡𝑚𝑎𝑥 − 𝑡𝑚𝑎𝑥−𝑡𝑚𝑖𝑛

𝑑𝑚𝑎𝑥𝑝𝑟𝑜𝑔 for 𝑝𝑟𝑜𝑔 ≤ 𝑑𝑚𝑎𝑥 (4.3)

𝑡𝑡𝑖𝑚𝑒𝑟 = 𝑡𝑚𝑖𝑛 for 𝑝𝑟𝑜𝑔 > 𝑑𝑚𝑎𝑥

𝑝𝑟𝑜𝑔 = 𝑑𝑖𝑠𝑡(D, Se ) − 𝑑𝑖𝑠𝑡(D, 𝑅𝑖)

Table 4.1 Parameter description of the CBF timer calculation

Unit Description

ttimer Timeout of the timer for buffering the packet

tmax Maximal timeout

tmin Minimum timeout

dmax Maximum theoretical communication range

S, Se, D, Ri Geographic position of the source, sender, destination and relays

prog Forwarding progress of the relay towards the destination

4.2.2.2 Extensions for RESCUE

In the standardized CBF algorithm [1] a packet is dropped if it is received a second time, hence there is

only one route to the destination. In RESCUE, multipath distribution of the packets is required to merge

erroneous packets, which arrive from different disjoint paths in the destination, to an error-free packet,

using distributed joint source and channel coding as well as specific signal processing algorithms. For this

reason, CBF is extended by retransmission counters and a mechanism that enables the transmission of

erroneous packets. Every time when a relay receives a copy of the packet in the contention period the

retransmission counter is incremented and the packet is also stored in the buffer and not dropped. When the

CBF timer expires, the packet is forwarded unless the retransmission counter exceeds a threshold. With the

threshold it is possible to control the load in the network and select the number of routes that should be

used. After the packet is sent every further packet will be treated as duplicate and dropped.


Page 46 (79)

In general, packets transmitted over lossy links can be erroneous. In order to take into account the quality

of a received packet, the PHY layer provides a confidence value of every received packet, which is

incorporated into the calculation of the timeout, meaning that packets with a lower confidence value have

to wait longer. If the quality of a packet exceeds a threshold (in our case if there are more than 20% errors

inside) it is dropped and not retransmitted anymore.

Another requirement for links-on-the-fly is to have disjoint links in order to guarantee uncorrelated errors

inside the packets. However, in vehicle-to-vehicle scenarios the vehicles move close together (roads are

narrow compared to the communication range) and if one relay retransmits the packet it is received by

every neighbour. Then the neighbours might have a set of packets which are originated from the same

sender. To enable disjoint links and avoid forwarding of correlated errors the relay needs to know the last

two relays and forwards only packets with different last two senders. One exception are the packets from

the source which will be forwarded every time.

Table 4.3 Functions of the CBF algorithm

Function Description

Buffer Stores a packet until it will be retransmitted

Timer Calculated depending on the distance to the destination and the

confidence value from the physical layer. A small distance and a high

confidence value means a short timer.

Location Service (LS) Provides the geographic position of the destination.

Retransmission Counter (RC) Counts how often the same packet is received.

Retransmission Threshold

(RT)

If the retransmission counter exceeds the retransmission threshold,

the packet is removed from the buffer and the timer is stopped.

4.2.2.3 Protocol operations for CBF

Figure 4.13 illustrates a toy scenario (TS2) to explain the functionality of the CBF algorithm in detail.

S D

B

A

Figure 4.13: The toy scenario (TS2) relevant to geo-routing

This network consists of a source S, a destination D and two relays A, B. Node S wants to send a packet to

D but there is no LOS. S broadcasts the packet to the relays A and B, which starts a timer depending on the

distance to D. The links between S-A and S-B are lossy, meaning that the packets received in A and B

cannot be completely decoded error free but they are still forwarded to D. In this scenario, A is

geographically closer to D, therefore its timer is shorter. After expiration of the timer in A the packet is re-

broadcasted to every neighbour which are S, B and D in this scenario. Even though B receives the packet a

second time it waits until the timer expires and also re-broadcasts the packet to every neighbour, instead of

dropping it as in the standard CBF algorithm. Now the destination is able to apply joint decoding to merge

the different copies of the packet. In this scenario it is not necessary to know the last two senders since the

packets from the source will be forwarded every time.

4.2.2.4 Flow diagram for the CBF algorithm

Figure 4.14 illustrates the CBF algorithm including the extensions for RESCUE requirements.


Page 47 (79)

Source Node

Neighbor

Broadcast packet to all

neighbors

Packet

Is P in bufferNo

Calculate progress

Remove P from buffer

Stop timer

Discard P

Progress > 0 yes

Add P to buffer

no

Discard P

Calculate timeout

Start timer

Neighbor

Timer expires

Take P from buffer

Send P to MAC

Input confidence

value

Yes

Is RT threshold reached

No

Increment retransmission

counterYes

Guarantee disjoint paths

Store copy in buffer

Figure 4.14: Flow diagram of the CBF algorithm.


This section describes the simulation results of the new and extended CBF (RESCUE CBF) compared to

the normal standardized CBF specified in ETSI EN 302 636 [1]. The evaluation scenario is described in

Section 2.4.1. The simulations were executed with 20 different seeds to achieve a statistical significance

and error bars are shown in the figures.

4.2.3.1 KPIs

To evaluate the performance and compare the algorithms the KPIs packet success rate (PSR), end-to-end

delay (E2ED) and data traffic overhead (DTO) were chosen. For safety and traffic efficiency applications

it is important that every vehicle receives the message reliably and in-time, which is measured by the PSR

and E2ED. The PSR is defined as the number of packets successfully received at the destination divided by

the source transmitted packets:

𝑃𝑆𝑅 = 𝑁𝑜.𝑜𝑓 𝑅𝑥 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑎𝑡 𝑑𝑒𝑠𝑡𝑖𝑛𝑎𝑡𝑖𝑜𝑛

𝑁𝑜.𝑜𝑓 𝑇𝑥 𝑝𝑎𝑐𝑘𝑒𝑡𝑠 𝑓𝑟𝑜𝑚 𝑠𝑜𝑢𝑟𝑐𝑒.

The E2ED is defined as the difference of the timestamp when the message is generated by the source and

the timestamp when it is received by the destination:

𝐸2𝐸𝐷 = 𝑡𝑅𝑥 − 𝑡𝑇𝑥.

In order to measure the network load the DTO is introduced. It enables the measurement of the

retransmissions in the network and is defined by the number of transmissions in the PHY divided by the

number of sent packets in the facility layer:


Page 48 (79)

𝐷𝑇𝑂 = 𝑁𝑜.𝑜𝑓 𝑓𝑟𝑎𝑚𝑒𝑠 𝑠𝑒𝑛𝑡 𝑓𝑟𝑜𝑚 𝑃𝐻𝑌 𝑙𝑎𝑦𝑒𝑟

𝑁𝑜.𝑜𝑓 𝐷𝐸𝑁𝑀𝑠 𝑠𝑒𝑛𝑡 𝑓𝑟𝑜𝑚 𝑓𝑎𝑐𝑖𝑙𝑖𝑡𝑦 𝑙𝑎𝑦𝑒𝑟.

4.2.3.2 Results

Figure 4.15 presents the packet success rate of the normal CBF (LOTF-Off) and the RESCUE CBF (LOTF-

On) for the RESCUE case. The PSR reflects the reliability of the packet transport in the network. We

observe that the RESCUE CBF outperforms the normal CBF over the whole range. Up to 23 dBm LOTF-

On has a PSR of 100% which is very important for V2V application, e.g., hazardous location notification

where already one uninformed car can cause a big disaster. LOTF-Off is less than 100% up to 35 dBm.

With constant transmit power the largest improvement is at 16.4 dBm by 37.5 percentage points in packet

success rate. On the other hand if we claim a minimum PSR of 90% we have a gain of 6 dB in transmit

power.

Figure 4.15: Packet success rate of the large scale V2V-scenario

Figure 4.16 shows the end-to-end delay (E2ED) for both algorithms. LOTF-On has a shorter E2ED for all

transmission powers since in links-on-the-fly every packet is forwarded even there are errors inside or not.

In the normal CBF if a packet is not received correctly it is dropped and we have to wait until further timers

of other nodes expire and they rebroadcast the packet again which leads to a longer E2ED by a factor of

three. If the transmit power decreases under 10 dBm just a few packets receive the destination and therefore

the statistics becomes worse and the error bars increase. With further decreasing transmit power no packets

arrive at the destination which can be decoded correctly. The second reason for the shorter E2ED is that

also the link quality is taken into account. A good link (high confidence value) has a shorter timer which

also reduces the E2ED.

Figure 4.16: End-to-End-Delay of the large scale V2V-scenario


Page 49 (79)

Figure 4.17 presents the data traffic overhead (DTO). For the RESCUE CBF the DTO is much higher due

to the permission of retransmissions after overhearing. Every packet is forwarded until a predefined

retransmission threshold is exceeded (Section 4.2.2.2). In the normal CBF the other nodes refrain from

retransmissions if a neighbour already forwarded the same packet. In very dense scenarios a high DTO

would lead to a congested data channel. In our case we consider a sparse distribution of nodes, which does

not affect the channel. Furthermore, in a scenario with a dense node distribution a sufficient number of

links for correct transmission of the packet are available – in this case LOTF would be unnecessary.

Figure 4.17: Data Traffic Overhead of the large scale V2V-scenario

Figure 4.18 presents the probability of reception over the transmit power for a different number of packets

used for joint decoding, which are required for error-free decoding: green – 1 packet, blue – 2 packets,

black – 3 packets, and the red line indicates that the packet could not be decoded correctly. The sum of all

four graphs represents the overall number of sent packets. We can see that for a high transmit power beyond

33 dBm over 80% of packets were decoded correctly with a single copy only (green line). With decreasing

Tx power also the capability to decode a packet with just one copy decreases and the blue graph where two

copies are necessary grows. At approximately 25 dBm also the black graph (three packets are needed for

decoding) becomes important and increases up to 20% at 17.5 dBm. It is worth noting that the green line

can be treated as baseline, and the blue and black graphs can be regarded as the gain achieved by the links-

on-the-fly concept.

Figure 4.18: Use of joint decoding in the large scale V2V scenario


Page 50 (79)

4.2.3.3 Conclusion

We have shown that RESCUE CBF outperforms the normal CBF in reliability (PSR) and latency (E2ED)

aspects over all regions of Tx power. It improves the PSR up to 37.5 percentage points and the E2ED by a

factor of three. As expected, the DTO is worse for RESCUE CBF since erroneous forwarding is allowed

and necessary to apply the RESCUE functionality.

Other metrics, i.e., link stability and time of convergence when routes change, were not investigated since

they are not applicable to geographic routing for a V2V scenario. As it is described in Section 4.2, in

contrast to link-state-routing protocols, in Geo-routing the information about the network topology is not

distributed. This is because the effort is too high for getting all information of every link when the topology

changes frequently. In our scenario we have multiple vehicles moving on a highway. The links change for

every new packet and therefore the packets search a way through the network.


Page 51 (79)

5. Error control

There are two independent ARQ techniques defined in the RESCUE network. The end-to-end (e2e) ARQ

(Section 5.1) is responsible for lossless communication between the source and destination in both single-

hop and multi-hop case. The partial ARQ (Section 5.2) works only on single-hop links and cannot guarantee

lossless communication in the RESCUE network. Both ARQ protocols are complimentary to provide

efficient and reliable transmission in distributed lossy link communication.

5.1 End-to-end ARQ

End-to-end (e2e) ARQ assures reliability and lossless communication between the source and destination

nodes. It uses a modified sliding window protocol to tell the source node to determine which DATA frames

need to be retransmitted. This e2e ARQ protocol operates in the Data Link Layer.


The e2e ARQ protocol uses ACK and NACK frames (messages sent by the destination node indicating that

it has correctly or incorrectly received a DATA frame) as well as timeouts (specified periods of time

allowed to elapse before a positive or negative acknowledgment is to be received) to achieve reliable data

transmission over multi-hop links. In comparison to the description of e2e ARQ presented in D3.1, the

Block NACK mechanism was added as a new feature. End-to-end ARQ exploits functionalities of the

Selective Repeat ARQ protocol but has been enhanced with a non-continuous transmit buffer mechanism

(the source node sends a number of DATA frames specified by a window size even without the need to

wait for individual ACK from the destination node). Moreover, the transmit window can be separated by

frames which were correctly acknowledged, so the distance between the first and last unacknowledged

frame in the window can be large. This mechanism can be especially useful for multi-hop networks with

high BER ratio on the transmission links, a large number of relays, and high propagation delays between

relay nodes. The operation of the end-to-end ARQ in simplest possible (basic) configuration is presented

in Figure 5.1.

The e2e ARQ protocol is equipped with additional mechanisms that should improve its performance

assuming the transmission distributed over lossy links. The first mechanism is Block ACK. Its operation is

as follows: the destination node after successfully joint decoding the first DATA frame can wait a

predefined time interval to receive more DATA frames that could be acknowledgement with a single Block

ACK frame. Moreover, if DATA frames are received at the destination node in the wrong order, the

destination node should wait a predefined time interval to receive missing DATA frames and after that the

Block ACK should be sent to the source node. The Block NACK mechanism is the functional opposite to

Block ACK. It informs the source node that a number of frames were received with errors at the destination

node. The second used mechanism is known as continuous acknowledgement. It is used to signalize the

relay nodes which are on the ACK frame path that the destination node received and correctly decoded

previous DATA frame(s). The continuous ACK number indicates the first frame that can be accounted to

the continuous frame chain of correctly decoded frames at the destination node. The relay node, after

receiving a continuous ACK frame (note that ACK frames can arrive through different relays), knows which

frames have been correctly received at the destination node and their copies can be removed from the relay’s

buffer.

A detailed description of the e2e ARQ protocol with examples of operation with different mechanisms

enabled and disabled is presented in D3.1.

The updated list of configurable parameters of the end-to-end ARQ protocol is presented below:

Window size – the general window size of the e2e ARQ (i.e., the maximum sequence number

used, e.g., eight in Figure 5.1).

Send window size – defines the upper bound on the number of unacknowledged frames that the

source node can transmit (e.g., four in Figure 5.1).

ACK timeout – the time interval the source node waits for the ACK frame before initiating

retransmission of the DATA frame.

NACK timeout – the time interval the destination node waits for other copies of the DATA frame

before sending the NACK frame.

Block ACK timeout – the time interval the destination node waits for other DATA frames before

sending the Block ACK frame.


Page 52 (79)

Figure 5.1: End-to-end ARQ based on Selective Repeat with non-continuous transmit buffer

mechanism.


The simulation analysis of the e2e ARQ protocol was performed by implementing this protocol in a

modified version of the ns-3 simulator which included the MAC implementation of Section 3.1. The

parameters listed in Table 3.1 were used for the simulation with the following exceptions:

Propagation loss model: fixed

Traffic load: 15 Mb/s (saturation)

ACK timeout (t_ACK_base): 3500 s

Furthermore, the validation was performed for various configurations of e2e ARQ (Table 5.1) and for two

network topology scenarios (Figure 5.2). The different configuration options allow to validate how each

individual mechanism impacts the performance of the whole protocol. The two network topology scenarios

allow us to first assess the basic performance of the protocol (in the single-path case) and then assess its

performance in a more realistic, multi-path scenario (in the two-path case). The number of additional hops

(relays) N was an important parameter as this protocol is designed for (and more useful in) cases where the

transmission is done over multiple links (unlike the toy scenarios described in Section 2.3).


Page 53 (79)

Table 5.1: Configuration scenarios for e2e ARQ where where N – number of additional hops, SW –

Send Window, t_ACK_base = MAX (SW×(PATHS+1), N+2), blockNACK( OFF) – the basic

sequence number in a blockACK frame refers to the last correctly received frame, blockNACK(ON)

– this sequence number refers to the last received frame (no necessarily correctly).

Scenario NACK continou

s ACK

block

ACK

block

NAC

K

ACK timeout

[s]

NACK

timeout

[s]

block ACK

timeout [s]

Basic OFF OFF OFF OFF t_ACK_base ×

2000

N/A N/A

NACK ON OFF OFF OFF 4 × t_ACK_base ×

2000

t_ACK_ba

se × 1600

N/A

ContACK OFF ON OFF OFF t_ACK_base ×

2000

N/A N/A

NACK+Cont

ACK

ON ON OFF OFF 4 × t_ACK_base ×

2000

t_ACK_ba

se × 1600

N/A

BlockACK OFF OFF ON OFF 4 × t_ACK_base ×

2000

N/A t_ACK_bas

e × 1600

BlockNACK OFF OFF ON ON 4 × t_ACK_base ×

2000

N/A t_ACK_bas

e × 1600

BlockACK+

ContACK

OFF ON ON OFF 4 × t_ACK_base ×

2000

N/A t_ACK_bas

e × 1600

BlockNACK+

ContACK

OFF ON ON ON 4 × t_ACK_base ×

2000

N/A t_ACK_bas

e × 1600

S R1 R2 RN D

Additional hops

Single-path end-to-end ARQ validation

Two-path end-to-end ARQ validation

S

RN-1

D

Additional hops

RN

Figure 5.2: Two network topology scenarios for end-to-end ARQ validation: single-path and two-

path.

To assess the performance improvement gained from using e2e ARQ we used the stop-and-wait ARQ

protocol as the baseline. This is the simplest ARQ protocol possible. Its operation in RESCUE scenarios is

described in Section 3.1.1 (i.e., it was used in the SimpleMAC protocol). The baseline results are presented

in each figure for comparison.

In general, the performance was measured with respect to three metrics (throughput, delay, and jitter), three

link quality values (SNR equal to -6.5, -4.5, or -1.5 dB), between 1 and 10 additional hops (relays) and

varying SW sizes (2, 4, 8, and 16). The link quality values describe the link quality of each individual link

between each transmitter and receiver in the network.

First, we present the results for the single path case in order to establish a basic understanding of the e2e

ARQ protocol operation in lossy-link scenarios. Figure 5.3 contains a complete set of results obtained for

the basic configuration of the e2e ARQ protocol. In this case, throughput improvement is visible for lower


Page 54 (79)

link qualities. When the links are of better quality (-1.5 dB) the throughput improvement is only for longer

paths (with more than four relays). Similarly, using e2e ARQ decreases delay at the cost of elevated jitter

values. For longer paths, delay can be stabilized at fixed values with the use of e2e ARQ. Furthermore, we

observed that SW sizes above two do not give significant gains in terms of throughput or delay but do

increase jitter.

SNR = -6.5 dB SNR = -4.5 dB SNR = -1.5 dB

Figure 5.5.3: Performance results of the basic end-to-end ARQ configuration in the single-path

topology for three link quality values (SNR equal to -6.5, -4.5, or -1.5 dB) for three metrics:

throughput (first row), delay (second row), and jitter (third row).

For the other configuration cases (NACK, BlockACK, BlockNACK) we present selected results below

(i.e., only for SNR = -4.5 dB). The results for the configuration cases which included the Continuous ACK

mechanism were omitted as this mechanism did introduce any significant changes in the results for the

single-path scenario.

Enabling the NACK mechanism also increases throughput and decreases delay but its effects are positive

for paths with at least three relays (Figure 5.4). Now, the impact of the SW value is evident with the best

throughput and delay performance achieved for SW equal to at least eight. However, this is offset by

increased jitter values.

Figure 5.4: Performance results of the NACK end-to-end ARQ configuration in the single-path

topology for links with SNR equal to -4.5 dB for three metrics: throughput (left), delay (middle), and

jitter (right).

0

0.1

0.2

0.3

0.4

0.5

0.6

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops

baseline SW=2 SW=4 SW=8 SW=16

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

0.5

1

1.5

2

2.5

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

2000

4000

6000

8000

10000

12000

1 2 3 4 5 6 7 8 9 10

Del

ay [

ms]

Additional hops


0

1000

2000

3000

4000

5000

6000

7000

1 2 3 4 5 6 7 8 9 10

Del

ay [

ms]

Additional hops


0

500

1000

1500

2000

2500

1 3 5 7 9

Del

ay [

ms]

Additional hops


0

50

100

150

200

250

300

350

400

1 2 3 4 5 6 7 8 9 10

Jitt

er [

ms]

Additional hops


0

50

100

150

200

250

1 2 3 4 5 6 7 8 9 10

Jitt

er [

ms]

Additional hops


0

5

10

15

20

25

30

35

40

45

50

1 2 3 4 5 6 7 8 9 10

Jitt

er [

ms]

Additional hops


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

1 3 5 7 9

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

1000

2000

3000

4000

5000

6000

7000

1 3 5 7 9

De

lay

[ms]

Additional hops


0

50

100

150

200

250

300

350

400

1 3 5 7 9

Jitt

er [

ms]

Additional hops



Page 55 (79)

For the BlockACK configuration the impact of the SW size is even more evident (Figure 5.5). In this case,

not all SW configurations can improve over the baseline in terms of throughput and delay. Only a large SW

(equal to 16) improves throughput regardless of the path length.

Figure 5.5: Performance results of the BlockACK end-to-end ARQ configuration in the single-path


jitter (right).

As can be expected, the BlockNACK mechanism performs better (than BlockACK) in lossy-link scenarios

(Figure 5.6). Improvements over the baseline are evident for all analysed path lengths. The SW value

slightly impacts throughput and delay and SW = 16 causes a significant increase in jitter.

Figure 5.6: Performance results of the BlockNACK end-to-end ARQ configuration in the single-path


jitter (right).

To assess the performance of e2e ACK in the single-path topology in each configuration, we provide a

direct comparison with the stop-and-wait baseline in terms of relative gain in throughput, relative decrease

of delay, and absolute change of jitter. For fixed link quality and SW values (Figure 5.7), it is evident that

not all mechanisms provide the same performance in the single-path case. In terms of throughput and delay

the BlockACK mechanism stands out with the worst performance. With regard to these metrics, the basic

and BlockNACK configurations are the best with the latter much better in achieving a low jitter. For fixed

path length and SW values (Figure 5.8) it is clear that the RESCUE e2e ARQ protocol provides the best

improvement for the target low link quality scenarios (i.e., lossy links). This is in particular true for the

basic and BlockNACK configurations. Conversely, the BlockACK mechanism performs better for higher

quality links. Another observation is that the BlockNACK mechanism can significantly outperform NACK

in terms of jitter.

Figure 5.7: Comparison of end-to-end ARQ performance with baseline in the single-path topology

for three metrics (throughput, delay, and jitter) for links with SNR equal to -4.5 dB and for a constant

send window size (SW=8).

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

1 3 5 7 9

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

1 3 5 7 9

Del

ay [

ms]

Additional hops


0

20

40

60

80

100

120

140

160

180

1 3 5 7 9

Jitt

er [

ms]

Additional hops


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

1 3 5 7 9

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

1000

2000

3000

4000

5000

6000

7000

1 3 5 7 9

De

lay

[ms]

Additional hops


0

20

40

60

80

100

120

140

160

180

200

1 3 5 7 9

Jitt

er [

ms]

Additional hops


-40%

-20%

0%

20%

40%

60%

80%

100%

120%

140%

160%

1 3 5 7 9

Thro

ugh

pu

t ch

ange

Additional hops

Basic NACK BlockACK BlockNACK

-70%-60%-50%-40%-30%-20%-10%

0%10%20%30%40%

1 3 5 7 9

Del

ay c

han

ge

Additional hops


20

40

60

80

100

120

140

160

1 3 5 7 9

Jitt

er c

han

ge [

ms]

Additional hops



Page 56 (79)

Figure 5.8: Comparison of end-to-end ARQ performance with baseline in the single-path topology

for three metrics (throughput, delay, and jitter) for a constant send window size (SW=8) and constant

number of additional hops (N=8) and varying SNR values.

Next, we continue presenting the results with the two-path topology (Figure 5.2) which constitutes a more

realistic scenario for the operation of the e2e ARQ protocol in lossy-link scenarios. Figure 5.9 contains the

results obtained for the basic configuration of the e2e ARQ protocol in this topology. Surprisingly, the

throughput improvement is visible for all link qualities. When the links are of better quality (-1.5 dB) the

throughput improvement is higher. This is especially visible for longer paths (with more than three relays).

Indeed, the proposed protocol outperforms the baseline for all SW values and all path lengths. Again,

increasing SW improves throughput and delay at the cost of elevated jitter. For longer paths, delay can be

stabilized at almost fixed values with the use of e2e ARQ and large SW sizes (SW=8 and SW=16). In

contrast to the single path case, we observed that large SW sizes have a significant gain in terms of

throughput for all link qualities. The better the link quality, the higher is gain, especially for longer paths.

The same conclusions are for the delay but not for the jitter which increases with the growth of SW size.

SNR = -6.5 dB SNR = -4.5 dB SNR = -1.5 dB

Figure 5.9: Performance results of the basic end-to-end ARQ configuration in the two-path topology

for three link quality values (SNR equal to -6.5, -4.5, or -1.5 dB) for three metrics: throughput (first

row), delay (second row), and jitter (third row) under saturation.

The results for the configuration cases which included the Continuous ACK mechanism were again omitted

as this mechanism did not introduce any improvement in the network performance for the two-path

scenario. Enabling the NACK mechanism provides significantly worse results (Figure 5.10). The stop-and-

0%

20%

40%

60%

80%

100%

120%

140%

160%

-6.5 -4.5 -1.5

Thro

ugh

pu

t ch

ange

SNR [dB]


-60%

-50%

-40%

-30%

-20%

-10%

0%

-6.5 -4.5 -1.5

Del

ay c

han

ge

SNR [dB]


0

50

100

150

200

250

-6.5 -4.5 -1.5

Jitt

er c

han

ge [

ms]

SNR [dB]


0

0,1

0,2

0,3

0,4

0,5

0,6

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

1,8

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

500

1000

1500

2000

2500

3000

3500

4000

4500

1 2 3 4 5 6 7 8 9 10

De

lay

[ms]

Additional hops


0

500

1000

1500

2000

2500

3000

3500

1 2 3 4 5 6 7 8 9 10

Del

ay [

ms]

Additional hops


0

500

1000

1500

2000

2500

3000

1 2 3 4 5 6 7 8 9 10

De

lay

[ms]

Additional hops


0

20

40

60

80

100

120

140

160

1 2 3 4 5 6 7 8 9 10

Jitt

er

[ms]

Additional hops


0

10

20

30

40

50

60

70

80

90

1 2 3 4 5 6 7 8 9 10

Jitt

er

[ms]

Additional hops


0

2

4

6

8

10

12

14

16

18

20

1 2 3 4 5 6 7 8 9 10

Jitt

er

[ms]

Additional hops



Page 57 (79)

wait baseline outperforms the e2e ARQ protocol in this case for all three metrics: throughput, delay, and

jitter.

Figure 5.10: Performance results of the NACK end-to-end ARQ configuration in the two-path


jitter (right) under saturation.

The BlockACK mechanisms provides only limited improvements in comparison with the baseline (Figure

5.11). In terms of throughput, a large SW size is required and the path length contain at least 2-3 additional

hops for this mechanism to prove useful. However, using BlockACK in the two-path topology increases

both delay and jitter.

Figure 5.11: Performance results of the BlockACK end-to-end ARQ configuration in the two-path



The BlockNACK mechanism provides further improvements (Figure 5.12). In almost all cases the

throughput is improved in comparison with the baseline with the SW=2 configuration closely following the

stop-and-wait results. Similarly, the delay is also improved. However, as in previous cases, jitter is

increased by the selective repeat mechanism used in the e2e ARQ protocol.

Figure 5.12: Performance results of the BlockNACK end-to-end ARQ configuration in the two-path



Figure 5.13 provides a comparison of the performance of the various mechanisms in the two-path topology.

It reveals the following conclusions:

as in previously studies topologies, the continuous ACK mechanism does not bring any

improvements,

the NACK mechanism performs much worse than other mechanisms,

the highest throughput and lowest delays are achieved by the e2e ARQ protocol in the basic

configuration,

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

1000

2000

3000

4000

5000

6000

7000

8000

1 2 3 4 5 6 7 8 9 10

De

lay

[ms]

Additional hops


0

100

200

300

400

500

600

700

1 2 3 4 5 6 7 8 9 10

Jitt

er

[ms]

Additional hops


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

1000

2000

3000

4000

5000

6000

7000

8000

1 2 3 4 5 6 7 8 9 10

De

lay

[ms]

Additional hops


0

100

200

300

400

500

600

700

1 2 3 4 5 6 7 8 9 10Ji

tte

r [m

s]Additional hops


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops


0

500

1000

1500

2000

2500

3000

3500

1 2 3 4 5 6 7 8 9 10

De

lay

[ms]

Additional hops


0

10

20

30

40

50

60

1 2 3 4 5 6 7 8 9 10

Jitt

er

[ms]

Additional hops



Page 58 (79)

enabling blockNACK can slightly reduce jitter.

Figure 5.13: Comparison of end-to-end ARQ performance mechanisms for three metrics

(throughput, delay, and jitter) in the two-path topology for links with SNR equal to -4.5 dB and for

a constant send window size (SW=16), under saturation.

Furthermore, if the obtained results are compared with the baseline for various SNR values (Figure 5.14),

it becomes evident that the additional complexity of the e2e ARQ protocol is most beneficial in networks

with links of higher quality (SNR = -1.5 dB). If the link quality is even lower, the best performance is

achieved with the basic or the blockNACK configurations.

Figure 5.14: Comparison of end-to-end ARQ performance with baseline in the two-path topology for

three metrics (throughput, delay, and jitter) for a constant send window size (SW=16) and constant

number of additional hops (N=8) and varying SNR values, under saturation.

Surprisingly for all the considered scenarios, the continuous ACK mechanism (ContACK) in all possible

combinations (NACK+ContACK, BlockACK+ContACK, and BlockNACK+ContACK) did not improve

the overall network performance. The authors think that this mechanism can behave much better for larger

networks composed of tens of nodes and when there are larger propagation delays between relays. The

analysis of such scenarios is left for future studies.

In summary, the simulation analysis of end-to-end ARQ has provided the following conclusions:

using a complex end-to-end ARQ protocol can significantly improve RESCUE network

performance in terms of increasing throughput and decreasing delay, especially for longer

transmission paths;

the best consistent performance improvements were provided by e2e ARQ in its basic and

blockNACK configurations and these mechanisms should be the focus of future study;

scenarios in which the continuousACK mechanism can provide impact have yet to be determined;

the other proposed configurations have not proven to be as useful and can therefore be omitted

from future study.

5.2 Partial ARQ

Lossy forwarding technique is effective in reducing the end-to-end latency and increasing the throughput

of multi-hop multi-relay systems, where erroneously decoded frames at the relay node can be forwarded by

re-interleaving and re-encoding them in such a way that the destination node can exploit the correlation of

the information parts of the frames received via all links. In fact, the correlation exists because the frames

are generated from the same source. Multiple copies of correlated frames are received not only from parallel

paths but also from retransmitted frames following an ARQ protocol. Every time a frame is retransmitted,

the receiving node will increase the amount of information. Hence, by accumulating sufficient information,

the node will be able to decode the message. In this case, ARQ technique, based on frame combining with

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1 2 3 4 5 6 7 8 9 10

Thro

ugh

pu

t [M

b/s

]

Additional hops

basic/contACK NACK/NACK+contACK blockACK

contACK+blockACK blockNACK contACK+blockNACK

0

1000

2000

3000

4000

5000

6000

1 2 3 4 5 6 7 8 9 10

Del

ay [

ms]

Additional hops

basic/contACK NACK/NACK+contACK/blockACK

contACK+blockACK blockNACK/contACK+blockNACK

0

100

200

300

400

500

600

700

1 2 3 4 5 6 7 8 9 10

Jitt

er [

ms]

Additional hops

basic/contACK NACK/NACK+contACK/blockACK

contACK+blockACK blockNACK/contACK+blockNACK

-100%

-50%

0%

50%

100%

150%

200%

250%

-6.5 -4.5 -1.5

Thro

ugh

pu

t ch

ange

SNR [dB]

Basic NACK contACK NACK+contACK

BlockACK contACK+blockACK BlockNACK contACK+blockNACK

-100%

-50%

0%

50%

100%

150%

-6.5 -4.5 -1.5

De

lay

chan

ge

SNR [dB]



-

100

200

300

400

500

600

700

800

900

-6.5 -4.5 -1.5

Jitt

er

chan

ge [

ms]

SNR [dB]




Page 59 (79)

FEC in a Hybrid-ARQ (HARQ) scheme, can achieve not only coding gain but also the time diversity

through retransmissions, as well as the spatial diversity through the relays which retransmit the source

information.

Forwarding frames having large distortions with e2e protocol may invoke continuously retransmission

request to the source node, resulting in reduced end-to-end throughput. Moreover, the capability of

correcting errors in a parallel network systems at the destination node is made possible regardless the

qualities of each path, so far as there is at least one connection where errors are not introduced in the relay

before re-encoding. Therefore, P-HARQ introduces a confidence indicator (𝐶𝐼) as a threshold by which a

relay node decides either forwarding the erroneous frame or requesting retransmission. In contrast with

CRC, 𝐶𝐼 has capability of identifying the reliability of the entire frame. Furthermore, the 𝐶𝐼 calculation is

beneficial since the receiving nodes do not need to know the original information sequence. It is given by

𝐶𝐼 = 1 −1

𝑁∑ 𝐻𝑏(

1

1+𝑒−|𝐿𝑝|)𝑁𝑛=1 ,

where 𝐻𝑏 and 𝐿𝑝 denote binary entropy function and the a posteriori log-likelihood ratio (LLR) of channel

decoder, respectively. The probability of error corresponding to the 𝐶𝐼 value can be calculated by

𝑃𝑏 ≈1

2𝑒𝑟𝑓𝑐(

𝐽−1(𝐶𝐼)

2√2 ),

where 𝐽−1(∙) is the inverse of function 𝐽(∙). For BPSK, 𝐽−1(𝐶𝐼) can be approximated by

𝐽−1(𝐶𝐼) = −1

𝐻1𝑙𝑜𝑔2(1 − 𝐶𝐼

1

𝐻3)1

2𝐻2 , 𝐻1 = 0.3073, 𝐻2 = 0.8935, 𝐻3 = 1.1064.

5.2.1 Protocol overview and design update

P-HARQ with the stop-and-wait protocol works for a two-hop multi-relay network, which corresponds to

TS2. The simulation results are shown in Section 5.2.4. The proposed algorithm is given as follows. At the

very beginning of each HARQ rounds for multiple information sequence to be transmitted, the frame from

the source node is forwarded to the destination node through the relay(s) even though it still contains errors.

It is due to the 𝐶𝐼 threshold not set yet. Each time receiving frame, the receiving nodes calculate its 𝐶𝐼 by

equation given in the previous sub-section.

The receiving nodes send NACK to their previous node to indicate unsuccessful decoding, and hence

requesting retransmission. There are two types of NACK in P-HARQ: NACK_1 indicating a retransmission

required from the node in one-hop back, and NACK_2 indicating retransmission required from the node in

two-hop back. Therefore, if a transmitting node receives NACK_1, it will retransmit the frame to the next

node. On the other hand, if a transmitting node receives NACK_2, it will transmit NACK_1 to the previous

node.

The destination node evaluate 𝐶𝐼 values of frames transmitted from all paths, before frame combining. The

destination node transmits NACK_1 whenever the frames transmitted for the first time (not retransmitted

version) by the relay are unsuccessfully recovered. This is to avoid the excessive end-to-end latency. In this

case, the 𝐶𝐼 is used as the threshold. Additionally, the destination node transmit NACK_2 whenever the

have-retransmitted frames are unsuccessfully recovered. In this case, the destination node uses the 𝐶𝐼 value,

which are larger than the previous 𝐶𝐼 as the threshold. As for the relay node, the threshold is set equal to

𝐶𝐼 of the very beginning of the HARQ rounds and update it whenever receiving NACK_2. The more details

of the algorithm is given in the table below.


Page 60 (79)

5.2.2 Simulation Setup

We consider a TS2 topology where a source node 𝑆𝑁 aims to transmit information sequence to a destination

node 𝐷𝑁 through two relay nodes 𝑅𝑁1 and 𝑅𝑁2 that are located physically separate in parallel links. There

are three time slots in one transmission cycle. In the first time slot, the node 𝑆𝑁 broadcasts its coded

sequences 𝒙𝑆 to the node 𝑅𝑁1 and 𝑅𝑁2. The rest time slots, both relays transmit their coded

sequence 𝑥𝑅𝑁𝑙, 𝑙 ∈ {1, 2} to the destination 𝐷𝑁, sequentially.

We consider a static channel within one block but varying link-by-link as well as transmission-by-

transmission during HARQ rounds. We use the terminologies transmitting nodes and receiving nodes for


Page 61 (79)

referring to the source node and the relay nodes on transmit phase, and relay nodes and destination node on

receive phase, respectively.

5.2.2.1 Transmit Phase

Figure 5.15: Block diagram of the source and the relay node. Both relays in TS2 have the same

structure.

Figure 5.15 depicts the transmitter structure of the source node and the relay node 𝑅𝑁1. The structure of

𝑅𝑁2 is similar to 𝑅𝑁1. With 𝑚 (re)transmissions, 𝑚 ∈ {1, 2, . . . , 𝑀}, where the maximum number of

retransmissions is 𝑀 − 1, the binary information sequence 𝑢𝑚 is first encoded by the channel encoder 𝐶𝑚.

For the retransmit phases, at relay node, 𝑢𝑚 is first random-interleaved by inner interleaver Π0,𝑚+1 before

encoding. It should be noticed that the use of the different interleaver for each round of transmission by the

relays converts the system into a distributed Turbo Code. The relay node discards the old packet whenever

receiving a new packet. Combining the packets at the relay node should further improve the performance,

but it is out of the scope of this study for the sake of simplicity. The same process is performed at the other

relay of the first transmission. The encoded bit sequence is then randomly interleaved by the outer

interleaver Π1,𝑚 followed by doped-accumulator 𝐷𝐴𝑚 with doping ratio 𝜌 = 𝜌𝑚. The outer interleaver

enables extrinsic LLR exchanging of systematic bits via vertical iteration at the receiver side, likewise, the

inner interleaver plays important function of extrinsic LLR exchanging via horizontal iteration. The doped-

accumulated bits are mapped in the Map box in Figure 5.15 to constellation points for modulation. In this

paper, we use binary phase shift keying (BPSK), which follows the mapping rule 0 → −1, 1 → +1, and

then transmitted over frequency flat block Rayleigh fading channel with the complex channel gain ℎ𝑞, 𝑞 ∈ {𝑆𝑁 − 𝑅𝑁1, 𝑆𝑁 − 𝑅𝑁2, 𝑅𝑁1 − 𝐷𝑁, 𝑅𝑁2 − 𝐷𝑁}. The transmitter transmits the modulated signal having N

symbols, as

𝒙𝑖𝑚 = [𝒙𝑖

𝑚(1), 𝒙𝑖𝑚(2), … , 𝒙𝑖

𝑚(𝑁)]𝑇 , 𝑖 ∈ {𝑆𝑁, 𝑅𝑁1, 𝑅𝑁2}

5.2.2.2 Receive Phase

The received signal of the transmitted packet can be formulated as

𝒚𝑗𝑚 = ℎ𝑖𝑗𝒙𝑖

𝑚 + 𝝊𝑗𝑚 , 𝑗 ∈ {𝑅𝑁1, 𝑅𝑁2, 𝐷𝑁},

Where 𝝊 is a zero mean complex additive white Gaussian noise (AWGN) vector with variance 𝜎2 (double

sided). The average signal-to-noise power ratio (SNR) is ⟨|ℎ𝑖𝑗|2

⟩ 𝜎2⁄ since 𝐸[𝒙𝑖𝑚] = 1. The conditional

log-likelihood ratios (LLRs) based on the probability that the receiver’s matched filter output 𝑦𝑗𝑚(𝑛) for

the 𝑛-th bit in 𝒙𝑖𝑚 is defined as

𝐿 (𝑦𝑗𝑚(𝑛)|ℎ𝑖𝑗 , 𝑥𝑖

𝑚(𝑛)) = 𝑙𝑛Pr (𝑦𝑗

𝑚(𝑛)|ℎ𝑖𝑗 , 𝑥𝑖𝑚(𝑛) = +1)

Pr (𝑦𝑗𝑚(𝑛)|ℎ𝑖𝑗 , 𝑥𝑖

𝑚(𝑛) = −1),

where 𝑛 = {0,1,2, … , 𝑁}. Hence, with Pr (𝑦𝑗𝑚(𝑛)|ℎ𝑖𝑗 , 𝑥𝑖

𝑚(𝑛)) =1

√𝜋𝜎2exp [−

|𝒚𝑗𝑚(𝑛)−ℎ𝑖𝑗𝒙𝑖

𝑚|2

𝜎2 ], it is

straightforward to calculate the soft output of the channel 𝑳𝑐, for BPSK over a block fading AWGN channel

as

𝑳𝑐,𝑗(𝑛) =4

𝜎2 ℜ(ℎ𝑖𝑗∗ ∙ 𝒚𝑖

𝑚(𝑛)), (1)

where ℜ(∙) is the real value of its argument.


Page 62 (79)

Figure 5.16: Block diagram of the destination node.

Figure 5.16 depicts the structure of the destination node. The block diagram only shows the structure of

receiving the packet from the same relay node. However, a similar structure also can be used for decoding

the packets coming from the other relay. The combiner Σ combines all the extrinsic LLRs, being the output

of channel decoder of each HARQ round. The soft output vector of the channel 𝑳𝑐𝑚 , the LLRs obtained by

(1), is first input to the demapper 𝐷𝑒𝑀 followed by 𝐷𝐴𝑚 decoder (𝐷𝐷𝐴𝑚), and its output extrinsic LLR is

forwarded to the inner-deinterleaver prior to the channel decoder 𝐷𝑚. The subtraction of a priori LLR 𝑳𝑎

from a posteriori LLR 𝑳𝑝 is not shown in the figure for the sake of simplicity. The CI of the received packet

is then calculated, which is equivalent to the mutual information between the a posteriori LLR and the

uncoded systematic bits. If the value of the CI is lower than the predetermined threshold, the extrinsic LLRs

obtained as the output of 𝐷𝑚 are exchanged via horizontal iteration (HI) between the 𝐷𝑒𝑀 + 𝐷𝐷𝐴𝑚and 𝐷𝑚.

The threshold is set adaptively while determining the threshold value of the a posteriori LLR. The

incorrectly decoded packet is stored in order to first update it to reflect the correlation knowledge and then

to combine with the retransmitted packet(s) in the following time slots.

When the retransmitted packet is received, the HI is performed independently, as in the first transmission,

and then the obtained extrinsic LLRs of the systematic information bits, 𝑳𝑒𝑢,𝑚

, are propagated crosswise

between the soft-input soft-output (SISO) channel decoders; this process is referred to as vertical iteration

(VI). VI can be seen as an iterative decoding process of parallel concatenated code. 𝑳𝑒𝑢,𝑚

is updated by the

function 𝑓𝑐 defined by (2). The function 𝑓𝑐 is utilized to help the decoder eliminate the errors in the packets

received by the relays, by exploiting the correlation knowledge between the relays. The correlation value

is indicated by the error probability 𝑝𝑒, block-by-block, which can be estimated by using a pair of a

posteriori LLRs, 𝑳𝑝,𝐷ℐ𝑢 and 𝑳𝑝,𝐷𝒥

𝑢 , ℐ ≠ 𝒥, the uncoded (systematic) bits output

from the decoders 𝐷ℐ and 𝐷𝒥, respectively, as

�̂�𝑒 =1

𝐾∑

exp(𝑳𝑝,𝐷ℐ𝑢 ) + exp (𝑳𝑝,𝐷𝒥

𝑢 )

(1 + 𝑳𝑝,𝐷ℐ

𝑢 ) (1 + 𝑳𝑝,𝐷𝒥

𝑢 ),

𝐾

𝑘=1

where 𝐾 denotes the number of the a posteriori LLR pairs obtained by the decoders for the packets

transmitted from 𝑅𝑁1 and 𝑅𝑁2, with sufficient reliability. The updated extrinsic LLR of 𝑳𝑝,𝐷ℐ𝑢 can then be

obtained by

𝑳𝑝,𝐷ℐ ,𝑢𝑝𝑑𝑎𝑡𝑒𝑑𝑢 = 𝑓𝑐(�̃�𝑝,𝐷ℐ

𝑢 , �̂�𝑒) = 𝑙𝑛(1−𝑝𝑒)∙exp(�̃�𝑝,𝐷ℐ

𝑢 )+𝑝𝑒

(1−𝑝𝑒)+exp(�̃�𝑝,𝐷ℐ𝑢 )∙𝑝𝑒

, (2)

where �̃�𝑝,𝐷ℐ𝑢 = 𝑳𝑝,𝐷ℐ

𝑢 for the first transmission, and �̃�𝑝,𝐷ℐ𝑢 = Π0,𝑚

−1 (𝑳𝑝,𝐷ℐ𝑢 )for the retransmissions. The a priori

LLR 𝑳𝑎𝑢,𝑚

is then

𝑳𝑎𝑢,𝑚 = ∑ 𝑳𝑝,𝐷ℐ ,𝑢𝑝𝑑𝑎𝑡𝑒𝑑

𝑢

𝑞∈𝜔\𝑚

,

with 𝜔 = {1, 2, . . . , 𝑀} being the set of retransmission number. Finally, by performing sufficient rounds

of iterative HI-VI-HI-VI decoding processes, the final hard decisions, �̂�𝑚 is made on the a posteriori LLR

originated by summing up all the deinterleaved and 𝑓𝑐-updated versions of the a posteriori LLR 𝑳𝑝,𝐷𝑚

𝑢,𝑚.


Page 63 (79)

5.2.3 Simulation Results

We evaluate BER, PER and e2e throughput performance by simulations that consider the transmission of

100,000 packets with 1,000 bytes per packet. The maximum number of retransmissions per node is set to 4

(M = 5). For fair comparison, we set the same total number of retransmission for all evaluated systems with

each SNR. All nodes use the same channel coding, where a half-rate non-systematic non-recursive

convolutional coding (NSNRCC) with a generator polynomial G = [7, 5] is considered. They all also use

the same varying doping ratio ρ (re)transmission-by-(re)transmission, where ρ ∈ {2, 10, 15, 20, 25}.

We assume no delay constraints for the overall transmission of information from the source to the

destination nodes, and hence the relay nodes can decode the packet before they forward. We also assume

an ideal medium access control protocol, where each node can transmit and receive a packet independently.

Each node is allowed to transmit and receive only one packet simultaneously, and every packet transmitted

from nodes is received without collisions.

We compare P-HARQ with the SHARQ [13] as the conventional scheme. In the conventional scheme, the

relay nodes forward only error free packets and the retransmissions occur either between the source node

and the relay nodes or between the relay nodes and the destination node. As stated previously, we perform

no packet combining at the relay nodes for all the schemes.

Figures 5.17-5.18 show that P-HARQ outperforms the conventional scheme in terms of BER and PER

performances, respectively. Figure 5.19 shows that the conventional scheme fails in combining all

transmitted packets to achieve a large diversity gain while it can be achieved by P-HARQ. This is because

P-HARQ is able to carefully combine the most reliable packets by employing the CI. P-HARQ has 6.2 dB

degradation from Maximal Ratio Combining (MRC) because the relay nodes forward even erroneous

packet to the destination while MRC assumes no error at the relay nodes.

Figure 5.17: BER performance.


Page 64 (79)

Figure 5.18: PER performance.

The throughput is defined as the ratio of the average number of successfully recovered packets at the

destination node per time slot to the total number of transmitted packets per time slot. We normalized the

throughput over two time slots, which means that the throughput of one is achieved whenever the packet is

successfully recovered within two time slots. Hence, the packet loss rate can be calculated as 𝑃𝑙𝑜𝑠𝑠 = 1 − 𝑇, with 𝑇 being the throughput of the system. Figure 5.19 shows that for the same ratio of end-to-end

packet loss, the BER performance of the proposed P-HARQ is lowest then the conventional scheme. For

the example, the 60% of end-to-end packet loss corresponds to BER of 0.0026 for P-HARQ.

Figure 5.19: Corresponding BER of throughput performances.


Page 65 (79)

6. Multirate

Comparing to the proposal presented in D3.1 the data rate selection (multirate) algorithm for the CSMA/CA

RESCUE network had to be redesigned4. Similarly to the initial design, the network under study uses

transmission of a broadcast type which means that transmitted frames can be received and processed by all

stations within the radio coverage. The process of frame retransmission is controlled by the partial ARQ

mechanism which keeps the number of retransmitted frames at a minimal level. The proposed design

assumes that every network node uses only single input single output (SISO) radio transceivers. The data

rate selection algorithm works in cooperation with the routing protocol, however, the requirements on

providing the list of relaying stations for each connection can be relaxed due to the distributed procedure

of the best relay selection. Nonetheless, as in the initial design no information concerning position of the

relays is given to the source station. For each network station, the data rate selection algorithm decision

variable was changed from slowly converged FER to the SNR value. The behaviour of the source and relay

stations has been differentiated. For the relaying stations distributed elements such as selection of the best

relay station have been added.

The design and evaluation of the data rate selection algorithm assumed a mobile station supporting two

data transmission modes abbreviated as Ofdm12Mbps and Ofdm36Mbps. The parameters of the

transmission modes used during the experiments are listed in Table 6.1. Both transmission modes were

chosen to facilitate a comparison between the RESCUE solution with existing IEEE 802.11a/g networks.

Table 6.1 Transmission modes used in evaluation of the data rate selection algorithm

Transmission mode name Ofdm12Mbit/s Ofdm36Mbit/s

Data throughput Mbit/s 12 36

Transmission technique OFDM OFDM

Subcarrier modulation QPSK 16 QAM

Convolution code rate 1/2 3/4

Transmission bandwidth [MHz] 20 20

All the simulation experiments presented in this chapter were conducted using the ns-3 network simulator.

Each of the simulated network stations was equipped with an error model based on the RESCUE Black

Box implemented in the ns-3 simulator. The position of network stations was assumed to be fixed during

all experiments, which means that the nomadic mobility model was used. The propagation model reflecting

the used mobility pattern consisted of a large scale fading model based on log-distance propagation loss

model with an exponential damping factor of 3.5 and a small scale fading based on Jakes frequency

spreading function. Since a transmission frequency band of 2.4 GHz was assumed the maximum Doppler

frequency shift was set to 4 Hz [7]5.

The goal of the first experiment was to evaluate the performance of a RESCUE station in a point-to-point

scenario. A network consisting of two stations operating with a fixed data rate was used. For each of the

mean SNR values the simulation experiment covered 105 seconds of network operation, the first five of

which were treated as a warm up period. The results of the evaluation of the system performance in the

point-to-point scenario with a zero collision probability are presented in Figure 6.1. According to them, the

SNR threshold for switching between transmission modes for a point-to-point link should be set to 11.9 dB.

This guarantees the highest data throughput and the lowest end-to-end delay value.

4 The final design is presented after the simulation results as it is a direct consequence of the performed analysis.

5 Had the 5 GHz band been used the change would not be significant. What would change is the spatial scaling of the

model and the width of the Doppler spectrum. However, this would not have an qualitative impact on the simulation

results.


Page 66 (79)

(a)

(b)

Figure 6.1: Performance of the RESCUE station in a point-to-point scenario: (a) throughput and (b)

end-to-end delay as a function of SNR between S and D.

The goal of the subsequent experiment conducted in the point-to-point setup was to determine the influence

of the transmission mode used for transmitting control frames on network performance. The experiment

was performed for an SNR value of 15 dB and data frames sent at a fixed data rate of 36 Mb/s. In the first

experiment control frames were transmitted with a fixed data rate of 12 Mb/s while in the second

experiment the 36 Mb/s data rate was used. The difference in the end-to-end data throughput values for

both experiments were within the statistical error bound. As a conclusion from the experiment the

Ofdm12Mbps transmission mode was selected to be the transmission mode used for transmitting control

frames. This should improve the reliability of control information transfer without significant impact on the

performance of the network throughput.

The purpose of the next experiment was to evaluate the performance of a RESCUE network operating in

the TS1 scenario. The network configuration consisted of three fixed stations: source (S), relay (R) and

destination (D). The relay station was placed on the straight line between S and D close to the optimal

location (i.e., on 0.48 of the distance between S and D [5]). In the subsequent experiments the distance

between S and D was increased while maintaining the S-R-D geometry. Each of the simulation experiments

lasted 105 seconds of the network operation, the first five of which were treated as a warm up period.

-5 0 5 10 15 20 25

0

2

4

6

8

10

12

SNR between source and destination [dB]

Thro

ugh

pu

t [M

bit

/s]

Ofdm12Mbps

0

50

100

150

200

250

-10 -5 0 5 10 15 20 25

End

-to

-en

d d

ela

y [m

s]


Ofdm12Mbps

Ofdm36Mbps


Page 67 (79)

(a)

(b)

Figure 6.2: Performance of the RESCUE network for TS1: (a) throughput and (b) end-to-end delay

as a function of SNR between S and D

The results presented in Figure 6.2 show that even in the case of direct visibility between S and D a station

can still benefit from using RESCUE coding. However, the increase in datarate is gained at the expense of

increased end-to-end delay. Additionally, the RESCUE gain increases with the desrease of the SNR

between S and D. The results of the experiment presented in Figure 6.2 represent the upper bound of the

gain provided by using the RESCUE scheme in a CSMA/CA network for TS1.

For the experiment presented next, the data rate selection strategy for the S station in TS1 was examined.

The spatial configuration of the network was chosen in order to maximize the gain provided by the

RESCUE coding. According to this rule the network was configured so that the SNR value between S and

D was set to -5 dB. The position of the R station was changed in subsequent runs of the experiment in the

area where the R station remained within the radio coverage of both S and D stations while the average

SNR between the S and R stations always exceeded the threshold of 11.9 dB. Two different data rate

selection strategies were examined. The S station selected its data rate according to the SNR value between

the S and D stations (red curve in Figure 6.3) or according to the SNR value between the S and R stations

(blue curve in Figure 6.3).

-10 -5 0 5 10 15 20 25

0

2

4

6

8

10

12


Thro

ugh

pu

t [M

bit

/s]

Max throughput withoutRescueMax throughput TS1

0

100

200

300

400

500

600

700

-10 -5 0 5 10 15 20 25

End

-to

-en

d d

ela

y [m

s]


delay TS1

delay without Rescue


Page 68 (79)

(a)

(b)

(c)

Figure 6.3: Cumulative distribution functions of (a) end-to-end throughput, (b) end-to-end delay, and

(c) end-to-end jitter for two different data rate selection strategies in TS1.

Figure 6.3 presents a cumulative distribution function of the end-to-end data throughut, delay and jitter as

a funtion of the varying position of station R. Examining the results presented in Figure 6.3 the preffered

strategy is to adjust the datarate according to the SNR value between S and D even in the presence of relays.

The next experiment evaluates the performance of a multi-rate CSMA/CA RESCUE network for TS2,

which assumes no direct link between S and D and the presence of two relay stations (R1, R2). Additionally

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.5 1 1.5 2

Pro

bab

ility

End-to-end throughput [Mb/s]

relay oriented

destination oriented

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 200 400 600 800 1000 1200

Pro

bab

ility

End-to-end delay [ms]

relay oriented


0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 5 10 15 20

Pro

bab

ility

End-to-end jitter [ms]


relay oriented


Page 69 (79)

the end-to-end communication is possible only when using the information provided by both relay stations,

meaning that one or both of the tandem links S-R1-D and S-R2-D are lossy. No information concerning the

position of the R stations is given to the S station.

Two basic strategies of data rate selection at the S station were examined. The goal of the first strategy was

to set the data rate at S according to the minimum value of the SNRs measured between S and the relay

stations (the weakest relay strategy). The second strategy was based on the higest value of the SNR

measured between S and the relaying stations (the strongest relay strategy).

In order to evaluate the performance of both aforementioned strategies series of experiments were

performed for TS2, consisting of S and D stations without a direct link and two relay stations forming two

lossy tandem links. The position of the relay stations was changed in subsequent runs of the experiment.

Each experiment was run for 105 seconds with 5 seconds of warm up. A thousand different relay positions

were examined and as a result a cumulative distribution of data rates achieved for both strategies was

obtained. The experiment results are presented in Figure 6.4.

Figure 6.4: Cumulative distribution functions of two data rate selection strategies for the TS2

scenario.

Analysing the CDF presented in Figure 6.4 one can observe that both strategies exhibit almost the same

probability of end-to-end transmission failure. For the majority of network configurations the data rate

selection strategy oriented on the SNR measured for the R station with a stronger signal offers higher data

throughput values.

In a configuration with more than two relays both presented data rate selection strategies may lead to a

suboptimal solution due to the lack of information of the RX-D SNR, which means that the capacity of the

S-RX-D tandem link is unknown. In the CSMA/CA network each station has an equal transmission

probability, which means that, in the case of the examined network links with a low SNR value, operating

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 0.5 1 1.5 2 2.5 3

Pro

bab

ility

End-to-end throughput [Mbps]

weakest relay

strongest relay

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

200 400 600 800 1000

Pro

bab

ility


weakest relay

strongest relay


Page 70 (79)

with lower data rates consumes three times more time than links with SNR above 11.9 dB. As a result, a

wrongly placed R station can decrease the performance of the whole network. Additionally, it is worth

mentioning that the gain provided by the RESCUE coding decreases with an increasing number of

combined frames. As an example, the dependency of the RESCUE gain with the number of combined

frames received with similar SNR values is presented in Figure 6.5.

Figure 6.5: RESCUE coding gain as a function of the number of combined frames

The remedy for both phenomenas is to increase the transmission probability for the relays with a higher

tandem S-R-D link quality in favour of badly placed relay stations. In CSMA/CA networks the medium

access probability can be varied by changing the contention window (CW) value. Since complete

information (SNRSR and SNRRD) about the quality of the S-R-D tandem link is available only at the relay

stations it is reasonable to set the probality of the chanel access in a distributed way.

In the proposed algorithm the S-R-D link capacity will be used as a cost function. Since only simple

retransmission is performed at the relaying station the SNR in the whole tandem link can be estimated as:

𝑆𝑁𝑅𝑆𝑅𝐷 =1

𝑆𝑁𝑅𝑆𝑅−1 + 𝑆𝑁𝑅𝑅𝐷

−1 (6.1)

where 𝑆𝑁𝑅𝑆𝑅 is the signal to noise ratio for the S-R link and 𝑆𝑁𝑅𝑅𝐷 is the signal to noise ratio for the R-D

link

The capacity of a tandem S-R-D link as a function of the mean SNR value was determined by simulation.

The experiment was performed for a number of tandem links with a variable position of the R station. Each

subsequent simulation experiment covered 105 seconds of network operation, the first five of which were

treated as a warm up period. The resulting tandem link capacity is presented in Figure 6.6 as a function of

the average SNRSRD.

Figure 6.6: Capacity of a tandem link as a function of the average 𝑺𝑵𝑹𝑺𝑹𝑫

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

0 2 4 6 8 10

RES

CU

E co

din

g ga

in [

dB

]

Number of combined frames

-5 0 5 10 15 20

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

Average SNR of a tandem link [dB]

End

-to

-en

d t

hro

ugh

pu

t [M

bit

/s]

Throughput of S-R-D link

1.19+0.28*SNR1.19+0.28×SNR


Page 71 (79)

The capacity of a tandem link for a CSMA/CA RESCUE network can be estimated as:

𝑐𝑎𝑝 = 1.19 + 0.28 𝑆𝑁𝑅𝑆𝑅𝐷. (6.2)

Based on the simulation results the maximum data throughput achieved by a tandem link is determined to

be approximately 𝑅0 = 4 Mb/s. The goal of the proposed algorithm is to give the same time share instead

of the same probability of accessing the wireless channel for each of the relays. The relays capable of

achieving throughput close to 𝑅0 should be given a transmission probability equal to the probability

assigned to the source station (standard priority) other relaying stations will be given priorities according

to their transmission capabilities.

In case of a tandem link with a high SNRSRD value the transmission time of an 𝑛-bit long frame is

𝑇0 =𝑛𝑏𝑖𝑡𝑠

𝑅0

(6.3)

For a particular capacity (cap) of a tandem link the transmission time of an 𝑛-bit long frame can be

calculated as follows:

𝑇𝑐𝑎𝑝 =𝑛𝑏𝑖𝑡𝑠

𝑐𝑎𝑝=

𝑛𝑏𝑖𝑡𝑠

𝑅0

∙𝑅0

𝑐𝑎𝑝= 𝑇0 ∙

𝑅0

𝑐𝑎𝑝 (6.4)

In order to give the same time share for all the relaying stations the following term should apply:

𝑇0𝑝0 = 𝑇𝑐𝑎𝑝𝑝𝑐𝑎𝑝, (6.5)

where 𝑝0 is the reference transmission probability and 𝑝𝑐𝑎𝑝 is the probability of accessing the wireless

channel for a tandem link with capacity cap.

If for the sake of simplicity a zero frame collision probability is assumed, then the dependency of the

medium access probability and the value of the contention window 𝐶𝑊𝑖 can be expressed as [6]:

𝑝𝑖 =2

𝐶𝑊𝑖 + 1 (6.6)

Assuming that a perfectly placed relay is given a transmission priority equal to the priority possessed by a

regular source station the reference transmission probability can be expressed as:

𝑝0 =2

𝐶𝑊0 + 1 (6.7)

and based on (6.5):

𝑝0 =𝑅0

𝑐𝑎𝑝𝑝𝑐𝑎𝑝 =

𝑅0

𝑐𝑎𝑝

2

𝐶𝑊𝑐𝑎𝑝 + 1 (6.8)

after substituting (6.8) to (6.7): 𝑅0(𝐶𝑊0 + 1)

𝑐𝑎𝑝− 1 = 𝐶𝑊𝑐𝑎𝑝 (6.9)

finally combining (6.9) with (6.2) gives: 𝑅0(𝐶𝑊0 + 1)

1.19 + 0.28 𝑆𝑁𝑅𝑆𝑅𝐷

− 1 = 𝐶𝑊𝑐𝑎𝑝 (6.10)

The differentiation of the channel access probability for the relaying stations enables another data rate

selection strategy for the source station. According to the new strategy the source station adapts its data rate

to the SNR value measured for the most frequently transmitting relay station.

The performance of the new data rate selection strategy was tested for two variants of the TS2 scenario.

The results achieved by the networks implementing the new data rate selection algorithm were compared

to those obtained for a network using the data rate selection strategy oriented on the SNR measured for a

relay station with the strongest signal. In the first experiment a minimalistic TS2 scenario with only two

relaying stations was examined. The positions of the relaying stations were changed in subsequent runs of

the experiment. For each of the network configurations 105 seconds of network operation was simulated

while the first 5 seconds were treated as a warp up period. Thousands of relay positions were examined and

as a result a cumulative distribution of data rates achieved for both strategies was calculated. The results

presented in Figure 6.7 show that the new strategy does not deteriorate the end-to-end network performance.

It is worth mentioning that for a minimalistic TS2 scenario both relaying stations must be involved in the

process of a frame transmission and in this case an incorrectly selected CW value could impact the network

performance. Since both relays take part in the frame forwarding procedure no improvements in comparison

to the strongest relay oriented data rate seletion strategy were expected for this scenario.


Page 72 (79)

(a)

(b)

Figure 6.7: Cumulative distribution functions of the (a) end-to-end throughput and (b) end-to-end

delay calculated for the TS2 scenario. Comparison of two strategies of data rate selection by the

source: strongest relay (highest measured SNR) or most frequently transmitting relay (assuming CW

control).

The second experiment evaluated the performance of the new relaying algorithm for an extended version

of the TS2 scenario with the number of potentially relaying stations increased to ten. The experiment was

conducted according to the same scenario as for the case of the minimalistic TS2 except for the simulation

time for each run, which was increased to 1005 seconds of network operation. The results of the experiment

are presented in Figure 6.8:

In case of the TS2 topology with an increased number of potentially relaying stations, the differentiation of

the medium access probability for the relaying stations leads in most cases to the increase of the end-to-end

throughput comparing to the strongest relay strategy. An additional benefit from using the distributed

selection strategy of the best relaying stations is increasing the reliability of frame delivery. The distributed

selection strategy of best relaying stations can also play a role in the simplification of the routing algorithm

which now can be freed from selecting the set of relaying stations for a particular connection.

0

0.2

0.4

0.6

0.8

1

0 0.5 1 1.5 2 2.5 3

Pro

bab

ility


most frequent +CW

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

200 400 600 800 1000

Pro

bab

ility


most frequent + CWstrongest relay


Page 73 (79)

(a)

(b)

Figure 6.8: Cumulative distribution functions of the (a) end-to-end throughput and (b) end-to-end

delay calculated for the TS2 scenario with more than two relays. Comparison of two strategies of

data rate selection by the source: strongest relay (highest measured SNR) or most frequently

transmitting relay (assuming CW control).

In conclusion, the final decision block diagram of the distributed data rate selection algorithm for RESCUE

CSMA/CA networks has been updated to reflect the lessons learned from the simulation results (Figure

6.9). The first step is to determine the stations role in the transmission of a given frame (source or relay).

In the former case, the S-D link quality is checked. If it exceeds the minimum (-5 dB) threshold, the data

rate is selected based on the results shown in Figure 6.1. Otherwise, data rate is determined based on the

SNR of the S-R link quality for the most frequently transmitting relay. In the case of the relay, the model

based on equations (6.1) and (6.10) is used to improve performance (airtime usage) and select the optimum

data rate.

Start of message processing

Check role

SNRSD<-5 dBNY

source

SNRSD>11.9 dB

relay

Y

Return Ofdm12Mbps

N

Return Ofdm36Mbps

Determine the SNRSR for the most

frequently transmitting relay

SNRSR>11.9 dB

Y

Return Ofdm12Mbps

N

Return Ofdm36Mbps

Calculate the SNRSRD for tandem

link (6.1)

Calculate new CW (6.10)

SNRRD>11.9 dB

Y

Return Ofdm12Mbps

N

Return Ofdm36Mbps

Figure 6.9: Diagram of the RESCUE data rate selection algorithm

0

0.2

0.4

0.6

0.8

1

0 0.2 0.4 0.6 0.8 1 1.2 1.4

Pro

bab

ility


most popular relay…

0

0.2

0.4

0.6

0.8

1

0 500 1000 1500 2000 2500

Pro

bab

ility


most popular relay + CW…


Page 74 (79)

7. Conclusion

In this deliverable, we have presented the design updates of the protocols previously defined in D3.1.

Furthermore, we have provided the simulation-based performance evaluation of these protocols, using

RESCUE’s unified NS3 platform which integrates an abstraction of the physical layer (an input from WP2),

various MAC mechanisms &protocols, Automatic Repeat reQuest (ARQ) or routing protocols in order to

properly access the concept of RECUE’s lossy forwarding which validate their usefulness in facilitating

RESCUE message transfer. The simulations, results and evaluations presented for the MAC protocols,

routing protocols, error control mechanisms and rate adaptation in this deliverable have all been produced

using key common parameter tables which are relevant to the verification of the RESCUE’s concepts in

lossy communication networks. This deliverable provided updates to the background on message transfer,

toy scenarios, and baselines for comparison. The full design details and simulation-based results which take

into consideration lossy wireless communication links to show functionalities proposed as benefits of

RESCUE project have also been presented for the following: (i) three complementary medium access

protocols for centralized and distributed networks, (ii) two complementary routing protocols (R-OLSR and

geo-routing protocols), (iii) two complementary error control methods for ensuring end-to-end reliability

and efficient retransmissions, and (iv) a multirate algorithm for providing improved performance by

adapting to channel conditions. More details on the forwarding threshold optimization for the considered

toy scenarios (TS1, TS2 and TS3) and the V2V scenario are presented in the appendix of this document.

The design details and simulation results provided in this deliverable will serve as a basis for the

implementation and performance analysis of each component to be reported D3.3 as well as the

implementation and validation of the integrated components to be performed in WP4.


Page 75 (79)

Appendix A. Forwarding Threshold Optimization

There are many parameters governing the behaviour of the RESCUE message transfer protocols which can

be subject to further optimization. One such parameter of interest is the forwarding threshold p which

represents the maximum allowable BER of a received message which is to be processed by the receiver

(i.e., passed to higher layers) as noted in Table 3.1. In the particular case of p=0, the resulting message

transfer system can be considered as being a selective decode and forward (SDF) approach. SDF is a

particular case of lossy forwarding (LF) where only correct packets are forwarded and joined decoding is

applied at the destination. While in general there are different SDF methods in the state of the art, in this

case we apply the RESCUE-developed joint decoding in SDF. Therefore, both approaches (LF and SDF,

for p=0.2 and p=0, respectively), which have been evaluated below, are contributions from the project.

Toy Scenarios

Simulation results of SimpleMAC for TS1-TS3 (Figures A.1 to A.3) show that in the basic RESCUE

topologies indeed the LF approach is better than SDF, especially in terms of throughput and end-to-end

delay in the range -3 to -6 dB of SNR. The forwarding of erroneous frames in LF together with the joint

decoding at the decoder can provide an increase in throughput, in comparison to SDF, of up to 84%.

However, this may not always be the case, as can be seen in the next analysed scenario.

Figure A.1: Throughput, end-to-end delay, jitter, and frame loss ratio for TS1 for two forwarding

thresholds. The link between the R and D stations is lossless, while the S-R and S-D links are lossy

and their SNR is the variable. For other lossy/lossless link configurations the performance of the two

forwarding thresholds was similar.

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]

p = 0 p = 0.2

0

200

400

600

800

1000

1200

1400

1600

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]

p = 0 p = 0.2

0

100

200

300

400

500

600

700

800

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]

p = 0 p = 0.2

0

20

40

60

80

100

120

-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%

]

SNR [dB]

p = 0 p = 0.2


Page 76 (79)


thresholds. The S-R2 and R1-D links are lossless, while the other two links are lossy and their SNR

is the variable. For other lossy/lossless link configurations the performance of the two forwarding

thresholds was similar.


thresholds. The relay to destination links are lossless, while the other links are lossy and their SNR is

the variable. For other lossy/lossless link configurations the performance of the two forwarding

thresholds was similar.

0

0.5

1

1.5

2

2.5

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]

p=0 p=0.2

0

200

400

600

800

1000

1200

1400

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]

p=0 p=0.2

0

100

200

300

400

500

600

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er

[ms]

SNR [dB]

p=0 p=0.2

0

20

40

60

80

100

120

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5FL

R [%

]SNR [dB]

p=0 p=0.2

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

5

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Thro

ugh

pu

t [M

b/s

]

SNR [dB]

p=0 p=0.2

0

200

400

600

800

1000

1200

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

De

lay

[ms]

SNR [dB]

p=0 p=0.2

0

0.5

1

1.5

2

2.5

3

3.5

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

Jitt

er[m

s]

SNR [dB]

p=0 p=0.2

0

20

40

60

80

100

120

-7.5-7-6.5-6-5.5-5-4.5-4-3.5-3-2.5-2-1.5

FLR

[%]

SNR [dB]

p=0 p=0.2


Page 77 (79)

V2V Scenario

For the V2V scenario (Section 2.4.1), Figure A.4 shows the simulation results and it turns out that SDF

(RESCUEp=0.0) performs better than LF (RESCUEp=0.2) in this large-scale V2V scenario. The reason lies in

the particular scenario and the V2V-specific requirements. With SDF, the CBF algorithm forwards error-

free packets only. Then, in the given scenario, where the SNR is too small to decode the packet as error

free at the last hop to the destination, joint decoding shows better performance in terms of packet success

ratio. With LF, the CBF algorithm forwards also packets with bit errors, which are used at the destination

to perform joint decoding. However, the packet success ratio of LF performs better compared to the

baseline. The intuitive explanation for the worse performance of LF to SDF is that CBF prefers forwarding

of packets with bit errors over error-free packets when the relay node is considered as the appropriate

forwarder (i.e., provides more spatial progress towards the destination). RESCUE CBF takes the confidence

value into account when the relay calculates the forwarding delay. This feature addresses the trade-off

between spatial progress and confidence value and would favour a relay which has less bit errors in a packet

over a relay which provides larger spatial progress. In this context SDF can be regarded as an extreme case,

where the importance of having a very small number of bit errors (actually zero bit errors) is much higher

than spatial progress, which then leads to SDF being a corner case of LF.

Due to the Nakagami channel also the relays in the second group (see Section 2.4.1) receive packets with

a high probability of bit errors inside the packets. In the LF approach relays forward the packet with errors

inside, in SDF they drop it. One constraint is the limit that each node is allowed to forward a packet at most

once. The advantage of SDF in VANETs is the shape of the network. The vehicles in a group are close

together and in direct communication range. If at least one vehicle receives the packet error free, it

distributes the packet in its group and generates three new potential forwarders. The probability that at least

one packet of the four forwarders in the first group is received by at least one node in the second group is

very high. Now, in the second group we have another four potential forwarders, which can send the packet

error free to the destination (but with low SNR). The situation now is as follows: in both cases (SDF/LF)

we receive four packet copies at the destination. In SDF all four packets were error free before the last

transmission whereas in LF errors can occur in the packets before. Therefore when the PHY Black Box

applies joint decoding SDF has an advantage compared to LF. However, the comparison of SDF and LF

can be seen as unfair because in SDF the nodes wait until an error-free packet arrives whereas in LF also

erroneous packets are forwarded. The Black Box supports just three packet copies and in this scenario the

probability that three error-free packets arrive is high. If all arriving packets would be used at the destination

LF should show better results. The end-to-end delay is worse in SDF since the vehicles in the second group

have to wait for subsequent error-free packets, where in LF erroneous packets are immediately forwarded.


Page 78 (79)

Figure A.4: Packet success rate and end to end delay of the large scale V2V-scenario

Summary

In conclusion, we can state that the forwarding threshold parameter is important to the performance of a

RESCUE network. Its optimal value is topology-specific and should be carefully considered during the

implementation and validation tests. Indeed, in some cases, as exemplified by the V2V scenario, adopting

SDF can be more beneficial. The presented results may lead to the formulation of a hypothesis that LF is

more appropriate in small-scale scenarios while SDF – in larger scenarios. Further research is required to

validate this hypothesis.


Page 79 (79)

References

[1] ETSI EN 302 636: „Intelligent Transport Systems (ITS); Vehicular Communications;

GeoNetworking”, Part 1 – 6, 2013

[2] ETSI EN 302 637-3 V1.2.2: “Intelligent Transport Systems (ITS); Vehicular Communications;

Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification

Basic Service”, 2014

[3] S. Kühlmorgen, S. Llatser, A. Festag, and G. Fettweis: "Performance Evaluation of ETSI

GeoNetworking for Vehicular Ad hoc Networks", VTC Spring 2015, Glasgow, Scotland,

May 2015

[4] RESCUE Project, “D1.2.1 – Assessment on Feasibility, Achievability, and Limits”, Version 1.0,

April 2015

[5] RESCUE Project, “D2.2.1 Interim Report of Detailed Optimisation Algorithm and Performance

Comparisons”, Version 1.0, April 2015

[6] G. Bianchi, "Performance analysis of the IEEE 802.11 distributed coordination function," Selected

Areas in Communications, IEEE Journal on, pp. 535-547, 2000.

[7] H. Hashemi, "A study of temporal and spatial variations of the indoor radio propagation channel,"

in Personal, Indoor and Mobile Radio Communications, 1994. Wireless Networks - Catching the

Mobile Future, 5th IEEE International Symposium on, Sep. 1994, pp. 127-134vol1.

[8] T. Clausen, and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October

2003.

[9] Y. Jiazi, C. Eddy, H. Salima, and P. Benoît, “Implementation of Multipath and Multiple

Description Coding in OLSR”, IEEE WCNC 2008, Las Vegas, USA 2008

[10] F. Bohdanowicz, M. Jakobs and C. Steigner “Statistical Convergence Investigation of Routing

Protocols” International Journal on Advances in Systems and Measurements, vol 3 no 3 & 4, 2010

[11] RESCUE Project, “D2.1.1 Interim Report of Detailed Coding/Decoding Algorithms and

Correlation Estimation Techniques”, Version 1.0, October 2014

[12] http://www.nsnam.org/

[13] A. Bhamri, F. Kaltenberger, R. Knopp, J. Hamalainen, “Smart Hybrid-ARQ (SHARQ) for

Cooperative Communication via Distributed Relays in LTE-Advanced”, in Signal Processing

Advances in Wireless Communications (SPAWC), 2011 IEEE 12th International Workshop on,

pp.41-45, 26-29 June 2011.

[14] Capacity of Ad-hoc Network, J. Li, C. Blake et al., Proceedings of the 7th ACM International

Conference on Mobile and Networking, 2001

[15] The capacity of wireless networks, P. Gupta and P.R. Kumar, IEEE transactions on information

theory, 2000

[16] Rogge, H., Baccelli, E., Kaplan, A., "Packet Sequence Number based ETX Metric for Mobile Ad

Hoc Networks", Internet-Draft, Sept. 2010

Documents

ICT- 619555 RESCUE D3.2 Version 2 - CORDIS...RESCUE D3.2 Version 2.0 Page 1 (79) ICT- 619555 RESCUE D3.2 Version 2.0 Report on revised WP3 architecture including simulation results