Citation
PERFORMANCE MEASUREMENT OF TCP OVER PACKET SWITCHED GSM NETWORKS

Material Information

Title:
PERFORMANCE MEASUREMENT OF TCP OVER PACKET SWITCHED GSM NETWORKS
Copyright Date:
2008

Subjects

Subjects / Keywords:
Bleeding time ( jstor )
Bytes ( jstor )
Circuit switching ( jstor )
Governmental protocol ( jstor )
Internet ( jstor )
Modems ( jstor )
Radio ( jstor )
Shuttle derived vehicles ( jstor )
Signals ( jstor )
Time division multiple access ( jstor )

Record Information

Source Institution:
University of Florida
Holding Location:
University of Florida
Rights Management:
Copyright the author. Permission granted to the University of Florida to digitize, archive and distribute this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.
Embargo Date:
5/4/2002
Resource Identifier:
51747976 ( OCLC )

Downloads

This item is only available as the following downloads:


Full Text

PAGE 1

PERFORMANCE MEASUREMENT OF TCP OVER PACKET SWITCHED GSM NETWORKS By JOSE E SANCHEZ-VELEZ A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF ENGINEERING UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Jose E Sanchez-Velez

PAGE 3

I dedicate this work to my wife Ivette, my son Jose Enrique and my daughter Gabriela.

PAGE 4

iv ACKNOWLEDGMENTS I wish to express my thanks to the members of my committee: Dr. Haniph Latchman, Dr. Herman Lam and Dr. Tan Wong. I am particularly thankful to Dr. Latchman for promoting and supporting distance learning programs like FEEDS. This program has been very beneficial for my professional development. Special thanks also go to my wife, Ivette and my friend, Eugene Lopatukhin, who always encouraged me to continue with graduate studies.

PAGE 5

v TABLE OF CONTENTS page ACKNOWLEDGMENT S ............................................................................................. . iv ABSTRAC T ................................................................................................................. . vii CHAPTERS1 INTRODUCTIO N ..................................................................................................... . 1 1.1 Motivation s .......................................................................................................... . 1 1.2 Historical Backgroun d ......................................................................................... . 2 1.3 The Evolution of Wireless Data in Cellula r .......................................................... . 4 1.4 Next Chapters: Overvie w ..................................................................................... . 5 2 GLOBAL SYSTEM FOR MOBILE COMMUNICATION S ..................................... . 6 2.1 Network Architectur e .......................................................................................... . 6 2.2 The Radio Interfac e ............................................................................................. . 9 2.3 Codin g ............................................................................................................... . 16 2.3.1 Waveform Codin g ...................................................................................... . 17 2.3.2 Vocoder s .................................................................................................... . 18 2.4 Conclusio n ......................................................................................................... . 18 3 DATA EVOLUTION IN GS M ................................................................................ . 19 3.1 Introductio n ....................................................................................................... . 19 3.2 Circuit Switching Vs Packet Switchin g .............................................................. . 20 3.3 Data Inter-workin g ............................................................................................. . 21 3.4 Early GSM Dat a ................................................................................................ . 21 3.5 First GSM Data Transmission Enhancemen t ...................................................... . 22 3.6 High-Speed Circuit Switched Dat a ..................................................................... . 22 3.7 The General Packet Radio Service Protoco l ....................................................... . 27 3.7.1 Network Architectur e ................................................................................. . 27 3.7.2 Air Interface and Protocol Reference Mode l ............................................... . 29 3.8 Conclusio n ......................................................................................................... . 36 4 GSM AND THE INTERNET PROTOCOL S ........................................................... . 37 4.1 Introductio n ....................................................................................................... . 37

PAGE 6

vi 4.2 Origin of the TCP/IP Protoco l ............................................................................ . 37 4.2.1 The Internet Protoco l .................................................................................. . 38 4.2.1.1 Addressin g .......................................................................................... . 39 4.2.1.2 Internet Protocol Datagram s ................................................................ . 39 4.2.2 The Transport Layer Protocol s ................................................................... . 40 4.3 Mobile Station Data Acces s ............................................................................... . 41 4.4 Wireless Environment Issues and TC P ............................................................... . 42 4.5 Conclusio n ......................................................................................................... . 43 5 PERFORMANCE OF TCP OVER GPRS ................................................................ . 44 5.1 Introductio n ....................................................................................................... . 44 5.2 Measurement Tools............................................................................................ . 44 5.3 General Packet Radio Services RF Mode m ........................................................ . 45 5.4 Measurements of Bulk Data Downloa d .............................................................. . 48 5.4.1 Data Download in Strong Signa l ................................................................. . 49 5.4.2 Data Download in a Mobile Environmen t ................................................... . 50 5.4.3 Data Download in a Weak Signal Environmen t ........................................... . 51 5.4.4 Bulk Data Download Measurement Analysis ............................................... . 55 5.5 Radio Link Control Protocol Benefits for TCP in GPR S .................................... . 56 5.6 Effect of GPRS Protocol Layers and Signaling on Overall Performance ............. . 59 5.7 Proposals to Enhance the TCP Performance on Wireless Networks .................... . 60 5.8 Conclusion s ....................................................................................................... . 61 6 CONCLUSION AND FUTURE WOR K ................................................................. . 63 6.1 Conclusio n ......................................................................................................... . 63 6.2 Future Wor k ...................................................................................................... . 64 APPENDIXA MODEM DAT A ..................................................................................................... . 66 A.1 Port Monitor Log for GPRS Connection with GPRS Mode m ............................ . 66 A.2 Connecting with a GPRS RF Mode m ................................................................ . 93 B EXPERIMENTS LOG S .......................................................................................... . 96 B.1 Decoded TCP Trace for Poor Channel Experimen t ............................................ . 96 B.2 Decoded TCP Trace for Mobile User Experimen t ............................................. . 98 B.3 Decoded TCP Trace for Good Channel Experiment ......................................... . 101 B.4 Decoded TCPTrace for WWW Experimen t ..................................................... . 104 B.5 Raw Trace for TCP over Poor Channe l ............................................................ . 118 LIST OF REFERENCES............................................................................................ . 126 BIOGRAPHICAL SKETC H ...................................................................................... . 128

PAGE 7

vii Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science PERFORMANCE MEASUREMENT OF TCP OVER PACKET SWITCHED GSM NETWORKS By Jos E Snchez-Vlez May 2002 Chairman: Haniph Latchman Major Department: Electrical and Computer Engineering The explosive growth of the Internet and the dramatic increase in demand of wireless data have created a wide range of applications and services for wireless devices. Emerging technologies (i.e., Third Generation Cellular or 3G, GSM-GPRS, GSM-HCSD and others) will facilitate the “ on the move ” use of services like audio conferencing, electronic mail, multimedia services, Internet browsing, electronic commerce and others using wireless devices with an acceptable Quality of Service (QoS). Most of these technologies make use of packet switch data networks and mainly rely on the Internet Protocol (TCP/IP). Terms like “Mobile IP ” and “GPRS device ” are now common language in the wireless arena. It is the purpose of this research to study the performance of the TCP protocol over packet switched Global System for Mobile Communications (GSM) networks and the new technologies introduced by GSM which make TCP more reliable over wireless links. Currently the GSM protocol is the number one cellular protocol worldwide in terms

PAGE 8

viii of number of subscribers and countries in service GSM circuit switched data will also be presented to make a comparison of the benefits of the new packet switching technology introduced by GPRS-GSM. The General Packet Radio Services (GPRS), which is also called the 2.5G, is GSM ’ s packet data protocol that supports rates of up to 171 kbps and is the precursor to the so called 3G (Universal Mobile Telephone Service – UMTS). This protocol plays an important role in the future roll out of 3G networks; once GPRS networks are in place operators will be able to determine which type of services consumers are looking for and this will be a determining factor on how fast 3G networks are rolled out. As part of this work, experiments were performed to analyze the performance of TCP over GPRS in a live network. The experiments were conducted in three different channel environments (good signal, mobile user, and bad signal). These experiments demonstrate that TCP operates efficiently over GPRS thanks to the reliable radio link control protocol (RLC) implemented in GPRS. The RLC protocol provides an efficient and fast ARQ mechanism that prevents TCP packets from timing out when there is loss of data due to a poor radio link. RLC successfully hides the problems in the radio link, thereby eliminating unnecessary TCP packet retransmissions. We will see that with the introduction of GPRS, GSM offers an efficient, fast connect, “ always on ” mechanism to access the Internet. This new mechanism is based on charge per volume of data instead of charge for connection time. GPRS is a true packet data mechanism that adapts its Quality of Service (QoS) depending on the different channel conditions.

PAGE 9

1 CHAPTER 1 INTRODUCTION 1.1 Motivations Cellular communication has created an entire industry that has become one of the key players of today ’ s business world. During the last decade of the 20th century we saw the great impact that cellular radio had on daily life style. Voice is just one of the services offered by cellular networks; today users can send a facsimile, browse the Internet, send and receive email, do electronic wireless commerce and subscribe to an array of services not imagined ten years ago. The Internet revolution has also taken over the world. The Internet provides one of the most powerful and easiest methods of worldwide communication; audio and video are transmitted at a good quality of service over the Internet, making applications such as multimedia viable. Due to its immense popularity in wired networks, the TCP/IP family of protocols has been adopted as the de facto standard for wireless Internet. The combination of digital cellular data services and the Internet is one of the most promising services of digital cellular. Cellular manufactures and operators all over the world are marketing cellular telephones and smart phones as Internet ready. But, how good are these services? Will they compare to what users are accustomed to? Will wireless data services grow at the expected rates? The success of mobile Internet services and wireless data will depend on the quality of service (QoS) provided to the consumers. Quality of service must be comparable to that of wired networks.

PAGE 10

2 The primary objective of this research work is to investigate the performance of the TCP protocol in Global System for Mobile Communications (GSM) networks. This work will concentrate on performance analysis of GSM packet switched connections, better known as GPRS. The secondary objective of this research is to introduce the new data services of the GSM protocol. During the year 2001 new GSM data services were introduced as part of the roll out of GSM Phase 2+ or 2.5G. These data services include the transmission of data over high-speed circuit switched connections and over packet data circuits. 1.2 Historical Background The cellular concept was conceived in the 1940 ’ s, but it was not until the 1980 ’ s that public mobile cellular networks were introduced. The cellular concept originated in 1947 in Bell Laboratories. In 1949 the precursor of today ’ s modern cellular system began operations in the city of Detroit as a wireless dispatch service for taxi drivers. It worked using small cells to serve hundred of square miles and frequencies were re-used in alternate cells. In this early system drivers had to switch channels manually at predetermined locations [1]. The first successful commercial cellular system was introduced in 1981 in the Scandinavian countries. This system was known as Nordic Mobile Telephone system (NMT) and it worked on the 450 and 900 MHz. The NMT was followed by the Advanced Mobile Phone System (AMPS) in the United States in 1984 and the Total Access Cellular System or TACS in the United Kingdom in 1986. All these early systems were analog and the modulation used was Frequency Division Multiple Access. Capacity and quality of service of analog systems prompted the cellular industry to adopt digital techniques to enhance cellular communications. In 1988, the Cellular

PAGE 11

3 Telecommunications Industry Association (CTIA) commissioned one of its subcommittees to review alternative technologies to allow for cost effective cellular expansion in the United States. In 1989 cellular manufactures and operators started developing a new technology called “ Digital Cellular ” . The first digital system accepted by the CTIA allowed users to share a radio channel by time division. Each user was assigned a specific time slot for transmission and reception. This system is widely used today and as mentioned before it utilizes Time Division Multiple Access. In North America a second digital system was accepted by the CTIA; this system was based on technology called Code Division Multiple Access. In CDMA users share the radio channel by a code division scheme. In this scheme, each user is assigned a Pseudo Noise (PN) code for transmission and reception. In 1991 the Global System for Mobile Communications (GSM) was inaugurated in Europe as the digital cellular standard for all European countries. GSM development took a long time to develop due to the diverse political and economical nature of European countries. Work on the GSM protocol started in 1982 when the Conference of European Post and Telecommunications (CEPT) held a meeting to begin the standardization process for a unique cellular system for all Europe. As a result, a forum was created to handle the specifications of the new cellular system. This forum was called the Groupe Special Mobile. In 1989, the technical specification work for the Global System for Mobile Communications was handed over to the newly created European Telecommunications Standards Institute (ETSI). Initially the digital nature of GSM was not a requirement; this decision was made in the course of developing the standard. The digital nature of GSM came about because of the services offered by the

PAGE 12

4 Integrated Services Digital Network (ISDN) wire-line standard, which was deployed in Europe during the time the standards for GSM were defined. 1.3 The Evolution of Wireless Data in Cellular Wireless data cover a broad spectrum of protocols and systems. Wireless data networks include everything from simple paging systems to broadband local area networks. Data in cellular networks came as a result of the new digital protocols. Aside from the increase in system capacity and quality of services, digital cellular systems provide data capabilities that range from facsimile, short messaging services, supplementary services like caller identification, and today most systems are offering wireless internet access. The majority of digital systems offer data rates with maximum speeds of 9.6 kbps (GSM) and 14.4 kbps (CDMA). Most of the data communications today is transmitted over wired networks. These networks provide users with high-speed data. Users are becoming mobile; therefore the demand for more wireless data services grows. Service providers, standard organizations and manufactures have been devoting a lot of time exploring new alternatives to provide higher data throughput and a more efficient utilization of the scarce network resources. To stay at a competitive edge most digital cellular systems are rolling out new protocols that will provide fast Internet access, multimedia services and a whole array of new wireless data applications. The European Telecommunications Standards Institute has defined two new data services in the GSM protocol that are expected to be operational in some European countries by the end of year 2000. These two services are the High-Speed Circuit Switch Data and the General Packet Radio Services. The General Packet Radio Services offers data rates of over 100 kbps and High-Speed Circuit Switch Data offers bit rates of 64

PAGE 13

5 kbps. The ETSI is also looking beyond these two systems and it is currently defining a data system that promises bit rates of over 300 kbps. This new system is called Enhanced Data Rates for GSM Evolution or EDGE. GPRS, High-Speed Circuit Data and EDGE are technologies that will prepare the communications world for the Universal Mobile Telecommunications Service (UMTS). 1.4 Next Chapters: Overview The outline of this document is as follows: chapter 2 discusses the GSM infrastructure and the GSM protocol. The third chapter is about GSM data; in specific chapter 3 concentrates on the newest GSM data services: High-Speed Circuit Switched Data (HSCD) and the General Packet Radio Service (GPRS). The fourth chapter covers the Internet Protocol and TCP/IP over GSM networks. The fifth chapter provides a performance analysis of TCP in GSM Packet Data Networks (i.e., GPRS); it also discusses the mechanisms used for such analysis. The sixth chapter provides a conclusion and recommends extensions to this research.

PAGE 14

6 CHAPTER 2 GLOBAL SYSTEM FOR MOBILE COMMUNICATIONS 2.1 Network Architecture Figure 1 illustrates most of the GSM network components. The GSM system contains many subsystems; these network components are discussed in this section. During this chapter the term “mobile station ” will be used to refer to the communication device used in the GSM network, e.g. GSM cellular phone. Figure 1. Network architecture in the GSM cellular system The Base Transceiver Station (BTS) and the Base Station Controller (BSC) cover most of the cellular specific functions. The BTS and BSC are called the Base Station Subsystem (BSS). It is the BSS the one that takes care of contacting the GSM terminal Location Area BTS BTS BTS BTS Location Area BTS BTS BTS PSTN Service Area An MSC serving one or more BSC GMSC BSC BSC EIR AUC HLR MSC VLR

PAGE 15

7 equipment. The coverage area provided by a BTS is called a cell. A typical GSM network contains hundreds of Base Transceiver Stations. Therefore the BTS is kept as simple as possible. The main function of the BTS is to communicate with the mobile station, providing only the radio functionality and signaling required to communicate with other network nodes. In the other hand, the Base Station Controller (BSC) is in charge of controlling the radio resources. It is the BSC the one that controls and supervises the different Base Transceiver Stations in its location area. While the BTS does the actual radio communication, it is the BSC the one that controls all the actions taken by the BTS. The BSC tells the BTS what to do, what transmit power it should use, how channels are allocated and determines when the BTS has to transmit. A typical BTS controls an average of ten transceiver stations. The Mobile Switching Center (MSC) is the entity that sets up, supervises and releases calls. An MSC connects calls with other networks (e.g. Public Switched Telephone Network, Integrated Services Digital Network) or with other mobile station within the GSM network. A gateway provides the communication interface between the GSM network and other networks. The Gateway Mobile Switching Center (GMSC) provides the mechanism to route the calls coming into the GSM network. It is the GMSC responsibility to find in which part of the network the mobile station is located. GMSC queries a database called the Home Location Register (HLR) to find out where a particular mobile station is located. Using the information in this database the GMSC then routes calls via the MSC to the mobile station.

PAGE 16

8 Due to subscribers mobility, two databases, the Home Location Register (HLR) and the Visitors Location Register (VLR) are used to keep track of the location of mobile station. The HLR stores data belonging to all the subscribers that are part of the network in which the HLR is located. Among the data stored on the HLR, one of the most important pieces is the MSC/VLR service area in which the mobile station is located. There is typically one HLR per network operator. The Visitors Location Register is a regional database that stores information about all the subscribers that are visiting the network. The MSC/VLR visited by the mobile station makes contact with the home HLR of the mobile station when the mobile registers on that new network. The Authentication Center (AUC) is a database that takes care of the security procedures in the network. The AUC produces the codes or keys necessary for encryption of information and authentication of mobile stations. The AUC contains information for all the subscribers belonging to a particular network operator. Normally the mobile stations go through an authentication procedure before they can do anything in the network. The SIM card in the mobile station is one of the most important pieces of the authentication process. The Equipment Identity Register (EIR) is a database that is used to store information about mobile equipment. This can be used to determine if a particular unit shall be banned from the network. For example, the unit may have been stolen or it may not comply with radio emissions specifications. The heart of the network is the subscriber unit or mobile station. Mobile stations consist of two parts: mobile equipment and subscriber identity module card (SIM card). The SIM card is a smart card that contains all the information about the user ’ s

PAGE 17

9 subscription with the network operator. The SIM card also contains security parameters and memory for storing short messages. The mobile equipment is the piece of equipment that enables radio communication with the network, e.g. smart phones, cellular phones. Signaling between the network nodes is performed using signaling system 7 (SS7). Signaling System 7 is designed for the exchange of control messages among entities on a telephone network. Signaling System 7 original purpose was to control fixed telephone networks, but it is now highly used as the main signaling protocol in different types of networks. 2.2 The Radio Interface The radio air interface in the GSM system is called the Um interface. The Um interface is the most important specification of the GSM network. GSM exists in three different frequencies, the GSM 900 MHz-frequency band, DCS 1800 MHz and PCS 1900 MHz. Table 1 shows the different frequency bands with its up-link and downlink frequency allocation. The GSM 900 MHz band is used in Europe. This was the first frequency spectrum allocated for GSM. Due to capacity issues another frequency band, 1800MHz, was allocated. Systems operating in this frequency are called DCS 1800 (Digital Cellular System 1800). In the United States the frequency band used is the 1900 MHz and it is called PCS. Table 1. Frequency spectrum in GSM Uplink Frequencies Downlink Frequencies GSM 900 890-915 MHz 935-960 MHz DCS 1800 1710-1785 MHz 1805-1880 MHz PCS 1900 1850-1910 MHz 1930-1990 MHz A GSM full duplex channel is made up of a pair of carriers. One of these carriers is used for the downlink frequency and the other for the uplink frequency. GSM radio

PAGE 18

10 interface makes use of Frequency Division Multiple Access (FDMA) and Time Division Multiple Access (TDMA). FDMA is applied on the frequency band to provide 200kHz bandwidth per carrier, thus providing 124 carries in GSM 900 MHz and 374 carriers in GSM 1800 MHz, see Figure 2. In the time domain each carrier is divided into eight consecutive time slots. These eight consecutive time slots are called a TDMA frame. Figure 2. Frequency allocation for GSM and DCS The GSM protocol defines two types of channels, the physical channel and the logical channel. A physical channel is one time slot on one carrier, while a logical channel is a specific type of information transmitted in a physical channel. Logical channels transmit all kind of information, from user speech to system control information. Therefore there are many types of logical channels. These will be discussed later in this chapter. Downlink Channel Uplink Channel 124 123 200kHz GSM 0 25MHz x 2 915MHz 960MHz 890MHz 935MHz Downlink Channel Uplink Channel 374 373 200kHz DCS 0 75MHz x 2 1785MHz 1880MHz 1710MHz 1805MHz

PAGE 19

11 A typical GSM base station utilizes more than one carrier. The main carrier, C0, will transmit most of the signaling information needed on time slots 0 and 1. The other carriers are used as traffic channels. Figure 3. Radio traffic channel frame structure Figure 3 shows the frame structure of the GSM radio channel. TDMA frames are grouped into multi frames. These multi frames are then repeated in cycles. A collection of multi frames is called a super frame. There are two types of super frames, one used for traffic and one used control signaling. Traffic channel (TCH) super frames contain 26 TDMA frames while signaling information super frames have 51 frames. Each TDMA frame contains 8 time slots. The largest time frame in the GSM protocol is the hyper frame. A hyper frame is composed of 2048 super frames; this is approximately 3.5 hours. During a hyper frame period each time slot has a unique sequential number, this number is composed of the frame number, time slot number and super frame number. Information on each logical channel time slot is transmitted in bursts of 148 bits each. Depending on the type of information transmitted on a logical channel a particular Control channel Control channel Traffic Channels Traffic Channels 26 GSM Frames (120ms) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 1 2 1 2 3 4 5 6 7 8 D T D 1 Frame 4.615ms 148 bits burst 577us D = Data T = Training Sequence

PAGE 20

12 type of burst will be used. There are five different types of bursts: the normal burst, the access burst, the frequency correction burst, the synchronization burst and the dummy burst. The normal burst is used for traffic data and some control signaling. A normal burst contains two information fields of 57 bits each. The information fields are separated by a 26 bits training sequence which is used by the equalizer. A normal burst is demarcated by three start bits and three stop bits. The access burst is used when a mobile station wants to access the GSM network. Access bursts are the shortest type of burst. The reason for this is that during access to the network the location of the mobile station is unknown, therefore a short access burst will allow certain delay without interrupting the next time slot. Synchronization bursts are used to allow the mobile station to get in sync with the GSM TDMA frame structure. Frequency correction bursts are used to tune the frequency of the mobile station to that of the base station. Dummy bursts are transmitted when the base station subsystem has been forced to transmit although it has no information to send to the active mobile stations. The purpose of these dummy bursts transmission is to allow the mobile station to measure the received signal strength of its home base station and neighboring base stations. We have already seen that information in the GSM system is transmitted on different types of bursts. Each of these bursts is associated to one or more logical control channels. The task of the logical control channels is to provide for the transfer of signaling information between the network and the mobile stations. Different type of

