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  T H E 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  The University of British Columbia Vancouver, Canada Date  DE-6 (2/88)  QrAolwr  IU,  1^8  C^P^p h/t&r  ^j  hjiury^  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.2  Wireless Data Networks  1.2  3  Motivation and Scope of This Thesis  ..-5  Chapter 2 Wireless Data Networks 2.1  Overview of Wireless Data Networks  2.2  Internet Protocol Stack  2.3  CDPD Network Architecture  2.3.1  CDPD Components  2.3.2  Airlink Protocol Profile  1  7 :  7 9 14 16 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  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  4.3.2  Client IFTP....  32  :  36 ;  39  Chapter 5 Design of a Simulation Model  42  5.1  Overview of the OPNET Simulation Tool...  5.2  CDPD Airlink Model Design.  :  42 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  5.3  LFTP Model  5.3.1  Client IFTP model  5.3.2  Server IFTP model  5.4  '.  57 59 59  .'  CDPD Network Configuration  60 61  Chapter 6 Simulations and Results  67  6.1  Simulation of Scheme 1 Transmission with TCP  6.2  Simulation of Scheme 2 Transmission with IFTP  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  67 70  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 Table 6.2 Summary of the Parameter Used in Scheme 2 Simulation  68 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  .'.  Figure 2.4 TCP Segment Header  12 '.  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 Figure 6.5 Comparison Between TCP and IFTP: BLER = 1%  :...-....„......!.... 73 ,  '.  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 Figure 6,10 Impact on TCP Clients, with or without IFTP, at BLER=5%  viii  79 80  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 h i g h degree o f data r e d u n d a n c y and result i n significant r e d u c t i o n o f the i m a g e size, relaxing  the  communication  and  storage  capacity  requirements.  However,  even  thus using  c o m p r e s s i o n techniques, i m a g e transmission over data networks d e m a n d s h i g h b a n d w i d t h . T h i s is not always available w h e n using m o b i l e computers and wireless data networks.  Image  c o m p r e s s i o n 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 n u m b e r o f bits. L o s s l e s s c o m p r e s s o r s preserve all the i n f o r m a t i o n i n the i m a g e and o n l y r e m o v e redundancies b y u s i n g entropy e n c o d i n g methods like L Z W and L Z 7 7 . T h e r e f o r e , the exact same unaltered i m a g e is reproduced  o n c e . decompressed.  Lossless  compression  reduces  the  original image  size  by  e n c o d i n g gray levels often u s e d with fewer bits and those s e l d o m u s e d with m o r e bits. Further lossless c o m p r e s s i o n c a n be a c h i e v e d b y taking into account spatial r e d u n d a n c y i n an image.  L o s s y c o m p r e s s i o n techniques such as those based on D C T (Discrete C o s i n e T r a n s f o r m ) , wavelet transform, or fractal transform, achieve m u c h higher c o m p r e s s i o n ratios b y r e m o v i n g i n f o r m a t i o n f r o m the i m a g e w h i c h is unimportant with respect to the h u m a n eye. T h e most p o p u l a r lossy c o m p r e s s i o n a p p r o a c h is J P E G (Joint Photographic E x p e r t G r o u p ) standard. T h e J P E G c o m p r e s s i o n a l g o r i t h m is the I S O standard for still images. It divides an i m a g e into b l o c k s of  8 b y 8 pixels, w h i c h are then converted into 64 values u s i n g the D C T . T h e s e values  are  analogous to f r e q u e n c y components. T h e loss o f i n f o r m a t i o n is i n t r o d u c e d b y q u a n t i z i n g the D C T coefficients. A f t e r quantization, an entropy e n c o d i n g step is p e r f o r m e d .  W a v e l e t based c o m p r e s s i o n has b e c o m e p o p u l a r in i m a g e and v i d e o c o d i n g [3].  This  c o m p r e s s i o n m e t h o d is based o n the wavelet transformation, w h i c h is u s u a l l y i m p l e m e n t e d b y quadrature m i r r o r filters c o n t a i n i n g a high-pass and a low-pass filter. B y successive filtering a n d  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 voiceoriented 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 M O B I T E X , 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 '  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.  6  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  '  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  8  Chapter 2 Wireless Data Networks  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.  9  10  Chapter 2 Wireless Data Networks  OSI  TCP/IP Based  Application  Application  Presentation Session Transport Transport Network Data link Physical  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  |  v  5  |  6  |  7  |  8  |  9  [  10  |  11  |  12  |  13  |  14  15  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  14  2.3 CDPD Network Architecture 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  .  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.  17  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.  MDBS  MES  MD-IS  IP/CLNP  IP/CLNP  SNDCP  SNDCP ; jj MDLP  Shaded Area: Scope of the Airlink  \,  MDLP Relay  MDLP  . TP4  MAC  Physical  CLNP  CLNP  RNDOF  SNPCF  X.25/LAPD/PPP  X.25/LAPD/PPP  D So/Ethernet  DStVEthernel  MAC  Physical  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  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  19  Chapter 2 Wireless Data Networks  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.  20  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 2 -1, i.e., shifted from unsigned integers with range [0, 2 -l] to signed integers P  p  with range [-2 , 2 "'-l], where P is the number of bits per pixel. Then the pixel values of the PA  P  image is divided into blocks of size 8 x 8, and each 8 x 8 block is transformed using an 8 x 8 forward DCT (FDCT). At the output of the decoder, the inverse DCT (IDCT) outputs the 8 x 8 block to form the reconstructed image [4, 7].  21  Chapter 3 JPEG Image Compression  22  8x8 blocks FD.CT  Source Image Data  Entropy Encoder  Compressed Image Data  Table Specifications  Table Specifications  Channel  Dequantizer  Entropy Decoder  Compressed Image Data  Table Specifications  Table Specifications  Encoder  I DCT  Reconstructed Image Data  Quantizer  Decoder  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 A C 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, topto-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 lowerresolution 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 8 x 8 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 bytealigned 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]  [table/misc]  frame header  scan header  /  [ECS„  scan,  RST„  [DNL segment]  ECS „, la>  [scanj  RST,„,.,]  scan  nsi  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 o p t i m i z e d progressive i m a g e c o d i n g m e t h o d based on J P E G has been p r o p o s e d [6], w h i c h is c o m p l i a n t with JPEG  standard.  This  method  is  a  hybrid  version  of  spectral  selection  and  successive  a p p r o x i m a t i o n techniques that produces scans w h i c h are ordered a c c o r d i n g to decreasing v i s u a l importance.  The  proposed  progressive  JPEG  (PJPEG)  coding  a l g o r i t h m first  tries  to  solve  the  relationship between the D C T coefficient and the reproduction quality. T o address the p r o b l e m , all the bits o f 64 D C T coefficients i n an 8 x 8 b l o c k are assigned i m p o r t a n c e levels that i n v o l v e the  size  of  the  resulting  scan  and  the  scan's  contribution  to  distortion  reduction.  More  s p e c i f i c a l l y , each bit i n a D C T coefficient is assigned a distortion-rate ratio, w h o s e numerator is the reduction in reconstruction distortion, and denominator is the scan's size i n bytes. T h e resulting v a l u e is then used to associate with each bit a priority l e v e l . T a k i n g into  account  progressive J P E G ' s encoder structure a n d constraints, the p r i o r i t i z e d bits are g r o u p e d , a c h i e v i n g higher c o m p r e s s i o n efficiency and l o w e r computational requirements. T h e g r o u p e d bits then are assigned with the same priority and e n c o d e d into one scan associated with the same i m p o r t a n c e class. A l l the scans are generated i n a sequence o f decreasing i m p o r t a n c e , w h i c h means  the.  earlier a scan is transmitted, the m o r e important it is to the reduction in reconstruction distortion.  Process of Bit Prioritization:  A s s u m i n g 8-bit input p r e c i s i o n , each D C T coefficient  will  have 11-bit p r e c i s i o n , 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 b l o c k c a n be considered as a parallelepiped w h i c h contains 8 x 8 x 10 or 640 bits as s h o w n in F i g u r e 3.4. A n i m a g e consists o f a n u m b e r o f 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 LSB  DC50 AC51 AC52 AC53 AC54 AC55 AC56 AC57 DC60 AC61 AC62 AC63 AC64 AC65 AC66 AC67 DC70 AC71 AC72 AC73 AC74 AC75 AC76 AC77  Figure 3.4 An 8 x 8 x 10 Parallelepiped  T h e decoder assumes 8 x 8 x 10 parallelepipeds o f all "0"s a n d the "0"s are r e p l a c e d b y the actual values o f the bits as they are decoded. T h e r e f o r e , to quantify the effect o f each bit o n the quality o f the d e c o d e d image, the distortion associated with each bit b e i n g c o n s i d e r e d "0" is calculated. W h e n  the value o f a bit is "0", its associated  distortion w i l l be e q u a l to  zero  regardless o f its position, as the decoder has already assumed all the bits to,have a "0" value, a n d d e c o d i n g a "0" bit w i l l not reduce the reconstruction distortion. In the progressive J P E G c o d i n g m o d e , each bit o f the parallelepiped s h o u l d be transmitted a l o n g with the bits at the  same  position o f all the parallelepipeds i n an image. T h u s , the o v e r a l l distortion reduction v a l u e s h o u l d be equal to the s u m o f the distortion reduction values associated with the bits at the same position  Chapter 3 JPEG Image Compression  29  in all the parallelepipeds in the i m a g e , that is, the o v e r a l l 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 n u m b e r o f 8 x 8 b l o c k s in the input image, bij is the value o f the ith bit o f the y'th parallelepiped and /?, is the position o f the ith bit. E n c o d i n g o f bits at different locations i n the parallelepipeds also results in different scan sizes or bit rates. T h u s , a ratedistortion o p t i m i z e d importance measure s h o u l d i n v o l v e the total distortion a n d bit rate values, and an appropriate importance measure 7, is then given b y  (3,2)  where / , , A D , a n d A/?, are the priority value, distortion reduction a n d scan size associated w i t h the ith bit, respectively. In this manner, those bits that contribute the most distortion r e d u c t i o n w h i l e r e q u i r i n g the least n u m b e r o f bits (smallest scan size) are assigned the highest priority values. B a s e d on the priority value defined in the last equation, all the 640 bits i n an 8 x 8 b l o c k c a n be sorted i n terms o f decreasing order o f priority values.  Grouping of bits:  In order to obtain m o r e efficient  c o m p r e s s i o n a n d c o n f o r m to  progressive J P E G standard, a n u m b e r o f consecutive bits s h o u l d be g r o u p e d to be e n c o d e d into a single scan. C o m b i n i n g successive a p p r o x i m a t i o n with spectral selection, g r o u p i n g D C T bits c a n then be p e r f o r m e d i n two directions, g o i n g f r o m most to least significant bits and i n the z i g - z a g direction f r o m the first A C coefficient to the highest frequency A C coefficient. W h e n t w o or  the  Chapter 3 JPEG Image Compression  30  m o r e bits are g r o u p e d , their distortions are added. U s i n g the rate o f the g r o u p e d bits, the p r i o r i t y value representing each spectral b a n d is recalculated. E a c h group is then e n c o d e d into a scan, a n d all the scans are transmitted a c c o r d i n g to their priority values in several stages.  F i n a l l y , the o v e r a l l P J P E G transmission a l g o r i t h m can be stated as f o l l o w s :  •  C a l c u l a t e the priority values o f all the bits o f all the D C T coefficients;  •  Obtain  the  best g r o u p i n g pattern, i.e.,  the  number of  the  most  significant  bits  c o m b i n e d to f o r m the first group for each coefficient;  •  C o m b i n e the bits or group o f bits to f o r m spectral bands;  •  R e c a l c u l a t e priority values as required for each scan;  •  O r d e r and transmit all the scans a c c o r d i n g 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 a n d the bit rate is g i v e n in [6], where the P S N R is defined as  PSNR(dB) = \0\og  In (3.3),  x  peak  (3.3)  is the peak value o f the output signal a n d Cy is the m e a n squared error.  F r o m that c u r v e , we can derive the relationship between P S N R a n d the a c c u m u l a t e d number of  scans, that are r e c e i v e d in order. T a b l e  3.1  shows  the  result  o f the  PSNR  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 P S N R and Accumulated Number of Scans for the 512 x 512 Lena Image Accumulated Number of Scans 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  PSNR (dB) 24.6 25.6 26.7 28.2 28.4 28.6 31.5 31.7 31.9 34.8 35.0 35.1 38.2 38.5 38.7 43.5 43.6 50.6 50.8 58.0  1  ;  ;ro^BitiRatejr:" .'-"t (bPP) . • 0.049. 0.077 0.093 0.137 0.153 0.169 0.273 0.289 0.305 0.506 0.530 0.546 0.957 1.005 1.020 2.018 2.034 3.376 3.392 4.654  Table 3.2 Scan Size and Importance Class of the 512 x 512 Lena Image Scan Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  Size (bytes) 1595 756 526 1426 536 525 3418 497 524 6590 785 524 13485 1549 523 32677 522 43980 525 41368  'it'.- .Importance Class 223695 24016 15099 5236 3874 3867 1566 966 940 426 251 246 110 . 70 62 28 16 9 4 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 c o r r e s p o n d i n g to the required quality as a parameter. W h e n the i m a g e server receives the request, it w i l l transmit a sequence o f scans as a response, in w h i c h the n u m b e r o f scans corresponds to the P S N R  that is required. S i n c e T C P p r o v i d e s a reliable  c o n n e c t i o n between the client and the server, every scan arrives at the client's a p p l i c a t i o n layer in order. T h e r e f o r e , the i m a g e can be reconstructed progressively as m o r e scans arrive. W h e n all the scans are r e c e i v e d , the i m a g e reconstruction is finished. T h e quality o f the i m a g e is what the client requires. T C P . guarantees that the i m a g e file can reach the client, no matter what the l i n k quality is and h o w l o n g it w i l l take to complete the.session. A f t e r the t r a n s m i s s i o n session i n v o k e d , application processes cannot change anything unless they stop the T C P session a n d start a new one with new parameters.  Using  this  scheme,  the . i m a g e  transmission  delay  is  determined  by  the  image  reconstruction quality ( P S N R ) required b y the client. F o r e x a m p l e , the transmission delay o f a large i m a g e file with a l o w quality requirement m a y be the same as that o f a s m a l l i m a g e file with a h i g h quality requirement. T h i s is because all the scans o f the s m a l l i m a g e file s h o u l d be transmitted, w h i l e o n l y s o m e h i g h priority scans o f the large i m a g e file need to be transmitted for a l o w e r quality image.  O n e o f the advantages o f this scheme is that the required i m a g e quality is guaranteed. M o r e o v e r , standard T C P is used and there is no need to m o d i f y the existing transport p r o t o c o l . H o w e v e r , the i m a g e transmission delay time m a y be longer in a wireless data network than in a w i r e l i n e counterpart. In the wireless  network, the channel is not as reliable as in the w i r e d  network. H i g h packet loss rate occurs all the time i n wireless channels. T h e p r i n c i p l e p r o b l e m here is the congestion  control a l g o r i t h m used in T C P . M o s t T C P implementations have  been  34  Chapter 4 JPEG Image Transmission over CDPD Network  carefully o p t i m i z e d based on assumptions that are true for wireline networks but w h i c h fail for wireless networks. A m o n g these assumptions, the one that has the most significant i m p a c t to the p e r f o r m a n c e o f T C P in wireless networks is that T C P assumes that timeouts  are c a u s e d  by  congestion, not b y packet loss. C o n s e q u e n t l y , when a T C P timer goes off, T C P slows d o w n and sends less v i g o r o u s l y , u s i n g an algorithm c a l l e d "slow start". T h e i d e a b e h i n d this a p p r o a c h is to reduce the network traffic and thus alleviate the congestion.  U n f o r t u n a t e l y , wireless transmission links are h i g h l y 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 q u i c k l y as possible. S l o w i n g d o w n just m a k e things worse, and the throughput drops a lot. W h e n a packet is lost o n a w i r e d network, the sender  s h o u l d slow d o w n because the packet loss is due  to  congestion. W h e n a packet is lost on a wireless network, the sender s h o u l d try harder. H o w e v e r , i f the sender does not k n o w what the network is, it is difficult to m a k e the correct d e c i s i o n . T h i s is the case with the n o r m a l T C P .  T h e r e are several methods to solve the p r o b l e m s i n v o k e d b y u s i n g n o r m a l T C P in the wireless networks. O n e of them, indirect T C P (I-TCP), is to break the T C P c o n n e c t i o n into two separate connections [8, 17]. T h i s is based o n that the path f r o m sender to receiver is almost all w i r e d , except the e n d section o f the path, w h i c h is f r o m base station to m o b i l e host. T h e r e f o r e , the first c o n n e c t i o n i n I - T C P goes f r o m the sender to the base station. T h e s e c o n d one goes f r o m the base station to the receiver. T h i s solves the p r o b l e m o f distinguishing packet losses due to congestion or corruption, but the disadvantage is that it violates the semantics o f T C P . b e c o m e s a p r o t o c o l that does not p r o v i d e end-to-end connections.  I-TCP  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 w i l l send the i m a g e scan b y scan o v e r the C D P D network u s i n g U D P . E a c h scan transmitted w i l l be assigned a priority a n d a sequence n u m b e r . W h e n the client E F T P receives a scan, it w i l l c h e c k its sequence n u m b e r a n d use it to reconstruct the i m a g e i f the scan has the expected sequence n u m b e r . If a scan is m i s s i n g d u r i n g the transmission, the client I F T P w i l l c h e c k this scan with the scan point test, a n d m a k e a d e c i s i o n o n whether it s h o u l d be retransmitted or not. T h e scan point test is b a s e d o n the scan priority a n d the channel conditions. If this scan passed the scan point test, a retransmission request w i l l be sent to the server. A f t e r the server receives this request, it w i l l retransmit the requested scan. F i g u r e 4.1 shows the Server I F T P system.  JPEG  JPEG  Scan  Image  Image  Trans-  Reader  mitter  1  UDP Socket  -  Client Request Analysis  IFTP Server  Figure 4.1 Server I F T P System  In an E F T P i m a g e server, all the available i m a g e files are p r e - c o m p r e s s e d b y P J P E G a n d stored. T h e S e r v e r E F T P system w i l l first open an U D P socket a n d wait f o r an i m a g e transfer request f r o m ah E F T P client. W h e n an i m a g e transfer request is arrived, the S e r v e r E F T P reads the requested i m a g e file into its buffer. T h e n the frame header o f the P J P E G i m a g e file is separated  Chapter 4 JPEG Image Transmission over CDPD Network  37  to f o r m the first scan. T h i s scan is very important to the P J P E G decoder because the c o n t r o l data for the w h o l e i m a g e is in this frame header. T h e client must get this f r a m e header to d o the d e c o d i n g . E v e n i f the client decoder has r e c e i v e d all the other scans, it cannot d e c o d e  them  without the frame header. If the first scan that contains the frame header data is lost d u r i n g the t r a n s m i s s i o n , the client I F T P w i l l have to send a retransmission request for this scan to the server. T h i s w i l l o c c u r w h e n the retransmission timer for this scan goes off, a n d w i l l continue until the f r a m e header arrives.  T h e other i m a g e data scans are p r i o r i t i z e d b y the ratio o f the scan i m p o r t a n c e 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 i n T a b l e 3.2. H e r e w e use the f o l l o w i n g equation to calculate the n o r m a l i z e d scan priority:  lOlogP=  ^  (4.1)  where P is the n o r m a l i z e d scan priority, / is the, scan importance factor, s is the scan size in bytes, P i is the n o r m a l i z e d scan priority for S c a n 1. D i v i d i n g the scan i m p o r t a n c e factor b y the scan size, the average i n f o r m a t i o n a byte carries in a scan can be obtained. T h e reason o f t a k i n g the l o g a r i t h m o f the scan importance factor over the scan size is that the d y n a m i c range o f the scan i m p o r t a n c e is-too large. T h e result o f the l o g a r i t h m w i l l be m u l t i p l i e d b y 10 a n d d i v i d e d b y the n o r m a l i z e d scan priority o f S c a n 1 so that S c a n 1 is always o f the highest priority, a n d the n o r m a l i z e d scan priority ranges f r o m 10 to 1. T a b l e 4.1 shows the scan i m p o r t a n c e factor, scan size and the n o r m a l i z e d scan priority.  Chapter 4 JPEG Image Transmission over CDPD Network  38  Table 4.1 Scan Priority for Lena Image i;i;>AfScanlNumber  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20  Scan Importance  223695 24016 15099 5236 3874 3867 1566 966 940 426 251 246 110 70 62 28 16 9 43  '  'Scan Size  1595 756 526 1426 536 525 3418 497 524 6590 785 524 13485 1549 523 32677 522 43980 525 41368  »  Scan Priority  10 '7 7 3 5 5 1 2 2 1 1 1 1 1 1 1 1 1 1 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. T h i s is also used b y the C l i e n t E F T P to determine whether a lost scan s h o u l d be retransmitted or not. T h e detailed a l g o r i t h m w i l l be discussed in the next sub-section.  4.3.2 Client IFTP The  C l i e n t E F T P resides i n the m o b i l e host, i.e., an M E S in a C D P D t e r m i n o l o g y . A n  i m a g e user uses the C l i e n t E F T P to issue an image file transfer request to the i m a g e file server. W h e n the first scan o f the i m a g e arrives, it w i l l be prepared to receive all the scans i n the i m a g e . At  the same time, the C l i e n t E F T P starts up a retransmission timer. W h e n the C l i e n t  EFTP  receives scans f r o m the server, it w i l l verify the n u m b e r o f scans r e c e i v e d so far as w e l l as c h e c k whether the p r e v i o u s scan has been received. If a previous scan is m i s s i n g , the scan point test a l g o r i t h m w i l l be used to determine whether the lost scan s h o u l d be retransmitted. If the m i s s e d scan passes the scan point test, a retransmission request for the m i s s e d scan is sent to the server, and a retransmission timeout timer is set started. If the m i s s e d scan does not pass the scan p o i n t test, then either it is not so important to reconstruction o f the i m a g e or the c h a n n e l c o n d i t i o n is v e r y bad. T h i s m i s s e d scan w i l l be discarded. F i g u r e 4.2 shows the C l i e n t E F T P system.  Reconstructed Image  Scan Retransmission Algorithm  IFTP Client  Figure 4.2 Client I F T P 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)  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.  (4.3)  Chapter 5 Design of a Simulation Model The discussion in the last chapter indicates that Scheme 2 of using I F T P 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 I F T P client is in the network and these send image transfer requests to the server, what w i 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, will the performance of T C P be affected? T o answer these questions, several investigation methods can be used. One is to implement I F T P 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. W e will 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. W e 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 ( O P N E T ) , 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.  Network Domain  Process Domain  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  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.  44  Chapter 5 Design of a Simulation Model  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  45  Chapter 5 Design of a Simulation Model  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 ReedSolomon (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  46  Chapter 5 Design of a Simulation Model  47  BLER = 1 - (1 - BER)  (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)  (5.2)  420  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  0.01 0.02 0.03 0.04 0.05 0.06 0.07 0.08 0.09 0.10  BER,,  .  0.000023929 0.000048101 0.000072519 0.000097191 0.00012212 0.00014731 0.00017277 0.00019851 0.00022452 0.00025083  ..  With these fictitious BER values, the physical layer can be modeled with a duplex pointto-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 M A C 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  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  49  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 M D - I S 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 w i l l be removed and a new T E I w i 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 w i 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 will be sent out at the same time. When frame 5 arrives, the receiving window w i 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  retransmissions  is absent i n the SWP  53  m o d e l . In the M D L P ,  this m a x i m u m n u m b e r o f frame  retransmissions is used to cause the release and reset o f a l o g i c a l data l i n k between the M E S a n d the M D - I S . A d d i n g this functionality is the major m o d i f i c a t i o n to the SWP SWP  model. T h e modified  as the M D L P m o d e l is s h o w n in F i g u r e 5.4.'  The  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 w i l l transition to one o f the five  states  a c c o r d i n g to the transition conditions. T h e five states and transition conditions are as f o l l o w s .  Figure 5.4 MDLP Model  1.  W h e n a packet arrives f r o m the upper layer ( S N D C P ) , the process w i l l transition to the state  xm.it,  in w h i c h the packet w i l l be converted to a M D L P frame and sent out to  the l o w e r M A C layer. If the sending w i n d o w is f u l l , the packet w i l l be inserted to a queue to wait for a position in the sending w i n d o w .  Chapter 5 Design of a Simulation Model  2.  When a packet arrives from the lower layer ( M A C ) , the process w i l l transition to the state rev. If the packet sequence number falls within the receiving window, it is accepted; otherwise, it w i 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 will 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 will transition to the send_ack state, and an explicit A C K for a received frame will be sent out to indicated the successful reception of this frame.  5.  When the number of retransmissions for a frame exceeds the parameter of M a x i m u m Number of Retransmissions, the logical data link is disconnected. The process w i l l transition to the reset state, and will 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 will 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 w i 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.  54  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 S N D C P 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 Airlink 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 state diagram of the Client EFTP process model is shown in Figure 5.8.  Figure 5.8 Process Model of Client I F T P  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  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 I F T P  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 T l 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  64  Chapter 5 Design of a Simulation Model  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 t y p i c a l Intermediate S y s t e m (IS) is s h o w n in F i g u r e 5.15. It consists o f a IP m o d u l e w h i c h routes packets to the destination and several transceiver pairs. S i n c e the structure o f the network m o d e l is not too c o m p l i c a t e d , the internal f i x e d routing table is d e p l o y e d here as the routing m e t h o d . T h e description o f the IS internal structure is also suitable to that o f the gateway m o d e l , w h i c h has the additional ability to route packets between the subnets.  U ip _enc ap  nun IIIIII  n  C ip_a rp_0  B  3  rx_0  3^  3  • ip_arp _2  3 m  B  B  tx_0  rx_2  .tx_2  1  ip_a  U B3 tx_l  ip_a rp_3  3  L*B3  rx_l  tx_3  B  3  S  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 w h i c h simulate the offered Internet traffic. T h e packets are generated with an exponential interarrival distribution. T h e m e a n interarrival time w i l l be set to different values  at the b e g i n n i n g o f  s i m u l a t i o n to obtain different Internet traffic load. T h e expected value o f the packet size is set to 6 5 5 3 6 bits (8192 bytes), close to the m a x i m u m transfer unit size o f the IP datagram. A s s h o w n i n F i g u r e 5.16, processor  a t y p i c a l peripheral node consists  (proc)  o f an ideal packet generator  (src),  a packet  a n d an IP m o d u l e . T h e addresses o f the packet destination net a n d node are  generated r a n d o m l y in the  proc m o d u l e .  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  11 _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  Application  TCP  MDLP Physical, Airlink Physical, Wireline  Parameter Image Size Size of Packets in Peripheral Nodes Distribution of Interarrival Time Mean of Interarrival Time Max A C K Delay  Max Segment Size Max Retransmission Timeout Value Min Retransmission Timeout Value Max Number of Retransmissions Max A C K Delay Max Delay before Frame Retransmission Window Size Data Rate BLER Data Rate  Value 64000 bytes 8192 bytes Exponential Variable 0.5 sec 8192 bytes 240 sec 0.5 sec 3 0.5 sec 3 sec 16 19.2 Kbps Variable 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 T r a n s m i s s i o n Time D l (MES1) 180  1  170 IGO  1 • 1  --L-J i  i  130  I  120  i .  110  ~~iii  100  .1  I •  i  r  " i i " *  i 1  --  p" .  1 1  1 > 1  i  i  j - . -j-. j  I  i  h---Mrii ; iii " 1 "  •  - -  , : • 1 • 1. 1  -i • y •  • 1  i  ' T " i — r " - f "  140  1  L.i..._  i  150  90  1  • 1  " r 1 • I I  I  i  1  1  " -i i 1  ___I___J_-__J._._1___ 1 1  80 .825  7.85  1 1  7.875  1  I  7.9  I 1  7.925  7.95 7.975 8 Other T r a f f i c  8.025 8.05 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 Application  UDP MDLP Physical, Airlink Physical, Wireline  Parameter Image Size Scan Size Scan Point Test Size of Packets in Peripheral Nodes Distribution of Interarrival Time ' Mean of Interarrival Time Datagram Size Max Number of Retransmissions Max ACK Delay Mac Delay before Frame Retransmission Window Size Data Rate BLER Data Rate  Value 64000 bytes 2000 bytes All Pass 8192 bytes Exponential Variable 2018 bytes 3 0.5 sec 3 sec 16 19.2 Kbps Variable T1 (1.544 Mbps)  Chapter 6 Simulations and Results  72  —e—  BLER = OMESO  •—  BLER = 0MES1  €>--  —©.--  BLER = 0 M E S 2 BLER = 1 % MESO  X  BLER = 1%MES1  X  BLER = 1 % M E S 2  1  BLER = 5 % MESO  1  0  1  •  BLER = 5 % MES1 • BLER = 5 % MES2  2  3  4 5 6. 7 Offered Network Traffic Load (bps)  8  9  10 10  .11 =  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 Offered Network Traffic Load (bps)  8  9  10  Figure 6.6 Comparison Between TCP and IFTP: BLER = 5%  11 1 Q6  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 EFTPbased 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 —  TCP  — - © - —  TCP BLER=1%  -—e—  TCPBLER=5% IFTP  150  200 250 Transmission Time (sec)  BLER=0  X  IFTP B L E R = 1 %  X  IFTP B L E R = 5 %  300  350  '  BLER=0  400  450  Figure 6.7 T C P and I F T P Comparison: P S N R 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  i  i  i  i  —e— A  BLER=0 BLER=1% BLER=5%  5 £ o  U  .  >  CO  10 E i= 30  -  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 I F T P 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  Figure 6.10 Impact on TCP Clients, with or without IFTP, at BLER=5%  80  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  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  82  Chapter 7 Conclusions and Further Study'  83  has and w h i c h an i m p r o v e d version w o u l d continue to have, is the ability to p r o v i d e the client the o p t i o n o f sacrificing image quality i n return for a faster transmission s h o u l d he c h o o s e .  O u r simulation m o d e l abstracted those features o f C D P D  w h i c h affect the  EFTP/TCP  c o m p a r i s o n the most. S o m e C D P D features that were not m o d e l e d are c h a n n e l h o p p i n g due to severe c h a n n e l signal-to-noise ratio degradation or due to A M P S user p r e e m p t i o n , a n d c h a n n e l contention b y m u l t i p l e M E S s .  A n o t h e r possible area o f further study lies in the p e r f o r m a n c e c o m p a r i s o n between I F T P and  m o d i f i e d T C P that is o p t i m i z e d for wireless networks.  In this w o r k , the c o m p a r i s o n  is  l i m i t e d to the standard T C P . S i n c e s o m e new T C P implementations are p r o p o s e d to address the problem  invoked  implementations  by  standard  T C P in  wireless  networks,  comparing  with the E F T P c o u l d benefit further research o n efficient  over wireless data networks.  these image  new  TCP  transmission  /  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, 3 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.  r  86  References  [12]  87  CCITT T.81, ISO/EEC 10918-1, Information Technology - Digital Compression and Coding of Continuous-Tone Still Images: Requirements and Guidelines, 1 ed., February st  1994. [13]  Yasushi Koyama and Susumu Yoshida, "Error control for still image transmission over a " fading channel," Proceedings of IEEE 45 Vehicular Technology Conference, V o l . 2, th  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 7 IEEE International Symposium on Personal, Indoor and Mobile Radio Communications, PIMRC '96, V o l . 3, pp.948-952, 1996. th  [15]  Jorge A . Cobb and Prathima Agrawal, "Congestion or corruption? A strategy for efficient wireless T C P sessions," Proceedings of IEEE Communications ISCC '95, 1995.  [16]  Symposium in Computers and  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 15 International Conference on Distributed Computing Systems (ICDCS), May 1995. th  [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  Process Model Report: iftp_clientO  89  Thu Oct 01 11:39:29 1998  | Page 1 of 15  Process Model Comments  Process Model Attributes Remote Port properties  Attribute  Property  1  Attribute  Remote Node properties  Property  Remote Net  Property  Value -1 integer. Private FALSE  Default Value: Data Type: Attribute Description: Auto, assign value: Attribute  Value  -1 integer Private FALSE  Default Value: Data Type: Attribute Description: Auto, assign value:  properties  Default Value: Data Type: Attribute Description: Auto, assign value:  Value -1 integer Private FALSE  Attribute Local Port properties Property  Value  Default Value: Data Type: Attribute Description: Auto, assign value:  -1 • integer Private FALSE  Attribute Start Time properties Property  1  Default Value: Data Type: Attribute Description: Auto, assign value:  Process Model Interface Attributes begsim intrpt properties  Attribute  Value 1.0' double Private FALSE  Property  Value  Inherit  Assign Status: Initial Value: Default Value: Data Type: Attribute Description:  set enabled disabled toggle Private  N/A YES N/A N/A  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  Comments:  Symbol Map: Attribute endsim intrpt properties  ThuOctOI 11:39:29 1998  Property  Value set disabled disabled toggle , Private  Attribute failure intrpts properties  Property  Value set disabled disabled enumerated Private  Attribute intrpt interval properties  Property  Value set disabled disabled toggle double Private sec.  Attribute priority properties  Inherit N/A YES N/A 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  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Units: Comments:  Symbol Map:  Inherit  N/A YES N/A 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  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Symbol Map:  Page 2 of 15  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 YES  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Symbol Map:  90  Inherit  N/A YES N/A N/A YES YES This attribute specifies how often regular interrupts are scheduled for the root process of a processor module. NONE YES  Property  Value  Assign Status: Initial Value: Default Value:  set  0 0  Inherit N/A YES  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  Data Type: Attribute Description: Low Range: High Range: Comments:  Thu Oct 01 11:39:29 1998  N/A N/A YES YES YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. NONE YES  Attribute recovery intrpts properties  •  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Value  N/A YES N/A N/A 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. NONE YES  Attribute super priority properties Property Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Value set disabled disabled toggle Private  Inherit  N/A YES N/A N/A YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. NONE YES  Symbol Map:  Header Block  5  Inherit  set disabled disabled enumerated Private  Symbol Map:  /* Include files */ #includc "u d p _ a p i .  Page 3 of 15  integer Private -32767 inclusive 32767 inclusive  Symbol Map:  Property  91  h"  /* Define the input and output streams */ #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  Process Model Report: iftp_clientO  92  Thu Oct 01'11:39:29 1998  #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) 20 #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 && \ 25 op_intrpt_code() == IFTPC_CODE_START) 15  /* Define the transition exaculive macros */ #define SEQ_TEST seq_test() 30  /* Data structure for scans */ typedef struct I . inl scan_num; 35 int scan_si/.e; int misscd_scan; double send_lime; Packet* scan_ptr; int scan_rcvd; ) IftpT_Scan; . 40 typedef struct ( Evhandle ev; 45 char active: 1 Ii'tpT_Timcr; void  seq_test():  50 /* Global variables '"/ double glbl_traftic_pkt; double glbl_traffic_bil: double glbl_thruput_pkl; double glbl_thruput_bit; 55 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, */ 60 /* the simulation will be terminated when numjnes is 3. '*/ int iftp_num_mes = 0;  /* Record the image delay time and prepare to update stat. '*/ iftp_mes()_d0; 65 double double iftp_m.es 1 _d I; double iftp_mes2_d2;  j Page4of15  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  93  Thu Oct 01 11:39:29 1998  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;  /* Sequence number of a scan which should be received in order '*/• ini \scan_seq_count; int \check_seq_count; 15 int \total_nscan_rcvd; int  \out_or_scq_flag;  int  \num_scans;  20 /* Buffer variables */ It'tpT_Scan \scan_buf[256]: /* Retransmission request timers*/ IftpT_Timer \rxrq_timer[256]; 25 /* 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; Stathandle 35 Stathandle  \scan_reved_stathndl; \total_nscan_stathndl;  /* Global stal handle */ Stathandle \traffic_bit_gstathndl: Stathandle \ete_delay_gslalhndl; 40 /* Data timout timer event handle "/ Evhandle • \data_timei_ev; Evhandle \rx_req_timer_ev[256]; 45 double  \timcout_valuc:  Temporary Variable Block Packet* Packet* int int int int  pkptr; pkptr_out: i; scan_num.„tmp; num_rcvd_.scans; index;  V V  : Page 5 of 15  Appendix A Source Code of the Client IFTP Model  94  Process Model Report iftp_clientO  double  Thu Oct 01 11:39:29 1998  :. Page.6 ot 15  send lime;  10  Function Block  unforced state init attribute name enter execs exit execs status  value init (See below.) (empty) unforced  tvpe string textlist textlist toggle  default value St (empty) unforced  enter execs init /* 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,  .  1,"' '?: ::':i\ZZ-. :12 ;  :  y  "udp");  /* 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; 20  /* At the beginnig, the frame header is not arrived. */ 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 timeoul_value = 0.0; /* Schedule the start of operation. */ op_intrpt_schedule_self(slart_limc, 1FTPC_C0DE_START); 45  50  /* Update the statistics op_stat_write ( s c a n _ r c v e d _ s t a t h n d l , op_stat_write ( i o t a l _ n s c a n _ s l a t h n d l ,  '*/ scan_seq_coun[);  lotal_nscan_rcvd);  /* Register the global output statistics to obtain the handles */ traffic_bit_gslathndl =o p _ s t a t _ i e g ( " G l o b a l ete_delay_gstathndl =op_stal_reg("ETE  T r a f f i c " , OPC_STAT_INDEX_NONE. OPC_STAT_GLOBAL);  Delay  f o rE a c h  S c a n " , OPC_STAT_INDEX_NONE, OPC_STAT_GLOBAL);  55  transition init -> snd req attribute name condition executive color drawing style  transition init -> init attribute name condition executive color drawing style  value tr_0 STARTJJP  type string string string color toggle  default value tr  default value tr  RGB333 spline .  tvpe string string string color toggle  value snd_req (See below.) (empty) forced  tvpe string textlist textlist toggle  RGB333 spline  value tr_17 default  forced state snd rea attribute name enter execs exit execs status  enter execs snd rea /* Create, the new port for image file transfer. */ udp_cmd_ici_ptr  5  = 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 " . , op_ici_attr_set ( u d p _ c m d j c i _ p t r , " r e m _ p o r t " .  remote_.net); remote_port);  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 " ,  local_port):  RGB333 spline  RGB333 spline  default value St  (empty) unforced  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  op_ici_attr_set (udp_cmd_ici_ptr, " r e m _ n o d e " , remolc_nodc);  IO  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. */  15 p k p t r = op_pk_create_fmt(" i f t p _ r e q u e s t " ) ; ii'(pkptr==OPC_NIL||  20  '  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)  { printf ( " \ n U n a b l e )  t oc r e a t e  o r i n i t i a l i z e  Request  packet.  \n");  25 /* 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);  30 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'*/ 35 data_limcr_cv = op_intrpt_schedule_self(op_sim_time()+5.0, IFTPC_DATA_TIMEOUT);  transition snd rea -> wait attribute name condition executive color drawing style  unforced state attribute name enter execs exit execs status  \.CMluelt.:~::,-:  RGB333 spline  string string string color toggle  value wait (See below.) (See below.) unforced  tvpe string textlist textlist toggle  tr_1  default tr  value  RGB333 spline  wait  enter execs  wait  default st  value  unforced  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  97  Thu Oct 01 11:39:30 1998  ,Page9oM5  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 name condition executive color drawing style  ltan\ition wait -> wait attribute name condition executive color drawing style  transition wait -> rtx req attribute name condition executive color drawing style  value tr 2 DATA_ARRVL  tvpe string' string string color toggle  default value tr  tvpe string string string color toggle  default value tr  default value tr  spline  tvpe string string string color toggle  value • . proc (See below.) (empty) forced  tvpe string textlist textlist toggle  RGB333 spline  value tr_6 default  RGB333 spline  value tr 9 DATA_TIMEOUT || RXR...  RGB333  RGB333 spline  RGB333 spline  RGB333 spline  forced state proc  attribute name enter execs exit execs status  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);  default value St  (empty) unforced  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  98  T h u O c t O I 11:39:30 1998  Page 10 of 15  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 "/  10  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 */  15  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) {' • •  20  /* A retransmission request has been sent, while we have got this scan, /* So cancel the retransmission timer associated with this scan.  i f (op_ev_valid(rxrq_t i mer| scan_num_tmp] .ev))  25  V */  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); */  30 else  35  40  /* 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)  ( 45  .•  /* 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; 50 tolal_nscan_rcvd++; op_stut_write (total_nscan_stathndl, total_nscan_rcvd);  55  if (scan_bul[scan_num_tnip].scan_iium == 0) {• /* Frame header received. */  frame_header = 1; /* Get the total number of scans from ScanO. */  60  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  /* 65  /* 70  /*  | Page 11 of 15  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  75  Thu Oct 01 11:39:30 1998  t h er e t r a n s m i s s i o n  request:  timeout_value  = % 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)  (  printf("\nUnable t o c r e a t e  80  '  o r i n i t i a l i z e  Request  packet.\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);  85  op_tct_instaII (udp_cmd_ici_ptr); op_pk„send (pkptr_out, OUTSTRM); 90  /* 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;  95  while C scan_buffscan_seq_count].scan_rcvd == 1 ) 100  105  110  115  (  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  prinll' ( " \ n U n a b l e  t o create  o r i n i t i a l i z e  Request  packet.\n");  120 /* get the total size of this scan and update the global variable */  100  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  Thu Oct 01 11:39:30 1998  [ P a g e 12 of 15  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);  125  /* 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;  130  135 /* Destroy the packet for the current scan to free memory V op_pk_destroy (pkptr);  if (scan_seq_count > num_scans && framejieader == 1)  140  (  145  /* 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. */ 150  155  160  if (ilip_num_mes = 3) ( /* All the 3 MESs have got the image. Terminate the simulation. */ op_stat_scalar_write ("Global T r a f f i c 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 T r a f f i c 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. */  165 /'* 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); 170  transition attribute name  proc -> wait value tr_11  tvpe string  default value . tr  J  Appendix A Source Code of the Client IFTP Model  ProcessiModel Report: iftp_clientO  101  Thu Oct 01 11:39:30 1998  condition executive  Page 13 of 15  string string  color  RGB333  color  RGB333  drawing style  spline  toggle  spline  forced state rtx req attribute name enter execs exit execs status  value rtx_req (See below.) (empty) forced  tvpe string textlist textlist toggle  default value st (empty) 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 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.  IO  */ */ */  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) ( i  15  printf("\nUnable 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_lraffic_pkt++: glbl_traffic_bit = glbl_lraffic_bit + (ctouble)op_pk_total_si7.e_get (pkplr): 20 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)) 1  35  40  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 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  Process Model Report: iftp_clientO  102  Thu Oct 01 11:39:30 1998  | Page 14 of 15  print!" (" \nllnable to create or i n i t i a l i z e Request packet.\n"); I 45  /* get the total size of this request and update the global variable */  50  op_ici_install (udp_cmd_ici_plr); op_pk_scnd (pkptr, OUTSTRM);  glbl_traffic_pkt++; glbl_traffic_bit = glbl_traffic_bit + (doublc)op_pk_total_size_get (pkptr);  /* 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; 55  /* 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);  60  else 65 /* 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(); 70  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)  75  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 */ 80  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);  85  /* 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:  90  transition rtx req -> wait attribute name condition executive  value tr_4  tvpe  default value-  string string string  tr  Appendix A Source Code of the Client IFTP Model  Process Model Report: iftp_clientO  color drawing style  ;  RGB333'  spline  ,  1 Thu Oct 01 11:39:30 1998  color toggle  | Page 15 of 15  RGB333 spline  103  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 Default Value: Data Type: Attribute Description: Auto, assign value:  Value -1 integer Private FALSE  Attribute Scan Size properties Value !:!::MMM''i/ii t!•. •.: 2000 integer Private FALSE bytes :  Default Value: Data Type: Attribute Description: Auto, assign value: Units:  Attribute Number of Scans properties Property Value c3wiiSi:2is-O Default Value: 32 Data Type: integer Attribute Description: Private Auto, assign value: FALSE Attribute Start Time properties Property Default Value: Data Type: Attribute Description: Auto, assign value:  Value 1.0 double Private FALSE  Attribute Local, Port 0 properties Property Default Value: Data Type: Attribute Description: Auto, assign value:  Value -1 integer Private FALSE  Attribute Remote Port 0 properties Property Default Value: Data Type: Attribute Description: Auto, assign value:  -1 integer Private FALSE  Attribute Property  Remote Node 0 properties  Value  Value  :  :  :' "': :  ;  -'.::'-C':..:•: , k< -1 \;¥.V'  ;  :  / r - ; : ' ! . • ' ' . . . . ' ' ' : ' : ;i ';'•'.:.!.: !  '< 'Iii.'-M  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  Default Value: Data Type: Attribute Description: Auto, assign value:  Attribute Local Port 1 properties Property Default Value: Data Type: Attribute Description: Auto, assign value:  Attribute Remote Port 1 properties  Property  Default Value: Data Type: Attribute Description: Auto, assign value: Attribute Remote Node 1 properties  T h u O c t O I 11:45:35 1998  -1 integer Private FALSE  Value  -1 integer Private FALSE  Value  -1 integer Private FALSE  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: Attribute Remote Node 2 properties  106  -1 integer Private FALSE  Property  Value  Default Value: Data Type: Attribute Description: Auto, assign value:  -1 integer Private FALSE  jfligigiM  Appendix B Source Code of the Server IFTP Model  107  i Process Model Report: iftp_server  Process Model Interface Attributes begsim intrpt properties  Attribute  Thu Oct 01 11:45:35 1998  Property  Value  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  set enabled disabled toggle Private  endsim intrpt  Property  properties:;  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Symbol Map: Attribute  Property  failure intrpts properties  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Symbol Map: Attribute  Property  intrpt interval properties  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Units: Comments:  Inherit  N/A YES N/A 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 YES  Symbol Map: Attribute  | Page 3 of 14  Value set disabled disabled toggle Private  v  Inherit  N/A YES N/A 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  Value set disabled disabled enumerated Private  Inherit N/A YES N/A 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  Value set disabled disabled toggle double Private sec.  Inherit  N/A YES N/A N/A YES YES This attribute specifies how often regular interrupts  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  Symbol Map: Attribute priority properties  Property  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Low Range: High Range: Comments:  Symbol Map: Attribute recovery intrpts properties  Property  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Symbol Map:  Attribute super priority properties Property  Assign Status: Initial Value: Default Value: Data Type: Attribute Description: Comments:  Symbol Map:  108  Thu  Oct 01 11:45:35 1998  Page 4 of 14  are scheduled for the root process of a processor module. NONE YES  Value  Inheut  set 0 0 integer Private -32767 inclusive 32767 inclusive  N/A YES N/A N/A YES YES YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. NONE YES  Value  Inherit  set disabled disabled enumerated Private  N/A YES N/A N/A 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. NONE YES  Value  :*'•'"': ''MS-JiM-M  set disabled disabled toggle Private  %^X'Z~.  i •'•  ^MMs''. •;.: •" ' i . WiInherit : :2J ;  :  N/A YES N/A N/A YES This attribute is used to determine the execution order of events that are scheduled to occur at the same simulation time. NONE YES  Header: Block /* Include files V #include "udp_api.h" /* Define the input and output streams */  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  #define OUTSTRM #definc TNSTRMO  109  Thu Oct 01 11:45:35 1998  0  /* Define some constants */  #define IFTPC_CODE_START 30 10 /* 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) 15 #dcfine STARTJJP (op_intrpt_typeO == OPC_INTRPT_SELF && \ op_intrpt_code() = IFTPC_CODE_START) /* Data structure for scans */  20 typedef struct {  25  -  int scan_num; int scan_si/.e: int inissed_scan; double send_time; Packet* scan_ptr; int scan_txed; } IftpT_Scan;  30 /"void  seq_tesl();*/  /* Global variables */  double 35 double double double double  glbl_traffic_pkt; glbl_traffic_bit; glbl_thruput_pkt; glbl_lhrupul_bit; glbl_ete_delay_scan;  State Variable Block /* Addressing Info V  Objid Objid int int int int int int int int int int int int int double int  \loc_mod_objid; \udp_objid; \local_port_0; \remote_port_0; \remote_node_0; \remote_net; \local_pori_ 1; \rcmote_port_ 1; \remotc_node_l: \local_port_2; \remote_port_2: \rcmotc_nodc_2; \reinote_port_in: \total_num_scans; \scan_sizc_in; \starl_timc; \scan_bytef501;  /* the input packet pointer */  Packet*  \pkplr.„.in;  ,  "'  [Page5of14  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  25  Ici* Ici* ' Ici* Ici*  110  Thu Oct 01 11:45:35 1998  | Page 6 of 14  \udp_cmd_ici_plr; \udp_cmd_ici_ptr_0; \udp_cmd_icj_ptr_l; \udp_cmd_ici_ptr_2:  /* Sequence number of a scan which should he received in order */  30 int int  -  int  \scan_seq_count; \scan_rctx_count; \num_scans;  35 /* Buffer variables */ IftpT_Scan Vscan_buff256]; /* Retransmission request timers*/ /* Flag offrame header transmission. */  40  int  .  \frame_headcr;  /* Relx request flag: if it is a retx request, flag is I: otherwise, flag is 0. "/  45  int  \retx_rq_flag;  Slathandle Stathandlc  \scan_txed_stathndl; \scan_retx_stathndl;  /* Data limout timer event handle */  Temporary Variable Block Packet* PacketsPacket* Packet* int int int /*  pkptr; pkptr_out; pkptr_scan; copy_pkptr; i; scan_num_req; pk_sizc;  int int double  num_rcvd_scans; index; send time;  unforced state init attribute name  value init  tvpe string  default value St  enter execs exit execs  (See below.) (empty)  textlist 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 /* Read object attributes. */  10  loc_mod_objid = op_id_self (); op_ima_obj_attr_get (loc_mod_objid, op_ima_obj_attr_get (loc_mod_objid, op_ima_obj_attr_gct ( l o c _ m o d _ o b j i d , op_ima_obj_attr_get (loc_mod_objid, op_ima_obj_attr_get (loc_mod_objid, op_ima_obj_attr_get ( l o c _ m o d _ o b j i d , op_ima_obj_attr_get ( l o c _ m o d _ o b j i d , op_ima_obj_attr_get ( l o c _ m o d _ o b j i d . op_ima_obj_attr_gct ( l o c _ m o d _ o b j i d , op_ima_obj_attr_get ( l o c _ m o d _ o b j i d , op_ima_obj_attr_get (loc_mod_objid, op_ima_obj_attr_gct (loc_mod_objid,  "start "Number  T i m e " , &starl_timc); of  S c a n s " , &lotal_iium_scans):  0", &local_port_0); 0", & r e m o l c _ p o r t _ 0 ) ; " R e m o t e N o d e 0", & r e m o l e _ n o d e _ 0 ) ; " L o c a l P o r t 1", & ] o c a l _ p o r t _ l ) ; " R e m o t e P o r t 1", & r c m o t c _ p o r t _ l ) ; " R e m o t e N o d e 1", & r e m o l e _ n o d e _ l ) : " L o c a l P o r t 2", &local_port_2); "Local  "Remote  Port  Port  "Remote  Port  "Remote  Node  2", & r e m o l c _ n o d c _ 2 ) ;  &remote_porl_2);  "Remote  Net",  &remote_nel):  2",  15 /* Scan size in bytes in the actual Lena imagefile*/ scan_byte[i] =  20  1595;  scan_byte[2] =  756;  scan_byte[3] =  526;  scan_byte[4] =  1426;  scan_byte[5] = scan_byte[6] scan_byte|7]  536;  =525; =3418;  scan_byte[8] =  25  497;  scan_bytc[9] =  524;  scan_byte[IO]  = 6590;  scan_byte[l 11 =  785;  scan_byte[12] =  524;  scan_bytc[13]= 13485;  30  scan_byte[l4] =  1549;  scan_byte[l5] = scan_byle[l61  523;  = 32677;  scan_byte[17] = scan_byte[18]  35  scan_byte[191 = scan_byte[20]  40  522;  = 43980; 525:  =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,  "udp");  /* The first scan which should be. transmitted in order is Scan 0... */ scari_seq_count =  45  scan_retx_counl =  0; 0;  /*c.heck_seq_count =-1 ;*/ /* At the beginnig. the frame header is not transmitted. */ f r a m e _ h e a d e r = 0;  •  50 /* Don't know the value of the flag at the beginning. */ relx_rq_flag =  -1:  I* Register the local output statistics to obtain the handles */  55  scan_txed_slalhndl = op_stal_reg("Scans T r a n s m i t t e d  in  Order",  OPC_STATJNDEX_NONE, OPC_STAT_LOCAL):  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  112  Thu Oct 01 ,11:45:35 1998  | Page 8 of 14  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++) 60 I scan_buf[i].scanjxed = 0: scan_buf[i].missed_scan = 0; } 65 /* Initalize the retransmission timers */ /*  for(i=0;i<256;i++) rxrq_timer/i].active = 0; 70 timeout_value = 0.0: */  '  /* Initialize the local statistics /*scan_seq_cottnl+ +; */ 75 op_stat_write (scan_L\ed_staihndl. scan_scq_count); op_stat_write (scan_retx_stathndl, scan_retx_count);  */  80 /* Schedule the start of operation. */ op_intrpJ_schedulc_self(slart_lime, IFTPC„CODE_START);  transition attribute  init -> init  name condition executive color drawing style  transition attribute  tr_22 default RGB333 . spline  tvpe  default value  string string string color toggle  tr  init -> open  name condition executive color drawing style  value  tvpe  default value  tr 26 START_UP  string string string color toggle  tr  RGB333 spline  unforced state wait attribute  value  tvpe  name  wait  string textlist textlist toggle  1  enter execs exit execs status  RGB333 spline  (empty) (See below.) unforced  RGB333 spline  default value st ' (empty) unforced  Appendix B Source Code of the Server IFTP Model  Process" Model Report: iftp_server,  113 •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. */  5  pkptr_in = op_pk_get(TNSTRM); 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 name condition executive color drawing style.  transition wait -> wait attribute name condition executive color drawing style  transition wait -> resend attribute name condition executive color drawing style  forced state send attribute name enter execs exit execs status  value tr 2 FILE_REQ R G B 3 3 3  spline  value tr_6  default RGB333  spline  value tr 9 RESEND_REQ RGB333  spline  value send (See below.) (empty) forced  tvpe string string string color toggle  default value tr  tvpe string string string color toggle  default value tr  ' tvpe string string string color toggle  default value tr  tvpe string textlist textlist toggle  R G B 3 3 3  spline  R G B 3 3 3  spline  R G B 3 3 3  spline  default value ~ st (empty) unforced  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  114  Thu Oct 01 11:45:35 1998  enter execs send /* Open: create the new port for imagefiletransfer. */  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 10 if (rcmote_por t_in = 1890) f udp_cmd_ici_ptr = udp_cmd_ici_ptr_2; 15 /*pkptr - opjk_get(lNSTRM): / S1  op_pk_nfd_get (pkptr_in, "scan number", &scan_num_req); 20 i f (scan_num_rcq == 0 && framc_header == 0) (  /* This is a valid imagefiletransfer request. /* First create thefirstscan ScanO and transmit it.  25  30  */ 7  :1  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 */  35  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.  40  45  */  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);  50 /* Update the statistics  scan_scq_cotint++; op_stat_writc (scan_txed_slathndl, scan_seq_count); 55 /* Now send out all the scans in the image file.  for (i=l;i<=total_num_scans;i++)  */  | Page 10 of 14  Appendix B Source Code of the Server IFTP Model  Process Model Report: iflp_server  /*  115  : j h U j ^  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);  60  65  /* 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);  70  /* 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;  75  80  op_ici_install (udp_cmd_ici_ptr); «P_pk_send (pkptr_ou't, OUTSTRM); /* Update the statistics  85  */  scan_seq_count++; op_stat_writc (scan_txed_stathndl, scan_scq_count);  90  1 • frame header = 1; else  95  /* Invalid imagefiletransfer request received. Print */ /* error message. '*/ printf("\n-- The image f i l e server got an i n v a l i d request --\n");  100 /* Destroy the packet for the current request to free memory */ op_pk_dcstroy (pkptr_in);  105  transition send -> wait attribute name condition executive color drawing style  value tr_11  RGB333 spline  tvpe string string string color toggle  default value tr  RGB333 spline  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  forced state resend attribute name enter execs exit execs status  116  Thu Oct 01 11:45:36 1998  value resend (See below.) (empty) forced  tvpe string textlist textlist toggle  1  default value st (empty) unforced  enter execs resend /* First,findout the port for retransmission of image,filetransfer. */  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; 10  )  if (remote_port_in == 1890) I udp_cmd_ici_plr = udp_cmd_ici_plr_2; 15  )  /*pkptr = op _pk_get(lNSTRM);*/  op_pk_nfd_get (pkprr_in, "scan number", &scan_num_roq); 20 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()); •25 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); 30 /* 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(); 35 op_ici_instalI (udp_cnid_ici_plr); op_pk_send (pkptr_oul, OUTSTRM); Update the statistics  40 scan_rctx_count++; op_stat_write (scan_rctx_stalhndl. scan_rctx_counl); /* Destroy the input packet to save memory. '*/  */  | Page 12 of 14  Appendix B Source Code of the Server IFTP Model  Process Model Report: iftp_server  117  Thu Oct 01 11:45:36 1998  | Page 13 of 14  op_pk_destroy(pkptr_in); 45  transition resend -> wait attribute' name condition executive color drawing style  forced state open attribute name enter execs exit execs status  value tr_4  default value tr  RGB333 spline  tvpe string string string color toggle  value open (See below.) (empty) forced  tvpe string textlist textlist toggle  default value st  enter execs open /* 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); 10 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); 20 op_ici_install (udp_cmd_ici_plr_l); , 15  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); 30 op_ici_install (udp_c md_ici_ptr_2);  25  RGB333 spline  (empty) unforced  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 name condition executive color drawing style  value tr_28  RGB333 spline  tvpe string string string color toggle  default value tr  RGB333 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