documentation - random access transport capacity

8/13/2019 Documentation - Random Access Transport Capacity

1/52

Random Access Transport Capacity


2/52

Abstract

This project develop a new metric for quantifying end-to end throughput in Multi

hop wireless networks, which we term random access transport capacity, since the

interference model presumes uncoordinated transmissions. The metric quantifies the

average maximum rate of successful end-to-end transmissions, multiplied by the

communication distance, and normali ed by the network area. !e show that a simple

upper bound on this quantity is computable in closed-form in terms of key network

parameters when the number of retransmissions is not restricted and the hops are

assumed to be equally spaced on a line between the source and destination. !e also

derive the optimum number of hops and optimal per hop success probability and showthat our result follows the well-known square root scaling law while providing exact

expressions for the pre-constants, which contain most of the design-relevant network

parameters. "umerical results demonstrate that the upper bound is accurate for the

purpose of determining the optimal hop count and success #or outage$ probability.


3/52


4/52

Chapter 2 Literature review

*n alternative approach pioneered by the current authors and others has focused oncomputing achievable rate regions and network densities for different architectures and

technologies. * key to this approach is to assume that the interferer locations are random,

in particular that they are oisson distributed over the plane. *lthough this is an

ideali ation, it accurately models the scenario where transmitters are randomly scattered

and uncoordinated, which seems to be quite a bit more realistic than other popular

alternatives, such as assuming they are placed deterministically on a regular grid. This

approach has allowed closed-form derivation of outage probability as well as the

maximum allowable transmission density at a specified outage probability and data rate,

the latter of which we have termed the transmission capacity . The analytical tractability

of this approach #using tools from stochastic geometry has to date allowed quantitative

design tradeoffs for spread spectrum interference cancellation multiple-antenna

architectures, cognitive radio and capacity overlays and power control.

* common shortcoming of the transmission capacity approach is that it considers a

typical network snapshot, and hence only simultaneous single hop transmissions. The

primary goal of this paper is to address this limitation, and we develop a related metric

which we term the random access transport capacity because it presumes packets are

transported end-to-end over some distance but assume independent locations and

transmissions for the interferers. 'n that sense, one contribution of the paper is to find a

middle ground between the transport and transmission capacity approaches into the

capacity of multi-hop wireless networks. *s one might expect, the results of this paper

follow the but provide exact expressions for the /preconstants0, which is where nearly all

the impact of any network design resides, since most reasonable protocols and physical

layer techniques can achieve.


5/52

Chapter !ystem Ana"ysis

#1 $%istence !ystem&

1omplementary to the transport capacity research, some recent work has

formulated the multi hop capacity problem as a line network without additional network

interference. 2oth of these papers agree that numerous hops are helpful only in the

/power-limited3 regime, that is where the spectral efficiency is low and overcoming noise

is the primary concern. 2oth also find that in the /bandwidth-limited regime3.

#2 'roposed !ystem&

The primary goal of this project is to address this limitation, and we develop a

related metric which we term the random access transport capacity because it presumes

packets are transported end-to-end over some distance, but assume independent locations

and transmissions for the interferers. 'n that sense, one contribution of the paper is to find

a middle ground between the transport and transmission capacity approaches into the

capacity of multi hop wireless networks. *s one might expect, the results of this paper

follow the scaling law, but provide exact expressions for the /preconstants0, which is

where nearly all the impact of any network design resides

The key distinction in this work is that we focus on achievable end-to end

throughput and optimal transmission strategies and hop count rather than the stability of

queues. !e also consider noise whereas they do not, which is important since we show

that it is in the power-limited regime where multi hop is beneficial.

The capacity of distributed wireless networks #i.e., ad hoc networks$ is one of the most

general and challenging open problems in information theory. )traightforward

applications of known information theoretic tools and inequalities become intractable

almost immediately and have hence yielded little in the way of results. This motivates the


6/52

exploration of approaches to describing ad hoc network throughput that, while falling

short of strict information theory upper bound standards, do provide insight into the

fundamental trends on achievable throughput.