PAGE 21

13 signaling information is transmitted in each logical channel. The logical control channels in the GSM systems are the following: Frequency Correction Channel (FCCH) Synchronization Channel (SCH) Broadcast Control Channel (BCCH) Paging Channel (PCH) Random Access Channel (RACH) Access Granted Channel (AGCH) Stand Alone Dedicated Control Channel (SDCCH) Slow Associated Control Channel (SACCH) Fast Associated Control Channel (FACCH) Traffic Channel (TCH) Logical control channels are divided in four categories: Broadcast Channel (BCH): includes Frequency Correction Channel, Synchronization channel and Broadcast Control Channel. Transmission in this category occurs only as down link and mobile station listen to these channels when they are in the idle state. Common Control Channel (CCH): includes Paging Channel, Random Access Channel and Access Granted Channel. Dedicated Control Channel (DCCH): includes Stand Alone Dedicated Control Channel, Slow Associated Control Channel and Fast Associated Control Channel. Traffic Channel: this is the channel where speech and data are transmitted. When a mobile station powers up, the first control channel that it tries to find is the Frequency Correction Channel. The base station transmits a frequency correction burst from this channel. It contains a pure sinusoidal signal, which is used for the purpose of orientation. The second purpose of this sinus wave is to provide the mobile station

PAGE 22

14 with a frequency to tune to. Due to the nature of the GMSK modulation used in GSM, a sequence of all zeros in the frequency correction burst will produce an easily detectable sinusoidal signal. The FCCH occurs on the first time slot and it will always be located one frame before the synchronization burst. Once the mobile station detects the FCCH, it will attempt to find a Synchronization Control Channel. The SCCH helps the mobile station to identify the base station subsystem. It also provides information that is used by the mobile station to determine if it is synchronized to the right frequency. After FCCH and SCCH are detected, the mobile station will find the system identification and access control in the Broadcast Control Channel. Figure 4 shows the signaling exchange that occurs when a mobile station receives a call. The mobile station monitors the Paging Channel to detect incoming calls. When a page is received or when a call has to be placed, the mobile station will try to gain access to the system utilizing the Random Access Channel. Acknowledgement for this request will be received in the Access Granted Channel. The Access Granted will also be used to assign a Stand Alone Dedicated Control Channel that the mobile station will use for two way signaling. The Stand Alone Dedicated Control Channel is used for call setup, authentication, ciphering and for short messaging to and from the network. During call setup procedure a mobile station is assigned a Traffic Channel. Table 2 shows the mapping of logical channels in the main carrier, C0. In this table we see the 51-frame channel structure used for control signaling. All other carriers used in the base station (i.e., C1, C2 and Cn) will have a mapping of only traffic channels. In other words, the other carriers will be mapped to a 26-frame traffic channel structure. Broadcast and Common Control Channels are mapped to time slot 0 of C0.

PAGE 23

15 Dedicated Control Channels are mapped to time slot1. In this table we are denoting the SDCCH with the letter D and the SACCH with the letter A. Figure 4. Call establishment for mobile terminated calls Table 2. Mapping of logical channels to the C0 carrier 0 F D 0 T T T T T T R A 5 T T T T T T 1 S D 0 T T T T T T R A 5 T T T T T T 2 B D 0 T T T T T T R A 5 T T T T T T 3 B D 0 T T T T T T R A 5 T T T T T T 4 B D 1 T T T T T T R A 6 T T T T T T 5 B D 1 T T T T T T R A 6 T T T T T T 6 C D 1 T T T T T T R A 6 T T T T T T Paging Mobile (PCH) Mobile Request Channel (RACH) Mobile is assigned a channel (AGCH) Authentication and ciphering procedures (SDCCH) Setup m essage for inco m ing call (SDCCH ) Confirmation (SDCCH) Assignment of a Traffic Channel (SDCCH) Acknowledge for Traffic Channel (FACCH) Ring to Alert Caller (FACCH) Connect Message (FACCH) Exchange of Speech (TCH) Mobile Station Base Station

PAGE 24

16 Table 2-continued 7 C D 1 T T T T T T R A 6 T T T T T T 8 C D 2 T T T T T T R A 7 T T T T T T 9 C D 2 T T T T T T R A 7 T T T T T T 10 F D 2 T T T T T T R A 7 T T T T T T 11 S D 2 T T T T T T R A 7 T T T T T T 12 C D 3 A I A I A I R I A I A I A I 13 C D 3 T T T T T T R I T T T T T T 14 C D 3 T T T T T T R I T T T T T T 15 C D 3 T T T T T T R D 0 D T T T T T T 16 C D 4 T T T T T T R D 0 T T T T T T 17 C D 4 T T T T T T R D 0 T T T T T T 18 C D 4 T T T T T T R D 0 T T T T T T 19 C D 4 T T T T T T R D 1 T T T T T T 20 F D 5 T T T T T T R D 1 T T T T T T 21 S D 5 T T T T T T R D 1 T T T T T T 22 C D 5 T T T T T T R D 1 T T T T T T 23 C D 5 T T T T T T R D 2 T T T T T T 24 C D 6 T T T T T T R D 2 T T T T T T 25 C D 6 I A I A I A R D 2 I A I A I A 26 C D 6 T T T T T T R D 2 T T T T T T 27 C D 6 T T T T T T R D 3 T T T T T T 28 C D 7 T T T T T T R D 3 T T T T T T 29 C D 7 T T T T T T R D 3 T T T T T T 30 F D 7 T T T T T T R D 3 T T T T T T 31 S D 7 T T T T T T R D 4 T T T T T T 32 C A 0 T T T T T T R D 4 T T T T T T 33 C A 0 T T T T T T R D 4 T T T T T T 34 C A 0 T T T T T T R D 4 T T T T T T 35 C A 0 T T T T T T R D 5 T T T T T T 36 C A 1 T T T T T T R D 5 T T T T T T 37 C A 1 T T T T T T R D 5 T T T T T T 38 C A 1 A I A I A I R D 5 A I A I A I 39 C A 1 T T T T T T R D 6 T T T T T T 40 F A 2 T T T T T T R D 6 T T T T T T 41 S A 2 T T T T T T R D 6 T T T T T T 42 C A 2 T T T T T T R D 6 T T T T T T 43 C A 2 T T T T T T R D 7 T T T T T T 44 C A 3 T T T T T T R D 7 T T T T T T 45 C A 3 T T T T T T R D 7 T T T T T T 46 C A 3 T T T T T T R D 7 T T T T T T 47 C A 3 T T T T T T R A 0 T T T T T T 48 C I T T T T T T R A 0 T T T T T T 49 C I T T T T T T R A 0 T T T T T T 50 I I T T T T T T R A 0 T T T T T T 51 I A I A I A I A I A I A 2.3 Coding One of the problems of digital radio is to transform the human voice into digital ones and zeros. Converting analog voice to digital brings to aspects that are of concern to

PAGE 25

17 the communications engineers; these are good speech quality and use of as little as possible the limited spectrum available. In order to achieve the desire bandwidth without affecting the voice quality, the right coding must be used. 2.3.1 Waveform Coding The main steps involved in waveform coding are sampling, quantification and coding. According to the sampling theorem, fs > 2*fmax, we must sample an analog signal with a frequency at least twice as high as the highest frequency component in the analogue signal. In GSM good speech quality is achieved if we are be able to reproduce frequencies of up to 3.4kHz, meaning that the sampling frequency must be at least 6.8kHz. In the Pulse Code Modulated (PCM) system a sampling frequency of 8kHz is utilized. Quantification is a process by which the amplitude of the samples taken from an analog signal is assigned a fixed level from a set of possible levels. The more levels, the better the quality of the speech in the sampled signal. In PCM systems (e.g. POTS), the number of levels used for quantification is 256 levels. Pulse code modulation (PCM) utilizes a method called the A-law, which provides the same resolution for low as well as for high amplitudes. The GSM protocol utilizes a uniform quantification system, meaning that the different fixed amplitude levels are at equal distances from each other. The decided level of the sampled value must then be coded into binary bits. In GSM 13 bits are needed in order to be able to get a good resolution with uniform quantification [1]. A waveform can produce very good speech quality but has the drawback that is needs high bit rate to produce a good speech quality.

PAGE 26

18 2.3.2 Vocoders Another approach to speech coding is the use of a vocoder. Vocoders use filters to reconstruct speech. The idea of vocoders is that instead of sending the actual signal, it sends information about how to reconstruct the original signal. A vocoder attempts to find the filter that at certain moments neutralizes tones or segments of speech. Once that filter is found only the filter parameters are transmitted to the other end in order to create an inverse filter to reconstruct the original signal. The advantage of using a vocoder is that the bit rate needed is low as compared to waveform coding. The main disadvantage of vocoders is that it is hard to achieve the right parameters in order to produce good signal quality. The GSM protocol uses a mix of waveform coding and vocoders. This is called hybrid coding. The hybrid coder combines the best of waveform coding and vocoder technologies. The vocoder takes care of most of the information at low bit rates while the waveform coder takes care of the residual information. Using these mechanisms GSM ensures high speech quality. 2.4 Conclusion This chapter has presented an overview of the GSM network architecture and the GSM radio interface. During this chapter we have seen the different nodes of a GSM network and their function. In subsequent chapters we will see how the GSM network architecture is affected by the introduction of new services like High-Speed Circuit Switched Data and the General Packet Radio Service. This chapter has also discussed in brief the logical radio channels used when the mobile station communicates with the network. We will see how this radio interface is affected by the introduction of the new GSM services mentioned above.

PAGE 27

19 CHAPTER 3 DATA EVOLUTION IN GSM 3.1 Introduction Cellular data services are becoming the fastest growing segment of digital wireless communications. In the GSM protocol the most used data service has been the Short Messaging Service (SMS) which is used to send short 160 characters messages to other GSM phones or to electronic mail addresses in the Internet [2]. Due to the immense popularity of the Internet, manufacturers and operators have begun introducing wireless devices that allow users to browse the web on the move. In order to support these new services, the different cellular protocols introduced new data protocols and inter-working functions to operate more efficiently with existing landline networks. In this chapter, the evolution of GSM data is presented with main emphasis on circuit switched and packet data services. Figure 5 shows how GSM data has evolved from the simple 9.6 kbps towards UMTS/IMT2000 (Universal Mobile Telecommunication Systems/International Mobile Telecommunications-2000). The following are the data services discussed in this chapter: High-Speed Circuit Switched Data (HSCSD) [4] General Packet Radio Service (GPRS) [5] Enhanced Data Rates for GSM Evolution (EDGE) [6] Wideband and Hybrid Time Division CDMA (W-CDMA/TD-CDMA) [7].

PAGE 28

20 Figure 5. Data evolution in GSM 3.2 Circuit Switching Vs Packet Switching There are two main transmission methods that can be used to transmit data in a network. Both of these methods, circuit switched and packet switched, are supported by the GSM protocol. In a circuit switched connection the network allocates an exclusive resource and creates an end to end connection or circuit between the communication nodes. This circuit is reserved for the entire connection period and the resources cannot be used by another entity until the connection between the communication nodes is terminated. The typical example of a circuit switched connection is speech communication in telephone lines. A circuit switched connection is suitable for some applications but it is a waste of resources for other type of applications. Cost in a circuit switched connection is based on connection time. Examples of circuit switched connection in the GSM protocol are the 9.6 kbps service, the New Basic Rate Interface and High-Speed Circuit Switched Data. GSM Data Evolution Basic 9.6kbps Landline-like circuit services (HSCSD) Internet-like IP packet services (GPRS) GPRS with more capacity (EDGE) Introduction of UMTS/IMT2000 (WCDMA/TDCDMA) 1995 1998 1999 2000 2001-2002

PAGE 29

21 In a packet switched network the resources are shared among several users thus making a more efficient use of the network. Data is transmitted in packets that may utilize different routes to get to the destination. One of the problems of packet switched networks is quality of service. Packet switching is ideal for bursty traffic and unsuitable for real time applications like video. The General Packet Radio Service is the prime example of packet switching in the GSM protocol. 3.3 Data Inter-working The GSM standard defines data inter-working functions with the Integrated Services Digital Network (ISDN), Public Switched Telephone Network (PSTN), packet switched data networks (PSPDN), circuit switched data network (CSPDN) and direct access networks. The interface with the PSTN is made by modems located in the Mobile Switching Center Inter-Working Function (MSC-IWF). ISDN-GSM inter-working has become one of the most important data services in GSM. The advantage of ISDN-GSM data call over a PSTN-GSM data call is that the entire ISDN-GSM interface is digital, therefore connection time establishment is significantly lower than that of a GSM-PSTN data call. In most situations PSTN-GSM data connection takes an average of 25 seconds while a GSM-ISDN connection typically takes less than 10 seconds [8]. 3.4 Early GSM Data During 1995 GSM operators began offering 9.6 kbps circuit switched data services. For the first time GSM users were able to use this connection for file transfer, access to Internet and e-mail/facsimile transmission by connecting the mobile station to a data terminal. These first applications were limited by the connection speed and commercially did not grow as expected. Some of the problems with a 9.6 kbps circuit switch connection are the following:

PAGE 30

22 Cost: a user will be charged for connection time and not for the amount of data transmitted during the circuit switched call. A connection of 9.6 kbps makes data transmission very slow for applications like the worldwide web. This has a direct impact on cost. Capacity: in GSM a carrier has 8 TDMA slots. During a circuit switched call a mobile station has one dedicated up-link and downlink slot. Only 50% of the resources for that connection are used because only one direction of the link is employed at a time. Connection: long establishment time. Performance: only 9.6 kbps. As mentioned before a 9.6 kbps is very limited and is unsuitable for high volume data calls. 3.5 First GSM Data Transmission Enhancement The need for more bandwidth for data services became the main motivation for the first GSM data rate improvement. The new basic data rate of 14.4 kbps was created in order to have more bandwidth to support applications like Internet access and multimedia and also to remain competitive with other standards like IS-95 (CDMA) that already offered 14.4 kbps as the basic data rate. The New Basic Rate Interface of 14.4 kbps was approved by ETSI in February 1997. The Basic Rate Interface boosts the speed of one GSM time slot from 9.6 kbps to 14.4 kbps by puncturing error correction bits from the existing channel coding scheme used in the 9.6 kbps connection. The new basic rate meant that users would have a 50% improvement in the data transmission speed. 3.6 High-Speed Circuit Switched Data Currently the data transmission methods used in landline telephone networks are better than the ones in GSM. As mentioned in previous sections, traditional GSM circuit switched data (9.6 kpbs and 14.4 kbps) supports one user per channel per GSM time slot.

PAGE 31

23 These data rates are inadequate and insufficient to support the services that a landline user is accustomed to, e.g. Internet browsing. The interest for higher speed wireless data services was the main reason the ETSI approved and promoted the standardization of a new data service with higher data rates and faster access called High-Speed Circuit Switched Data (HSCSD) [4]. HSCSD was introduced commercially in 1998 as part of GSM phase 2+, release 96. This new technology provides higher data rates by combining GSM time slots and by making use of the basic rate interface of 14.4 kbps per slot. Data rates in multiples of 9.6 kbps or 14.4 kbps provide GSM data users a variety of new bits rate ranging from 9.6 kbps to 57.6 kbps. Due to its high-speed circuit switched service, HSCSD is an appropriate tool when real time components are required for user applications, e.g. video conferencing. As presented in chapter 2, the available bandwidth in GSM is divided into carriers of 200kHz. Each of these carries supports a time division multiple access scheme based on 8 time slot frames. A full rate traffic channel (TCH/F) uses one time slot per frame and always provides data services at 9.6 kbps or 14.4 kbps (depending on coding). In GSM, data services functionality are handled by the Terminal Adapter Functions (which is software that resides in the mobile station) and the Inter-Working Functions (IWF) of the Mobile Switching Center (IWF-MSC) [4]. The TAF achieves adaptation between the data terminal and the MS. The IWF provides the required adaptation between the GSM network and external networks. The architecture of HSCSD is fully aligned with the GSM standard air interface at the physical layer and the only requirement for operators that wish to support HSCSD is a

PAGE 32

24 software upgrade to their network components; no additional network nodes or hardware is required. In High-Speed Circuit Switched Data a multi-slot connection consists of multiple independent sub channels between the MS-TAF and the MSC-IWF [4]. On the “ A ” interface, the use of resources is restricted to one 64 kbps circuit. As seen in Figure 6, this requirement is met by multiplexing the data streams into one “ A ” interface circuit. New functions are introduced in the MS and the network side to provide the mechanisms for combining and splitting the data into separate parallel sub-streams. These streams are transferred over the air interface via “ n ” channels called HSCSD channels; where n goes from 1 to 8 [4]. The air interface resources are allocated to an HSCSD-call in steps of one full rate traffic channel. As a minimum, one full rate traffic channel is allocated. Due to physical constraints, all slots allocated to a HSCSD call must belong to the same carrier. As mentioned before, HSCSD supports up to eight TDMA time slots. The reality is that most GSM operators will most likely use 2 to 4 TDMA slots when offering HSCSD [9]. The reasons for this limitation are the MS and a tradeoff between system capacity and bit rates. Table 3 shows the different bit rates for 9.6 kbps and 14.4 kbps per slot respectively. Both transparent and non-transparent services are supported in HSCSD. The transparent service in HSCSD is based on the Recommendation V.110, which has been specified for ISDN. With transparent transmission HSCSD offers constant bit rates and transmission delays, which is very useful for applications like video. The non-transparent data service is based on the GSM Radio Link Protocol (RLP) between the MS and the

PAGE 33

25 IWF. If the service used is transparent and requires 4 time slots, the 4 time slots must always be available for the user. Communication will be lost if the user moves to a cell that does not have 4 time slots available for communication. Figure 6. Network architecture for High-Speed Circuit Switched Data Table 3. Bit rates for 9.6 kbps and 14.4 kbps channel coding Time slots used 9.6 kbps channel coding 14.4 kbps channel coding 1 9.6 kbps 14.4 kbps 2 19.2 kbps 28.8 kbps 3 28.8 kpbs 48.2 kbps 4 38.4 kbps 57.6 kbps In the other hand, there is no problem losing the communication with nontransparent transmission when switching to another cell because the network will always guarantee at least one time slot for communication. In this case reduction of data rate is possible. N full rate traffic channels or n time slots per TDMA frame 1 circuit BSC Mobile Station BTS Air I/F Abis I/F PSTN ISDN A I/F MSC/VLR

PAGE 34

26 In the HSCSD the transfer of data can be symmetric or asymmetric. An asymmetric configuration means that a user will be assigned more time slots in one direction, usually the downlink direction. This is particularly useful for applications like a TCP/IP session in which most of the data is transferred from the network to the mobile station. In these cases a rate of 9.6 kbps or 14.4 kbps will be sufficient for the uplink direction. An asymmetric connection of 3 time slots in the downlink and 1 slot in the uplink is referred to as 3+1 connection. In the case of a symmetric configuration the user rates are the same in the uplink and downlink direction. In order to use HSCSD users must subscribe to the General Bearer Services introduced in GSM phase 2+. Higher capacity opens the door for new applications like wireless imaging, multimedia and all kind of applications that require real time data transfer. These applications have a common need for a continuous flow of information over the connection. High-Speed Circuit Switched Data provides an optimal circuit switched connection like ISDN on the land line side. High-Speed Circuit Switched Data has the following benefits: Wireless data at par with existing land line data, i.e. ISDN. Higher transmission rates (up to 6 time 9.6 kbps) and minor operator investment. Works similar to the 9.6 kbps connection. Simple to implement for network operators. The HSCSD does not require the user to learn a new data service. It is similar to the existing 9.6 kbps but substantially faster. Due to the nature of its circuit switched oriented service, the HSCSD has some disadvantages: Costly when high bit rates are desired (more channels allocated)

PAGE 35

27 Charged on connection time rather than data traffic Inefficient use of the system resources (traffic channels) for applications that are bursty in nature, i.e. Internet browsing. 3.7 The General Packet Radio Service Protocol The GSM protocol was designed with voice and data capabilities; mainly circuit switched data. Discussions of packet data service in GSM started in 1992/1993. GPRS was finally approved and incorporated in the ETSI release 97. Corrections and minor improvements continue as of today. The main driving forces for GPRS are as follows: Predictions of increase in mobile data communications made operators aware that a packet data solution was desperately needed in GSM. New market segments and improved competition with other mobile networks. More efficient use of the radio resources with packet switched data. Existing circuit switch data solutions in GSM are too expensive for applications that make use of bursty traffic. Re-use of already existing network with worldwide coverage. More data rates: maximum GPRS data rate is 171.2 kbps. 3.7.1 Network Architecture In order to introduce GPRS, modifications of the GSM network were required. Two new nodes were added to the network to provide packet data support and interface with other packet switch data networks (PSDPN). These two nodes are the Serving GPRS Support Node (SGSN) and the Gateway GPRS Support Node (GGSN). In addition, this technology requires the development of new mobile phones. Figure 7 shows all the nodes and interfaces defined for GPRS [5]. With the exception of the SGSN, the GGSN, and the

PAGE 36

28 introduction of the Packet Control Unit (PCU), all other nodes in this figure are described in chapter 2 of this document. The GGSN is the gateway node between an external packet data networks (i.e. IP and X.25) and the GPRS network. An interface, called the Gi interface, is used to communicate with external packet data networks. In the case of an external IP network, the GGSN is seen as a router serving all IP addresses of mobile stations in the GPRS network. The SGSN interfaces between the GPRS backbone and the radio access network. It also switches the packets to the correct base station subsystem (BSS). The SGSN tasks include ciphering and authentication of mobile stations, session management, mobility management of mobile stations, quality of service functions, collection of charging information (packet data usage) and logical link management of the mobile stations. The SGSN has interfaces to the HLR and MSC/VLR that are required for accessing subscriber data and to update subscriber location and information. As discussed before, this information is used to determine the type of services that a customer should receive. The SGNS and GGSN are connected by an IP based GPRS backbone. The GSM Base Station Subsystem (BSS) is used as a shared resource by circuit switched and packet switched network elements to ensure backward compatibility. In order to support packet data transmission a Packet Control Unit (PCU) was added to the BSS. The PCU function is to set up, supervise and disconnect packet-switched calls. The PCU also includes support for cell change, radio resource configuration and channel assignment.

