1

INTRODUCTION

Automatic-Repeat-reQuest (ARQ) is an error control technique widely used in digital data

transmission. An ARQ system corrects erroneously received packets through retransmission of

packets. after which three classical ARQ schemes (or protocols) have been developed: stop-and-wait

(SW-ARQ), go-back-N (GBN-ARQ), and selective-repeat (SR-ARQ). In terms of the open system

interconnection (OSI) reference model for layered network architectures, an ARQ protocol is usually

located at the link layer (i.e., layer 2). Below and above it are the physical layer (or layer 1) and the

network layer (or layer 3), respectively. From the ARQ’s point of view, the physical layer provides

forward channels (for data packets from the transmitter to the receiver) and feedback channels (for

acknowledgement messages from the receiver to the transmitter), while the network layer

provides/receives data packets. The transmitter sends packets to the receiver, which generates either a

positive acknowledgement (ACK) or a negative acknowledgement (NACK) for each received packet

based on the error detection result. Error detection is implemented by using a high-rate cyclic

redundancy check (CRC) error-detection code. In SW-ARQ, the transmitter sends a packet to the

receiver and waits for its acknowledgement. Upon receiving a packet, the receiver generates either an

NACK or an ACK for the received packet and sends it over a feedback channel. If an ACK is

received, the transmitter sends out the next packet; otherwise, if an NACK is received, retransmission

of the same packet will be scheduled immediately, and this process continues until the packet is

positively acknowledged. In GBN-ARQ, the transmitter sends packets to the receiver continuously

and receives acknowledgements as well. When an NACK is received, the transmitter retransmits the

negatively acknowledged packet immediately and all following packets (positively or negatively

acknowledged) already transmitted. In SR-ARQ [5], the transmitter sends packets continuously until

an NACK arrives at the transmitter, in which case the transmitter retransmits the negatively

acknowledged packet without re-sending the transmitted packets following it. To preserve the original

arriving order of packets at the receiver in SR-ARQ, a buffer, referred to as the resequencing buffer, is

provided at the receiver to store the correctly received packets that have not been released to the upper

layer.

An ARQ scheme plays such an important role in digital data transmission. ARQ continues to

[7] be a classical research area, which can be dated back to the 1960s. Many studies on ARQ reported

in the last century have been based on the assumption that the error probability of packets does not

change over time (i.e., the time-invariant or iid model of packet errors). This assumption is realistic

for a satellite communicate on system, which was one of the originally proposed application areas of

ARQ, and has been extensively used for modeling and analysis of ARQ protocols. With the

2

introduction of the third-generation wireless networks in the 1990s, data integrated with voice

services have been provided over mobile wireless links. Since ARQ protocols achieve reliable

transmission of packets over intrinsically unreliable wireless links, they have been used in the current

and future generation wireless networks with the aim being the provisioning of multimedia services.

In reality, the transmission condition of a wireless channel changes over time due to multi-path

fading, scattering, and shadowing. Consequently, a wireless channel is often severely affected by

time-varying errors or losses of packets. That is, the probability that packets, when transmitted over a

wireless channel, are erroneously received or simply lost, varies over time and these probabilities at

different time instants may be correlated (i.e., the error burstiness). To reflect the Quality of Service

(QoS) of a wireless system with ARQ, different packet error models (e.g., a finite state Markov chain

model) have been employed for modeling and analysis of ARQ protocols. The above mentioned

studies have shown that analysis simply based on an iid model of packet errors cannot give rise to a

true QoS of a wireless data network with ARQ due to the non-realistic assumption, confirmed that the

throughput performance of ARQ protocols for a Markov channel is better than that for a static

channel,showed that, when a Bernoulli packet arrival process is assumed, the mean transport delay

(the duration from the time a packet arrives at the transmitter until its successful reception by the

receiver) of SR-ARQ over a Markov channel is up to 100% longer than that of SR-ARQ over a static

channel reported that the mean packet delay (the duration from the time a packet is first time

transmitted until its in-sequence delivery to the upper layer) of SRARQ over a static channel can be

up to 100% longer than that of SR-ARQ over a Markov channel, when the transmitter is saturated

with packets. All these results have shown that, an iid model, which neglects the time-varying

property and the error burstiness in packet errors (and losses), is a misleading assumption for a time-

varying channel in terms of the performance (e.g., throughput and delay) of ARQ protocols. It is

worthwhile to point out that, Rayleigh fading model, which describes how the signal propagates

through the wireless medium, is a very popular channel model adapted in studies at the physical layer.

Previous studies,have used finitestate Markov chains to model Rayleigh fading channels. It is shown

that a Markov process can be used to characterize the erroneous behavior of a Rayleigh fading

channel and the accuracy of Markov models grows with the number of states used. This brings to

researchers the theoretical basis through which relatively simple Markov chain models have been

applied to the performance analysis of protocols in a higher layer, such as studies mentioned above in

the link layer or in the TCP layer. This also motivates us to study SW-ARQ over multiple Markov

channels.

Unlike packet transmission over a single channel, in a multichannel communication system,

multiple packets are sent simultaneously, i.e., one packet per channel, and packet transmission errors

could occur across every channel. To implement error control through retransmission of packets in a

multichannel communication system, ARQ protocols have been generalized to allow concurrent

transmission of multiple packets and are becoming integral parts of wireless data services in High

3

Speed Downlink Packet Access and in WiMax. Among the three classical ARQ protocols (SW-ARQ,

GBN-ARQ, SR-ARQ), SWARQ requires the least overhead and is the simplest one to implement.

Since the transmitter remains idle during the round-trip propagation delay (RRT) for the packet, SW-

ARQ is more suitable for short-distance communication systems. In real-life implementations, SW-

ARQ has been standardized in the specification of Bluetooth for single-channel communications, and

is expected to be part of the standard for high-speed Bluetooth technology in a multichannel

communication environment. Another example is the adoption of SW-ARQ over multiple channels in

to achieve a compatible system throughput performance with SR-ARQ. A communication system

using SW-ARQ over multiple channels is also proposed in patent.

Unlike studies on ARQ protocols for single-channel communications, only a limited number

of publications are available on multichannel ARQ protocols. Chang and Yang studied performance

of the three classical ARQ protocols for multiple identical channels (i.e., all channels have the same

transmission rate and the same time-invariant error rate). In that study, expressions for the throughput,

which is the average number of packets successfully transmitted per unit of time, and the mean

transmission delay, which is the average time between the instant at which a packet is transmitted for

the first time and the instant at which it is successfully received, have been derived. Meanwhile, Wu

and Vassiliadis and Chung conducted a throughput performance study on multichannel ARQ

protocols based on the same model as that in. The resequencing issue in multichannel ARQ protocols

was first addressed by Shacham and Chin. In that study, they conducted a resequencing analysis (e.g.,

the resequencing buffer occupancy and the resequencing delay) for SR-ARQ over parallel channels,

all of which have the same transmission rate but possibly different time-invariant error rates. The

authors in analyzed the packet delay distribution function of GBN-ARQ for a generic number of

parallel channels, each of which has the same transmission rate but a possibly different fixed error

rate. Recently, Ding and Rice, considered ARQ protocols for parallel channels, each having unique

transmission rate and error rate. An optimal packet scheduling rule has been identified and an

expression for system throughput has been derived in. Analyzed the throughput performance of SW-

ARQ for multiple channels in HSDPA using simulation. Ding derived an approximate expression of

the mean packet delay for multichannel ARQ protocols. Evaluated the system throughput

performance of SR-ARQ for multiple time-varying channels through simulation analysis.

From the above discussion, it is clear that SW-ARQ for multiple channels has important real-

world applications, but exact analysis of multichannel SW-ARQ models is very limited, which

motivated the research in this thesis in one part. Moreover, all above mentioned studies on

multichannel ARQ protocols have been based on the assumption of a time-invariant error rate for each

channel except, in which only simulation analysis has been conducted. Similar to studies in the

context of single-channel communications, we expect that these results based on time-invariant error

rates of channels may not reflect the true QoS of a communication system containing multiple

4

wireless channels characterized by time-varying packet errors. There has been no study reported in the

literature for a systematical analysis of a multichannel ARQ model characterizing time-varying packet

errors, although studies, on ARQ for a single channel of time-varying models have been extensively

conducted. This motivated another part of the thesis research. Through the thesis research, we not

only extend early studies on ARQ protocols for multiple channels with time-invariant error rates, but

also generalize the results in published works on ARQ protocols for single time-varying channels

(e.g., Markov channels). It is worthwhile to point out that hybrid-ARQ, in which an erroneously

received packet is corrected by a combination of ARQ and forward-error-correction (FEC), for

multiple time-varying channels, has also received an increasing research attention recently, for

instance, studies in. While having the impetus to improve the throughput performance of fading

MIMO systems, these studies have been conducted from the coding perspective at the physical layer,

which is not within the scope of this project.

5

LITERATURE SURVEY

2.1 EXISTING SYSTEM

Reliable transmission of packets over intrinsically unreliable channels such as lossy wireless

links, they have been extensively used in the next-generation wireless packet data networks to provide

high-speed data integrated with voice services.

2.2 A Multichannel System with ARQ Error Control

A multichannel data communication system, in which a transmitter-receiver pair

