* Distributed: for well-connected environments, the knowledge of other users is taken into account by exchanging their environments parameters upon contacts.

Within the requirements of our proposition, calculations are performed dynamically and locally, which is more reliable in the instable environment of OppNets with rare opportunistic contacts.

## 5.3 CONTACT-BASED ADAPTIVE PACKETIZATION

This section overviews the proposed adaptive solution. It enables the nodes to predict future contact times, derive the suitable chunk size and then perform packetization on the small NALUs into single transmission units of the corresponding calculated size.

### 5.3.1 Contact Time Prediction

In OppNets, where no fixed topology exists, the network conditions differ from one location to another, and from one node to another. For example, because of the continuous mobility, some parts of the environment might temporarily become denser than other parts, and hence contacts would be more frequent. Moreover, some nodes might be moving faster than other nodes, which makes the contacts last shorter. Therefore, the environmental parameters which reflect those conditions have to be measured at each node separately. Similarly, the calculations and the process of packetization are to be performed by each node independently. Each node of the network keeps track of its own contact time history, and prior to packetization it tries to predict the next contact time by calculating the target value out of the history list up to the most recent past. This predicted target value is meant to serve as a lower limit for the next contact time, so that the actual contact time has a low probability to last shorter than this limit.

According to Gao and Cao [121], the distribution of contact times in Delay Tolerant Networks (DTNs) approximately follows a normal law, therefore each node is proposed to calculate only the contact times' mean (μ) and standard deviation (σ), and keep updating them regularly. Updates take place after every disconnection, to push the last contact into the history list. Based on the up-to-date μ and σ values, the prediction of the next contact time is done then using the 3-sigma rule on the normal distribution [122]. This rule is based on the fact that an observation x lies around the mean value within distances that are defined by the standard deviation with the following probabilities:

$$P(\mu - \sigma \le x \le \mu + \sigma) \approx 0.682$$

$$P(\mu - 2\sigma \le x \le \mu + 2\sigma) \approx 0.954$$
$$P(\mu - 3\sigma \le x \le \mu + 3\sigma) \approx 0.997$$

The different distances are depicted in Figure 5.2, along with corresponding probabilities for x to lie within the given distance.

<figure><img src="image_47.png" /><figcaption>Figure 5.2: The 3-Sigma Rule</figcaption></figure>

However, we are looking for a lower bound value of the contact time, which will high probably be close to or less than the actual contact time to take place next. Therefore, the greater ranges of the previous relations are excluded, leading to the following probabilities:

$$P(\mu - \sigma \le x) \approx 0.841$$

$$P(\mu - 2\sigma \le x) \approx 0.977$$

$$P(\mu - 3\sigma \le x) \approx 0.998$$

A negligible increment of probability is noticed between 2σ and 3σ distances. Therefore, to not over lower the predicted contact time limit, it is fixed as in Equation 5.2.

$$T_{next} = \mu - (2 \times \sigma) \qquad (5.2)$$

This relation holds that $P(t \ge T_{next}) \approx 97.7\%$, which means that the actual future contact time, t, will most likely (with a certainty of 97.7%) last for no shorter than $T_{next}$, and thus be enough to transmit the designated chunk size.

### 5.3.2 The Process of Packetization

Once the contact time limit is determined, the corresponding chunk size limit can be calculated from Equation 5.1:

$$size_{limit} = T_{next} \times transferRate$$

and this implicitly defines m, the optimal number of chunks:

$$m = \left\lfloor \frac{size_{total}}{size_{limit}} \right\rfloor; size_{total}: the size if the whole SVC video \qquad (5.3)$$
When the source node has all the NALUs ready, it prepares the initial chunks and transmits them. The number of NALUs in a single chunk is not fixed and varies from one chunk to another, because the NALUs differ in size.

When any further node X, along the way to the destination, receives a chunk of packetized NALUs after a contact with a node Y, it has to record the last contact duration. Then (if necessary), it has to update its μ and σ values, and depacketize the NALUs and repacketize them into one or more chunks of the newly adjusted size limit. That necessity is based on the condition, whether the newly recorded contact duration is much bigger or much smaller than the calculated μ. Otherwise, if the contact duration does not change drastically, the received chunk can remain untouched and ready to be retransmitted. We consider that a new contact duration necessitates an update if it lies outside a distance of σ from the average μ.

The complete algorithm of the above described process is summarized in Listing 5.1.

The contact time (t) with node Z is most likely to be no shorter than $T_{next}$, and enough to send at least one packet. However, there is still a possibility for t to be:

* $t < T_{next}$ ⇒ no chunk will be transmitted

* $t \gg T_{next}$ ⇒ more than 1 chunk is transmitted

In all cases, after every contact, the most recent contact time is pushed (if necessary) to the list of the contact times history of both contact's parties, and will influence the newly updated values of their μ and σ parameters. Hence, both nodes will update their $T_{next}$ accordingly. This behavior ensures the dynamicity of the approach when facing changing network conditions, since recent contacts are directly taken into account in the history of the concerned nodes.

## 5.4 EXPERIMENTS

This section presents and analyzes the results of the conducted experiments. For the continuity of the work, the experimental setup is remained untouched from Section 4.3. However, as no different conclusions were found for the different video sequences, we limit the experiments in this chapter to the $V_2$: *Highway*, which is fairly long enough to have a big number of NALUs and allow testing our proposal. For the same reason, we limit the mobility model to the *Shortest Path Map-Based Movement* (*SPMBM*), and exclude the unrealistic Random Way-Point (RWP). Lastly, the routing protocol is set to *binary Spray-and-Wait* (*SnW*) only to build on our experimented proposal of prioritized data parts.
```javascript
% When disconnected after receiving a chunk c from Y to X
connection(X,Y).on('disconnection') {
    % Record the last contact duration
    Tlast = connection(X,Y).duration;
    if (Tlast < (X.µ + X.σ) && Tlast > (X.µ - X.σ)) {
        % the contact duration changed only slightly
        X.buffer1.push(c); % buffer1 is for chunks. c is ready to be transmitted
        return; % update nothing.
    }
    % Update the contact time history and corresponding parameters
    X.history.push(Tlast);
    X.µ = average(X.history);
    X.σ = stdev(X.history);
    % predict the next contact time, and the corresponding optimal chunk size
    Tnext = µ - (2 × σ);
    size limit = Tnext × transferRate
    % depacketize: extract NALUs
    NALUs = depacketize(c);
    X.buffer2.concatenate(NALUs); % buffer2 is for NALUs
    % do not repacketize now, because more NALUs might be received from other
    % nodes than Y
}
```

```javascript
% When coming in contact with a new node Z ≠ Y
connection(X,Z).on('set-up') {
    % repacketize the extracted NALUs accordingly
    c = newChunk();
    while (X.buffer2.notEmpty) {
        NALU = X.buffer2 pull();
        if (c.size + NALU.size > size limit) {
            % c reached its size limit, then it is ready to be transmitted
            X.buffer1.push(c); % buffer1 is for chunks
            c = newChunk();
        }
        c.add(NALU);
    }
    % there is one last chunk that might not reach size limit
    X.buffer1.push(c);
}
```

```javascript
% When the connection with Z is up
connection(X,Z).on('connected') {
    while (connection(X,Z).isUp()) {
        c = X.buffer1 pull();
        connection(X,Z).send(c);
    }
}
```

<caption>Listing 5.1: Adaptive Packetization at Node X: Reception & Transmission</caption>

### 5.4.1 Transmission Using NALUs

As introduced, the drawbacks identified in Chapter 4 lead to the idea of using smaller units than SVC layers. And because an SVC stream is composed by definition of small
NALUs, we performed an experiment to see how feasible it is to use NALUs as the transmission units. Results are given in Figure 5.3.

<figure><img src="image_48.png" /><figcaption>Figure 5.3: Transmission of NAL-Units</figcaption></figure>

The left part of the figure analyzes the delays of delivering the quality of the BL (depicted in light-blue) and the maximum delivered quality level (depicted in dark-blue). Whereas the quality distribution is depicted on the right part of the figure with 5 quality levels referring to the 5 defined Operating Points (OPs). The results are given as a percentage of the simulation rounds that reached the corresponding quality level.

Compared to the results from Chapter 4, the percentage of rounds with no delivery increased from 0% to 42% (i.e. playout availability = 58%), and 34% of the rounds were limited to only the BL quality. This bad result is justified by the very big number of units, which increased the probability of worst-case delay as described in Section 5.2.1.2. For instance, the used video stream has 8000 NALUs under the given configurations. These units are distributed among the different layers (e.g. 500 NALUs for the BL alone). A layer is only playable if all its composing NAL units are successfully received, and hence if any unit of a layer is lost, other received units are useless (with the assumption that no error concealment is applied). Therefore, the more composing parts a video (or a layer) has, the less likely it is to be playable.

### 5.4.2 Oracle-Based Experiments

Before testing our adaptive-granularity approach, an optimal baseline reference is recommended to be built. This optimal case is simulated by running oracle-based experiments. These experiments assume the existence of an oracle, which knows everything about the simulation environment in advance, e.g. contacts occurrences and contacts- and inter-contacts- times. That is, given the environmental configurations as the map, the mobility model, the density and the nodes speed, the oracle can
analyze the overall contact times in advance and allow the nodes to estimate their chunks' size$_{limit}$ before launching the simulation. Thus, no calculations have to be performed by the nodes at run-time. Using our given configuration, the distribution of contact times is as shown in Figure 5.4.

<figure><img src="image_49.png" /><figcaption>Figure 5.4: Distribution of Contact Times</figcaption></figure>

This distribution holds that $\mu \approx 7.8$ and $\sigma \approx 2$. By applying these values into Equations 5.2 and 5.1, we get <fnref n="2" />:

$$ 
\begin{aligned}
T_{\text{next}} &= 7.8 - (2 \times 2) \approx 3.8 \text{sec} \\
\Rightarrow \text{size}_{\text{limit}} &= 3.8 \times 250 \text{kBps} \approx 1 \text{MB}
\end{aligned}
$$

As an oracle, the chunk size for all nodes during the whole simulation time is fixed to 1 MB, and all nodes are limited to this size when packetizing.

Consequently, by applying our adaptive approach with the above calculated size$_{limit}$ to transmit the NALUs of the video V$_{2}$, we got the results in Figure 5.5, including the delivery delays and quality distribution.

<figure><img src="image_50.png" /><figcaption>Figure 5.5: Oracle-Based Packetization</figcaption></figure>

The playout delay is the delivery time for BL, and it is worse compared to Figure

<footnote n="2">² Transmission interface: Bluetooth, transmission rate= 250 kBps (see Chapter 4)</footnote>
4.14b from Chapter 4 (75 min vs. 130 min), while the delivery time for the maximum quality is improved (from ≈ 190 in Figure 4.14b to ≈ 145 min). However, the significant improvement lies in the highest achieved quality, which is depicted on the right part of the figure. Over 90% of the rounds reported a full quality (level-5), compared to 34% when using SVC layers (Figure 4.15 from Chapter).

Although having an oracle with a full knowledge is not close to reality, but its experiments serve well for a comparison purpose.

### 5.4.3 Adaptive Packetization

Next, this section applies the adaptive approach on the actual experiments, where each node keeps track of its contact history, and hence also of updated $\mu$ and $\sigma$ values. The next contact time and the corresponding chunk size limit are dynamically predicted as given in Listing 5.1. Simulation are performed with the given configurations, and the results of delay, playout availability, and quality distribution are given in Figure 5.6.

<figure><img src="image_51.png" /><figcaption>Figure 5.6: Adaptive Packetization</figcaption></figure>

Similarly to oracle-based results, the significant improvement compared to Figure 4.14b appears in the achieved quality level, where 81% of the simulation rounds reach the maximum quality level. On the other hand, the delay of the maximum quality has a slight improvement in comparison to Figure 4.14b, from 190min to ≈ 170min. However, the playout delay reports a setback from 75min to 170min. Another bad result is the 14% loss rate, which lowers the playout availability from 100% to 86%. Both setbacks are related to the BL, whose delayed delivery affects the playout delay, and failed delivery affects the playout availability.

Therefore, to overcome the mentioned setbacks, we propose to combine the two transmission approaches of SVC layers and NALUs adaptive packetization. The idea is to condition the adaptive packetization of the NALUs of a given layer (or OP), so that
it is performed only if the layer (or OP) is larger than the computed threshold size. Hence, if a given OP is already smaller than the computed optimal chunk size, this OP is kept as it is and excluded from extracting its composing NALUs, which are to be fed to the packetization procedure. For the BL, this is particularly important, so that if the BL size does not fulfill the condition (i.e. does not exceed the determined chunk size limit), its NALUs are excluded from being packetized, and the OP is sent at once. Hence, the algorithm in Listing 5.1 is modified accordingly into the one in Listing 5.2.