PAGE 37

29 Figure 7. The GPRS Network architecture 3.7.2 Air Interface and Protocol Reference Model The GPRS protocol complies with the standard TDMA scheme of GSM. In other words the burst structure of GPRS is compatible to that of GSM. A special multiframe structure as well as new physical and logical channels are defined for GPRS. The following are the main features of the GPRS air interface: The GSM separation of 200kHz per channel is maintained and the TDMA structure of 8 time slots used in GSM is also used in GPRS. Information is transferred in access bursts and normal bursts. Radio resources shared dynamically between GSM and GPRS. New channel coding allows for higher data rates. Users reserve the traffic channel only when transmission or reception of data is needed. PSTN/ ISDN PSPDN Gb Gn Gi MAP-D Gs (optional) Gr Gc (optional) MSC/VLR HLR BSS SGSN GGSN EIR SMS-SC GPRS backbone Gn

PAGE 38

30 Up and downlink channels are allocated separately. Multi slot configurations which allow for data rates as high as 171 kbps. The physical channel dedicated to GPRS is called the Packet Data Channel (PDCH). A PDCH is a time slot on a GSM RF carrier. In a GSM cell none, one or several physical channels may be allocated for GPRS resources. Allocation of physical channels for regular circuit switch calls and GPRS packet data is performed dynamically according to a principle of capacity in demand. As discussed in chapter 2, in GSM there are around ten different logical channels that are used to transfer different kind of information between the mobile and the network. With GPRS a new set of logical channels is defined. Most of these channels provide the same functionality as the ones used in regular GSM. The GPRS logical channels are called logical packet data channels; these are denoted with a starting letter P. The new packet logical channels are divided in four groups: Packet Common Control Channel (PCCH): this channel group contains the Packet Random Access Channel (PRACH), the paging channel (PPCH) and the Packet Access Grant Channel (PAGCH). All these channels provide the same functionality as in regular GSM. Packet Broadcast Control Channel (PBCCH): this channel is transmitted only in the downlink direction and it is used to transmit system information. This channel provides GPRS specific information. Packet Dedicated Control Channels (PDCCH): this category comprises the following logical channels: Packet Associated Control Channel (PACCH), Packet Timing Advance Control Channel: Up link (PTCCH/U) and Packet Timing Advance Control Channel: Downlink (PTCCH/D). The PTCCH channels are used for time in advance information and the PACCH transmit signaling information like acknowledgements and power control. Packet Data Traffic Channels (PDTCH) – this channel (up link and down link) is used to transmit the user ’ s packet data.

PAGE 39

31 In addition to the logical channels mentioned above, the GPRS mobile stations make use of the FCCH, SCH and BCCH channels discussed in chapter 2. GPRS utilizes a set of protocols modeled after the ISO-OSI (International Standards Organization-Open Systems Interconnection) model. Figure 8 shows the protocols used in the various layers of the different network nodes [5]. Three protocols are used to control the link between the mobile station (MS) and the SGSN: the Subnetwork Dependent Convergence Protocol (SNDCP) [10], the Logical Link Control Protocol (LLC) [11], and the Radio Link Control/Medium Access Protocol (RLC/MAC) [12]. Figure 8. Protocol Reference Model The SNDCP protocol provides convergence functionality to map different protocols into a single LLC link. The SNDCP multiplexes packets from different protocols (i.e. TCP/IP, UDP/IP, and X.25). It also compresses and segments packets that are larger than the maximum LLC packet size. GSM R F MA C RL C LL C SNDC P IP/X.25 Application M S GSM R F MA C RL C LLC Relay BSSGP Frame Relay L1 bis BS S LL C BSSG P Frame Relay L1 bis L1 L2 IP UDP/TCP SNDC P GT P SGS N IP/X.25 GT P UDP/TCP IP L2 L1 GGS N Um Gb Gn

PAGE 40

32 The LLC protocol establishes a logical link between the MS and SGSN. The LLC has two operating modes, unacknowledged mode and acknowledged mode. In unacknowledged mode, the LLC does not handle packet loses, while in acknowledged mode the LLC applies retransmission and flow control to ensure that packets are delivered. The LLC also takes care of ciphering procedures between the MS and the network. The Medium Access Control protocol (MAC) is used to share the radio channels between multiple mobile stations and to allocate a physical channel for the MS when needed. These channels can be standard GSM of GPRS channels. The GPRS backbone used to communicate between multiple SGSN and GGSN is the Internet. In Figure 7 we see that a GPRS tunneling protocol (GTP) is used to tunnel the TCP/IP packets that are transmitted between network nodes. The physical layer consists of two sub layers; the physical RF layer which handles all the modulation/demodulation and the physical link layer which is responsible for channel coding, rectangular interleaving, radio link control procedures and detection of congestion. Table 4 shows the different channel coding schemes used in GPRS. In theory GPRS can achieve a data rate of up to 171.2 kbps by using 8 GSM TDMA slots and coding scheme 4 (CS-4). Available GPRS phones in the market utilize CS-1 and CS-2 and can achieve a maximum data rate of approximately 50 kbps by using 4 time slots with CS-2. Figure 9 shows the encapsulation and segmentation that occurs across the different layers. The LLC layer utilizes the High-Level Data Link Control protocol

PAGE 41

33 (HDLC), to frame SNDCP packets. The LLC frames have a maximum size of 1600 octets and are passed to the RLC layer. The RLC layer takes care of segmenting the LLC frames into smaller RLC blocks suitable for over the air transmission. The size of the RLC block depends on the type of coding scheme. In order to ensure successful delivery of RLC blocks, a sliding window flow control mechanism and Automatic Repeat Request (ARQ) are utilized. These provide a reliable link between the MS and the BSS. One RLC block is transmitted in four consecutive bursts according to the TDMA structure used in GSM. Interleaving is also used in the RLC blocks. Table 4. Data rates for the different GPRS coding schemes Coding Scheme Data Rate How is it achieved? CS-1 9.05 kbps Half rate convolutional code used in regular GSM SDCCH channel. CS-2 13.4 kbps Puncturing applied to CS-1 CS-3 15.6 kbps More puncturing CS-4 21.4 kbps No forward error correction GPRS Mobile Stations differ in many ways from regular circuit switched mobile stations. A GPRS MS is described by its mode of operation and its multi slot capability. The modes of operation defined for a GPRS MS are the following: Class A, Class B and Class C. The actual mode of operation depends in the MS and network capabilities. Class A MS can operate GPRS and GSM services simultaneously. Class B MS can only operate one of the services at a time, but it has the ability to monitor control channels for both services at the same time. Class C MS can only use one of the services at a time. The multi slot capabilities of a GPRS MS refer to the number of time slots that can be used simultaneously for data transfer. A multi slot capable MS is either of type 1 or type 2. A type 1 MS is not required to transmit and receive at the same time, while a

PAGE 42

34 type 2 must be able to receive and transmit simultaneously. The number of slots (multi slot) used in downlink and uplink channels can be different. As an example commercially available GPRS Mobile Stations use 1 to 4 slots for downlink transmission and 1 slot for uplink transmission [13]. Figure 9. Frames and packets in GPRS When a GPRS mobile station wants to transmit data, it must initiate what is called the attach procedure. Mobile stations can attach at power up or can attach manually when an application has selected GPRS as the bearer. The GPRS attach procedure is used to create a logical link between the mobile station and the SGSN. The mobile station or the network can request PDP (Packet Data Protocol) context activation once the attach procedure has been completed. Uplink: The SNDCP packet is fragmented if it exceeds the maximum size of the LLC frame. Downlink: receives SN-PDUs from LLC. Buffers until the N-PDU is completed. Uplink: Formats the SN-PDUs: Adds frame header and FCS. Downlink: Acknowledges frames and requests retransmissions. RLC Produces a complete LLC frame (from all the LLC segments) IP header TCP or UDP header Data IP header TCP or UDP header Data SNDC header IP header TCP or UDP header Data SNDC header CF AF FCS MAC header RLC header data spare MAC header RLC header data spare Multiple MAC/RLC frames that form a complete LLC frame ....... 1 1 to 3 ~140 to 1520 3

PAGE 43

35 MS SGSN GGSN Activate PDP Context Req. Create PDP Context Req. NSAPI, TI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Config Options PDP Type, PDP Address, Access Point Name, QoS Negotiated, TID, Selection Mode, PDP Config Options Create PDP Context Resp. Activate PDP Context Acc. PDP Type, PDP Address, TI, QoS Negotiated, Radio Priority, PDP Config Options TID, PDP Address, BB Protocol, Reordering Required, PDP Configuration Options, QoS Negotiated, Charging Id, Cause Figure 10. PDP Context Activation During PDP context activation, the mobile station receives a static or dynamic PDP address. The home operator assigns static addresses as part of the user ’ s subscription. The home PLMN is the one that has the information about the subscription of the particular mobile requesting the address. In the case of dynamic addresses, either the visiting PLMN or the home PLMN can assign the addresses. The network node responsible for allocating dynamic addresses is the GGSN. A PDP address is typically an IP address and it is assigned to the mobile station when applications like email and Internet browsing request PDP context activation. Figure 10 shows the information sent and received during PDP context activation [5].

PAGE 44

36 3.8 Conclusion In this chapter we have seen how the data services in GSM have evolved from 9.6 kbps all the way to the High-Speed Circuit Switched Data and the General Packet Radio Service. The main emphasis of this chapter was to describe to the user the operation of the General Packet Radio Services. High-Speed Circuit Switched Data is not a new technology; it is basically an enhancement to the existing GSM network. Instead of using one time slot of the 8 time slots available on a GSM frame, HSCSD makes use of up to 4 time slots at a time. In contrast to the 9.6 kbps and 14.4 kbps provided by regular GSM, HSCSD can provide up to 57.6 kbps if 4 time slots are used. The drawbacks with HSCSD are that time slots are reserved even if nothing is transmitted, system capacity is reduced when multiple slots of the GSM system are used and due to the multiple slots usage HSCSD ends up being expensive for the end user. The General Packet Radio Services is the packet switched mechanism in GSM. The introduction of GPRS brings many benefits to the GPRS network. Some of these benefits include: efficient usage of the system resources, higher data rates than those in HSCSD, fast setup and access times, coexistence of circuit and packet switched services in one mobile network, volume based charges instead of connection based charges and user differentiation based on quality of service. Chapter 5 will concentrate on performance analysis of TCP over packet data in GSM with emphasis on GPRS. Chapter 4 will serve to introduce the readers to the TCP and IP protocols.

PAGE 45

37 CHAPTER 4 GSM AND THE INTERNET PROTOCOLS 4.1 Introduction This chapter provides an introduction to the protocols used in the transport and network layers of existing packet-based networks. The Internet Protocol (IP) is one of the network layer protocols of the TCP/IP family. The Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) are the transport layer protocols [14]. This chapter will also provide the basis for the performance discussion of chapter 5 which is how TCP based applications perform over wireless, specifically GSM circuit switched and GPRS. 4.2 Origin of the TCP/IP Protocol The beginnings of the TCP/IP family of protocols is traced back to the 1960s and the 1970s when the Advanced Research Projects Agency (ARPA) of the US government Department of Defense (DoD) sponsored the development of a network called the ARPANET. The ARPANET used TCP/IP, originally called “ DARPA Internet protocol suite ” as the standard protocol family [14]. The TCP/IP family of protocols is used on the Internet, in private industries, government systems, fixed networks and on wireless data networks. Although we refer to the protocol family as TCP/IP, there are more members in this family of protocols. Figure 11 shows the Open Systems Interconnection model (OSI) and their relationship with the TCP/IP protocols. In this figure we can also see the different protocols in the TCP/IP family.

PAGE 46

38 Table 5. Open Systems Interconnect model and the Internet Protocol OSI Layers Internet Protocols Suite 7 Application FTP, TELNET, TFTP, SMTP 6 Presentation 5 Session 4 Transport TCP, UDP 3 Network IP, ICMP, ARP, RARP 2 Data Link Hardware Interface 1 Physical 4.2.1 The Internet Protocol The IP protocol is a network layer protocol used to provide a connectionless delivery system. It is called “ connectionless ” because it considers each packet to be a different entity. It is also an unreliable protocol because there is no guarantee that the IP packets will be delivered to its intended destination or that the IP packets will be delivered correctly. The upper layers are in charge of providing reliability and association between each IP packet. The IP protocol mainly takes care of the following tasks: handle routing of packets through a network (Internet), fragmentation of packets, and elementary flow control to indicate if packets are arriving too fast to the destination. An IP packet is normally fragmented into smaller packets. Due to its unreliable nature, the IP protocol needs a higher layer protocol to provide end to end reliability. The Transmission Control Protocol (TCP) is the transport layer protocol normally used to provide this end to end reliability. The TCP/IP protocol is the most popular protocol for non real time data transmission.

PAGE 47

39 4.2.1.1 Addressing As in other protocol suites, IP defines the types of addresses that are used to identify networks and computers. An IP address is a 32 bit binary number and encodes the host and network identification. Every host on the network must have a unique IP address. There are four types of IP addresses; these are shown on Figure 12. Figure 11. Types of IP addresses and formats Class A addresses are used for those networks that have a lot of hosts on a single network. Class C addresses allow for more networks but fewer hosts. A source and a destination address can be of type A, B or C. 4.2.1.2 Internet Protocol Datagrams Each IP datagram consists of 20 bytes stacked by five 32-bit words. Every datagram contains the address of the source host and the destination host. A protocol field indicates the high level protocol responsible for the data carried in this datagram (i.e., 0 Network ID Host ID 24 bits 7 bits Class A Class B 1 0 Network ID Host ID 16 bits 14 bits Class C 1 1 0 Network ID Host ID 8 bits 21 bits Class D 1 1 1 0 Multicast Address 28 bits

PAGE 48

40 TCP, UDP). The datagram also has a “ Time to Live ” field that specifies how long a datagram is allowed to move through the network. It also has provisions for packet fragmentation. For a detailed explanation of each of the fields in an IP datagram refer to [14]. 4.2.2 The Transport Layer Protocols The Transmission Control Protocol (TCP), provides a connection oriented reliable stream to an application program. A connection-oriented service requires that the source and destination hosts establish a logical connection between each other before communication can take place. The TCP protocol handles the establishment and termination of a connection between two hosts, the re ordering of out of order data, the end to end reliability and the end to end flow control. In TCP segments are sent as Internet protocol datagrams. A TCP header follows the Internet Protocol header. Figure 12 shows the information carried in a TCP header. Note that each word in the table below contains 32 bits of information. In Chapter 5 we will study the information in this header in order to analyze the performance of TCP over wireless links, i.e. GPRS network. The first word of the TCP header contains the source and destination addresses. The sequence and acknowledgement number fields follow the address. Every octet is sequenced such that each of them can be acknowledged. The acknowledgment mechanism employed is cumulative. An acknowledgment of sequence number A indicates that all octets up to but not including A have been received. This mechanism allows for straightforward duplicate detection in the presence of packet retransmission. The acknowledgement number field is present only if the ACK control bit is set. The control fields SYN and FIN are used only when the connection is opened or closed. For

PAGE 49

41 sequence number purposes, the SYN appears before the first actual data octet of the segment in which it occurs. The FIN is considered to happen after the last actual data octet in the segment in which it occurs. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Source Port Destination Port Sequence Number Acknowledge Number Data Offset Reserved U R G A C K P S H R S T S Y N F I N Window Checksum Urgent Pointer Options Padding Data Figure 12. The TCP header format The UDP (User Datagram Protocol) protocol provides a connection-less, unreliable datagram service. It only provides source and destination port numbers and an optional checksum used to verify the contents of the IP packet. 4.3 Mobile Station Data Access As we have previously discussed, a GPRS user is charged by the number of bytes transmitted over the link and not by the connection time. Therefore one of the most important difference between GPRS and CSD is that GPRS acts like a LAN-like connection and not as a modem connection. The GPRS protocol provides support for IP-based services by using the standard AT commands that are provided for modem communication [15]. Normally these AT commands are used to control modems in order to establish a circuit switched connection over the Public Switched Telephone Network (PSTN). The creators of GPRS added an

PAGE 50

42 extended AT command set to support all the GPRS functionality. These new commands support GPRS attach/detach, PDP context activation/deactivation, quality of service negotiation and other GPRS features [15]. Mobiles supporting GPRS can work as standalone web browsers or as adapters to a Personal Computer (PC) or Personal Digital Assistant (PDA). When GPRS is used with a PC or PDA (using Infrared or RS232), AT commands are used to communicate between the mobile and the PC. For example, when a PC user wants to use a mobile to do wireless internet access, the user (or the program running on the PC) issues a special AT command, to do GPRS context activation. The special command is ATD*99*#, where is the context activation identifier. After the context activation procedure is completed, the mobile receives an IP address and can start a TCP/IP session. 4.4 Wireless Environment Issues and TCP The TCP/IP family of protocols was not designed for wireless environments. Traditionally networking engineers have focused their attention on wireline networks. With the introduction of GPRS, engineers were faced with requirements of providing optimal support for Internet applications. Highly sophisticated protocols were developed to optimize data transmission over the radio interface. A wireless environment can have poor radio channel characteristics that can lead to packet loses. As we know, TCP is the most widely used transport protocol for non real time applications like the world wide web, file transfer and electronic mail. In TCP, segment loses are interpreted as congestion signals caused by buffer overflows in routers. When an event like this is detected, TCP adjust parameters like window size and retransmission timeouts to slow down the connection [16].

PAGE 51

43 In a wireless environment, poor radio channels can lead to packet loses or long packet delays. When this happens, TCP timeouts are frequent and the basic assumption of congestion is wrong. As a result, the measures taken by TCP will not be optimal; packet loses were not caused by congestion, thereby constant retransmission may occur. To minimize these problems GPRS provides a Radio Link Control (RLC) mode [12]. Also, as discussed previously, four different coding schemes were standardized to cope with different radio channel environments. 4.5 Conclusion In this chapter we have provided an overview of the TCP/IP protocol. We have provided the fundaments that will help us understand the performance analysis discussed in Chapter 5. Questions like, How Internet applications perform over GPRS? How do GPRS compares to a CSD bearer? And most important, What is the Performance of TCP/IP over GPRS?

PAGE 52

44 CHAPTER 5 PERFORMANCE OF TCP OVER GPRS 5.1 Introduction As discussed in previous chapters, GPRS is an extension of GSM that can provide packet data services of more than 100 kbps. In comparison, CSD GSM provides data rates up to 14.4 kbps. The majority of the services provided by GPRS are Internet related. A close interaction between the GPRS protocol and the TCP/IP family of protocols is necessary in order to achieve a performance comparable to that of wire line networks. The TCP protocol performs well in fixed networks in which the majority of the packet loses are caused by network congestion. In this chapter we will evaluate the performance of TCP over GPRS under scenarios in which packet loses can occur due to cell reselection (mobile user), low/fading signal and high packet delays due to busy network. We will compare these scenarios with the case in which the GPRS handset is not mobile and is located in a strong signal area. A performance analysis of TCP over GPRS using simulations is detailed in M. Myers paper [16]. The experiments in this thesis will confirm the theoretical results found in Myers simulations. At the end of this chapter the TCP Eifel algorithm [17], the TCP Selective Acknowledgements option, SACK [18], and TCP Timestamps option [18] will be presented as possible solutions to improve the performance of TCP in wireless networks. 5.2 Measurement Tools The experiments in this chapter were conducted utilizing the Motorola Timeport GPRS phone [13], a GPRS provisioned VoiceStream SIM card, South Florida ’ s

PAGE 53

45 VoiceStream GPRS network and the field engineering mode of the phone. The fieldengineering mode provides information about the configuration of the cellular network as well as data sent and received by the phone. The tools used to measure and analyze TCP packets were WinDump [19], TCPTrace [20] and UNIX ’ s plotting tool Xplot. WinDump is a packet-capturing tool that can sniff and capture a variety of protocols including TCP and IP. TCPTrace is a UNIX tool written in the University of Ohio that analyzes and produces graphs of the information contained in traces captured with WinDump. The graphs in this chapter were created using Xplot. FTP was the application used for bulk data transfers, WWW and PING were used to check for packet delays and loses in the different channel environments were the experiments were conducted. Data collected using WinDump will be analyzed to determine actual bit rates versus theoretical rates, TCP performance and effect of network conditions on packet transfer. The effect of lower layers in TCP performance will also be discussed. 5.3 General Packet Radio Services RF Modem Figure 13 shows the typical connection for a GPRS RF Modem. The mobile unit is physically connected to the PC via Infrared, USB or an RS232 link. The GPRS RF modem used to take the measurements supports GPRS coding schemes CS-1 and CS-2 (see Chapter 3 for more details on the coding schemes) and three downlink and one uplink slots. On the PC side a program is used to command the mobile to establish a GPRS PDP context thereby initiating a GPRS session. Figure 14 shows a snapshot of the program used to accomplish this and Figure 15 shows the Motorola GPRS phone used to conduct the experiments (shown in GPRS attached mode). Once the PDP context is established, the mobile receives an IP address from the network. Then the mobile and the

PAGE 54

46 PC establish a PPP (Point to Point Protocol) session. At this point applications in the PC can utilize the link created with the GPRS RF modem. Infrared or serial link (USB or RS232) GPRS Network The Internet Personal Computer Figure 13. A GPRS RF modem Figure 14. The iStream GPRS software

PAGE 55

47 Figure 15. First GPRS phone, Motorola ’ s Timeport, attached to VStream network. The entire initialization and hang-up sequence of the GPRS modem is performed utilizing AT modem commands created specifically for GSM and GPRS; these are defined in ETSI documents [15]. The listing in Appendix A was created monitoring the data in the serial port of the PC in order to take a snapshot of the AT commands sent to/from the mobile. In summary, the sequence of commands is as follows: Flow control between the PC and the mobile is established. The PC performs a check to make sure that the mobile is GPRS attached utilizing the

PAGE 56