communicates data packets for one communication (e.g., a large-size video file transfer), is illustrated

in Fig. 1. The communication link connecting the transmitter and the receiver consists of M (M ≥ 2)

parallel channels numbered from 1 to M, each of which is characterized by a data transmission rate

and a channel model. The transmission rate of a channel is measured by the maximum number of

packets that can be transmitted over that channel during a specified time period, while the channel

model, or the model of packet errors[4], describes the statistical property of transmission errors of

packets when they are transmitted over the channel. In this study, two channel models will be

considered with the assumption that packet errors occurring in different channels are mutually

independent. A feedback channel is also provided in the system. We assume that an erroneous packet

can always be detected through CRC coding and that the feedback channel is error-free for

transmitting acknowledgement packets,[1].

6

Each packet to be transmitted is identified by a unique integer number, referred to as the

sequence number. We assume that there is a buffer in the transmitter, referred to as the transmission

queue, in which infinitely many packets are waiting according to their sequence numbers[6] for first-

in-first-out transmission and retransmission. That is, there are always packets in the system to be

transmitted, which in related studies is referred to as the heavy traffic condition. We also assume that

all channels have the same transmission rate, and that the M channels are time-slotted with one unit

(or slot) equal to the transmission time of a packet over a channel. Therefore, the transmission rate of

each channel is one packet per slot. All packets, when transmitted from the transmitter to the receiver,

have a fixed round trip time (RRT) equal to (m − 1) slots, which is assumed to be an even number of

slots. (Therefore, m slots represent the sum of the transmission time and RTT of a packet.) A packet

experiences the same propagation delay in forward and feedback channels, which is (m−1)/2 slots.

Once packet transmission starts, the transmitter sends multiple packets at a time, one per channel. All

channels share the same set of sequence numbers of the packets in packet-to-channel scheduling. A

multichannel ARQ model, which is to be described in the next chapter, is used in the system for

packet error control.

2.2.1 Channel Models A channel model, or a model of packet errors, defines the statistical property of transmission

errors when packets are transmitted over a physical channel. We consider two models of packet

errors, iid model and Markov model, for this study[2], [7].

2.2.2 The iid Model In the case of an iid model, the transmission error of a packet when it is transmitted over the

channel is characterized by a time-invariant error rate representing the probability that the packet is

erroneously received or simply lost. [2]

2.2.3 The Markov Model In the Markov model, the packet error property over the Markov channel is characterized by

the Gilbert-Elliott model, in which the state of the channel is modeled as a two-state Markov chain

{E(t) : t = 0, 1,….}. The state space of the Markov chain {E(t) : t = 0, 1,….} is {GOOD,BAD}and the

transition matrix of the Markov chain {E(t) : t ≥ 0} is, [2], [7], [11]

7

The packet error rate when the channel is in “GOOD” is eG, and the packet error rate corresponding

to “BAD” is eB. We let 0 ≤ eG < eB ≤ 1, since the case where eG = eB corresponds to an iid model

with the error rate eG.

The Markov chain {E(t) : t ≥ 0} has the stationary distribution given by

For the Gilbert-Elliott model, we define the following parameters

The two pairs of parameters (χ, σ) and (α, β) are uniquely determined by each other. In steady state,

the stationary distribution of the error process {E(t) : t ≥ 0} can be re-written as

(σ, 1 − σ).

2.3 Multichannel SW-ARQ Models

In this section, we describe two stochastic systems for modeling multichannel SW-ARQ,

which are MSW-ARQ and MSW-ARQ-inS. The following error control procedure is valid for both

models, while different actions are discussed in Section 3.1.1 for MSW-ARQ and in Section 3.1.2 for

MSW-ARQ-inS.

1. At the beginning of a slot tm, t = 0, 1… (is illustrated in Fig. 2), the transmitter starts transmitting a

block of M packets to the receiver, and completes transmission at the end of the slot. Before the

transmitter sends the next block of M packets in slot (t + 1)m, it is idle.

2. The receiver receives the block of M packets at the end of slot tm+(m−1)/2. The packet transmitted

over channel i is received erroneously or simply lost according to the packet error model

corresponding to channel i. Which packet error model for the channel is used will be specified when

analysis is performed in the following chapters. After the error detection, the receiver sends an

acknowledgement packet, which contains exactly M acknowledgements (ACKs/NACKs)

corresponding to the most recently received block of M packets, to the transmitter. We assume that

8

error detection and transmission of acknowledgement packets take no time at the receiver, so that they

are both completed at the end of slot tm + (m − 1)/2.

3. After sending the acknowledgement packet, the receiver takes different actions on the M packets, a

for MSW-ARQ and for MSW-ARQ-inS. The transmitter receives the acknowledgement packet at the

end of slot (tm + m − 1). It checks each acknowledgement in the acknowledgement packet, and

prepares the next block of M packets to transmit according to rules to be stated for MSW-ARQ and in

for MSW-ARQ-inS.

4. To transmit the next block of M packets in slot (t + 1)m, a packet-to-channel scheduling policy

needs to be specified. There are two packet scheduling policies, the static scheduling and the dynamic

scheduling, to be considered in this study. For the static scheduling, an old packet (i.e., a packet to be

retransmitted) is always retransmitted over the same channel as the originally assigned one, and new

packets selected to be transmitted are randomly assigned to the channels available for transmitting

new packets. With the dynamic scheduling, the transmitter assigns the packet with the smallest

sequence number (either an old unqualified or a new packet) in the block to channel 1, the packet with

the second smallest sequence number to channel 2, and so forth [6].

5. We assume that the transmitter completes acknowledgement checking and preparation of the next

block to transmit instantaneously. Then, the transmitter starts transmitting the next block of M packets

at the beginning of slot (t + 1)m and completes transmission at the end of the slot. As described above,

the different actions between MSW-ARQ and MSW-ARQ-inS are those in item 3, which are

discussed in detail below.

2.3.1 MSW-ARQ A qualified packet is a correctly received packet with a sequence number such that all packets

with a smaller sequence number have been correctly received. After sending the acknowledgement

packet at the end of slot (tm + (m − 1)/2), the receiver delivers all qualified packets to the upper layer

and discards all unqualified packets received. The transmitter prepares the next block of M packets to

transmit in slot (t + 1)m according to the following rule: if no NACK is contained in the

acknowledgement packet, the next block to transmit is composed of M (new) packets that will be

transmitted for the first time; if the acknowledgement packet contains one or more NACKs, however,

the next block ofM packets contain those (old) unqualified and possibly new packets. MSW-ARQ

with the dynamic scheduling for three time-invariant channels with p1 ≤ p2 ≤ p3, where pi ∈ (0, 1)

represents the error rate for channel i.

9

Fig.2. MSW-ARQ (M=3, m=5)

2.3.2 MSW-ARQ-inS

In MSW-ARQ-inS, which is a variant of MSW-ARQ, the transmitter retransmits only

erroneously received packets. In order to achieve packets’ delivery in the order of their sequence

numbers (i.e., in-sequence delivery), a resequencing buffer is provided at the receiver to temporarily

store undeliverable packets. An undeliverable packet is a correctly received but unqualified packet

(i.e., there is another packet with a smaller sequence number, which has not been received correctly so

far). After sending the acknowledgement packet at the end of slot (tm + (m − 1)/2), the receiver

discards erroneously received packets and stores correctly received ones in the resequencing buffer.

Then, it delivers all qualified packets, from the resequencing buffer to the upper layer, and continues

storing undeliverable packets for future delivery. The transmitter prepares [12]the next block of M

packets to transmit in slot (t+ 1)m according to the following rule: if there is no NACK in the

acknowledgement packet, the next block to transmit is composed of M new packets; if the

acknowledgement packet contains one or more, for example k, NACKs, the next block onM packets

consist of those k old packets, which are negatively acknowledged by the receiver, andM −k new

packets. An example of MSWARQ- inS with the dynamic scheduling for three time-invariant

channels with p1 ≤ p2 ≤ p3, where pi ∈ (0, 1) represents the error rate for channel i.

Fig.3 MSW-ARQ-inS (M=3, m=5)

10

2.3.3 Study Objective and Performance Metrics

With the settings described above, both MSW-ARQ and MSW-ARQ-inS implement error

control while packets are delivered to the upper layer in the order of their sequence numbers (or in-

sequence delivery). However, the performance, such as throughput and delay, of one model is

different from the other model, and thus it needs to be investigated under various channel conditions.

The main purpose of this study is to carry out steady-state analysis of the two multichannel SW-ARQ

models when they are used for error control. We establish a new method used to evaluate the packet

delay performance of the multichannel SW-ARQ models, conduct a resequencing analysis for MSW-

ARQ-inS, and identify the impact of packet scheduling policies on the model performance through

numerical and simulation analysis.

In our steady-state analysis of the MSW-ARQ model, the performance metric is the packet

delay. The delay of a packet is defined as the amount of time between the instant at which the packet

is transmitted for the first time and the instant at which it is delivered to the upper layer.

In the performance analysis of the MSW-ARQ-inS model, in addition to the analysis of the

packet delay for the model, analysis of the resequencing buffer is also conducted. The resequencing

buffer is analyzed through deriving statistical properties of resequencing buffer occupancy and