# !ystem !peci(ication

)ardware !peci(ication

rocessor 4 entium +'''

)peed 4 5.5 (h

&*M 4 678 M2 #min$

9ard isk 4 6: (2

;loppy rive 4 5.(*

!o(tware Re*uirements&

?anguage 4 @ava &M', )!'"(, @6M%

Mobile toolkit 4 @6M% !ireless Toolkit 6.7.6

evelopment Tool 4 My %clipse A.:

B ) 4 !'"6::: C


7/52

#+ !o(tware , Techno"o y Description

.ava Techno"o y

@ava technology is both a programming language and a platform.

The .ava 'ro rammin Lan ua e

The @ava programming language is a high-level language that can be

characteri ed by all of the following bu words4

)imple

*rchitecture neutral

Bbject oriented

ortable

istributed

9igh performance

'nterpreted

Multithreaded

&obust

ynamic

)ecure

!ith most programming languages, you either compile or interpret a program so that you

can run it on your computer. The @ava programming language is unusual in that a

program is both compiled and interpreted. !ith the compiler, first you translate a

program into an intermediate language called Java byte codes Dthe platform-

independent codes interpreted by the interpreter on the @ava platform. The interpreter

parses and runs each @ava byte code instruction on the computer. 1ompilation happens

just onceE interpretation occurs each time the program is executed. The following figure

illustrates how this works.


8/52

Fou can think of @ava byte codes as the machine code instructions for the Java

Virtual Machine #@ava >M$. %very @ava interpreter, whether itGs a development tool or a

!eb browser that can run applets, is an implementation of the @ava >M. @ava byte codes

help make /write once, run anywhere0 possible. Fou can compile your program into byte

codes on any platform that has a @ava compiler. The byte codes can then be run on any

implementation of the @ava >M. That means that as long as a computer has a @ava >M,

the same program written in the @ava programming language can run on !indows 6:::,

a )olaris workstation, or on an iMac.

The .ava '"at(orm


9/52

* platform is the hardware or software environment in which a program runs. !eGve

already mentioned some of the most popular platforms like !indows 6:::, ?inux,

)olaris, and MacB). Most platforms can be described as a combination of the operating

system and hardware. The @ava platform differs from most other platforms in that itGs a

software-only platform that runs on top of other hardware-based platforms.

The @ava platform has two components4

The Java Virtual Machine #@ava >M$

The Java Application Programming Interface #@ava * '$

FouGve already been introduced to the @ava >M. 'tGs the base for the @ava platform and is

ported onto various hardware-based platforms.

The @ava * ' is a large collection of ready-made software components that provide many

useful capabilities, such as graphical user interface #(H'$ widgets. The @ava * ' is

grouped into libraries of related classes and interfacesE these libraries are known as

packages . The next section, !hat 1an @ava Technology oI 9ighlights what

functionality some of the packages in the @ava * ' provide.

The following figure depicts a program thatGs running on the @ava platform. *s the figure

shows, the @ava * ' and the virtual machine insulate the program from the hardware.

"ative code is code that after you compile it, the compiled code runs on a specific

hardware platform. *s a platform-independent environment, the @ava platform can be a

bit slower than native code. 9owever, smart compilers, well-tuned interpreters, and just-

in-time byte code compilers can bring performance close to that of native code without

threatening portability.


10/52


11/52

Internationa"i ation 4 9elp for writing programs that can be locali ed for users

worldwide. rograms can automatically adapt to specific locales and be displayed

in the appropriate language.

!ecurity 4 2oth low level and high level, including electronic signatures, publicand private key management, access control, and certificates.

!o(tware components 4 =nown as @ava2eans TM , can plug into existing component

architectures.

b3ect seria"i ation 4 *llows lightweight persistence and communication via

&emote Method 'nvocation #&M'$.

.ava Database Connectivity 4.D5C TM 64 rovides uniform access to a wide

range of relational databases.

The @ava platform also has * 's for 6 and A graphics, accessibility, servers,

collaboration, telephony, speech, animation, and more. The following figure depicts what

is included in the @ava 6 ) =.

How Will Java Technology Change My Life?


12/52

!e canGt promise you fame, fortune, or even a job if you learn the @ava programming

language. )till, it is likely to make your programs better and requires less effort than

other languages. !e believe that @ava technology will help you do the following4

7et started *uic0"y 4 *lthough the @ava programming language is a powerfulobject-oriented language, itGs easy to learn, especially for programmers already

familiar with 1 or 1JJ.

8rite "ess code 4 1omparisons of program metrics #class counts, method counts,

and so on$ suggest that a program written in the @ava programming language can

be four times smaller than the same program in 1JJ.

8rite better code 4 The @ava programming language encourages good coding

practices, and its garbage collection helps you avoid memory leaks. 'ts object

orientation, its @ava2eans component architecture, and its wide-ranging, easily

extendible * ' let you reuse other peopleGs tested code and introduce fewer bugs.

Deve"op pro rams more *uic0"y 4 Four development time may be as much as

twice as fast versus writing the same program in 1JJ. !hyI Fou write fewer

lines of code and it is a simpler programming language than 1JJ.

Avoid p"at(orm dependencies with 199: 'ure .ava 4 Fou can keep your

program portable by avoiding the use of libraries written in other languages. The

5::K ure @ava TM roduct 1ertification rogram has a repository of historical

process manuals, white papers, brochures, and similar materials online.

8rite once; run anywhere 4 2ecause 5::K ure @ava programs are compiled into

machine-independent byte codes, they run consistently on any @ava platform.

Distribute so(tware more easi"y 4 Fou can upgrade applets easily from a centralserver. *pplets take advantage of the feature of allowing new classes to be loaded

/on the fly,0 without recompiling the entire program.

D5C


13/52

Microsoft Bpen atabase 1onnectivity #B 21$ is a standard programming interface for

application developers and database systems providers. 2efore B 21 became a de facto

standard for !indows programs to interface with database systems, programmers had to

use proprietary languages for each database they wanted to connect to. "ow, B 21 has

made the choice of the database system almost irrelevant from a coding perspective,

which is as it should be. *pplication developers have much more important things to

worry about than the syntax that is needed to port their program from one database to

another when business needs suddenly change.

Through the B 21 *dministrator in 1ontrol anel, you can specify the particular

database that is associated with a data source that an B 21 application program is

written to use. Think of an B 21 data source as a door with a name on it. %ach door will

lead you to a particular database. ;or example, the data source named )ales ;igures

might be a )L? )erver database, whereas the *ccounts ayable data source could refer

to an *ccess database. The physical database referred to by a data source can reside

anywhere on the ?*".

The B 21 system files are not installed on your system by !indows 7. &ather, they

are installed when you setup a separate database application, such as )L? )erver 1lient

or >isual 2asic


14/52

or )L? )erver$. The loading of the B 21 drivers is transparent to the B 21 application

program. 'n a client server environment, the B 21 * ' even handles many of the

network issues for the application programmer.

The advantages of this scheme are so numerous that you are probably thinking there must be some catch. The only disadvantage of B 21 is that it isnGt as efficient as talking

directly to the native database interface. B 21 has had many detractors make the charge

that it is too slow. Microsoft has always claimed that the critical factor in performance is

the quality of the driver software that is used. 'n our humble opinion, this is true. The

availability of good B 21 drivers has improved a great deal recently. *nd anyway, the

criticism about performance is somewhat analogous to those who said that compilers

would never match the speed of pure assembly language. Maybe not, but the compiler #or

B 21$ gives you the opportunity to write cleaner programs, which means you finish

sooner. Meanwhile, computers get faster every year.

.D5C

'n an effort to set an independent database standard * ' for @avaE )un Microsystems

developed @ava atabase 1onnectivity, or @ 21. @ 21 offers a generic )L? database

access mechanism that provides a consistent interface to a variety of & 2M)s. This

consistent interface is achieved through the use of /plug-in0 database connectivity

modules, or drivers . 'f a database vendor wishes to have @ 21 support, he or she must

provide the driver for each platform that the database and @ava run on.

To gain a wider acceptance of @ 21, )un based @ 21Gs framework on B 21. *s you

discovered earlier in this chapter, B 21 has widespread support on a variety of

platforms. 2asing @ 21 on B 21 will allow vendors to bring @ 21 drivers to marketmuch faster than developing a completely new connectivity solution.

@ 21 was announced in March of 5 8. 't was released for a : day public review that

ended @une N, 5 8. 2ecause of user input, the final @ 21 v5.: specification was

released soon after.


15/52

The remainder of this section will cover enough information about @ 21 for you to know

what it is about and how to use it effectively. This is by no means a complete overview of

@ 21. That would fill an entire book.

.D5C 7oa"s

;ew software packages are designed without goals in mind. @ 21 is one that, because of

its many goals, drove the development of the * '. These goals, in conjunction with early

reviewer feedback, have finali ed the @ 21 class library into a solid framework for

building database applications in @ava.

The goals that were set for @ 21 are important. They will give you some insight as towhy certain classes and functionalities behave the way they do. The eight design goals

for @ 21 are as follows4

1. SQL Level API

The designers felt that their main goal was to define a )L? interface for @ava.

*lthough not the lowest database interface level possible, it is at a low enough level forhigher-level tools and * 's to be created. 1onversely, it is at a high enough level for

application programmers to use it confidently. *ttaining this goal allows for future tool

vendors to /generate0 @ 21 code and to hide many of @ 21Gs complexities from the end

user.

. SQL Confo!"ance

)L? syntax varies as you move from database vendor to database vendor. 'n an effort to

support a wide variety of vendors, @ 21 will allow any query statement to be passed

through it to the underlying database driver. This allows the connectivity module to

handle non-standard functionality in a manner that is suitable for its users.


16/52

A. JD#C "$%t &e i"'le"ental on to' of co""on (ata&a%e inte!face%

The @ 21 )L? * ' must /sit0 on top of other common )L? level * 's. This

goal allows @ 21 to use existing B 21 level drivers by the use of a software

interface. This interface would translate @ 21 calls to B 21 and vice versa.

). P!ovi(e a Java inte!face that i% con%i%tent with the !e%t of the Java %y%te"

2ecause of @avaGs acceptance in the user community thus far, the designers feel that they

should not stray from the current design of the core @ava system.

*. +ee' it %i"'le

This goal probably appears in all software design goal listings. @ 21 is no exception.

)un felt that the design of @ 21 should be very simple, allowing for only one method ofcompleting a task per mechanism. *llowing duplicate functionality only serves to

confuse the users of the * '.

,. -%e %t!ong %tatic ty'ing whe!eve! 'o%%i&le

)trong typing allows for more error checking to be done at compile timeE also, less

error appear at runtime.

/. +ee' the co""on ca%e% %i"'le

2ecause more often than not, the usual )L? calls used by the programmer are simple

)%?%1TGs, '")%&TGs, %?%T%Gs and H *T%Gs, these queries should be simple to

perform with @ 21. 9owever, more complex )L? statements should also be possible.

;inally we decided to precede the implementation using @ava "etworking.

*nd for dynamically updating the cache table we go for M) *ccess database.

@ava ha two things4 a programming language and a platform.

@ava is a high-level programming language that is all of the following

)imple *rchitecture-neutralBbject-oriented ortableistributed 9igh-performance


17/52

'nterpreted multithreaded&obust ynamic

)ecure

@ava is also unusual in that each @ava program is both compiled and interpreted. !ith a

compile you translate a @ava program into an intermediate language called @ava byte

codes the platform-independent code instruction is passed and run on the computer.

1ompilation happens just onceE interpretation occurs each time the program is executed.

The figure illustrates how this works.

Fou can think of @ava byte codes as the machine code instructions for the @ava >irtual

Machine #@ava >M$. %very @ava interpreter, whether itGs a @ava development tool or a

!eb browser that can run @ava applets, is an implementation of the @ava >M. The @ava

>M can also be implemented in hardware.

Java Program

Compilers

Interpreter

My Program


18/52

@ava byte codes help make /write once, run anywhere0 possible. Fou can compile your

@ava program into byte codes on my platform that has a @ava compiler. The byte codes

can then be run any implementation of the @ava >M. ;or example, the same @ava

program can run !indows "T, )olaris, and Macintosh.

0etwo! ing

TC'


19/52

header. The header includes the source and destination addresses. The ' layer handles

routing through an 'nternet. 't is also responsible for breaking up large datagram into

smaller ones for transmission and reassembling them at the other end.

>D'

H is also connectionless and unreliable. !hat it adds to ' is a checksum for the

contents of the datagram and port numbers. These are used to give a client server model -

see later.

TC'

T1 supplies logic to give a reliable connection-oriented protocol above ' . 't provides a

virtual circuit that two processes can use to communicate.

Internet addresses

'n order to use a service, you must be able to find it. The 'nternet uses an address scheme

for machines so that they can be located. The address is a A6 bit integer which gives the

' address. This encodes a network ' and more addressing. The network ' falls into

various classes according to the si e of the network address.

/etwor0 address

1lass * uses N bits for the network address with 6< bits left over for other addressing.

1lass 2 uses 58 bit network addressing. 1lass 1 uses 6< bit network addressing and class

uses all A6.

!ubnet address

'nternally, the H"'C network is divided into sub networks. 2uilding 55 is currently on

one sub network and uses 5:-bit addressing, allowing 5:6< different hosts.

)ost address

N bits are finally used for host addresses within our subnet. This places a limit of 678

machines that can be on the subnet.


20/52

Tota" address

The A6 bit address is usually written as < integers separated by dots.

'ort addresses

* service exists on a host, and is identified by its port. This is a 58 bit number. To send a

message to a server, you send it to the port for that service of the host that it is running

on. This is not location transparencyO 1ertain of these ports are 3well known3.

!oc0ets

* socket is a data structure maintained by the system to handle network connections. *

socket is created using the call socket. 't returns an integer that is like a file descriptor. 'n

fact, under !indows, this handle can be used with &ead ;ile and !rite ;ile functions.

Pinclude Qsys types.hR

Pinclude Qsys socket.hR

int socket#int family, int type, int protocol$E

9ere 3family3 will be *;S'"%T for ' communications, protocol will be ero, and type

will depend on whether T1 or H is used. Two processes wishing to communicate

over a network create a socket each. These are similar to two ends of a pipe - but the

actual pipe does not yet exist.

.?ree Chart


21/52


22/52

3view3 rectangle that allows you to select the subset of the time series data to display in

the main chart.

4. Da%h&oa!(%

There is currently a lot of interest in dashboard displays. 1reate a flexible dashboard

mechanism that supports a subset of @;ree1hart chart types #dials, pies, thermometers,

bars, and lines time series$ that can be delivered easily via both @ava !eb )tart and an

applet.

). P!o'e!ty 5(ito!%

The property editor mechanism in @;ree1hart only handles a small subset of the

properties that can be set for charts. %xtend #or reimplement$ this mechanism to provide

greater end-user control over the appearance of the charts.

.2M$ 4.ava 2 Micro edition6&-

)un Microsystems defines @6M% as 3a highly optimi ed @ava run-time environmenttargeting a wide range of consumer products, including pagers, cellular phones, screen-

phones, digital set-top boxes and car navigation systems.3 *nnounced in @une 5 at the

@avaBne eveloper 1onference, @6M% brings the cross-platform functionality of the @ava

language to smaller devices, allowing mobile wireless devices to share applications. !ith

@6M%, )un has adapted the @ava platform for consumer products that incorporate or are

based on small computing devices.

1# 7enera" .2M$ architecture


23/52

@6M% uses configurations and profiles to customi e the @ava &untime %nvironment#@&%$. *s a complete @&%, @6M% is comprised of a configuration, which determines the

@>M used, and a profile, which defines the application by adding domain-specific

classes. The configuration defines the basic run-time environment as a set of core classes

and a specific @>M that run on specific types of devices. !e ll discuss configurations in

detail in the The profile defines the applicationE specifically, it adds domain-specific

classes to the @6M% configuration to define certain uses for devices. !e ll cover profiles

in depth in the The following graphic depicts the relationship between the different

virtual machines, configurations, and profiles. 't also draws a parallel with the @6)% * '

and its @ava virtual machine. !hile the @6)% virtual machine is generally referred to as a

@>M, the @6M% virtual machines, =>M and 1>M, are subsets of @>M. 2oth =>M and

1>M can be thought of as a kind of @ava virtual machine -- it s just that they are

shrunken versions of the @6)% @>M and are specific to @6M%.

2# Deve"opin .2M$ app"ications

'ntroduction 'n this section, we will go over some considerations you need to keep inmind when developing applications for smaller devices. !e ll take a look at the way the

compiler is invoked when using @6)% to compile @6M% applications. ;inally, we ll

explore packaging and deployment and the role preverification plays in this process.


24/52

# Desi n considerations (or sma"" devices

eveloping applications for small devices requires you to keep certain strategies in mind

during the design phase. 't is best to strategically design an application for a small device

before you begin coding. 1orrecting the code because you failed to consider all of the3gotchas3 before developing the application can be a painful process. 9ere are some

design strategies to consider4

U =eep it simple. &emove unnecessary features, possibly making those features a

separate, secondary application.

U )maller is better. This consideration should be a 3no brainer3 for all developers.

)maller applications use less memory on the device and require shorter installation times.

1onsider packaging your @ava applications as compressed @ava *rchive #jar$ files.

U Minimi e run-time memory use. To minimi e the amount of memory used at run time,

use scalar types in place of object types. *lso, do not depend on the garbage collector.

Fou should manage the memory efficiently yourself by setting object references to null

when you are finished with them. *nother way to reduce run-time memory is to use la y

instantiation, only allocating objects on an as-needed basis. Bther ways of reducing

overall and peak memory use on small devices are to release resources quickly, reuse

objects, and avoid exceptions.

+# Con(i urations overview

The configuration defines the basic run-time environment as a set of core classes and a

specific @>M that run on specific types of devices. 1urrently, two configurations exist for

@6M%, though others may be defined in the future4

UConnected Limited Device Con(i uration 4CLDC6

is used specifically with the

=>M for 58-bit or A6-bit devices with limited amounts of memory. This is the

configuration #and the virtual machine$ used for developing small @6M% applications. 'ts

si e limitations make 1? 1 more interesting and challenging #from a development point

of view$ than 1 1. 1? 1 is also the configuration that we will use for developing our


25/52

drawing tool application. *n example of a small wireless device running small

applications is a alm hand-held computer.

U Connected Device Con(i uration 4CDC6 is used with the 1 virtual machine #1>M$

and is used for A6-bit architectures requiring more than 6 M2 of memory. *n example ofsuch a device is a "et T> box.

@# .2M$ pro(i"es

8hat is a .2M$ pro(i"e

*s we mentioned earlier in this tutorial, a profile defines the type of device supported.

The Mobile 'nformation evice rofile #M' $, for example, defines classes for cellular

phones. 't adds domain-specific classes to the @6M% configuration to define uses forsimilar devices. Two profiles have been defined for @6M% and are built upon 1? 14

=@ava and M' . 2oth =@ava and M' are associated with 1? 1 and smaller devices.

rofiles are built on top of configurations. 2ecause profiles are specific to the si e of the

device #amount of memory$ on which an application runs, certain profiles are associated

with certain configurations.

* skeleton profile upon which you can create your own profile, the ;oundation rofile, is

available for 1 1.

'ro(i"e 1& B.ava

=@ava is )un s proprietary profile and contains the =@ava * '. The =@ava profile is built

on top of the 1? 1 configuration. The =@ava virtual machine, =>M, accepts the same

byte codes and class file format as the classic @6)% virtual machine. =@ava contains a

)un-specific * ' that runs on the alm B). The =@ava * ' has a great deal in common

with the @6)% *bstract !indowing Toolkit #*!T$. 9owever, because it is not a standard

@6M% package, its main package is com.sun.kjava. !e ll learn more about the =@ava * '

later in this tutorial when we develop some sample applications.

'ro(i"e 2& MID'


26/52

M' is geared toward mobile devices such as cellular phones and pagers. The M' ,

like =@ava, is built upon 1? 1 and provides a standard run-time environment that allows

new applications and services to be deployed dynamically on end user devices. M' is a

common, industry-standard profile for mobile devices that is not dependent on a specific

vendor. 't is a complete and supported foundation for mobile application

development. M' contains the following packages, the first three of which are core

1? 1 packages, plus three M' -specific packages.

U java.lang

U java.io

U java.util

U javax.microedition.io

U javax.microedition.lcdui

U javax.microedition.midlet

U javax.microedition.rms


27/52

Chapter + Modu"e Description

'mplementation is the stage of the project when the theoretical design is turned out into a

working system. Thus it can be considered to be the most critical stage in achieving a

successful new system and in giving the user, confidence that the new system will work

and be effective.

The implementation stage involves careful planning, investigation of the existing

system and itGs constraints on implementation, designing of methods to achieve

changeover and evaluation of changeover methods.

'ro3ect Imp"ementation Modu"e&-

1# !in "e )op; !in "e Transmission

'n this project we develop a new, quite general model for end-to-end throughput in a

multi hop wireless network. !e term the resulting metric random access transport

capacity since the analysis requires all transmissions to be independent, which precludes

cooperative transmission scheduling among the nodes, since this would generally couple

transmissions and the active transmitter locations would no longer be independent.

9owever, that the model does not preclude cooperative or multi packet reception,

although we do not consider such approaches in this paper. The general model includes

arbitrary paths of hops and an end-to-end delay

2# Mu"tip"e )ops; Mu"tip"e Transmissions per )op Modu"e&

The random access transport capacity for a multi hop wireless network is the maximum

average source to destination rate that can be sustained reliably over a distance with at

most transmission attempts per packet, normali ed by the area of


28/52


29/52

"ode ) checks the table that there is any information of node , which canGt

communicate with infrastructure. 'f it doesnGt have information about node , node )

sends &&%L messages, with sequence number to countermeasure loops, to the

neighboring nodes via broadcast and starts path discovery process. &&%L messages are

sent throughout the network within the predefined time period until it reaches to the

destination node ,

'n emergency situation, a node that canGt communicate with infrastructure turns on *d

hoc mode and communicate with a node who can communicate with infrastructure.

9owever suppose one of the node in the path moves and path is broken. Then a

surrounding node which is the nearest to the node ) broadcasts &&%LSrp message torecover path. Hsing reserve part in the message, it notices to receive nodes that it is for

path. )ee fig given below... &ecovery

+# $nd-to-$nd 7uaranteed De"ivery Modu"e&


30/52

%ach transmission per hop to have independent success probability requires sufficient

diversity in the interference and signal strength per transmission attempt, which could

possibly be achieved through diversity techniques such as frequency hopping.

't follows the square-root scaling law for source-destination transmissions in largewireless networks. That is, unscheduled, channel-blind transmissions can achieve + given

well-positioned relays + a transport capacity that scales the same as optimally scheduled

nearest neighbor routing.


31/52

Chapter @ - !ystem Desi n

Data ?"ow Dia ram < >se Case Dia ram < ?"ow Dia ram

The ; is also called as bubble chart. 't is a simple graphical formalism

that can be used to represent a system in terms of the input data to the system, various

processing carried out on these data, and the output data is generated by the system.

Leve"1

/orma" Transport /etwor0 ?"ow


32/52

Leve" 2

!ome /etwor0 ?ai"ure its usin A"ter path networ0


33/52


34/52

Activity Dia ram&

Path DisconnectedPath Connected to

net!or Monitor

Mess"e #eceived

Mobile Client

Mobile Server

$ntermediate Nodes

Node On/O%% De%ault node On/O%%


35/52

!e*uence Dia ram&

Mobile Server

Message Send

Set De%ault node On/ o%% Message send

Connect Sin Node&ath Created

Mess"e not send

Mobile c lient

Network Monitor

Messa"e #eceived

Messa"e #eceived

messa"e #eceivedAlter &ath

chec Node ca&acit' status

Create Node On/Off

transport capacityIntermideate N odes

Chapter !ystem Testin

!ig"re #


36/52

The purpose of testing is to discover errors. Testing is the process of trying to

discover every conceivable fault or weakness in a work product. 't provides a way to

check the functionality of components, sub assemblies, assemblies and or a finished product 't is the process of exercising software with the intent of ensuring that the

)oftware system meets its requirements and user expectations and does not fail in an

unacceptable manner. There are various types of test. %ach test type addresses a specific

testing requirement.

T '$! ? T$!T!

>nit testin

Hnit testing involves the design of test cases that validate that the internal program

logic is functioning properly, and that program inputs produce valid outputs. *ll decision

branches and internal code flow should be validated. 't is the testing of individual

software units of the application .it is done after the completion of an individual unit

before integration. This is a structural testing, that relies on knowledge of its constructionand is invasive. Hnit tests perform basic tests at component level and test a specific

business process, application, and or system configuration. Hnit tests ensure that each

unique path of a business process performs accurately to the documented specifications

and contains clearly defined inputs and expected results.

Inte ration testin

'ntegration tests are designed to test integrated software components to determine

if they actually run as one program. Testing is event driven and is more concerned with

the basic outcome of screens or fields. 'ntegration tests demonstrate that although the

components were individually satisfaction, as shown by successfully unit testing, the

combination of components is correct and consistent. 'ntegration testing is specifically

aimed at exposing the problems that arise from the combination of components.


37/52

?unctiona" testin

;unctional tests provide systematic demonstrations that functions tested are

available as specified by the business and technical requirements, system documentation,

and user manuals.

;unctional testing is centered on the following items4

>alid 'nput 4 identified classes of valid input must be accepted.

'nvalid 'nput 4 identified classes of invalid input must be rejected.

;unctions 4 identified functions must be exercised.

Butput 4 identified classes of application outputs must be exercised.

)ystems rocedures4 interfacing systems or procedures must be invoked.

Brgani ation and preparation of functional tests is focused on requirements, key

functions, or special test cases. 'n addition, systematic coverage pertaining to identify

2usiness process flowsE data fields, predefined processes, and successive processes must

be considered for testing. 2efore functional testing is complete, additional tests are

identified and the effective value of current tests is determined.

!ystem Test

)ystem testing ensures that the entire integrated software system meets requirements.

't tests a configuration to ensure known and predictable results. *n example of system

testing is the configuration oriented system integration test. )ystem testing is based on

process descriptions and flows, emphasi ing pre-driven process links and integration

points.


38/52

8hite 5o% Testin

!hite 2ox Testing is a testing in which in which the software tester has knowledgeof the inner workings, structure and language of the software, or at least its purpose. 't is

purpose. 't is used to test areas that cannot be reached from a black box level.

5"ac0 5o% Testin

2lack 2ox Testing is testing the software without any knowledge of the inner

workings, structure or language of the module being tested. 2lack box tests, as most otherkinds of tests, must be written from a definitive source document, such as specification or

requirements document, such as specification or requirements document. 't is a testing in

which the software under test is treated, as a black box .you cannot /see0 into it. The test

provides inputs and responds to outputs without considering how the software works.

#1 >nit Testin &

Hnit testing is usually conducted as part of a combined code and unit test phase of

the software lifecycle, although it is not uncommon for coding and unit testing to be

conducted as two distinct phases.

Test strate y and approach

;ield testing will be performed manually and functional tests will be written in

detail.

Test ob3ectives

*ll field entries must work properly.


39/52

ages must be activated from the identified link.

The entry screen, messages and responses must not be delayed.

?eatures to be tested

>erify that the entries are of the correct format

"o duplicate entries should be allowed

*ll links should take the user to the correct page.

#2 Inte ration Testin

)oftware integration testing is the incremental integration testing of two or more

integrated software components on a single platform to produce failures caused by

interface defects.

The task of the integration test is to check that components or software

applications, e.g. components in a software system or + one step up + software

applications at the company level + interact without error.

Test Resu"ts& *ll the test cases mentioned above passed successfully. "o defects

encountered.

# Acceptance Testin


40/52

Hser *cceptance Testing is a critical phase of any project and requires significant

participation by the end user. 't also ensures that the system meets the functional

requirements.

Test Resu"ts& *ll the test cases mentioned above passed successfully. "o defects

encountered.

Chapter E !ystem Imp"ementation


41/52

Chapter F - Conc"usion


42/52

This paper introduced a metric called the random access transport capacity, which is

similar in spirit to the well known transport capacity metric but made more tractable #and

admittedly, less general$ with three admittedly strong assumptions4 #i$ uncoordinatedtransmissions, allowing a oisson interference model, #ii$ equally spaced relays on a line

between the source and destination, which allows identical statistics for each hop, and

#iii$ an iid interference and signal sample for each retransmission, which allows a

geometric distribution to model the number of transmissions required per hop. The

primary benefit of these assumptions is that they allow a closed-form and reasonably

tight upper bound to be derived for the end-to-end throughput in terms of the key network

parameters, which is notoriously difficult to accomplish in a general model.

*lternatively, the approach in this paper can be viewed as a nontrivial extension of the

more recent transmission capacity line of work + all of which is single hop, single

transmission, and not end-to-end + to a multi hop, end-to-end setting where

retransmissions are allowed.

!creenshots


43/52


44/52


45/52


46/52


47/52


48/52


49/52

]


50/52


51/52

Re(erences

5. . (upta and . =umar, /The capacity of wireless networks,3 '%%% Trans. 'nf.

Theory, vol.


52/52

!ites Re(erred&

http4 java.sun.com

http4 www.sourcefordgde.com

http4 www.networkcomputing.com

http4 www.roseindia.com

http4 www.java6s.com
http://java.sun.com/http://www.sourcefordgde.com/http://www.networkcomputing.com/http://www.roseindia.com/http://www.java2s.com/http://java.sun.com/http://www.sourcefordgde.com/http://www.networkcomputing.com/http://www.roseindia.com/http://www.java2s.com/

documentation - random access transport capacity

Documents