48 command AT+CGATT? If the mobile is attached to the GPRS network, the PC will perform a PDP context ID request. In this procedure two parameters will be sent to the network: the packet network protocol to use, namely X.25 or IP, and the Access Point Name for the GGSN. This command can be seen in the logs in Appendix A. The following is the syntax of the command: AT+CGDCONT=1,"IP","internet3.voicestream.com",,0,0. Before the actual GPRS “ call ” is made, the PC indicates to the network the minimal quality of service required. This is done with AT+CGQMIN=1,0,0,3,0,0. Once the mobile has the context id and the quality of service has been negotiated, the mobile will perform a PDP context activation procedure using the command ATD*99#. When successful the PC will command the mobile to switch from command mode (mode in which mobile accepts AT commands) to GPRS data mode. During GPRS data mode the PC receives the IP address assigned to the mobile in a PPP packet. Besides higher data rates, an important advantage of a GPRS modem over a CSD modem is the faster setup/connection time. As we can see in the example data in Appendix A, the total time from initial modem setup to GPRS connected is approximately 6 seconds. This is the time between the GPRS attached query to the radio and the establishment of the PPP session with the PC. This is extremely fast when compared to dial up connections using circuit switched data calls (CSD) over cellular networks. A CSD data call over cellular networks is for all practical purposes very close in connection time to that of modems in PSTN. 5.4 Measurements of Bulk Data Download In order to analyze the performance of TCP over GPRS three different environments were chosen. These environments are strong signal no mobility, weak signal no mobility and strong signal in a mobile environment (i.e. traveling on a car). During each experiment, FTP was used to download a 300Kbytes picture (GIF) from an anonymous server in a California university ( ftp.cecm.sfu.ca) . This file was downloaded

PAGE 57

49 several times to take average measurements of throughput, retransmissions and round trip times (RTT). During the download session, WinDump was used to trace the packets sent and received by the GPRS RF Modem and TCPTrace was used to analyze the output of WinDump. The entire log files for each experiment can be found in Appendix B. 5.4.1 Data Download in Strong Signal During this experiment a total of 1031 TCP packets were traced in 2 TCP connections. The assigned IP address received by the GPRS mobile was 216.155.173.39 and the anonymous FTP server IP address was 142.58.12.69. The second TCP connection contains the ftp data for the 300Kbyte image. Figure 16 shows the throughput of this connection. The Y-axis represents throughput and the Xaxis represents time. Throughput is shown as instantaneous throughput (yellow dots), average throughput (blue line) and average throughput over the last 10 instantaneous samples (red line). In this connection we can see that the average throughput was 2133Bytes/sec (17.064 kbps). Figure 17 shows that no TCP sequence numbers were retransmitted during the time of the connection. The white line shows segments sent and the yellow line indicates the receive window advertised by the receiver. Figure 16. Throughput in strong signal

PAGE 58

50 Figure 17. Receiver trace in strong signal 5.4.2 Data Download in a Mobile Environment This experiment is the same as in the previous section with the difference that it was conducted in a mobile environment. In order to determine where the cell handovers would occur, a program called Enhanced Field Engineering Mode (EFEM) was used. This program is part of the GPRS handset and operators use it to test different parameters of the cellular network and the mobile. The results of this experiment were consistent with those of the no mobility case indicating that the cell reselection did not have any effect on the performance of TCP during the GPRS download. The average throughput during this experiment was 2109 Bytes/sec (16.872 kbps) and there were no retransmitted packets. Figures 18 and 19 show the throughput and time sequence graphs.

PAGE 59

51 Figure 18. Throughtput while cell reselecting Figure 19. Time-sequence graph for mobile environment 5.4.3 Data Download in a Weak Signal Environment The third experiment was conducted in an environment were the signal was weak. In this case, the number of signal strength bars in the radio varied from 1 to 0. This

PAGE 60

52 experiment was conducted to investigate the data flow in a bad channel environment. The file was downloaded from the same ftp anonymous site. The average throughput was 1878 Bytes/sec (15.024 kbps). The decrease in throughput was caused by the amount of TCP packets that had to be retransmitted. Approximately 5.2% of the packets were retransmitted from host 142.58.12.69 (see data in Appendix B). Figure 20 shows the throughput graphs and Figure 21 shows the timesequence graphs. In Figure 21 we can observe where the retransmission of packets occurred. Retransmitted packets are marked with the letter R. Figure 20. Throughput graph in weak signal environment In Figures 20 through 23 we can observe that during the first minute of the download the throughput remains low (500Kbytes/sec). During this period there are lots of retransmissions. The change in the slope of the curve in the time-sequence graphs shows the instances in which the throughput decreased. The letter “ R ” represents places in which retransmission of packets took place.

PAGE 61

53 Figure 21. Ttime-sequence graph for bad channel environment Figure 22. Time-sequence graph showing retransmitted packets

PAGE 62

54 The time-sequence graph in Figure 23 is a zoomed version of Figure 22. In this graph we can clearly see the retransmitted segments (red arrows with the letter “ R ” ). We can also observe, by looking at the green ticks below the green line, that duplicate acknowledgements were received for such sequence number. The number “ 3 ” indicates that three duplicate acknowledgements took place. The following snapshot of the trace captured by WinDump reveals the occurrence of the first retransmitted set of packets and Go-Back-N retransmission (more in Appendix B): 09:05:25.985431 142.58.12.69.20 > 216.155.171.38.1269: . 16897:17409(512) ack 1 win 61440 [tos 0x8] 09:05:25.998600 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:33.569829 142.58.12.69.20 > 216.155.171.38.1269: . 18433:18945(512) ack 1 win 61440 [tos 0x8] 09:05:33.577451 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:33.991109 142.58.12.69.20 > 216.155.171.38.1269: . 18945:19457(512) ack 1 win 61440 [tos 0x8] 09:05:34.003263 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:34.435700 142.58.12.69.20 > 216.155.171.38.1269: . 19457:19969(512) ack 1 win 61440 [tos 0x8] 09:05:34.448245 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:34.859515 142.58.12.69.20 > 216.155.171.38.1269: . 19969:20481(512) ack 1 win 61440 [tos 0x8] 09:05:34.868228 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF)

PAGE 63

55 09:05:35.272366 142.58.12.69.20 > 216.155.171.38.1269: . 20481:20993(512) ack 1 win 61440 [tos 0x8] 09:05:35.283213 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:35.723703 142.58.12.69.20 > 216.155.171.38.1269: . 20993:21505(512) ack 1 win 61440 [tos 0x8] 09:05:35.733194 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) Figure 23. Time-sequence graph, zoomed version 5.4.4 Bulk Data Download Measurement Analysis The purpose of the experiments in the previous section was to find out how throughput and transmission of TCP segments is affected by channel conditions. As it can be seen in sections 5.4.1 and 5.4.2, under good channel conditions, even if the user is mobile, TCP perceives a constant data flow; not a single timeout or retransmission

PAGE 64

56 occurred. In the other case, in section 5.3.3 we observed that in a “ bad ” channel packets arrive with a certain variance in delay and packets start dropping once channel conditions deteriorate. Figure 24 shows the RTT graph for the bad channel. At approximately 9:05:20 and 9:07:00, bad channel conditions lead to increased RTT. The RTT statistics (from TCPTrace) were as follows: RTT min of 7.8 ms, RTT max of 209.5 ms, RTT average 127.2 ms and RTT standard deviation of 64.0 ms. When these experiments were performed, the VoiceStream network in South Florida supported CS-1 and CS-2 coding schemes and a 4x1 and 3x1 PDCH configuration for GPRS. In these experiments the coding scheme used was CS-1 and three downlink and one uplink slots. Therefore the theoretical throughput in ideal conditions would be approximately 28 kbps (three downlink slots at 9.05 kbps each). Figure 25 shows the actual throughput for the three channel conditions. It is obvious that a bad channel, where signal is lost, will lead to retransmissions. But, why do the first two experiments show no TCP retransmissions? Why is CS-1 the coding scheme used and what is the reason for lower throughput than the one theoretically predicted? Some of the factors that affect the throughput are the different GPRS protocol layers, in particular the positive and negative acknowledgments sent by the RLC protocol. In the next section we will see that even in a strong signal or a mobile user environment there are packets that are received with errors and need to be retransmitted. It is the job of the GPRS RLC protocol to recover these packets quickly. 5.5 Radio Link Control Protocol Benefits for TCP in GPRS The TCP protocol was designed with the concept that loss of data originates from congestion signals caused by overflows in different routers. In traditional wireless circuit switched data networks, channel conditions can lead to loss of data which in turn can

PAGE 65

57 degrade the TCP performance by making TCP believe that the data was lost due to congestion. Figure 24. Round trip time graph for bad channel The GPRS protocol was designed for non-real time applications. Most of these applications utilize the TCP/IP protocol. The creators of GPRS knew the basic assumptions of TCP; therefore they added the RLC protocol to provide an extra ARQ mechanism that along with the ARQ mechanism of TCP would provide a robust recovery mechanism. Besides ARQ, the RLC protocol utilizes Forward Error Correction (FEC) to recover erroneous packets. The recovery of these packets normally happens before the TCP timeout. Timeouts that occur when using GPRS as a bearer are for real packet loses.

PAGE 66

58 The RLC ARQ retransmissions avoid the spurious TCP timeouts that would be present if a protocol like RLC did not exist on GPRS. Throughput comparison 14 14.5 15 15.5 16 16.5 17 17.5 Weak signal Roaming Strong No Roaming Channel Conditions Throughput (Kbit/s) Figure 25. Throughput for the different channel conditions One of the important characteristics of GPRS quality of service is that the RLC protocol also adapts itself to the different radio channel conditions by dynamically changing between the four different coding schemes discussed in Chapter 3. These coding schemes basically make a tradeoff between speed/throughput and data protection. These explains why the coding scheme seen in the experiments was CS-1. As we saw in the previous experiments, TCP shows no retransmissions under good channel conditions, but are there really no retransmissions? The following experiments make use of PING, FTP and WWW over the GPRS wireless link to investigate how many RLC retransmissions occur in a good signal environment. The TCPTrace data is located in Appendix B. The RLC data was obtained using the field engineering mode feature of the phone. The next table shows the result of the three experiments. The first experiment consisted of sending 10 PING packets to list.ufl.edu. In this experiment all 10 PING

PAGE 67

59 packets were successfully received. During the duration of the PING experiment the RLC layer sent 68 ACK/NACK packets. Two of these were used to request retransmission of data. The second experiment involves a bigger data payload, downloading a 300kB image from an anonymous FTP server. During this experiment the RLC ARQ protocol requested retransmissions of RLC blocks 53 times. The data taken with TCPTrace shows that there were no TCP retransmissions. In the third experiment, a web session is established and the URL browsed is list.ufl.edu. During the course of this experiment 11 TCP connections were made with no request for TCP packet retransmissions. The field-engineering mode indicated that 57 RLC retransmission requests were made. Table 6. Experiment results using PING, FTP and WWW TCP/RLC Application Number of TCP retransmission Number of RLC requests for retransmission PING No TCP packets were traced. 2 FTP (300kB) 0 53 WWW (list.ufl.edu) 0 57 In conclusion, these three experiments demonstrate that the RLC protocol is sufficiently fast to recover erroneous data. The fast recovery mechanism employed in RLC helps prevent timeouts that could lead to data loss in the view of TCP. 5.6 Effect of GPRS Protocol Layers and Signaling on Overall Performance Protocol overhead on top of RLC also contributes to the fact that the theoretical data rates discussed in Chapter 3 cannot be achieved. Under the Transport/Network layers in the GPRS protocol stack we have the RLC, LLC and SNDCP protocols. The LLC protocol also provides segmentation of data and congestion control between the MS

PAGE 68

60 and the SGSN. Signaling messages such as cell broadcast messages, quality of service adjustment, RLC acknowledgement of uplink traffic also have to be transmitted. According to Meyer ’ s experimentation, a GPRS user will only be able to achieve approximately 85% of the theoretical value for the data rates specified for all four coding schemes [16]. 5.7 Proposals to Enhance the TCP Performance on Wireless Networks The intent of this thesis is to discuss the performance of TCP for a single mobile in a live GPRS network. It is also important to mention that several studies analyze the utilization of wireline TCP solutions for TCP over GPRS. Some of these studies are TCP SACK, TCP timestamps, and the Eifel Algorithm The TCP SACK and the TCP Timestamps are used to differentiate the congestion problems in wireline networks from other type of packet loses. The TCP SACK option is used to information the sender about all the segments that arrived correctly at the receiver. The TCP Timestamps option is used to make the RTT more accurate by collection samples of RTT in the sender. According to the GPRS-TCP simulation analysis made by Rendon J. [18], the TCP Timestamp degrades the throughput. The TCP Timestamp alone degrades the throughput by 3.85% and when used together with TCP SACK the throughput is degraded by approximately 6.88%. In the other hand the TCP SACK enhanced the performance by 9.09%. These results were based on simulations made with the Bones tool and not with a live network. The Eifel algorithm is a proposal made by Ericsson Research Labs to eliminate the retransmission problems caused by spurious timeouts and spurious fast retransmits [17]. The intent of the Eifel algorithm is to make TCP truly wireless. These two problems occur in wireless networks due to the variable signal strength in the radio networks that in

PAGE 69

61 turn can cause disconnection in the order of seconds or it can also be caused by various network delays. The first step the Eifel algorithm takes is the elimination of retransmission ambiguity and then it restores and resumes the transmission with the next unsent packet. The Eifel algorithm accomplishes its objective by adding extra information on the ACK packets in order to distinguish between an ACK from an original segment and an ACK from a retransmitted segment. Using this extra information unnecessary go-back-N retransmits are avoided. The Eifel algorithm is still in experimental stages; recently a BSD implementation was made public by Ericsson Research labs. 5.8 Conclusions This chapter investigated the performance of TCP over GSM packet data network (GPRS). The experiments showed that even in strong signal condition the theoretical throughput predicted for GPRS could not be achieved. The overhead in the different GPRS protocol layers and radio link acknowledgement packets cause this. We have seen that in a strong signal area with no mobility and in a strong signal with mobile user, the TCP protocol performs excellent. This is due in part to the ARQ mechanism used in the RLC protocol whose purpose is to prevent TCP from observing packet loses, instead TCP wool observe packet delays when there are errors in the radio interface. In the case of a bad signal environment we saw that TCP performed as it should by requesting packets to be retransmitted when signal is lost. Other experiments using PING and WWW were performed to confirm the findings in the bulk data transfer experiments. As part of this experiment it was demonstrated that a GPRS modem connection has quick setup time and outperforms that of a typical circuit switched modem. It was

PAGE 70

62 also seen that GPRS modem data rates are superior to that of current circuit switched wireless modems and that true packet data operates in GPRS. Finally alternative options to make TCP more robust were introduced. The SACK, Timestamps and Eifel algorithm are proposed method to make TCP over wireless networks more reliable. It is still to be seen if these methods are really necessary for TCP over GPRS since the RLC protocol by itself provides sufficient protection from problems in the radio interface.

PAGE 71

63 CHAPTER 6 CONCLUSION AND FUTURE WORK 6.1 Conclusion This thesis focuses on the performance of TCP using a live GPRS network. The GSM cellular protocol introduced a packet switched mechanism called GPRS. This new technology provides Internet type service (FTP, Email, WWW, PING) comparable to that of wireline networks. The GPRS protocol is needed due to the increasing popularity of wireless data and as an introductory step for UMTS. The GPRS protocol was designed with TCP in mind, therefore different protocols were created underneath the network and transport layers. These protocols provide a mechanism to make TCP operate efficiently over a wide range of channel conditions. The GPRS protocol provides many benefits to the wireless data user: a very fast connection time, theoretically up to 171.2 kbps (most mobile phones today support 28 kbps to approximately 50 kbps), dynamic coding schemes and mechanisms to ensure that TCP detects real loss of data. Despite all these benefits it is still questionable whether GPRS will become popular for wireless TCP/IP connections. There are two main reasons for this. The first one is that most of the carriers do not have an adequate method to charge for the service. In GPRS users are charged by data transfer and not by connection time (it is a packet switched network). Current charging rates are expensive. The second reason is that even in optimal conditions, it is hard to achieve the predicted theoretical rates. Faster data rates are expected with the introduction of new handsets.

PAGE 72

64 The experiments in this thesis were conducted using tools available in the Internet, tools available for GPRS phone users and network operators, and the VoiceStream network in South Florida. At the time these experiments were conducted, the available GPRS handsets supported a maximum of 3 RX and 1 TX slot with coding scheme 1, thereby providing a maximum theoretical data rate of approximately 28 kbps. Traditionally, TCP performance experiments were based on fixed networks and not in wireless cellular networks. The experiments on this thesis showed that TCP performed well in a live GPRS network and that no packet loses were present when the channel conditions varied from medium to optimal (mobile user). When the channel conditions deteriorated, a drop in the data rate occurred due to the periods of missing signals. The RLC protocol implemented in GPRS provides an ARQ scheme that is appropriately designed to ensure that TCP observes packet delays instead of packet loses. The success of this mechanism is based on its speed, which allows retransmissions before the TCP timers expire. These experiments also showed that even in perfect channel conditions the theoretical GPRS data rates could not be achieved. This is due to the different protocol layer overheads and various network delays. 6.2 Future Work Various researchers focus their attention on improving the TCP performance over wireless network [17] [18]. These researchers suggest additional algorithms and capabilities into TCP in order to solve various issues like unnecessary retransmits, spurious timeouts and spurious fast retransmits. One of these methods is the Eifel algorithm. Currently Eifel (and other algorithms) is in experimental stages and have not been tested with live GPRS networks. It is still to be seen if these algorithms provide a

PAGE 73

65 real improvement for TCP over GPRS or if their modifications prove to be negligible for TCP over GPRS. The GPRS network was introduced commercially into the European and United States cellular markets in the first quarter of 2001 and the fourth quarter of 2001 respectively. As it occurs with many introductory technologies it is still to be seen if the networks and handsets will evolve to the maximum specified by the standards thereby making multimedia and other applications possible over this bearer. It will be interesting to see how multimedia services perform over GPRS and how the GPRS quality of service adapts to these applications.

PAGE 74

66 APPENDIX A MODEM DATA A.1 Port Monitor Log for GPRS Connection with GPRS Modem This log was taken with the application Portmon for Windows version 3.02 from Mark Russinovich. This program is freeware and can be found in http://www.sysinternals.com . This log presents the entire handshake and AT commands used to establish a GPRS data connection. In the log we can see that after the serial port handshake is performed the GPRS application (GPRS Manager) makes sure that the GPRS phone is GPRS attached to the network. This happens in line 60 with the command AT+CGATT. After that, other AT commands are used to setup the APN and the QoS. It is important to note that this log demonstrates that the connection time for GPRS is very fast. In line 288, the command ATD*99# is used to establish a PDP context activation with the GPRS network. Once that command is successful we see that in matter of a few seconds the PPP connection with the PC is started (modem switched to data mode by control sequence sent from PC) and data starts to flow to/from the GPRS RF modem. Moving the modem back to command mode terminates the connection and sending the AT command ATH hangs up the PDP context. This happens in line 596. [\\COCO] 0 7:43:12 AM Gprsmana VCOMM_EscapeCommFunction 0x0 0x1000 Unknown Func: 38 1 7:43:12 AM Gprsmana VCOMM_OpenComm COM2 SUCCESS 2 7:43:12 AM Gprsmana VCOMM_EscapeCommFunction COM2 SUCCESS CLRTIMERLOGIC

PAGE 75

67 3 7:43:12 AM Gprsmana VCOMM_EscapeCommFunction COM2 SUCCESS IGNOREERRORONREADS 4 7:43:12 AM Gprsmana VCOMM_SetupComm COM2 SUCCESS RxSize: 4096 TxSize: 0 5 7:43:12 AM Gprsmana VCOMM_SetupComm COM2 SUCCESS RxSize: 8192 TxSize: 8192 6 7:43:12 AM Gprsmana VCOMM_GetCommState COM2 SUCCESS Baud: 57600 Bits: 8 Stop: 1 Parity: None 7 7:43:12 AM Gprsmana VCOMM_SetCommState COM2 SUCCESS Mask: fff Baud: 57600 Bits: 8 Stop: 1 Parity: None 8 7:43:12 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:250 RM:0 RC:0 WM:0 WC:5000 9 7:43:12 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 10 7:43:12 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 11 7:43:12 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 12 7:43:12 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:250 RM:0 RC:2000 WM:0 WC:2000 13 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 14 7:43:12 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 15 7:43:12 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 1: A 16 7:43:12 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 17 7:43:12 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 18 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 19 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 20 7:43:12 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 21 7:43:12 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 1: . 22 7:43:12 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 23 7:43:12 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 24 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 25 7:43:12 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 26 7:43:12 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 27 7:43:12 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:250 RM:0 RC:2000 WM:0 WC:2000 28 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 29 7:43:12 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 30 7:43:12 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 3: AT. 31 7:43:12 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR

PAGE 76

68 32 7:43:12 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 33 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 34 7:43:12 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 35 7:43:12 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 36 7:43:12 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 37 7:43:14 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 38 7:43:14 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 9: AT...OK.. 39 7:43:14 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 40 7:43:14 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 41 7:43:14 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 42 7:43:14 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:500 RM:0 RC:2000 WM:0 WC:500 43 7:43:14 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 44 7:43:14 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 45 7:43:14 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 3: AT. 46 7:43:14 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 47 7:43:14 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 48 7:43:14 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 49 7:43:14 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 50 7:43:14 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 51 7:43:14 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 52 7:43:14 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 53 7:43:14 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 9: AT...OK.. 54 7:43:14 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 55 7:43:14 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 56 7:43:14 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 57 7:43:14 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:500 RM:0 RC:2000 WM:0 WC:500

PAGE 77

69 58 7:43:14 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 59 7:43:14 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 60 7:43:14 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 10: AT+CGATT?. 61 7:43:14 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 62 7:43:14 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 63 7:43:14 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 64 7:43:14 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 65 7:43:14 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 66 7:43:14 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 67 7:43:16 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 68 7:43:16 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 29: AT+CGATT?...+CGATT: 1....OK.. 69 7:43:16 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 70 7:43:16 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 71 7:43:16 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 72 7:43:16 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:500 RM:0 RC:2000 WM:0 WC:500 73 7:43:16 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 74 7:43:16 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 75 7:43:16 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 6: AT E0. 76 7:43:16 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 77 7:43:16 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 78 7:43:16 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 79 7:43:16 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 80 7:43:16 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 81 7:43:16 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 82 7:43:16 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 83 7:43:16 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 12: AT E0...OK..

PAGE 78