resequencing delay in the equilibrium regime. The resequencing buffer occupancy is the number of

packets waiting in the resequencing buffer for delivery. The resequencing delay of a packet is defined

as the amount of waiting time of the packet in the resequencing buffer. In MSW-ARQ-inS, we use

transmission delay to denote the time period from the instant at which a packet is transmitted for the

first time until its correct receipt by the receiver. Then the packet delay is the sum of the transmission

delay and the resequencing delay[9].

2.4. Analysis for Time-invariant Channels

In this section, we investigate statistical properties of the resequencing buffer occupancy and

the resequencing delay when the time-invariant error model (i.e., the iid model) of channels is

assumed. That is, the error rate for channel i, for i = 1,…,M, is pi ∈ (0, 1), and pi might be different

from pj for i _= j.

Without loss of generality, the M channels are numbered from 1 to M such that p1 ≤ p2 ≤

….≤ p M. The dynamic scheduling is implemented as follows[8]. To send the next block of M packets

in slot (t + 1)m, the transmitter assigns the packet with the smallest sequence number in the block to

channel 1, then the packet with the second smallest sequence number to channel 2, and so forth.

11

We denote by C an arbitrary packet of our interest and let slot 0 represent the slot at the end of which

C is received for the first time. Given that C is received for the first time over channel i, for i = 1,.. ,M,

we define the following two random variables for each t = 0, 1,….. 1. Xi(t) is the number of packets,

in the block of M packets received at the end of slot tm, whose sequence numbers are not larger than

that associated with C.

2. Yi(t) is the number of packets, in the block of M packets received at the end of slot tm, whose

sequence numbers are not larger than that associated with C, if C is contained in the block, and zero

otherwise. The stochastic processes {X2(t) : t = 0, 1,…} and {Y2(t) : t = 0, 1,…} are

illustrated in Figure 4. Moreover, both process {XM(t) : t = 0, 1,…} and process

Fig 4. Processes {Xi(t) : t ≥ 0} and {Yi(t) : t ≥ 0} (M=3, m=5)

{YM(t) : t = 0, 1,…} are Markov chains with the same state space {0, 1,…,M}.

We define

qk = 1− pk, k = 1,… ,M, (4.1)

and

Ωi = {1,… , i}. (4.2)

Then we let Bi,j denote a subset of Ωi of size j, and Bc i,j = Ωi \ Bi,j . The product over an empty set Φ

is defined to be one, i.e.,

12

Where

for i = 1,… ,M and j = 0,… , i. The transition matrix of the Markov chain {YM(t) : t = 0, 1,…} is

given by

Where

ij iQ p

For we note that the upper - left sub matrix of P , which is lower triangular, is

the transition matrix of the Markov chain This implies that for in the state space of the

Markov chain . This implies that for j, l in the state space of the Markov chain

Where is in nth step transition probability from I to l of the Markov chain

This is also true for the Markov chain {XM(t) : t ≥ 0}. As illustrated, the constructed markov chains

are used to an analyze the resequencing buffer occupancy and the resequencing delay in steady state.

10 11

20 21 22

,0 ,1 ,2 ,

1 0 0 00 0

0

M M M M M

p pp p pP

p P p p

, ,. ci i j i j

ijBi j k B k B

P pk qk

1 1

2 21 22

1 ,2 ,

1 0 0 00 0

1 00 (4)

M M M M

q pq q qQ

q T

qm Q Q Q

1, 1 1, 1ci i ik B k B j

pk qk

2,..., 1,.... .i M and i i

: 0 .iX t t

: 0iX t t

( )i iX t n X t j ( ) nM i jlX t n X t j p

njlP : 0iX t t

13

2.4.1 Resequencing Delay

With the construction of Markov chain {XM(t) : t ≥ 0}, the probability that C is transmitted

for the first time over channel i, for i = 1,..,M, is given in the following lemma[7].

2.5. Analysis for Markov Channels

In this section, we analyze the distribution function of the resequencing buffer occupancy and

the mean resequencing delay for Markov channels. That is, the packet error property of channel i, for i

= 1,… ,M, is characterized by the error process {Ei(k) : k ≥ 0}, which is a two-state discrete-time

Markov chain. k represents the very beginning of slot km. The M error processes are mutually

independent and have the same state space and transition matrix, respectively. We assume that, before

the transmission of a block of M packets, which occurs during kth step (or in slot km), the transmitter

knows the realizations (or observed values) of the random variables Ei(k), for[8], [6]

i = 1,… ,M. The dynamic scheduling works as follows. The transmitter counts the number, referred to

as L, of channels whose states at step t + 1 are in “GOOD”. If L is either zero or M (i.e., all channels

are in a same state), each packet of the M packets for transmitting at step t + 1 is randomly (i.e., with

probability 1/M) assigned to a channel; otherwise (i.e., L is between 0 and M), the transmitter assigns

each of the packets with sequence numbers being the first L smallest in the block of M packets, to a

channel, whose state is in “GOOD”, and assigns the rest (M − L) packets to the channels with states

being in “BAD”. We let Co be the packet that has the smallest sequence number in the block of M

packets to be received at the end of the slot of observing the resequencing buffer, and then let Br and

An have the same definitions as given in Section 4.1. If A0 is true, the resequencing buffer is empty at

the observation instant. When An is true for n ≥ 1, we denote by nm the slot at the end of which Co is

received for (n + 1)st time, and by Br,n the resequencing buffer occupancy. For each t = 0,…, n, we

define X(t) as the number of packets, in the block of M packets received at the end of slot tm, which

have a sequence number smaller than that associated with Co, and Y (t) as the number of channels

whose states are in “BAD” at step t. Clearly, X(t) is a {0, 1,…,M − 1}-valued random variable and Y

(t) is a {0, 1,… ,M}-valued random variable. Furthermore, the process {(X(t), Y (t)) : t = 0, 1,…n} is

a Markov chain with the state space

2.5.1 Packet Delay Analysis

In this chapter, we derive the distribution function of the packet delay for MSW-ARQ and

MSW-ARQ-inS, respectively, when an iid model is assumed for each channel. Based on the analysis,

we present numerical and simulation result. The main results presented in this chapter have been

14

summarized in for publication. Our analysis is under the condition that the system is in equilibrium

regime. From the system settings, the condition under which the system enters equilibrium regime is

trivially satisfied. Also, our steady-state analysis is based on the dynamic scheduling (simulation

results for the static scheduling will be presented in Section 5.3 for performance comparisons) and the

assumption that each channel assumes an iid model for packet errors. The assumption means that a

time-invariant error rate pi, which is the probability that a packet is received erroneously by the

receiver or simply lost, corresponds to channel i, for i = 1,… ,M, and pi might be different from pj for

i _= j. A special case of the MSW-ARQ model for which p1 = …= pM was addressed in for the mean

packet delay analysis by using a direct probabilistic argument not appropriate for a general model.

Recently, the MSW-ARQ model studied in this chapter was considered and an approximate

expression of the mean packet delay was obtained. However, the approximation can significantly

deviate from the true result as the error rates become relatively large according to a simulation.

Compared to the throughput, which is defined as the average number of packets successfully

transmitted per slot and given in as [4], [7].

where pM+1 = 1, and qi = 1− pi, i= 1,…,M,

the packet delay is usually a more demanding performance metric. 2.5.2 Packet Delay Of Msw-Arq

In this section, steady-state analysis of the packet delay is performed for MSW-ARQ using

the dynamic scheduling. Without loss of generality, the M channels are numbered from channel 1 to

M such that p1 ≤ p2 ≤ … ≤ pM.

In steady state, we denote by C* an arbitrary packet of interest and let slot 0 represent the slot

at the end of which the receiver receives C* for the first time. We denote by Λi the event that C* is

received over channel i for the first time, for i = 1,… ,M, and D the packet delay of C*.

Provided that event Λi occurs, we define Xi(t) to be the number of packets, in the block of M

packets received at the end of slot tm, whose sequence numbers are not larger than that associated

with C*, for t = 0, 1,…. An example of the stochastic process {X3(t) : t ≥ 0} is shown in Figure 5.1.

15

Fig. 5. Process {X3(t) : t ≥ 0} (M=3, m=5)

The stochastic process {Xi(t) : t = 0, 1,…} is a Markov chain with the state space {0, 1,… , i}.

The initial state of the Markov chain {Xi(t) : t = 0, 1,…} is i with probability one, i.e.,

Xi(0) = i, i = 1,…,M. [4], [7]

This is because, if channel i is assigned to transmit C*, then all packets assigned to channels 1 to i − 1

have a sequence number smaller than that associated with C*. Also, the Markov chain {Xi(t) : t = 0, 1,

…} eventually enters state 0 and then stays in that state forever. Therefore, the Markov chain {Xi(t) : t

= 0, 1,…} is transient with absorbing state 0 and transient states 1,.., i. We define the product over an

empty set Φ to be one,

Since the event {Xi(t) = j} is equivalent to the fact that C* is received in slot tm over channel j (i.e.,

packets received over channel 1 to j in slot tm have sequence numbers no larger than that associated

with C∗), given that C∗ is received for the first time over channel i,

SOLUTION OF THESE PROBLEMS Unlike packet transmission over a single channel, in a multichannel communication system, multiple

