Books
in black and white
Main menu
Share a book About us Home
Books
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics
Ads

GPRS and 3G Wireless application - Anderson C.

Anderson C. GPRS and 3G Wireless application - Wiley publishing , 2001. - 356 p.
ISBN: 0-471-41405 -0
Download (direct link): gprsand3gwirelessapplica2001.pdf
Previous << 1 .. 60 61 62 63 64 65 < 66 > 67 68 69 70 71 72 .. 125 >> Next

C:\ping www.ericsson.com
Pinging 192.168.14.14 with 32 bytes of data:
Reply from 192.168.14.14: bytes = 32 time = 34ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 32ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 40ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 25ms TTL = 128
Ping statistics for 192.168.14.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% Loss)
Approximate rount trip times in milli-seconds:
Minimum = 25ms, Maximum = 40ms, Average = 33ms
These results show the ping times from a computer in the MAI Stockholm labs to a computer that serves Ericsson’s Web pages. Ping just sends an Internet Control Message Protocol (ICMP) message to the destination server and awaits
Page 159
the results. This particular message does not require any processing at the destination server, and the time that it takes to go back and forth should reflect the total time that it takes to travel that distance. As we saw in the example, the average time is about 33 milliseconds, which is fast. The slowest link to this server is probably in the range of a T1 line (1.5Mbps), and the links that are involved are very low-latency links.
To get a feeling for the latencies that your wireless applications will experience, we now perform the same command over an emulated GPRS environment. We perform this task by using the Global Application Test Environment (GATE) emulator that we will describe in more detail in Chapter 14, “Testing the Wireless Applications.” The laptop that runs Windows 98 now talks to the Internet via the Linux computer that emulates the network. In a real situation, this laptop would have a GPRS PCMCIAcard or a Bluetooth connection to a GPRS phone. In this example, though, the GPRS radio is emulated inside the GATE. With an emulated 4+1 TS mobile, five other low-traffic GPRS users, no voice users on the same transceiver (TRX), and pretty good radio conditions (C/I = 18dB), we get the following result when we ping the location:
C:\ping www.ericsson.com
Pinging 192.168.14.14 with 32 bytes of data:
Reply from 192.168.14.14: bytes = 32 time = 450ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 520ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 360ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 370ms TTL = 128
Ping statistics for 192.168.14.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% Loss)
Approximate rount trip times in milli-seconds:
Minimum = 360ms, Maximum = 520ms, Average = 425ms
As we can see, the average RTT is now 425 milliseconds, which is a lot higher than the fixed result. Now, let’s see what happens if we bump up the number of GPRS users to 40 and the number of voice users to four. Now, you have 40 other users who are competing for the four time slots (four time slots occupied by voice users). The new result is as follows:
C:\ping www.ericsson.com
Pinging 192.168.14.14 with 32 bytes of data:
Reply from 192.168.14.14: bytes = 32 time = 900ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 750ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 602ms TTL = 128
Reply from 192.168.14.14: bytes = 32 time = 834ms TTL = 128
Page 160
Ping statistics for 192.168.14.14:
Packets: Sent = 4, Received = 4, Lost = 0 (0% Loss)
Approximate rount trip times in milli-seconds:
Minimum = 602ms, Maximum = 900ms, Average = 772ms
Figure 8.2 shows how the bandwidth usage increases dramatically as more users join the cell. This situation occurs because GPRS basically enables concurrent users to take turns at sending, and the more users who join the cell, the longer the latency for each user. We will discuss GATE, the tool that we use here, in more detail in Chapter 14, “Testing the Wireless Applications. ”
After seeing this example, we see more clearly that the latency is not only in the air interface propagation, but also in the processing of the traffic as the load increases. The processing in the network nodes takes time, and so do the retransmissions over the air. In cases of a high load, GPRS latency can be as high as several seconds (which can be devastating for chatty applications). 3G networks are expected to have lower latency, but LANs and radio networks are still very different.
Chatty applications are those that have a tendency of running off to the server all of the time, just to have the capability of enabling the user to perform the smallest task. Many applications do not even need the user to trigger requests
Figure 8.2 The upper-left corner shows the available bandwidth (light colored) in a loaded cell.
Page 161
to the server; rather, they constantly check network nodes for new information and updates. One of the key reasons why WTP is transaction oriented instead of HTTP/TCP packet oriented is to minimize the chattiness (HTTP is a very chatty protocol). In this way, you can fetch one message (an entire deck) by using one request and response. This method is the desired way to write wireless applications, where you always try to minimize the number of interactions with the server and try not to start too many sessions.
Previous << 1 .. 60 61 62 63 64 65 < 66 > 67 68 69 70 71 72 .. 125 >> Next