70 84 7:43:16 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 85 7:43:16 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 86 7:43:16 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 87 7:43:16 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:500 RM:0 RC:2000 WM:0 WC:500 88 7:43:16 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 89 7:43:16 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 90 7:43:16 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 51: AT+CGDCONT=1,"IP","internet3.voicestream.com",,0,0. 91 7:43:16 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 92 7:43:16 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 93 7:43:16 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 94 7:43:16 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 95 7:43:16 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 96 7:43:16 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 97 7:43:18 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 98 7:43:18 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 6: ..OK.. 99 7:43:18 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 100 7:43:18 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 101 7:43:18 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 102 7:43:18 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:500 RM:0 RC:2000 WM:0 WC:500 103 7:43:18 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 104 7:43:18 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 105 7:43:18 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 22: AT+CGQREQ=1,0,0,3,0,0. 106 7:43:18 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 107 7:43:18 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 108 7:43:18 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0

PAGE 79

71 109 7:43:18 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 110 7:43:18 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 111 7:43:18 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 112 7:43:18 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1 113 7:43:18 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 6: ..OK.. 114 7:43:18 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 115 7:43:18 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue 116 7:43:18 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 117 7:43:18 AM Gprsmana VCOMM_GetSetCommTimeouts COM2 SUCCESS SET: RI:500 RM:0 RC:2000 WM:0 WC:500 118 7:43:18 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 119 7:43:18 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 120 7:43:18 AM Gprsmana VCOMM_WriteComm COM2 SUCCESS Length: 22: AT+CGQMIN=1,0,0,3,0,0. 121 7:43:18 AM Gprsmana WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 122 7:43:18 AM Gprsmana VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 123 7:43:18 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 124 7:43:18 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 125 7:43:18 AM Gprsmana VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 126 7:43:18 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1024 127 7:43:20 AM Gprsmana VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1 128 7:43:20 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 6: ..OK.. 129 7:43:20 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 130 7:43:20 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 131 7:43:20 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Receive Queue

PAGE 80

72 132 7:43:20 AM Gprsmana VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 133 7:43:20 AM Gprsmana VCOMM_EscapeCommFunction COM2 SUCCESS CLRDTR 134 7:43:20 AM Gprsmana VCOMM_CloseComm COM2 SUCCESS 135 7:43:20 AM MSGSRV32 VCOMM_EscapeCommFunction 0x0 0x1000 Unknown Func: 39 136 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction 0x0 0x1000 Unknown Func: 38 137 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction 0x0 0x1000 Unknown Func: 38 138 7:43:20 AM Tapisrv VCOMM_OpenComm COM2 SUCCESS 139 7:43:20 AM Tapisrv VCOMM_EnableCommNotification COM2 SUCCESS 140 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETUPDATETIMERADDR 141 7:43:20 AM Tapisrv VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 142 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 143 7:43:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 144 7:43:20 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 145 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 146 7:43:20 AM Tapisrv VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1 147 7:43:20 AM Tapisrv VCOMM_GetCommState COM2 SUCCESS Baud: 57600 Bits: 8 Stop: 1 Parity: None 148 7:43:20 AM Tapisrv VCOMM_SetCommState COM2 SUCCESS Mask: ffffffff Baud: 57600 Bits: 8 Stop: 1 Parity: None 149 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETDTR 150 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETRTS 151 7:43:20 AM Tapisrv VCOMM_OpenComm Motorola Serial GPRS 56K SUCCESS 152 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction Motorola Serial GPRS 56K SUCCESS CLRTIMERLOGIC 153 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction Motorola Serial GPRS 56K SUCCESS IGNOREERRORONREADS 154 7:43:20 AM Tapisrv VCOMM_SetupComm Motorola Serial GPRS 56K SUCCESS RxSize: 4096 TxSize: 0 155 7:43:20 AM Tapisrv VCOMM_SetupComm Motorola Serial GPRS 56K SUCCESS RxSize: 4096 TxSize: 4096 156 7:43:20 AM Tapisrv VCOMM_GetCommState COM2 SUCCESS Baud: 57600 Bits: 8 Stop: 1 Parity: None 157 7:43:20 AM Tapisrv VCOMM_SetCommState COM2 SUCCESS Mask: ffffffff Baud: 57600 Bits: 8 Stop: 1 Parity: None 158 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETDTR

PAGE 81

73 159 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETRTS 160 7:43:20 AM Tapisrv VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 161 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 162 7:43:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 163 7:43:20 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 164 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 165 7:43:20 AM Tapisrv VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1 166 7:43:20 AM Tapisrv VCOMM_SetCommEventMask COM2 SUCCESS 167 7:43:20 AM Tapisrv VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 168 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 169 7:43:20 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Receive Queue 170 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 171 7:43:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 172 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETDTR 173 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 174 7:43:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 175 7:43:20 AM Tapisrv VCOMM_WriteComm COM2 SUCCESS Length: 3: AT. 176 7:43:20 AM Tapisrv VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 177 7:43:20 AM Tapisrv VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 178 7:43:20 AM Tapisrv VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 179 7:43:20 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 180 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 181 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 182 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 183 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 184 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 185 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 186 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 187 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: O 188 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 189 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 190 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: K 191 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1

PAGE 82

74 192 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 193 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 194 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 195 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 196 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 197 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 198 7:43:20 AM KERNEL32 VCOMM_WriteComm COM2 SUCCESS Length: 18: AT &F0 &D2 &C1 E0. 199 7:43:20 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 2 200 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: 1 201 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 202 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 203 3178.07790720 KERNEL32 WriteNotifyProc COM2 VOID TRANSMIT: TXCHAR 204 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 205 7:43:20 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 206 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 207 7:43:20 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 208 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 209 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 210 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 211 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 212 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 213 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 214 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 215 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: O 216 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 217 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 218 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: K

PAGE 83

75 219 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 220 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 221 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 222 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 223 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 224 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 225 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 226 7:43:20 AM KERNEL32 VCOMM_WriteComm COM2 SUCCESS Length: 16: AT V1 W1 S95=47. 227 7:43:20 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 228 7:43:20 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 229 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 230 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 231 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 232 7:43:20 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 233 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 234 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 235 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 236 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 237 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 238 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 239 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 240 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: O 241 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 242 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 243 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: K 244 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 245 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR

PAGE 84

76 246 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 247 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 248 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 249 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 250 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 251 7:43:20 AM KERNEL32 VCOMM_WriteComm COM2 SUCCESS Length: 6: AT&K3. 252 7:43:20 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 253 7:43:20 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 254 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 255 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 256 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 257 7:43:20 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 258 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 259 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 260 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 261 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 262 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 263 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 264 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 265 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: O 266 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 267 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 268 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: K 269 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 270 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 271 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 272 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1

PAGE 85

77 273 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 274 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 275 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 276 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 277 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 278 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 279 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 280 7:43:20 AM Tapisrv VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 281 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 282 7:43:20 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Receive Queue 283 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 284 7:43:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 285 7:43:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS SETDTR 286 7:43:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 287 7:43:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 288 7:43:20 AM Tapisrv VCOMM_WriteComm COM2 SUCCESS Length: 8: ATD*99#. 289 7:43:20 AM Tapisrv VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 290 7:43:20 AM Tapisrv VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 291 7:43:20 AM Tapisrv VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 292 7:43:20 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 293 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 294 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 295 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 296 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 297 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 298 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 299 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 300 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: C 301 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 302 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR

PAGE 86

78 303 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: O 304 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 305 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 306 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: N 307 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 308 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 309 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: N 310 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 311 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 312 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: E 313 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 314 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 315 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: C 316 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 317 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 318 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 319 7:43:20 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 320 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 321 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: T 322 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 323 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 324 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 325 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 326 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 327 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 328 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 329 7:43:20 AM KERNEL32 VCOMM_GetCommState COM2 SUCCESS Baud: 57600 Bits: 8 Stop: 1 Parity: None 330 7:43:20 AM KERNEL32 VCOMM_SetCommEventMask COM2 SUCCESS

PAGE 87

79 331 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 332 7:43:20 AM KERNEL32 VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 333 7:43:20 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 334 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 335 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: ~ 336 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 337 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 338 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 339 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: } 340 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 341 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: # 342 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 343 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 344 7:43:20 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 345 7:43:20 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 346 7:43:20 AM Rnaapp VCOMM_EscapeCommFunction Motorola Serial GPRS 56K SUCCESS ENABLETIMERLOGIC 347 7:43:20 AM Rnaapp VCOMM_GetCommState Motorola Serial GPRS 56K SUCCESS Baud: 57600 Bits: 8 Stop: 1 Parity: None 348 7:43:20 AM Rnaapp VCOMM_SetCommState Motorola Serial GPRS 56K SUCCESS Mask: 800 349 7:43:20 AM Rnaapp VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 350 7:43:20 AM Rnaapp VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 53: !}!}%%} }<}!}$}'.}"}&} }*} } }'}"}(}"}%%}&=XmD}#}$.#..~ 351 7:43:20 AM Rnaapp VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 352 7:43:20 AM Rnaapp VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 353 7:43:20 AM Rnaapp VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 354 7:43:20 AM Rnaapp VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS NONE 355 7:43:20 AM Rnaapp VCOMM_SetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 356 7:43:20 AM Rnaapp VCOMM_EnableCommNotification Motorola Serial GPRS 56K SUCCESS

PAGE 88

80 357 7:43:20 AM Rnaapp VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 358 7:43:20 AM Rnaapp VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 53: ~.}#.!}!}!} }7}"}&} }*} } }%%}&} <".}'}"}(}"}-}#}&}/.~ 359 7:43:20 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 360 7:43:20 AM Portmon EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 361 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 362 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.}#.!}$ 363 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 364 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 365 7:43:20 AM Portmon VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1509 366 7:43:20 AM Portmon VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 367 7:43:20 AM Portmon EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 368 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 369 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 15: }!} }'}-}#}&.2~ 370 7:43:20 AM Portmon VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 371 7:43:20 AM Portmon VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 46: ~.}#.!}!}"} }4}"}&} }*} } }%%}&} <".}'}"}(}"IT~ 372 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 373 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 374 7:43:20 AM Portmon VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 375 7:43:20 AM Portmon VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 376 7:43:20 AM Portmon WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 377 7:43:20 AM Portmon EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 378 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 379 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.}#.!}"

PAGE 89

81 380 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 381 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 382 7:43:20 AM Portmon VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1509 383 7:43:20 AM Portmon VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 384 7:43:20 AM Portmon EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 385 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 386 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 38: }"} }4}"}&} }*} } }%%}&} <".}'}"}(}".=~ 387 7:43:20 AM Portmon VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 388 7:43:20 AM Portmon VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 389 7:43:20 AM Portmon VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 390 7:43:20 AM Portmon VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 391 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 392 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 393 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.}#.!}! 394 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 395 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 396 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1509 397 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 398 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 399 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 400 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 50: }%%} }<}!}$}'.}"}&} }*} } }'}"}(}"}%%}&=XmD}#}$.#..~ 401 7:43:24 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1

PAGE 90

82 402 7:43:24 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 59: ~.}#.!}"}%%} }<}!}$}'.}"}&} }*} } }'}"}(}"}%%}&=XmD}#}$.#.}.~ 403 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 404 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 405 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 406 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 407 7:43:24 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 408 7:43:24 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 409 7:43:24 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 24: ~.#.....iStream.dummy.<~ 410 7:43:24 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 411 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 412 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 413 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.#..... 414 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 415 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 416 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1507 417 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 418 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 419 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 420 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 3: .0~ 421 7:43:24 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 422 7:43:24 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 46: ~.!...(...-.................................L~ 423 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR

PAGE 91

83 424 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 425 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 426 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 427 7:43:24 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 428 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 429 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 430 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.!..... 431 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 432 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 433 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1507 434 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 435 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 436 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 437 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 20: ..-................~ 438 7:43:24 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 439 7:43:24 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 28: ~.!........................~ 440 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 441 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 442 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 443 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 444 7:43:24 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 445 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 446 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR

PAGE 92

84 447 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.!..... 448 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 449 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 450 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1507 451 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 452 7:43:24 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 453 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 454 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: .....i;~ 455 7:43:24 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 456 7:43:24 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 16: ~.!...........O~ 457 7:43:24 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 458 7:43:24 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 459 7:43:24 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 460 7:43:24 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 461 7:43:24 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: 462 7:43:26 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 463 7:43:26 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 28: ~.!.......................%%~ 464 7:43:26 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 465 7:43:26 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 466 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 467 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.!..... 468 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 469 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0:

PAGE 93

85 470 7:43:26 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1507 471 7:43:26 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 472 7:43:26 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 473 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 474 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 20: .................4.~ 475 7:43:26 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 476 7:43:26 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 28: ~.!.......................O~ 477 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 478 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 479 7:43:26 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 480 7:43:26 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 481 7:43:26 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 482 7:43:26 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 483 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 484 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.!..... 485 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 486 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 487 7:43:26 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1507 488 7:43:26 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 489 7:43:26 AM KERNEL32 EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 490 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 491 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 20: .................m.~ 492 7:43:26 AM KERNEL32 VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR

PAGE 94

86 493 7:43:26 AM KERNEL32 VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 494 7:43:26 AM KERNEL32 VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1514 495 7:43:26 AM KERNEL32 VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 496 7:43:28 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 497 7:43:28 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 33: ~!E..........2..................~ 498 7:43:28 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 499 7:43:30 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 500 7:43:30 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 33: ~!E..........2................-.~ 501 7:43:30 AM Portmon WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 502 7:43:32 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 503 7:43:32 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}13F.............L...&)......... EDEPEDEPCACACACACACA 504 7:43:32 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 505 7:43:32 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 506 7:43:32 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}12F.............L...()......... EGEMDBDJEOEFFEDBCACA 507 7:43:32 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 508 7:43:32 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 509 7:43:32 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}11F.............L...*)......... EDEPEDEPCACACACACACA 510 7:43:32 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 511 7:43:34 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 512 7:43:34 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}10F.............L...&)......... EDEPEDEPCACACACACACA 513 7:43:34 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR

PAGE 95

87 514 7:43:34 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 515 7:43:34 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1/F.............L...*)......... EDEPEDEPCACACACACACA 516 7:43:34 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 517 7:43:34 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 518 7:43:34 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 104: ~!E..`.....}1.F.............L...()......... EGEMDBDJEOEFFEDBCACA 519 7:43:34 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 520 7:43:34 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 521 7:43:34 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 33: ~!E..........2.................j~ 522 7:43:34 AM Explorer WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 523 7:43:34 AM Portmon VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 524 7:43:34 AM Portmon VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1,F.............L...&)......... EDEPEDEPCACACACACACA 525 7:43:34 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 526 7:43:34 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 527 7:43:34 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1+F.............L...()......... EGEMDBDJEOEFFEDBCACA 528 7:43:34 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 529 7:43:34 AM MSGSRV32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 530 7:43:34 AM MSGSRV32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1*F.............L...*)......... EDEPEDEPCACACACACACA 531 7:43:34 AM MSGSRV32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 532 7:43:34 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 533 7:43:34 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1)F.............L...&(......... EDEPEDEPCACACACACACA

PAGE 96

88 534 7:43:34 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 535 7:43:34 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 536 7:43:34 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1(F.............L...*(......... EDEPEDEPCACACACACACA 537 7:43:34 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 538 7:43:34 AM KERNEL32 VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 539 7:43:34 AM KERNEL32 VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 103: ~!E..`.....}1'F.............L...((......... EGEMDBDJEOEFFEDBCACA 540 7:43:34 AM KERNEL32 WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 541 7:44:20 AM Rnaapp VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1 542 7:44:20 AM Rnaapp VCOMM_WriteComm Motorola Serial GPRS 56K SUCCESS Length: 17: ~.}#.!}%%}#} }$.r~ 543 7:44:20 AM Rnaapp WriteNotifyProc Motorola Serial GPRS 56K VOID TRANSMIT: TXCHAR 544 7:44:20 AM Rnaapp EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 545 7:44:20 AM Rnaapp VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 546 7:44:20 AM Rnaapp VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 8: ~.}#.!}& 547 7:44:20 AM Rnaapp VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 548 7:44:20 AM Rnaapp VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0: 549 7:44:20 AM Rnaapp VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1509 550 7:44:20 AM Rnaapp VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 551 7:44:20 AM Rnaapp EventNotifyProc Motorola Serial GPRS 56K VOID EVENT: RXFLAG 552 7:44:20 AM Rnaapp VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 553 7:44:20 AM Rnaapp VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 16: }#} }$HW~~.}#.!} 554 7:44:20 AM Rnaapp VCOMM_ClearCommError Motorola Serial GPRS 56K SUCCESS NOERROR 555 7:44:20 AM Rnaapp VCOMM_ReadComm Motorola Serial GPRS 56K SUCCESS Length: 0:

PAGE 97

89 556 7:44:20 AM Rnaapp VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: 1510 557 7:44:20 AM Rnaapp VCOMM_GetCommEventMask Motorola Serial GPRS 56K SUCCESS TRANSMIT 558 7:44:20 AM Rnaapp VCOMM_SetReadCallBack Motorola Serial GPRS 56K SUCCESS Trigger: -1 559 7:44:20 AM Rnaapp VCOMM_SetWriteCallBack Motorola Serial GPRS 56K SUCCESS Trigger: -1 560 7:44:20 AM Rnaapp VCOMM_PurgeComm Motorola Serial GPRS 56K SUCCESS Receive Queue 561 7:44:20 AM Rnaapp VCOMM_PurgeComm Motorola Serial GPRS 56K SUCCESS Transmit Queue 562 7:44:20 AM Rnaapp VCOMM_EnableCommNotification Motorola Serial GPRS 56K SUCCESS 563 7:44:20 AM Rnaapp VCOMM_SetCommEventMask Motorola Serial GPRS 56K SUCCESS 564 7:44:20 AM Tapisrv VCOMM_SetCommEventMask COM2 SUCCESS 565 7:44:20 AM Tapisrv VCOMM_SetReadCallBack COM2 SUCCESS Trigger: -1 566 7:44:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 567 7:44:20 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 568 7:44:20 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 569 7:44:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 570 7:44:20 AM Tapisrv VCOMM_SetReadCallBack COM2 SUCCESS Trigger: 1 571 7:44:20 AM Tapisrv VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 572 7:44:20 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Receive Queue 573 7:44:20 AM Tapisrv VCOMM_EscapeCommFunction COM2 SUCCESS CLRDTR 574 7:44:20 AM Tapisrv VCOMM_SetCommEventMask COM2 SUCCESS 575 7:44:20 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 576 7:44:20 AM Gprsmana ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 577 7:44:20 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 578 7:44:20 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 1: . 579 7:44:20 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 580 7:44:20 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 1: ~ 581 7:44:20 AM Gprsmana VCOMM_ClearCommError COM2 SUCCESS NOERROR 582 7:44:20 AM Gprsmana VCOMM_ReadComm COM2 SUCCESS Length: 0: 583 7:44:22 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 584 7:44:22 AM KERNEL32 VCOMM_SetCommEventMask COM2 SUCCESS 585 7:44:22 AM KERNEL32 VCOMM_EscapeCommFunction COM2 SUCCESS SETDTR 586 7:44:22 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0

PAGE 98

90 587 7:44:22 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 588 7:44:22 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 589 7:44:22 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 590 7:44:22 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 591 7:44:22 AM KERNEL32 VCOMM_PurgeComm COM2 SUCCESS Receive Queue 592 7:44:22 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 593 7:44:22 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 594 7:44:22 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 595 7:44:22 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 596 7:44:22 AM KERNEL32 VCOMM_WriteComm COM2 SUCCESS Length: 4: ATH. 597 7:44:22 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 598 7:44:22 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 599 7:44:22 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 600 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 601 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 602 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 603 7:44:24 AM KERNEL32 VCOMM_WriteComm COM2 SUCCESS Length: 4: ATH. 604 7:44:24 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 605 7:44:24 AM KERNEL32 VCOMM_GetCommQueueStatus COM2 SUCCESS RX: 0 TX: 0 606 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 607 7:44:24 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 608 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 609 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 610 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 611 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 612 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: .

PAGE 99

91 613 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 614 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 615 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: N 616 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 617 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 618 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: O 619 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 620 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 621 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: 622 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 623 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 624 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: C 625 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 626 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 627 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: A 628 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 629 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 630 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: R 631 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 632 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 633 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 634 7:44:24 AM KERNEL32 ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 635 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 636 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: R 637 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 638 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 639 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: I 640 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1

PAGE 100

92 641 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 642 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: E 643 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 644 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 645 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: R 646 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 647 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 648 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 649 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 650 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 651 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 652 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 653 7:44:24 AM KERNEL32 VCOMM_EscapeCommFunction COM2 SUCCESS SETDTR 654 7:44:24 AM KERNEL32 VCOMM_GetCommState COM2 SUCCESS Baud: 57600 Bits: 8 Stop: 1 Parity: None 655 7:44:24 AM KERNEL32 VCOMM_SetCommState COM2 SUCCESS Mask: ffffffff Baud: 57600 Bits: 8 Stop: 1 Parity: None 656 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 657 7:44:24 AM KERNEL32 VCOMM_SetWriteCallBack COM2 SUCCESS Trigger: -1 658 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 659 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 660 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 661 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 1: . 662 7:44:24 AM KERNEL32 VCOMM_ClearCommError COM2 SUCCESS NOERROR 663 7:44:24 AM KERNEL32 VCOMM_ReadComm COM2 SUCCESS Length: 0: 664 7:44:24 AM Tapisrv ReadNotifyProc COM2 VOID RECEIVE: RXCHAR 665 7:44:24 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 666 7:44:24 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 1: K 667 7:44:24 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 668 7:44:24 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 1: . 669 7:44:24 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 670 7:44:24 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 1: .

PAGE 101