packets are sent at a time, one packet per channel, and packet transmission errors can occur across

every channel. To implement error control through retransmission of packets in a multichannel

communication system, an ARQ protocol has been generalized to allow concurrent transmission of

multiple packets.

16

3. DESIGN

3.1 System Analysis

INTRODUCTION

After analyzing the requirements of the task to be performed, the next step is to analyze the

problem and understand its context. The first activity in the phase is studying the existing system and

other is to understand the requirements and domain of the new system. Both the activities are equally

important, but the first activity serves as a basis of giving the functional specifications and then

successful design of the proposed system. Understanding the properties and requirements of a new

system is more difficult and requires creative thinking and understanding of existing running system

is also difficult, improper understanding of present system can lead diversion from solution.

3.1.2. ANALYSIS MODEL

The model that is basically being followed is the WATER FALL MODEL, which states that

the phases are organized in a linear order. First of all the feasibility study is done. Once that part is

over the requirement analysis and project planning begins. If system exists one and modification and

addition of new module is needed, analysis of present system can be used as basic model.

The design starts after the requirement analysis is complete and the coding begins after the

design is complete. Once the programming is completed, the testing is done. In this model the

sequence of activities performed in a software development project are: -

Requirement Analysis

Project Planning

System design

Detail design

Coding

Unit testing

System integration & testing

Here the linear ordering of these activities is critical. End of the phase and the output of one

phase is the input of other phase. The output of each phase is to be consistent with the overall

requirement of the system. Some of the qualities of spiral model are also incorporated like after the

people concerned with the project review completion of each of the phase the work done.

17

WATER FALL MODEL was being chosen because all requirements were known beforehand

and the objective of our software development is the computerization/automation of an already

existing manual working system shown in Fig 1.

Fig: 6 WATER FALL MODEL

3.1.3 STUDY OF THE SYSTEM

GUI’S

In the flexibility of the uses the interface has been developed a graphics concept in mind,

associated through a browser interface. The GUI’S at the top level have been categorized as

1. Administrative user interface

2. The operational or generic user interface

Communicated Requirements

Requirements Specification

Design Specification

Executable Software Modules

Integrated Software Product

Delivered Software Product

Changed Requirements

Requirements Engineering

Design

Programming

Integration

Delivery

Maintenance

Product Product Input Output

Process

18

The administrative user interface concentrates on the consistent information that is practically,

part of the organizational activities and which needs proper authentication for the data collection. The

interfaces help the administrations with all the transactional states like Data insertion, Data deletion

and Date updation along with the extensive data search capabilities.

The operational or generic user interface helps the users upon the system in transactions

through the existing data and required services. The operational user interface also helps the ordinary

users in managing their own information helps the ordinary users in managing their own information

in a customized manner as per the assisted flexibilities.

19

3.2 SOFTWARE REQUIREMENT SPECIFICATION

3.2.1 INTRODUCTION

Purpose: The main purpose for preparing this document is to give a general insight into the analysis

and requirements of the existing system or situation and for determining the operating characteristics

of the system.

Scope: This Document plays a vital role in the development life cycle (SDLC) and it describes the

complete requirement of the system. It is meant for use by the developers and will be the basic during

testing phase. Any changes made to the requirements in the future will have to go through formal

change approval process.

3.2.2 DEVELOPERS RESPONSIBILITIES OVERVIEW:

The developer is responsible for:

1) Developing the system, which meets the SRS and solving all the requirements of the system?

2) Demonstrating the system and installing the system at client's location after the acceptance

testing is successful.

3) Submitting the required user manual describing the system interfaces to work on it and also

the documents of the system.

4) Conducting any user training that might be needed for using the system.

5) Maintaining the system for a period of one year after installation.

20

3.2.3 FUNCTIONAL REQUIREMENTS:

3.2.3(a) OUTPUT DESIGN

Outputs from computer systems are required primarily to communicate the results of

processing to users. They are also used to provides a permanent copy of the results for later

consultation. The various types of outputs in general are:

External Outputs, whose destination is outside the organization.

Internal Outputs whose destination is with in organization and they are the

User’s main interface with the computer.

Operational outputs whose use is purely with in the computer department.

Interface outputs, which involve the user in communicating directly with

3.2.3(b) OUTPUT DEFINITION

The outputs should be defined in terms of the following points:

Type of the output

Content of the output

Format of the output

Location of the output

Frequency of the output

Volume of the output

Sequence of the output

It is not always desirable to print or display data as it is held on a computer. It should be

decided as which form of the output is the most suitable.

For Example

Will decimal points need to be inserted

Should leading zeros be suppressed.

21

3.2.3(c) OUTPUT MEDIA:

In the next stage it is to be decided that which medium is the most appropriate for the output.

The main considerations when deciding about the output media are:

The suitability for the device to the particular application.

The response time required.

The location of the users

The software and hardware available.

Keeping in view the above description the project is to have outputs mainly coming under the

category of internal outputs. The main outputs desired according to the requirement specification are:

The outputs were needed to be generated as a hot copy and as well as queries to be viewed on the

screen. Keeping in view these outputs, the format for the output is taken from the outputs, which are

currently being obtained after manual processing. The standard printer is to be used as output media

for hard copies.

3.2.3(d) INPUT DESIGN

Input design is a part of overall system design. The main objective during the input design is as

given below:

To produce a cost-effective method of input.

To achive the highest possible level of accuracy.

To ensure that the input is acceptable and understood by the user.

3.2.3(e) INPUT STAGES:

The main input stages can be listed as below:

Data recording

Data transcription

Data conversion

Data verification

Data control

Data transmission

Data validation

Data correction

22

3.2.3(f) INPUT TYPES:

It is necessary to determine the various types of inputs. Inputs can be categorized as follows:

External inputs, which are prime inputs for the system.

Internal inputs, which are user communications with the system.

Operational, which are computer department’s communications to the system?

Interactive, which are inputs entered during a dialogue.

3.2.3(g) INPUT MEDIA:

At this stage choice has to be made about the input media. To conclude about the input media

consideration has to be given to;

Type of input

Flexibility of format

Speed

Accuracy

Verification methods

Rejection rates

Ease of correction

Storage and handling requirements

Security

Easy to use

Portability

Keeping in view the above description of the input types and input media, it can be said that

most of the inputs are of the form of internal and interactive. As

Input data is to be the directly keyed in by the user, the keyboard can be considered to be the most

suitable input device.

3.2.3(h) ERROR AVOIDANCE

At this stage care is to be taken to ensure that input data remains accurate form the stage at

which it is recorded upto the stage in which the data is accepted by the system. This can be achieved

only by means of careful control each time the data is handled.

23

3.2.3(i) ERROR DETECTION

Even though every effort is make to avoid the occurrence of errors, still a small proportion of

errors is always likely to occur, these types of errors can be discovered by using validations to check

the input data.

3.2.3(j) DATA VALIDATION

Procedures are designed to detect errors in data at a lower level of detail. Data validations

have been included in the system in almost every area where there is a possibility for the user to

commit errors. The system will not accept invalid data. Whenever an invalid data is keyed in, the

system immediately prompts the user and the user has to again key in the data and the system will

accept the data only if the data is correct. Validations have been included where necessary.

The system is designed to be a user friendly one. In other words the system has been

designed to communicate effectively with the user. The system has been designed with pop up

menus.

3.3 USER INTERFACE DESIGN

It is essential to consult the system users and discuss their needs while designing the user

interface:

3.3.1 USER INTERFACE SYSTEMS CAN BE BROADLY CLASIFIED AS:

1. User initiated interface the user is in charge, controlling the progress of the user/computer

dialogue. In the computer-initiated interface, the computer selects the next stage in the

interaction.

2. Computer initiated interfaces

In the computer initiated interfaces the computer guides the progress of the user/computer

dialogue. Information is displayed and the user response of the computer takes action or displays

further information.

24

3.3.2 USER_INITIATED INTERGFACES

User initiated interfaces fall into tow approximate classes:

1. Command driven interfaces: In this type of interface the user inputs commands or queries which

are interpreted by the computer.

2. Forms oriented interface: The user calls up an image of the form to his/her screen and fills in the

form. The forms oriented interface is chosen because it is the best choice.

3.3.3 COMPUTER-INITIATED INTERFACES

The following computer – initiated interfaces were used:

1. The menu system for the user is presented with a list of alternatives and the user chooses one; of

alternatives.

2. Questions – answer type dialog system where the computer asks question and takes action based

on the basis of the users reply.

Right from the start the system is going to be menu driven, the opening menu displays the

available options. Choosing one option gives another popup menu with more options. In this way

every option leads the users to data entry form where the user can key in the data.

3.3.4 ERROR MESSAGE DESIGN:

The design of error messages is an important part of the user interface design. As user is

bound to commit some errors or other while designing a system the system should be designed to be

helpful by providing the user with information regarding the error he/she has committed.

This application must be able to produce output at different modules for different inputs.

25

3.4 DATA FLOW DIAGRAMS

3.4.1 INTRODUCTION

Software design sits at the technical kernel of the software engineering process and is applied

regardless of the development paradigm and area of application. Design is the first step in the

development phase for any engineered product or system. The designer’s goal is to produce a model

or representation of an entity that will later be built. Beginning, once system requirement have been