```R
% When disconnected after receiving a chunk c from Y to X
connection(X,Y).on('disconnection') {
  % Record the last contact duration
  Tlast = connection(X,Y).duration;
  if (Tlast < (X.µ + X.σ) && Tlast > (X.µ - X.σ)) {
    % the contact duration changed only slightly
    X.buffer1.push(c); % buffer1 is for chunks. c is ready to be transmitted
    return; % update nothing.
  }
  % Update the contact time history and corresponding parameters
  X.history.push(Tlast);
  X.µ = average(X.history);
  X.σ = stdev(X.history);
  % predict the next contact time, and the corresponding optimal chunk size
  Tnext = µ - (2 × σ);
  size limit = Tnext × transferRate
  % check the need to depacketize
  if (c.isOP() && c.size < size limit) {
    % exclude from depacketization
    X.buffer1.push(c); % buffer1 is for chunks. c is ready to be transmitted
  }
  else {
    % depacketize: extract NALUs
    NALUs = depacketize(c);
    X.buffer2.concatenate(NALUs); % buffer2 is for NALUs
  }
}

% When coming in contact with a new node Z ≠ Y
... % untouched from Listing 5.1

% When the connection with Z is up
... % untouched from Listing 5.1
```

<caption>Listing 5.2: Adaptive Packetization at Node X: The Combined Solution</caption>

Consequently, by applying the proposed combined solution and running new simulations, the results are refined as shown in Figure 5.7.

The combined solution, compared to Figure 5.6, returns a playout availability of
<figure><img src="image_52.png" /><figcaption>Figure 5.7: Combined Solution: Conditioned Packetization</figcaption></figure>

100%, where 19% of the rounds stop at the BL quality level, and 81% continues to the maximum quality level associated with OP-5. Furthermore, the playout delay becomes equivalent to the one in Figure 4.14b (≈ 75min). Consequently, these results positively contribute for a better viewing Quality-of-Experience (QoE), as presented in the next section.

### 5.4.4 Viewing QoE

#### 5.4.4.1 Results Normalization

The viewing experience is evaluated using the Equation 4.1 from Section 4.2.2, after the measurement values are normalized using the Equation 4.2.

**QUALITY** The average delivered Peak Signal-to-Noise Ratio (PSNR) video quality is given in Table 5.2. Moreover, the same as done in Section 4.4.3.1, the video quality is normalized and inverted, so that the optimal value lies at zero.

<table><caption>Table 5.2: Average and Normalized Quality Level</caption><thead><tr><th rowspan="2">Metric</th><th>Binary <i>SnW</i></th></tr><tr><th><i>V</i><sub>2</sub></th></tr></thead><tbody><tr><td><i>PSNR</i></td><td>35.7</td></tr><tr><td><i>PSNR</i></td><td>0.96</td></tr><tr><td><i>q̃</i></td><td>0.04</td></tr></tbody></table>

**DELAY** The delay values are normalized on the basis of the messages' set Time-to-Live (TTL) as the upper bound. The lower bound is set to 0.
**OVERHEAD** One of the important aspects in the proposed adaptive packetization approach is that it does not add extra network overhead onto the previously implemented SVC layers approach. Hence, the calculation and normalization of the overhead remains the same as previously given in Section 4.4.3.1.

### 5.4.4.2 Calculation Of The Viewing QoE

The viewing experience is evaluated as proposed using the Equation 4.1 on two measurement points ($p_1, p_2$). Analytical summary is given in Table 5.3.

<table><caption>Table 5.3: Viewing Experience Evaluation</caption><thead><tr><th></th><th></th><th>Binary<br>SnW</th></tr><tr><th></th><th></th><th>V<sub>2</sub></th></tr></thead><tbody><tr><td rowspan="7">p<sub>1</sub></td><td>PSNR</td><td>28.7</td></tr><tr><td>PSNR</td><td>0.77</td></tr><tr><td>q̃</td><td>0.23</td></tr><tr><td>t (min)</td><td>80</td></tr><tr><td>t̃</td><td>0.222</td></tr><tr><td>ō (%)</td><td>0.15</td></tr><tr><td>val(p<sub>1</sub>)</td><td>0.353</td></tr><tr><td rowspan="7">p<sub>2</sub></td><td>PSNR</td><td>35.7</td></tr><tr><td>PSNR</td><td>0.96</td></tr><tr><td>q̃</td><td>0.04</td></tr><tr><td>t (min)</td><td>180</td></tr><tr><td>t̃</td><td>0.5</td></tr><tr><td>ō (%)</td><td>0.15</td></tr><tr><td>val(p<sub>2</sub>)</td><td>0.524</td></tr><tr><td></td><td>QoE(p)</td><td>0.438</td></tr></tbody></table>

Consequently, compared to Table 4.5 of Chapter 5, the adaptive solution improves the viewing QoE from 0.454 to 0.438, based on slight improvements of the maximum quality level and its associated delay.

### 5.4.5 Validation and Comparison

This section aims to validate our results by comparing them to some of the corresponding works from Section 3.3.

It complements the Section 4.6 with regard to the transmission approach and the resulting viewing QoE. We showed in that section how Raffelsberger and Hellwagner [81] can achieve playout delay and quality that are similar to our result. However, our results reflect a better viewing QoE because of the maximum delivered quality.
In this chapter, we succeeded to achieve a better maximum quality level at a lower
delay, leading to a still better viewing QoE. Similarly, the same comparison applies
for the work of Wu and Ma [84], where our better analyzed viewing QoE is shifted
forward in this chapter. Furthermore, the adaptive solution in this chapter introduces
improvements of the maximum quality level and its associated delay, which helps to
overcome the advantage of Chen et al. [82, 83] with regard to the viewing QoE's p₂
result point.

Besides, addressing the comparison with regard to adaptive decisions in *OppNets*, a different analysis must be drawn. Schierl et al. [74] adapt the channel coding replication factor by studying the quality of the connection. Whereas in *Mobile Ad-hoc Networks (MANETs)* it is very easy to determine the quality and stability of a connection, this is possible in *OppNets* only using estimations. Tournoux et al. [98] tried to perform such an estimation by analyzing the number of contacts of the encountered nodes to assign them a "node degree" value. Hence, they could build an off-line hash-map to optimize the redundancy factor of the *SnW* routing protocol based on given node degree and target delay. Nevertheless, using the channel quality estimation and the node degree metric for the adaptive size tuning has two main drawbacks: 1) The adaptive measurements can take place only when you are in contact with node, to which the data must be sent. Therefore, a long part of the contact duration is spent on calculating and preparing the chunk to be sent. Whereas our adaptive solution can make use of the time between contacts to update history and prepare the measurements correspondingly. 2) The off-line hash-map is based on a metric (i.e. the number of contacts) that is not directly relevant to estimate the optimal chunk size. Hence, the problem of delivery failure due to big a chunk size will arise again.

The PRoPHET routing protocol [33] also functions adaptively through its estima-
tion function. However, PRoPHET was experimentally tested in Chapter 4, and it
reported bad results in Figures 4.14 and 4.16.

Lastly, Hu and Hsieh [100] and Wang et al. [32] developed algorithms to determine
whether to send data to another node upon contact or not. However, using their
techniques for the adaptive size tuning will run into the above mentioned drawbacks
of using the technique of Tournoux et al. [98].

5.5 SUMMARY

This chapter proposed advancements and refinements of the video dissemination
scheme in *OppNet*. The transmission units are tuned to form chunks encapsulating
the small *NALUs*. Those chunks vary in size according to adaptive node-dependent
measurements that respect the changing network conditions of *OppNets*. The theoret-
ical propositions are promoted through experimental simulations. Constantly to the
former results in Chapter 4, the 100% ratio of playout availability is kept, a slight improvement for the delivery delay is achieved, and the average received quality level is improved. Consequently, these results led to an improved value of the viewing QoE.

* * *
<figure><img src="image_53.png" /></figure>
# THE INTEGRATION OF BALCON: A BACKWARD LOSS CONCEALMENT MECHANISM

## 6.1 PROBLEM STATEMENT

It is seen from Chapters 4 and 5 how the dissemination scheme implemented two related techniques for delivery enhancement at the sender's side. However, this did not suffice to completely eliminate cases with limited delivery. Failures in delivering certain layers are detected to be caused by a partial loss of only a small fraction of the composing NAL Units (NALUs). Such small data gaps of partial loss can usually be filled using loss- or error-concealment techniques. However, under the lack of a loss concealment technique and because of the continuity of the video medium, a Scalable Video Coding (SVC) layer is successfully delivered only if all its composing NALUs are delivered.

Therefore, this chapter addresses the third research problem (from Chapter 1), which aims to induct a concealment mechanism at the destination node. This will mitigate the impact of partial losses and enable the receiver to react to data loss.

As given in Chapter 3, most of the interest in loss- or error- concealment in OppNets is concerned with "forward" techniques, where the source node has to spend more processing power in order to calculate correction codes. These codes are attached and transmitted as a part of the original data to help the receiver node in recovering lost chunks. Some discussed drawbacks of these techniques are: the extra data to be computed and transmitted, the prolonged delivery delay and the need to modify the encoding process to integrate their implementations. Furthermore, some correction codes are sensitive to the amount and pattern of the occurred losses. That is, if an essential code part is missing, the recovery process is suspended with the receiver node sitting on his hands.

Hence, this chapter studies how to push the destination node at the back-end into action by reacting to missing data in a "backward" solution. First, the receiver asks
for the missing data from other nodes in the network in the form of request-response. Second, since the transmission is concerned with video content, video Frame Loss error-Concealment (FLC) techniques can also be exploited at the receiver side. Consequently, we propose to combine the two techniques in a composite *Backward* loss concealment solution, which can react to a limited amount of loss.

## 6.2 OBJECTIVES AND CONTRIBUTIONS

This section highlights the objectives and contributions of this chapter. First, it overviews the proposed loss concealment mechanism, and how the composing techniques are integrated within the frame of one concealment mechanism. Then, it discusses the criteria for initiating the concealment process.

### 6.2.1 Backward Loss Concealment

In this section, a “backward” solution is proposed, which is based on involving the receiver node in the dissemination process by reacting to missing data parts<fnref n="1" />. The solution is shortly named Backward Loss Concealment (BALCON), which compositely combines two concealment techniques:

1. Network demands: the receiver node asks for the missing parts from other nodes in the network in the form of request-response.

2. Video-based: because the transmission is concerned with video content, video FLC techniques can also be exploited at the receiver side.

#### 6.2.1.1 Network Demands

As introduced, the first part of the composite concealment mechanism is to initiate demands by the receiver in the network, in search for the missing data parts from other nodes. Unlike Mobile Ad-hoc Network (MANET)'s Automatic Retransmission Request (ARQ), demands are not generated as acknowledgments (automatically and for every message), and their destination is not limited to the original source.

So, from now on we will refer to the receiver node in this context as the “d demand” who initiates demands. Those demands can target then through multihop paths one or more nodes, whose ability to serve a demand by having a copy of the sought data part is probable. We refer to those potentially serving nodes as the “potentials”. Hence, if any potential can serve the demand, it will reply and address the sought data part back to the demander.

The ratio of concealed loss by the received data parts in response to the network

<footnote n="1">¹ We use “data part” as a general term that can have difference references (e.g. NALU, chunk, layer, .. etc.) depending on the context, where the concealment mechanism is applied.</footnote>
demands represents the capability of the network-demands concealment technique.
This capability depends on many parameters that are related to the network configu-
ration, like the routing protocol, the mobility and the density.
However, more detail on how the demands are initiated, and how the responses are
routed back, are given in Section 6.3.

6.2.1.2 *Video Frame Loss Error Concealment*

Video content-based concealment techniques represent another possibility at the re-
ceiver side, and hence can complement the network demands in the composite mech-
anism. As given in Section 3.4, the SVC reference software implementation (Joint Scal-
able Video Model (JSVM) [2]) adopts four basic concealment techniques: Frame copy,
Temporal direct, BL-skip and Reconstruction BL-upsampling. All the four mentioned
techniques are mainly designed to conceal errors in the Base Layer (BL) as well as the
temporal and spatial Enhancement Layers (ELs). Their applicability for the Signal-to-
Noise Ratio (SNR) quality ELs has to go through a more complex process, which is a
different research topic [123]. Therefore, this is kept out of the concern of this work.
The four FLC techniques are already implemented and tested in the literature [106,
107]. Hence, their concealment capability can be easily evaluated by measuring the
associated video quality drop (in relevance to the quality<fnref n="2" /> of the original video) when
they are applied on on different loss ratios. Then, fixing a certain value, below which
the video quality is not acceptable, will refer to the concealable amount of loss by the
corresponding video FLC technique.

6.2.2 *Launching Criteria of The Concealment Process*

We propose to calculate the launching moment or criteria of the whole concealment
process by setting a threshold on either time or delivery ratio.

6.2.2.1 *Time*

In this approach, BALCON starts after a time Tstart, that is measured from the starting
point of the dissemination. The concealment process is launched then regardless of
the delivery and loss ratios. This criteria is easy to implement because it does not
involve any computation and the value of Tstart can be directly set either arbitrarily
or based on a certain delay value. For the latter case, when the delivery delay exceeds
a predefined threshold, the concealment mechanism is launched.
In both cases, the ignorance of the present amount of loss makes the concealment
mechanism prone to one of two deficiencies: either to start too early, then the con-

<footnote n="2">2 Quality is measured by the means of Peak Signal-to-Noise Ratio (PSNR) metric.</footnote>
cealment can not help to complete the delivery. Or to start too late, then an avoidable
delivery delay will take place.

6.2.2.2 Delivery