93 671 7:44:24 AM Tapisrv VCOMM_ClearCommError COM2 SUCCESS NOERROR 672 7:44:24 AM Tapisrv VCOMM_ReadComm COM2 SUCCESS Length: 0: 673 7:44:24 AM Tapisrv VCOMM_EscapeCommFunction Motorola Serial GPRS 56K SUCCESS CLRDTR 674 7:44:24 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Receive Queue 675 7:44:24 AM Tapisrv VCOMM_PurgeComm COM2 SUCCESS Transmit Queue 676 7:44:24 AM Tapisrv VCOMM_SetCommEventMask COM2 SUCCESS EVENT 677 7:44:24 AM Tapisrv VCOMM_WriteComm COM2 SUCCESS Length: 9: AT&FS0=0. 678 7:44:24 AM Tapisrv VCOMM_CloseComm COM2 SUCCESS 679 7:44:24 AM Tapisrv VCOMM_SetReadCallBack 0xC15759C4 BADPORT 680 7:44:24 AM Tapisrv VCOMM_CloseComm Motorola Serial GPRS 56K SUCCESS 681 7:44:24 AM MSGSRV32 VCOMM_EscapeCommFunction 0x0 0x1000 Unknown Func: 39 7:44:24 AM MSGSRV32 VCOMM_EscapeCommFunction 0x0 0x1000 Unknown Func: 39 . A.2 Connecting with a GPRS RF Modem The following three pictures show the sequence of events when connecting to the GPRS network using the Timeport GPRS phone. Figure 25 shows the GPRS phone in idle mode or attached mode. In this mode the phone is aware that there is a GPRS network but it is not in a GPRS session. If there were no GPRS network present the phone would not show the text GPRS on its display. Figure 26 shows the display of the phone after a GPRS session has been started, the first information displayed on the phone is the IP address assigned to the phone by the network. As discussed in Chapter 3 and 5, this IP address is assigned by the GPRS GGSN. Figure 27 shows the GPRS phone in an active data session.

PAGE 102

94 Figure 26. Mobile station in idle mode or GPRS attached. Figure 27. Internet Protocol address assigned to GPRS phone

PAGE 103

95 Figure 28. Mobile station in a GPRS data session

PAGE 104

96 APPENDIX B EXPERIMENTS LOGS B.1 Decoded TCP Trace for Poor Channel Experiment This section presents the data decoded by the application TCPTrace for the experiment conducted under bad channel conditions. The raw data for that experiment was captured with WinDump [19]. It is included in section B.5 of this appendix. 1 arg remaining, starting with 'ftp7.out' Ostermann's tcptrace -version 5.2.1 -Wed Sep 15, 1999 1056 packets seen, 1055 TCP packets traced elapsed wallclock time: 0:00:00.411224, 2567 pkts/sec analyzed trace file elapsed time: 0:02:44.330279 TCP connection info: 2 TCP connections traced: TCP connection 1: host a: 216.155.171.38:1264 host b: 142.58.12.69:ftp complete conn: no (SYNs: 0) (FINs: 0) first packet: Wed Dec 5 09: 04:48.832174 2001 last packet: Wed Dec 5 09:06:52.515234 2001 elapsed time: 0:02:03.683059 total packets: 10 filename: ftp7.out a->b: b->a: total packets: 5 total packets: 5 ack pkts sent: 5 ack pkts sent: 5 pure acks sent: 3 pure acks sent: 1 unique bytes sent: 54 unique bytes sent: 136 actual data pkts: 2 actual data pkts: 4 actual data bytes: 54 actual data bytes: 218 rexmt data pkts: 0 rexmt data pkts: 1 rexmt data bytes: 0 rexmt data bytes: 82 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 4 SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0 mss requested: 0 bytes mss requested: 0 bytes

PAGE 105

97 max segm size: 27 bytes max segm size: 82 bytes min segm size: 27 bytes min segm size: 24 bytes avg segm size: 26 bytes avg segm size: 54 bytes max win adv: 8095 bytes max win adv: 61440 bytes min win adv: 7959 bytes min win adv: 61440 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 8017 bytes avg win adv: 61440 bytes initial window: 27 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 0 bytes truncated data: 80 bytes truncated packets: 0 pkts truncated packets: 2 pkts data xmit time: 0.983 secs data xmit time: 122.529 secs idletime max: 115115.6 ms idletime max: 114938.8 ms throughput: 0 Bps throughput: 1 Bps RTT samples: 2 RTT samples: 3 RTT min: 947.2 ms RTT min: 14.6 ms RTT max: 1058.0 ms RTT max: 156.8 ms RTT avg: 1002.6 ms RTT avg: 98.7 ms RTT stdev: 0.0 ms RTT stdev: 74.6 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0 duplicate acks: 3 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 2: host c: 142.58.12.69:ftp-data host d: 216.155.171.38:1269 complete conn: yes first packet: Wed Dec 5 09:04:50.917205 2001 last packet: Wed Dec 5 09:07:33.162454 2001 elapsed time: 0:02:42.245249 total packets: 1045 filename: ftp7.out c->d: d->c: total packets: 632 total packets: 413 ack pkts sent: 631 ack pkts sent: 413 pure acks sent: 2 pure acks sent: 411 unique bytes sent: 304768 unique bytes sent: 0

PAGE 106

98 actual data pkts: 629 actual data pkts: 0 actual data bytes: 321664 actual data bytes: 0 rexmt data pkts: 33 rexmt data pkts: 0 rexmt data bytes: 16896 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 0 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 mss requested: 512 bytes mss requested: 960 bytes max segm size: 512 bytes max segm size: 0 bytes min segm size: 128 bytes min segm size: 0 bytes avg segm size: 511 bytes avg segm size: 0 bytes max win adv: 61440 bytes max win adv: 8192 bytes min win adv: 61440 bytes min win adv: 8192 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 61537 bytes avg win adv: 8192 bytes initial window: 512 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: 304768 bytes ttl stream length: 0 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 295246 bytes truncated data: 0 bytes truncated packets: 629 pkts truncated packets: 0 pkts data xmit time: 158.333 secs data xmit time: 0.000 secs idletime max: 9306.4 ms idletime max: 9474.3 ms throughput: 1878 Bps throughput: 0 Bps RTT samples: 533 RTT samples: 2 RTT min: 7.8 ms RTT min: 1454.2 ms RTT max: 209.5 ms RTT max: 1539.4 ms RTT avg: 127.2 ms RTT avg: 1496.7 ms RTT stdev: 64.0 ms RTT stdev: 0.0 ms post-loss acks: 1 post-loss acks: 0 segs cum acked: 63 segs cum acked: 0 duplicate acks: 16 duplicate acks: 596 triple dupacks: 1 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms B.2 Decoded TCP Trace for Mobile User Experiment This section presents the data decoded by the application TCPTrace for the experiment conducted when the user is mobile. The term mobile describes the action of moving among different cells in the network.

PAGE 107

99 1 arg remaining, starting with 'ftp7gs.out' Ostermann's tcptrace -version 5.2.1 -Wed Sep 15, 1999 1030 packets seen, 1030 TCP packets traced elapsed wallclock time: 0:00:00.189689, 5429 pkts/sec analyzed trace file elapsed time: 0:02:26.522398 TCP connection info: 2 TCP connections traced: TCP connection 1: host a: 216.155.173.39:1026 host b: 142.58.12.69:ftp complete conn: no (SYNs: 0) (FINs: 0) first packet: Thu Dec 6 06:55:39.752378 2001 last packet: Thu Dec 6 06:57:38.432704 2001 elapsed time: 0:01:5 8.680325 total packets: 8 filename: ftp7gs.out a->b: b->a: total packets: 4 total packets: 4 ack pkts sent: 4 ack pkts sent: 4 pure acks sent: 2 pure acks sent: 1 unique bytes sent: 52 unique bytes sent: 136 actual data pkts: 2 actual data pkts: 3 actual data bytes: 52 actual data bytes: 136 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 3 SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0 mss requested: 0 bytes mss requested: 0 bytes max segm size: 27 bytes max segm size: 82 bytes min segm size: 25 bytes min segm size: 24 bytes avg segm size: 25 bytes avg segm size: 45 bytes max win adv: 4121 bytes max win adv: 61440 bytes min win adv: 3985 bytes min win adv: 61440 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4051 bytes avg win adv: 61440 bytes initial window: 25 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 0 bytes truncated data: 40 bytes truncated packets: 0 pkts truncated packets: 1 pkts data xmit time: 0.970 secs data xmit time: 117.591 secs idletime max: 114950.5 ms idletime max: 114960.8 ms throughput: 0 Bps throughput: 1 Bps

PAGE 108

100 RTT samples: 2 RTT samples: 3 RTT min: 955.9 ms RTT min: 14.0 ms RTT max: 1109.1 ms RTT max: 143.5 ms RTT avg: 1032.4 ms RTT avg: 96.9 ms RTT stdev: 0.0 ms RTT stdev: 72.0 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0 duplicate acks: 2 duplicate acks: 0 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 2: host c: 142.58.12.69:ftp-data host d: 216.155.173.39:1029 complete conn: yes first packet: Thu Dec 6 06:55:41.779688 200 1 last packet: Thu Dec 6 06:58:06.274776 2001 elapsed time: 0:02:24.495088 total packets: 1022 filename: ftp7gs.out c->d: d->c: total packets: 599 total packets: 423 ack pkts sent: 598 ack pkts sent: 423 pure acks sent: 2 pure acks sent: 421 unique bytes sent: 304768 unique bytes sent: 0 actual data pkts: 596 actual data pkts: 0 actual data bytes: 304768 actual data bytes: 0 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 1 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 0 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 mss requested: 512 bytes mss requested: 536 bytes max segm size: 512 bytes max segm size: 0 bytes min segm size: 128 bytes min segm size: 0 bytes avg segm size: 511 bytes avg segm size: 0 bytes max win adv: 61440 bytes max win adv: 4288 bytes min win adv: 61440 bytes min win adv: 4288 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 61542 bytes avg win adv: 4288 bytes initial window: 512 bytes initial window: 0 bytes

PAGE 109

101 initial window: 1 pkts initial window: 0 pkts ttl stream length: 304768 bytes ttl stream length: 0 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 279736 bytes truncated data: 0 bytes truncated packets: 596 pkts truncated packets: 0 pkts data xmit time: 141.069 secs data xmit time: 0.000 secs idletime max: 1600.4 ms idletime max: 1995.0 ms throughput: 2109 Bps throughput: 0 Bps RTT samples: 421 RTT samples: 2 RTT min: 5.7 ms RTT min: 1492.7 ms RTT max: 213.4 ms RTT max: 1584.9 ms RTT avg: 90.3 ms RTT avg: 1538.7 ms RTT stdev: 78.5 ms RTT stdev: 0.0 ms post-loss acks: 1 post-loss acks: 0 segs cum acked: 175 segs cum acked: 0 duplicate acks: 1 duplicate acks: 596 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms B.3 Decoded TCP Trace for Good Channel Experiment This section present the data decoded by the application TCPTrace for the experiment conducted when the user is not mobile and the channel conditions are good. 1 arg remaining, starting with 'ftp7ags.out' Ostermann's tcptrace -version 5.2.1 -Wed Sep 15, 1999 1031 packets seen, 1031 TCP packets traced Elapsed wallclock time: 0:00:00.181368, 5684 pkts/sec analyzed trace file elapsed time: 0:02:25.076440 TCP connection info: 2 TCP connections traced: TCP connection 1: host a: 216.155.173.39:1026 host b: 142.58.12.69:ftp complete conn: no (SYNs: 0) (F INs: 0) first packet: Thu Dec 6 07:01:14.724255 2001 last packet: Thu Dec 6 07:03:13.065602 2001

PAGE 110

102 elapsed time: 0:01:58.341346 total packets: 8 filename: ftp7ags.out a->b: b->a: total packets: 4 total packets: 4 ack pkts sent: 4 ack pkts sent: 4 pure acks sent: 2 pure acks sent: 1 unique bytes sent: 52 unique bytes sent: 136 actual data pkts: 2 actual data pkts: 3 actual data bytes: 52 actual data bytes: 136 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 3 SYN/FIN pkts sent: 0/0 SYN/FIN pkts sent: 0/0 mss requested: 0 bytes mss requested: 0 bytes max segm size: 27 bytes max segm size: 82 bytes min segm size: 25 bytes min segm size: 24 bytes avg segm size: 25 bytes avg segm size: 45 bytes max win adv: 4288 bytes max win adv: 61440 bytes min win adv: 3806 bytes min win adv: 61440 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4048 bytes avg win adv: 61440 bytes initial window: 25 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 0 bytes truncated data: 40 bytes truncated packets: 0 pkts truncated packets: 1 pkts data xmit time: 1.011 secs data xmit time: 117.237 secs idletime max: 114444.4 ms idletime max: 114532.0 ms throughput: 0 Bps throughput: 1 Bps RTT samples: 2 RTT samples: 3 RTT min: 993.5 ms RTT min: 17.3 ms RTT max: 1109.9 ms RTT max: 198.0 ms RTT avg: 1051.7 ms RTT avg: 108.6 ms RTT stdev: 0.0 ms RTT stdev: 90.4 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0 duplicate acks: 2 duplicate acks: 0 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms

PAGE 111

103 sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 2: host c: 142.58.12.69:ftp-data host d: 216.155.173.39:1031 complete conn: yes first packet: Thu Dec 6 07:01:16.887206 2001 last packet: Thu Dec 6 07:03:39.800696 2001 elapsed time: 0:02:22.913489 total packets: 1023 filename: ftp7ags.out c->d: d->c: total packets: 599 total packets: 424 ack pkts sent: 598 ack pkts sent: 424 pure acks sent: 2 pure acks sent: 422 unique bytes sent: 304768 unique bytes sent: 0 actual data pkts: 596 actual data pkts: 0 actual data bytes: 304768 actual data bytes: 0 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 1 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 0 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 mss requested: 512 bytes mss requested: 536 bytes max segm size: 512 bytes max segm size: 0 bytes min segm size: 128 bytes min segm size: 0 bytes avg segm size: 511 bytes avg segm size: 0 bytes max win adv: 61440 bytes max win adv: 4288 bytes min win adv: 61440 bytes min win adv: 4288 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 61542 bytes avg win adv: 4288 bytes initial window: 512 bytes initial window: 0 bytes initial window: 1 pkts initial window: 0 pkts ttl stream length: 304768 bytes ttl stream length: 0 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 279736 bytes truncated data: 0 bytes truncated packets: 596 pkts truncated packets: 0 pkts data xmit time: 140.227 secs data xmit time: 0.000 secs idletime max: 1489.9 ms idletime max: 1924.9 ms throughput: 2133 Bps throughput: 0 Bps RTT samples: 422 RTT samples: 2 RTT min: 5.8 ms RTT min: 861.1 ms RTT max: 209.7 ms RTT max: 1477.1 ms RTT avg: 89.5 ms RTT avg: 1169.0 ms

PAGE 112

104 RTT stdev: 77.0 ms RTT stdev: 0.0 ms post-loss acks: 1 post-loss acks: 0 segs cum acked: 174 segs cum acked: 0 duplicate acks: 1 duplicate acks: 596 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms B.4 Decoded TCPTrace for WWW Experiment This experiment shows the decoded TCP data when connecting to the site list.ufl.edu. 1 arg remaining, starting with 'jan17www' Ostermann's tcptrace -version 5.2.1 -Wed Sep 15, 1999 243 packets seen, 230 TCP packets traced elapsed wallclock time: 0:00:00.218880, 1110 pkts/sec analyzed trace file elapsed time: 0:01:22.171813 TCP connection info: 11 TCP connections traced: TCP connection 1: host a: 216.155.172.100:1283 host b: 128.227.8 0.92:80 complete conn: yes first packet: Thu Jan 17 21:10:28.615632 2002 last packet: Thu Jan 17 21:10:33.020454 2002 elapsed time: 0:00:04.404822 total packets: 10 filename: jan17www a->b: b->a: total packets: 5 total packets: 5 ack pkts sent: 4 ack pkts sent: 5 pure acks sent: 2 pure acks sent: 2 unique bytes sent: 329 unique bytes sent: 348 actual data pkts: 1 actual data pkts: 1 actual data bytes: 329 actual data bytes: 348 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 1 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req sack: Y req sack: Y

PAGE 113

105 sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 329 bytes max segm size: 348 bytes min segm size: 329 bytes min segm size: 348 bytes avg segm size: 328 bytes avg segm size: 347 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 3940 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 5186 bytes avg win adv: 65392 bytes initial window: 329 bytes initial window: 348 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 329 bytes ttl stream length: 348 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 287 bytes truncated data: 306 bytes truncated packets: 1 pkts truncated packets: 1 pkts data xmit time: 0.000 secs data xmit time: 0.000 secs idletime max: 1805.7 ms idletime max: 1181.7 ms throughput: 75 Bps throughput: 79 Bps RTT samples: 3 RTT samples: 3 RTT min: 831.7 ms RTT min: 8.3 ms RTT max: 1108.5 ms RTT max: 25.3 ms RTT avg: 965.5 ms RTT avg: 14.2 ms RTT stdev: 138.6 ms RTT stdev: 9.6 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0 duplicate acks: 2 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 2: host c: 216.155.172.100:1284 host d: 216.155.175.188:80 complete conn: ye s first packet: Thu Jan 17 21:10:31.230510 2002 last packet: Thu Jan 17 21:10:36.290357 2002 elapsed time: 0:00:05.059847 total packets: 10 filename: jan17www c->d: d->c: total packets: 5 total packets: 5 ack pkts sent: 4 ack pkts sent: 5

PAGE 114

106 pure acks sent: 2 pure acks sent: 2 unique bytes sent: 460 unique bytes sent: 381 actual data pkts: 1 actual data pkts: 1 actual data bytes: 460 actual data bytes: 381 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 1 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 460 bytes max segm size: 381 bytes min segm size: 460 bytes min segm size: 381 bytes avg segm size: 459 bytes avg segm size: 380 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 3907 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 5169 bytes avg win adv: 65392 bytes initial window: 460 bytes initial window: 381 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 460 bytes ttl stream length: 381 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 418 bytes truncated data: 339 bytes truncated packets: 1 pkts truncated packets: 1 pkts data xmit time: 0.000 secs data xmit time: 0.000 secs idletime max: 3008.0 ms idletime max: 1549.0 ms throughput: 91 Bps throughput: 75 Bps RTT samples: 3 RTT samples: 3 RTT min: 958.3 ms RTT min: 8.2 ms RTT max: 1443.3 ms RTT max: 15.7 ms RTT avg: 1122.4 ms RTT avg: 10.9 ms RTT stdev: 277.9 ms RTT stdev: 4.2 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0 duplicate acks: 2 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 3: host e: 216.155.172.100:1285

PAGE 115

107 host f: 128.227.80.92:80 complete conn: yes first packet: Thu Jan 17 21:10:35.315350 2002 last packet: Thu Jan 17 21:10:38.684329 2002 elapsed time: 0:00:03.368978 total packets: 10 filename: jan17www e->f: f->e: total packets: 5 total packets: 5 ack pkts sent: 4 ack pkts sent: 5 pure acks sent: 2 pure acks sent: 2 unique bytes sent: 329 unique bytes sent: 348 actual data pkts: 1 actual data pkts: 1 actual data bytes: 329 actual data bytes: 348 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 1 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 329 bytes max segm size: 348 bytes min segm size: 329 bytes min segm size: 348 bytes avg segm size: 328 bytes avg segm size: 347 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 3940 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 5186 bytes avg win adv: 65392 bytes initial window: 329 bytes initial window: 348 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 329 bytes ttl stream length: 348 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 287 bytes truncated data: 306 bytes truncated packets: 1 pkts truncated packets: 1 pkts data xmit time: 0.000 secs data xmit time: 0.000 secs idletime max: 1279.9 ms idletime max: 1149.7 ms throughput: 98 Bps throughput: 103 Bps RTT samples: 3 RTT samples: 3 RTT min: 903.4 ms RTT min: 8.7 ms RTT max: 1076.0 ms RTT max: 94.0 ms RTT avg: 993.5 ms RTT avg: 37.7 ms RTT stdev: 86.5 ms RTT stdev: 48.8 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0

PAGE 116

108 duplicate acks: 2 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 4: host g: 216.155.172.100:1286 host h: 216.155.175.188:80 complete conn: yes first packet: Thu Jan 17 21:10:37.680267 2002 las t packet: Thu Jan 17 21:10:41.945101 2002 elapsed time: 0:00:04.264833 total packets: 10 filename: jan17www g->h: h->g: total packets: 5 total packets: 5 ack pkts sent: 4 ack pkts sent: 5 pure acks sent: 2 pure acks sent: 2 unique bytes sent: 460 unique bytes sent: 381 actual data pkts: 1 actual data pkts: 1 actual data bytes: 460 actual data bytes: 381 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 1 pushed data pkts: 1 SYN/FIN pkts sent: 1/1 SYN/FIN pkts sent: 1/1 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 460 bytes max segm size: 381 bytes min segm size: 460 bytes min segm size: 381 bytes avg segm size: 459 bytes avg segm size: 380 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 3907 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 5169 bytes avg win adv: 65392 bytes initial window: 460 bytes initial window: 381 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: 460 bytes ttl stream length: 381 bytes missed data: 0 bytes missed data: 0 bytes truncated data: 418 bytes truncated data: 339 bytes truncated packets: 1 pkts truncated packets: 1 pkts data xmit time: 0.000 secs data xmit time: 0.000 secs

PAGE 117

109 idletime max: 1884.9 ms idletime max: 1223.2 ms throughput: 108 Bps throughput: 89 Bps RTT samples: 3 RTT samples: 3 RTT min: 889.0 ms RTT min: 6.1 ms RTT max: 1126.4 ms RTT max: 10.8 ms RTT avg: 972.8 ms RTT avg: 8.9 ms RTT stdev: 133.1 ms RTT stdev: 2.5 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 0 duplicate acks: 2 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 5: host i: 216.155.172.100:1287 host j: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:40.580144 2002 last packet : Thu Jan 17 21:10:56.859541 2002 elapsed time: 0:00:16.279396 total packets: 15 filename: jan17www i->j: j->i: total packets: 8 total packets: 7 ack pkts sent: 7 ack pkts sent: 7 pure acks sent: 4 pure acks sent: 1 unique bytes sent: 1106 unique bytes sent: 1578 actual data pkts: 3 actual data pkts: 5 actual data bytes: 1106 actual data bytes: 1578 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 3 pushed data pkts: 3 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 420 bytes max segm size: 536 bytes min segm size: 329 bytes min segm size: 134 bytes avg segm size: 368 bytes avg segm size: 315 bytes max win adv: 4288 bytes max win adv: 65392 bytes

PAGE 118