specified and analyzed, system design is the first of the three technical activities -design, code and test

that is required to build and verify software.

The importance can be stated with a single word “Quality”. Design is the place where quality

is fostered in software development. Design provides us with representations of software that can

assess for quality. Design is the only way that we can accurately translate a customer’s view into a

finished software product or system. Software design serves as a foundation for all the software

engineering steps that follow. Without a strong design we risk building an unstable system – one that

will be difficult to test, one whose quality cannot be assessed until the last stage.

During design, progressive refinement of data structure, program structure, and procedural

details are developed reviewed and documented. System design can be viewed from either technical

or project management perspective. From the technical point of view, design is comprised of four

activities – architectural design, data structure design, interface design and procedural design.

3.4.2. DATA FLOW DIAGRAMS

A data flow diagram is graphical tool used to describe and analyze movement of data through

a system. These are the central tool and the basis from which the other components are developed.

The transformation of data from input to output, through processed, may be described logically and

independently of physical components associated with the system. These are known as the logical

data flow diagrams. The physical data flow diagrams show the actual implements and movement of

data between people, departments and workstations. A full description of a system actually consists

of a set of data flow diagrams. Using two familiar notations Yourdon, Gane and Sarson notation

develops the data flow diagrams. Each component in a DFD is labeled with a descriptive name.

Process is further identified with a number that will be used for identification purpose. The

development of DFD’S is done in several levels. Each process in lower level diagrams can be broken

down into a more detailed DFD in the next level. The lop-level diagram is often called context

26

diagram. It consists a single process bit, which plays vital role in studying the current system. The

process in the context level diagram is exploded into other process at the first level DFD.

The idea behind the explosion of a process into more process is that understanding at one

level of detail is exploded into greater detail at the next level. This is done until further explosion is

necessary and an adequate amount of detail is described for analyst to understand the process.

Larry Constantine first developed the DFD as a way of expressing system requirements in a

graphical from, this lead to the modular design.

A DFD is also known as a “bubble Chart” has the purpose of clarifying system requirements

and identifying major transformations that will become programs in system design. So it is the

starting point of the design to the lowest level of detail. A DFD consists of a series of bubbles joined

by data flows in the system.

27

3.4.3 DFD SYMBOLS:

In the DFD, there are four symbols

1. A square defines a source(originator) or destination of system data

2. An arrow identifies data flow. It is the pipeline through which the information flows

3. A circle or a bubble represents a process that transforms incoming data flow into outgoing

data flows.

4. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow.

Source or Destination of data

Data flow

Data Store

3.4.4 CONSTRUCTING A DFD:

Several rules of thumb are used in drawing DFD’S:

1. Process should be named and numbered for an easy reference. Each name should be

representative of the process.

2. The direction of flow is from top to bottom and from left to right. Data traditionally flow from

source to the destination although they may flow back to the source. One way to indicate this is

28

to draw long flow line back to a source. An alternative way is to repeat the source symbol as a

destination. Since it is used more than once in the DFD it is marked with a short diagonal.

3. When a process is exploded into lower level details, they are numbered.

4. The names of data stores and destinations are written in capital letters. Process and dataflow

names have the first letter of each work capitalized

A DFD typically shows the minimum contents of data store. Each data store should contain

all the data elements that flow in and out.

Questionnaires should contain all the data elements that flow in and out. Missing interfaces

redundancies and like is then accounted for often through interviews.

SAILENT FEATURES OF DFD’S

1. The DFD shows flow of data, not of control loops and decision are controlled considerations do

not appear on a DFD.

2. The DFD does not indicate the time factor involved in any process whether the dataflow take

place daily, weekly, monthly or yearly.

3. The sequence of events is not brought out on the DFD.

3.4.5 TYPES OF DATA FLOW DIAGRAMS

1. Current Physical

2. Current Logical

3. New Logical

4. New Physical

3.4.5(a) CURRENT PHYSICAL:

In Current Physical DFD process label include the name of people or their positions or the

names of computer systems that might provide some of the overall system-processing label includes

an identification of the technology used to process the data. Similarly data flows and data stores are

often labels with the names of the actual physical media on which data are stored such as file folders,

computer files, business forms or computer tapes.

29

3.4.5(b) CURRENT LOGICAL:

The physical aspects at the system are removed as mush as possible so that the current system

is reduced to its essence to the data and the processors that transform them regardless of actual

physical form.

3.4.5(c) NEW LOGICAL:

This is exactly like a current logical model if the user were completely happy with he user

were completely happy with the functionality of the current system but had problems with how it was

implemented typically through the new logical model will differ from current logical model while

having additional functions, absolute function removal and inefficient flows recognized.

3.4.5(d) NEW PHYSICAL:

The new physical represents only the physical implementation of the new system.

3.4.6 RULES GOVERNING THE DFD’S

PROCESS

1) No process can have only outputs.

2) No process can have only inputs. If an object has only inputs than it must be a sink.

3) A process has a verb phrase label.

3.4.7 DATA STORE

1) Data cannot move directly from one data store to another data store, a process must move data.

2) Data cannot move directly from an outside source to a data store, a process, which receives, must

move data from the source and place the data into data store

3) A data store has a noun phrase label.

3.4.7.1 SOURCE OR SINK

The origin and /or destination of data.

30

1) Data cannot move direly from a source to sink it must be moved by a process

2) A source and /or sink has a noun phrase land

3.4.7(a) DATA FLOW

1) A Data Flow has only one direction of flow between symbols. It may flow in both directions

between a process and a data store to show a read before an update. The later is usually indicated

however by two separate arrows since these happen at different type.

2) A join in DFD means that exactly the same data comes from any of two or more different

processes data store or sink to a common location.

3) A data flow cannot go directly back to the same process it leads. There must be atleast one other

process that handles the data flow produce some other data flow returns the original data into the

beginning process.

4) A Data flow to a data store means update (delete or change).

5) A data Flow from a data store means retrieve or use.

A data flow has a noun phrase label more than one data flow noun phrase can appear on a single

arrow as long as all of the flows on the same arrow move together as one package.

31

3.5 UML DIAGRAMS

Select File

Make Segments

If Failed Send Segments

Destination

Receive Segments Send ACK

Receive ACK

Resend

32

Class Diagram:

33

Clients:

34

Use case Diagram:

Source Terminal Dest Terminal

Source Terminal Dest Terminal

ACK

35

Sequence Diagram:

S1:Source S2: Source D1:Dest ACK D2: Destination

If Failed

36

4. IMPLEMENTATION

4.1 INTRODUCTION TO .NET Framework

The .NET Framework is a new computing platform that simplifies application development in the

highly distributed environment of the Internet. The .NET Framework is designed to fulfill the

following objectives:

To provide a consistent object-oriented programming environment whether object code is stored

and executed locally, executed locally but Internet-distributed, or executed remotely.

To provide a code-execution environment that minimizes software deployment and versioning

conflicts.

To provide a code-execution environment that guarantees safe execution of code, including code

created by an unknown or semi-trusted third party.

To provide a code-execution environment that eliminates the performance problems of scripted or

interpreted environments.

To make the developer experience consistent across widely varying types of applications, such as

Windows-based applications and Web-based applications.

To build all communication on industry standards to ensure that code based on the .NET

Framework can integrate with any other code.

The .NET Framework has two main components: the common language runtime and the .NET

Framework class library. The common language runtime is the foundation of the .NET Framework.

You can think of the runtime as an agent that manages code at execution time, providing core services

such as memory management, thread management, and Remoting, while also enforcing strict type

safety and other forms of code accuracy that ensure security and robustness. In fact, the concept of

code management is a fundamental principle of the runtime. Code that targets the runtime is known as

managed code, while code that does not target the runtime is known as unmanaged code. The class

library, the other main component of the .NET Framework, is a comprehensive, object-oriented

collection of reusable types that you can use to develop applications ranging from traditional

command-line or graphical user interface (GUI) applications to applications based on the latest

innovations provided by ASP.NET, such as Web Forms and XML Web services.

The .NET Framework can be hosted by unmanaged components that load the common language

runtime into their processes and initiate the execution of managed code, thereby creating a software

environment that can exploit both managed and unmanaged features. The .NET Framework not only

provides several runtime hosts, but also supports the development of third-party runtime hosts.

37

For example, ASP.NET hosts the runtime to provide a scalable, server-side environment for

managed code. ASP.NET works directly with the runtime to enable Web Forms applications and

XML Web services, both of which are discussed later in this topic.

Internet Explorer is an example of an unmanaged application that hosts the runtime (in the

form of a MIME type extension). Using Internet Explorer to host the runtime enables you to embed

managed components or Windows Forms controls in HTML documents. Hosting the runtime in this

way makes managed mobile code (similar to Microsoft® ActiveX® controls) possible, but with

significant improvements that only managed code can offer, such as semi-trusted execution and

secure isolated file storage.

The following illustration shows the relationship of the common language runtime and the

class library to your applications and to the overall system. The illustration also shows how managed

code operates within a larger architecture.

4.1.1 FEATURES OF THE COMMON LANGUAGE RUNTIME

The common language runtime manages memory, thread execution, code execution, code

safety verification, compilation, and other system services. These features are intrinsic to the managed

code that runs on the common language runtime.