In the second variation, BALCON starts when the delivery ratio exceeds a fixed value, regardless of when that would happen. The computation of the threshold value has to be done precisely, with respect to the loss and the concealment capabilities of the used techniques, so that:

$$
\underbrace{\text{data}_{\text{total}} - \text{data}_{\text{delivered}}}_{\text{loss}} \le \text{concealment}_{\text{demands}} + \text{concealment}_{\text{FLC}}
$$

This is to be interpreted as: the total concealment capability must be no less than the present amount of loss, which ensures a feasible application of BALCON.

Deriving the launching threshold can be done then by knowing the capabilities of the
concealment techniques, and waiting for the parameter (data<sub>delivered</sub>) to increase
until it satisfies the given relation. This is explained in more detail later in Listing 6.1.

6.3 NETWORK DEMANDS: REQUESTS & RESPONSES

This section addresses in more details the network demands technique, through its
two phases: the initiation of demands, and serving them back.

6.3.1 Requests: Initiating Demands

The set of target potentials can include the original source node only (Unicast), fur-
ther nodes that are known to the demander (Multicast), or any encountered node in
the network (Broadcast). Thus, the distribution is subject to a trade-off between the
probability of serving the demand, on the first hand, and the privacy<fnref n="3" /> and resources
consumption on the other hand.

The probability that any single potential can serve the demand is named "servability,"
which is (for any potential rather than the source) tightly dependent on the originally
used routing protocol and the resulting distribution of data among the mobile nodes.

For instance, if a message is distributed using the Spray-and-Wait (SnW) routing pro-
tocol with M copies, in a network having n nodes, the servability of any potential is
limited to:

$$
\text{servability} \le \frac{M}{n} \tag{6.1}
$$

<footnote n="3">³ For example, who is allowed to know which data parts are missing? However, this is a different research topic, and it is kept out of the scope of this work.</footnote>
The upper bound applies after a time T, when the M copies are equally distributed to M nodes, leaving no node with more than one copy of the message. At any time t < T, only m < M nodes are able to serve.

All of above constitutes the case when only one potential is targeted. Then the serv-
ability when targeting k potentials is:

$$
\begin{align*}
\text{servability}_{(k)} &= P(\text{at least one potential can serve}) \\
&= 1 - P(\text{none of the k potential nodes can serve}) \\
&= 1 - P(\text{node}_1 \text{ can't & node}_2 \text{ can't & .. & node}_k \text{ can't})
\end{align*}
$$

The probability that a potential can not serve the demand is given by the ratio of
the number of nodes that do not have a copy of the message, to the total number of
nodes. Hence, because the events of that the k potentials can not serve the demand
are not mutually exclusive, then:

$$
\text{servability}_{(k)} = 1 - \underbrace{\frac{n-m}{n} \times \frac{n-m-1}{n-1} \times \dots \times \frac{n-m-(k-1)}{n-(k-1)}}_{k \text{ times}}
$$

$$
\Rightarrow \text{servability}_{(k)} = 1 - \left( \frac{\sigma(n-m, k)}{\sigma(n, k)} \right) \qquad (6.2)
$$

Where P(..) refers to probability, and σ(..) refers to permutation. Obviously, when tar-
geting more potentials (greater k), the servability would be higher, i.e. the probability
that the demand will be served by any potential, regardless of its identity.

6.3.2 Responses: Serving Demands

When a potential receives a demand of a specific data part, it looks that part up
in its buffer. If found, the demanded part is routed back to the demander. For this,
the potential can use either the originally used routing protocol, or configure a new
protocol.

In Chapters 4 and 5, the SnW routing protocol was used with different redundancy
factors for the different data parts depending on their importance degree. In this
case, if a potential receives a demand of an existing part, the demand can act then as
a trigger to increase the redundancy factor of that part, which will allow to initiate
more copies and help to serve the demand back. For example, the source initiates
a message with cᵢ copies. This message reaches later a node X with a left forward-
allowance (redundancy factor) of only one copy. This copy must reside at X until it
can be directly transmitted to its destination. Now, if X receives a demand for this
message, X will reset its redundancy factor from 1 to cᵢ again to increase its delivery
probability. Otherwise, a newly configured routing protocol can be independent of
the first one.

6.3.2.1 The Applicability of Smart Routing

In less dynamic peer-to-peer networks, the path of the demand message along the way from the demander to the potential, might represent a useful information for routing back response messages. These latter can, for example, try to go through the same or a very similar path to the former one. In Opportunistic Networks (OppNets), on the other hand, this is hardly applicable because of the high dynamicity of the network. For example, assume a node A delivers a message to node B, and they both continue their movements. Thus, a disconnection is highly probable, so that B will no longer be able to send a response back through A.

To investigate this assumption practically, we performed a “ping-pong” message ex-
change experiment in a simulated OppNet environment between 100 different and
random node pairs<fnref n="4" />. So that a random node xᵢ sends a very small message (1 byte)
to a random node yᵢ using the epidemic routing protocol. When delivered, yᵢ re-
turns the same message back to xᵢ on any path using the same routing protocol. To
study the correlation between the path of any of the messages and their responses,
we counted the common nodes between the path of a message and the path of its
response. Among over 500 exchanged messages, we got the following results:

• Number of hops ∈ [1,7], Avg ≈ 3

• ~ 49.5% of paths had 0 common node

• ~ 50% of paths had 1 common node

• Only ~ 0.5% of paths had 2 common nodes

Consequently, it is concluded to let response messages make no prior-knowledge
assumptions for the routing protocol, because targeting any of the nodes on the de-
mand path as a next relay, would unpredictably delay the delivery if that node is far
or left the network.

6.4 THE FUNCTIONALITY OF BALCON

Our proposal is to combine the two previously described techniques in a composite
solution (i.e. BALCON) that can work better at the receiver side. As seen in Chapter 5,
a partial loss of a small amount of the NALUs dramatically affects the total delivery.
Therefore, the goal of BALCON is to conceal the loss of missing NALUs.

<footnote n="4">⁴ Other setup parameters are the same as used for the experiments in Chapter 4 and 5: SPMBM mobility, Bluetooth transmission interface, a big enough buffer and a long enough TTL.</footnote>
For a specific SVC Operating Point (OP), BALCON applies both network demands and FLC techniques in an adaptive way with regard to the individual types of the missing NALUs (i.e. BL, temporal-, spatial- or SNR-enhancing unit). The designated functionalities for the different NALU types are summarized in the algorithm in Listings 6.1 and 6.2.

Input:
Delivered data: delivered
Delivery threshold: D
Amount of loss that can be concealed using FLC: C<sub>FL</sub>
% Check the delivery ratio with regard to the defined threshold
while (delivered < D) {
  wait();
}
% When the delivery exceeds the defined threshold, BALCON starts
% Determine the missing NALUs and apply the network-demands technique
missingNALUs = recognizeMissingNALUs(delivered);
delivered += networkDemands(missingNALUs, C<sub>FL</sub>);
% Determine the still missing NALUs and apply the FLC technique
missingNALUs = recognizeMissingNALUs(delivered);
for (x in missingNALUs) {
  % The functionality varies depending on the NALU type
  if (x.type == BL || x.type == EL-Temporal) {
    delivered += FLC(delivered, missingNALUs, "Frame-copy");
  }
  else if (x.type == EL-Spatial) {
    if (BL.exists) {
      delivered += FLC(delivered, missingNALUs, "Frame-copy");
    }
    else {
      delivered += FLC(delivered, missingNALUs, "BL-skip");
    }
  }
  else if (x.type == EL-SNR) {
    % No FLC is applied
  }
}

<caption>Listing 6.1: BALCON Functionality - 1</caption>

Because FLC is based on extrapolating missing NALUs, it has more impact on the quality. Hence, it is chosen to always start with the network demands technique, and then apply FLC on the remaining loss fraction. Furthermore, the launching criteria is set for BALCON to “delivery,” because the whole mechanism is based on analyzing the
```javascript
function recognizeMissingNALUs(delivered) {
    allNALUs = delivered.metadata.listOfNALUs;
    missingNALUs = [];
    for (x in allNALUs) {
        if (delivered.hasNALU(x) == false) {
            missingNALUs.push(x);
        }
    }
    return missingNALUs;
}

function networkDemands(missingNALUs, CFL) {
    servedDemands = [];
    % Send demands
    for (x in missingNALUs) {
        broadcastDemand(x);
    }
    % Wait for responses
    while (missingNALUs.size > C_FL) {
        if (new NALU, x, is received) {
            servedDemands.push(x);
            missingNALUs.delete(x);
        }
        % else wait
    }
    % The function returns only when the amount of the remaining loss can be
    % concealed using FLC
    return servedDemands;
}
```

<caption>Listing 6.2: BALCON Functionality - 2: Utility Functions</caption>

capabilities of both concealment techniques. The algorithm waits for the loss ratio to drop under a specific threshold (or the delivery ratio to go over a specific threshold), so that it can be concealed then. Determining this threshold is tightly dependent on the mentioned capabilities. It starts by studying the capability of the FLC technique by measuring the video quality drop associated with different loss ratios, as presented in Section 6.2.1. Next, the capability of the network demands approach is measured as a percentage of the demands that can be successfully served. Since the value of the capability must be known by the algorithm, there are two possibilities to measure it:

* Statically: by performing off-line experiments to estimate the capability value of the network demands technique, then fix this value statically for further experiments.

* Dynamically: by making BALCON self-adaptive, so that to take the network conditions into consideration and calculate the capability at run-time.
To concentrate on the concealment aspect of the algorithm, we limit the experiments in this chapter to the statical approach. However, the self-adaptive BALCON mechanism is kept as a future work.

Lastly, unserved demands represent the remaining loss fraction, which must be equal to the capability of FLC.

Consequently, by merging the two approaches together, a threshold for the whole BALCON solution can be defined, at which the concealment process will start. Mathematically formulated, BALCON should satisfy the following relation:

$$l - (C_{ND} \times l) = C_{FL} \qquad (6.3)$$

where

l : total amount of loss

CND : ratio of servable demands, ∈ [0, 1[

CFL : concealable loss using FLC

Rearranging the relation, it can be written as:

$$l = \frac{C_{FL}}{1 - C_{ND}} \qquad (6.4)$$

Where l in this last relation represents the loss threshold, with which the concealment process may start.

Lastly, this is repeated for each OP separately, because the OPs (and their constituting layers) posses different scalability characteristics and importance degrees, which results in varying the threshold values.

## 6.5 EXPERIMENTS

This section presents and analyzes the results of executed experiments. Again for the continuity of work, the experimental setup is remained untouched from Section 4.3. Moreover, as in Chapter 5, the tested video sequence is limited to V2: Highway, the routing protocol to binary SnW, and the mobility model to Shortest Path Map-Based Movement (SPMBM).

### 6.5.1 Capability Estimation of The Network Demands

The first set of experiments is meant to approximate the capability of the network demands technique in general, out of the context of video data.

Messages that are similar in size to NALUs are transmitted in the simulated network
toward the receiver node, which will turn into a demander after an arbitrarily fixed
time $T_{start}$ regardless of the delivery. Responses are analyzed in order to statistically
set the parameter $C_{ND}$ in Equation 6.4. Epidemic and SnW (with different numbers of
copies) routing protocols were tested to route responses back. SnW copies are identical
to the number of copies that were already used to transmit the SVC OPs in previous
chapters, namely: 16, 8, 4 and 2 copies. Besides, demands have two options with
regard to the target group: one or multiple potential nodes. Results for each case are
described separately. Measurements include the ratio of returned responses to the
demander, and their delays.

6.5.1.1 One Potential Node

To limit the resources consumption and implement an easier selection of target poten-
tials, the demander sends the demands exclusively to the source node, which for any
successfully received demand has a servability of 100%. Results for epidemic and the
different SnW variations are shown in Figure 6.1.

<figure><img src="image_54.png" /><figcaption>Figure 6.1: Network Demands: One Potential</figcaption></figure>

Using *SnW* with 2 copies, only 18% of the demanded messages could have been suc-
cessfully received back, with an average delay of about 160 min. Results become better
while using more copies, until reaching 66% of successful reception and ≈ 100 min
delay using *SnW* with 16 copies. Lastly, using the uncontrolled flooding, Epidemic
reports 69% of successful reception and 80 min delay.

6.5.1.2 Multiple Potential Nodes

With less strict constraints, demands can target a larger set of potentials. Due to
the characteristics of *OppNets*, the demander does not know in advance the member
nodes of the network. Therefore, to expand the set of potentials, demands will be
broadcasted in the network. Results for epidemic and the different *SnW* variations are
shown in Figure 6.2.

Results in Figure 6.2 are obviously better than those in Figure 6.1 in terms of both
<figure><img src="image_55.png" /><figcaption>Figure 6.2: Network Demands: Multiple Potentials</figcaption></figure>

successful reception of demands and delay. Using SnW with 16 copies reports a successful reception of 80% and around 70 min delay. This means that with targeting multiple potentials using the SnW-16 routing protocol, the network-demands technique is capable to conceal 80% of existing loss.

These results will be used next to derive the capability and impact of applying BALCON.

### 6.5.2 Concealment Capability of BALCON

The proposals detailed in Section 6.4 are now put into practice, relying on already existing evaluations in the literature to measure the FLC capability. The concealment capability for each NALU type is be measured, and then all concealment techniques are combined together to analyze the impact of BALCON.

#### 6.5.2.1 BL & Temporal Enhancing

**BASE LAYER** Keränen et al. [107] evaluated many video FLC techniques on different loss patterns. For example, when using frame-copy for the concealment on 10% loss ratio, the PSNR value drops to about 50% of its error-free original value. Now to determine the concealable amount of loss by the frame-copy technique, the minimum acceptable video quality drop must be set. For instance, if 75% of the PSNR value is taken as an acceptable one, it will hold $C_{FL} = 5\%$.

Furthermore, for the BL, the SnW routing protocol is associated with 16 copies as presented before. Hence, from Figure 6.2 we can extract that $C_{ND} = 0.8$.

By applying these values into Equation 6.4, the threshold loss value will be then:

$$l_{threshold} = \frac{0.05}{1 - 0.8} = 0.25 = 25\%$$

This is interpreted as: when the loss ratio is no more than 25%, the concealment process for the BL NALUs starts, with the network demands first and FLC then.
**TEMPORAL ENHANCING** The BL and temporal enhancing units are subject to the same video FLC evaluation: C<sub>FL</sub> = 5%. Besides, for the temporal EL, the SnW routing protocol is associated with 8 copies as presented before. Hence, from Figure 6.2 we can extract that C<sub>ND</sub> = 0.76. By applying these values into Equation 6.4, the threshold loss value will be then:

$$l_{threshold} = \frac{0.05}{1 - 0.76} = 0.208 = 20.8\%$$

This holds that when the loss ratio is no more than 20.8%, the concealment process for the temporal enhancing NALUs may start, with the network demands first and FLC then.

### 6.5.2.2 Spatial Enhancing

Chen et al. [106] evaluated the FLC technique on wider loss patterns including more NALUs types. Loss in spatial-enhancing NALUs is less sensitive than in the BL, however the concealment is affected by the loss on both levels. Using an inter-layer technique (BLSkip) on a loss of 10% in the spatial EL drops the PSNR value of the concealed video to about 85%. However, this technique assumes that the corresponding BL frame is correctly present. The same loss causes a PSNR drop equal to 75% of its original value when using an intra-layer technique. By accepting these values as the minimum acceptable video quality drop, we can set C<sub>FL</sub> = 10%.

For the spatial ELs, SnW uses 4 copies. So from Figure 6.2 we find C<sub>ND</sub> = 0.66, which is to be applied into Equation 6.4:

$$l_{threshold} = \frac{0.1}{1 - 0.66} = 0.294 = 29.4\%$$

As before, when the delivery allows to get < 29.4% loss, the concealment process for the spatial enhancing NALUs may start.

### 6.5.3 The Complete Functionality of BALCON

#### 6.5.3.1 Impact on SVC

To clearly show the impact of BALCON, it is more efficient to build on the experiment from Section 5.4.1, where NALUs are transmitted in an OppNet scenario. We recall results from Figure 5.3 again in Figure 6.3.

The shown high delivery failure is mainly because of the partial loss in the big set of composing units, causing whole layers to be useless. Only a playout availability of 58% could have been concluded, with a dominant limited BL quality. Whereas 42% of the simulation rounds had no video playout at all.

By analyzing the cases of an undelivered BL (no playout) in that experiment, it is found that failures were caused by 10-20% partial loss. That is, for a given example
<figure><img src="image_56.png" /><figcaption>Figure 6.3: Transmission of NAL-Units</figcaption></figure>

undelivered BL, 80-90% of its composing NALUs are reported to be successfully delivered. But without a concealment mechanism, this small fraction of partial loss leads the delivery of the corresponding BL to fail. Similarly, limited higher quality is caused by about 30% partial loss in higher OPs. An example of an undelivered BL and an undelivered EL is depicted in Figure 6.4 as a progress over time.

<figure><img src="image_57.png" /><figcaption>Figure 6.4: Delivery Progression of an Undelivered BL and an Undelivered EL</figcaption></figure>

Time instances when the concealment process starts, can also be derived from Figure 6.4. As calculated in Section 6.5.2, $l_{threshold} = 25\%$ for the BL. This is equivalent to a delivery of 75%, which is reached around the 180th minute. For the spatial EL, $l_{threshold} \approx 30\% \Rightarrow delivered \approx 70\%$, which corresponds to the 240th minute. Consequently, after experimentally applying BALCON, new results are reported in Figure 6.5.

Compared to Figure 6.3, the quality distribution is enhanced to reflect a 100% playout availability and an upgraded quality level. But on the other hand, results regarding the delay show no refinement, because of the extra delay generated by the network demands approach.

Nevertheless, since we take the statical approach to calculate the threshold values in the experiments, these values can not be generalized. The capability thresholds dif-
<figure><img src="image_58.png" /><figcaption>Figure 6.5: Transmission of NAL-Units + Applying BALCON</figcaption></figure>

fer from one application to another, because they depend on many parameters like: video concealment technique, video content, desired PSNR values and network settings. However, the statistical measurement serve in the presented experiments to show the applicability and functionality of the BALCON mechanism in our video dissemination scheme in OppNets.

### 6.5.3.2 Varying The Starting Point

This section will study the influence of starting the concealment process earlier or later than the computed threshold.

For instance, for the BL case in the last experiments, the computed loss threshold is: $l_{threshold} = 25\%$. By letting BALCON start at this threshold value, we argue that it will conceal all of the loss and reach a full delivery ratio, because the amount of loss corresponds to the concealment capability of BALCON (i.e. 25% as calculated in Section 6.5.2.1). Now, if BALCON starts earlier, for example when delivery = 70% ⇒ loss = 30% : by adding the BALCON capability, the delivery ratio may reach 70+25=95%. Hence, the full delivery ratio could not have been reached. Moreover, as Equation 6.2 suggests, when starting earlier the distribution of the m messages by the SnW routing protocol will not reach the upper limit M. Therefore, only $m < M$ nodes will have copies then, which holds a lower servability value and hence also a lower $C_{ND}$ capa-bility.

On the other hand, starting later at a delivery level higher than the computed threshold is not feasible, because either the higher level will not be reached, or if reached there will be no benefit but only a higher delay. For example, if BALCON waits until delivery = 80% ⇒ loss = 20%, then (if this level is reached) BALCON is already more capable than the remaining amount of loss.

Consequently, starting the concealment process at arbitrary points is not recommended, because either a full delivery ratio will not be reached, or an extra delay will be waste-fully added.
### 6.5.3.3 Validation and Comparison

To the best of our knowledge, loss recovery in *OppNets* is mainly addressed by applying network and channel coding techniques, as already given in Section 3.4.
Nguyen et al. [110] use Reed-Solomon Forward Error Correction (FEC) on a loss ratio of 20%. The recovered videos report PSNR drops of 77-79% of their original values. Whereas *BALCON* reaches better quality levels at higher loss ratios, i.e. 75% PSNR quality at 25% loss for the BL, and 75-85% PSNR quality at 20.8-29.4% loss for higher enhancing levels. Besides, with regard to the delay results, no direct numerical comparisons can be drawn because of the many different setting parameters. Instead, we try to estimate the results as in Section 4.6. To reach a playout availability ratio of 100%, the authors technique takes longer because of the prolonged distribution of packets by the source. However, *BALCON* also involves extra delay through the network-demands technique, since it waits for the demands to be distributed and the responses to be received back.

A better perceived quality could have been achieved by Schierl et al. [73], and a lower delay by Sardari et al. [109], both by using multiple sources to distribute the FEC code blocks. However, this is not applicable in our case, because of the need for a coordination between the source nodes, which is not available in *OppNets*.

## 6.6 SUMMARY

This chapter is intended to implement and study the feasibility of a backward loss concealment mechanism (shortly named as *BALCON*) for scalable videos in *OppNets*. We proposed a solution at the receiver side, that is able to conceal loss below a specific threshold. *BALCON* applies a composite concealment solution, that is based on video Frame Loss error-Concealment (FLC) techniques as well as network demands. Experiments of an example scenario showed the applicability and feasibility of our proposal. In the experimented example, *BALCON* was capable of concealing a loss amount of 25% in the BL and 20.8%-29.4% in higher levels. However, these derived threshold values in the experiments can not be generalized, since they may differ from one application to another. Threshold values depend on many parameters like: video concealment technique, video content, desired PSNR values and network settings, under which there exist many other parameters. Nevertheless, in sparse environments and applications that accept some quality drop, the *BALCON* mechanism can successfully be applied to conceal an amount of loss similar to the results of our example experiment.

* * *
<figure><img src="image_59.png" /></figure>
Part III

CONCLUSION

Chapter 7: Conclusion and Future Work.

Now this is not the end.
It is not even the beginning of the end.
But it is, perhaps, the end of the beginning.

— Winston Churchill
<figure><img src="image_60.png" /></figure>
# CONCLUSION AND FUTURE WORK

This chapter concludes the thesis by first overviewing the defined context of work and the addressed issues. Then, it highlights the made contributions. And lastly, it suggests possible directions of further improvements and future research.

## 7.1 OVERVIEW

Through the massive growth of handheld devices both quantitatively and qualitatively, a new ad-hoc networking pattern has been enabled, by which different devices may communicate, interact and share content. The general idea behind ad-hoc networking is to offer a decentralized connection, which decouples the communicating nodes from access points and base stations. When two nodes are physically close enough to be in the communication range of each other, they can substitute the data exchange through a centralized infrastructural entity with an ad-hoc short-range alternative. A Mobile Ad-hoc Network (MANET) communication might have a longer path than a direct source-destination data delivery. Data may hop through multiple intermediary nodes to reach the destination. Furthermore, Opportunistic Networks (OppNets) induct more tolerance into the network functionality with regard to nodes mobility and resulting disconnection. Using the Store-Carry-Forward (SCF) paradigm, intermediary nodes are allowed to store received messages and carry them until having the opportunity to forward them again.

Consequently, OppNets support indirect end-to-end data delivery and possess a dynamic network topology. Nevertheless, because forwarding opportunities depend on nodes' mobility, communication disruptions and uncertain data delivery are dominant. These characteristics made the usual use case scenarios of OppNets limited to the exchange of small messages, in relation for example to traffic notifications or disaster alarms. However, the available capabilities of the handheld devices created possible scenarios to share User-Generated Content (UGC) of multimedia, where users need to lay infrastructural means aside and switch to a multihop ad-hoc alternative. Examples are the cases of absence, high costs or undesirable censorship of the infras-
structural networks.

The challenge of a video dissemination application is that *OppNets* would expose large-sized video data to partial loss, which is assumed to make any received parts useless because of the continuity of the medium. Despite the impossibility of realizing a streaming application with hard time constraints in this context, we propose a dissemination scheme that supports the *"download-and-play"* use-case. This scheme is made up of two solution folds:

* Delivery enhancement at the sender's side, depending on data partitioning and adaptive data volumes tuning.

* Loss concealment at the receiver's side to overcome small fractions of partial losses.

The objective of the scheme is an enhanced video viewing experience, by the means of playout delay, delivery ratio that determines the maximum achievable quality, and the overhead that is applied on the network.

The Opportunistic Network Environment (ONE) simulator is configured to experiment the proposed solutions in a simulated environment. A series of experiments are preformed, concluding through the gathered results the applicability of the proposed video dissemination scheme within the frame of *OppNets*.

## 7.2 CONTRIBUTIONS

The thesis presented three contributions in Chapters 4, 5 and 6 for the proposed video dissemination scheme.

**FIRST**, the scheme applies the Scalable Video Coding (SVC) technique, which divides videos into scalable layers of smaller volumes, holding different levels of quality. The dependency among layers marks them with multiple unequal importance degrees. This property is exploited to prioritize the video layers and route them with unequal degrees of redundancy proportionally to their importance. Consequently, playout delay is reduced by stressing on faster and more reliable delivery of layers with lower quality (but higher importance). Furthermore, an evaluation metric for the viewing experience is defined, involving the delivery delay, video quality and network overhead.

**SECOND**, the scheme goes deeper in the direction of data partitioning, by not sticking to the scalable layers with predetermined sizes. Instead, data volumes are tuned adaptively with regard to the continuously changing network conditions of *OppNet*. Thus, the scheme enables each node to record a history of environmental information, and use this history then to predict future forwarding opportunities, and optimize the data volumes accordingly.
THIRD, the scheme involves the destination node by implementing a feasible con-
cealment mechanism at its side, with the capability to react to an amount of
loss. The implemented concealment mechanism functions in a composite man-
ner with a twofold profit: a content-based video frame loss concealment, and a
network-based loss concealment through demands, that are initiated and cast
in search for the missing units from other nodes in the network.

* * *

7.3 FUTURE WORK

Due to many constraints, for instance in time and deployment, it is hard to meet
perfection in research. Consequently, many aspects in the research work remain un-
touched or imperfect. Therefore, this section presents future visions of the thesis,
which can promise further improvements or open the door for new domains of re-
search.

7.3.1 Further Improvements

Future prospects to further improve this work can be observed from the perspective
of the identified contributions in Chapter 1.

C₁ & C₂ The first two contributions focused on delivery enhancement at the sender's side, depending on data partitioning and adaptive data volumes tunning. Aspects that could have been addressed in a better or more advanced way include:

* Real testbeds or real mobility traces: Despite their high costs, the real testbeds are the most reliable approach to perform experiments and collect real-world-driven statistics. However, under the difficult applicability of real testbeds, using real mobility traces helps to give an insight about how the proposed solution would look like when actually applied.

* Dynamic selection of Operating Points (OPs): The selection of OPs to overlay the SVC layers (as given in Section 4.3.1.4) can be done in a more advanced and dynamic way with regard to the resulting viewing experience, based on the size and the video content.

C₃ The last contribution tackled a loss concealment mechanism at the receiver’s side to overcome small fractions of partial losses. The functionality of the mechanism is based on static calculations to measure the concealment capabilities of the used techniques, as given in Section 6.4. Thus, a self-adaptive loss concealment mecha-
nism is very encouraged to be addressed. That is, the mechanism can estimate those
capabilities at run-time, based on the video content and the network conditions.

7.3.2 *New Domains of Research*

Beside further improvements of already existing topics, complete new domains of research can also be initialized as extensions to this work. Examples basically include:

* Security: In *OppNets*, security is a very important and wide topic, and can be addressed from different aspects, as for instance:

- Privacy: The identity of the communicating nodes must be kept hidden at the communication interface, as well as within the exchanged content.

- Forgery: Prevent unwanted or irrelevant content from flowing in the network.

* Hybrid (mesh) networks: It is very interesting to study the impact of the proposed solutions when applied in a network that can switch between the *OppNet* and the infrastructural communication domains. The advantages of both types of networks can then combined, and new challenges are introduced, like:

- Data distribution and consumption control: Decide for which network to use when sending specific data.

- Further security challenges, when using an unreliable infrastructural network.

* * *
Part IV

APPENDIX

Appendix A: Technical Details

> *The most important property of a program is,
> whether it accomplishes the intention of its user.*

— C.A.R. Hoare
<figure><img src="image_61.png" /></figure>
# TECHNICAL DETAILS

This appendix overviews the essential technical material that enables delivering the scientific contribution of this thesis. The technical material includes instructions, implementations and techniques from the following addressed aspects:

* Scalable Video Coding (SVC) encoding and decoding

* Computations with regard to video quality

* Functionality adaptation of the open-source simulator

## A.1 SVC ENCODER/DECODER

This section highlights how to configure and SVC-encode a raw video using the Joint Scalable Video Model (JSVM) tools. As an input for the examples below, we consider a raw video file "bus_352x288_30.yuv", which has a spatial resolution of 352 x 288 and a frame rate of 30 frame per second (fps).

### A.1.1 Encoder

Using the JSVM library, SVC encoding is simply performed from the command line using the following instruction:

```
> H264AVCEncoderLibTestStatic.exe -pf main.cfg
```

<caption>Listing A.1: SVC Encoding Instruction</caption>

Where the whole configuration has to be in the text file "main.cfg". An overview of the used main configuration file is given in Listing A.2.

It is noticed that the main configuration file is fed with other ".cfg" files, which determine the spatial and Signal-to-Noise Ratio (SNR) scalability layers in the output video file "coded.264", whereas the number of temporal layers is dependent
<table><caption>Listing A.2: SVC Encoding: JSVM Main Configuration File</caption><tr><td>OutputFile</td><td>..\vid\bus\coded.264</td><td># Bitstream file</td></tr><tr><td>FrameRate</td><td>30.0</td><td># Maximum frame rate [Hz]</td></tr><tr><td>FramesToBeEncode</td><td>150</td><td># Number of frames (at input frame rate)</td></tr><tr><td>GOPSize</td><td>4</td><td># GOP Size (at maximum frame rate)</td></tr><tr><td>CgsSnrRefinement</td><td>1</td><td># SNR refinement as 1: MGS; 0: CGS</td></tr><tr><td>EncodeKeyPictures</td><td>1</td><td># Key pics at T=0 (0:none, 1:MGS, 2:all)</td></tr><tr><td>MGSControl</td><td>1</td><td># ME/MC for non-key pictures in MGS layers<br /># (0:std, 1:ME with EL, 2:ME+MC with EL)</td></tr><tr><td>BaseLayerMode</td><td>0</td><td># Base layer mode (0,1: AVC compatible,<br /># 2: AVC w subseq SEI)</td></tr><tr><td>SearchMode</td><td>4</td><td># Search mode (0:BlockSearch, 4:FastSearch)</td></tr><tr><td>SearchRange</td><td>32</td><td># Search range (Full Pel)</td></tr><tr><td>NumLayers</td><td>4</td><td># Number of layers</td></tr><tr><td>LayerCfg</td><td>..\vid\bus\layer0.cfg</td><td># Layer configuration file</td></tr><tr><td>LayerCfg</td><td>..\vid\bus\layer1.cfg</td><td># Layer configuration file</td></tr><tr><td>LayerCfg</td><td>..\vid\bus\layer2.cfg</td><td># Layer configuration file</td></tr><tr><td>LayerCfg</td><td>..\vid\bus\layer3.cfg</td><td># Layer configuration file</td></tr></table>

on the set "GOPSize" parameter<fnref n="1" />. Namely, there will be $log(GOPSize) + 1 = \log(4) + 1 = 3$ temporal layers for the given configuration file.

#### A.1.1.1 Spatial Scalability

To achieve spatial scalability, down-sampled versions of the original raw video must be manually generated using JSVM's "DownConvertStatic" tool. For instance, to down-sample the original video "bus_352x288_30.yuv" by a ratio of 2, the following instruction is used:

> DownConvertStatic.exe 352 288 bus_352x288_30.yuv 176 144 bus_176x144_30.yuv

Then both files "bus_352x288_30.yuv" and "bus_176x144_30.yuv" are used as input files in the complementary configuration files of the scalability layers. This is shown in Listings A.3 and A.4.

<table><caption>Listing A.3: SVC Encoding: JSVM Configuration File layero.cfg (basic)</caption><tr><td>InputFile</td><td>..\vid\bus_176x144_30.yuv</td><td># Input file</td></tr><tr><td>SourceWidth</td><td>176</td><td># Input frame width</td></tr><tr><td>SourceHeight</td><td>144</td><td># Input frame height</td></tr><tr><td>FrameRateIn</td><td>30</td><td># Input frame rate [Hz]</td></tr><tr><td>FrameRateOut</td><td>30</td><td># Output frame rate [Hz]</td></tr></table>

<footnote n="1">¹ Refer to Section 2.3.2 for more details.</footnote>
<table><caption>Listing A.4: SVC Encoding: JSVM Configuration File layer2.cfg (basic)</caption><tr><td>InputFile</td><td>..\vid\bus_352x288_30.yuv</td><td># Input file</td></tr><tr><td>SourceWidth</td><td>352</td><td># Input frame width</td></tr><tr><td>SourceHeight</td><td>288</td><td># Input frame height</td></tr><tr><td>FrameRateIn</td><td>30</td><td># Input frame rate [Hz]</td></tr><tr><td>FrameRateOut</td><td>30</td><td># Output frame rate [Hz]</td></tr></table>

### A.1.1.2 SNR Scalability

The SNR scalability depends on the fixed quantization parameters in the layers configuration files. To have multiple SNR scalability layers in a given spatial resolution, the corresponding layer configuration file has to be repeated with different quantization parameters. In the last example, `layer1.cfg` is repeated from `layer0.cfg` to have a further SNR scalability dimension at the spatial resolution of 176 × 144. Consequently, the two complete configuration files are given in the Listings A.5 and A.6.

<table><caption>Listing A.5: SVC Encoding: JSVM Configuration File layer0.cfg</caption><tr><td>InputFile</td><td>..\vid\bus_176x144_30.yuv</td><td># Input file</td></tr><tr><td>SourceWidth</td><td>176</td><td># Input frame width</td></tr><tr><td>SourceHeight</td><td>144</td><td># Input frame height</td></tr><tr><td>FrameRateIn</td><td>30</td><td># Input frame rate [Hz]</td></tr><tr><td>FrameRateOut</td><td>30</td><td># Output frame rate [Hz]</td></tr><tr><td>QP</td><td>34</td><td># Quantization parameters</td></tr><tr><td>MeQP0</td><td>32</td><td># QP for mot. est. / mode decision (stage 0)</td></tr><tr><td>MeQP1</td><td>32</td><td># QP for mot. est. / mode decision (stage 1)</td></tr><tr><td>MeQP2</td><td>32</td><td># QP for mot. est. / mode decision (stage 2)</td></tr><tr><td>MeQP3</td><td>32</td><td># QP for mot. est. / mode decision (stage 3)</td></tr><tr><td>MeQP4</td><td>32</td><td># QP for mot. est. / mode decision (stage 4)</td></tr><tr><td>MeQP5</td><td>32</td><td># QP for mot. est. / mode decision (stage 5)</td></tr></table>

<table><caption>Listing A.6: SVC Encoding: JSVM Configuration File layer1.cfg</caption><tr><td>InputFile</td><td>..\vid\bus_176x144_30.yuv</td><td># Input file</td></tr><tr><td>SourceWidth</td><td>176</td><td># Input frame width</td></tr><tr><td>SourceHeight</td><td>144</td><td># Input frame height</td></tr><tr><td>FrameRateIn</td><td>30</td><td># Input frame rate [Hz]</td></tr><tr><td>FrameRateOut</td><td>30</td><td># Output frame rate [Hz]</td></tr><tr><td>QP</td><td>28</td><td># Quantization parameters</td></tr><tr><td>MeQP0</td><td>28</td><td># QP for mot. est. / mode decision (stage 0)</td></tr><tr><td>MeQP1</td><td>28</td><td># QP for mot. est. / mode decision (stage 1)</td></tr><tr><td>MeQP2</td><td>28</td><td># QP for mot. est. / mode decision (stage 2)</td></tr><tr><td>MeQP3</td><td>28</td><td># QP for mot. est. / mode decision (stage 3)</td></tr><tr><td>MeQP4</td><td>28</td><td># QP for mot. est. / mode decision (stage 4)</td></tr><tr><td>MeQP5</td><td>28</td><td># QP for mot. est. / mode decision (stage 5)</td></tr></table>
The same applies for the second spatial resolution of 352 × 288, where the configuration file "layer3.cfg" is repeated from "layer2.cfg" to have a further SNR scalability dimension at the corresponding spatial resolution. Consequently, the two complete configuration files are given in the Listings A.7 and A.8.

<table><caption>Listing A.7: SVC Encoding: JSVM Configuration File layer2.cfg</caption><tr><td>InputFile</td><td>..\vid\bus_352x288_30.yuv</td><td># Input file</td></tr><tr><td>SourceWidth</td><td>352</td><td># Input frame width</td></tr><tr><td>SourceHeight</td><td>288</td><td># Input frame height</td></tr><tr><td>FrameRateIn</td><td>30</td><td># Input frame rate [Hz]</td></tr><tr><td>FrameRateOut</td><td>30</td><td># Output frame rate [Hz]</td></tr><tr><td>QP</td><td>38</td><td># Quantization parameters</td></tr><tr><td>MeQP0</td><td>38</td><td># QP for mot. est. / mode decision (stage 0)</td></tr><tr><td>MeQP1</td><td>38</td><td># QP for mot. est. / mode decision (stage 1)</td></tr><tr><td>MeQP2</td><td>38</td><td># QP for mot. est. / mode decision (stage 2)</td></tr><tr><td>MeQP3</td><td>38</td><td># QP for mot. est. / mode decision (stage 3)</td></tr><tr><td>MeQP4</td><td>38</td><td># QP for mot. est. / mode decision (stage 4)</td></tr><tr><td>MeQP5</td><td>38</td><td># QP for mot. est. / mode decision (stage 5)</td></tr></table>

<table><caption>Listing A.8: SVC Encoding: JSVM Configuration File layer3.cfg</caption><tr><td>InputFile</td><td>..\vid\bus_352x288_30.yuv</td><td># Input file</td></tr><tr><td>SourceWidth</td><td>352</td><td># Input frame width</td></tr><tr><td>SourceHeight</td><td>288</td><td># Input frame height</td></tr><tr><td>FrameRateIn</td><td>30</td><td># Input frame rate [Hz]</td></tr><tr><td>FrameRateOut</td><td>30</td><td># Output frame rate [Hz]</td></tr><tr><td>QP</td><td>34</td><td># Quantization parameters</td></tr><tr><td>MeQP0</td><td>34</td><td># QP for mot. est. / mode decision (stage 0)</td></tr><tr><td>MeQP1</td><td>34</td><td># QP for mot. est. / mode decision (stage 1)</td></tr><tr><td>MeQP2</td><td>34</td><td># QP for mot. est. / mode decision (stage 2)</td></tr><tr><td>MeQP3</td><td>34</td><td># QP for mot. est. / mode decision (stage 3)</td></tr><tr><td>MeQP4</td><td>34</td><td># QP for mot. est. / mode decision (stage 4)</td></tr><tr><td>MeQP5</td><td>34</td><td># QP for mot. est. / mode decision (stage 5)</td></tr></table>

### A.1.2 Decoder and Player

Although all of the experiments are performed on a simulator, and the receiving nodes receive videos only virtually, a video decoder and player is needed to test the scalability and practice the applicability of SVC. To decode and play SVC coded videos, we use the OpenSvc Decoder (OSD) [124], which is an open-source library that is built into the "mplayer" open-source video player. OSD with mplayer give the possibility at run time to change video parameters as the frame rate and resolution.

Playing a video using the mplayer can be done by executing the following instruction from the command line:
> mplayer coded.264 -fps 30

Where "coded.264" is the name of the encoded video file. The scalability options can be changed then during the decoding process using a set of "hot-keys" as described by Blestel and Raulet [124].

Besides, it is also possible to play a raw video file using the same `mplayer` open-source video player. This is done as the following:

> mplayer rawVid.yuv -demuxer rawvideo -rawvideo w=352:h=288:fps=7.5:format=i420

Where the characteristics of the video (e.g. width, height, frame rate, ..etc.) must be known in advance and given to the `mplayer` command.

* * *
## A.2 PSNR CALCULATION FOR SVC VIDEOS

### A.2.1 Problem Statement

As outlined in Chapter 2, for the objective measurement of video quality, the Peak Signal-to-Noise Ratio (PSNR) function is calculated for each frame of the video with regard to the Mean Square Error (MSE), then the average is taken over all values:

$$MSE = \frac{1}{W \cdot H} \sum_{x}^{W} \sum_{y}^{H} [Y_{r}(x, y) - Y_{p}(x, y)]$$

$$PSNR = 10 \times \log_{10} \frac{I^2}{MSE}$$

$$PSNR_{total} = \frac{1}{N} \sum_{x}^{N} PSNR$$

where

* W, H : Frame's width and height

* Yr, Yp : Luminance value of the reference/processed frame in pixel (x, y)

* I : Maximum luminance value

* N : Number of frames in the video

For multistream videos, PSNR has to be calculated for each of the substreams separately. The problem is that each substream will have different values for the W, H and N parameters from the reference video, depending on the spatial and temporal resolution. The reference video has the upper bound values for those parameters. A substream of a lower spatial layer will have smaller W, H values, whereas substream of a lower temporal layer will have a smaller N value.

As the JSVM implementation provides all necessary tools to deal with SVC streams, it also includes a tool to compute PSNR values for the different layers upon encoding. However, the computed PSNR values lack precision, as shown in the result snapshot in Figure A.1.

Among 2 spatial resolutions and 5 temporal resolutions in this example, it is noticed that lower temporal layers have higher PSNR values. The inaccurate computation of PSNR that is done by JSVM will be justified in the next section.
<figure><img src="image_62.png" /><figcaption>Figure A.1: Snapshot of PSNR Values using JSVM [2]</figcaption></figure>

### A.2.2 The Limitation of PSNR Computation in JSVM

#### A.2.2.1 Difference in Temporal Resolution

When the tested video has a lower frame rate than the reference, JSVM ignores the extra frames of the reference video. Hence, the number of performed single PSNR computations is equal to the smaller number of frames of the tested video, as shown in Figure A.2. The smaller number of PSNR computations results in a better PSNR than expected.

<figure><img src="image_63.png" /><figcaption>Figure A.2: The Limitation of JSVM's PSNR Computation Due to Different Temporal Resolutions</figcaption></figure>

Sohn et al. [118] suggest how the computation should efficiently be performed. The video with the lower temporal resolution must duplicate its frames a number of times, so that both videos end up having the same number of frames. This is depicted in Figure A.3. Consequently, the number of single PSNR computations will be equal then to the larger number of frames, and the total PSNR value can be calculated more reliably than in the first case.
<figure><img src="image_64.png" /><figcaption>Figure A.3: Solution to Temporal Resolution Difference</figcaption></figure>

#### A.2.2.2 Difference in Spatial Resolution

When the tested video has a lower spatial resolution than the reference video, JSVM downsamples the reference video to fit the smaller one, then it performs the PSNR computation in the lower resolution as shown in Figure A.4a.

<figure><img src="image_65.png" /><figcaption>Figure A.4: The Limitation of JSVM's PSNR Computation Due to Different Spatial Resolutions: Problem & Solution</figcaption></figure>

This also results in a better PSNR value than expected, because of the degradation applied to the reference video when it is downsampled. Sohn et al. [118] claim that to yield a more reliable computation, the tested video is the one that must be resized (upsampled) to the resolution of the reference video. This solution is depicted in Figure A.4b.
### A.2.3 Implementing the Proposed Solutions

In this section, the above mentioned techniques are practically implemented. For this, we assume the presence of a raw video file "ref.yuv", and an SVC-encoded version of it "encoded.264". No matter how many layers does the SVC video contain, we will perform the PSNR computation on the Base Layer (BL), and the same can be applied on any other layer. PSNR computation is summarized by the following steps:

1. Ensure that we know the characteristics of each layer:
   > BitStreamExtractorStatic .\vid\encoded.264

2. Extract the current target layer (base layer in this case)
   > BitStreamExtractorStatic .\vid\encoded.264 .\vid\L0.264 -sl 0

3. Decode the extracted layer into the raw video format
   > H264AVCDecoderLibTestStatic .\vid\L0.264 .\vid\x0.yuv

4. Scale the resulted raw video temporally and spatially to match the reference video. This is done using ffmpeg, the free video manipulation tool <fnref n="2" />
   > ffmpeg.exe -r 7.5 -s 176x144 -i .\vid\x0.yuv -r 30 -s 352x288 xx0.yuv
   Where 7.5 and 176x144 are the initial values of the frame rate and spatial resolution, and 30 and 352x288 are the target values.

5. Now PSNR can be calculated between the scaled video and the reference
   > PSNRStatic 352 288 .\vid\ref.yuv .\vid\xx0.yuv

Where BitStreamExtractorStatic, H264AVCDecoderLibTestStatic and PSNRStatic are built-in tools in the installed JSVM library.

* * *

<footnote n="2">² http:// Committee of the International Standardization Organization</footnote>
## A.3 FUNCTIONALITY ADAPTATION OF THE O.N.E. SIMULATOR

### A.3.1 Analysis of Adaptation Necessity

#### A.3.1.1 Problem Statement

As presented in Section 2.2.2, Opportunistic Network Environment (ONE) is an open-source Java-based simulator, designed to implement and evaluate applications in Delay Tolerant Network (DTN) and Opportunistic Network (OppNet). The simulator can be configured with a wide range of parameters using an external text file. Configurable parameters include, for example: simulation duration, communication interface, nodes, environment, mobility model, routing protocol, messages and output reports. However, despite the powerful configurability, newly proposed functionalities can not be implemented using the textual configuration parameters. But rather, the source-code of the simulator has to be reviewed, adapted and rebuilt in order to apply core changes.

#### A.3.1.2 Body Structure

One of the few disadvantages of the ONE simulator is the lack of a detailed documentation. Therefore, a reverse-engineering analysis of the source-code had to be performed in order to analyze the structure of the simulator's body, and hence determine where the implementation of any new functionality has to go in. A short overview of the basic classes that are invoked when starting a simulation is given in the diagram in Figure A.5.

1. "DTNSim" is the main class that starts "DTNSimTextUI" in the batch mode (or "DTNSimGUI" in the graphical mode), which are inherited from "DTNSimUI"

2. "DTNSimUI" creates a new "SimScenario", which by itself is responsible for creating the hosts (nodes)

3. "DTNSimUI" calls `warmUp()` of "World", which is responsible for the movement of hosts

4. "DTNSimTextUI" calls `update()`, which is passed to the "ExternalEvent" generator

5. "MsgCreateEvent" passes the task of message creation to the hosts, which delegate that to the corresponding routing protocol (for example in the diagram: Spray-and-Wait (SnW))

This sequence is important to follow the execution of the simulator, and determine where the adaptation has to take place.
The "initialNrofCopies" parameter is read from the configuration file. Instead, we propose to ignore the value from the configuration file and overwrite the number of copies depending on the names of the messages.

```java
public boolean createNewMessage(message msg) {
    String mId = msg Id();
    switch (mId) {
        case "??": this initialNrofCopies = ??; break;
        ...
    }
    makeRoomForNewMessage(msgSIZE());
    msg.setTtl(this.msgTtl);
    msg prop(MSG_COUNT PROPERTY, new Integer(initialNrofCopies));
    addToMessages(msg, true);
    return true;
}
```

<caption>Listing A.10: Prioritized Message Creation in SnW</caption>

Assuming that the names of the messages are predefined, the "switch" block can be filled with the corresponding redundancy factors for the different messages.

### A.3.3 Adaptive Packetization & Size Tunning

#### A.3.3.1 Update The History of Contact Times

To keep track of the contact times history, as proposed in Chapter 5, we provided the "DTNHost" class with the following member variable:

```java
public List Double> contactTime;
```

This list has to be updated after each contact between two nodes, at each of them. To detect connections and disconnections between nodes, the "ContactTimesReport" report class implements the necessary listeners. Consequently, we add the lines of code<fnref n="3" /> that are presented in Listing A.11.

After updating the lists at the two corresponding hosts, a host is ready to packetize its messages according to the newly updated values when coming in contact with a new host.

#### A.3.3.2 Packetization

The `packetizeMessages()` function must be implemented within the corresponding routing protocol, because it will affect the list of messages (buffer) that are ready to be

<footnote n="3">³ For simplicity, some code blocks are described as pseudo-code in "`/* .. */`" comments.</footnote>
```java
public void hostsDisconnected(DTNHost host1, DTNHost host2) {
    /* original code */

    host1.contactTime.add ci.getConnectionTime());
    host2.contactTime.add ci.getConnectionTime());
}
```

```java
public void hostsConnected(DTNHost host1, DTNHost host2) {
    /* original code */

    host1.getRouter().packetizeMessages();
    host2.getRouter().packetizeMessages();
}
```

<caption>Listing A.11: Update Contact Times on Hosts Disconnections</caption>

The implementation is an identical interpretation of the algorithm in Listing 5.1 in Chapter 5.

#### A.3.3.3 De-Packetization

A de-packetization procedure must take place after forwarding a message at both sender and receiver nodes, in order to extract packetized sub-messages to update their parameters, check their reception as well as prepare them for a new packetization process that is subject to the updated parameters. After a message forwarding, the sender ("host1") calls the function *transferDone*, and the receiver ("host2") calls the function *messageTransferred* from the class of the corresponding routing protocol. Both functions are adapted as in Listings A.12 and A.13.

```java
protected void transferDone(Connection con) {
    String msgId = con().getId();
    Message pM =ATSMessage(msgId);
    // pM is a packetizing message, loop over its sub-messages
    for (Message m : pM) {
        addToMessages(m, true);
    }
    // remove pM from buffer
    removeFromMessages(pM Id());
}
```

<caption>Listing A.12: De-Packetize at Sender</caption>
```java
public Message messageTransferred(String id, DTNHost from) {
    Message pM = super.messageTransferred(id, from);
    // pM is a packetizing message, loop over its sub-messages
    for (Message m : pM) {
        /*
         * check if this host is the final recepient
         */
        addToMessages(m, true);
    }
    // remove pM from buffer
    removeFromMessages(pM Id());
}
```

<caption>Listing A.13: De-Packetize at Receiver</caption>

* * *
BIBLIOGRAPHY

[1] Ari Keränen, Jörg Ott, and Teemu Kärkkäinen. The one simulator for dtn protocol evaluation. In *SIMUTools '09: Proceedings of the 2nd International Conference on Simulation Tools and Techniques*. ICST, 2009. ISBN 978-963-9799-45-5.

[2] Julien Reichel, Heiko Schwarz, and Mathias Wien. Joint scalable video model 11 (jsvm 11). *Joint Video Team, Doc. JVT-X202*, page 23, 2007.

[3] Mark Weiser. The computer for the 21st century. *Scientific american*, 265(3): 94–104, 1991.

[4] Imrich Chlamtac, Marco Conti, and Jennifer J-N Liu. Mobile ad hoc networking: imperatives and challenges. *Ad hoc networks*, 1(1):13–64, 2003.

[5] Luciana Pelusi, Andrea Passarella, and Marco Conti. Opportunistic networking: data forwarding in disconnected mobile ad hoc networks. *Communications Magazine, IEEE*, 44(11):134–141, 2006.

[6] Kevin Fall. A delay-tolerant network architecture for challenged internets. In *Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications*, pages 27–34. ACM, 2003.

[7] Merza Klaghstan, David Coquil, Nadia Bennani, Harald Kosch, and Lionel Brunie. Enhancing video viewing-experience in opportunistic networks based on svc, an experimental study. In *2013 IEEE 24th International Symposium on Personal Indoor and Mobile Radio Communications (PIMRC)*, pages 3563–3567. IEEE, 2013.

[8] Merza Klaghstan, Nadia Bennani, David Coquil, Harald Kosch, and Lionel Brunie. Contact-based adaptive granularity for scalable video transmission in opportunistic networks. In *2014 International Wireless Communications and Mobile Computing Conference (IWCMC)*, pages 773–778. IEEE, 2014.

[9] Merza Klaghstan, David Coquil, Nadia Bennani, Harald Kosch, and Lionel Brunie. "balcon: Backward loss concealment mechanism for scalable videos in opportunistic networks. In *2016 IEEE 27th International Symposium on Personal Indoor and Mobile Radio Communications (PIMRC)*, pages 1789–1795. IEEE, 2016.
[10] Scott Corson and Joseph Macker. Mobile ad hoc networking (manet): Routing protocol performance issues and evaluation considerations. *RFC 2501*, 1999.

[11] Bhaskar Krishnamachari, Stephen B Wicker, Ramon Bejar, and Marc Pearlman. Critical density thresholds in distributed wireless networks. *Communications, information and network security*, 1:15, 2002.

[12] M Ali Rostami, Azin Azadi, and Masoumeh Seydi. Graphtea: Interactive graph self-teaching tool. In *Proc. 2014 Int. Conf. Edu. & Educat. Technol. II*, pages 48–52, 2014.

[13] Thrasyvoulos Spyropoulos, Rao Naveed Rais, Katia Turletti, Thier-ryand Obraczka, and Athanasios Vasilakos. Routing for disruption tolerant networks: taxonomy and design. *Wireless networks*, 16(8):2349–2370, 2010.

[14] Marco Conti and Mohan Kumar. Opportunities in opportunistic computing. *Computer*, 43(1):42–50, 2010.

[15] Sushant Jain, Kevin Fall, and Rabin Patra. *Routing in a delay tolerant network*, volume 34. ACM, 2004.

[16] Sunil Taneja and Ashwani Kush. A survey of routing protocols in mobile ad hoc networks. *International Journal of Innovation, Management and Technology*, 1 (3):2010-0248, 2010.

[17] Laurent Franck. Performance comparison of mobile ad-hoc and delay tolerant networks. *les technologies de l'information et de la communication pour l'enseignement*, 2015.

[18] Chung-Ming Huang, Kun-chan Lan, and Chang-Zhou Tsai. A survey of opportunistic networks. In *2008.AINAW 2008. 22nd International Conference on Advanced Information Networking and Applications-Workshops*, pages 1672–1677. IEEE, 2008.

[19] Radu Ioan Ciobanu and Ciprian Dobre. Opportunistic networks: A taxonomy of data dissemination techniques. *International Journal of Virtual Communities and Social Networking (IJVCSN)*, 5(2):11–26, 2013.

[20] Marco Conti, Silvia Giordano, Martin May, and Andrea Passarella. From opportunistic networks to opportunistic computing. *Communications Magazine*, IEEE, 48(9):126–139, 2010.

[21] Samo Grasic and Anders Lindgren. An analysis of evaluation practices for dtn routing protocols. In *Proceedings of the seventh ACM international workshop on Challenged networks*, pages 57–64. ACM, 2012.
[22] Ari Keränen and Jörg Ott. Increasing reality for dtn protocol simulations. *Helsinki University of Technology, Tech. Rep*, 2007.

[23] Salman Ali, Junaid Qadir, and Adeel Baig. Routing protocols in delay tolerant networks-a survey. In *2010 6th International Conference on Emerging Technologies (ICET)*, pages 70–75. IEEE, 2010.

[24] RS Mangrulkar and Mohammad Atique. Routing protocol for delay tolerant network: A survey and comparison. In *2010 IEEE International Conference on Communication Control and Computing Technologies (ICCCCT)*, pages 210–215. IEEE, 2010.

[25] Yue Cao and Zhili Sun. Routing in delay/disruption tolerant networks: A taxonomy, survey and challenges. *Communications Surveys & Tutorials, IEEE*, 15(2): 654–677, 2013.

[26] Shyam Kapadia, Bhaskar Krishnamachari, and Lin Zhang. *Data delivery in delay tolerant networks: A survey*. INTECH Open Access Publisher, 2011.

[27] Evan PC Jones and Paul AS Ward. Routing strategies for delay-tolerant networks. *Submitted to ACM Computer Communication Review (CCR)*, 2006.

[28] Thrasyvoulos Spyropoulos, Konstantinos Psounis, and Cauligi S Raghavendra. Single-copy routing in intermittently connected mobile networks. In *2004 First Annual IEEE Communications Society Conference on Sensor and Ad Hoc Communications and Networks*, pages 235–244. IEEE, 2004.

[29] Amin Vahdat, David Becker, et al. Epidemic routing for partially connected ad hoc networks. *Duke University Technical Report CS-200006*, 2000.

[30] Thrasyvoulos Spyropoulos, Konstantinos Psounis, and Cauligi S Raghavendra. Spray and wait: an efficient routing scheme for intermittently connected mobile networks. In *Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking*, pages 252–259. ACM, 2005.

[31] Ram Ramanathan, Richard Hansen, Prithwish Basu, Regina Rosales-Hain, and Rajesh Krishnan. Prioritized epidemic routing for opportunistic networks. In *Proceedings of the 1st international MobiSys workshop on Mobile opportunistic networking*, pages 62–66. ACM, 2007.

[32] Xin Wang, Yantai Shu, Zhigang Jin, Qingfen Pan, and Bu Sung Lee. Adaptive randomized epidemic routing for disruption tolerant networks. In *2009 5th International Conference on Mobile Ad-hoc and Sensor Networks*, pages 424–429. IEEE, 2009.
[33] Anders Lindgren, Avri Doria, and Olov Schelén. Probabilistic routing in intermittently connected networks. *ACM SIGMOBILE mobile computing and communications review*, 7(3):19–20, 2003.

[34] Jérémie Leguay, Timur Friedman, and Vania Conan. Dtn routing in a mobility pattern space. In *Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking*, pages 276–283. ACM, 2005.

[35] Mirco Musolesi, Stephen Hailes, and Cecilia Mascolo. Adaptive routing for intermittently connected mobile ad hoc networks. In *World of wireless mobile and multimedia networks, 2005. WoWMoM 2005. Sixth IEEE International Symposium on*, pages 183–189. IEEE, 2005.

[36] Morten Lindeberg, Stein Kristiansen, Thomas Plagemann, and Vera Goebel. Challenges and techniques for video streaming over mobile ad hoc networks. *Multimedia Systems*, 17(1):51–82, 2011.

[37] Stuart Kurkowski, Tracy Camp, and Michael Colagrosso. Manet simulation studies: the incredibles. *ACM SIGMOBILE Mobile Computing and Communications Review*, 9(4):50–61, 2005.

[38] Saba Siraj, A Gupta, and Rinku Badgujar. Network simulation tools survey. *International Journal of Advanced Research in Computer and Communication Engineering*, 1(4):199–206, 2012.

[39] Ari Keranen. Opportunistic network environment simulator. *Special Assignment report, Helsinki University of Technology, Department of Communications and Networking*, 2008.

[40] Mengjuan Liu, Yan Yang, and Zhiguang Qin. A survey of routing protocols and simulations in delay-tolerant networks. In *Wireless Algorithms, Systems, and Applications*, pages 243–253. Springer, 2011.

[41] Kevin Fall and Kannan Varadhan. The ns manual (formerly ns notes and documentation). *The VINT project*, 47, 2005.

[42] Thomas R Henderson, Sumit Roy, Sally Floyd, and George F Riley. ns-3 project goals. In *Proceeding from the 2006 workshop on ns-2: the IP network simulator*, page 13. ACM, 2006.

[43] Andras Varga et al. The omnet++ discrete event simulation system. In *Proceedings of the European simulation multiconference (ESM 2001)*, volume 9, page 65. sn, 2001.

[44] Ari Keränen, Teemu Kärkkäinen, and Jörg Ott. Simulating mobility and dtns with the one. *Journal of Communications*, 5(2):92–105, 2010.
[45] Mirco Musolesi and Cecilia Mascolo. Mobility models for systems evaluation, a survey. *Middleware for Network Eccentric and Mobile Applications, Springer-Verlag*, 2008.

[46] David B Johnson and David A Maltz. Dynamic source routing in ad hoc wireless networks. In *Mobile computing*, pages 153–181. Springer, 1996.

[47] Frans Ekman, Ari Keränen, Jouni Karvo, and Jörg Ott. Working day movement model. In *Proceedings of the 1st ACM SIGMOBILE workshop on Mobility models*, pages 33–40. ACM, 2008.

[48] Thomas Wiegand, Gary J Sullivan, Gisle Bjontegaard, and Ajay Luthra. Overview of the h. 264/avc video coding standard. *IEEE Transactions on Circuits and Systems for Video Technology*, 13(7):560–576, 2003.

[49] Vivek K Goyal. Multiple description coding: compression meets the network. *IEEE Signal processing magazine*, 18(5):74–93, 2001.

[50] Fenta Adnew Mogus. Performance comparison of multiple description coding and scalable video coding. In *2011 IEEE 3rd International Conference on Communication Software and Networks (ICCSN)*, pages 452–456. IEEE, 2011.

[51] Yi-Hsuan Chiang, Polly Huang, and Homer H Chen. Svc or mdc? that’s the question. In *2011 9th IEEE Symposium on Embedded Systems for Real-Time Multimedia (ESTIMedia)*, pages 76–82. IEEE, 2011.

[52] Yugang Zhou and Wai-Yip Chan. Performance comparison of layered coding and multiple description coding in packet networks. In *Global Telecommunications Conference, 2005. GLOBECOM '05*. IEEE, volume 4. IEEE, 2005.

[53] Jacob Chakareski, Sangeun Han, and Bernd Girod. Layered coding vs. multiple descriptions for video streaming over multiple paths. *Multimedia Systems*, 10(4): 275–285, 2005.

[54] Heiko Schwarz, Detlev Marpe, and Thomas Wiegand. Overview of the scalable video coding extension of the h. 264/avc standard. *IEEE Transactions on circuits and systems for video technology*, 17(9):1103–1120, 2007.

[55] Heiko Schwarz and Mathias Wien. The scalable video coding extension of the H.264/AVC standard [standards in a nutshell]. *IEEE Signal Processing Magazine*, 25(2):135, 2008.

[56] Gary J Sullivan, Jens Ohm, Woo-Jin Han, and Thomas Wiegand. Overview of the high efficiency video coding (hevc) standard. *IEEE Transactions on Circuits and Systems for Video Technology*, 22(12):1649–1668, 2012.
[57] Gary J Sullivan, Jill M Boyce, Ying Chen, J-R Ohm, C Andrew Segall, and Anthony Vetro. Standardized extensions of high efficiency video coding (hevc). *Selected Topics in Signal Processing, IEEE Journal of*, 7(6):1001–1016, 2013.

[58] Jill Boyce and Adarsh K. Ramasubramonian. Wd1 of shvc profiles. *Conformance Testing: http://mpeg.chiariglione.org/standards/mpeg-h/high-efficiency-video-coding*, Oct. 2014.

[59] Iraide Unanue, Iñigo Urteaga, Ronaldo Husemann, Javier Del Ser, Valter Roesler, Aitor Rodríguez, and Pedro Sánchez. A tutorial on h. 264/svc scalable video coding and its tradeoff between quality, coding efficiency and performance. *Recent Advances on Video Coding*, 13, 2011.

[60] Peter Amon, Thomas Rathgen, and David Singer. File format for scalable video coding. *IEEE Transactions on Circuits and Systems for Video Technology*, 17(9):1174–1185, 2007.

[61] Eugene F Krause. *Taxicab geometry: An adventure in non-Euclidean geometry*. Courier Corporation, 2012.

[62] Thomas Schierl, Cornelius Hellge, Shpend Mirta, K Gruneberg, and Thomas Wiegand. Using h. 264/avc-based scalable video coding (svc) for real time streaming in wireless ip networks. In *Circuits and Systems, 2007. ISCAS 2007*. *IEEE International Symposium on*, pages 3455–3458. IEEE, 2007.

[63] Noel Crespi, B Molina, CE Palau, et al. Qoe aware service delivery in distributed environment. In *2011 IEEE Workshops of International Conference on Advanced Information Networking and Applications (WAINA)*, pages 837–842. IEEE, 2011.

[64] Omneya Issa, Filippo Speranza, Tiago H Falk, et al. Quality-of-experience perception for video streaming services: Preliminary subjective and objective results. In *Signal & Information Processing Association Annual Summit and Conference (APSIPA ASC), 2012 Asia-Pacific*, pages 1–9. IEEE, 2012.

[65] Jirka Klaue, Berthold Rathke, and Adam Wolisz. Evalvid—a framework for video transmission and quality evaluation. In *Computer Performance Evaluation. Modelling Techniques and Tools*, pages 255–272. Springer, 2003.

[66] Stephen Wolf and Margaret Pinson. Video quality measurement techniques. *NTIA Report 02-392*, 2002.

[67] Margaret H Pinson and Stephen Wolf. A new standardized method for objectively measuring video quality. *IEEE Transactions on Broadcasting*, 50(3):312–322, 2004.
[68] Christian J Van den Branden Lambrecht and Olivier Verscheure. Perceptual quality measure using a spatiotemporal model of the human visual system. In *Electronic Imaging: Science & Technology*, pages 450–461. International Society for Optics and Photonics, 1996.

[69] Zhou Wang, Ligang Lu, and Alan C Bovik. Video quality assessment based on structural distortion measurement. *Signal processing: Image communication*, 19 (2):121–132, 2004.

[70] Quan Huynh-Thu and Mohammed Ghanbari. The accuracy of psnr in predicting video quality for different video scenes and frame rates. *Telecommunication Systems*, 49(1):35–48, 2012.

[71] Shyamprasad Chikkerur, Vijay Sundaram, Martin Reisslein, and Lina J Karam. Objective video quality assessment methods: A classification, review, and performance comparison. *IEEE Transactions on Broadcasting*, 57(2):165–182, 2011.

[72] Yao Yu, Yu Zhou, and Sidan Du. Video multicast over mobile ad hoc networks using network coding. In *International Conference on Management and Service Science*, pages 1–5. IEEE, 2009.

[73] Thomas Schierl, Karsten Ganger, Cornelius Hellge, Thomas Wiegand, and Thomas Stockhammer. Svc-based multisource streaming for robust video transmission in mobile ad hoc networks. *Wireless Communications*, IEEE, 13(5):96–103, 2006.

[74] Thomas Schierl, Stian Johansen, Cornelius Hellge, Thomas Stockhammer, and Thomas Wiegand. Distributed rate-distortion optimization for rateless coded scalable video in mobile ad hoc networks. In *2007 IEEE International Conference on Image Processing*, volume 6, pages VI-497. IEEE, 2007.

[75] Thomas Schierl, Thomas Stockhammer, and Thomas Wiegand. Mobile video transmission using scalable video coding. *IEEE Transactions on Circuits and Systems for Video Technology*, 17(9):1204–1217, 2007.

[76] Hulya Seferoglu and Athina Markopoulou. Opportunistic network coding for video streaming over wireless. In *Packet Video 2007*, pages 191–200. IEEE, 2007.

[77] Hulya Seferoglu and Athina Markopoulou. Video-aware opportunistic network coding over wireless networks. *IEEE Journal on Selected Areas in Communications*, 27(5):713–728, 2009.

[78] Min Qin and Roger Zimmermann. Improving mobile ad-hoc streaming performance through adaptive layer selection with scalable video coding. In *Proceedings of the 15th international conference on Multimedia*, pages 717–726. ACM, 2007.
[79] Shiwen Mao, Shunan Lin, Shivendra S Panwar, Yao Wang, and Emre Celebi. Video transport over ad hoc networks: multistream coding with multipath transport. *IEEE Journal on Selected Areas in Communications*, 21(10):1721–1737, 2003.

[80] Sergio Cabrero, Xabiel G Pañeda, Thomas Plagemann, Vera Goebel, and Matti Siekkinen. Overlay solution for multimedia data over sparse manets. In *Proceedings of the 2009 International Conference on Wireless Communications and Mobile Computing: Connecting the World Wirelessly*, pages 1056–1061. ACM, 2009.

[81] Christian Raffelsberger and Hermann Hellwagner. A multimedia delivery system for delay-/disruption-tolerant networks. In *2015 IEEE International Conference on Pervasive Computing and Communication Workshops (PerCom Workshops)*, pages 530–536. IEEE, 2015.

[82] Ling-Jyh Chen, Chen-Hung Yu, Tony Sun, and Yung-Chih ChenHao-hua Chu. Effective file transfer for opportunistic networks. *Academia Sinica Technical Report TR-IIS-06-010, IIS*, 2006.

[83] Ling-Jyh Chen, Chen-Hung Yu, Cheng-Long Tseng, Hao-hua Chu, and Cheng-Fu Chou. A content-centric framework for effective data dissemination in opportunistic networks. *IEEE Journal on Selected Areas in Communications*, 26(5): 761–772, 2008.

[84] Honghai Wu and Huadong Ma. Dsvm: A buffer management strategy for video transmission in opportunistic networks. In *2013 IEEE International Conference on Communications (ICC)*, pages 2990–2994. IEEE, 2013.

[85] Hayoung Yoon, JongWon Kim, Feiselia Tan, and Robert Hsieh. On-demand video streaming in mobile opportunistic networks. In *2008. PerCom 2008. Sixth Annual IEEE International Conference on Pervasive Computing and Communications*, pages 80–89. IEEE, 2008.

[86] Hayoung Yoon and JongWon Kim. Peer-assisted video-on-demand in multi-channel switching wifi-based mobile networks. In *Signal & Information Processing Association Annual Summit and Conference (APSIPA ASC), 2012 Asia-Pacific*, pages 1–7. IEEE, 2012.

[87] Kevin Fall, Wei Hong, and Samuel Madden. Custody transfer for reliable delivery in delay tolerant networks. *IRB-TR-03-030, July*, 2003.

[88] Mikko Pitkanen, Ari Keranen, and Jörg Ott. Message fragmentation in opportunistic dtns. In *2008 International Symposium on a World of Wireless, Mobile and Multimedia Networks*, pages 1–7. IEEE, 2008.
[89] M Renuka and P Thangaraj. Multi-path encrypted data security architecture for mobile ad hoc networks. In *2011 National Conference on Innovations in Emerging Technology (NCOIET)*, pages 153–156. IEEE, 2011.

[90] DS Vinod and G Madhusudan. Novel technique of multipath routing protocol in ad hoc network. *International Journal of Computer Networks & Communications*, 4(3):109, 2012.

[91] Yong Wang, Sushant Jain, Margaret Martonosi, and Kevin Fall. Erasure-coding based routing for opportunistic networks. In *Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking*, pages 229–236. ACM, 2005.

[92] Fani Tsapeli and Vassilis Tsaoussidis. Routing for opportunistic networks based on probabilistic erasure coding. In *Wired/Wireless Internet Communication*, pages 257–268. Springer, 2012.

[93] Uwe Horn, Klaus Stuhlmüller, M Link, and B Girod. Robust internet video transmission based on scalable coding and unequal error protection. *Signal Processing: Image Comm.*, 15(1):77–94, 1999.

[94] Amir Naghdinezhad, MR Hashemi, and Omid Fatemi. A novel adaptive unequal error protection method for scalable video over wireless networks. In *2007. ISCE 2007. IEEE International Symposium on Consumer Electronics*, pages 1–6. IEEE, 2007.

[95] Joohee Kim and Ji-Cheol Hong. Channel-adaptive multiple description coding for wireless video streaming. In *2007. ICCCN 2007. Proceedings of 16th International Conference on Computer Communications and Networks*, pages 474–478. IEEE, 2007.

[96] Waldir Moreira and Paulo Mendes. Survey on opportunistic routing for delay/disruptiontolerant networks. *SITI Technical Report SITI-TR-11-02*, 2011.

[97] Ling-Jyh Chen, Chen-Hung Yu, Tony Sun, Yung-Chih Chen, and Hao-hua Chu. A hybrid routing approach for opportunistic networks. In *Proceedings of the 2006 SIGCOMM workshop on Challenged networks*, pages 213–220. ACM, 2006.

[98] Pierre-Ugo Tournoux, Jeremie Leguay, Farid Benbadis, John Whitbeck, Vania Conan, and Marcelo Dias de Amorim. Density-aware routing in highly dynamic dtns: The rollernet case. *IEEE Transactions on Mobile Computing*, 10(12): 1755–1768, 2011.

[99] John Burgess, Brian Gallagher, David Jensen, and Brian Neil Levine. Maxprop: Routing for vehicle-based disruption-tolerant networks. In *INFOCOM*, volume 6, pages 1–11, 2006.
[100] Chih-Lin Hu and Bing-Jung Hsieh. A density-aware routing scheme in delay tolerant networks. In *Proceedings of the 27th Annual ACM Symposium on Applied Computing*, pages 563–568. ACM, 2012.

[101] Jani Lakkakorpi, Mikko Pitkänen, and Jörg Ott. Adaptive routing in mobile opportunistic networks. In *Proceedings of the 13th ACM international conference on Modeling, analysis, and simulation of wireless and mobile systems*, pages 101–109. ACM, 2010.

[102] Jingwei Miao, Omar Hasan, Sonia Ben Mokhtar, and Lionel Brunie. An adaptive routing algorithm for mobile delay tolerant networks. In *2011 14th International Symposium on Wireless Personal Multimedia Communications (WPMC)*, pages 1–5. IEEE, 2011.

[103] Yi Guo, Ying Chen, Ye-Kui Wang, Houqiang Li, Miska M Hannuksela, and Moncef Gabbouj. Error resilient coding and error concealment in scalable video coding. *IEEE Transactions on Circuits and Systems for Video Technology*, 19(6):781–795, 2009.

[104] Georg Carle and Ernst W Biersack. Survey of error recovery techniques for ip-based audio-visual multicast applications. *Network*, IEEE, 11(6):24–36, 1997.

[105] Vineeth Shetty Kolkeri, MS Koul, JH Lee, and KR Rao. Error concealment techniques in h. 264/avc for wireless video transmission in mobile networks. *IEEE Fellow, Department of Electrical Engineering, University of Texas at Arlington, Advances in Engineering Science*, pages 9–16, 2008.

[106] Ying Chen, Kai Xie, Feng Zhang, Purvin Pandit, and Jill Boyce. Frame loss error concealment for svc. *Journal of Zhejiang University SCIENCE A*, 7(5):677–683, 2006.

[107] Tommi Keränen, Janne Vehkaperä, and Johannes Peltola. Error concealment for svc utilizing spatial enhancement information. In *Proceedings of the 4th International Mobile Multimedia Communications Conference (MobiMedia'08)*, 2008.

[108] Eitan Altman and Francesco De Pellegrini. Forward correction and fountain codes in delay-tolerant networks. *IEEE/ACM Transactions on Networking*, 19(1): 1–13, 2011.

[109] Mohsen Sardari, Faramarz Hendessi, and Faramarz Fekri. Dmrc: dissemination of multimedia in vehicular networks using rateless codes. In *INFOCOM Workshops 2009, IEEE*, pages 1–6. IEEE, 2009.

[110] Dieu Thanh Nguyen, Michio Hayashi, and Joern Ostermann. Adaptive error protection for scalable video coding extension of h. 264/avc. In *2008 IEEE International Conference on Multimedia and Expo*, pages 417–420. IEEE, 2008.
[111] Amir Naghdinezhad, MR Hashemi, and Omid Fatemi. A novel adaptive unequal error protection method for scalable video over wireless networks. In *2007. ISCE 2007. IEEE International Symposium on Consumer Electronics*, pages 1–6. IEEE, 2007.

[112] Selim Aksoy and Robert M Haralick. Feature normalization and likelihood-based similarity measures for image retrieval. *Pattern recognition letters*, 22(5): 563–582, 2001.

[113] Munchurl Kim, Sangjin Hahm, Keunsik Lee, Keunsoo Park, et al. A partial protection scheme based on layer dependency of scalable video coding. In *2008. VIE 2008. 5th International Conference on Visual Information Engineering*, pages 777–782. IET, 2008.

[114] Thrasyvoulos Spyropoulos, Konstantinos Psounis, and Cauligi S Raghavendra. Efficient routing in intermittently connected mobile networks: the multiple-copy case. *IEEE/ACM Transactions on Networking*, 16(1):77–90, 2008.

[115] M Reisslein. Video trace library. *Arizona State University, [online] Available: http://trace.eas.asu.edu*, 2012.

[116] Ye-Kui Wang, Stephan Wenger, and Miska M Hannuksela. Common conditions for svc error resilience testing. *ISO/IEC JTC1/SC29/WG11 and ITU-T SG16 Q*, 6: 7–10, 2005.

[117] J. Chen, D. Wu, H. Gao, and J.Y. Tham. A novel scheme of generating streamable mp4 files for scalable video coding. In *2009. AH-ICI 2009. First Asian Himalayas International Conference on Internet*, pages 1–5. IEEE, 2009.

[118] Hosik Sohn, Hana Yoo, Wesley De Neve, Cheon Seog Kim, and Yong Man Ro. Full-reference video quality metric for fully scalable and mobile svc content. *IEEE Transactions on Broadcasting*, 56(3):269–280, 2010.

[119] Arno Barzan, Bram Bonné, Peter Quax, Wim Lamotte, Mathias Versichele, and Nico Van de Weghe. A comparative simulation of opportunistic routing protocols using realistic mobility data obtained from mass events. In *2013 IEEE 14th International Symposium and Workshops on a World of Wireless, Mobile and Multimedia Networks (WoWMoM)*, pages 1–6. IEEE, 2013.

[120] Philip Ginzboorg, Valtteri Niemi, and Jörg Ott. Message fragmentation for disrupted links. In *Wireless Conference 2011-Sustainable Wireless Technologies (European Wireless)*, 11th European, pages 1–10. VDE, 2011.

[121] Wei Gao and Guohong Cao. On exploiting transient contact patterns for data forwarding in delay tolerant networks. In *2010 18th IEEE International Conference on Network Protocols (ICNP)*, pages 193–202. IEEE, 2010.
[122] Friedrich Pukelsheim. The three sigma rule. *The American Statistician*, 48(2): 88–91, 1994.

[123] Marco Brandas, Maria G Martini, Mikko Uitto, and Janne Vehkapera. Quality assessment and error concealment for svc transmission over unreliable channels. In *2011 IEEE International Conference on Multimedia and Expo (ICME)*, pages 1–6. IEEE, 2011.

[124] Médéric Blestel and Mickaël Raulet. Open svc decoder: a flexible svc library. In *Proceedings of the international conference on Multimedia*, pages 1463–1466. ACM, 2010.