obability of longer RTT (TCP) or higher jitter (UDP) [26]. 12.1.3.1 EDGE DL Access 12.1.3.1.1 EDGE DL Access on TCP The first scenario is represented in Figure 12.2a. The available bandwidth is mea- sured with Jperf (see Figure 12.8) and Ethereal/Wireshark (see Figures 12.9 and 12.10), both at the client and at the probe. As illustrated by Figure 12.8, at the start of the transmission, for about 2 S, there is no data transfer on the "probe" (server) side. This is caused by the setup of the radio channels. The peak on the client side is caused by the filling of the transmis- sion buffers. After the radio channels are set up, the buffers are emptied which is causing a peak in the data transmission. The small (but steady) increase of the avail- able bandwidth is caused by the adjustment of the TCP window size. Interpretation of Figure 12.9: The test case considers a step-by-step increase of Time/Div at the time base of the oscilloscope. It can be seen that the bit rate is increasing proportionally. At the moment should the time base be switched, there Tele-Measurement Services for m-Learning Time (s) Figure 12.8 Jperf/Iperf measurement of the bandwidth (kbps) on DL TCP for 70 kbps at the client. will be some spikes caused by the fact that in those moments the oscilloscope is not providing the samples at the same speed (a small time is needed for the stabilization of this speed). Out of the measurement, it can be noticed that most of the RTT values are situ- ated around 700 ms. There are also packets with a RTT of a few seconds. These delays are caused by loss of packets on the radio interface. Also, one can notice the almost constant throughput when maintaining the first Time/Div values. In the second part, reaching channels' capacity ("congestion"), when the needed bit rate approaches the available bandwidth, more and more packets are lost causing big variations in the throughput (which is dramatically dropping during negotiation of the retransmission). 20,000 bps 10,000 bps 0 bps Figure 12.9 Ethereal/Wireshark mea