With regards to security, managed components are awarded varying degrees of trust,

depending on a number of factors that include their origin (such as the Internet, enterprise network, or

local computer). This means that a managed component might or might not be able to perform file-

access operations, registry-access operations, or other sensitive functions, even if it is being used in

the same active application.

The runtime enforces code access security. For example, users can trust that an executable

embedded in a Web page can play an animation on screen or sing a song, but cannot access their

personal data, file system, or network. The security features of the runtime thus enable legitimate

Internet-deployed software to be exceptionally featuring rich.

The runtime also enforces code robustness by implementing a strict type- and code-

verification infrastructure called the common type system (CTS). The CTS ensures that all managed

code is self-describing. The various Microsoft and third-party language compilers

Generate managed code that conforms to the CTS. This means that managed code can

consume other managed types and instances, while strictly enforcing type fidelity and type safety.

In addition, the managed environment of the runtime eliminates many common software

issues. For example, the runtime automatically handles object layout and manages references to

38

objects, releasing them when they are no longer being used. This automatic memory management

resolves the two most common application errors, memory leaks and invalid memory references.

The runtime also accelerates developer productivity. For example, programmers can write

applications in their development language of choice, yet take full advantage of the runtime, the class

library, and components written in other languages by other developers. Any compiler vendor who

chooses to target the runtime can do so. Language compilers that target the .NET Framework make

the features of the .NET Framework available to existing code written in that language, greatly easing

the migration process for existing applications.

While the runtime is designed for the software of the future, it also supports software of today

and yesterday. Interoperability between managed and unmanaged code enables developers to continue

to use necessary COM components and DLLs.

The runtime is designed to enhance performance. Although the common language runtime

provides many standard runtime services, managed code is never interpreted. A feature called just-in-

time (JIT) compiling enables all managed code to run in the native machine language of the system on

which it is executing. Meanwhile, the memory manager removes the possibilities of fragmented

memory and increases memory locality-of-reference to further increase performance.

Finally, the runtime can be hosted by high-performance, server-side applications, such as

Microsoft® SQL Server™ and Internet Information Services (IIS). This infrastructure enables you to

use managed code to write your business logic, while still enjoying the superior performance of the

industry's best enterprise servers that support runtime hosting.

4.1.2 Server Application Development

Server-side applications in the managed world are implemented through runtime hosts.

Unmanaged applications host the common language runtime, which allows your custom managed

code to control the behavior of the server. This model provides you with all the features of the

common language runtime and class library while gaining the performance and scalability of the host

server.

The following illustration shows a basic network schema with managed code running in

different server environments. Servers such as IIS and SQL Server can perform standard operations

while your application logic executes through the managed code.

4.1.3 SERVER-SIDE MANAGED CODE

ASP.NET is the hosting environment that enables developers to use the .NET Framework to

target Web-based applications. However, ASP.NET is more than just a runtime host; it is a complete

architecture for developing Web sites and Internet-distributed objects using managed code. Both Web

39

Forms and XML Web services use IIS and ASP.NET as the publishing mechanism for applications,

and both have a collection of supporting classes in the .NET Framework.

XML Web services, an important evolution in Web-based technology, are distributed, server-

side application components similar to common Web sites. However, unlike Web-based applications,

XML Web services components have no UI and are not targeted for browsers such as Internet

Explorer and Netscape Navigator. Instead, XML Web services consist of reusable software

components designed to be consumed by other applications, such as traditional client applications,

Web-based applications, or even other XML Web services. As a result, XML Web services

technology is rapidly moving application development and deployment into the highly distributed

environment of the Internet.

If you have used earlier versions of ASP technology, you will immediately notice the

improvements that ASP.NET and Web Forms offers. For example, you can develop Web Forms pages

in any language that supports the .NET Framework. In addition, your code no longer needs to share

the same file with your HTTP text (although it can continue to do so if you prefer). Web Forms pages

execute in native machine language because, like any other managed application, they take full

advantage of the runtime. In contrast, unmanaged ASP pages are always scripted and interpreted.

ASP.NET pages are faster, more functional, and easier to develop than unmanaged ASP pages

because they interact with the runtime like any managed application.

The .NET Framework also provides a collection of classes and tools to aid in development

and consumption of XML Web services applications. XML Web services are built on standards such

as SOAP (a remote procedure-call protocol), XML (an extensible data format), and WSDL ( the Web

Services Description Language). The .NET Framework is built on these standards to promote

interoperability with non-Microsoft solutions.

For example, the Web Services Description Language tool included with the .NET

Framework SDK can query an XML Web service published on the Web, parse its WSDL description,

and produce C# or Visual Basic source code that your application can use to become a client of the

XML Web service. The source code can create classes derived from classes in the class library that

handle all the underlying communication using SOAP and XML parsing. Although you can use the

class library to consume XML Web services directly, the Web Services Description Language tool

and the other tools contained in the SDK facilitate your development efforts with the .NET

Framework.

If you develop and publish your own XML Web service, the .NET Framework provides a set

of classes that conform to all the underlying communication standards, such as SOAP, WSDL, and

XML. Using those classes enables you to focus on the logic of your service, without concerning

yourself with the communications infrastructure required by distributed software development.

Finally, like Web Forms pages in the managed environment, your XML Web service will run with the

speed of native machine language using the scalable communication of IIS.

40

4.1.4 LANGUAGE SUPPORT The Microsoft .NET Platform currently offers built-in support for three languages: C#, Visual

Basic, and JScript.

C# is an event based object oriented programming

41

4.2 C# .NET – SOCKET PROGRAMMING

4.2.1 Introduction

A socket is a fundamental technology to computer networking. Sockets allow for two or

more applications to communicate with each other, whether these are on the same or different

computers. They operate on standard mechanisms that are built into network hardware and operating

systems. Many of the most popular web applications rely heavily on sockets, most notably, web

browsers!

A socket represents a single connection between two applications, these can be on the same

computer (called an interprocess), or across the Internet. More than two applications can communicate

in things we call "client/server" or "distributed" connections, however these employ multiple sockets.

Sockets are bidirectional, this means that either side of the connection is capable of sending and

receiving data.

There are a variety of libraries that allow for socket programming. There are things like the

Berkeley Socket Library (used primarily on UNIX systems) and the Winsock Library primarily used

on Microsoft operating systems. However, we'll be using the .NET framework, which fully supports

socket programming. Socket interfaces are often divided into three categories. The most common is

the stream socket, which allows for connection-oriented semantics; wherein a stream requires that two

communicating parties establish a socket connection, and therefore any data passed through the

connection will be guaranteed to arrive, and arrive in the same order they were sent.

The next type is the datagram socket, this allows for connection-less semantics. This means

connections are implicit rather than explicit (as seen in streams). Therefore, an application can send

the datagram as needed and then waits for the other to respond. Therefore, messages can be lost, or

arrive out of order. Therefore, it is the application's responsibility (not the socket's) to deal with such

problems. The last type, known as the raw socket, bypasses standard support for protocols like TCP or

UDP, these are often used for custom, low-level protocol development.

In the modern day, sockets are used with standard Internet Protocols, utilizing IP, TCP, and UDP.

Typically, libraries that implement sockets for IP use TCP for streams, UDP for datagrams, and IP for

raw sockets.

Sockets use the IP address to identify specific computers (when communicating across the

Internet). The other aspect to socket programming is that stream and datagram sockets use IP port

numbers to distinguish multiple applications. Therefore, web browsers on the Internet typically use

port 80 as the default

socket for communication via HTTP with web servers.

42

A network socket is a lot like an electrical socket. Various plugs around the network have a

standard way of delivering their payload. Anything that understands the standard protocol can “plug

in” to the socket and communicate. Internet Protocol is a low-level routing protocol that breaks data

into small packets to the destination. Transmission Control Protocol (TCP) is a higher-level protocol

that manages to robustly string together these packets, sorting and retransmitting them as necessary to

reliably transmit your data.

A server is anything that has some resource which can be shared. A client is simply any other

entity that wants to gain access to a particular server. The interaction between client and server is just

like the interaction between a lamp and an electrical socket. The power grid of the house is the server,

and the lamp is a power client. The server is a permanently available resource, while the client is free

to “unplug” after it has been served.

The notion of a socket allows a single computer to serve many different clients at once, as

well as serving many different types of information. This feat is managed by the introduction of a

port, which is a numbered socket on a particular machine. A server process is said to “listen” to a port

until a client connects to it. A server is allowed to accept multiple clients connected to the same port

number, although each session is unique.

The objective of this article is to demonstrate a socket-based client/server application that will

allow two-way asynchronous communication between a server and multiple client applications.

Because this example uses asynchronous methods, the server application does not use threads to

communicate to multiple clients (although internally the asynchronous communication mechanism

uses threads at the OS level).

4.2.2 The Difference Between Synchronous and Asynchronous Communication in

Network Programming The key difference between synchronous and asynchronous communication can be explained

with an example.

Consider a server application that is listening on a specific port to get data from clients. In

synchronous receiving, while the server is waiting to receive data from a client, if the stream is empty

the main thread will block until the request for data is satisfied. Hence, the server cannot do anything

else until it receives data from the client. If another client attempts to connect to the server at that

time, the server cannot process that request because it is blocked on the first client. This behavior is