110 min win adv: 4108 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4849 bytes avg win adv: 65392 bytes initial window: 329 bytes initial window: 670 bytes initial window: 1 pkts initial window: 2 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 980 bytes truncated data: 1368 bytes truncated packets: 3 pkts truncated packets: 5 pkts data xmit time: 13.090 secs data xmit time: 12.818 secs idletime max: 51308.0 ms idletime max: 51316.5 ms throughput: 68 Bps throughput: 97 Bps RTT samples: 4 RTT samples: 4 RTT min: 883.5 ms RTT min: 6.5 ms RTT max: 2179.8 ms RTT max: 205.5 ms RTT avg: 1474.4 ms RTT avg: 57.0 ms RTT stdev: 557.1 ms RTT stdev: 99.0 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 2 duplicate acks: 3 duplicate acks: 3 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 6: host k: 216.155.172.100:1288 host l: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:44.137657 2002 last packet: Thu Jan 17 21:10:57.414517 2002 elapsed time: 0:00:13.276859 total packets: 16 filename: jan17www k->l: l->k: total packets: 8 total packets: 8 ack pkts sent: 7 ack pkts sent: 8 pure acks sent: 4 pure acks sent: 1 unique bytes sent: 1129 unique bytes sent: 1961 actual data pkts: 3 actual data pkts: 6 actual data bytes: 1129 actual data bytes: 1961 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0

PAGE 119

111 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 3 pushed data pkts: 4 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 402 bytes max segm size: 536 bytes min segm size: 363 bytes min segm size: 5 bytes avg segm size: 376 bytes avg segm size: 326 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 4108 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4874 bytes avg win adv: 65392 bytes initial window: 402 bytes initial window: 180 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 1003 bytes truncated data: 1746 bytes truncated packets: 3 pkts truncated packets: 5 pkts data xmit time: 9.540 secs data xmit time: 10.043 secs idletime max: 50753.0 ms idletime max: 50937.2 ms throughput: 85 Bps throughput: 148 Bps RTT samples: 4 RTT samples: 5 RTT min: 1090.3 ms RTT min: 7.9 ms RTT max: 2137.6 ms RTT max: 184.2 ms RTT avg: 1646.2 ms RTT avg: 76.4 ms RTT stdev: 500.9 ms RTT stdev: 93.0 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 2 duplicate acks: 4 duplicate acks: 2 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 7: host m: 216.155.172.100:1289 host n: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:44.150085 2002 last packet: Thu Jan 17 2 1:10:55.739588 2002 elapsed time: 0:00:11.589503 total packets: 34

PAGE 120

112 filename: jan17www m->n: n->m: total packets: 15 total packets: 19 ack pkts sent: 14 ack pkts sent: 19 pure acks sent: 12 pure acks sent: 1 unique bytes sent: 696 unique bytes sent: 8574 actual data pkts: 2 actual data pkts: 17 actual data bytes: 696 actual data bytes: 8574 rexmt data pkts: 0 rexmt data pkts: 0 rexmt data bytes: 0 rexmt data bytes: 0 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 8 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 358 bytes max segm size: 536 bytes min segm size: 338 bytes min segm size: 152 bytes avg segm size: 347 bytes avg segm size: 504 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 4136 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4583 bytes avg win adv: 65392 bytes initial window: 338 bytes initial window: 536 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 612 bytes truncated data: 7860 bytes truncated packets: 2 pkts truncated packets: 17 pkts data xmit time: 6.955 secs data xmit time: 7.996 secs idletime max: 52428.0 ms idletime max: 52438.5 ms throughput: 60 Bps throughput: 740 Bps RTT samples: 3 RTT samples: 13 RTT min: 1358.9 ms RTT min: 7.0 ms RTT max: 3037.2 ms RTT max: 205.3 ms RTT avg: 1976.9 ms RTT avg: 93.6 ms RTT stdev: 922.4 ms RTT stdev: 79.7 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 5 duplicate acks: 16 duplicate acks: 1 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms

PAGE 121

113 sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 8: host o: 216.155.172.100:1290 host p: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:47.369891 2002 last packet: Thu Jan 17 21:11:00. 259410 2002 elapsed time: 0:00:12.889519 total packets: 18 filename: jan17www o->p: p->o: total packets: 9 total packets: 9 ack pkts sent: 8 ack pkts sent: 9 pure acks sent: 6 pure acks sent: 1 unique bytes sent: 718 unique bytes sent: 2407 actual data pkts: 2 actual data pkts: 7 actual data bytes: 718 actual data bytes: 2943 rexmt data pkts: 0 rexmt data pkts: 1 rexmt data bytes: 0 rexmt data bytes: 536 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 4 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 359 bytes max segm size: 536 bytes min segm size: 359 bytes min segm size: 70 bytes avg segm size: 358 bytes avg segm size: 420 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 4288 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4824 bytes avg win adv: 65392 bytes initial window: 359 bytes initial window: 606 bytes initial window: 1 pkts initial window: 2 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 634 bytes truncated data: 2649 bytes truncated packets: 2 pkts truncated packets: 7 pkts data xmit time: 6.825 secs data xmit time: 9.119 secs idletime max: 47908.1 ms idletime max: 47914.8 ms throughput: 56 Bps throughput: 187 Bps RTT samples: 3 RTT samples: 5 RTT min: 1543.2 ms RTT min: 6.7 ms RTT max: 2735.8 ms RTT max: 155.7 ms

PAGE 122

114 RTT avg: 2089.0 ms RTT avg: 59.5 ms RTT stdev: 602.6 ms RTT stdev: 71.9 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 2 duplicate acks: 6 duplicate acks: 3 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 9: host q: 216.155.172.100:1291 host r: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:47.964863 2002 last packet: Thu Jan 17 21:11:25.329927 2 002 elapsed time: 0:00:37.365063 total packets: 65 filename: jan17www q->r: r->q: total packets: 29 total packets: 36 ack pkts sent: 28 ack pkts sent: 36 pure acks sent: 26 pure acks sent: 2 unique bytes sent: 700 unique bytes sent: 14757 actual data pkts: 2 actual data pkts: 33 actual data bytes: 700 actual data bytes: 16901 rexmt data pkts: 0 rexmt data pkts: 4 rexmt data bytes: 0 rexmt data bytes: 2144 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 17 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 1/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 358 bytes max segm size: 536 bytes min segm size: 342 bytes min segm size: 126 bytes avg segm size: 349 bytes avg segm size: 512 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 4162 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4436 bytes avg win adv: 65392 bytes initial window: 358 bytes initial window: 536 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: NA ttl stream length: NA

PAGE 123

115 missed data: NA missed data: NA truncated data: 616 bytes truncated data: 15515 bytes truncated packets: 2 pkts truncated packets: 33 pkts data xmit time: 27.239 secs data xmit time: 32.258 secs idletime max: 22837.6 ms idletime max: 23030.8 ms throughput: 19 Bps throughput: 395 Bps RTT samples: 3 RTT samples: 22 RTT min: 1944.5 ms RTT min: 6.5 ms RTT max: 2513.8 ms RTT max: 204.6 ms RTT avg: 2176.1 ms RTT avg: 94.4 ms RTT stdev: 299.1 ms RTT stdev: 75.5 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 8 duplicate acks: 33 duplicate acks: 6 triple dupacks: 0 triple dupacks: 1 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 10: host s: 216.155.172.100:1292 host t: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:48.394870 2002 last packet: Thu Jan 17 21:11:40.302873 2002 el apsed time: 0:00:51.908003 total packets: 20 filename: jan17www s->t: t->s: total packets: 10 total packets: 10 ack pkts sent: 9 ack pkts sent: 10 pure acks sent: 7 pure acks sent: 2 unique bytes sent: 695 unique bytes sent: 2938 actual data pkts: 2 actual data pkts: 6 actual data bytes: 695 actual data bytes: 2938 rexmt data pkts: 0 rexmt data pkts: 1 rexmt data bytes: 0 rexmt data bytes: 1 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 3 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 2/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes

PAGE 124

116 max segm size: 357 bytes max segm size: 536 bytes min segm size: 338 bytes min segm size: 359 bytes avg segm size: 347 bytes avg segm size: 489 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 3929 bytes min win adv: 65392 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4684 bytes avg win adv: 65392 bytes initial window: 357 bytes initial window: 536 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 611 bytes truncated data: 2686 bytes truncated packets: 2 pkts truncated packets: 6 pkts data xmit time: 46.898 secs data xmit time: 46.300 secs idletime max: 43233.3 ms idletime max: 45383.1 ms throughput: 13 Bps throughput: 57 Bps RTT samples: 3 RTT samples: 6 RTT min: 1989.0 ms RTT min: 6.7 ms RTT max: 2571.7 ms RTT max: 178.1 ms RTT avg: 2341.6 ms RTT avg: 108.0 ms RTT stdev: 310.1 ms RTT stdev: 79.5 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 1 duplicate acks: 7 duplicate acks: 3 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms ================================ TCP connection 11: host u: 216.155.172.100:1293 host v: 128.227.80.92:80 complete conn: no (SYNs: 2) (FINs: 0) first packet: Thu Jan 17 21:10:48.404852 2002 last packet: Thu Jan 17 21:11:48.167553 2002 elapsed t ime: 0:00:59.762700 total packets: 22 filename: jan17www u->v: v->u: total packets: 10 total packets: 12 ack pkts sent: 9 ack pkts sent: 12 pure acks sent: 7 pure acks sent: 2 unique bytes sent: 696 unique bytes sent: 3805

PAGE 125

117 actual data pkts: 2 actual data pkts: 8 actual data bytes: 696 actual data bytes: 3805 rexmt data pkts: 0 rexmt data pkts: 1 rexmt data bytes: 0 rexmt data bytes: 1 outoforder pkts: 0 outoforder pkts: 0 pushed data pkts: 2 pushed data pkts: 5 SYN/FIN pkts sent: 1/0 SYN/FIN pkts sent: 2/0 req sack: Y req sack: Y sacks sent: 0 sacks sent: 0 mss requested: 536 bytes mss requested: 536 bytes max segm size: 358 bytes max segm size: 536 bytes min segm size: 338 bytes min segm size: 194 bytes avg segm size: 347 bytes avg segm size: 475 bytes max win adv: 4288 bytes max win adv: 65392 bytes min win adv: 4288 bytes min win adv: 65034 bytes zero win adv: 0 times zero win adv: 0 times avg win adv: 4764 bytes avg win adv: 65362 bytes initial window: 358 bytes initial window: 536 bytes initial window: 1 pkts initial window: 1 pkts ttl stream length: NA ttl stream length: NA missed data: NA missed data: NA truncated data: 612 bytes truncated data: 3469 bytes truncated packets: 2 pkts truncated packets: 8 pkts data xmit time: 54.393 secs data xmit time: 53.412 secs idletime max: 50560.9 ms idletime max: 51700.9 ms throughput: 12 Bps throughput: 64 Bps RTT samples: 3 RTT samples: 6 RTT min: 1134.1 ms RTT min: 5.9 ms RTT max: 2570.3 ms RTT max: 162.3 ms RTT avg: 2000.3 ms RTT avg: 70.7 ms RTT stdev: 762.6 ms RTT stdev: 76.3 ms post-loss acks: 0 post-loss acks: 0 segs cum acked: 0 segs cum acked: 3 duplicate acks: 9 duplicate acks: 3 triple dupacks: 0 triple dupacks: 0 max # retrans: 0 max # retrans: 0 min retr time: 0.0 ms min retr time: 0.0 ms max retr time: 0.0 ms max retr time: 0.0 ms avg retr time: 0.0 ms avg retr time: 0.0 ms sdv retr time: 0.0 ms sdv retr time: 0.0 ms

PAGE 126

118 B.5 Raw Trace for TCP over Poor Channel The following is a portion of the data captured with WinDump [19] for the experiment discussed in chapter 5 in which a GPRS connection was made in a bad channel. This data was parsed and decoded using TCPTrace. 09:04:48.832174 216.155.171.38.1264 > 142.58.12.69.21: P 600978653:600978680(27) ack 640385321 win 8095 (DF) 09:04:49.799966 142.58.12.69.21 > 216.155.171.38.1264: P 1:31(30) ack 27 win 61440 [tos 0x10] 09:04:49.814968 216.155.171.38.1264 > 142.58.12.69.21: P 27:54(27) ack 31 win 8065 (DF) 09:04:50.917205 142.58.12.69.20 > 216.155.171.38.1269: S 666048000:666048000(0) win 61440 [tos 0x8] 09:04:50.929923 216.155.171.38.1269 > 142.58.12.69.20: S 601153082:601153082(0) ack 666048001 win 8192 (DF) 09:04:50.935514 142.58.12.69.21 > 216.155.171.38.1264: . ack 54 win 61440 [tos 0x10] 09:04:52.873245 142.58.12.69.20 > 216.155.171.38.1269: . ack 1 win 61440 [tos 0x8] 09:04:52.932670 142.58.12.69.21 > 216.155.171.38.1264: P 31:113(82) ack 54 win 61440 [tos 0x10] 09:04:53.129839 216.155.171.38.1264 > 142.58.12.69.21: . ack 113 win 7983 (DF) 09:04:53.204842 142.58.12.69.20 > 216.155.171.38.1269: . 1:513(512) ack 1 win 61440 [tos 0x8] 09:04:53.329830 216.155.171.38.1269 > 142.58.12.69.20: . ack 513 win 8192 (DF) 09:04:57.389677 142.58.12.69.21 > 216.155.171.38.1264: P 31:113(82) ack 54 win 61440 [tos 0x10] 09:04:57.399675 216.155.171.38.1264 > 142.58.12.69.21: . ack 113 win 7983 (DF) 09:05:00.042802 142.58.12.69.20 > 216.155.171.38.1269: . 1:513(512) ack 1 win 61440 [tos 0x8] 09:05:00.054571 216.155.171.38.1269 > 142.58.12.69.20: . ack 513 win 8192 (DF) 09:05:09.349165 142.58.12.69.20 > 216.155.171.38.1269: . 513:1025(512) ack 1 win 61440 [tos 0x8] 09:05:09.528845 216.155.171.38.1269 > 142.58.12.69.20: . ack 1025 win 8192 (DF) 09:05:09.763371 142.58.12.69.20 > 216.155.171.38.1269: . 1025:1537(512) ack 1 win 61440 [tos 0x8] 09:05:09.929190 216.155.171.38.1269 > 142.58.12.69.20: . ack 1537 win 8192 (DF) 09:05:10.820620 142.58.12.69.20 > 216.155.171.38.1269: . 1537:2049(512) ack 1 win 61440 [tos 0x8] 09:05:10.953618 142.58.12.69.20 > 216.155.171.38.1269: . 2049:2561(512) ack 1 win 61440 [tos 0x8] 09:05:10.964150 216.155.171.38.1269 > 142.58.12.69.20: . ack 2561 win 8192 (DF) 09:05:11.629137 >>> NetBeui Packet Type=0x3 Length=44 (0x2c) Signature=0xEFFF Command=0x8 NetbiosDataGram:

PAGE 127

119 Destination=NA3 NameType=0x1D (Master Browser) Source=TDAVANI_PC NameType=0x00 (Workstation) SMB PACKET: SMBtrans (REQUEST) 09:05:11.944774 142.58.12.69.20 > 216.155.171.38.1269: . 2561:3073(512) ack 1 win 61440 [tos 0x8] 09:05:12.065581 142.58.12.69.20 > 216.155.171.38.1269: . 3073:3585(512) ack 1 win 61440 [tos 0x8] 09:05:12.074107 216.155.171.38.1269 > 142.58.12.69.20: . ack 3585 win 8192 (DF) 09:05:12.226472 142.58.12.69.20 > 216.155.171.38.1269: . 3585:4097(512) ack 1 win 61440 [tos 0x8] 09:05:12.429096 216.155.171.38.1269 > 142.58.12.69.20: . ack 4097 win 8192 (DF) 09:05:13.550324 142.58.12.69.20 > 216.155.171.38.1269: . 4097:4609(512) ack 1 win 61440 [tos 0x8] 09:05:13.706274 142.58.12.69.20 > 216.155.171.38.1269: . 4609:5121(512) ack 1 win 61440 [tos 0x8] 09:05:13.719065 216.155.171.38.1269 > 142.58.12.69.20: . ack 5121 win 8192 (DF) 09:05:13.769043 216.155.171.38.138 > 216.155.171.255.138: >>> NBT UDP PACKET(138) Res=0x1102 ID=0xBB6 IP=216 (0xd8).155 (0x9b).171 (0xab).38 (0x26) Port=138 (0x8a) Length=187 (0xbb) Res2=0x0 SourceName=TDAVANI_PC NameType=0x00 (Workstation) DestName=NA NameType=0x00 (Workstation) SMB PACKET: SMBmkdir (REQUEST) 09:05:13.841625 142.58.12.69.20 > 216.155.171.38.1269: . 5121:5633(512) ack 1 win 61440 [tos 0x8] 09:05:14.027836 142.58.12.69.20 > 216.155.171.38.1269: . 5633:6145(512) ack 1 win 61440 [tos 0x8] 09:05:14.034033 216.155.171.38.1269 > 142.58.12.69.20: . ack 5633 win 8192 (DF) 09:05:14.234027 216.155.171.38.1269 > 142.58.12.69.20: . ack 6145 win 8192 (DF) 09:05:15.046595 142.58.12.69.20 > 216.155.171.38.1269: . 6145:6657(512) ack 1 win 61440 [tos 0x8] 09:05:15.171884 142.58.12.69.20 > 216.155.171.38.1269: . 6657:7169(512) ack 1 win 61440 [tos 0x8] 09:05:15.183987 216.155.171.38.1269 > 142.58.12.69.20: . ack 7169 win 8192 (DF) 09:05:15.739119 142.58.12.69.20 > 216.155.171.38.1269: . 7169:7681(512) ack 1 win 61440 [tos 0x8] 09:05:15.835102 142.58.12.69.20 > 216.155.171.38.1269: . 7681:8193(512) ack 1 win 61440 [tos 0x8] 09:05:15.843962 216.155.171.38.1269 > 142.58.12.69.20: . ack 8193 win 8192 (DF) 09:05:16.338657 142.58.12.69.20 > 216.155.171.38.1269: . 8193:8705(512) ack 1 win 61440 [tos 0x8]

PAGE 128

120 09:05:16.507279 142.58.12.69.20 > 216.155.171.38.1269: . 8705:9217(512) ack 1 win 61440 [tos 0x8] 09:05:16.518938 216.155.171.38.1269 > 142.58.12.69.20: . ack 9217 win 8192 (DF) 09:05:16.682608 142.58.12.69.20 > 216.155.171.38.1269: . 9217:9729(512) ack 1 win 61440 [tos 0x8] 09:05:16.833925 216.155.171.38.1269 > 142.58.12.69.20: . ack 9729 win 8192 (DF) 09:05:17.301399 142.58.12.69.20 > 216.155.171.38.1269: . 9729:10241(512) ack 1 win 61440 [tos 0x8] 09:05:17.433902 216.155.171.38.1269 > 142.58.12.69.20: . ack 10241 win 8192 (DF) 09:05:17.463003 142.58.12.69.20 > 216.155.171.38.1269: . 10241:10753(512) ack 1 win 61440 [tos 0x8] 09:05:17.624919 142.58.12.69.20 > 216.155.171.38.1269: . 10753:11265(512) ack 1 win 61440 [tos 0x8] 09:05:17.631037 216.155.171.38.1269 > 142.58.12.69.20: . ack 10753 win 8192 (DF) 09:05:17.831045 216.155.171.38.1269 > 142.58.12.69.20: . ack 11265 win 8192 (DF) 09:05:18.185635 142.58.12.69.20 > 216.155.171.38.1269: . 11265:11777(512) ack 1 win 61440 [tos 0x8] 09:05:18.331014 216.155.171.38.1269 > 142.58.12.69.20: . ack 11777 win 8192 (DF) 09:05:18.342700 142.58.12.69.20 > 216.155.171.38.1269: . 11777:12289(512) ack 1 win 61440 [tos 0x8] 09:05:18.512043 142.58.12.69.20 > 216.155.171.38.1269: . 12289:12801(512) ack 1 win 61440 [tos 0x8] 09:05:18.523864 216.155.171.38.1269 > 142.58.12.69.20: . ack 12801 win 8192 (DF) 09:05:19.087354 142.58.12.69.20 > 216.155.171.38.1269: . 12801:13313(512) ack 1 win 61440 [tos 0x8] 09:05:19.230982 216.155.171.38.1269 > 142.58.12.69.20: . ack 13313 win 8192 (DF) 09:05:19.265467 142.58.12.69.20 > 216.155.171.38.1269: . 13313:13825(512) ack 1 win 61440 [tos 0x8] 09:05:19.413197 142.58.12.69.20 > 216.155.171.38.1269: . 13825:14337(512) ack 1 win 61440 [tos 0x8] 09:05:19.420961 216.155.171.38.1269 > 142.58.12.69.20: . ack 14337 win 8192 (DF) 09:05:19.543339 142.58.12.69.20 > 216.155.171.38.1269: . 14337:14849(512) ack 1 win 61440 [tos 0x8] 09:05:19.730974 216.155.171.38.1269 > 142.58.12.69.20: . ack 14849 win 8192 (DF) 09:05:20.010628 142.58.12.69.20 > 216.155.171.38.1269: . 14849:15361(512) ack 1 win 61440 [tos 0x8] 09:05:20.130926 216.155.171.38.1269 > 142.58.12.69.20: . ack 15361 win 8192 (DF) 09:05:20.155427 142.58.12.69.20 > 216.155.171.38.1269: . 15361:15873(512) ack 1 win 61440 [tos 0x8] 09:05:20.330918 216.155.171.38.1269 > 142.58.12.69.20: . ack 15873 win 8192 (DF) 09:05:20.347258 142.58.12.69.20 > 216.155.171.38.1269: . 15873:16385(512) ack 1 win 61440 [tos 0x8] 09:05:20.484003 142.58.12.69.20 > 216.155.171.38.1269: . 16385:16897(512) ack 1 win 61440 [tos 0x8] 09:05:20.491954 216.155.171.38.1269 > 142.58.12.69.20: . ack 16897 win 8192 (DF)

PAGE 129

