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 ARQs 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 (m1)/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+(m1)/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




Wher e

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


Wher e
ij i
Q p =


For w e not e t hat t h e upper - l ef t sub mat r i x of P , w hi ch i s l ow er t r i angul ar, is
t he t r ansi t i on mat r i x of t h e M ar kov chai n Thi s i mpl i es t hat f or i n t h e st at e space of t h e
M ar kov chai n . Thi s i mpl i es t hat f or j, l i n t he st at e space of t he M ar kov chai n

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 0
0 0
0
M M M M M
p p
p p p P
p P p p
(
(
(
( =
(
(
(

, ,
.
c
i i j i j
ij
Bi j k B k B
P pk qk
cO e e
| |
| =
|
\ .
[ [
1 1
2 21 22
1 ,2 ,
1 0 0 0
0 0
1 0
0 (4)
M M M M
q p
q q q Q
q T
qm Q Q Q
(
(
(
(
( = =
(
(

(
(

1, 1 1, 1
c
i i i
k B k B j
pk qk

e e
| |
|
|
\ .
[ [
2,..., 1,.... . i M and i i = =
( ) { } : 0 .
i
X t t >
( ) { } : 0
i
X t t >
( ) ( )
i i
X t n X t j P + = = (

( )
( )
( )
n
M i jl
X t n X t j p ( =P + = = =

( ) n
jl
P
( ) { } : 0
i
X 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 = 1pi, 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
GUIS
In the flexibility of the uses the interface has been developed a graphics concept in mind,
associated through a browser interface. The GUIS at the top level have been categorized as
1. Administrative user interface
2. The operational or generic user interface

Communicat ed
Requirement s
Requirement s
Specificat ion
Design
Specifi cat ion
Execut able
Sof t ware
Modules
I nt egrat ed
Soft ware
Pr oduct
Deli vered
Soft ware
Pr oduct
Changed
Requi rement s
Requirement s
Engineeri ng
Desi gn
Pr ogramming
I nt egrat ion
Del ivery
Mai nt enance

Pr oduct Pr oduct
I nput
Out put
Pr ocess
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
- Users 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
- Dat a val i dat i on
- Dat a cor r ect i on
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 departments 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 designers 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 customers 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 DFDS 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 DFDS:
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 DFDS
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 DFDS
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) Dat a cannot mo ve di r el y f r om a sour ce t o si nk i t must be mo ved by a pr ocess
2) A sour ce and / or si nk has a noun phr ase l and
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
M ake 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 Test ing
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 GilbertElliott 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.
2940, 1956.
[2] M. E. Anagnostou and E. N. Protonotarios, Performance analysis of the selective repeat ARQ
protocol, IEEE Trans. Commun., vol. COM-34, pp. 127135, 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. 205207, 1986.
[4] Z. Rosberg and N. Shacham, Resequencing delay and buffer occupancy under the selective-
repeat ARQ, IEEE Trans. Inf. Theory, vol. 35, pp. 166173, 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. 16391644, 2006.
[6] R. Fantacci, Queueing analysis of the selective repeat automatic repeat request protocol wireless
packet networks, IEEE Trans. Veh. Technol., vol. 45, pp. 258264, 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. 19681981, 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. 32343243,
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. 15261536, 2006.
[10] D. Towsley, A statistical analysis ofARQprotocols operating in a nonindependent error
environment, IEEE Trans. Commun., vol. COM-29, pp. 971981, 1981.
[11]. E. N. Gilbert, Capacity of a burst-noise channel, Bell System Technical Journal, vol. 39, no. 5,
pp. 12531266, 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. 773782, 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).