not acceptable for a real-world application where we need to support multiple clients at the same time.

In asynchronous communication, while the server is listening or receiving data from a client,

it can still process connection requests from other clients as well as receive data from those clients.

When a server is receiving asynchronously, a separate thread (at the OS level) listens on the socket

and will invoke a callback function (specified when the asynchronous listening was commenced)

43

when a socket event occurs. This callback function in turn will respond and process that socket event.

For example, if the remote program writes some data to the socket, a "read data event" (callback

function you specify) is invoked; it knows how to read the data from the socket at that point. Even

though this could be achieved by running multiple threads, the C# and .NET frameworks provide a

rich set of functionalities to do asynchronous communications without introducing the complexity of

threading.

4.1.3 Socket Class The Socket class (System.Net.Sockets.Socket) provides a set of synchronous and

asynchronous methods for synchronous or asynchronous communication. As per the .NET naming

convention, all the asynchronous method names are created by prefixing the words "Begin" or "End"

to the name of the synchronous methods. The methods prefixed with "Begin" and "End" represent a

pair of asynchronous methods corresponding to a single synchronous method, as shown in the

following table.

4.1.4 Socket Server Implementation

The Socket Server application is implemented in the SocketServer class (file name

SocketServer.cs). This class has a main Socket object (m_mainSocket) and an array of worker Socket

objects (m_workerSocket) as members. The main Socket object does the listening for the clients.

Once a client is connected, the main Socket transfers the responsibility to process the transactions

related to that particular client to a worker Socket. Then, the main Socket goes back and continues

listening for other clients.

BeginAccept() and BeginReceive() are the two important methods in the Socket class used by the

Socket Server application.

The BeginAccept() method has the following signature:

public IAsyncResult BeginAccept

(

AsyncCallback callback, // (1) Function to call when a client

// is connected

Synchronous Methods Asynchronous Methods

Connect() BeginConnect() EndConnect()

Receive() BeginReceive() EndReceive()

44

object state // (2) State object to preserve socket

// info

);

Essentially, after calling the Listen() method of the main Socket object, you call this asynchronous

method and specify a call back function (1), which you designated to do the further processing related

to the client connection. The state object (2) can be null in this particular instance. Because this is an

asynchronous method, it will return immediately and the server main thread is free to process other

events. Behind the scenes, a separate thread will start listening on that particular socket for client

connections. When a client requests a connection, the callback function you specified will be invoked.

Inside the callback function (in the example, the function is named "OnClientConnect()"), you will do

further processing related to the client connection.

public void OnClientConnect(IAsyncResult asyn)

