Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Performance evaluation of two transport protocols for image transmission over CDPD networks Zhou, Jun 1998

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1998-0682.pdf [ 5.55MB ]
Metadata
JSON: 831-1.0064854.json
JSON-LD: 831-1.0064854-ld.json
RDF/XML (Pretty): 831-1.0064854-rdf.xml
RDF/JSON: 831-1.0064854-rdf.json
Turtle: 831-1.0064854-turtle.txt
N-Triples: 831-1.0064854-rdf-ntriples.txt
Original Record: 831-1.0064854-source.json
Full Text
831-1.0064854-fulltext.txt
Citation
831-1.0064854.ris

Full Text

PERFORMANCE EVALUATION OF TWO TRANSPORT PROTOCOLS FOR IMAGE TRANSMISSION OVER CDPD NETWORKS by JUN ZHOU M.Eng., Tsinghua University, 1993 B.Eng., Tsinghua University, 1988 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF APPLIED SCIENCE in THE FACULTY OF GRADUATE STUDIES DEPARTMENT OF ELECTRICAL AND COMPUTER ENGINEERING We accept this thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA October 1998 © Jun Zhou, 1998 In presenting this thesis in partial fulfilment of the requirements for an advanced degree at the University of British Columbia, I agree that the Library shall make it freely available for reference and study. I further agree that permission for extensive copying of this thesis for scholarly purposes may be granted by the head of my department or by his or her representatives. It is understood that copying or publication of this thesis for financial gain shall not be allowed without my written permission. Department of £\<l-c^r^cA c\^A C^P^p h/t&r ^ j hjiury^ The University of British Columbia Vancouver, Canada Date QrAolwr IU, 1^8 DE-6 (2/88) Abstract Due to the low bandwidth and harsh noise characteristics of cellular wireless networks, the transmission of images over these networks may require a long time, especially if the transport protocol used is the standard Transmission Control Protocol (TCP), which has been tuned for more reliable wireline networks. In this thesis, we study and compare the performance of two efficient image transmission schemes suitable for low bit rate wireless data networks. The Cellular Digital Packet Data (CDPD) network is chosen as the example wireless data network in this research. Scheme 1 uses the standard TCP in conjunction with a flexible image transmission strategy, in which the amount of image data sent is negotiated by the client according to a desired image quality. Scheme 2 uses a new file transfer protocol called Image File Transfer Protocol (IFTP), and is built on the top of the User Datagram Protocol (UDP) in the transport layer. IFTP keeps the error and retransmission control in the application, and transmits the progressive JPEG image scan by scan in a sequence according to the scan priorities. An extensive OPNET model is developed for the performance evaluation of the two proposed image transmission schemes. Simulation results show that IFTP is functionally sound in a multi-link network and outperforms the TCP-based scheme in terms of image transmission time. Table of Contents Abstract ii List of Tables vi List of Figures vii Acknowledgement ix Chapter 1 Introduction.... .". 1 1.1 Overview 1 1.1.1 Background of Image Compression and Transmission 1 1.1.2 Wireless Data Networks 3 1.2 Motivation and Scope of This Thesis ..-5 Chapter 2 Wireless Data Networks 7 2.1 Overview of Wireless Data Networks : 7 2.2 Internet Protocol Stack 9 2.3 CDPD Network Architecture 14 2.3.1 CDPD Components 16 2.3.2 Airlink Protocol Profile 17 Chapter 3 JPEG Image Compression 21 3.1 Overview 21 3.2 Progressive Mode JPEG 25 3.3 Rate-Distortion Optimized Progressive JPEG 27 iii Chapter 4 JPEG Image Transmission over CDPD Network 32 4.1 Overview : 32 4.2 Scheme 1 - Sending Scans According to Its Importance Class with TCP 32 4.3 Scheme 2 - Image File Transfer Protocol (IFTP) 35 4.3.1 Server IFTP 36 4.3.2 Client IFTP.... ; 39 Chapter 5 Design of a Simulation Model 42 5.1 Overview of the OPNET Simulation Tool... : 42 5.2 CDPD Airlink Model Design. 45 5.2.1 Physical Layer Model 45 5.2.2 MAC Layer Model 48 5.2.3 MDLP Layer Model 51 5.2.4 SNDCP Layer Model 55 5.2.4 Node Model of the Airlink '. 57 5.3 LFTP Model 59 5.3.1 Client IFTP model 59 5.3.2 Server IFTP model .' 60 5.4 CDPD Network Configuration 61 Chapter 6 Simulations and Results 67 6.1 Simulation of Scheme 1 Transmission with TCP 67 6.2 Simulation of Scheme 2 Transmission with IFTP 70 6.3 Comparison Between Scheme 1 (TCP) and Scheme 2 (IFTP) 73. 6.4 Simulation of Example Image File Transfers 76 6.5 Impact of IFTP on the Other TCP Users 78 iv Chapter 7 Conclusions and Further Study 81 Glossary of Abbreviations 84 REFERENCES.... 86 Appendix A Source Code of the Client IFTP Model 88 Appendix B Source Code of the Server IFTP Model 104 List of Tables Table 3.1 Relationship Between PSNR and Accumulated Number of Scans for the 512 x 512 Lena Image 31 Table 3.2 Scan Size and Importance Class of the 512 x 512 Lena Image 31 Table 4.1 Scan Priority for Lena Image 38 Table 5.1 BLER and Corresponding Fictitious BER.., 47 Table 6.1 Summary of the Parameter Used in Scheme 1 Simulation 68 Table 6.2 Summary of the Parameter Used in Scheme 2 Simulation 71 List of Figures Figure 1.1 The Cellular Digital Packet Data Network 4 Figure 2.1 OSI and the Internet Protocol Models 10 Figure 2.2 TCP Sliding Window.. 11 Figure 2.3 TCP Connection Establishment .'. 12 Figure 2.4 TCP Segment Header '. 13 Figure 2.5 UDP Segment Header 13 Figure 2.6 CDPD Network Overlay 14 Figure 2.7 A Typical CDPD Network 15 Figure 2.8 CDPD Airlink Protocol 18 Figure 3.1 DCT-Based Encoder and Decoder Processing Steps 22 Figure 3.2 Zig-Zag Sequence Structure of the DCT Coefficients 23 Figure 3.3 Data Format of Progressive Mode JPEG 26 Figure 3.4 An 8 x 8 x 10 Parallelepiped 28 Figure 4.1 Server IFTP System 36 Figure 4.2 Client IFTP System..... 39 Figure 5.1 OPNET Model Structure 43 Figure 5.2 MAC Layer Model in MDBS 50 Figure 5.3 Receiving Window of Selective Repeat ARQ..... 52 Figure 5.4 MDLP Model 53 vii Figure 5.5 SNDCP Segmentation Module ; 56 Figure 5.6 SNDCP Reassembly Module. 57 Figure 5.7 Node Model of the Airlink in the MES 58 Figure 5.8 Process Model of Client IFTP '. 59 Figure 5.9 Process Model of Server IFTP ': 60 Figure 5.10 CDPD Network Configuration 61 Figure 5.11 Structure of SubnetjO : 62 Figure 5.12 Structure of Subnet_l 63 Figure 5.13 Structure of Subnet_2 and Subnet_3 64 Figure 5.14 Structure of Subnet_4 64 Figure 5.15 Typical Structure of the IS ...:.65 Figure 5.16 Peripheral Node Model .' 66 Figure 6.1 A Typical Output Scalar File 69 Figure 6.2 TCP: Image Transmission Time vs. Network Traffic Load for Various BLERs 70 Figure 6.3 IFTP: Image Transmission Time vs. Network Traffic Load for Various BLERs 72 Figure 6.4 Comparison Between TCP and IFTP: BLER = 0 :...-....„......!.... 73 Figure 6.5 Comparison Between TCP and IFTP: BLER = 1% , '. 74 Figure 6.6 Comparison Between TCP and IFTP: BLER = 5% 74 Figure 6.7 TCP and IFTP Comparison: PSNR vs. Transmission Time for the Lena Image 77 Figure 6.8 Percentage of Transmission Time Saved by EFTP Compared to TCP 78 Figure 6.9 SubnetJ) for Study of the IFTP Impact on the Network 79 Figure 6,10 Impact on TCP Clients, with or without IFTP, at BLER=5% 80 viii Acknowledgement I would like to take this opportunity to thank my supervisor, Dr. Samir Kallel, for his continuous support and guidance. I would also like to thank Robert Link for his assistance, support and advice throughout this thesis work. Also, I would express my appreciation towards all my friends in the Efficient Image Transmission Strategies for Low Bit Rate Wireless Applications project team. ix Chapter 1 Introduction Images are fundamental to many applications. With the rising popularity of the Internet and wireless communications, image transmission over the wireless data network is becoming increasingly significant. Due to the low bandwidth and high noise of cellular wireless channels, image transmission over wireless channels is' more difficult than over wireline channels. Although the image is normally compressed before transmission, the image transmission may have a long time delay i f standard transport protocol for wireline networks is used in the case of wireless data networks. In this thesis, the performance of two schemes that try to address this problem is evaluated and compared. 1.1 Overview In this section, we briefly review image compression transmission techniques, and wireless data networks. 1.1.1 Background of Image Compression and Transmission Usually, the amount of data required to represent a digital image that is directly obtained from an image capture device, is huge. For example, a digitized version of a single, color picture at T V resolution contains on the order of one million bytes; 35mm resolution requires ten times that amount [4]. Because of the huge volumes of data involved, computer images are almost never transmitted or stored in their original format. Image compression techniques can exploit 1 . Chapter 1 Introduction 2 the high degree of data redundancy and result in significant reduction of the image size, thus relaxing the communicat ion and storage capacity requirements. However , even using compression techniques, image transmission over data networks demands high bandwidth. T h i s is not always available when using mobile computers and wireless data networks. Image compression techniques are classified as either lossless or lossy [7]. Lossless techniques, such as G I F and P N G , compress a'picture into a smaller number of bits. Lossless compressors preserve all the information in the image and only remove redundancies by using entropy encoding methods like L Z W and L Z 7 7 . Therefore, the exact same unaltered image is reproduced once . decompressed. Lossless compression reduces the original image size by encoding gray levels often used with fewer bits and those seldom used with more bits. Further lossless compression can be achieved by taking into account spatial redundancy in an image. L o s s y compression techniques such as those based on D C T (Discrete Cos ine Transform), wavelet transform, or fractal transform, achieve much higher compression ratios by removing information from the image which is unimportant with respect to the human eye. T h e most popular lossy compression approach is J P E G (Joint Photographic Expert Group) standard. T h e J P E G compression algorithm is the I S O standard for still images. It divides an image into blocks of 8 by 8 pixels, which are then converted into 64 values using the D C T . These values are analogous to frequency components. T h e loss of information is introduced by quantizing the D C T coefficients. After quantization, an entropy encoding step is performed. Wavelet based compression has become popular in image and video coding [3]. T h i s compression method is based on the wavelet transformation, which is usually implemented by quadrature mirror filters containing a high-pass and a low-pass filter. B y successive filtering and Chapter 1 Introduction 3 subsampling, the image is partitioned into a hierarchy of smaller images. Again, the loss of information is introduced by quantization. Fractal image compression is based on iterated function systems and exploits self-similarities in the image [3]. Image blocks of different size are considered similar to other blocks or their translated, rotated, mirrored and/or scaled copies according to a similarity function. The error metric of this function determines the loss of information. However, searching for similar blocks in an image is a process of high complexity. Although there are at least three lossy compression algorithms for still images, we only consider the JPEG standard. This is because not only is JPEG the industry standard and most popular for applications on the Internet, but also a JPEG image can have progressive mode structure suitable for transmission over a low bit rate wireless channel. The detailed discussion of JPEG image structure is in Chapter 3. 1.1.2 Wireless Data Networks Essentially, existing wireless communication systems can be categorized as either voice-oriented or data-oriented. Cellular and cordless telephones are typical examples of voice-oriented systems. The Advanced Mobile Phone System (AMPS) is the traditional analog cellular system implemented in North America. New generation digital cellular systems such as G S M , IS-54 and IS-95 are currently being deployed around the world to satisfy the large demand for voice communications. Data-oriented systems have grown out of the success of the paging-service industry and the increasing customer demand for more advanced services. Examples of these are proprietary wireless data networks, such as ARDIS and MOBITEX, which have been used for many years for various data transfer applications. The big demand for data-oriented services has Chapter I Introduction 1 4 recently resulted in an open standard called Cellular Digital Packet Data (CDPD) [1]. CDPD is designed to provide digital packet-switched data services as an overlay to existing analog AMPS cellular networks in use throughout North America. Due to its flexibility and the fact that it is an open standard, CDPD has been adopted by the cellular telephone industry to provide data services. Wireless public data networks such as CDPD provide end-to-end connectivity between land-based applications and mobile peer applications, essentially extending wireline based networks to mobile users. In a manner analogous to cellular telephone networks today, wireless packet data services have the potential to enable a broad range of applications such as telemetry, process control, transaction processing, and Internet access; The use of standard internetworking protocols like the Internet Protocol (IP) allows the mobile subscribers to gain services such as email, file transfer and World Wide Web (WWW). In this thesis, we focus on the CDPD network, whose sketch is shown in Figure 1.1. Mobile R a d i o S i t e Network Router Figure 1.1 The Cellular Digital Packet Data Network Chapter 1 Introduction 5 1.2 Motivation and Scope of This Thesis The usual method for image transmission over the Internet is to first compress the images using a lossy algorithm like JPEG, and then to transmit them across the intrinsically lossy packet switching network using the lossless TCP/IP protocol suite which is designed mainly for wireline channel applications. The standard File Transfer Protocol (FTP) is an example of such an application. Due to the wireless channel characteristics of low bit rate and low reliability, the transfer time of the image transmission will be very long if normal image transmission protocol for wireline channels is used in the case of wireless data networks like CDPD. To solve this problem, several schemes for efficient image transmission over wireless data networks have been proposed [5, 13, 14, 21]. An important feature of these schemes is that they allow the option of decreasing the image transmission time by sacrificing image quality. The example wireless data network used in our project is the CDPD network. In CDPD, 30 kHz channels are used to provide a 19.2 Kilobits per second (Kbps) raw data rate at the airlink. To increase power efficiency, a Forward Error Correction (FEC) redundant code is employed. This along with the data protocol overhead results in an even lower effective data rate, which is about 11 Kbps. The Automatic Retransmission Request (ARQ) can reduce this even further, often to as low as 1 Kbps, when the channel quality is poor. Thus, a typical 100-Kilobyte JPEG image can take 13.3 minutes to download. In our approach, the JPEG image is progressively encoded into scans, and the scans are assigned importance measure that corresponds to the visual impact of the data contained in the scan on the overall image quality. Two image transmission schemes which apply this JPEG algorithm are possible: Chapter 1 Introduction ' 6 1. Transmit scans successively according to decreasing importance, up to the client/server negotiated importance class, over one TCP connection. 2. Image File Transfer Protocol (IFTP) [5]: Uses UDP and places transport layer functionality into the application. Scans are selectively retransmitted via an acknowledgment scheme which depends on scan importance to visual quality. To carry out the performance analysis of these two schemes, an OPNET model for the CDPD network is developed. The purpose of the OPNET simulation is a) to verify the transport layer functionality of the application; b) to quantify the image transmission time versus the parameters of total network traffic and the airlink block error rate (BLER). These will allow us to evaluate the relative merit of both schemes. The performance comparison between TCP and IFTP is studied with respect to the CDPD airlink BLER and the offered network traffic load. The rest of this thesis is organized as follows. In Chapters 2 and 3, we review the CDPD network and the JPEG image structure, respectively, especially those aspects related to our work. Chapter 4 describes two schemes for JPEG image transmission over a CDPD network in detail. Chapter 5 outlines the simulation tool (OPNET), and describes the model of CDPD used for performance analysis of the image transmission schemes. Chapter 6 shows the results of various simulations and contains discussions of the results. Chapter 7 summarizes the analysis and concludes the work of this thesis project. Chapter 2 Wireless Data Networks 2.1 Overview of Wireless Data Networks Wireless networks can be characterized as either Wide Area Networks (WANs) or Local Area Networks (LANs). WANs include Cellular, Wide Area Paging, ARDIS and MOBITEX. These systems operate over a wide area ranging from a big city to the whole country. Among these systems, ARDIS and MOBITEX fall into the category of private wireless data networks. The ARDIS (Advanced Radio Data Information Service) packet data network was built by IBM and Motorola in 1984, mainly to provide in-building coverage [11]. By using overlapping cells of the same frequency, an increased coverage of the building is achieved. In ARDIS, two-level FM modulation on radio frequency links running at 4.8 Kbps with a packet size of 256 bytes are used. After protocol overhead is taken into account, the actual application data throughput is about 2 Kbps. Upgrading of ARDIS base stations to run at 19.2 Kbps is planned. Users can exchange electronic mail over ARDIS with both private and public email systems. MOBITEX is a protocol developed by Ericsson [11]. It is used in the RAM Data network. RAM Mobile Data was formed in 1989, and BellSouth became a major partner in 1992. The MOBITEX protocol uses GMSK as the modulation scheme in the airlink. Its radio channel data rate is 8 Kbps, and the actual data throughput is 2.4 to 4.8 Kbps. Cellular systems are mainly employed for voice communications. There are several standards for these systems that are implemented with different technologies. AMPS is the most 7 Chapter 2 Wireless Data Networks ' 8 widely used cellular infrastructure standard in North America. It is the first-generation wireless cellular telephone network and is based on analog signaling. Its counterpart in Europe is TACS (Total Access Communication System). As an analog system, AMPS does not have intrinsic ability for packet data transmission. Although it can use modems to establish a connection similar to the case in wireline modem connections, the drawbacks inherent to the technology constrain the widespread use of this method. CDPD is an attempt to support data transmission using the AMPS infrastructure . We will discuss CDPD in detail in the following sections. The next generation of cellular systems uses digital technologies. Standards such as GSM, IS-136 (TDMA) and IS-95 (CDMA) are being added to the existing infrastructure. The digital cellular systems have intrinsic ability for data communications. For example, two basic data transfer modes are available in GSM. One is the T-mode, in which error correction is entirely done by the forward error correction codes defined . as part of the radio interface transmission. The other is the NT-mode, in which a retransmission scheme is used to recover from frame errors. Although digital wireless systems are becoming increasingly dominant and the analog systems will fade out, the existing analog cellular infrastructure will be still in service for a time before PCS (Personal Communications Services) is established. Hence, CDPD as a bridge between the two technologies for wireless data communications will continue to be in service for. some years. LANs on the other hand have a maximum diameter of a few kilometers and employ technologies that are very different from those used for WANs. The implementation of LANs is to be independent of vendor and computer type. The access media for wireless LANs can be either infrared (IR) or radio [11]. IR technology is low cost, but it requires a line-of-sight Chapter 2 Wireless Data Networks 9 between the modules. It is most suited for applications in open working environments and in short range. Radio LANs are more flexible. The cost is relatively high and the speed is relatively low when radio LANs are compared to the IR LANs. In this thesis, we study image transmission over CDPD networks; therefore, in the following, we focus on the CDPD network, which is overlaid on the AMPS system infrastructure. 2.2 Internet Protocol Stack The CDPD standards supports both the Open System Interconnection (OSI) reference model and the Internet protocol stack. The OSI reference model was developed by the International Standards Organization [8]. It has seven layers, which are: physical layer, data link layer, network layer, transport layer, session layer, presentation layer and application layer. Due to the fact that nowadays the Internet is the actual standard in widespread use for internetworking, CDPD network are mainly based on the Internet protocol reference model. The Internet protocol stack has fewer layers than the OSI stack, but the functionality provided by these two models is almost the same. Figure 2.1 illustrates the layers of the OSI and TCP/IP based architectures, showing roughly the correspondence in functionality between the two protocol stack reference models. Chapter 2 Wireless Data Networks 10 OSI Application Presentation Session Transport Network Data link Physical TCP/IP Based Application Transport Internet Network Access Physical Figure 2.1 OSI and the Internet Protocol Models The transport layer and network layer protocols of the Internet are TCP and IP, respectively. IP is connectionless, it does not guarantee the delivery of the packets, called IP datagrams, from the upper transport layer. IP's main job is routing the datagram. In order to allow gateways or other intermediate systems to forward the datagram, it adds its own header. The main items in this header are the source and destination Internet addresses (32-bit), the protocol version information, and the checksum. ^ In the transport layer, there are two main protocols, the connection-oriented Transmission Control Protocol (TCP) and the connectionless User Datagram Protocol (UDP). TCP provides a reliable end-to-end byte stream over an unreliable internetwork. The IP layer gives no guarantee that datagrams will be delivered properly, so it is up to TCP to time out and retransmit them as need be. If datagrams arrive in wrong order, it is also up to TCP to re-order them in the proper sequence. TCP also provides a flow and error control mechanism. Chapter 2 Wireless Data Networks • 11 For flow and error control, TCP uses a sliding window scheme to coordinate the sender and receiver. The sender assigns a sequence number to every packet that it sends out, and the receiving side uses the sequence number to re-arrange the packets when they arrive out of order, and to eliminate duplicated packets. TCP does not provide a message boundary. The sender's transport layer will buffer up the incoming data bytes from application layer before passing them to the IP layer. Therefore, when an application passes data to TCP, this does not mean the data will be sent immediately. TCP will queue up the incoming data until the queue reaches to a certain size, at which point it will send out all the queued data in the form of a segment. If an application wants TCP to send the data out as soon as it gets it, a PUSH command has to be issued to flush the TCP queue buffer. During a session, TCP keeps the connection open between the sender and receiver until an application explicitly closes the connection. To illustrate the sliding window scheme, Figure 2.2 shows an example. 1 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 [ 10 | 11 | 12 | 13 | 14 15 v Figure 2.2 TCP Sliding Window In this example, packets 1 and 2 have been sent and acknowledged. Packets 3 to 13 have been sent but not acknowledged. Packets 14 and 15 have not been sent. If packet 3 is acknowledged, the window will move to the right by one and packet 14 will be sent. However, if packet 3 acknowledgement is lost or packet 3 is never acknowledged, packet 14 will never be sent. When the acknowledgement timer times out, packet 3 will be retransmitted, and packet 14 will only be sent when packet 3 is acknowledged by the receiver. Chapter 2 Wireless Data Networks 12 Connections are established in TCP using a three-way handshake. To establish a connection, the server waits for an incoming connection passively; the client sends a TCP segment of sequence number x with the SYN flag on and ACK flag off as a connection request. When this segment arrives at the server, an ACK segment for acknowledging x is sent back with its own sequence number y. Finally, the client will acknowledges the server's initial sequence number y in its next TCP segment. This process is shown in Figure 2.3. client server SYN (SEQ = x) time SYN (SEQ = x+1, ACK = y+1) Figure 2.3 T C P Connection Establishment The sending and receiving TCP entities exchange data in the form of segments. A TCP segment consists of a fixed 20-byte header followed by zero or more data bytes. The format of the TCP segment header is shown in Figure 2.4. Chapter 2 Wireless Data Networks 0 . 4 10 16 Source Port Destination Port Sequence Number Acknowledge Number TCP Header Length • Reserved Flags Window Size Checksum Urgent Pointer Options+. Padding Data ... (optional) Figure 2.4 T C P Segment Header In contrast, U D P does not provide any flow control, error control or packet sequencing. U D P provides a way for applications to send encapsulated raw IP datagrams and send them without having to establish a connection. A U D P segment consists of an 8-byte header followed by the data. The header is shown in Figure 2.5. 0 16 31 ' Source Port Destination Port Message Length Checksum Data ... Figure 2.5 U D P Segment Header It is clear that the U D P header is much shorter than that of T C P . The short U D P header is an additional advantage for the newly developed IFTP. Chapter 2 Wireless Data Networks 2.3 CDPD Network Architecture 14 Cellular Digital Packet Data (CDPD) is a packet data network that overlays the existing AMPS cellular telephone network infrastructure [2]. It uses either an idle channel normally dedicated to voice, or a dedicated channel for data transmission, to send bursts of packetized data between a mobile host (mobile end user, or MES) and a mobile data base station (MDBS). The base station sends the data along a wired network to a mobile data intermediate system (MD-IS), where the data is processed and forwarded to the correct mobile end user or fixed end user (FES), for example, a file server. ' Cell Site Figure 2.6 C D P D Network Overlay Figure 2.6 shows a cellular network with the CDPD overlay. The CDPD network shares the airlink, base station, and switching office with the AMPS network. In the AMPS network, calls arrive and acquire a radio channel of a base station. The transmissions travel over the Chapter 2 Wireless Data Networks 15 channel to the base station, where they are converted for transmission over wireline to the Mobile Telephone Switching Office (MTSO). From there, the calls are routed to their correct destinations. CDPD requires the addition of a base station that resides on the same site as the cellular voice base station. It also requires its own switching mechanism, a special router MD-IS, residing at the MTSO. Beyond the MTSO, the cellular voice network is connected to the public telephone network, while the CDPD network is connected to the'public data network. Figure 2.7 shows a typical CDPD network. It consists of a portion dedicated to mobile communication and a portion dedicated to non-mobile communication. The mobile portion consists of several kinds of nodes such as MES, MDBS and MD-IS. The fixed portion consists of several kinds of nodes such as MD-IS, intermediate system (IS) and fixed hosts like servers and databases, which are called Fixed End Systems (FES). The MD-IS is the connection between the mobile portion and the fixed portion. • MES Figure 2.7 A Typical CDPD Network Chapter 2 Wireless Data Networks 16 2.3.1 CDPD Components A typical CDPD network contains five major components. They are the Mobile End System, or MES; the Mobile Data Base Station, or MDBS; the Mobile Data Intermediate System, or MD-IS; the Intermediate System, or IS; and the Fixed End System, or FES. These five components work together to perform the data transfer service between the mobile user and the fixed data network. A CDPD session originates and/or terminates at an MES. The MES uses the wireless airlink interface, or A interface, to communicate with the MDBS. Packet transmission over the airlink has a raw data rate of 19.2 Kbps. Due to protocol and FEC overhead, the actual data rate is around 10 Kbps. The channel stream is a bi-directional communication path between a MDBS and a group of MESs, using a single RF channel pair at a time within a single cell. In the forward direction, the MDBS transmissions are received by all MESs listening to that channel stream. In the reverse direction, the MESs of a cell contend for the channel using the DSMA/CD (Digital Sense Multiple Access with Collision Detection) protocol. The MDBS has a function of relay between the MES and the MD-IS. In the forward direction, the MDBS receives data from the MD-IS and passes it to the MES. In the reverse direction, the MDBS receives data from the MESs via an RF channel, and routes this data to the MD-IS. The MDBS takes care of channel acquisition and maintenance matters. Both the MDBS and MD-IS play a role in assigning a channel to each MES at call setup time. The MD-IS accepts packets from the mobile end and converts them to IP format for transmission over the fixed network. Similarly, it accepts packets from the fixed network and Chapter 2 Wireless Data Networks . 17 processes them for transmission over the airlink. In addition, the MD-IS handles the registration (connection establishment) of each MES. The IS is a router in the fixed portion of the network. It is responsible for routing the packets according to a number of different network layer protocols such as IP in the Internet protocols and CLNP (Connectionless Network Protocol) in the ISO-OSI reference model. A CDPD network contains three interfaces. Figure 2.7 illustrates the different interfaces in the network. The A, or airlink, interface provides the link between the MES and the CDPD service provider network. It is comprised of RF channels. The E, or external, interface forms the connection between the service provider network and external data networks (FESs). The I, or interservice provider, interface comprises the interface between different service provider networks. Both the E and I interfaces are wired interfaces. Among these three interfaces, the airlink is the one unique to a wireless mobile data network like CDPD. 2.3.2 Airlink Protocol Profile The airlink provides the wireless radio frequency data communications between the MES and the MDBS and the MD-IS. Using the functions provided by the CDPD airlink, the mobile serving function.at the MD-IS communicates with each M-ES through the MDBS. Chapter 2 Wireless Data Networks 18 The airlink protocol stack sits under either the Internet protocol or the ISO connectionless network protocol. It is a collection of subprofiles that go into each of the network elements, namely, the MES, MDBS, and MD-IS. Figure 2.8 shows the airlink protocol profile. MES IP/CLNP SNDCP MDLP MAC Physical MDBS ; jj Shaded Area: Scope of the Airlink \ , MDLP Relay MAC . TP4 CLNP RNDOF Physical X.25/LAPD/PPP D So/Ethernet MD-IS IP/CLNP SNDCP MDLP CLNP SNPCF X.25/LAPD/PPP DStVEthernel Figure 2.8 CDPD Airlink Protocol The figure demonstrates that network layer protocol data units (NPDUs or packets) are transmitted across a mobile data link connection between the MES and the MD-IS using the mobile data link protocol (MDLP). The link layer protocol data units (called MDLP frames) are sent out in two steps, namely exchanges between the MD-IS and MDBS and exchanges between the MES and MDBS. The MD-IS to MDBS communications are dictated by the particular subnetwork protocol in use. The network layer (IP/CLNP) receives the data packets from the upper layers and transforms them into IP datagram or CLNP packets. Chapter 2 Wireless Data Networks 19 The Subnetwork Dependent Convergence Protocol (SNDCP) provides the following primary functions: • Segmentation/reassembly. The NPDU is segmented based on the maximum frame size handled by the link layer and an SNDCP header is added to each segment. • Compression/decompression. Optional header compression is implemented on the header portion of the NPDU packet and optional V.42bis data compression is implemented on the data portion. • Encryption/decryption. Encryption is performed on the data portion. The MDLP enables a point (MD-IS) to multipoint (MESs), connection-oriented, fully sequenced, and reliable data transfer. The protocol used at the MDLP layer is the Selective Repeat protocol. It provides the following main functions: • One or more logical data link connections on a channel stream. • Sequence control. • Flow control. • Frame error detection and correction by retransmissions. The Medium Access Control (MAC) layer provides arbitrated access to share the medium between MES and MDBS. In the MAC layer, a sequence of MDLP frames is converted into a bit stream by inserting at least a single frame flag between successive frames. The bit stream is Chapter 2 Wireless Data Networks 20 blocked into consecutive sets of bits and a (63, 47) Reed-Solomon encoding is performed. In reverse channel, the data and RS code bits (378 bits) are interleaved with 7 continuity indicator bits to form 385-bit blocks. In the forward channel, the data and RS code bits (378 bits) are interleaved with an additional 42 bits containing forward synchronization word, decode status, and busy/idle flags to make up a 420-bit block. CDPD uses a mechanism called Digital Sense Multiple Access with Collision Detection (DSMA/CD) in the MAC layer to arbitrate the medium share. DSMA/CD is very similar to CSMA/CD (Carrier Sense Multiple Access with Collision detection). In DSMA/CD, the forward channel includes transmission of busy/idle flags and decoding status as channel indicators. Mobile devices use the busy/idle flag to obtain information on whether another mobile device is already transmitting on the channel. The decode status indicator is transmitted by the MDBS to indicate whether it is successful in decoding the received data frame. The mobile device interprets a failure indication to indicate a possible collision in which case it initiates the back-off and retransmission mechanism. CDPD uses Gaussian Minimum Shift Keying (GMSK) as the modulation scheme in the physical layer. This is a constant envelope modulation scheme which has efficient bandwidth characteristics. Tuning to specific RF channel and controlling the output power are also functions performed in the physical layer. Chapter 3 JPEG Image Compression Normally, in order to transmit an image efficiently, images will be compressed prior to transmission. JPEG still image compression standard is one of the most widely used methods to achieve this. Here, we consider JPEG image transmission over the CDPD network [4]. 3.1 Overview In the current JPEG standard, both lossless and lossy compression implementations are possible. In a lossless compression mode, JPEG uses the predictive compression method. In the lossy compression implementation, the discrete cosine transform (DCT) is used. Since the compression ratio of the lossless mode is much less than that of the lossy modes, the lossless mode is not suitable for image transmission over wireless networks. Hence, we focus on the DCT-based JPEG compression. The basic steps of the DCT method are shown in Figure 3.1. The input image is first level-shifted by 2P-1, i.e., shifted from unsigned integers with range [0, 2p-l] to signed integers with range [-2PA, 2 P"'-l], where P is the number of bits per pixel. Then the pixel values of the image is divided into blocks of size 8 x 8, and each 8x8 block is transformed using an 8 x 8 forward DCT (FDCT). At the output of the decoder, the inverse DCT (IDCT) outputs the 8x8 block to form the reconstructed image [4, 7]. 21 Chapter 3 JPEG Image Compression 22 8x8 blocks Source Image Data Reconstructed Image Data FD.CT Encoder I DCT Quantizer Decoder Table Specifications Dequantizer Table Specifications Entropy Encoder Table Specifications Entropy Decoder Table Specifications Compressed Image Data Channel Compressed Image Data Figure 3.1 DCT-Based Encoder and Decoder Processing Steps In an image, the pixel values typically vary slowly from point to point so that most of the signal will be concentrated in the lower spatial frequencies. This forms the foundation for FDCT to provide compression. Most of the higher spatial frequencies have zero or near-zero amplitude and need not to be encoded. At the decoder, the IDCT reverse this process step. It takes the 64 DCT coefficients and reconstructs a 64-point output image signal by summing the basis signals. After output from the FDCT, each of the 64 DCT coefficients is quantized using uniform midtread quantization. The quantizer step sizes are organized in a table called a quantization table. The quantization table must be specified by the application, and there is an example of such a quantization table in the JPEG recommendation. This quantization will introduce quantization error, and it is the principle source of lossiness in the DCT-based JPEG encoder. Chapter 3 JPEG Image Compression 23 After the quantization, the DC coefficient is treated separately from the 63 AC coefficients for coding. The DC coefficient is a measure of the average value of the 64 image samples. Because there is usually strong correlation between the DC coefficients of adjacent 8 x 8 blocks, the quantized DC coefficient is encoded as the difference from the DC term of the previous block rather than that of the coefficients themselves. All of the AC coefficients are ordered into a "zig-zag" sequence as shown in Figure 3.2. DCOO AQ01 Af0"4" AC05 AGffO A0'11 A0'12 A.0'13 AJZU AC15 A£''i6 17 AC20 A021 A022 AC'23 AC24 AC'25 AG26 In A(/io A031 AC'32 AC'33 AC34 AC35 A036 37 AC40 A£f41 A€42 AC43 AG44 AG45 A046 '47 AC50 A€"51 AC52 AG53 A054 A055 A.G56 57 AC60 AC61 AGfe Ap'63 AG'64 A065 AC7CT AC72" £C73 AC74 ^C75 AC^" Figure 3.2 Zig-Zag Sequence Structure of the DCT Coefficients This ordering helps to facilitate entropy coding by placing low-frequency coefficients (which are more likely to be nonzero) before high-frequency coefficients. When encoding the AC coefficients, each nonzero AC coefficient is represented in combination with the run-length of zero-valued AC coefficients which precede it in the zig-zag sequence. Chapter 3 JPEG Image Compression 24 The final DCT-based encoder processing step is entropy coding. This step achieves additional compression losslessly by encoding the quantized DCT coefficients more compactly based on their statistical characteristics. The JPEG standard uses two entropy coding methods, Huffman coding and arithmetic coding. Huffman coding requires that one or more, sets of Huffman code tables. The tables can be specified by the application or computed specifically for a given image in an initial statistics-gathering pass prior to compression. The arithmetic coding method requires no tables. The DCT-based lossy JPEG can be implemented with various modes of operation as follows [4]: . • Sequential encoding: each image component is encoded in a single left-to-right, top-to-bottom scan; • Progressive encoding: the image is encoded in multiple scans for applications in which transmission time is long, and the viewer prefers to watch the images build up in multiple coarse-to-clear passes. • Hierarchical encoding: the image is encoded at multiple resolutions so that lower-resolution versions maybe accessed without first having to decompress the image at its full resolution. Among the above JPEG operation modes, the progressive mode is suitable for image transmission over the CDPD network due to the fact that the image can still be reconstructed, albeit at lower quality, with some scans missed during transmission. Chapter 3 JPEG Image Compression 25 3.2 Progressive Mode JPEG There are two complementary methods by which an image can be encoded in multiple scans. First, only a specified band of coefficients from the zig-zag sequence need be encoded within a scan. This procedure is called spectral selection, since each band typically contains coefficients which occupy a lower or higher part of the spatial-frequency spectrum for that 8x8 block. Second, the coefficients within the current band need not be encoded to their full accuracy in a given scan. Upon a coefficient's first encoding, the N most significant bits can be encoded first. In subsequent scans, the less significant bits can then be encoded. This procedure is called successive approximation. In the JPEG images, the compressed data formats consist of an ordered collection of parameters, markers, and entropy-coded data segments. Parameters and markers in turn are often organized into marker segments. Because all of these constituent parts are represented with byte-aligned codes, each compressed data format consists of an ordered sequence of 8-bit byte. Figure 3.3 shows the format that applies to the progressive mode JPEG image [12]. The abbreviations are defined as follows: • SOI = start of image marker; • EOI = end of image marker; • DNL = define number of lines; • RST = restart marker; Chapter 3 JPEG Image Compression 26 ECS = entropy-coded segment; • MCU = minimum coded unit. compressed image data SOI frame EOI frame [tables/misc] frame header scan, [DNL segment] [scanj s c a n nsi [table/misc] scan header [ECS„ RST„ ECSla>„, RST,„,.,] ECS / entropy-coded segment <MCU,>, <MCI_L>, ... Figure 3.3 Data Format of Progressive Mode J P E G Since a progressive mode compressed image file consists of several scans, the image transmission over a data network can be completed by sending one scan after another. At the receiver side, an image viewer can decode the scans that are already received to obtain an approximation of the whole image. As more scans arrive, the quality of the decoded image would increase steadily. When the quality of the reconstructed image, which is determined by the viewer, is high enough, the transmission process then can be terminated. This indicates that the image transmission over a network, especially a low bit rate wireless network such as CDPD, the progressive mode JPEG compression is the best choice. The proposed Image File Transfer Protocol (IFTP), as discussed later, uses the progressive JPEG as the image compression method. Chapter 3 JPEG Image Compression 27 3.3 Rate-Distortion Optimized Progressive JPEG In order to achieve the goal of progressive image transmission over bandwidth constrained wireless channels, and rate control at the same time, a new rate-distortion opt imized progressive image coding method based on J P E G has been proposed [6], which is compliant with J P E G standard. Thi s method is a hybrid version of spectral selection and successive approximation techniques that produces scans which are ordered according to decreasing visual importance. T h e proposed progressive J P E G ( P J P E G ) coding algorithm first tries to solve the relationship between the D C T coefficient and the reproduction quality. T o address the problem, all the bits of 64 D C T coefficients in an 8 x 8 block are assigned importance levels that involve the size of the resulting scan and the scan's contribution to distortion reduction. M o r e specifically, each bit in a D C T coefficient is assigned a distortion-rate ratio, whose numerator is the reduction in reconstruction distortion, and denominator is the scan's size in bytes. T h e resulting value is then used to associate with each bit a priority level. T a k i n g into account progressive J P E G ' s encoder structure and constraints, the prioritized bits are grouped, achieving higher compression efficiency and lower computational requirements. T h e grouped bits then are assigned with the same priority and encoded into one scan associated with the same importance class. A l l the scans are generated in a sequence of decreasing importance, which means the. earlier a scan is transmitted, the more important it is to the reduction in reconstruction distortion. Process of Bit Prioritization: A s s u m i n g 8-bit input precision, each D C T coefficient wi l l have 11-bit precision, 10 bits for magnitude and 1 bit for sign. E x c l u d i n g the sign bit, an 8 x 8 Chapter 3 JPEG Image Compression 28 D C T coefficient block can be considered as a parallelepiped which contains 8 x 8 x 10 or 640 bits as shown in Figure 3.4. A n image consists of a number of these parallelepipeds. DC00 AC01 AC02 AC03 AC04 AC05 AC06 AC07 DC10 AC11 AC12 AC13 AC14 AC15 AC16 AC17 DC20 AC21 AC22 AC23 AC24 AC25 AC26 AC27 DC30 AC31 AC32 AC33 AC34 AC35 AC36 AC37 DC40 AC41 AC42 AC43 AC44 AC45 AC46 AC47 DC50 AC51 AC52 AC53 AC54 AC55 AC56 AC57 DC60 AC61 AC62 AC63 AC64 AC65 AC66 AC67 DC70 AC71 AC72 AC73 AC74 AC75 AC76 AC77 LSB Figure 3.4 An 8 x 8 x 10 Parallelepiped T h e decoder assumes 8 x 8 x 10 parallelepipeds of all "0"s and the "0"s are replaced by the actual values o f the bits as they are decoded. Therefore, to quantify the effect o f each bit on the quality of the decoded image, the distortion associated with each bit being considered "0" is calculated. W h e n the value of a bit is "0", its associated distortion wi l l be equal to zero regardless o f its position, as the decoder has already assumed all the bits to,have a "0" value, and decoding a "0" bit wi l l not reduce the reconstruction distortion. In the progressive J P E G coding mode, each bit of the parallelepiped should be transmitted along with the bits at the same position of all the parallelepipeds in an image. Thus , the overall distortion reduction value should be equal to the sum of the distortion reduction values associated with the bits at the same position Chapter 3 JPEG Image Compression 29 in all the parallelepipeds in the image, that is, the overall distortion reduction A D , associated with the /th bit is equal to A D i = T ( b i j 2 " H ) 2 (3-1) where / = 1,2, . . . , 640, TV is the number of 8 x 8 blocks in the input image, bij is the value of the ith bit o f the y'th parallelepiped and /?, is the position of the ith bit. E n c o d i n g of bits at different locations in the parallelepipeds also results in different scan sizes or bit rates. T h u s , a rate-distortion optimized importance measure should involve the total distortion and bit rate values, and an appropriate importance measure 7, is then given by (3,2) where / , , A D , and A/?, are the priority value, distortion reduction and scan size associated with the ith bit, respectively. In this manner, those bits that contribute the most distortion reduction while requiring the least number of bits (smallest scan size) are assigned the highest priority values. Based on the priority value defined in the last equation, all the 640 bits in an 8 x 8 b lock can be sorted in terms of decreasing order of priority values. Grouping of bits: In order to obtain more efficient compression and conform to the progressive J P E G standard, a number of consecutive bits should be grouped to be encoded into a single scan. C o m b i n i n g successive approximation with spectral selection, grouping D C T bits can then be performed in two directions, going from most to least significant bits and in the zig-zag direction from the first A C coefficient to the highest frequency A C coefficient. W h e n two or Chapter 3 JPEG Image Compression 30 more bits are grouped, their distortions are added. U s i n g the rate o f the grouped bits, the priority value representing each spectral band is recalculated. E a c h group is then encoded into a scan, and all the scans are transmitted according to their priority values in several stages. F ina l ly , the overall P J P E G transmission algorithm can be stated as follows: • Calculate the priority values o f all the bits of all the D C T coefficients; • Obtain the best grouping pattern, i.e., the number of the most significant bits combined to form the first group for each coefficient; • C o m b i n e the bits or group of bits to form spectral bands; • Recalculate priority values as required for each scan; • Order and transmit all the scans according to their priority values in stages. U s i n g the above algorithm, a curve that shows the relationship between P S N R and the bit rate is given in [6], where the P S N R is defined as PSNR(dB) = \0\og (3.3) In (3.3), xpeak is the peak value of the output signal and Cy is the mean squared error. F r o m that curve, we can derive the relationship between P S N R and the accumulated number of scans, that are received in order. Table 3.1 shows the result of the P S N R of Chapter 3 JPEG Image Compression 31 reconstructed image and the related accumulated number of scans received in order. In the next chapters, we will use this result in our simulation. The image used here is the standard monochrome 512x512 Lena. Table 3.2 shows the size of each scan in this image file. Table 3.1 Relationship between PSNR and Accumulated Number of Scans for the 512 x 512 Lena Image Accumulated Number of PSNR1 ;ro^BitiRatejr:" .'-"t Scans (dB) ; (bPP) . • 1 24.6 0.049. 2 25.6 0.077 3 26.7 0.093 4 28.2 0.137 5 28.4 0.153 6 28.6 0.169 7 31.5 0.273 8 31.7 0.289 9 31.9 0.305 10 34.8 0.506 11 35.0 0.530 12 35.1 0.546 13 38.2 0.957 14 38.5 1.005 15 38.7 1.020 16 43.5 2.018 17 43.6 2.034 18 50.6 3.376 19 50.8 3.392 20 58.0 4.654 Table 3.2 Scan Size and Importance Class of the 512 x 512 Lena Image Scan Number Size (bytes) 'it'.- .Importance Class 1 1595 223695 2 756 24016 3 526 15099 4 1426 5236 5 536 3874 6 525 3867 7 3418 1566 8 497 966 9 524 940 10 6590 426 11 785 251 12 524 246 13 13485 110 14 1549 . 70 15 523 62 16 32677 28 17 522 16 18 43980 9 19 525 4 20 41368 3 Chapter 4 JPEG Image Transmission over CDPD Network 4.1 Overview Although C D P D has a relatively high R F channel data rate compared to other wireless data networks, it is still difficult to transmit image files efficiently because image files are normally large even after compression. Therefore, it is quite useful to find an efficient way to transmit J P E G image files over the C D P D network. Here we consider 2 schemes which are based on transmitting J P E G image progressively. The rate-distortion optimized progressive J P E G image coding algorithm is used. The importance class associated with a scan is used to control the retransmission over the connection. Scheme 1. Transmit scans successively according to decreasing importance, up to the client/server negotiated importance class, over one T C P connection. Scheme 2. Image File Transfer Protocol (IFTP): Uses U D P and places transport layer functionality into application. Scans are selectively retransmitted via an acknowledgment scheme, which depends on scan importance [5]. 4.2 Scheme 1 - Sending Scans According to Its Importance Class with TCP In Scheme 1, the P J E G images are sent and received over a T C P connection. The quality of the reconstructed image can be negotiated. If a client requires an image with certain quality, 32 Chapter 4 JPEG Image Transmission over CDPD Network 33 he sends out a request with P S N R corresponding to the required quality as a parameter. W h e n the image server receives the request, it wi l l transmit a sequence of scans as a response, in which the number of scans corresponds to the P S N R that is required. Since T C P provides a reliable connection between the client and the server, every scan arrives at the client's application layer in order. Therefore, the image can be reconstructed progressively as more scans arrive. W h e n all the scans are received, the image reconstruction is finished. T h e quality of the image is what the client requires. T C P . guarantees that the image file can reach the client, no matter what the l ink quality is and how long it wi l l take to complete the.session. After the transmission session invoked, application processes cannot change anything unless they stop the T C P session and start a new one with new parameters. U s i n g this scheme, the . image transmission delay is determined by the image reconstruction quality ( P S N R ) required by the client. F o r example, the transmission delay of a large image file with a low quality requirement may be the same as that of a small image file with a high quality requirement. Thi s is because all the scans of the small image file should be transmitted, while only some high priority scans of the large image file need to be transmitted for a lower quality image. One of the advantages of this scheme is that the required image quality is guaranteed. Moreover , standard T C P is used and there is no need to modify the existing transport protocol . However , the image transmission delay time may be longer in a wireless data network than in a wireline counterpart. In the wireless network, the channel is not as reliable as in the wired network. H i g h packet loss rate occurs all the time in wireless channels. T h e principle problem here is the congestion control algorithm used in T C P . M o s t T C P implementations have been Chapter 4 JPEG Image Transmission over CDPD Network 34 carefully optimized based on assumptions that are true for wireline networks but which fail for wireless networks. A m o n g these assumptions, the one that has the most significant impact to the performance of T C P in wireless networks is that T C P assumes that timeouts are caused by congestion, not by packet loss. Consequently, when a T C P timer goes off, T C P slows down and sends less vigorously, using an algorithm called "slow start". T h e idea behind this approach is to reduce the network traffic and thus alleviate the congestion. Unfortunately, wireless transmission links are highly unreliable. T h e y lose packets all the time. T h e proper approach to dealing with lost packets is to send them again, and as quickly as possible. S lowing down just make things worse, and the throughput drops a lot. W h e n a packet is lost on a wired network, the sender should slow down because the packet loss is due to congestion. W h e n a packet is lost on a wireless network, the sender should try harder. However , i f the sender does not know what the network is, it is difficult to make the correct decision. T h i s is the case with the normal T C P . There are several methods to solve the problems invoked by using normal T C P in the wireless networks. One of them, indirect T C P (I-TCP), is to break the T C P connection into two separate connections [8, 17]. Thi s is based on that the path from sender to receiver is almost all wired, except the end section of the path, which is f rom base station to mobile host. Therefore, the first connection in I - T C P goes from the sender to the base station. T h e second one goes f rom the base station to the receiver. T h i s solves the problem of distinguishing packet losses due to congestion or corruption, but the disadvantage is that it violates the semantics o f T C P . I - T C P becomes a protocol that does not provide end-to-end connections. Chapter 4 JPEG Image Transmission over CDPD Network 35 Another solution works by making some modifications to the network layer in the base station [18]. One of the changes is the addition of a snooping agent that observes and caches TCP segments going out to the mobile host, and acknowledgements coming back from it. When the snooping agent sees a TCP segment going out to the mobile host but does not see an acknowledgement coming back before its (relatively short) timer goes off, it just retransmits that segment, without telling the sender about it. This solution does not violate the semantics of TCP. However, if the wireless link is very lossy, the sender may time out waiting for an acknowledgement and invokes its congestion control algorithm. Moreover, the network layer in the base station is changed. Back to our image transmission over CDPD network problem, the image file is usually large and the CDPD airlink is both lossy and of low date rate. The congestion and packet loss may happen at the same time. The performance of normal TCP will be degraded almost for sure, especially under the condition of high block error rate on the airlink. The performance of Scheme 1 will be studied by comparison with Scheme 2. 4.3 Scheme 2 - Image File Transfer Protocol (IFTP) In the application layer, the IFTP will run on top of UDP. Because UDP is a connectionless transfer protocol and there is no error and flow control in UDP, the packets are just added a UDP header and sent out to IP. The IFTP makes use of UDP, but keeps the error control in the application. The proposed IFTP consists of two parts. One part resides in the fixed image transmission server and is called Server IFTP. The other part resides in the mobile host and is called Client IFTP. We will discuss these two parts separately. Chapter 4 JPEG Image Transmission over CDPD Network 36 4.3.1 Server IFTP W h e n an I F T P server receives an image transfer request, it wi l l send the image scan by scan over the C D P D network using U D P . E a c h scan transmitted wi l l be assigned a priority and a sequence number. W h e n the client E F T P receives a scan, it wil l check its sequence number and use it to reconstruct the image i f the scan has the expected sequence number. If a scan is miss ing during the transmission, the client I F T P wi l l check this scan with the scan point test, and make a decision on whether it should be retransmitted or not. T h e scan point test is based on the scan priority and the channel conditions. If this scan passed the scan point test, a retransmission request wi l l be sent to the server. After the server receives this request, it wi l l retransmit the requested scan. Figure 4.1 shows the Server I F T P system. J P E G I m a g e I F T P S e r v e r Figure 4.1 Server IFTP System In an E F T P image server, all the available image files are pre-compressed by P J P E G and stored. T h e Server E F T P system wi l l first open an U D P socket and wait for an image transfer request from ah E F T P client. W h e n an image transfer request is arrived, the Server E F T P reads the requested image file into its buffer. T h e n the frame header of the P J P E G image file is separated J P E G I m a g e R e a d e r S c a n T r a n s -mitter 1 -C l i e n t R e q u e s t A n a l y s i s U D P S o c k e t Chapter 4 JPEG Image Transmission over CDPD Network 37 to form the first scan. T h i s scan is very important to the P J P E G decoder because the control data for the whole image is in this frame header. T h e client must get this frame header to do the decoding. E v e n i f the client decoder has received all the other scans, it cannot decode them without the frame header. If the first scan that contains the frame header data is lost during the transmission, the client I F T P wil l have to send a retransmission request for this scan to the server. T h i s wi l l occur when the retransmission timer for this scan goes off, and wi l l continue until the frame header arrives. T h e other image data scans are prioritized by the ratio of the scan importance factor to the scan size. F o r the testing L e n a image, the scan importance factor and the scan size are listed in Table 3.2. Here we use the fol lowing equation to calculate the normalized scan priority: lOlog-P = ^ (4.1) where P is the normalized scan priority, / is the, scan importance factor, s is the scan size in bytes, P i is the normalized scan priority for Scan 1. D i v i d i n g the scan importance factor by the scan size, the average information a byte carries in a scan can be obtained. T h e reason of taking the logarithm of the scan importance factor over the scan size is that the dynamic range of the scan importance is-too large. T h e result of the logarithm wil l be mult ipl ied by 10 and div ided by the normal ized scan priority of Scan 1 so that Scan 1 is always of the highest priority, and the normal ized scan priority ranges from 10 to 1. Table 4.1 shows the scan importance factor, scan size and the normalized scan priority. Chapter 4 JPEG Image Transmission over CDPD Network 38 Table 4.1 Scan Priority for Lena Image i;i;>AfScanlNumber Scan Importance ' 'Scan Size » Scan Priority 1 223695 1595 10 2 24016 756 '7 3 15099 526 7 4 5236 1426 3 5 3874 536 5 6 3867 525 5 7 1566 3418 1 8 966 497 2 9 940 524 2 10 426 6590 1 11 251 785 1 12 246 524 1 13 110 13485 1 14 70 1549 1 15 62 523 1 16 28 32677 1 17 16 522 1 18 9 43980 1 19 4- 525 1 20 3 41368 1 . As shown in Table 4.1, the scan importance factor and the scan priority decrease as the scan number increases. For the last 50% of the scans, the normalized scan priorities are all 1. The advantage of the proposed PJPEG coding method is that the more important scans are always sent first, the client always receives the best image quality for the number of bytes it has received. Normally, when the receiver decodes 50% of all the scans, the decoded image contains more than 90% of the important image information. Therefore, if the last 50% of the scans are missing, it is often not necessary to retransmit them when the channel bit error rate is high or the network traffic load is high. The Server IFTP also time stamps each scan sent to the client. When the client receives a scan, it compares the receiving time with the sending time found in this scan. The difference is the end-to-end delay for the server to send this scan to the client over the CDPD network. If the CDPD network is not too busy and the block error rate (BLER) of the airlink is not high, the delay is not long. On the contrary, if the network traffic is high or the airlink BLER is high, the Chapter 4 JPEG Image Transmission over CDPD Network 39 delay is large. Thi s is also used by the Client E F T P to determine whether a lost scan should be retransmitted or not. T h e detailed algorithm wi l l be discussed in the next sub-section. 4.3.2 Client IFTP T h e Cl ient E F T P resides in the mobile host, i.e., an M E S in a C D P D terminology. A n image user uses the Cl ient E F T P to issue an image file transfer request to the image file server. W h e n the first scan of the image arrives, it wi l l be prepared to receive all the scans in the image. A t the same time, the Cl ient E F T P starts up a retransmission timer. W h e n the Cl ient E F T P receives scans f rom the server, it wi l l verify the number of scans received so far as wel l as check whether the previous scan has been received. If a previous scan is missing, the scan point test algorithm wi l l be used to determine whether the lost scan should be retransmitted. If the missed scan passes the scan point test, a retransmission request for the missed scan is sent to the server, and a retransmission timeout timer is set started. If the missed scan does not pass the scan point test, then either it is not so important to reconstruction of the image or the channel condition is very bad. T h i s missed scan wil l be discarded. Figure 4.2 shows the Cl ient E F T P system. R e c o n -s t r u c t e d I m a g e S c a n R e t r a n s m i s s i o n A l g o r i t h m I F T P C l i e n t Figure 4.2 Client IFTP System Chapter 4 JPEG Image Transmission over CDPD Network 40, If a missing scan is not received by the Client EFTP when the retransmission timeout timer goes off, a retransmission request for this scan will be re-issued to the server provided that the missing scan can still pass the scan point test under the current network traffic and airlink .BLER conditions. The value of the timeout interval is therefore a very important parameter. If the Client EFTP timeouts too soon, it may cause many unnecessary retransmissions, making the network even busier. This is especially true in the CDPD network because the airlink in the CDPD is a relatively low data rate channel. On the other hand, if the Client EFTP times out too late, it will take the client a long time to discover the retransmitted scan is missing again. The total image transmission delay will be large in this case. To solve this problem, a common way to estimate the timeout interval is to measure the end-to-end delay for a packet travelling from server to client. The most popular algorithm used to realize the above method is called Karn's algorithm [9]. Karn's algorithm is currently being used in some TCP implementations. It uses the round trip delay for estimating the timeout interval. The TCP calculates the round trip delay by subtracting the packet sending time from the packet acknowledgement time. The round trip delay time will then be used to estimate the timeout interval using timeout interval = y • (round trip delay time) (4.2) where the value of y is set to 2 typically. While in the proposed EFTP, the control is in the client side, not in the server side. There are no acknowledgements sent to the server from the client. The above method cannot be used in our case. A new method for the estimation of the timeout interval is to use the single trip delay time instead of round trip delay time. As mentioned in the last sub-section, every scan sent from the server will be stamped a sending time. When a scan Chapter 4 JPEG Image Transmission over CDPD Network 41 arrives, the Client IFTP will check this time stamp and find out the sending time of this scan. The single trip delay time is then obtained by subtracting the sending time from the current time. The estimation of the timeout interval is calculated from the equation below: timeout interval = y • (single trip delay time) (4.3) where the value of y is 4. Using single trip delay time to estimate the timeout interval gives rise to a serious problem, which is the time synchronization between the server and the client. If the server and the client are not synchronized in time, any difference in time will affect the result of the scan point test algorithm. For example, if the client clock is 10 seconds faster than that of the server, the end-to-end delay is always 10 seconds longer than the actual one. The error may make a would-be mistake to fail a scan in the scan point test, leading the scan not to be retransmitted. Therefore, the image quality will be decreased unnecessarily. To solve this problem, the proposed IFTP recommends that the Global Positioning System (GPS) transceiver may be used as a method to synchronize the timing between the server and the client. In this section, we have discussed the proposed IFTP that is used to transmit PJPEG images over CDPD network. IFTP tries to make use of the advantages of UDP, such as small packet overhead, no need for connection establishment and no state update. At the same time, some functions that are similar to TCP, such as retransmission request and timeout timer control, are added to EFTP. This makes Scheme 2 (EFTP) attractive to the applications like image transmission over wireless network. We will further study the EFTP and focus on the comparison between Schemes 1 and 2 in the following chapters. Chapter 5 Design of a Simulation Model The discussion in the last chapter indicates that Scheme 2 of using IFTP is the most favorable method to transmit P J P E G images over a C D P D network efficiently. The performance of the EFTP over a single airlink has been investigated and a positive result was obtained [5]. However, the performance of IFTP in the network under the condition of high traffic load and various airlink block error rates has not been investigated. If more than one IFTP client is in the network and these send image transfer requests to the server, what wi l l the performance of EFTP be like? If there are not only IFTP server and clients, but also standard T C P server and clients in the C D P D network at the same time, wi l l the performance of T C P be affected? To answer these questions, several investigation methods can be used. One is to implement IFTP server and client systems in the actual network. This is high cost and time consuming. Another efficient method is to make use of computer simulation. We wi l l follow this widely used method in the field of data communications. The performance evaluation of IFTP in a large network environment and the performance comparison between EFTP and T C P are based on an O P N E T simulation. We first overview the O P N E T simulation tool in the next section. 5.1 Overview of the OPNET Simulation Tool Optimized Network Engineering Tools (OPNET) , which is licensed by M i l 3 , Inc., is a comprehensive engineering system capable of simulating large communication networks with detailed protocol modeling and performance analysis. O P N E T features include: graphical 42 Chapter 5 Design of a Simulation Model 43 specification of models; a dynamic, discrete event driven simulation kernel; integrated data analysis tools; and hierarchical, object-based modeling tools. O P N E T allows the definition of a network topology, the nodes, and the links that go towards making up a network. The processes that may happen in a particular node can be user defined, as can the properties of the transmission links. A simulation can then be executed, and the results analyzed for any network element in the simulated network. O P N E T has three main types of tools - the Model Development tool, the Simulation Execution tool and the Result Analysis tool. These three types of tools are used together to model, simulate and analyze a network. O P N E T defines a model using a hierarchical structure - at the top there is the network domain, which is constructed from the node domain and link domain. While the node domain in turn is made from the process domain. The O P N E T model structure is shown in Figure 5 .1. N e t w o r k D o m a i n P r o c e s s D o m a i n Figure 5.1 OPNET Model Structure The Network Domain contains one top level network. This top level network may consist of one or more subnets, and anyone of those subnets there may consists of any number of further subnets. In this way, O P N E T can easily represent the hierarchical structure of a network. Chapter 5 Design of a Simulation Model 44 In the Node Domain the processes that happen inside a network node - such as a signal being generated, segmented, having a header added, and finally routed - are defined using process modules. Different process modules are combined to form a node model. The Process Domain allows the designer to create the processes required for use in the process models. These can consist of processes such as reading in a data stream, counting it and then segmenting it and forwarding it to the next process. These processes are defined using state transition diagrams along with some additional textual specifications using Proto-C. Proto-C is a variation of the C programming language specialized for protocols and distributed algorithms. Both standard and Proto-C code together form a finite state machine in the process model. OPNET is a discrete event simulation tool. Simulations can be automatically generated based on the model created in the model development tool. During a simulation run, probes can be used to monitor the points of interest in the network model. The OPNET Analysis Tool provides a graphical environment that allows users to view and manipulate data collected during simulation runs. A full range of statistical analysis tools is available in the Analysis Tool. Additional filter tools allow users to manipulate and extract useful data from the simulation results. OPNET also comes with built-in model libraries for some common protocols including the transport protocols UDP and TCP which we use. It enables the concentration of the effort to be directed towards modeling of the user modifications or enhancements. Chapter 5 Design of a Simulation Model 45 At the time of model development, there was no publicly available OPNET model of the CDPD airlink protocol stack. Therefore, this was the main element of the OPNET model which we needed to develop. We begin describing our modeling work of the CDPD airlink. 5.2 CDPD Airlink Model Design Within the context of the CDPD system architecture, the airlink protocol is primarily concerned with communication at the physical and medium access control (MAC) layers of the protocol stack between an MES and an MDBS. The complete airlink protocol additionally involves MDLP and SNDCP layers. In the airlink protocol stack, application data ready for transmission undergoes several transformations before appearing as bits on the physical transmission channels. The functions of each layer in CDPD airlink can be modeled with one or more process modules. The general function of the airlink protocol can be simulated by combining these modules together with packet streams. The data transformation and control can be completed when the application data goes through these modules. In this section, the OPNET model of the airlink protocol will be described from bottom to top, i.e., from the physical layer to the SNDCP layer. 5.2.1 Physical Layer Model The primary function of the physical layer is to transmit a sequence of bits as a modulated waveform, receive modulated data, demodulate it, and generate a sequence of received bits. The CDPD physical layer employs Gaussian Minimum Shift Keying (GMSK) waveform modulation, with a raw data transmission rate of 19.2Kbps. Furthermore, the communication between an MES and an MDBS is conducted over a pair of RE channels; each of Chapter 5 Design of a Simulation Model 46 which Occupies a 30 kHz bandwidth AMPS channel. Transmission from the MDBS to the MES is maintained on the "forward channel", whereas the opposite link runs on the "reverse channel". In our study, the modulation technique is not important to the image transmission time; hence, the physical layer is not explicitly implemented. However, the effect of the wireless channel must be considered due to its impact on the image transmission time. Since the wireless channel is not reliable and bit errors will occur during transmission, a forward error-correction (FEC) code is normally employed to increase the transmission reliability. In CDPD, the Reed-Solomon (RS) code is used. Both channels divide the transmitted bit stream into RS coded blocks. The forward channel blocks include 378 data encoded bits which are interleaved with 42 additional bits containing forward synchronization word, decode-status and busy/idle flags to make up 420-bit block. The reverse channel bit stream similarly uses 378 bits which are interleaved with continuity indicators to form 385-bit blocks. The channel quality is measured with BLER in CDPD. BLER is defined as the ratio of the number of uncorrectable blocks compared to the total number of blocks received. Therefore, the higher is the BLER, the lower the channel quality is, and the longer the image file transmission time will be. BLER is the parameter that we use to report our results. However, in the OPNET point-to-point link model, the channel quality is measured by the bit error rate (BER), which is defined as the ratio of the number of incorrect bits to the total number of bits received. To make use of the link model in OPNET, it is necessary to convert a BLER into a fictitious BER in the OPNET model. For simplicity, we just consider the forward channel since this is the direction in which the application data such as an image file will be delivered. In the forward link, 1 block contains 420 bits. The BLER then can be calculated from Chapter 5 Design of a Simulation Model BLER = 1 - (1 - BER) 47 (5.1) where BER is the bit error rate in this block. From the above equation, we can obtain the fictitious BER, which is i BER = 1- (1- BLER)420 (5.2) From this equation, the fictitious BER used in the OPNET model can be calculated if the BLER in CDPD is known. Table 5.1 shows some of the results. We use the same BLER for the reverse channel as for the forward. Table 5.1 BLER and Corresponding Fictitious BER BLER BER,, . . 0.01 0.000023929 0.02 0.000048101 0.03 0.000072519 0.04 . 0.000097191 0.05 0.00012212 0.06 0.00014731 0.07 0.00017277 0.08 0.00019851 0.09 0.00022452 0.10 0.00025083 With these fictitious BER values, the physical layer can be modeled with a duplex point-to-point data link in OPNET. In the attribute list of this duplex point-to-point link, the parameter BER is set to the fictitious BER corresponding to the BLER in the actual CDPD airlink. The date transmission rate of the duplex point-to-point link is set to 19.2 Kbps. Chapter 5 Design of a Simulation Model 48 5.2.2 MAC Layer Model From the point of view of the OSI model, the data link layer protocol is divided into two sublayers: the lower sublayer called the media access control (MAG) layer; and the upper sublayer called the mobile data link protocol (MDLP). The main function of the MAC layer is to convey information between the logical link layers of the MDBS and MES across the airlink interface. The frames from the link layer are further block encoded to contain forward error-correction codes. Additional frame synchronization information is added and transmitted on the forward and reverse channel streams. The forward and reverse channel streams differ in their operational characteristics as follows: • The forward channel is a contentionless broadcast channel carrying continuous information from the MDBS to the MESs. • The reverse channel is a shared channel that can be used by all the MESs within the range of the cell boundary covered by the forward channel stream. Multiple MESs have to compete for using the reverse channel and transmit data in bursts when a channel is acquired. If more than one MES transmits simultaneously, resulting collisions will generate blocks with errors. Some of the block errors due to collision or noise in the radio medium can be recovered directly at the MAC layer by the Reed-Solomon FEC code. The other uncorrectable block errors will reflect as frame errors in the link layer and will have to be recovered by retransmissions at the link layer. Chapter 5 Design of a Simulation Model 49 Since we mainly consider the situation that an image file is transmitted from a fixed image file server to the mobile client, the forward channel has much more traffic than the reverse channel during the transmission session. Thus, in order to simplify the MAC layer modeling, the DSMA/CD mechanism in MAC layer of MES is not modeled. In the model, a single MES in an MDBS cell is assumed. In our application, the reverse channel traffic consists only of packetized control data. We assume each such packet is contained in a single burst. The data transformation function of the MAC layer is implemented in the OPNET model. The MAC layer receives information for transmission from the link layer as frames and forwards them to the physical layer in sequence of bits. The transformation is carried out in reverse when receiving data from the physical layer. The different steps of the transformation from frames to bits are as follows: • Frames to Bit Stream. The initial task of the MAC layer is to convert the sequence of frames it receives from the link layer to a bit-stream in preparation for breaking the bit-stream into blocks. The MAC will be required to use interframe fills when there are no frames to transmit in the forward channel or to fill the last block in a reverse channel burst. • Bit Stream to Blocks. The basic unit of transmission used by the MAC layer is a fixed-length error control block that is comprised of 282 bits (47 6-bit symbols) of data extracted from the bit-stream created from the frames and 96 bits (16 6-bit symbols) of Reed-Solomon FEC code. The 282-bit data portion includes an 8-bit color code, hence a block consists 274 bits of the actual data. The 282-bit data portion and the 96-bit parity check portion make up a nominal block length of 378 bits (or 63 Chapter 5 Design of a Simulation Model • 50 6-bit symbols). A 42-bit (7-symbol) control flag will be added to each RS code block to form a 420-bit MAC block in the forward channel. The control flag includes channel status flag and decode status flag. The data transformation model of the forward link MAC layer is fully constructed in our model. It is shown is Figure 5.2. Figure 5.2 MAC Layer Model in MDBS The init state.is to initialize all the variables, statistics, memory allocations and so on. When a packet from the upper link layer arrives, the state machine will go into segmentation (seg) state, in which the packet will be segmented into 274-bit data blocks. These data blocks will be inserted to the MAC data format (iftpjnacjmi) to form the 420-bit MAC data blocks. When an idle status indication comes from the transmitter, these data blocks will be sent out to the forward channel in the send state. In addition, if no data comes from the link layer, the send state will send out interframe fills to maintain a continuous bit-stream in the forward channel. Chapter 5 Design of a Simulation Model 51 When packets from the lower physical layer arrive, they will be reassembled to form link layer frames in the reassembly (rsm) state. The reset state is used to flush all the incomplete frames in the segmentation and reassembly buffers when the link is released by link layer due to a failure channel condition. It will reset the finite state machine and get ready for a new session. The MAC layer model in the MES is similar to that in the MDBS, except that there are no interframe fills transmitted if there are no data transmitted on the reverse channel. This is to simply simulate the transmission of a burst on the reverse channel. 5.2.3 MDLP Layer Model The MDLP layer is responsible for establishing the data link between the MES and the MD-IS. The main service the MDLP layer provides to higher layers is its error detection and recovery capabilities, thereby attempting to alleviate the error recovery and consequent retransmissions that the higher layers may generate. In MDLP, two modes of operation are available across the airlink: the unacknowledged mode and the acknowledged mode. In unacknowledged operation mode, the link layer frames are sent out in unnumbered information (Ul) format, and there is no error recovery mechanism or flow control defined. Typically, only some control messages and broadcast information are transferred by unacknowledged mode. User data is transferred by acknowledged operation mode in numbered information (I) frames. These acknowledged frames are sent only to specific end-points or temporary equipment identifiers (TEIs). This leads to a reliable, sequenced, point-to-point data link connection. In MDLP, the implementation of the logical link control services between the MD-IS and the MES is achieved by using a sliding window protocol with selective repeat as its retransmission control. The TEI is used by the data link layer to address an individual subscriber unit or MES. It is Chapter 5 Design of a Simulation Model 52 assigned to an M E S by an MD-IS data link layer protocol entity at the beginning of connection establishment. If a connection is broken due to a bad airlink condition, the current T E I wi l l be removed and a new T E I wi l l be assigned when a new connection is established. The sliding window protocol in the data link layer employs selective repeat as its A R Q mechanism. The receiving window of the selective repeat A R Q has the ability to request frames to be retransmitted out of their original sequence, and to retain frames for later re-ordering. In selective repeat A R Q , both acknowledgements ( A C K ) and negative acknowledgements ( N A K ) are used. This is shown in Figure 5.3. The window size is 5 and it is ready for receiving frames 3 to 7. If frames 3, 4, 6 and 7 arrive, whereas frame 5 is missing, the receiving window wi l l accept frames 3 and 4 in order, and also accept frames 6 and 7 for later re-ordering. A N A K for frame 5 wi l l be sent out at the same time. When frame 5 arrives, the receiving window wi l l send an A C K for frame 7 which acknowledges the whole receiving window. A n A C K or N A K is normally piggybacked on an outgoing data frame for a better use of the available channel bandwidth. The selective repeat A R Q , compared with other sliding window protocols, is more efficient in high error rate channels. NAK for 5 0 1 Figure 5.3 Receiving Window of Selective Repeat ARQ In the O P N E T library, there is a sliding window protocol model which is named as SWP. Although selective repeat is used in this SWP model, it is somewhat too simple to use directly as the M D L P model in C D P D . This is because a parameter called maximum number of frame Chapter 5 Design of a Simulation Model 53 retransmissions is absent in the SWP model . In the M D L P , this m a x i m u m number of frame retransmissions is used to cause the release and reset of a logical data l ink between the M E S and the M D - I S . A d d i n g this functionality is the major modification to the SWP model . T h e modif ied SWP as the M D L P model is shown in Figure 5.4.' T h e init state initialized all the variables. In the idle state, the process waits for an event (interrupt) to occur. If an event occurs, the process wi l l transition to one of the five states according to the transition conditions. T h e five states and transition conditions are as follows. Figure 5.4 MDLP Model 1. W h e n a packet arrives from the upper layer ( S N D C P ) , the process wi l l transition to the state xm.it, in which the packet wi l l be converted to a M D L P frame and sent out to the lower M A C layer. If the sending window is full , the packet wi l l be inserted to a queue to wait for a position in the sending window. Chapter 5 Design of a Simulation Model 54 2. When a packet arrives from the lower layer ( M A C ) , the process wi l l transition to the state rev. If the packet sequence number falls within the receiving window, it is accepted; otherwise, it wi l l be discarded. 3. If a timer associated with a sent frame times out, it means no A C K s for this frame arrives in time. The process wil l transition to the resend state, send the frame again, and restart the timer. 4. If the network idle timer times out, it means that no packets from the upper S N D C P layer are being sent. The process wi l l transition to the send_ack state, and an explicit A C K for a received frame wi l l be sent out to indicated the successful reception of this frame. 5. When the number of retransmissions for a frame exceeds the parameter of Max imum Number of Retransmissions, the logical data link is disconnected. The process wi l l transition to the reset state, and wi l l reset all the state variables. The queue for the incoming packets from S N D C P and the sending window buffer are also flushed. Indications for the link release are sent to the S N D C P layer and the M A C layer at the same time. The process wi l l wait in the reset state until an indication from M A C layer comes, indicating that the M A C layer is ready for a new link. Then the process wi l l go back to the idle state to start a new link session with a new T E L A t the same time, an indication of the new link is sent to the S N D C P layer. Chapter 5 Design of a Simulation Model 55 The MDLP models in the MES and the MDBS are identical. They can communicate in a full duplex link to maintain a reliable logical data link connection between the MES and the MDBS. 5.2.4 SNDCP Layer Model The Subnetwork Dependent Convergence Protocol (SNDCP) layer is unique to the CDPD airlink protocol stack. It performs the function of packet transformation into segments which are handed over to the MDLP layer. The packet is segmented based on the maximum frame size that can be handled by the MDLP layer, and an SNDCP header is added to each segment. If the underlying data link connection at the MDLP layer fails, the transmitter discards any unsent segments of a partially transmitted packet and the receiver discards any partially reassembled packet resulting in packet loss at the airlink. Other functions of SNDCP are data compression and encryption. Data encryption is not related to our study of image transmission, hence it is not concerned in the SNDCP model. Since the JPEG image file is in the format of compression, it is not necessary to do compression again. The OPNET model of the SNDCP is divided onto two modules. One is for the data segmentation; the other is for the data reassembly. However, in the MES and the MDBS, the SNDCP models are identical. The model of the segmentation module is shown in Figure 5.5, and the model of the, reassembly module is shown in Figure 5.6. Chapter 5 Design of a Simulation Model 56 Figure 5.5 SNDCP Segmentation Module The SNDCP segmentation process starts from the init state, in which the state variables are initialized. In the idle state, the process waits for an event to occur. If an event occurs, the process will transition to one of the three states according to the transition conditions. The three states and transition conditions are as follows. When packets arrive from upper IP layer ("ARRIVAL"), the process will transition to the segment state, and the packets are fragmented into segments and put into a segment queue to wait for transmission. If this segment queue is not empty when a packet arrives from EP, the packet is first put into a packet queue. When the MDLP layer is ready, the process will go into the send state, and a segment will be sent out to the MDLP layer. This frame is taken out from the segment queue. If the segment queue is empty, a packet.from the head of the packet queue will be fragmented and put into the segment queue first. If the link is released by the MDLP layer, the process will transition to the reset state. Chapter 5 Design of a Simulation Model 57 All the segments, which are not sent out in the segment queue, will be flushed; whereas the packets in the packet queue are all reserved for use in the new link session. 11 Figure 5.6 S N D C P Reassembly Module The SNDCP reassembly process is similar to the segmentation process, except that there is only one queue in it. The segments arrived from MDLP layer will be put into this reassembly queue first. When all the segments that consist of a packet are available, the packet will- be delivered to the up IP layer. If a "DLJDISC" interrupt occurs, the reassembly queue will flush all its partially reassembled packets. 5.2.4 Node Model of the Airlink The node model of the CDPD airlink is shown in Figure 5.7. Chapter 5 Design of a Simulation Model 58 • 'appli^atioli • transport • sxidc5_rsm • sndcd. .seg Figure 5.7 Node Model of the Air l ink in the M E S In the application layer, the model of the IFTP or a simple FTP is implemented. The transport layer will be TCP if FTP is used in the application layer, or UDP if IFTP is used in the application layer. This is the model in the MES. In MDBS, no application and transport layers are needed. The three modules, ip_encap, ip and arp consist of a full IP model. Modules sndcp_seg and sndcpjrsm are the models of SNDCP segmentation and reassembly, respectively. The process model of the MDLP resides in the MDLP module. The process model of the MAC layer resides in the mac module. Note that the MAC process model in the MES is different from the one in the MDBS. Also note that the MDBS model is not implemented explicitly because MDBS functions only as a relay between the MES and the MD-IS. Chapter 5 Design of a Simulation Model 59 5.3 IFTP Model The OPNET model of EFTP consists of two parts: the Client and the Server EFTP models. 5.3.1 Client IFTP model The process starts from the init state, in which the state variables are initialized. In the . sndjreq state, an image file transfer request will be sent to the image file server (Server EFTP). The process enters the wait state, and wait for arrival of the first scan. If the first scan does not arrive before its timer expires, the Client EFTP will transition to the rtx_req state and retransmit the image file transfer request. Only after the first scan is received, the Client EFTP will start to accept other scans. When a scan is received, the process will enter the proc state. If the scan arrives in order, it will simply be added to the image file and contributes to the image reconstruction. If the scan arrives out of order, it is also passed to the PJPEG decoder. At the same time, a Scan Point Test The state diagram of the Client EFTP process model is shown in Figure 5.8. Figure 5.8 Process Model of Client IFTP Chapter 5 Design of a Simulation Model 60 for the missing scan will be calculated to determine if a retransmission request should be sent or not. If a retransmission request is sent, a timer associated with this request is started. If such a timer times out, the process enters the rtxjreq state to do the Scan Point Test again. In our case, the Scan Point Test is not implemented. Instead, an assumption that all the scans can pass the Scan Point Test is made so that every scan must be received. This is to obtain a fair condition for comparison between TCP and IFTP. The source code of the Client IFTP model is listed in Appendix A. 5.3.2 Server IFTP model The state diagram of the Server IFTP process model is shown in Figure 5.9. (FILE_BZQ) (default) / I (START_UP) (RESEHD_REQ)N * Figure 5.9 Process Model of Server IFTP In the init state, the process will initialized the state variables and read in the information of the image file. In the open state, the service ports are opened. In.the wait state, the process Chapter 5 Design of a Simulation Model 61 waits for the image transfer requests or the retransmission requests. If an image transfer request arrives, the process will transition to the send state and sends out the image scan by scan. If a retransmission request arrives, the process will transition to the resend state and re-sends the corresponding scan. The source code of the Server EFTP model is listed in Appendix B. 5.4 CDPD Network Configuration Figure 5.10 CDPD Network Configuration Because of the high complexity of the actual network, it is impossible to build a CDPD network model very close to the actual one. Moreover, the simulation efficiency is decreased if a too complicated model is used. Therefore, a carefully chosen network configuration is required in order to obtain useful simulation data. Chapter 5 Design of a Simulation Model 62 The structure of the CDPD network model is shown in Figure 5.10. It consists of 5 subnetworks, denoted from subnetjO to subnet_4. Links between these subnetworks are duplex Tl links, each with a data rate of 1.544 Megabits per second (Mbps). In the image transmission simulation, all the clients are located in subnetjO^ and the image server is located in subnet_l. Each subnet consists of several nodes. Among these nodes, some are clients or, servers, some are peripheral nodes which represents Internet traffic generators, some are routers or gateways. The links between these nodes are also duplex T l . The topology of subnetjO is shown in Figure 5.11. Figure 5.11 Structure of SubnetjO In subnetjO, nodejD to node_2 are MESs. The image clients will be in these MESs and can be configured to use IFTP or normal TCP as the image transmission scheme. Node_3 is the Chapter 5 Design of a Simulation Model 63 MD-IS node. The MDBSs are only data relays between MESs and MD-ISs and are combined in the MD-IS models for simplicity. The 3 duplex links between node_0, node_l and node_2, and node_3 represent 3 airlinks, with each data rate set to 19.2 Kbps. Node_4 to node_7 are the Intermediate Systems (IS) or routers in subnetj). Node_8 is the gateway which provides connection to the other subnetworks. Node_9 to node_16 are peripheral nodes which generate traffic loaded to the network. Other subnets have similar structure and are shown in Figures 5.12 to 5.14. In subnet_], node_13 acts as the image server, in which IFTP or TCP can be used. I GUUY I -111 Figure 5.12 Structure of Subnet_l Chapter 5 Design of a Simulation Model 64 ll G W Y I Figure 5.13 Structure of Subnet_2 and Subnet_3 Figure 5.14 Structure of Subnet_4 Chapter 5 Design of a Simulation Model 65 A typical Intermediate System (IS) is shown in Figure 5.15. It consists o f a IP module which routes packets to the destination and several transceiver pairs. Since the structure of the network model is not too complicated, the internal fixed routing table is deployed here as the routing method. T h e description of the IS internal structure is also suitable to that of the gateway model , which has the additional ability to route packets between the subnets. B ip U _enc nun ap C ip_a 3 B rp_0 3 ^ B • ip 3 I I I I I I n _arp m _2 ip_a UB 3 3 B ip_a 3 L*B 1 rp_3 3 S 3 rx_0 tx_0 rx_2 .tx_2 tx_l r x _ l tx_3 rx_3 Figure 5.15 Typical Structure of the IS T h e peripheral nodes in the network are designed to generate arbitrary packet data which simulate the offered Internet traffic. T h e packets are generated with an exponential interarrival distribution. T h e mean interarrival time wi l l be set to different values at the beginning of simulation to obtain different Internet traffic load. T h e expected value of the packet size is set to 65536 bits (8192 bytes), close to the m a x i m u m transfer unit size of the IP datagram. A s shown in Figure 5.16, a typical peripheral node consists of an ideal packet generator (src), a packet processor (proc) and an IP module. T h e addresses of the packet destination net and node are generated randomly in the proc module. T h e outgoing packets with these addresses are passed to Chapter 5 Design of a Simulation Model , 6 6 the EP module and sent out. The incoming packets are destroyed after recording the statistics to save system resources. © src n proc 1 1 _encap 1 n - — - * Figure 5.16 Peripheral Node Model Chapter 6 Simulations and Results The purpose.of the simulations is to compare the image transmission Schemes 1 and 2 under the condition of various airlink block error rates and various offered network traffic loads. Image transmission time is the basis of the comparison. 6.1 Simulation of Scheme 1 Transmission with TCP The structure of the CDPD network used to simulate Scheme 1 is shown in Figure 5.13. The internal structures of these subnets are shown in Figures 5.14 through 5.18. There are 3 image file transfer clients located in subnetJJ, which are nodejD(MESO), node_l(MESl) and node_2(MES2). They are connected to the MD-IS with 3 airlinks denoted from airlinkj) to airlink_2, respectively. The image file transfer server is in node_13 of subnet_l. In Figure 5.15, the name of node_13 should be TCP_Server instead of IFTP_Server. Each client sends an image file transfer request to the server at the same time. The image file size is first chosen as 64,000 bytes. When the server receives one of the 3 requests, it will establish a separate TCP connection to each client, and the image file transmission is totally controlled by TCP. The mean size of the data packets that are generated by the peripheral nodes is set to 8192 bytes (65536 bits). They represent the offered network traffic load in the Internet, hence their mean size is set to the same as the maximum transfer unit size of TP datagram.. The interarrival time of these packets is exponentially distributed. The mean of the interarrival time is controlled by. the simulation runs in order to achieve different offered network traffic loads. The 67 Chapter 6 Simulations and Results 68 BLER of each airlink is also set at different simulation runs. Table 6.1 shows the summary of the parameters used in Scheme 1 simulation. Table 6.1 Summary of the Parameter Used in Scheme 1 Simulation * Layer Parameter Value Application Image Size 64000 bytes Size of Packets in Peripheral Nodes 8192 bytes Distribution of Interarrival Time Exponential Mean of Interarrival Time Variable T C P Max ACK Delay 0.5 sec Max Segment Size 8192 bytes Max Retransmission Timeout Value 240 sec Min Retransmission Timeout Value 0.5 sec MDLP Max Number of Retransmissions 3 Max ACK Delay 0.5 sec Max Delay before Frame Retransmission 3 sec Window Size 16 Physical, Airlink Data Rate 19.2 Kbps BLER Variable Physical, Wireline Data Rate T1 (1.544 Mbps) In order to reduce the random error in the simulation results and obtain a typical behavior of the simulated image transmission schemes, multiple simulation runs must be carried out for the same model, using different random number generator seeds. The results obtained from the separate simulations can be combined to estimate typical behavior of the scheme. The combination is done by sample averaging. Theoretically, the more simulation runs executed, the more closer the result to the typical behavior. However, the more simulation runs executed, the more the resources and longer the simulation time are needed. Here, the seeds ranged from 0 to 100 in a step size of 2 are used to achieve 50 separate simulation runs. The result of each simulation is recorded in an output scalar file to be accumulated. The final result can be obtained by averaging these values. A typical output scalar file is shown in Figure 6.1. Chapter 6 Simulations and Results 69 Panel # 0 ! Image F i l e Transmission Time Dl (MES1) 180 170 IGO 150 140 130 120 110 100 90 80 1 1 1 • 1 - - L - J L . i . . . _ i i i i ' T " i — r " - f " I I -i • y i . • i • p" . i h - - - M -i i i i i i i i 1 • 1 1 • 1 1 > 1 r i i - - j - . -j-. j - -, : • 1 • 1 . 1 I I i " r " -i i 1 1 1 ~~i " i " r ; i " .1 * 1 1 " • 1 _ _ _ I _ _ _ J _ - _ _ J . _ . _1___ 1 1 I I 1 1 1 1 • I I 1 .825 7.85 7.875 7.9 7.925 7.95 7.975 8 8.025 8.05 Other T r a f f i c T (xle+0S> Figure 6.1 A Typical Output Scalar File From Figure 6.1, we can take the sample mean of the x and y axis separately to obtain the average offered network traffic load and the image transmission time, respectively. Running the simulations under conditions of various offered traffic load and airlink BLER, the transmission time of the 64 Kilobytes (KB) image can be shown in Figure 6.2. The transmission time is defined in the following equation: transmission time - time that client sends out the request - time that client receives the whole image. As shown in Figures 6.2, the image transmission time increases as the offered network traffic load becomes heavy. Moreover, the image transmission time will be longer if the BLER is higher, as we expect. Under the same network condition, the image transmission performance of the three clients behaves in almost the same manner, especially in the lower BLER cases. Chapter 6 Simulations and Results 70 Figure 6.2 T C P : Image Transmission Time vs. Network Traffic Load for Various B L E R s 6.2 Simulation of Scheme 2 Transmission with IFTP In order to compare Schemes 1 and 2, the structure of the CDPD network used to simulate Scheme 2 is chosen as the same with the one of Scheme 1. Therefore, Figures 5.13 to -5.18 show the network configuration. There are 3 image file transfer clients located in subnetj), which are node_0(MES0), node_l(MESl) and node_2(MES2). They are connected to the MD-IS with 3 airlinks denoted from airlinkj) to airlink_2, respectively. The image file transfer server is in node_13 of subnet_l. Each client sends an image file transfer request to the server at the same time. The image file size is 64 Kilobytes too. In a file transfer session using TCP, it cannot be interrupted to Chapter 6 Simulations and Results 71 obtain a certain amount of bytes that is useful to the image decoding, since TCP session is a byte stream, and this byte stream cannot be broken during the transmission session. Hence, the image file transfer using IFTP is set to a mode for the full image transmission, i.e., every scan is assumed to be able to pass the Scan Point Test. If a scan is missing during transmission, it must be retransmitted until it is received by the client. This is used to do a fair comparison between the two schemes, in which the transmission time is compared under the condition of the same image quality. The parameters used in Scheme 2 simulation is shown in Table 6.2. The simulation results are shown in Figure 6.3. Table 6.2 Summary of the Parameter Used in Scheme 2 Simulation , Layer Parameter Value Application Image Size 64000 bytes Scan Size 2000 bytes Scan Point Test All Pass Size of Packets in Peripheral Nodes 8192 bytes Distribution of Interarrival Time ' Exponential Mean of Interarrival Time Variable UDP Datagram Size 2018 bytes MDLP Max Number of Retransmissions 3 Max ACK Delay 0.5 sec Mac Delay before Frame Retransmission 3 sec Window Size 16 Physical, Airlink Data Rate 19.2 Kbps BLER Variable Physical, Wireline Data Rate T1 (1.544 Mbps) Chapter 6 Simulations and Results 72 — e — B L E R = O M E S O • — € > - - B L E R = 0 M E S 1 — © . - - B L E R = 0 M E S 2 B L E R = 1 % M E S O X B L E R = 1 % M E S 1 • X B L E R = 1 % M E S 2 1 B L E R = 5 % M E S O B L E R = 5 % M E S 1 • 1 B L E R = 5 % M E S 2 0 1 2 3 4 5 6. 7 8 9 10 .11 Offered Network Traffic Load (bps) 10= Figure 6.3 IFTP: Image Transmission Time vs. Network Traffic Load for Various BLERs From Figure 6.3, we can conclude that the image file transfer time increases as the network traffic increases. The BLER is also an important factor that affects the transfer time. These are just the same as the one in Scheme 1, which uses TCP. However, unlike using TCP, the file transfer time for each client is not similar to others in the IFTP Scheme. One of the clients will take less time to complete the image transmission. This is because there is no flow control such as the sliding window scheme adopted in IFTP. One of the clients will take as much as the resources to make the transmission. Hence, others will suffer a worse network condition. As the network traffic load gets heavier, the impact from the first client is more significant to the others, and the difference of transmission time between the first and others is greater. Chapter 6 Simulations and Results 73 6.3 Comparison Between Scheme 1 (TCP) and Scheme 2 (IFTP) The comparisons of the image transmission time between using TCP and EFTP with respect to the offered network traffic load under different airlink BLERs are shown in Figures 6.4, 6.5 and 6.6 , respectively. Figure 6.4 Comparison Between TCP and IFTP: BLER = 0 Under the condition of low network traffic, the image file transfer time of each EFTP client is less than that of each TCP client. At the point that the offered network traffic load is around 7.5 Mbps, the transfer time difference between EFTP and TCP starts to become larger and larger as the offered network traffic load increases. This point is the transition point of the image transmission time, which indicates that the network begins to be congested. Chapter 6 Simulations and Results 74 Figure 6.5 Comparison Between TCP and IFTP: BLER = 1% 4 5 6 7 8 9 10 11 Offered Network Traffic Load (bps) 1 Q6 Figure 6.6 Comparison Between TCP and IFTP: BLER = 5% Chapter 6 Simulations and Results 75 As discussed in Chapter 5, TCP makes use of the sliding window algorithm as the scheme of flow control. The time out interval value of the retransmission timer is calculated based on the round trip delay time in the network. It cannot distinguish between congestion and corruption. In CDPD network, the delay is mainly due to the unreliable airlink. There are a lot of retransmissions and even packet losses in the MDLP layer between the two end points of the airlink. This makes the round trip delay very large in the TCP layer. As we know, if the packet loss is due to corruption, the packet should be immediately retransmitted. Instead of retransmitting packet immediately, TCP schedule the retransmissions according to the round trip delay. While in the case of EFTP, the packets (scans) are retransmitted immediately if the retransmission requests are received. Therefore, EFTP can make a faster image file transfer. Under the condition of network congestion, the round trip delay is degraded further by the congestion. The interval of TCP retransmission time out will become even larger, until it reaches the value of maximum retransmission delay. (The maximum retransmission delay is 240 seconds in the model, which is the default value for TCP in the OPNET model library.) Hence, the image file transfer time of TCP becomes much greater than EFTP after the transition point. Moreover, although one of the EFTP clients needs less image transfer time than the other two EFTP clients, the image file transfer time of these two EFTP clients is still less than that of the clients using TCP. In conclusion, EFTP outperforms TCP in the image file transfer applications. While because there is no flow control in EFTP, it is possible that the impact of EFTP on other TCP users may exist. The further discussion is in Section 6.5 Chapter 6 Simulations and Results 76 6.4 Simulation of Example Image File Transfers In this section, we discuss the simulation of image file transfers over CDPD with an actual image file. The image quality with respect to the transfer time of using TCP is compared with that of using IFTP. The image file used is the standard , gray-scale 512 x 512 Lena image, which is compressed by the proposed PJPEG algorithm. The relationship between the image quality and the accumulated number of scans received is shown in Table 3.1. In the simulation, when TCP is used, an image file that consists of certain number of scans that corresponding to the required image quality is sent; when EFTP is used, a number of scans that corresponding to the required image quality are sent scan by scan in sequence of descending scan priority. The network structure used in this simulation is the same as the one used in Sections 6.2 and 6.3. However, only one TCP or EFTP client (MESO) is enabled to send image transfer request. The other two MESs are assumed to be not in use. The traffic load in the network model is set to be around 2.6 Mbps. The simulation results are shown in Figure 6.7. As shown in Figure 6.7, when the image quality requirement is under 28 dB of PSNR, the image transmission time difference between EFTP and TCP is slight under various airlink BLERs. As the requirement for the image quality increases, the transmission time difference between these two schemes becomes larger. For the BLER of 0, the time saving of using EFTP-based scheme can be as much as 30 seconds; for the BLER of 1%, the time saving can be as much as 50 seconds; and for the BLER of 5%, the time saving can be as much as about 100 seconds. If the requested image quality is higher than 30 dB, the PSNR of the image file received by. EFTP can be 5 to 10 dB higher than that of TCP using the same transmission time. For Chapter 6 Simulations and Results 77 example, if the transmission time is 50 seconds and BLER is 1%, the PSNR of the Lena image received by the TCP client is 35 dB. While the PSNR of the image received by the EFTP client is 43.5 dB, which is 8.5 dB higher. — e — T C P B L E R = 0 — - © - — T C P B L E R = 1 % -—e— T C P B L E R = 5 % ' I F T P B L E R = 0 X I F T P B L E R = 1 % X I F T P B L E R = 5 % 150 200 250 300 Transmission Time (sec) 350 400 450 Figure 6.7 T C P and IFTP Comparison: PSNR vs. Transmission Time for the Lena Image Figure 6.8 shows the percentage of time saving, by using EFTP compared with using TCP, with respect to the PSNR of the received image file. At lower image quality of PSNR under 30 dB, the percentage of transmission time saved by using EFTP is about 10% to 30%. As the PSNR increases, the image file size becomes larger, and the percentage of transmission time saving can be as high as 50% to 80%. This is similar to the results shown in [5]. Chapter 6 Simulations and Results 78 5 £ o U . > CO 10 E i= 30 i i i i — e — A BLER= 0 BLER = 1 % BLER = 5 % - A ^ * -. i i i i i 40 PSNR (dB) Figure 6.8 Percentage of Transmission Time Saved by IFTP Compared to TCP Both Figures 6.7 and 6.8 indicate that the IFTP has a better performance compared with TCP in terms of the image transmission time. 6.5 Impact of IFTP on the Other TCP Users Since effective flow control is not implemented in the IFTP, the impact of the . retransmission packets generated by IFTP on the network traffic might be large. To investigate this impact, the simulation based on the same network structure as the one shown in Figure 5.10 was carried out. The new subnetwork model in subnetjO is shown in Figure 6.9. There are four image file clients located in subnetj). Three of them (ME0 to MES2) are standard TCP users, the other one (MES3) can be either a TCP or an IFTP user. In the case of four image clients all Chapter 6 Simulations and Results 79 using standard TCP, the image transmission time is approximately the same for each client. While in the other case, one EFTP client has a faster image file transfer than the other three TCP clients do. In order to maintain a continuous EFTP session, the EFTP client will send out another request for the same image file after it received a whole image. Figure 6.9 SubnetjO for Study of the IFTP Impact on the Network The simulation result is shown in Figure 6.10. The curves with mark."o" are the result in the case that all four MESs are TCP clients. The curves with mark "x" are the result in the case that one of the four MESs is EFTP user. The image transmission performance of both cases is almost the same in terms of the transmission time. There is slight effect at high traffic load, however, it is insignificant. We can conclude that the impact on the TCP users is not noticeable when the percentage of the EFTP users is lower than 25%. Chapter 6 Simulations and Results 80 Figure 6.10 Impact on TCP Clients, with or without IFTP, at BLER=5% Chapter 7 Conclusions and Further Study The goal of this thesis work was to do a performance evaluation of two schemes for PJPEG image transmission over a CDPD network. These two schemes, which make use of TCP and EFTP, respectively, are discussed and analyzed. An OPNET model of a CDPD network used for the simulation study of the image transmission performance was established. The image transmission scenarios of Schemes 1 and 2 under various network and airlink conditions were simulated and the results were compared. In both schemes, the rate-distortion optimized progressive mode JPEG algorithm was adopted as the compression method for the image data. Scheme 1 uses standard TCP directly. It does not need any modifications in the transport layer and needs only slight modifications in the existing application software. The only requirement is that the image must be in the PJPEG format. This scheme guarantees that the image can reach the client with a certain required quality. To decrease the transmission time, the image quality requested by the client should be reduced accordingly. When the network load becomes heavy, the image transmission time used by Scheme 1 increases sharply. This becomes worse if the block error rate of the airlink is high. This is in part due to the nature of standard TCP, which is related to its flow and congestion control algorithm. . Scheme 2 uses the EFTP. It makes use of UDP in the transport layer, and keeps the error and retransmission control in the application. The PJPEG image is sent scan by scan in a sequence according to the scan priorities. The results of a simulation with multiple simultaneous EFTP sessions show that the EFTP is functionally sound in a multi-link network. Packet 81 Chapter 7 Conclusions and Further Study 82 retransmission requests are controlled by the client according to a scan point test. If the scans arrived at the client can reconstruct the image with high enough quality, or the transmission is experiencing severe delays due to congestion or corruption, the client can choose not to request retransmission of the non-essential scans to save image transfer time by sacrificing the image quality. In our simulation, in order to compare Schemes 1 and 2 under the condition of the same image quality, the EFTP was configured to guarantee arrival of the whole image. As shown by the simulation, the EFTP outperforms TCP in terms of the image transmission time. For a lightly loaded network, the transmission time saving varies between 10% and 80%, depending on the image size and the airlink BLER. In a more heavily loaded network, the advantage of the EFTP in terms of transmission time becomes more significant. However, the simulation results also indicate that if several EFTP clients are sharing the same MD-IS, the client whose transmission started first will be unfairly favored among the group of simultaneous users. Furthermore, the impact of IFTP to the network can be heavy due to the lack of flow control. Although the retransmission packets generated by the EFTP might degrade the network traffic condition and cause other standard TCP users to experience a longer image transmission time, we have found this effect not to be noticeable provided that the percentage of the EFTP users is lower than 25%. A future version of the EFTP should implement flow control. Because it is.meant for PJPEG transmission, each packet can be decoded separately; thus it is not necessary to maintain the sequence ordering that TCP maintains. This would result in a protocol similar to TCP, but should however enjoy some advantage. A more important feature of the EFTP which our version Chapter 7 Conclusions and Further Study' 83 has and which an improved version would continue to have, is the ability to provide the client the option of sacrificing image quality in return for a faster transmission should he choose. O u r simulation model abstracted those features of C D P D which affect the E F T P / T C P comparison the most. Some C D P D features that were not modeled are channel hopping due to severe channel signal-to-noise ratio degradation or due to A M P S user preemption, and channel contention by multiple M E S s . Another possible area of further study lies in the performance comparison between I F T P and modif ied T C P that is optimized for wireless networks. In this work, the comparison is l imited to the standard T C P . Since some new T C P implementations are proposed to address the problem invoked by standard T C P in wireless networks, comparing these new T C P implementations with the E F T P could benefit further research on efficient image transmission over wireless data networks. / Glossary of Abbreviations ACK Acknowledgement AMPS Advanced Mobile Phone System ARDIS Advanced Radio Data Information Service ARQ Automatic Retransmission Request BER Bit Error Rate BLER Block Error Rate CDMA Code Division Multiple Access CDPD Cellular Digital Packet Data CLNP Connectionless Network Protocol CSMA/CD Carrier Sense Multiple Access with Collision Detection DCT Discrete Cosine Transform DSMA/CD Digital Sense Multiple Access with Collision Detection FDCT Forward Discrete Cosine Transform FEC Forward Error Correction FES Fixed End System FTP File Transfer Protocol GIF Graphics Interchange Format GMSK Gaussian Minimum Shift Keying GPS Global Positioning System GSM Global System for Mobile Communications FDCT Inverse Discrete Cosine Transform EFTP Image File Transfer Protocol IP Internet Protocol IS Intermediate System IS-95 Intermediate Specification 95 IS-136 Intermediate Specification 136 ISO International Standard Organization 84 Glossary of Abbreviations I-TCP Indirect TCP JPEG Joint Photographic Expert Group Kbps Kilobits per second LAN Local Area Network LZ77 Lempel-Ziv 77 Algorithm LZW Lempel-Ziv-Welch Algorithm MAC Medium Access Control Mbps Megabits per second MDBS Mobile Data Base Station MD-IS Mobile Data Intermediate System MDLP Mobile Data Link Protocol MES Mobile End System MSC Mobile Switching Center MTSO Mobile Telephone Switching Office NAK Negative Acknowledgement NPDU Network Protocol Data Unit. OPNET Optimized Network Engineering Tools OSI Open System Interconnection PCS Personal Communication System PJPEG Progressive JPEG PNG Portable Network Graphics PSNR Peak Signal to Noise Ratio RAM RAM Mobile Data RF Radio Frequency SNDCP Subnetwork Dependent Convergence Protocol TA'CS Total Access Communication System TCP Transmission Control Protocol TDMA Time Division Multiple Access UDP User Datagram Protocol WAN Wide Area Network WWW World Wide Web REFERENCES [1] CDPD Forum, Cellular Digital Packet Data System Specification, Release 1.1, January 1995. [2] Muthuthamby Sreetharan and Rajiv Kumar, Cellular Digital Packet Data, Artech House, Inc., 1996. [3] Christopher Cramer, Erol Gelenbe, and Pamir Gelenbe, "Image and video compression," IEEE Potentials, pp.29-33, February/March 1998. [4] Gregory K. Wallace, "The JPEG still image compression standard," IEEE Transactions on Consumer Electronics, Vol. 38, No. 1, pp. 18-34, February 1992. [5] Michael K. Wong, Transmission of JPEG Compressed Images over the Wireless CDPD Network, M.A.Sc. Thesis, Department of Electrical and Computer Engineering, University of British Columbia, April 1998. [6] Jaehan In, Shahram Shirani, and Faouzi Kossentini, "On RD optimized progressive image coding using JPEG," Proceedings of International Conference on Image Processing, 1998. [7] Khalid Sayood, Introduction to Data Compression, Morgan Kaufman Publishers, Inc., 1996. [8] Andrew S. Tenanbaum, Computer Networks, 3r ed., Prentice Hall, 1996. [9] Phil Karn and Craig Partridge, " Improving round-trip time estimates in reliable transport protocols," Proceedings of ACM SIGCOMM '87, pp. 2-7, August 1987. [10] Van Jacobson, "Congestion avoidance and control," Proceedings of ACM SIGCOMM '88, pp. 314-329, August 1988. [11] W. A. McGladdery and Robin Clifford, "Survey of current and emerging wireless data networks," IEEE Proceedings of CCECE/CCGEI '93, pp. 1000-1003, 1993. 86 References 87 [12] CCITT T.81, ISO/EEC 10918-1, Information Technology - Digital Compression and Coding of Continuous-Tone Still Images: Requirements and Guidelines, 1 s t ed., February 1994. [13] Yasushi Koyama and Susumu Yoshida, "Error control for still image transmission over a " fading channel," Proceedings of IEEE 45th Vehicular Technology Conference, Vol . 2, pp.609-613, 1995. [14] Masaki Yamashida, Takeshi Tanda, and Toshiaki Tanaka, "Image transmission control over fading channel using SR-ARQ based on DCT frequency and image frame structure," Proceedings of the 7th IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC '96, Vol . 3, pp.948-952, 1996. [15] Jorge A . Cobb and Prathima Agrawal, "Congestion or corruption? A strategy for efficient wireless TCP sessions," Proceedings of IEEE Symposium in Computers and Communications ISCC '95, 1995. [16] Hari Balakrishnan, Venkata N . Padmanabhan, Srinivasan Seshan , and Randy H. Katz, " A comparison of mechanisms for improving TCP performance over wireless links," IEEE/ACM Transactions on Networking, December 1997. [17] Ajay Bakre and B. R. Badrinath, "I-TCP: Indirect TCP for mobile hosts," Proceedings of 15th International Conference on Distributed Computing Systems (ICDCS), May 1995. [18] Hari Balakrishnan, Srinivasan Seshan, and Randy H. Kartz, "Improving reliable transport and handoff performance in cellular wireless networks," ACM Wireless Networks, December 1995. [19] Ramon Caceres, and Liviu Iftode, " Improving. the performance of reliable transport protocols in mobile computing environments," IEEE Journal on Selected Areas in Communications, Vol . 13, No. 5, pp. 850-857, June 1995. [20] Pietro Manzoni, Dipak Ghosal, and Giuseppe Serazzi, "Imapact of mobility on TCP/IP: an integrated performance study," IEEE Journal on Selected Areas in Communications, Vol . 13, No. 5, pp. 858-867, June 1995. [21] Jianhua. Lu, Ming L. Liou, and K. Ben Letaief, "Efficient image transmission over wireless channels," Proceedings of IEEE International Symposium on Circuits and Systems '97, pp. 1097-1100, June 1997. Appendix A Source Code of the Client IFTP Model Appendix A Source Code of the Client IFTP Model 89 Process Model Report: iftp_clientO Thu Oct 01 11:39:29 1998 | Page 1 of 15 Process Model Comments Process Model Attributes Attribute Remote Port properties Property 1 Value Default Value: -1 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Remote Node properties Property Value Default Value: -1 Data Type: integer. Attribute Description: Private Auto, assign value: FALSE Attribute Remote Net properties Property Value Default Value: -1 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Local Port properties Property Value Default Value: -1 • Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Start Time properties 1 Property Value Default Value: 1.0' Data Type: double Attribute Description: Private Auto, assign value: FALSE Process Model Interface Attributes Attribute begsim intrpt properties Inherit Property Value Assign Status: set Initial Value: enabled N/A Default Value: disabled YES Data Type: toggle N/A Attribute Description: Private N/A Appendix A Source Code of the Client IFTP Model 90 Process Model Report: iftp_clientO ThuOctOI 11:39:29 1998 Page 2 of 15 Comments: YES This attribute specifies whether a 'begin simulation interrupt' is generated for a processor module's root process at the start of the simulation. Symbol Map: NONE YES Attribute endsim intrpt properties Property Value Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: toggle , N/A Attribute Description: Private N/A Comments: YES This attribute specifies whether an 'end simulation interrupt' is generated for a processor module's root process at the end of the simulation. Symbol Map: NONE YES Attribute failure intrpts properties Property Value Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: enumerated N/A Attribute Description: Private N/A Comments: YES This attribute specifies whether failure interrupts are generated for a processor module's root process upon failure of nodes or links in the network model. Symbol Map: NONE YES Attribute intrpt interval properties Property Value Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: toggle double N/A Attribute Description: Private N/A Units: sec. YES Comments: YES This attribute specifies how often regular interrupts are scheduled for the root process of a processor module. Symbol Map: NONE YES Attribute priority properties Property Value Inherit Assign Status: set Initial Value: 0 N/A Default Value: 0 YES Appendix A Source Code of the Client IFTP Model 91 Process Model Report: iftp_clientO Thu Oct 01 11:39:29 1998 Page 3 of 15 Data Type: integer N/A Attribute Description: Private N/A Low Range: -32767 inclusive YES High Range: 32767 inclusive YES Comments: YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. Symbol Map: NONE YES Attribute recovery intrpts properties Property • Value Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: enumerated N/A Attribute Description: Private N/A Comments: YES This attribute specifies whether recovery interrupts are scheduled for the processor module's root process upon recovery of nodes or links in the network model. Symbol Map: NONE YES Attribute super priority properties Property Value Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: toggle N/A Attribute Description: Private N/A Comments: YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. Symbol Map: NONE YES Header Block /* Include files */ #includc " u d p _ a p i . h " /* Define the input and output streams */ 5 #define OUTSTRM 0 #define INSTRM 0 /* Define sonic constants */ #definc IFTPC_DATA_TIMEOUT -18 10 #definc 1FTPC_RXRQ_TIME0UT 20 #define lFrPC_CODE_START 30 /* Define the transition condition macros */ Appendix A Source Code of the Client IFTP Model 92 Process Model Report: iftp_clientO Thu Oct 01'11:39:29 1998 j Page4of15 15 20 25 30 35 40 45 50 55 60 65 #define DATA_ARRVL (op_intrpt_type() == OPCJNTRPT.STRM && \ image_rcvd_flag == 0) #definc OUT_OF_SEQ (out_of_seq_flag == 1) #define TN_SEQ (oul_of_scqjlag == 0) #define DATA_TIMEOUT (op_intrpt_type() == OPC_INTRPT_SELF && \ op_intrpt_code() — IFTPC_DATA_TIMEOUT && \ image_rcvd_flag == 0) #definc RXRQ_TIMEOUT (op_intrpt_type() == OPCJNTRPT_SELF && \ op_intrpt_code() != 1 FTPC_DATA_TIMEOUT && \ image_rcvd_flag == 0) #define START_UP (op_intrpt_type() == OPC_TNTRPT_SELF && \ op_intrpt_code() == IFTPC_CODE_START) /* Define the transition exaculive macros */ #define SEQ_TEST seq_test() /* Data structure for scans */ typedef struct I . inl scan_num; int scan_si/.e; int misscd_scan; double send_lime; Packet* scan_ptr; int scan_rcvd; ) IftpT_Scan; . typedef struct ( Evhandle ev; char active: 1 Ii'tpT_Timcr; void seq_test(): /* Global variables '"/ double glbl_traftic_pkt; double glbl_traffic_bil: double glbl_thruput_pkl; double glbl_thruput_bit; double glbl_ete_delay_scan; double other_lraflic_bit; /* Global variable to record the number of MESs which have */ /* already received the whole image. If total number of MESs is 3, */ /* the simulation will be terminated when numjnes is 3. '*/ int iftp_num_mes = 0; /* Record the image delay time and prepare to update stat. '*/ double iftp_mes()_d0; double iftp_m.es 1 _d I; double iftp_mes2_d2; Appendix A Source Code of the Client IFTP Model 93 Process Model Report: iftp_clientO Thu Oct 01 11:39:29 1998 : Page 5 of 15 State Variable Block 5 /* Addressing Info '*/ Objid \loc_mod_objid; Objid \udp_objid; double \start_lime; int \local_port; int \remote_porl; inl \remole_net; int \reinole_node;. 10 Ici* \udp_cmd_ici_ptr; 15 /* Sequence number of a scan which should be received in order '*/• ini \scan_seq_count; int \check_seq_count; int \total_nscan_rcvd; int \out_or_scq_flag; 20 25 int \num_scans; /* Buffer variables */ It'tpT_Scan \scan_buf[256]: /* Retransmission request timers*/ IftpT_Timer \rxrq_timer[256]; /* Flag of frame header obtaining. */ int \frame_header: int \last_scan_rcvd; 30 /* Whole image received flag. Indicate this MES has /"' got the whole image. Used to control the state transition. int \imagc_rcvd_fiag; V V 35 Stathandle Stathandle \scan_reved_stathndl; \total_nscan_stathndl; 40 /* Global stal handle */ Stathandle \traffic_bit_gstathndl: Stathandle \ete_delay_gslalhndl; /* Data timout timer event handle "/ Evhandle • \data_timei_ev; Evhandle \rx_req_timer_ev[256]; 45 double \timcout_valuc: Temporary Variable Block Packet* pkptr; Packet* pkptr_out: int i; int scan_num. „tmp; int num_rcvd_ .scans; int index; Appendix A Source Code of the Client IFTP Model 94 Process Model Report iftp_clientO Thu Oct 01 11:39:29 1998 :. Page.6 ot 15 10 double send lime; Function Block unforced state init attribute value tvpe default value name init string St enter execs (See below.) textlist exit execs (empty) textlist (empty) status unforced toggle unforced enter execs init . 1,"' ;'?: :::':i\ZZ-. y:12 /* Read object attributes. */ • loc_mod_objid = op_id_self (); op_ima_obj_attr_gct (loc_mod_objid, " S t a r t T i m e " , &stan_lime); op_ima_obj_attr_get (loc_mod_objid, " L o c a l P o r t " . &local_porl); 5 op_ima_obj_attr_get (loc_mod_objid, " R e m o t e P o r t " , &remote_port); op_ima_obj_attr_get (loc_mod_objid, " R e m o t e N e t " , &remotc_ncl); op_ima_obj_attr_get (loc_mod_objid, " R e m o t e N o d e " , &remote_node); /* Get the objid of the UDP process */ 10 udp_objid = op_id_from_name(op_topo_parent(loc_mod_objid), OPC_OBJTYPE_PROC, " u d p " ) ; /* The first scan which should be reveived in order is Scan 0... */ scan_scq_count = 0; check_seq_coum = -1; 15 total_nscan_rcvd = 0; out_ol'_seq_llag = -1; /* At the beginnig, the frame header is not arrived. */ 20 lrame_header = 0; lasl_scan_rcvd = 0; /* the image has not been received at leh beginning. */ image_rcvd_riag = 0; • • 25 num_scans = -1; /* Register the. local output statistics to obtain the. handles V scan_rcved_stathndl = op_stat_rcg("Scans R e c e i v e d i n O r d e r " , OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL); 30 lotal_nscan_slalhndl = op_slat_reg("Total N u m b e r o f S c a n s R e c e i v e d " , OPC_STATJNDEX_NONE, OPC_STAT_LOCAL /* Initialize the receiver scan buffer '*/ for(i=0;i<256;i++) scan_bulli].scan_revd = 0; 35 /* Initalize the retransmission timers */ for (i=0;i<256;i++) rxrq_timcr[i].active = 0; Appendix A Source Code of the Client IFTP Model 95 Process Model Report: iftp_clientO Thu Oct 01 11:39:29 1998. ! P a g e 7 o l 1 5 40 45 50 55 timeoul_value = 0.0; /* Schedule the start of operation. */ op_intrpt_schedule_self(slart_limc, 1FTPC_C0DE_START); /* Update the statistics '*/ op_stat_write ( s c a n _ r c v e d _ s t a t h n d l , s c a n _ s e q _ c o u n [ ) ; op_stat_write ( i o t a l _ n s c a n _ s l a t h n d l , l o t a l _ n s c a n _ r c v d ) ; /* Register the global output statistics to obtain the handles */ t r a f f i c _ b i t _ g s l a t h n d l = o p _ s t a t _ i e g ( " G l o b a l T r a f f i c " , OPC_STAT_INDEX_NONE. OPC_STAT_GLOBAL); e t e _ d e l a y _ g s t a t h n d l = o p _ s t a l _ r e g ( " E T E D e l a y f o r E a c h S c a n " , OPC_STAT_INDEX_NONE, OPC_STAT_GLOBAL); transition init -> snd req attribute value type default value name tr_0 string tr condition STARTJJP string executive string color RGB333 color RGB333 drawing style spline toggle spline transition init -> init attribute value tvpe default value name tr_17 string tr condition default string executive string color RGB333 color RGB333 drawing style spline . toggle spline forced state snd rea attribute value tvpe default value name snd_req string S t enter execs (See below.) textlist exit execs (empty) textlist (empty) status forced toggle unforced enter execs snd rea /* Create, the new port for image file transfer. */ u d p _ c m d _ i c i _ p t r = op_ici_create ( " u d p _ c o m m a n d " ) ; op_ici_attr_set(udp_cmd_ici_ptr, " r e m _ n e t " . , r e m o t e _ . n e t ) ; 5 op_ici_attr_set ( u d p _ c m d j c i _ p t r , " r e m _ p o r t " . r e m o t e _ p o r t ) ; op_ici_attr_set ( u d p _ c m d _ i c i _ p t r , " l o c a l _ p o r t " , l o c a l _ p o r t ) : Appendix A Source Code of the Client IFTP Model 96 Process Model Report: iflp_clientO Thu Oct 01 11:39:29 1998 | Page 8 of 15 IO 15 20 25 30 35 op_ici_attr_set (udp_cmd_ici_ptr, " r e m _ n o d e " , remolc_nodc); op_ici_install (udp_cmd_ici_ptr); op_intrpt_force_rcmote (UDPC_COMMAND_CREATE_PORT, udp_objid); /* Issue a Request command to the UDP atul send it lo the image server. */ p k p t r = op_pk_create_fmt(" i f t p _ r e q u e s t " ) ; ii'(pkptr==OPC_NIL|| op_pk_nfd_sct (pkptr, " L o c a l P o r t " , locaLport) == OPC_COMPCODE_FAILURE |[ op_pk_nfd_set (pkptr, " s c a n n u m b e r " , 0) == OPC_COMPCODE_FAILURE || ' op_pk_nfd_set (pkptr, " r e t x r e q u e s t f l a g " , 0) == OPC_COMPCODE_FAILURE) { p r i n t f ( " \ n U n a b l e t o c r e a t e o r i n i t i a l i z e R e q u e s t p a c k e t . \ n " ) ; ) /* get the total size, of this request and update the global variable V glbl_traffic_pkl++; glbl_traffic;_bit = glbl_traffic_bil' + op_pk_total_si/.e_get (pkptr); op_iei_install (udp_cmd_ici_ptr); op_pk_send (pkptr, OUTSTRM); /* Start the data timeout timer and get the. event handle of this timer'*/ data_limcr_cv = op_intrpt_schedule_self(op_sim_time()+5.0, IFTPC_DATA_TIMEOUT); transition snd rea -> wait attribute \.CMluelt.:~::,-: default value name tr_1 string tr condition string executive string color RGB333 color RGB333 drawing style spline toggle spline unforced state wait attribute value tvpe default value name wait string st enter execs (See below.) textlist exit execs (See below.) textlist status unforced toggle unforced enter execs wait Appendix A Source Code of the Client IFTP Model 97 Process Model Report: iftp_clientO Thu Oct 01 11:39:30 1998 , P a g e 9 o M 5 exit execs wait it"(op_intrpt_type() == OPC_INTRPT_STRM && image_rcvd_nag == I) i /* The image transfer to this node (MES) has been completed. */ /" Destroy the incoming packet to save memory. */ 5 op_pk_destroy(op_pk_get(rNSTRM)); I transition wait -> proc attribute value tvpe default value name tr 2 string' tr condition DATA_ARRVL string executive string color RGB333 color RGB333 drawing style spline toggle spline ltan\ition wait -> wait attribute value tvpe default value name tr_6 string tr condition default string executive string color RGB333 color RGB333 drawing style spline toggle spline transition wait -> rtx req attribute value tvpe default value name tr 9 string tr condition DATA_TIMEOUT || RXR... string executive string color RGB333 color RGB333 drawing style spline toggle spline forced state proc attribute value • . tvpe default value name proc string S t enter execs (See below.) textlist exit execs (empty) textlist (empty) status forced toggle unforced enter execs proc . pkptr = op_pk_f>ct(INSTRM); op_pk_nfd_get (pkptr, "scan number", &scaii_num_tmp): op pk nfd.act (pkptr, "send time", &send....tirne); Appendix A Source Code of the Client IFTP Model 98 Process Model Report: iftp_clientO ThuOctOI 11:39:30 1998 Page 10 of 15 10 15 20 25 30 35 40 45 50 55 60 printf("IFTP_client_0: scan # = %d, send time = %f, receive time = %f, e-to-e delay = %f\n" scan_num_tmp, send_time, op_sim_timc(), op_.sim_timc()-scnd_tiine): /* Update the global end-to-end delay statistic "/ glbl_ele_delay_scan = op_sim_timc()-send_time; op_stat_write (ele_delay_gslathndl, glbl_ete_delay_scan); op_stat_write (tralTic_bit_gstalhndl, (double)glbl_tra(Tic_bit/op_sim_tinic()); /* Update the timeout value for retransmission request timer */ timeout_value = 4.0*(op_sim_time() - send_time); if (scan_bulTscan_num_tmp].scan_rcvd == I) { /'* Retransmitted scan received. */ if (rxrq_timcr[scan_num_lmpl. active) {' • • /* A retransmission request has been sent, while we have got this scan, V /* So cancel the retransmission timer associated with this scan. */ i f (op_ev_valid(rxrq_t i mer| scan_num_tmp] .ev ) ) op_cv_cancel(rxrq_timei'[scan_num_tiTip].ev); rxrq_iimer[scan_num_tmp].aciive = 0; ' } /*• Destroy this scan which has been received before. '*/ /* op_pk_deslroy(pkptr); */ else /* This scan has not been received before. Put it into the scan buffer. */ op_pk_nfd_get (pkptr, " s c a n number", &scan_buf[scan_num_tmp].scan_num): op_pk_nfd_get (pkptr. " s c a n s i z e " , &scan_buf[scan_num_tmp].scan_size); op_pk_nf'd_get (pkptr, " m i s s e d s c a n " , &scan_buf[scan_nuin_lmp].misscd_scan); «P_pk_nfd_gct (pkptr, " s e n d t i m e " , &scan_buflscan_num_tmpl.send_timc); op_pk_nfd_get (pkptr, " s c a n d a t a " , &scan_baflscan_nuni_lmp].scan_ptr); scan_bu(Tscan_num_lmp].scan_rcvd = 1; if (rxrq_limer[scan_num_tmp].active) ( . • /* A retransmission request has been sent, while we have got this scan, */ /* So cancel the retransmission timer associated with this scan. */ if (op_ev_valid(rxrq_timerfscan_num_tmpl.ev)) op_cv_canccl(rxrq_timer[scan_num_lmp].ev); rxrq_timcr[scart_ntim_tmp]. active = 0; tolal_nscan_rcvd++; op_stut_write (total_nscan_stathndl, total_nscan_rcvd); if (scan_bul[scan_num_tnip].scan_iium == 0) {• /* Frame header received. */ frame_header = 1; /* Get the total number of scans from ScanO. */ op_pk_nfd_gct (scan_bu(lscan_num_tmp].scan_ptr, " n u m b e r of s c a n s " , &num_scans); Appendix A Source Code of the Client IFTP Model 99 Process,Model Report: iftp_clientO Thu Oct 01 11:39:30 1998 | Page 11 of 15 65 70 75 80 85 90 95 100 105 110 115 120 /* if (scan_buf[scan_num_lmp].scan_num - scan_seq_counl >= 3)*/ i = scan_scq_count; ' while (scan_num_tmp - i >= 3) i ' . printf (" r x r q _ t i m e r [ i ] . a c t i v e = % d \ n " ,rxrq_limer[i].active); /* if I !(rxrq_limerfscan _seq_count].active))*/ if ((scan_buf[i].scan_rcvd == 0) && (!rxrq_tinier[i].active)) ( printf ( " E n t e r t h e r e t r a n s m i s s i o n r e q u e s t : t i m e o u t _ v a l u e = % f \ n " , limeout_value); /* Issue a retransmission request for the expected scan V pkptr_out = op_pk_creatc_fmt(" i f t p _ r e q u e s t " ) ; • if (pkptr_out = 0PC_NI.L || op_pk_.nfd_.set (pkptr_out, » L o c a l P o r t " , locaLport) == OPC_COMPCODE_FAILURE|| /* op_j}k_nfd_set (pkplr_out, "scan number", scan_seq_counl) == OPCJCOMPCODEJFAILURE)*/ op_pk_nfd_sct (pkptr_out, " s c a n n u m b e r " , i) == OPC_COMPCODE_FAILURE) ( ' p r i n t f ( " \ n U n a b l e t o c r e a t e o r i n i t i a l i z e R e q u e s t p a c k e t . \ n " ) ; /* get the total size of this scan and update the global variable */ glbl_traffic_pkt++; glbl_traffic_bit = glbl_traffic_bit + (double)op_pk_total_size_get (pkptr_out); op_tct_instaII (udp_cmd_ici_ptr); op_pk„send (pkptr_out, OUTSTRM); /* Start the retransmission request timer for this scan */ rxrq_timcr[i].cv = op_intrpt_schcdule_self(op_sim_time()+timcout_value, i); rxrq_timer[il.acllve = I; while C scan_buffscan_seq_count].scan_rcvd == 1 ) ( scan_seq_count++; op_stat_write (scan_rcved_stalhndl, scan_seq_count); ) if ((scan_num_tmp == num_scans) && (framejieader == |) ) { last_scan_rcvd = 1; for (i=0;i<num_scans;i++) I if ((scan_buffi].scan_rcvd == 0)&&(!rxrq_timer[i"]. active)) I /* Scan i has not been received. */ /* fane a retransmission request for each expected scan */ pkptr_out• = op_pk_create_fmt(" i f t p _ r e q u e s t " ) ; if (pkptr_out == OPC_NlL |] op_pk_nfd_set (pkptr_out, " L o c a l P o r t " , locaLport) == OPC_COMPCODE_FAlLURE|| op_pk_nfd_set (pkptr_out, " s c a n n u m b e r " , I) == OPC_COMPCODE_FAILURE) I prinl l ' ( " \ n U n a b l e t o c r e a t e o r i n i t i a l i z e R e q u e s t p a c k e t . \ n " ) ; /* get the total size of this scan and update the global variable */ Appendix A Source Code of the Client IFTP Model 100 Process Model Report: iftp_clientO Thu Oct 01 11:39:30 1998 [ P a g e 12 of 15 125 130 135 140 145 150 155 160 165 170 glbl_lralTic_pkt++;-glbl_lral'fic_bit = glbl_traffic_bit + (double)op_pk_total_size_get (pkptr_ou(): op_ici_install (udp_cmd_ic Lptr); bp_pk_send (pkplr_out. OUTSTRM); /* Stan the retransmission request timer for this scan */ rxrq_limer[i].ev = op_intrpt_schcdule_self(op_sim_timc()+timcout_vaiuc, i); rxrq_limer[i].active = 1; /* Destroy the packet for the current scan to free memory V op_pk_destroy (pkptr); if (scan_seq_count > num_scans && framejieader == 1) ( /* the whole image file has been received. Record the scalar stat and end the simulation '*/ /* op_stat_scalar_write ("Global Traffic. G", (double) glbl_traJ]ic_bit/op_sim_time());*/ /* op_stal_scalar_wrile ("Other Traffic T", (double) other_lraffic_bit/op_sim_time());*/ /*• op_stat_scalar_write ("IFTP Image File Transmission Time DO (MESO)", op_sim_lime()-start_time);*/ if(p_mes0_d0 = op_sim_timc()-start_lime; imagc_rcvd_flag = I.;/* Update the transition control */ iftp_num_mes++; /* iftp_num_mes is the global variable to record the number of MESs that */ /* have received the whole image. The initialization is done in MESO module. */ if (ilip_num_mes = 3) ( /* All the 3 MESs have got the image. Terminate the simulation. */ op_stat_scalar_write ("Global Traff ic G", (double) glbl_traffic_bit/op_sim_time()); ' op_stat_scaIar_writc ("IFTP Image F i l e Transmission Time DO (MESO) ". iftp_mes0_d0); op_stat_scalar_writc (" IFTP Image F i l e Transmission Time DI (MES1) ", iftp_mes 1 d 1); op_Stat_SCalar_write ("IFTP Image F i l e Transmission Time D2 (MES2) ", iflp_mes2_d2); op_stat_scalar_vvritc ("Other Traff ic T", (double) other_traffic_bit/op_sim_time()); op_sim„end(" — The whole image has been obtained. Simulation ends .=-","","",""); ) /* Else, go to wait slate and stay there waiting for other MESs. */ /'* Reset the data timeout timer */ if (op_ev_valid(data_timcr_cv)) op_ev_canceI(data_timer_ev); data_timer_ev = op_intrpt_schedule_self(op_simjimc()+5.0, IFTPC_DATA_TIMEOUT); transition proc -> wait attribute value tvpe default value name tr_11 string . tr J Appendix A Source Code of the Client IFTP Model 101 ProcessiModel Report: iftp_clientO Thu Oct 01 11:39:30 1998 Page 13 of 15 condition string executive string color RGB333 color RGB333 drawing style spline toggle spline forced state rtx req attribute value tvpe default value name rtx_req string st enter execs (See below.) textlist exit execs (empty) textlist (empty) status forced toggle unforced enter execs rtx rea if (op_intrpt_code () = IFrPC_DATA_'riMEOUT) t /* No data received for .5 seconds "/ if ( !rxrq_timer[scan_seq_count].active) r IO V /* And there is NO retransmission request scheduled for the expected scan. */ /* Issue a retransmission request for the expected scan immediately, and */ /* schedule the retransmission request timer. */ pkplr = op_pk_ereate_fmt(" i f tp_request"); if (pkptr ==OPC_NIL || op_pk_nfd_sct (pkplr, "Local Port". locaLporl) == OPC„COMPCODE„FAILURE|| op„pk_nfd_set (pkplr, "scan number", scan_scq_coiint) == OPC_COMPCODE_FAILURE) ( 15 i printf("\nUnable to create or i n i t i a l i z e Request packet.\n"); I 20 /* get the total size of this request and update the global variable */ glbl_lraffic_pkt++: glbl_traffic_bit = glbl_lraffic_bit + (ctouble)op_pk_total_si7.e_get (pkplr): op_ici_install (udp_cmd_ici_ptr); op_pk_send (pkplr, OUTSTRM); 25 if(scan_seq_count != 0) ( /* Start the retransmission request timer for this scan. V rxrq_timcr[scan_scq_count].cv = op_intrpt_schedule_self(op_sim_time()+timcout_valuc, scan_scq_count); rxrq_tiraer[scan_seq_count],active = 1; i 30 t if ( framc_hcadcr == 1 && scan_scq_count != (num_scans-l)) 35 1 The last few scans are lost. Issue retransmission requests for them */ /* immediately, and schedule the retransmission request timers. */ for (i=(scan_seq_count+1 );i<num_scans;i++) j 40 t pkptr = op_pk_create_fmt(" i f tp_request"); if(pkplr==OPC_NIL|| op_pk_nfd_sct (pkptr, "Local Port", locaLport) == OPC_COMPCODE_FAILURE|| op_pk_nfd_sct (pkptr. "scan number", i) == OPC_COMPCODE_FAILURE) Appendix A Source Code of the Client IFTP Model 102 Process Model Report: iftp_clientO Thu Oct 01 11:39:30 1998 | Page 14 of 15 45 50 55 60 65 70 75 80 85 90 print!" (" \nllnable to create or i n i t i a l i z e Request packet.\n"); I /* get the total size of this request and update the global variable */ glbl_traffic_pkt++; glbl_traffic_bit = glbl_traffic_bit + (doublc)op_pk_total_size_get (pkptr); op_ici_install (udp_cmd_ici_plr); op_pk_scnd (pkptr, OUTSTRM); /* Start the retransmission request timer for this scan. rxrq_timcr[i].cv = op_iritrpt_schedule_self(op_sim_time()+timcotit_valuc, i); rxrq_limer[i].active = i; /* Start the data timeout timer and get the event handle of this timer. */ data_timer_cv = op_intrpt_schedule_self(op_sim_time()+5.0, IFTPC_DATA_TIMEOUT); else /* The timeout timer is related to a scan. Get the scan sequence number /* first, then send a retransmission request for this scan. index = op_intrpt_codc(); pkptr = op_pk_create_fmt(" i f tp_reques t"); if (pkptr == OPCJMIL || op_pk_nfd_sct (pkptr, "Local Port", locaLport) = OPC_COMPCODE_FAILURE|| op_pk_nfd_set (pkptr, »scan number". index) == OPC_COMPCODE_FAILURE) ( • printf (" \nUnable to create or i n i t i a l i z e Request packet. \n"); /* gel the total size of this request and update the global variable */ glbl_traflic_pkt++; glbl_traffic_bit = glbl_traffic_bil + (double)op_pk_total_sizc_get (pkptr); op_ici_install (udp_cmd_ici_ptr); op_pk_send (pkptr, OUTSTRM); /* Start the retransmission request timer for this scan */ rxrq_limer[index].ev = op_intrpt_scliedule_self(op_sim_timc()+timeotiLvalue, index); rxrq_timer[index].aclive = 1: */ */ transition rtx req -> wait attribute value tvpe default value-name tr_4 string tr condition string executive string Appendix A Source Code of the Client IFTP Model , 103 Process Model Report: iftp_clientO ; 1 Thu Oct 01 11:39:30 1998 | Page 15 of 15 color RGB333' color RGB333 drawing style spline toggle spline Appendix B Source Code of the Server IFTP Model 104 Appendix B Source Code of the Server IFTP Model 105 Process Model Report: iftp_server Thu Oct 01 11:45:35 1998 Page 1 of 14 Process Model Comments Process Model Attributes Attribute Remote Net properties Property Value Default Value: -1 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Scan Size properties Value !:!::MMM''i:/ii t!•.: •.:: : ' : " ' : -'.::'-C':..:•: :, k< -1 \;¥.V'; Default Value: 2000 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Units: bytes Attribute Number of Scans properties Property Value c3wiiSi:2is-O ; / r - ; : ' ! .• ' ' . . . . ' ' ' : ' : ;i!';'•'.:.!.: '< 'Iii.'-M Default Value: 32 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Start Time properties Property Value Default Value: 1.0 Data Type: double Attribute Description: Private Auto, assign value: FALSE Attribute Local, Port 0 properties Property Value Default Value: -1 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Remote Port 0 properties Property Value Default Value: -1 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Remote Node 0 properties Property Value Appendix B Source Code of the Server IFTP Model 106 Process Model Report: iftp_server ThuOctOI 11:45:35 1998 jfligigiM Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Attribute Local Port 1 properties Property Value Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Attribute Remote Port 1 properties Property Value Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Attribute Remote Node 1 properties Property Value Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Attribute Local Port 2 properties Property Value Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Attribute Remote Port 2 properties Property Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Attribute Remote Node 2 properties Property Value Default Value: Data Type: Attribute Description: Auto, assign value: -1 integer Private FALSE Appendix B Source Code of the Server IFTP Model i 107 Process Model Report: iftp_server Thu Oct 01 11:45:35 1998 | Page 3 of 14 Process Model Interface Attributes Attribute begsim intrpt properties Property Value Inherit Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments: Symbol Map: set enabled N/A disabled YES toggle N/A Private N/A YES This attribute specifies whether a 'begin simulation interrupt' is generated for a processor module's root process at the start of the simulation. NONE Y E S v Attribute endsim intrpt properties:; Property Value Inherit Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments: Symbol Map: set disabled N/A disabled YES toggle N/A Private N/A YES This attribute specifies whether an 'end simulation interrupt' is generated for a processor module's root process at the end of the simulation. NONE YES Attribute failure intrpts properties Property Value Inherit Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments: Symbol Map: set disabled N/A disabled YES enumerated N/A Private N/A YES This attribute specifies whether failure interrupts are generated for a processor module's root process upon failure of nodes or links in the network model. NONE YES Attribute intrpt interval properties Property Value Inherit Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Units: Comments: set disabled N/A disabled YES toggle double - N/A Private N/A sec. YES YES This attribute specifies how often regular interrupts Appendix B Source Code of the Server IFTP Model 108 Process Model Report: iftp_server Thu Oct 01 11:45:35 1998 Page 4 of 14 are scheduled for the root process of a processor module. Symbol Map: NONE YES Attribute priority properties Property Value Inheut Assign Status: set Initial Value: 0 N/A Default Value: 0 YES Data Type: integer N/A Attribute Description: Private N/A Low Range: -32767 inclusive YES High Range: 32767 inclusive YES Comments: YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. Symbol Map: NONE YES Attribute recovery intrpts properties Property Value Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: enumerated N/A Attribute Description: Private N/A Comments: YES This attribute specifies whether recovery interrupts are scheduled for the processor module's root process upon recovery of nodes or links in the network model. Symbol Map: NONE YES Attribute super priority properties Property Value :*'•'"': ''MS-JiM-M %^X'Z~. i •'• ^ MMs''. •;.: •";' i:. Wi :::2J Inherit Assign Status: set Initial Value: disabled N/A Default Value: disabled YES Data Type: toggle N/A Attribute Description: Private N/A Comments: YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. Symbol Map: NONE YES Header: Block /* Include files V #include " u d p _ a p i . h " /* Define the input and output streams */ Appendix B Source Code of the Server IFTP Model 109 Process Model Report: iftp_server Thu Oct 01 11:45:35 1998 [ P a g e 5 o f 1 4 10 15 20 25 30 35 #define OUTSTRM 0 #definc TNSTRMO /* Define some constants */ #define IFTPC_CODE_START 30 /* Define the transition condition macros */ #dcfinc F1LE_REQ (op_intrpt_typeO == OPC_INTRPT_STRM && framejieader == 0 &.& \ retx_rq_flag == 0) #define RESEND_REQ (op_intrpt_type() = OPC_TNTRPT_STRM && framcjieader == I && \ retx_rq_flag == 1) #dcfine STARTJJP (op_intrpt_typeO == OPC_INTRPT_SELF && \ op_intrpt_code() = IFTPC_CODE_START) /* Data structure for scans */ typedef struct { - "' int scan_num; int scan_si/.e: int inissed_scan; double send_time; Packet* scan_ptr; int scan_txed; , } IftpT_Scan; /"void seq_tesl();*/ /* Global variables */ double glbl_traffic_pkt; double glbl_traffic_bit; double glbl_thruput_pkt; double glbl_lhrupul_bit; double glbl_ete_delay_scan; State Variable Block /* Addressing Info V Objid \loc_mod_objid; Objid \udp_objid; int \local_port_0; int \remote_port_0; int \remote_node_0; int \remote_net; int \local_pori_ 1; int \rcmote_port_ 1; int \remotc_node_l: int \local_port_2; int \remote_port_2: int \rcmotc_nodc_2; int \reinote_port_in: int \total_num_scans; int \scan_sizc_in; double \starl_timc; int \scan_bytef501; /* the input packet pointer */ Packet* \pkplr.„.in; Appendix B Source Code of the Server IFTP Model 110 Process Model Report: iftp_server Thu Oct 01 11:45:35 1998 | Page 6 of 14 25 30 35 40 45 Ici* \udp_cmd_ici_plr; Ici* ' \udp_cmd_ici_ptr_0; Ici* \udp_cmd_icj_ptr_l; Ici* \udp_cmd_ici_ptr_2: /* Sequence number of a scan which should he received in order */ int \scan_seq_count; int - \scan_rctx_count; int \num_scans; /* Buffer variables */ IftpT_Scan Vscan_buff256]; /* Retransmission request timers*/ /* Flag of frame header transmission. */ int . \frame_headcr; /* Relx request flag: if it is a retx request, flag is I: otherwise, flag is 0. "/ int \retx_rq_flag; Slathandle \scan_txed_stathndl; Stathandlc \scan_retx_stathndl; /* Data limout timer event handle */ Temporary Variable Block Packet* pkptr; Packets- pkptr_out; Packet* pkptr_scan; Packet* copy_pkptr; int i; int scan_num_req; int pk_sizc; /* int num_rcvd_scans; int index; double send time; unforced state init attribute value tvpe default value name init string St enter execs (See below.) textlist exit execs (empty) textlist (empty) status unforced toggle unforced Appendix B Source Code of the Server IFTP Model 111 Process Model Report: iftp_server Thu Oct 01 • 11:45:35 1998 . j . Page.7 of 14 enter execs init 10 15 20 25 30 35 40 45 50 55 /* Read object attributes. */ loc_mod_objid = op_id_self (); op_ima_obj_attr_get (loc_mod_objid, " s t a r t T i m e " , &s tar l_ t imc) ; op_ima_obj_attr_get (loc_mod_objid, " N u m b e r o f S c a n s " , & lo ta l_ i ium_scans ) : op_ima_obj_attr_gct ( l o c _ m o d _ o b j i d , " L o c a l P o r t 0", &local_port_0); op_ima_obj_attr_get (loc_mod_objid, " R e m o t e P o r t 0", &remolc_port_0); op_ima_obj_attr_get (loc_mod_objid, " R e m o t e N o d e 0", &remole_node_0); op_ima_obj_attr_get ( l o c _ m o d _ o b j i d , " L o c a l P o r t 1", &]ocal_port_l ) ; op_ima_obj_attr_get ( l o c _ m o d _ o b j i d , " R e m o t e P o r t 1", &rcmotc_por t_ l ) ; op_ima_obj_attr_get ( l o c _ m o d _ o b j i d . " R e m o t e N o d e 1", & r e m o l e _ n o d e _ l ) : op_ima_obj_attr_gct ( l o c _ m o d _ o b j i d , " L o c a l P o r t 2", &local_port_2); op_ima_obj_attr_get ( l o c _ m o d _ o b j i d , " R e m o t e P o r t 2", &remote_porl_2); op_ima_obj_attr_get (loc_mod_objid, " R e m o t e N o d e 2", &remolc_nodc_2) ; op_ima_obj_attr_gct (loc_mod_objid, " R e m o t e N e t " , & remote_ne l ) : /* Scan size in bytes in the actual Lena image file */ scan_by te [ i ] = 1595; scan_byte[2] = 756; scan_byte[3] = 526; scan_byte[4] = 1426; scan_byte[5] = 536; scan_byte[6] =525; scan_byte|7] =3418; scan_byte[8] = 497; scan_bytc[9] = 524; scan_byte[IO] = 6590; scan_byte[l 11 = 785; scan_byte[12] = 524; scan_bytc[13]= 13485; scan_byte[l4] = 1549; scan_byte[l5] = 523; scan_byle[l61 = 32677; scan_byte[17] = 522; scan_byte[18] = 43980; scan_byte[191 = 525: scan_byte[20] =41368; /* Get the. objid of the UDP process */ u d p _ o b j i d = op_id_from_name(op_topo_parent(loc_mod_objid), OPC_OBJTYPE_PROC, " u d p " ) ; /* The first scan which should be. transmitted in order is Scan 0... */ scar i_seq_count = 0; scan_re tx_coun l = 0; /*c.heck_seq_count =-1 ;*/ /* At the beginnig. the frame header is not transmitted. */ f rame_header = 0; • /* Don't know the value of the flag at the beginning. */ re lx_rq_f lag = -1: I* Register the local output statistics to obtain the handles */ scan_txed_s la lhndl = o p _ s t a l _ r e g ( " S c a n s T r a n s m i t t e d i n O r d e r " , OPC_STATJNDEX_NONE, OPC_STAT_LOCAL): Appendix B Source Code of the Server IFTP Model 112 Process Model Report: iftp_server Thu Oct 01 ,11:45:35 1998 | Page 8 of 14 60 65 70 75 80 scan_rctx_stathndl = op_stat_reg("Number of Retransmissions". OPC_STAT_INDEX_NONE, OPC_STAT_LOCAL); /* Initialize the receiver scan buffer */ for(i=0;i<256;i++) I scan_buf[i].scanjxed = 0: scan_buf[i].missed_scan = 0; } /* Initalize the retransmission timers */ /* for(i=0;i<256;i++) rxrq_timer/i].active = 0; timeout_value = 0.0: ' */ /* Initialize the local statistics */ /*scan_seq_cottnl+ +; */ op_stat_write (scan_L\ed_staihndl. scan_scq_count); op_stat_write (scan_retx_stathndl, scan_retx_count); /* Schedule the start of operation. */ op_intrpJ_schedulc_self(slart_lime, IFTPC„CODE_START); transition init -> init attribute tvpe default value name tr_22 string tr condition default string executive string color RGB333 color RGB333 drawing style . spline toggle spline transition init -> open attribute value tvpe default value name tr 26 string tr condition START_UP string executive string color RGB333 color RGB333 drawing style spline toggle spline unforced state wait attribute 1 value tvpe default value name wait string st enter execs (empty) textlist ' (empty) exit execs (See below.) textlist status unforced toggle unforced Appendix B Source Code of the Server IFTP Model 113 Process" Model Report: iftp_server, •ThuOctOI 11:45:35 1998 j Page 9 of 14 exit execs wait ' , if (op_intrpt_type() == OPC_INTRPT_STRM) ) ' ' i /* Transmission request has arrived. */ pkptr_in = op_pk_get(TNSTRM); 5 op_pk_nfd_get(pkptr_in, "retx request f lag", &.relx_rq_flag); op_pk_nfd_get(pkplr_in, "Local Port", &remote porl_in); ) transition wait -> send attribute value tvpe default value name tr 2 string tr condition FILE_REQ string executive string color R G B 3 3 3 color R G B 3 3 3 drawing style. spline toggle spline transition wait -> wait attribute value tvpe default value name tr_6 string tr condition default string executive string color R G B 3 3 3 color R G B 3 3 3 drawing style spline toggle spline transition wait -> resend attribute value ' tvpe default value name tr 9 string tr condition RESEND_REQ string executive string color R G B 3 3 3 color R G B 3 3 3 drawing style spline toggle spline forced state send attribute value tvpe default value ~ name send string st enter execs (See below.) textlist exit execs (empty) textlist (empty) status forced toggle unforced Appendix B Source Code of the Server IFTP Model 114 Process Model Report: iftp_server Thu Oct 01 11:45:35 1998 | Page 10 of 14 enter execs send 10 15 20 25 30 35 40 45 50 55 /* Open: create the new port for image file transfer. */ il'(remote_port_in == 1888) I udp_cmd_ici_ptr = udp_cmd_ici_ptr_0; ) if (remote_port_in == 1889) { udp_cnid_ici_ptr = udp_cmd_ici_ptr_l; 1 if (rcmote_por t_in = 1890) f udp_cmd_ici_ptr = udp_cmd_ici_ptr_2; /*pkptr - opjk_get(lNSTRM):S1/ op_pk_nfd_get (pkptr_in, "scan number", &scan_num_req); i f (scan_num_rcq == 0 && framc_header == 0) ( /* This is a valid image file transfer request. */ /* First create the first scan ScanO and transmit it. :17 pkptr_scan = op_pk_creatc_fmt ("if tp_scan0"); op_pk_nfd_set ( pkptr_scan, "number of scans", total_num_scans); pkptr_out = op_pk_create_fmt ("if tp_data"); op_pk_nfd_set ( pkptr_out, "scan number". 0); op_pk_nfd_set ( pkptr_oul, "scan size", op_pk_total_sizc_get(pkptr_scan)); op_pk_nfd_set (pkplr_out. "missed scan",0); op_pk_nfd_set ( pkptr_out. "send time", op_sim_time()); copy_pkplr = op_pk_copy(pkptr_scan); op_pk_nfd_set ( pkptr_out, "scan data", copy_pkptr); /* gel the total size of this scan and update the global variable */ glbl_lraffic_pkt++; glbl_traffic_bit = glbl_traffic_bil + (double)op_pk_totaI_size_get (pkptr_out); /* Save the scan in the transmitter scan buffer. */ scan_buf[0].scan_num = 0; scan_b»f[0].scan_size ='op_pk_total_size_gct(pkplr_scan); printf ("\n ==========Here=======\n"); scan_buf[0].misscd_scait = 0; scan_buf[01.send_time = op_sim_time(); scan_buf[0].scan_ptr = pkptr_scan; scan_buf[0].scan_txcd = 1; op_ici_install (udp_cmd_ici_ptr); op_pk_send (pkptr_out, OUTSTRM); /* Update the statistics */ scan_scq_cotint++; op_stat_writc (scan_txed_slathndl, scan_seq_count); /* Now send out all the scans in the image file. for (i=l;i<=total_num_scans;i++) Appendix B Source Code of the Server IFTP Model 115 Process Model Report: iflp_server : j h U j ^ 60 65 70 75 80 85 90 95 100 105 /* pkptr_scan = op_]>k_crealc( S*scan_size_in):*/ pkptr_scan = op_pk_crcate( 8*scan_byle[i]); pkptr_out = op_pk_creatc_fmt ("i£tp_data"); op_pk_nfd_sct ( pkptr_out, "scan number", i); op_pk_nfd_set ( pkptr_out, "scan size", op_pk_total_size_get(pkptr_scan)); op_pk_nfd_sct ( pkplr_out, "missed scan", 0); op_pk_nfd_set ( pkptr_out, "send time", op_sim_time()); copy_pkptr = op_pk_copy(pkptr_scan); op_pk_nfd_set ( pkptr_6ut, "scan data", copy_pkptr); /* get the total size of this scan and update the global variable */ glbl_traffic_pkt++; glbl_traffic_bil = glbJ_lraffic_bit + (doublc)op_pk_total_size_get (pkptr_out); /* Save the scan in the transmitter scan buffer. */ scan_buf[i].scan_num = i; scan_buf[i].scan_sizc = op_pk_total_size_get(pkptr_scan); . scan_buf[i].missed_scan = 0; scan_buf[i].send_time = op_sim_time(); scan_biil'[i].scan_ptr = pkplr_scan; scan_bulTi|.scan_lxed = 1; op_ici_install (udp_cmd_ici_ptr); «P_pk_send (pkptr_ou't, OUTSTRM); /* Update the statistics */ scan_seq_count++; op_stat_writc (scan_txed_stathndl, scan_scq_count); 1 • frame header = 1; else /* Invalid image file transfer request received. Print */ /* error message. '*/ printf("\n-- The image f i l e server got an inval id request --\n"); /* Destroy the packet for the current request to free memory */ op_pk_dcstroy (pkptr_in); transition send -> wait attribute value tvpe default value name tr_11 string tr condition string executive string color RGB333 color RGB333 drawing style spline toggle spline Appendix B Source Code of the Server IFTP Model 116 Process Model Report: iftp_server Thu Oct 01 11:45:36 1998 | Page 12 of 14 forced state resend attribute value1 tvpe default value name resend string st enter execs (See below.) textlist exit execs (empty) textlist (empty) status forced toggle unforced enter execs resend 10 15 20 •25 30 35 40 /* First, find out the port for retransmission of image, file transfer. */ if (remote_port_in == 1888) { udp_cmd_ici_plr = udp_cmd_ici_plr_0; I if (remote_port_in == 1889) { udp_cmd_ici_ptr = udp_crad_ici_ptr_1; ) if (remote_port_in == 1890) I udp_cmd_ici_plr = udp_cmd_ici_plr_2; ) /*pkptr = op _pk_get(lNSTRM);*/ op_pk_nfd_get (pkprr_in, "scan number", &scan_num_roq); pkptr_oM = op_pk_create_fmt ("if tp_data"); op_pk_nfd_sct ( pkptr_out, "scan number". scan_buf[scan_num_req].scan_num); op_pk_nfd_set ( pkptr_out. "scan size". scan_buf'[scan_nura_req].scan_sizc); op_pk_nfd_set ( pkptr_out. "missed scan", 1); op_pk_nfd_sct ( pkptr_out, "send time", op_sim_time()); copy_pkptr = op_pk_copy(scan_bul[scan_num_rcq].scan_ptr); op_pk_nfd_sct (pkptr_out, "scan data", copy_pkptr); /* get the total size of this scan and update the global variable */ glbl_lraflic_pkt++; glbl_traffic_bit = glbl_lraffic_bit + (double)op_pk_total_sizc_gct (pkptr_oul); /* Update the scan information in the transmitter scan buffer. ' scan_buf[scan_num_rcq].nrissed_scan = 1; scan_buffscan_num_rcq].send_linic = op_sim_time(); op_ici_instalI (udp_cnid_ici_plr); op_pk_send (pkptr_oul, OUTSTRM); Update the statistics */ scan_rctx_count++; op_stat_write (scan_rctx_stalhndl. scan_rctx_counl); /* Destroy the input packet to save memory. '*/ Appendix B Source Code of the Server IFTP Model 117 Process Model Report: iftp_server Thu Oct 01 11:45:36 1998 | Page 13 of 14 45 op_pk_destroy(pkptr_in); transition resend -> wait attribute' value tvpe default value name tr_4 string tr condition string executive string color RGB333 color RGB333 drawing style spline toggle spline forced state open attribute value tvpe default value name open string st enter execs (See below.) textlist exit execs (empty) textlist (empty) status forced toggle unforced enter execs open 10 15 20 25 30 /* Create the new proisfnr image file transfer. */ /* Port number 0 */ udp_cmd_ici_plr_0 = opjci_create("udp_command"); op_ici_attr_set (udp_cmdjci_ptr_0, " rem_net". remote_net); /* only one net */ op_ici_attr_set (udp_cind_ici_ptr_0, "rem_port", remote_port_0); op_ici_attr_set (udp_cmd_ici_ptr_0, "local_port". local_port_0); t>p_ici_attr_set (udp_cmd_ici_ptr_0, "rem_node", remotc_node_0); op_ici_install (udp_cmd_ici_ptr_0); op_intrpt_forcc_remotc (UDPC_COMMAND_CREATE_PORT, udp_objid); /* Port number I */ udp_cmdjci_ptr_l = op_iei_create("udp_commarid"); op_ici_attr_SCt (udp_cmd_ici_ptr_l, "rem_net", remote_net); /* only one net */ op_ici_attr_set (udp_cmd_ici_plr_l., "rem_port", rcmotc_porl_l); op_ici_attr_set (udp_cmd_ici_ptr_l, "local_port", local_port_l): op_ici_attr_set (udp_cmd_ici_ptr_l, "rem_node", remote_node_l); op_ici_install (udp_cmd_ici_plr_l); , op_intrpt_force_rcmotc (UDPC_COMMAND_CREATE_PORT, udp_objid); /* Port number 2 */ udp_cmd_ici_plr_2 = op_ici_creatc("udp_comraand"); op_ici_attr_set (udp_cmd_ici_ptr_2, " rem_net", remote_nct); /* only one net */ op_ici_attr_set (udp_cmd_ici_ptr_2, "rem_port", remote_port_2); op_id_attr_set (udp_cmd_ici_ptr_2, "local_port", local_port_2); op_ici_attr_set (udp_cmd_ici_ptr_2, "rem_node", rcmolc_node_2); op_ici_install (udp_c md_ici_ptr_2); Appendix B Source Code of the Server IFTP Model Process Model Report: iftp_server 118 Thu Oct 01 11:45:36 1998 [ Page 14 of 14 op_intrpt_force_remote (UDPC_COMMAND_CREATE_PORT, udp_objid); transition open -> wait attribute value tvpe default value name tr_28 string tr condition string executive string color RGB333 color RGB333 drawing style spline toggle spline 

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0064854/manifest

Comment

Related Items