121 09:05:20.947187 142.58.12.69.20 > 216.155.171.38.1269: . 16897:17409(512) ack 1 win 61440 [tos 0x8] 09:05:21.099514 142.58.12.69.20 > 216.155.171.38.1269: . 17409:17921(512) ack 1 win 61440 [tos 0x8] 09:05:21.108760 216.155.171.38.1269 > 142.58.12.69.20: . ack 17921 win 8192 (DF) 09:05:21.287718 142.58.12.69.20 > 216.155.171.38.1269: . 17921:18433(512) ack 1 win 61440 [tos 0x8] 09:05:21.433747 216.155.171.38.1269 > 142.58.12.69.20: . ack 18433 win 8192 (DF) 09:05:21.760803 142.58.12.69.20 > 216.155.171.38.1269: . 18433:18945(512) ack 1 win 61440 [tos 0x8] 09:05:21.927836 142.58.12.69.20 > 216.155.171.38.1269: . 18945:19457(512) ack 1 win 61440 [tos 0x8] 09:05:21.938727 216.155.171.38.1269 > 142.58.12.69.20: . ack 19457 win 8192 (DF) 09:05:22.027299 142.58.12.69.20 > 216.155.171.38.1269: . 19457:19969(512) ack 1 win 61440 [tos 0x8] 09:05:22.138722 216.155.171.38.1269 > 142.58.12.69.20: . ack 19969 win 8192 (DF) 09:05:22.992960 142.58.12.69.20 > 216.155.171.38.1269: . 19969:20481(512) ack 1 win 61440 [tos 0x8] 09:05:23.130984 142.58.12.69.20 > 216.155.171.38.1269: . 20481:20993(512) ack 1 win 61440 [tos 0x8] 09:05:23.138681 216.155.171.38.1269 > 142.58.12.69.20: . ack 20481 win 8192 (DF) 09:05:23.315644 142.58.12.69.20 > 216.155.171.38.1269: . 20993:21505(512) ack 1 win 61440 [tos 0x8] 09:05:23.328672 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:25.985431 142.58.12.69.20 > 216.155.171.38.1269: . 16897:17409(512) ack 1 win 61440 [tos 0x8] 09:05:25.998600 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:33.569829 142.58.12.69.20 > 216.155.171.38.1269: . 18433:18945(512) ack 1 win 61440 [tos 0x8] 09:05:33.577451 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:33.991109 142.58.12.69.20 > 216.155.171.38.1269: . 18945:19457(512) ack 1 win 61440 [tos 0x8] 09:05:34.003263 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:34.435700 142.58.12.69.20 > 216.155.171.38.1269: . 19457:19969(512) ack 1 win 61440 [tos 0x8] 09:05:34.448245 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:34.859515 142.58.12.69.20 > 216.155.171.38.1269: . 19969:20481(512) ack 1 win 61440 [tos 0x8] 09:05:34.868228 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:35.272366 142.58.12.69.20 > 216.155.171.38.1269: . 20481:20993(512) ack 1 win 61440 [tos 0x8] 09:05:35.283213 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF) 09:05:35.723703 142.58.12.69.20 > 216.155.171.38.1269: . 20993:21505(512) ack 1 win 61440 [tos 0x8] 09:05:35.733194 216.155.171.38.1269 > 142.58.12.69.20: . ack 21505 win 8192 (DF)

PAGE 130

122 09:05:36.138244 142.58.12.69.20 > 216.155.171.38.1269: . 21505:22017(512) ack 1 win 61440 [tos 0x8] 09:05:36.343172 216.155.171.38.1269 > 142.58.12.69.20: . ack 22017 win 8192 (DF) 09:05:36.588169 142.58.12.69.20 > 216.155.171.38.1269: . 22017:22529(512) ack 1 win 61440 [tos 0x8] 09:05:36.748156 216.155.171.38.1269 > 142.58.12.69.20: . ack 22529 win 8192 (DF) 09:05:37.027882 142.58.12.69.20 > 216.155.171.38.1269: . 22529:23041(512) ack 1 win 61440 [tos 0x8] 09:05:37.148141 216.155.171.38.1269 > 142.58.12.69.20: . ack 23041 win 8192 (DF) 09:05:37.621507 142.58.12.69.20 > 216.155.171.38.1269: . 23041:23553(512) ack 1 win 61440 [tos 0x8] 09:05:37.748120 216.155.171.38.1269 > 142.58.12.69.20: . ack 23553 win 8192 (DF) 09:05:37.995878 142.58.12.69.20 > 216.155.171.38.1269: . 23553:24065(512) ack 1 win 61440 [tos 0x8] 09:05:38.148130 216.155.171.38.1269 > 142.58.12.69.20: . ack 24065 win 8192 (DF) 09:05:38.390291 142.58.12.69.20 > 216.155.171.38.1269: . 21505:22017(512) ack 1 win 61440 [tos 0x8] 09:05:38.403092 216.155.171.38.1269 > 142.58.12.69.20: . ack 24065 win 8192 (DF) 09:05:39.402057 142.58.12.69.20 > 216.155.171.38.1269: . 24065:24577(512) ack 1 win 61440 [tos 0x8] 09:05:39.498894 142.58.12.69.20 > 216.155.171.38.1269: . 24577:25089(512) ack 1 win 61440 [tos 0x8] 09:05:39.508050 216.155.171.38.1269 > 142.58.12.69.20: . ack 25089 win 8192 (DF) 09:05:39.791448 142.58.12.69.20 > 216.155.171.38.1269: . 25089:25601(512) ack 1 win 61440 [tos 0x8] 09:05:39.953031 216.155.171.38.1269 > 142.58.12.69.20: . ack 25601 win 8192 (DF) 09:05:40.222826 142.58.12.69.20 > 216.155.171.38.1269: . 25601:26113(512) ack 1 win 61440 [tos 0x8] 09:05:40.353018 216.155.171.38.1269 > 142.58.12.69.20: . ack 26113 win 8192 (DF) 09:05:42.554382 142.58.12.69.20 > 216.155.171.38.1269: . 26113:26625(512) ack 1 win 61440 [tos 0x8] 09:05:42.656037 142.58.12.69.20 > 216.155.171.38.1269: . 26625:27137(512) ack 1 win 61440 [tos 0x8] 09:05:42.667929 216.155.171.38.1269 > 142.58.12.69.20: . ack 27137 win 8192 (DF) 09:05:42.849815 142.58.12.69.20 > 216.155.171.38.1269: . 27137:27649(512) ack 1 win 61440 [tos 0x8] 09:05:42.946855 142.58.12.69.20 > 216.155.171.38.1269: . 27649:28161(512) ack 1 win 61440 [tos 0x8] 09:05:42.957916 216.155.171.38.1269 > 142.58.12.69.20: . ack 28161 win 8192 (DF) 09:05:43.103042 142.58.12.69.20 > 216.155.171.38.1269: . 28161:28673(512) ack 1 win 61440 [tos 0x8] 09:05:43.257904 216.155.171.38.1269 > 142.58.12.69.20: . ack 28673 win 8192 (DF) 09:05:43.873693 142.58.12.69.20 > 216.155.171.38.1269: . 28673:29185(512) ack 1 win 61440 [tos 0x8] 09:05:44.042733 142.58.12.69.20 > 216.155.171.38.1269: . 29185:29697(512) ack 1 win 61440 [tos 0x8]

PAGE 131

123 09:05:44.052875 216.155.171.38.1269 > 142.58.12.69.20: . ack 29697 win 8192 (DF) 09:05:44.776639 142.58.12.69.20 > 216.155.171.38.1269: . 29697:30209(512) ack 1 win 61440 [tos 0x8] 09:05:44.957752 142.58.12.69.20 > 216.155.171.38.1269: . 30209:30721(512) ack 1 win 61440 [tos 0x8] 09:05:44.957891 216.155.171.38.1269 > 142.58.12.69.20: . ack 30209 win 8192 (DF) 09:05:45.149849 142.58.12.69.20 > 216.155.171.38.1269: . 30721:31233(512) ack 1 win 61440 [tos 0x8] 09:05:45.157831 216.155.171.38.1269 > 142.58.12.69.20: . ack 30721 win 8192 (DF) 09:05:45.251788 142.58.12.69.20 > 216.155.171.38.1269: . 31233:31745(512) ack 1 win 61440 [tos 0x8] 09:05:45.262828 216.155.171.38.1269 > 142.58.12.69.20: . ack 31745 win 8192 (DF) 09:05:45.708536 142.58.12.69.20 > 216.155.171.38.1269: . 31745:32257(512) ack 1 win 61440 [tos 0x8] 09:05:45.862805 216.155.171.38.1269 > 142.58.12.69.20: . ack 32257 win 8192 (DF) 09:05:45.897407 142.58.12.69.20 > 216.155.171.38.1269: . 32257:32769(512) ack 1 win 61440 [tos 0x8] 09:05:46.062798 216.155.171.38.1269 > 142.58.12.69.20: . ack 32769 win 8192 (DF) 09:05:46.779500 142.58.12.69.20 > 216.155.171.38.1269: . 32769:33281(512) ack 1 win 61440 [tos 0x8] 09:05:46.945263 142.58.12.69.20 > 216.155.171.38.1269: . 33281:33793(512) ack 1 win 61440 [tos 0x8] 09:05:46.957762 216.155.171.38.1269 > 142.58.12.69.20: . ack 33793 win 8192 (DF) 09:05:47.128224 142.58.12.69.20 > 216.155.171.38.1269: . 33793:34305(512) ack 1 win 61440 [tos 0x8] 09:05:47.247096 142.58.12.69.20 > 216.155.171.38.1269: . 34305:34817(512) ack 1 win 61440 [tos 0x8] 09:05:47.257751 216.155.171.38.1269 > 142.58.12.69.20: . ack 34817 win 8192 (DF) 09:05:47.375533 142.58.12.69.20 > 216.155.171.38.1269: . 34817:35329(512) ack 1 win 61440 [tos 0x8] 09:05:47.504942 142.58.12.69.20 > 216.155.171.38.1269: . 35329:35841(512) ack 1 win 61440 [tos 0x8] 09:05:47.517740 216.155.171.38.1269 > 142.58.12.69.20: . ack 35841 win 8192 (DF) 09:05:47.973700 142.58.12.69.20 > 216.155.171.38.1269: . 35841:36353(512) ack 1 win 61440 [tos 0x8] 09:05:48.141151 142.58.12.69.20 > 216.155.171.38.1269: . 36353:36865(512) ack 1 win 61440 [tos 0x8] 09:05:48.152716 216.155.171.38.1269 > 142.58.12.69.20: . ack 36865 win 8192 (DF) 09:05:48.623203 142.58.12.69.20 > 216.155.171.38.1269: . 36865:37377(512) ack 1 win 61440 [tos 0x8] 09:05:48.767719 216.155.171.38.1269 > 142.58.12.69.20: . ack 37377 win 8192 (DF) 09:05:48.792495 142.58.12.69.20 > 216.155.171.38.1269: . 37377:37889(512) ack 1 win 61440 [tos 0x8] 09:05:48.967684 216.155.171.38.1269 > 142.58.12.69.20: . ack 37889 win 8192 (DF) 09:05:49.259031 142.58.12.69.20 > 216.155.171.38.1269: . 37889:38401(512) ack 1 win 61440 [tos 0x8]

PAGE 132

124 09:05:49.404868 142.58.12.69.20 > 216.155.171.38.1269: . 38401:38913(512) ack 1 win 61440 [tos 0x8] 09:05:49.417667 216.155.171.38.1269 > 142.58.12.69.20: . ack 38913 win 8192 (DF) 09:05:49.617713 142.58.12.69.20 > 216.155.171.38.1269: . 38913:39425(512) ack 1 win 61440 [tos 0x8] 09:05:49.731593 142.58.12.69.20 > 216.155.171.38.1269: . 39425:39937(512) ack 1 win 761440 [tos 0x8] 09:05:49.742654 216.155.171.38.1269 > 142.58.12.69.20: . ack 39937 win 8192 (DF) 09:05:49.866472 142.58.12.69.20 > 216.155.171.38.1269: . 39937:40449(512) ack 1 win 61440 [tos 0x8] 09:05:49.996842 142.58.12.69.20 > 216.155.171.38.1269: . 40449:40961(512) ack 1 win 61440 [tos 0x8] 09:05:50.007644 216.155.171.38.1269 > 142.58.12.69.20: . ack 40961 win 8192 (DF) 09:05:50.189355 142.58.12.69.20 > 216.155.171.38.1269: . 40961:41473(512) ack 1 win 61440 [tos 0x8] 09:05:50.288755 142.58.12.69.20 > 216.155.171.38.1269: . 41473:41985(512) ack 1 win 61440 [tos 0x8] 09:05:50.297633 216.155.171.38.1269 > 142.58.12.69.20: . ack 41985 win 8192 (DF) 09:05:50.446707 142.58.12.69.20 > 216.155.171.38.1269: . 41985:42497(512) ack 1 win 61440 [tos 0x8] 09:05:50.457628 216.155.171.38.1269 > 142.58.12.69.20: . ack 42497 win 8192 (DF) 09:05:51.019042 142.58.12.69.20 > 216.155.171.38.1269: . 42497:43009(512) ack 1 win 61440 [tos 0x8] 09:05:51.118235 142.58.12.69.20 > 216.155.171.38.1269: . 43009:43521(512) ack 1 win 61440 [tos 0x8] 09:05:51.127604 216.155.171.38.1269 > 142.58.12.69.20: . ack 43521 win 8192 (DF) 09:05:51.218977 142.58.12.69.20 > 216.155.171.38.1269: . 43521:44033(512) ack 1 win 61440 [tos 0x8] 09:05:51.339054 142.58.12.69.20 > 216.155.171.38.1269: . 44033:44545(512) ack 1 win 61440 [tos 0x8] 09:05:51.347594 216.155.171.38.1269 > 142.58.12.69.20: . ack 44545 win 8192 (DF) 09:05:51.830939 142.58.12.69.20 > 216.155.171.38.1269: . 44545:45057(512) ack 1 win 61440 [tos 0x8] 09:05:51.982572 216.155.171.38.1269 > 142.58.12.69.20: . ack 45057 win 8192 (DF) 09:05:51.986262 142.58.12.69.20 > 216.155.171.38.1269: . 45057:45569(512) ack 1 win 61440 [tos 0x8] 09:05:52.151316 142.58.12.69.20 > 216.155.171.38.1269: . 45569:46081(512) ack 1 win 61440 [tos 0x8] 09:05:52.162562 216.155.171.38.1269 > 142.58.12.69.20: . ack 46081 win 8192 (DF) 09:05:52.275095 142.58.12.69.20 > 216.155.171.38.1269: . 46081:46593(512) ack 1 win 61440 [tos 0x8] 09:05:52.482549 216.155.171.38.1269 > 142.58.12.69.20: . ack 46593 win 8192 (DF) 09:05:52.709545 142.58.12.69.20 > 216.155.171.38.1269: . 46593:47105(512) ack 1 win 61440 [tos 0x8] 09:05:52.882800 216.155.171.38.1269 > 142.58.12.69.20: . ack 47105 win 8192 (DF)

PAGE 133

125 09:05:52.928426 142.58.12.69.20 > 216.155.171.38.1269: . 47105:47617(512) ack 1 win 61440 [tos 0x8] 09:05:53.031470 142.58.12.69.20 > 216.155.171.38.1269: . 47617:48129(512) ack 1 win 61440 [tos 0x8] 09:05:53.042720 216.155.171.38.1269 > 142.58.12.69.20: . ack 48129 win 8192 (DF) 09:05:53.133538 142.58.12.69.20 > 216.155.171.38.1269: . 48129:48641(512) ack 1 win 61440 [tos 0x8] 09:05:53.234553 142.58.12.69.20 > 216.155.171.38.1269: . 48641:49153(512) ack 1 win 61440 [tos 0x8] 09:05:53.247521 216.155.171.38.1269 > 142.58.12.69.20: . ack 49153 win 8192 (DF) 09:05:53.333173 142.58.12.69.20 > 216.155.171.38.1269: . 49153:49665(512) ack 1 win 61440 [tos 0x8] 09:05:53.432518 142.58.12.69.20 > 216.155.171.38.1269: . 49665:50177(512) ack 1 win 61440 [tos 0x8] 09:05:53.442516 216.155.171.38.1269 > 142.58.12.69.20: . ack 50177 win 8192 (DF) 09:05:53.550488 142.58.12.69.20 > 216.155.171.38.1269: . 50177:50689(512) ack 1 win 61440 [tos 0x8] 09:05:53.665639 142.58.12.69.20 > 216.155.171.38.1269: . 50689:51201(512) ack 1 win 61440 [tos 0x8] 09:05:53.677503 216.155.171.38.1269 > 142.58.12.69.20: . ack 51201 win 8192 (DF) 09:05:53.790775 142.58.12.69.20 > 216.155.171.38.1269: . 51201:51713(512) ack 1 win 61440 [tos 0x8] 09:05:53.992496 216.155.171.38.1269 > 142.58.12.69.20: . ack 51713 win 8192 (DF) 09:05:54.242111 142.58.12.69.20 > 216.155.171.38.1269: . 51713:52225(512) ack 1 win 61440 [tos 0x8] 09:05:54.397477 216.155.171.38.1269 > 142.58.12.69.20: . ack 52225 win 8192 (DF) 09:05:54.405744 142.58.12.69.20 > 216.155.171.38.1269: . 52225:52737(512) ack 1 win 61440 [tos 0x8] 09:05:54.567184 142.58.12.69.20 > 216.155.171.38.1269: . 52737:53249(512) ack 1 win 61440 [tos 0x8] 09:05:54.577468 216.155.171.38.1269 > 142.58.12.69.20: . ack 53249 win 8192 (DF) 09:05:54.705510 142.58.12.69.20 > 216.155.171.38.1269: . 53249:53761(512) ack 1 win 61440 [tos 0x8] 09:05:54.717465 216.155.171.38.1269 > 142.58.12.69.20: . ack 53761 win 8192 (DF) 09:05:54.848795 142.58.12.69.20 > 216.155.171.38.1269: . 53761:54273(512) ack 1 win 61440 [tos 0x8] 09:05:54.997454 216.155.171.38.1269 > 142.58.12.69.20: . ack 54273 win 8192 (DF) 09:05:55.011000 142.58.12.69.20 > 216.155.171.38.1269: . 54273:54785(512) ack 1 win 61440 [tos 0x8] 09:05:55.183857 142.58.12.69.20 > 216.155.171.38.1269: . 54785:55297(512) ack 1 win 61440 [tos 0x8] 09:05:55.192445 216.155.171.38.1269 > 142.58.12.69.20: . ack 55297 win 8192 (DF) 09:05:55.359698 142.58.12.69.20 > 216.155.171.38.1269: . 55297:55809(512) ack 1 win 61440 [tos 0x8] 09:05:55.457282 142.58.12.69.20 > 216.155.171.38.1269: . 55809:56321(512) ack 1 win 61440 [tos 0x8]

PAGE 134

126 LIST OF REFERENCES [1] L. Harte, S. Prokup, Cellular and PCS/PCN Telephones and Systems , APDG Publishing, Fuquay-Varina, NC, 1996. [2] H. Latchman, Computer Communication Networks and the Internet , McGraw-Hill, New York, 1997. [3] S. Redl, M. Weber, M. Oliphant, An Introduction to GSM , Artech House, Norwood, MA, 1995. [4] European Telecommunications Standards Institute, GSM 03.34, Digital Cellular Telecommunications system (Phase 2+), High-Speed Circuit Switched Data (HSCSD), Stage 2, 1997. [5] European Telecommunications Standards Institute, GSM 03.64, Digital Cellular Telecommunications system (Phase 2+), General Packet Radio Service (GPRS), Overall description of the GPRS radio interface , 1997. [6] European Telecommunications Standards Institute, SMG95/97, EDGE Feasibility Study, Work Item 184, Improved Data Rates through Optimized Modulation , version 0.3, 1997. [7] T. Ojanpera, R. Prasad, Wideband CDMA for Third Generation Mobile Communications , Artech House, Boston, MA, 1998. [8] T. Kokkola, Analysis and measurements of the performance characteristics of GSM data services , Master ’ s Thesis to the University of Helsinki, October 1995. [9] D. Zhou, M. Zukerman, Performance and Efficiency Evaluation of Channel Allocation Schemes for HSCSD in GSM , IEEE Proceedings of the Global Telecommunications Conference, December 1999, Volume 1b, pp. 1084. [10] European Telecommunications Standards Institute, GSM 04.65, Digital Cellular Telecommunications system (Phase 2+), General Packet Radio Service (GPRS), Subnetwork Dependent Convergence Protocol (SNDCP) , 1999. [11] European Telecommunications Standards Institute, GSM 04.64, Digital Cellular Telecommunications system (Phase 2+), General Packet Radio Service (GPRS), Logical Link Control (LLC) layer specification , 1999.

PAGE 135

127 [12] European Telecommunications Standards Institute, GSM 04.60, Digital Cellular Telecommunications system (Phase 2+), General Packet Radio Service (GPRS), Radio Link Control/Medium Access Control (RLC/MAC) , 1999. [13] Motorola Inc., Motorola Timeport P7389i , http://commerce.motorola.com/cgibin/ncommerce3/CategoryDisplay/ , 2001. [14] W. R. Stevens, TCP/IP Illustrated, Volume I: The Protocols , Addison Wesley, Boston, MA, 1994. [15] European Telecommunications Standards Institute, GSM 07.60, Digital Cellular Telecommunications system (Phase 2+), General Packet Radio Service (GPRS), Mobile Station Supporting GPRS , 1999. [16] M. Meyer, TCP Performance over GPRS , Proceedings of the Wireless Communications and Networking Conference; 21-24 Sept 1999, IEEE WCNC, Volume 3 pp. 1248. [17] R. Ludwig, R. Katz, The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions , Computer Communication Review, January 2000, Volume 30 Number 1. [18] J . Rendon, F. Casadevall, J Faner , Wireline TCP Options Behavious in the GPRS Network , Polythecnic University of Catalonia (UPC) – Department of Signal Theory and Communications, Barcelona, Spain, 2000. [19] Degionanni, Loris and Piero Viano and Fulvio Risso, WinDump 3.6.2: TCPDump for Windows , http://netgroup-serv.polito.it/windump/ , Politecnicio di Torino, Italy 2000. [20] S. Ostermann, TCPTrace , http://jarok.cs.ohiou.edu/software/tcptrace/tcptrace.html , University of Ohio, 2001.

PAGE 136

128 BIOGRAPHICAL SKETCH Jos Enrique Snchez-Vlez was born in San Juan, Puerto Rico, in 1973. In 1990 he joined the electrical and computer engineering program at the University of Puerto Rico. He completed his Bachelor of Science in Computer Engineering in 1994 graduating magna cum laude. During his tenure at the University of Puerto Rico he received several opportunities to join Motorola, Inc., as a part time employee. In 1994 he joined Motorola Inc. as a full time employee. Currently Jos holds the position of Senior Staff Software Engineer at Motorola and works in the design and development of software for digital cellular phones. He holds one U.S. government patent. In 1996 he joined the FEEDS program and entered the graduate program in electrical and computer engineering at the University of Florida. His interests include networking, embedded microcomputer software and world history.