{

try

{

// Here we complete/end the BeginAccept() asynchronous call

// by calling EndAccept() - which returns the reference to

// a new Socket object

m_workerSocket[m_clientCount] = m_mainSocket.EndAccept (asyn);

// Let the worker Socket do the further processing for the

// just connected client

WaitForData(m_workerSocket[m_clientCount]);

// Now increment the client count

45

++m_clientCount;

// Display this client connection as a status message on the GUI

String str = String.Format("Client # {0} connected",

m_clientCount);

textBoxMsg.Text = str;

// Since the main Socket is now free, it can go back and wait

// for other clients who are attempting to connect

m_mainSocket.BeginAccept(new AsyncCallback

( OnClientConnect ),null);

}

catch(ObjectDisposedException)

{

System.Diagnostics.Debugger.Log(0,"1","\n OnClientConnection:

Socket has been closed\n");

}

catch(SocketException se)

{

MessageBox.Show ( se.Message );

}

}

The first thing you do inside the "OnClientConnect()" function is to call the EndAccept()

method on the m_mainSocket member object, which will return a reference to another socket object.

You set this object reference to one of the members of the array of Socket object references you have

(m_workerSocket) and also increment the client counter. Now, because you have a reference to a new

socket object that now can do the further transaction with the client, the main Socket (m_mainSocket)

is free; hence, you will call its BeginAccept() method again to start waiting for connection requests

from other clients.

On the worker socket, you use a similar strategy to receive the data from the client. In place

of calling BeginAccept() and EndAccept(), here you call BeginReceive() and EndReceive(). This, in a

nutshell, is the Socket Server implementation. While you are sending out data to the clients, the server

simply uses the specific worker socket objects to send data to each client.

46

Socket Client Implementation

The Socket Client application is implemented in the SocketClient class (file name

SocketClient.cs). Compared to the server where you have a main Socket and an array of worker

Sockets, here you only have a single Socket object (m_clientSocket).

The two important methods in Socket class used by the Socket Client application are the

Connect() and BeginReceive() methods. Connect() is a synchronous method and is called to connect

to a server that is listening for client connections. Because this call will succeed/fail immediately,

depending on whether there is an active server listening or not at the specified IP and Port number, a

synchronous method is okay for this purpose.

Once a connection is established, you call the BeginReceive() asynchronous function to wait

for any socket write activity by the server. Here, if you call a synchronous method, the main thread on

the client application will block and you will not be able to send any data to the server while the client

is waiting for data from the server.

When there is any write activity on the socket from the server end, the internal thread started

by BeginReceive() will invoke the callback function ("OnDataReceived()" in this case), which will

take care of the further processing of the data written by the server.

When sending the data to the server, you just call the Send() method on the m_clientSocket

object, which will synchronously write the data to the socket.

That is all there is for asynchronous socket communication using multiple clients.

47

4.1.5 Limitations/Possible Improvements 1. Up to 10 simultaneous clients are supported. You can easily modify and support unlimited

number of clients by using a HashTable instead of an array.

2. For simplicity, when the server sends out a message, it is broadcast to all the connected clients.

This could easily be modified to send messages to specific clients by using the Socket object

pertaining to that particular client.

3. When a client is disconnected, proper action is not taken; the client count is not decremented.

The correct way would be to reuse or release resources for other client connections.

Screen Shot of Socket Server

48

Screen Shot of Socket Client

4.1.6 How to Find Which Client Sent a Particular Message

When multiple clients are connected, you may need to differentiate between the messages

received from different clients. Also, there may be a reason to send a message to a particular client.

You could solve this problem by keeping track of each client by assigning them a serially incremented

number as soon as they are connected to the server. Here is the code that does that:

public void OnClientConnect(IAsyncResult asyn)

{

try

{

// Here we complete/end the BeginAccept() asynchronous call

// by calling EndAccept(), which returns the reference to a

// new Socket object

Socket workerSocket = m_mainSocket.EndAccept (asyn);

// Now, increment the client count for this client

++m_clientCount;

// Add the workerSocket reference to the ArrayList

// We will use (clientNumber - 1) as the index to access

// this socket in the future

m_workerSocketList.Add(workerSocket);

//........

// Let the worker Socket do the further processing for the

// just-connected client

49

WaitForData(workerSocket, m_clientCount);

//........

Inside the WaitForData() function, you will make the actual asynchronous call to receive the data

from the client as shown below:

public void WaitForData(System.Net.Sockets.Socket soc,

int clientNumber)

{

try

{

if( pfnWorkerCallBack == null )

{

// Specify the callback function that is to be invoked when

// there is any write activity by the connected client

pfnWorkerCallBack = new AsyncCallback (OnDataReceived);

}

SocketPacket theSocPkt = new SocketPacket (soc, clientNumber);

// Start receiving any data written by the connected client

// asynchronously

soc.BeginReceive (theSocPkt.dataBuffer, 0,

theSocPkt.dataBuffer.Length,

SocketFlags.None,

pfnWorkerCallBack,

theSocPkt);

//........

In the above code, the user-defined class SocketPacket is the most critical item. As you can see, an

object of this class is the last parameter passed to the asynchronous function call BeginReceive().

This object can contain any information that you find useful; it can be used later, when you actually

receive the data from the client. You send (1) the worker socket object and (2) the index number of

the client packaged inside this object. You will retrieve them back when you actually receive the data

from a particular client.

Given below is the definition of the SocketPacket class.

public class SocketPacket

{

// Constructor that takes a Socket and a client number

public SocketPacket(System.Net.Sockets.Socket socket,

int clientNumber)

{

50

m_currentSocket = socket;

m_clientNumber = clientNumber;

}

public System.Net.Sockets.Socket m_currentSocket;

public int m_clientNumber;

// Buffer to store the data sent by the client

public byte[] dataBuffer = new byte[1024];

}

In the above code, the SocketPacket class contains the reference to a socket, a data buffer of

size 1024 bytes, and a client number. This client number will be available when you actually start

receiving data from a particular client. By using this client number, you can identify which client

actually sent the data.

To demonstrate this in the example code, the server will echo back to the client (after converting to

upper case) the received message, using the correct socket object.

4.1.7 How to Reply or Send Messages to Specific Clients You might have figured out this already. This is very simple to implement. Because the

SocketPacket object contains the reference to a particular worker socket, you just use that object to

reply to the client. Additonally, you also could send any message to any particular client by using the

worker socket object stored in the ArrayList.

4.1.8 How to Find when a Particular Client is Disconnected

This is a bit harder to address. There may be other elegant ways to do this, but here is a

simple way. When a client is disconnected, there will be a final call to the OnDataReceived()

function. If nothing in particular is done, this call will throw a SocketException. What you can do

here is to look inside this exception and see whether this was triggered by the "disconnection" of a

client. For this, you will look at the error code inside the exception object and see whether it

corresponds to 10054. If so, you will do the required action corresponding to the client disconnection.

Here again, the SocketPacket object will give you the index number of the client that was

disconnected.

catch(SocketException se)

{

if(se.ErrorCode == 10054) // Error code for Connection reset

// by peer

{

51

string msg = "Client " + socketData.m_clientNumber +

" Disconnected" + "\n";

richTextBoxReceivedMsg.AppendText(msg);

// Remove the reference to the worker socket of the closed

// client so that this object will get garbage collected

m_workerSocketList[socketData.m_clientNumber - 1] = null;

UpdateClientList();

}

else

{

MessageBox.Show (se.Message );

}

}

4.1.9 Conclusion: The C# language has access to an entire suite of networking libraries. Some of its capabilities

range from low-level socket connections to wrapped HTTP classes. Though these days distributed, n-

tier concepts are gaining focus, some of the legacy system and Internet utilities still uses client-server

computing.

52

5.1 OUTPUT SCREENS

53

54

55

56

57

58

5.2 TESTING

5.2.1 INTRODUCTION

Software testing is a critical element of software quality assurance and represents the ultimate

review of specification, design and coding. In fact, testing is the one step in the software engineering

process that could be viewed as destructive rather than constructive.

A strategy for software testing integrates software test case design methods into a well-

planned series of steps that result in the successful construction of software. Testing is the set of

activities that can be planned in advance and conducted systematically. The underlying motivation of

program testing is to affirm software quality with methods that can economically and effectively

apply to both strategic to both large and small-scale systems.

5.2.2 STRATEGIC APPROACH TO SOFTWARE TESTING

The software engineering process can be viewed as a spiral. Initially system engineering

defines the role of software and leads to software requirement analysis where the information domain,

functions, behavior, performance, constraints and validation criteria for software are established.

Moving inward along the spiral, we come to design and finally to coding. To develop computer

software we spiral in along streamlines that decrease the level of abstraction on each turn.

A strategy for software testing may also be viewed in the context of the spiral. Unit testing

begins at the vertex of the spiral and concentrates on each unit of the software as implemented in

source code. Testing progress by moving outward along the spiral to integration testing, where the

focus is on the design and the construction of the software architecture. Talking another turn on

outward on the spiral we encounter validation testing where requirements established as part of

software requirements analysis are validated against the software that has been constructed. Finally

we arrive at system testing, where the software and other system elements are tested as a whole.

59

F

Fig. 7 Phases of Testing

5.2.3. Unit Testing

Unit testing focuses verification effort on the smallest unit of software design, the module. The unit

testing we have is white box oriented and some modules the steps are conducted in parallel.

1. WHITE BOX TESTING This type of testing ensures that

All independent paths have been exercised at least once

All logical decisions have been exercised on their true and false sides

All loops are executed at their boundaries and within their operational bounds

All internal data structures have been exercised to assure their validity.

To follow the concept of white box testing we have tested each form .we have created independently

to verify that Data flow is correct, All conditions are exercised to check their validity, All loops are

executed on their boundaries.

UNIT TESTING

MODULE TESTING

SUB-SYSTEM TESING

SYSTEM TESTING

ACCEPTANCE TESTING

Component Testing

Integration Testing

User Testing

60

2. BASIC PATH TESTING

Established technique of flow graph with Cyclomatic complexity was used to derive test cases for all

the functions. The main steps in deriving test cases were:

Use the design of the code and draw correspondent flow graph.

Determine the Cyclomatic complexity of resultant flow graph, using formula:

V(G)=E-N+2 or

V(G)=P+1 or

V(G)=Number Of Regions

Where V(G) is Cyclomatic complexity,

E is the number of edges,

N is the number of flow graph nodes,

P is the number of predicate nodes.

Determine the basis of set of linearly independent paths.

3. CONDITIONAL TESTING

In this part of the testing each of the conditions were tested to both true and false aspects. And all the

resulting paths were tested. So that each path that may be generate on particular condition is traced to

uncover any possible errors.

4. DATA FLOW TESTING

This type of testing selects the path of the program according to the location of definition and use of

variables. This kind of testing was used only when some local variable were declared. The definition-

use chain method was used in this type of testing. These were particularly useful in nested statements.

5. LOOP TESTING

In this type of testing all the loops are tested to all the limits possible. The following exercise was adopted for all loops:

All the loops were tested at their limits, just above them and just below them.

61

All the loops were skipped at least once.

For nested loops test the inner most loop first and then work outwards.

For concatenated loops the values of dependent loops were set with the help of connected loop.

Unstructured loops were resolved into nested loops or concatenated loops and tested as above.

Each unit has been separately tested by the development team itself and all the input have been validated.

62

6. CONCLUSION AND POSSIBLE FUTURE WORK

We conducted performance analysis of the resequencing buffer for SW-ARQ-in S over a

generic number of parallel channels with both time-varying and time-invariant packet error rates.

With the dynamic assignment rule applied in the protocol, exact statistical results of the resequencing

buffer occupancy with both channel models were derived in steady state. The distribution function of

the resequencing delay for the model with time-invariant error rates and the mean resequencing delay

for the model with time-varying error rates were also obtained. For the model with time-invariant

error rates, we numerically computed the pmf of the resequencing buffer occupancy using its

probability generating function and the pmf of the resequencing delay. Through numerical and

simulation results, we discussed the impact of the packet-to-channel assignment rules, the variance in

the error states, the average error rate, and the number of parallel channels on the mean resequencing

buffer occupancy and the mean resequencing delay. The dynamic assignment rule always outperforms

the static assignment rule for both channel models. For MSW-ARQ-inS over parallel channels with

both possibly different time-invariant error rates and the Gilbert–Elliott model, the mean resequencing

buffer occupancy and the mean resequencing delay increase with the average error rate and the

number of parallel channels even though the mean resequencing buffer occupancy decreases with the

variance in the error states. In future work, we can apply the modeling and analytical approach

presented in this paper to conducting performance studies on the selective-repeat ARQ protocol over

parallel channels with time-varying channel models.

63

BIBLIOGRAPHY

FOR .NET INSTALLATION www.support.mircosoft.com FOR DEPLOYMENT AND PACKING ON SERVER www.developer.com www.15seconds.com REFERENCES [1] S. S. L. Chang, “Theory of information feedback systems,” IEEE Trans.Inf. Theory, vol. IT-2, pp.

29–40, 1956.

[2] M. E. Anagnostou and E. N. Protonotarios, “Performance analysis of the selective repeat ARQ

protocol,” IEEE Trans. Commun., vol. COM-34, pp. 127–135, 1986.

[3] M. Moeneclaey, H. Nruneel, I. Bruyland, and D. Y. Chung, “Throughput optimization for a

generalized stop-and-wait ARQ scheme,” IEEE Trans. Commun., vol. COM-34, pp. 205–207, 1986.

[4] Z. Rosberg and N. Shacham, “Resequencing delay and buffer occupancy under the selective-

repeat ARQ,” IEEE Trans. Inf. Theory, vol. 35, pp. 166–173, 1989.

[5] L. Badia, M. Rossi, and M. Zorzi, “SR ARQ packet pelay ptatistics on parkov channels in the

presence of variable arrival rate,” IEEE Trans. Wireless Commun., vol. 5, pp. 1639–1644, 2006.

[6] R. Fantacci, “Queueing analysis of the selective repeat automatic repeat request protocol wireless

packet networks,” IEEE Trans. Veh. Technol., vol. 45, pp. 258–264, 1996.

[7] J. G. Kim and M. K. Krunz, “Delay analysis of selective repeat ARQ for a Markovian source over

a wireless channel,” IEEE Trans. Veh. Technol., vol. 49, pp. 1968–1981, 2000.

[8] L. B. Le, E. Hossain, and A. S. Alfa, “Delay statistics and throughput performance for multi-rate

wireless networks under multiuser diversity,” IEEE Trans. Wireless Commun., vol. 5, pp. 3234–3243,

2006.

[9] M. Rossi, L. Badia, and M. Zorzi, “SR ARQ delay statistics on N-state Markov channels with non-

instantaneous feedback,” IEEE Trans.Wireless Commun., vol. 5, pp. 1526–1536, 2006.

[10] D. Towsley, “A statistical analysis ofARQprotocols operating in a nonindependent error

environment,” IEEE Trans. Commun., vol. COM-29, pp. 971–981, 1981.

[11]. E. N. Gilbert, “Capacity of a burst-noise channel,” Bell System Technical Journal, vol. 39, no. 5,

pp. 1253–1266, 1960.

[12] W. Stallings, Data and Computer Communications, 6th ed. Upper Saddle River, NJ: Prentice-

Hall, 2000, ch. 2.

[13] N. Shacham and B. C. Shin, “A selective-repeat-ARQ protocol for parallel channels and its

resequencing analysis,” IEEE Trans. Commun., vol. 40, pp. 773–782, 1992

64

PUBLICATIONS

“Improvised Technique Of Transmitting The Data Using Sw-Arq Protocol” has accepted for

publication in International Journal of Computer Engineering and Software Technology (ISSN:

2229-3086) (Vol.3 No.1 2012).