Page | 15
Introduction
The Internet has revolutionized the way organizations operate by
providing them with the means for gathering and sharing of
information. As a result, it has become an indispensable resource
for economic growth, prompting the attention of individuals,
organizations and governments all over the world.
As the Internets popularity has increased, so has networked
multimedia applications which place heavy demands on the network in
terms of throughput and responsiveness. While these demands are
easily satisfied on networks with sufficient bandwidth and low
delay, they present a challenge in networks with large
bandwidth-delay products. The latter include links provisioned over
geostationary satellites, where the long distances involved impose
a delay of over 500 milliseconds [38, 1, 36].
Satellite links are the only mode of connecting to the Internet
backbone in areas not served by submarine optic fiber cables.
However, building, launching and operating a satellite is costly,
and they also have a limited operational life span and capacity.
Due to these factors, bandwidth provisioned over satellite links is
more expensive than that on terrestrial links. Consequently,
subscribers of these links are unable to procure enough bandwidth,
leading to sharing of low capacity links by a large number of
users. The satellite part of the link in this case becomes a
bottleneck, leading to deterioration of user perceived quality of
service (QoS).
While most of flows on Internet links are short-lived web data
transfers, a small percentage of users engage in bulk transfers of
data characterized by long-lived flows. Rai et al. [40] estimate
less than 1% of these long-lived flows account for over 50% of the
data downloaded on an Internet link. On low capacity shared links,
the presence of long-lived flows might therefore mean 99% of the
users sharing about half of the link capacity, leading to poor
quality of service. On a University network for example, this may
mean a majority of students failing to access journal and other
educational web sites.
Bandwidth is a measure of the amount of data passing through a
network at a given time. A measure of spectrum (frequency) use or
capacity. For instance, a voice transmission by telephone requires
a bandwidth of about 3000 cycles per second (3KHz). A TV channel
occupies a bandwidth of 6 million cycles per second (6 MHz) in
terrestrial systems. In satellite based systems a larger bandwidth
of 17.5 to 72 MHz is used to spread or "dither" the television
signal in order to prevent interference.
One system or tool is needed to monitor wireless bandwidth.
Wireless bandwidth monitoring solution helps to visualize the
health of wireless network, alerts when problems arise, and tracks
your actual bandwidth usage for verification and planning.
Good wireless bandwidth monitoring software lets you visualize
the health of your wireless network at a glance. Automatic alerts
notify you when bandwidth reaches levels you determine are
unhealthy, whether there's too much traffic or not enough.
This system works out in wireless LAN (Local Area Network)
environment. It used to check bandwidth in LAN (Local Area Network)
which used wireless connection.
We need one system or tool to monitor wireless bandwidth. This
system is developed using Microsoft Visual Basic as new software.
This software installed in one server that will monitor access
point connection. This system will detect which AP is not
functioning well. It means no activities occurred in that AP. It is
also detect if bandwidth is too low or too high. Alert will appear
as massage box and a system will send an email to network admin who
is monitoring that AP.
A number of bandwidth management architectures have been
proposed to provide service guarantees on networks. Examples
include the Doris Omenihu Bandwidth Monitoring System (DOBMS), the
band differentiated services (DiffServ) architecture, Integrated
services (IntServ) architecture and Multi-Protool Label Switching
(MPLS). Internally, DOBMS Bandwidth monitoring is on the basis of
NetFlow and packet sniffer sensors and generally use the host
machine's network card, but can be configured to use monitoring
ports found on some networking devices using port mirroring /
forwarding in order to monitor the overall network bandwidth
utilization.
Due to its support of NetFlow, DOBMS receives preaggregated data
forwarded by NetFlow-capable Cisco devices.
The Diffserv, IntServ, and MPL architectures use admission
control, active queue management, scheduling and constraint-based
routing to control bandwidth utilization. Differentiated services
architecture was proposed to address scalability problems
experienced under IntServ. Despite the said scalability advantages,
DiffServ and similar architectures have not been widely adopted on
the Internet [40, 47].
1.2 PROBLEM STATEMENT
Nowadays, wireless technology becomes more popular in networking
environment. This is because it more simple or easier compare to
wired connection. Wireless connection needs access point to connect
device from server LAN ( Local Area Network ). Access point is a
hardware device or a computer's software that acts as a
communication hub for users of a wireless device to connect to a
wired LAN. Access Point is important for providing heightened
wireless security and for extending the physical range of service a
wireless user has access to.
In the other hand, wireless technology has it's own weaknesses.
One of those weaknesses is there is no connection or connection
down. We can check from that AP in order own to know that access
point has connection or not. By seeing at LED which if it blinking
it's meant that has no problem with that access point connection.
This method much easier if we want to monitor access point. But the
situation will change if it involves a large amount of access
point. It is impossible to check every access point by checking to
each location. It gives more troublesome to network admin if this
case involves wide area or high building.
The other weaknesses are when connection is breaking down at
break time or after office hour. The major problem occurs when
there is no network admin stays at the office after office hours.
This will lead to some problem to those who still need to access to
the internet.
The solution for that problem is to have some software that will
monitor every access point in one server. This system will monitor
each access point and network admin and we will know which one has
problem and need to be repaired. So that, no need for network admin
to check every location. Furthermore, this system will alert
network admin if problem occurs after office hour by sending an
e-mail. Network admin will be alert about that problem and checked
the problem immediately.
1.3 AIM AND OBJECTIVESThe aim of this project was to implement a
bandwidth monitor by way of simulation based on open source tools.
The simulators design was based on data obtained from studying the
Projectcorp Nigeria network.
Combining the passion of wireless technology in this era,
monitoring system to monitor wireless connection is very needed to
avoid any problem involving wireless connection. Based on this
proposed monitoring system, it can be useful to achieve several
objectives which are:
i. To review current literature on bandwidth management
technology;
ii. To study the Projectcorp Nigeria network, with a special
emphasis on flow size distribution;
iii. To design a bandwidth monitor simulator based on data
collected on Projectcorp Nigeria, and techniques available on open
source platforms;
iv. To monitor access point connection automatically. It can
help network admin to monitor large amount of access point and it
will not take much time to monitor all access point in one time.v.
To alert network admin of connection problem. The system will ping
access point any time a network admin want to do that. If access
point does not reply when the system is pinging two times, so the
system will assume that access point is down. This system will send
an e-mail if the connection down after office hours, so that a
network admin can solve the problem immediately.vi. To display
current connection with different color at the interface of the
system. Red side if connection is down or no connection at that
access point, Green side if the connection is doing well. This can
help the network admin to manage the system wisely.vii. To display
current bandwidth with graph. The system will plot a graph
according to the current bandwidth which is through that access
point.viii. To display Log File database. Current connection will
be save in data as a Log File.
ix. To evaluate the performance of the prototype under varying
network loads and conditions.
1.4 SCOPE
This system works out in wireless LAN (Local Area Network)
environment. It used to check the connection in LAN (Local Area
Network) with wireless connection.
This system can be used in faculty especially to monitor
wireless connection or access point status.
This wireless bandwidth monitoring use Microsoft Visual Basic
6.0 as a programming language. It is because VB provides more of
the actual code for a programmer than any other non-visual
programming language. The structure of the Basic programming
language is very simple, particularly as to the executable code.
The graphical user interface of the VB-IDE provides intuitively
appealing views for the management of the program structure in the
large and the various types of entities (classes, modules,
procedures, forms etc.). This system will build from VB code to
develop an interface to easier network admin to monitor.
This system will use windows XP Professional server as a
platform. This system also can alert network admin by sending an
e-mail to inform about that problem.
1.5 PROJECT SIGNIFICANCE
Other system for wireless monitoring is already developed and
already sold in the market. But this system has it's own advantages
from other wireless monitoring which is already developed
before.
Even though there are many software for monitoring wireless
connection in the market, still have organization is not used any
system to monitor their wireless connection. This most bind up
small organization because it difficult to manage and need someone
expert to manage. But this system is easy to use and not need an
expert to manage or monitor that system. Ordinary network admin can
manage and handle that system.
By using this system, the network admin can monitor access point
easily especially in handling a network for one high building. It
is troublesome for him to check each location every day to
ascertain every access point have connection. With this system the
network admin only needs to monitor each access point only from
server and knows if occurs some problem with connection.
This system will make network admin alert 24 hours per day. If
connection down or connection problem, the system will alert
network admin by sending email. That email contains time connection
down and the location.
Current connection will be saved in log file. This is very
useful for network admin to print out the connection status to give
a report to a manager in weekly meeting if he is telling to do
that.
Compare to other wireless monitoring system, this system has a
simple interface to monitor wireless connection and easier for
network admin to monitor access point with simple button or simple
interaction from network admin. This interface is user friendly for
network admin to manage and understand. Furthermore it give only a
short time to master that interface.1.6 LIMITATIONS
We were faced with an uphill task of coming out with an
unequivocal picture of what was expected to be done concerning the
project i.e. the objectives and scope of the project itself prior
to the commencement of the research process.
During the research process up to the moment of documentation,
we encountered the following ugly but inevitable limitations, which
posed a threat to the successful completion of the project. These
limitations in one way or the other impeded the research process
and they include amongst others.
TIME CONSTRAINTS: Because the project must be conducted and
completed within a specified time and date, we had to cut down on
some of the objectives of the study and came out with the scope as
described in sections 1.4 to forestall any form of uncertainty and
to avoid running behind schedule. Therefore, an in-depth research
into this topic was not fully carried out.
Unavailability of sufficient information on simulators and
network technologies was also among the list of our limitations.
This was as a result of the inability of the various information
personnel's of the various institutions and organizations visited
to exercise their prerogative to supply us with the needed and for
required information.
Contacts with each other was not that much and therefore,
created what seemed to be a laxity problem among the researchers
resulting to the seemingly endless nature of the research work.
Financial constraints: Arising from the lean resources available
to facilitate and boost the research process had a knock on effect
on the research process thus, making it almost impossible to
carryout a full and empeakable research work on the topic.
1.7 ASSUMPTIONS
The researchers worked on the research process with the
following assumptions.
That most organizations have some forms of network with extended
services in place.
That only a distributed resource management approach can really
be used to achieve and improve the use of network resources
efficiently when simulated.
That the bridge network simulator is sufficiently enough to do
the simulation
1.8 Definition of TermsChapter Two2.1 Bandwidth Management
Mechanisms
Bandwidth management is a means of allocating bandwidth
resources to critical applications on a network to meet the
organizational objectives. Without bandwidth management, an
application or a user can take control of all available bandwidth
and prevent other applications or users from using the network.
Because it is impossible to differentiate between types of network
traffic, it is also impossible to control which users or
applications have priority on the network. Applications can also
require a specific quantity and quality of service, which cannot be
predicted in terms of available bandwidth. This can make some
applications run poorly if bandwidth is not properly allocated to
them when necessary.
Bandwidth management can be done in different ways. In the
network layer this is done in routers using traffic shaping and
rate limiting techniques. In some instances specially designed
devices are used for bandwidth management. Queuing algorithms are
the fundamentals of these specific bandwidth management products.
Bandwidth management is done in the application layer using proxy
servers.
With high growing demand for Internet like 165% [3], bandwidth
management has become an interesting research area. Today the
web-based applications require more bandwidth and it is difficult
to predict the required bandwidth amount for a certain user at a
given time. With this behaviour of the web applications, managing
network bandwidth has become a critical task for all the service
providers. As described in [4] new concepts and formulas are used
and tested for bandwidth allocates. Especially because of the
unpredictability of bandwidth usage, bandwidth management is always
a new field for researches and experiments.
Currently used bandwidth management mechanisms are described
under the following sub headings.
2.1.1 Traffic Shaping and Rate Limiting
Traffic shaping and rate limiting are used in routers and
operate as network layer bandwidth management techniques. Traffic
shaping provides a mechanism to control the amount and volume of
traffic being sent into a network, and the rate at which the
traffic is being sent. For this reason, traffic shaping schemes are
implemented at the network edges to control the traffic entering
the network. It also may be necessary to identify traffic flows at
the point at which traffic enters the network, with a granularity
that allows the traffic-shaping control mechanism to separate
traffic individual flows and shape them differently. A
before-and-after example [5] of how traffic shaping works is as
follows.
Before traffic shaping: 10 packets in the first second, 0
packets in the second second, 10 packets in the third second, 0
packets the forth second.
After traffic shaping: 1 packet per 0.2 seconds.
To accomplish this, queues and classes are used. Before a packet
is sent out to the Internet, it is analyzed to some extend and
based on a set of conditions, might end up on one of the many
queues. These queues are connected to a hierarchy of classes,
forming a tree. After landing in its final destination the packet
moves up the hierarchy until it reaches the interface and is sent
out.
Technically, traffic shaping can be used on both incoming and
outgoing packets, but is typically implemented just on the outgoing
[6]. This is because user can't control what is sent to his/her
network and there is little point in building an incoming queue and
keeping packets in there even though they could be dealt with right
away. On the other hand outgoing packets can leave only at the
connection speed and queue up while incoming packets have already
come in at connection speed. Sometimes incoming packets are dropped
to reduce the speed of some connections, which is called policying.
Usually, shaping incoming packets is done indirectly through the
outgoing queues When traffic-shaping boxes are used, wide area
(Internet) bandwidth can be actively managed to limit traffic in
several different ways[7]:
1. Per-application rules. Traffic shapers can identify and
categorize specific types of network traffic, constraining each
particular category of traffic to use no more than a specified
amount of bandwidth. For example, administrator may have
hypothetically defined a rule that limits aggregate FTP traffic to
no more than 6 mbps and another rule that limits total streaming
audio traffic to no more than 3 Mbps, etc.
Traffic shapers can categorize traffic based on macroscopic
characteristics, such as the traffic's protocol (IP, IPX,
AppleTalk, DECNet, etc.), the ports an application is known to use
(for example, Kazaa typically runs on port 1214), or on the basis
of connections to a particular well-known host (such as a central
game server), etc. Traffic can also be categorized based of the
content of the flow regardless of the flow's macroscopic
characteristics. For example, most traffic shapers can easily
identify and automatically categorize web traffic based on the
negotiations that take place between a web server and a web browser
when a page is requested, regardless of whether the web server is
running on port 80 (the default) or some other nonstandard port.2.
Per-user rules. Traffic shapers can set per-user traffic limits to
ensure that network traffic is shared fairly among all users. For
instance, administrator might decide to use a per-user rule that
limits traffic to or from each user to no more than 256Kbps (giving
them DSL-like service). When traffic is limited in that way, a user
can still access whatever he or she wants, but the flows are
"smoothed out" to a specified level rather than attempting to use
all or much of the total available network capacity campus
wide.Traffic limits can be either "hard" or "burstable." A hard
limit is a fixed ceiling that cannot be exceeded. Burstable limits,
on the other hand, allow traffic to exceed the base threshold value
at least up to a specified "burst limit", as long as capacity
remains available and there is no higher priority application
pre-emptively claiming that capacity.3. Priority management. In
addition to setting hard or burstable traffic limits on a
per-application or per-user basis, traffic shaping devices can also
be used to define the relative importance, or priority, of
different types of traffic. For example, in an academic network
where teaching and research are most important, recreational uses
of the network (such as network games or peer-to-peer file sharing
application traffic) can be allowed bandwidth only when higher
priority applications do not need it. Some traffic shaping tasks
can be done directly on a regular Cisco or Juniper router, just as
a router can also be used to do some firewall-like packet filtering
tasks.However, specialized traffic shapers, like any specialized
devices, can be optimized to specifically and efficiently handle
their unique responsibilities. Specialized devices also typically
have different mechanisms to be used when dealing with problems in
their special area of expertise. Doing traffic shaping on a
dedicated traffic shaping box also avoids loading up routers with
other tasks, leaving the router free to focus on doing its job of
routing packets as fast as it can.Primary technology used in
traffic shaping is TCP rate limiting. It is a technique that paces
traffic by faking out the transmitter by artificially changing TCP
window and pacing ACKs, effectively throttling the traffic. Though
rate limiting is used in many bandwidth management technologies, it
has some drawbacks, which affect the entire network. For example if
the rate limit size of the window is set to a smaller value than
the size of the actual data packet, the number of packet in the
network will be increased as well as the network traffic [8].
Another limitation on rate limiting is its incapability of working
on encrypted data packets. Since the TCP header is hidden in these
data packets, rate-limiting technique cannot be applied for
bandwidth management. As the techniques like IPSec is utilized more
and more in the data, the effectiveness of TCP rate limiting will
reduce proportionally.
A good practical example of bandwidth management using hard rate
limits and traffic shaping is described by Deke Kassabian [9].
According to him, this methodology has been used to increase the
efficiency of bandwidth usage of more than 48,000 clients.
According to the senior network administrator of the University
of Pennsylvania they have applied bandwidth limits on IP address
ranges in outgoing direction using firewall filters in high-end
routers. In the initial stage they limited the outbound bandwidth
to a pre-defined value (4Mb/s for 256 IP address) and gradually
changed to an optimum value (400 kbps for one IP address). They
believe this mechanism is more effective and suitable for their
requirements than application level bandwidth management
techniques.
2.1.2 Queuing Mechanisms Used in Bandwidth Management
Queuing is the reordering of traffic packet after their arrival
and dispatching them in the new order, favoring desirable traffic.
The most commonly used queuing techniques used in bandwidth
management are Class Based Queuing (CBQ) and Fair Queuing. The CBQ
is commonly used in many low-end bandwidth management products [8].
In this mechanism, the data packets are categorized into user
defined classes and the queues are maintained for each class. The
data in these queues are sent out according to the time schedules
and prioritized by processing the queues at specific intervals.
With these queues, the high-prioritized data frames are always sent
out before the low prioritized data. The negative of the CBQ is
that it introduces latencies to entire traffic. It is also not
practical to have a very large number of classes (queues) due to
excessive overhead and loss of precision. Also when the number of
classes is high, the efficiency of the management decreases.
Fair queuing is a similar technique that attempts to allocate
bandwidth based on the usage by individual flows. Its based on the
relative allocations rather than the priorities. "Flows" are simply
a property of a larger entity, as each entity can have any number
of flows. Also, like CBQ, Fair Queuing works well in environments
where there are a small number of users and a small number of
definable flows But has problems when the number of flows is
increased.
2.2 Previous Research on Bandwidth Management on Proxy
servers
When considering application level bandwidth management
mechanisms, much research has been done on proxy servers. The
system implemented by Austin Poulton,
Peter Clayton & FF Jacot-Guillarmod, is a proxy server which
is capable of providing bandwidth management control and pricing
based on the priority policies specified by the network
administrators. The priority policies allow network administrators
to control congestion, provide users with incentive to limit their
usage and account for service provider cost [10]. Here also, the
user involvement in allocating bandwidth is minimum since the
bandwidth is set according to the predefined priority policies, by
the network administrators.
The concept of dynamic bandwidth allocation through delay pools
was introduced by the network research team of the University of
Moratuwa. The papers [11,12] describe the complete technology and
it has been implemented in the University network since 2002. This
research also uses this delay pool concept as the base and
introduces the concept of managing bandwidth on user demand and
request.
The concept of bandwidth sharing in hierarchical proxies is
described in paper [12].
This concept is also an extension of the delay pool concept. It
describes a way of sharing Internet bandwidth among proxies A
practical implementation of this system is available in the
University of Moratuwa.
2.3 Wireless Standard
As you probably know, 802.1l a and 802.11 b each define a
different physical layer. 802.1lb radios transmit at 2.4 GHz and
send data up to 11Mbps using direct sequence spread spectrum
modulation; whereas, 802.11 a radios transmit at 5 GHz and send
data up to 54 Mbps using OFDM (Orthogonal Frequency Division
Multiplexing).
Of course the superior performance of 802.11a offers excellent
support for bandwidth hungry applications, but the higher operating
frequency equates to relatively shorter range. I've seen
demonstrations of 802.11a radios delivering 54Mbps with distances
of about 60 feet, which is far less than the 300 feet or so that
you'll have with 802.1lb systems. As compared to 802.1lb, you'll
need a much larger number of 802.1la access points to cover a
facility, especially large ones.
The different radio frequency and modulation types of 802.11a
and 802.11b causes them to not interoperate. For example, an end
user equipped with an 802.11a radio card will not be able to
connect with an 802.1lb access point. The 802.11 standard offers no
provisions for interoperability between the different physical
layers.
802.1lg is an extension to 802.11b, the basis of the majority of
wireless LANs in existence today. 802.11g will broaden 802.11b's
data rates to 54Mbps within the 2.4GHz band using OFDM (orthogonal
frequency division multiplexing) technology.
Because of backward compatibility, an 802.11b radio card will
interface directly with an
802.1lg access point (and vice versa) at 11Mbps or lower
depending on range. Range at
54Mbps will likely be less than existing 802.11b access points
operating at 11Mbps. As
a result, don't count on upgrading your existing access points
that currently provide 11Mbps throughout all areas.
Similar to 802.11b, 802.1lg operates in the 2.4GHz band, and the
transmitted signal uses approximately 30MHz, which is one third of
the band. This limits the number of non-overlapping 802.1lg access
points to three, which is the same as 802.11b. This means that
you'll have the same difficulty with 802.1lg channel assignment as
you do with 802.1lb when covering a large area where there is a
high density of users. The solution of course is to lower the power
of each access point, which enables you to place access points
closer.
Wireless standard compatibility list is like below:Chapter
Three
3.0SYSTEM ANALYSIS
Since, it is an application development project; a number of
existing applications were preferred. Bandwidth Monitor Pro and Net
Limiter were used to get some extra ideas about the software we
made. We tried to include all the necessary features that a
complete bandwidth monitoring system should have. We have built
this software on Java on Windows operating system and thus it will
be platform independent i.e. it will work on different other
operating systems like Windows, Linux, etc.
For doing this project, we took reference from books like, Head
First Java, OReilly. Also some reference tutorials were used to get
some knowledge to complete this project.
Since this project required some knowledge about networking, we
also studied basics of computer networking which in some way helped
us making this software even better.
3.0.1 Existing Bandwidth Monitoring Tools
Bandwidth Monitor Pro Bandwidth Monitor Pro is a utility that
displays and logs your network adapters bandwidth usage. It
supports logging of all your network adapters at once and has a
detailed transfer history.
Included is an advanced alert system where you can set up rules
to execute various actions like send e-mail, play sounds, and
execute files, shutdown, etc. when certain conditions are
meeting.
You can let Bandwidth Monitor Pro run in the background and it
will log all your incoming and outgoing traffic for you to view
later in the transfer log, or in real time if you wish. (Helleseth,
2000-2005)
NetLimiter NetLimiter is an ultimate internet traffic control
and monitoring tool designed for Windows. You can use NetLimiter to
set download/upload transfer rate limits for applications or even
single connection and monitor their internet traffic. Along with
this unique feature, NetLimiter offers comprehensive set of
internet statistical tools. It includes real-time traffic
measurement and long-term per-application internet traffic
statistics
There are 3 NetLimiter editions available, Pro, Lite and
freeware Monitor. (NetLimiter, 2003 - 2008)
3.0.2 APIs used Jpcap To capture network packets in our Java
program, we needed a help because no parts of the core Java API
give access to low-level network data. However, Jpcap is a Java API
that provides us with this access on Windows or UNIX systems. Jpcap
isn't a pure Java solution; it depends on the use of native
libraries. On either Windows or UNIX, we must have the required
third-party library, WinPcap or libpcap respectively.
Jpcap uses an event model to allow us to process packets.
2.2.2 Jfreechart Jfreechart is an open-source framework for the
programming language Java, which allows the creation of complex
charts in a simple way. Jfreechart also works with GNU Classpath, a
free software implementation of the standard class library for the
Java programming language. Jfreechart supports a number of various
charts, including combined charts. Following chart types are
supported:
X-Y charts (line, spline and scatter).
Pie charts
Gantt charts
Bar charts (horizontal and vertical, stacked and independent).
It also has built-in histogram plotting.
Single valued (thermometer, compass, speedometer) that can then
be placed over map.
Various specific charts (wind chart, polar chart, bubbles of
varying size, etc.).
JFreeChart automatically draws the axis scales and legends.
Charts in GUI automatically get the capability to zoom in with
mouse and change some settings through local menu. The existing
charts can be easily updated through the listeners that the library
has on its data collections.3.1 METHODOLOGY FOR FACT FINDING
Another methodology was to investigate written materials and
excerpts, which include downloads from notable authors. However, a
top down methodology was used during the research process. This was
because when eventually, the project becomes feasible and is
implemented; it would ultimately be managed by the Companies.
Therefore, informed the choice of the top down approach to
information gathering.Fact-finding is an important activity in
system investigation. In this stage, the functioning of the system
is to be understood in order to design the proposed system. Various
methods are applied for this and these fact-finding techniques are
described as below:
Document review - The researcher has reviewed the document
include security reports, system guideline of the system being
used.
On-site observation - The observation of current operating
procedures had been. First-hand knowledge of the activities,
operations, processes of the system on-site was obtained.
Internet research - The major source of the Internet research is
Universiti Teknologi MARA (UiTM) digital library and Google Books
as they offer great volume of books, journals and articles that
related information.
Interview interviews technique had been done with the potential
users to collect information about the current system. The areas of
misunderstanding, unrealistic exception and descriptions of
activities and problems were discovered along with resistance to
the new proposed system.
3.1.1 Semi-structured interview
The semi-structured telephone interview is designed to
qualitatively analyze respondents views on OEMSs adoption. It is
used to verify and understand the data collected from the survey.
In this research, a total of 10 top managers were interviewed
independently. People, within the event management industry, who
had previous experience with ecommerce, were chosen for the
semi-structured interview. Interview time varied in length from 15
to 30 minutes. The interview was recorded by note taking. The
interview was made up of questions relating to economic and
business factors affecting the adoption of OEMS within the Event
Industry.
The also study involved a personal interview of some notable
Telecom institutions staff members such as the operation manager,
secretary, as well as other staff members. Also interviewed were
members of the public/subscribers of gsm networks.
3.1.2 Document Analysis
The researcher investigated written materials and excerpts,
which included downloads from notable authors.
Information about Bandwidth management and monitoring were
gathered from documents such as companys annual report, journals,
and industry magazines. This provided better understanding of the
research problem and findings. Books about the telecom industry
were searched, we were able to get a broader view and a deeper
understanding of the industry this way. Also, web pages of telecom
operators were accessed from the Internet in order to get latest
information about the companys activities, services offered and
future services being planned.
3.2 GENERAL OVERVIEW OF THE SYSTEM
DOBMS is a utility that monitors and saves your computers
internet bandwidth usage. It supports recording of all your network
adapters at once and has a detail data transfer history. You can
let IBM run in the background and it will save all your incoming
and outgoing data transfer for you to view later in the transfer
log or in real time in a graphical way. With DOBMS you can see in a
dashboard that how much of your bandwidth is being used.
Features: Displays data in both bit and byte values. After
monitoring, DOBMS will make the user flexible by displaying data
byte by byte or bit by bit per seconds.
Detailed transfer history. Database is used to keep records.
Customizable layout. Different layout facilities will be
available as per the users wish. It provides different attractive
views.
Customizable colors and fonts. Also provides the different
features of color changing facility.
Auto start with windows. DOBMS need not to be loaded frequently
it has the feature of auto loading as the window starts and also we
can turn off the option as per the users wish.
Always on top.
3.2 Organizational Structure
3.3 Objectives of the Existing System
The objectives of the existing system are as follows:
1. Ensure the proper use of network bandwidth,2. Provides
flexibility in meeting management and reporting requirements of the
companies,
3. Provide timely information for effective decision making,
4. Maintains an up-to-date database so that the system can
function on a daily basis.
3.4 Input Process And Output Analysis
The input, process and output sub systems of the conventional
DSS information system being used by both tcorp and projectcorp are
treated below.
3.4.1 Input Analysis
The input specification here refers to the data coming from your
computer or network being used. The data include search queries by
the user and/or those automatically sent by the system
(Computer/network) behind the scene, once connected the
network.3.4.2 Processing Analysis
The monitor has DataMonitor class provides a container for
holding byte counts of data (either inbound or outbound), along
with corresponding start and stop times. The start and stop times
log the time interval for the data transaction. The DataMonitor
provides an addSample() method for adding bandwidth measurement
samples. Each of these samples is interpreted as being the number
of bytes processed since the last sample, and the time interval
during which the data was processed. Once a number of samples have
been collected by the DataMonitor, it can be queried for statistics
about the historical data rate. In this example we only show three
methods offering basic measurements of data throughput: one
provides the average data rate for all samples stored in the
monitor (getAverageRate()), another provides the data rate for any
given sample stored in the monitor (getRateFor()), and the third
returns the data rate for the last sample stored
(getLastRate()).3.4.3 Output Analysis
The output specification for the Bandwidth simulator includes
the following.
Average data throughput rate over a given time period
Total data throughput over a given time period
Estimate of time until a given amount of data will be
available
Other first- and second-order statistics on data rate and
throughput over time (variances, median rate, data "acceleration,"
or change in throughput rate, etc.).
3.5 Information Flow Diagram
Deliberately omitted
3.6 Problems of Existing System
Below are some of the problems identified with the existing
system
1.During investigation it was noticed or discovered that much
time is wasted while recovering report related documents,
2.Loss in transit of DSS reports during delivery as well as
delay in delivery or lack of delivery is usually a regular
occurrence,
3.Lack of real-time online information processing,
4.Lacks real-time online reporting mechanism, and
5.Lack of trained attendants or specialists.
3.7 Justification for the New System From the analysis of
existing systems done so far, and the problems associated with them
as observed, it becomes obviously important and necessary that a
new system be designed to handle some is not all of the problems
associated with the existing systems.
The current system being developed would go a long way to
satisfy the present need of network resource management. Thus it is
expected that the network Bandwidth simulator to be developed would
be able to amongst others achieve the following objectives.
Support different routing and admission control algorithms
Dynamic bandwidth management and fast restoration mechanisms
Facilitate the development and testing of various mechanisms
used or fund in a distributed system.
The network Bandwidth simulator can be compared with the
existing systems in terms of its performance, comparingly. The new
system ensures speed, accurate calculations, efficiency, and
reliability. It is above all expected to allow for the simulation
of many work groups of the same topology or configuration connected
to each other via the BANDWIDTH.
Chapter Four 4.0 Design of The Simulator This chapter addresses
issues bordering the proposed design called DOBMS, which include
output/input and design specifications, file design strategy, and
system requirements. Following a thorough examination of the old
system and the information needs of both researchers and the
general public, the following specifications, requirements, and
design standards, which are explained in the following sections,
were put together for the new system.
4.1 Design Standards
Two major considerations were taken into account when designing
the simulator. First, the simulator had to be robust and had to be
easily extensible to provide functionality for other projects. In
other words, we wanted to build a general purpose real-time network
simulation framework. We did this by implementing the basic
structure of the simulation in as general a way as possible, and
provide an interface to the user from which to derive an
application-specific actor class from an abstract item class. This
provides the necessary interface to interact with the rest of the
simulation framework. The user can make the actors perform as
required by designing application-specific handler methods. This
was proven to work, and DOBMS was successfully used in another
project [8].
Second, the simulator had to be as efficient as possible. Since
we are simulating a cloud computing environment, we must to be able
to simulate a very large number of actors. Our simulations have
successfully simulated more than a million actors, at which stage
the performance of the server deteriorates.
4.2 OUTPUT SPECIFICATIONS AND DESIGN
The output in whichever case (soft or hardcopy), must contain
information about the following field items:-
1. Amount of Data Sent
2. Amount of Data Received/Downloaded
3. Estimated Download Speed
4. Estimated Upload Speed
4.3 INPUT SPECIFICATIONS AND DESIGN
As stated in chapter three, the input specification here refers
to the data coming from your computer or network being used. The
data include search queries by the user and/or those automatically
sent by the system (Computer/network) behind the scene, once
connected the network. It also include some settings that may be
associated with the monitor.
Figure 4.3 DOBMS Input interface design
4.4 FILE DESIGN
Two file designs were use in the project. One called DOBMSDB
created with MySQL is to serve as the database back-end file while
the other called Report.rtf in richly formatted text format, is
internally generated by the software itself to serve as the
printable version of the records in the database Back-end file and
is compatible with Microsoft word of any version and other
available word processing software document templates. The Back-end
database file design structure is as below
4.4.1 File Design Structure
DOBMS Login profileFiled NameData TypeSize
Username
Password
StatusText
Text
Text25
50
8
Table 1 DOBMS Login profile
4.4 Procedure Chart
4.5 System Flowchart
4.6 System Requirements The system requirements for deploying
the simulator is grouped into two main categories thus:
Hardware requirements and
Software requirements
4.6.1 Hardware Requirements This category of requirements is
basically the physical components of the computer, which would be
used to aid the design of the network simulator. These include
amongst others.
Pentium Core 2 Duo Computer with the following
configurations
SVGA Card 2 MB RAM or more
500GB space in HDD and above
CDROM
Enhanced or windows keyboard
Serial mouse
Laserjet or inkjet printer
1000 VA UPS
4.6.2 Software Requirements The software requirements are that
those used during the development phase as well as the deployment
phase. These include:-
Operating system such as
Windows 2000, XP, Vista or
Linux (RedHat, Fedora, or Free BSD)
Microsoft Data Access Component 2.0
MySQL Database Server
Web server
McAfee Antivirus or any other with up-to-date virus
definition
4.6.3 Operational Requirements
5 Internet Ready Resource Centers
1 Executive Table and chair for the manning Personnel
Well cable trenched
Air conditioners
Well-floored with tiles
Fire extinguishers etc
4.6.4 Personnel Requirements
The resource centre where this installation would be made should
have at least, three to five personnel with one technologist as the
head.
4.7 IMPLEMENTATION
The monitoring system is based on the client server model. Each
virtual machine in the cloud runs the client application, while one
server is run for each cluster of physical machines reporting to a
single aggregation router. The reason for running multiple servers
is two-fold. First it reduces the workload on each server. Second,
by examining each cluster individually, and throttling the
bandwidth for each cluster separately, the network usage of the
entire cloud will also be controlled. As mentioned above, since
broadcasting is not allowed, the clients have to be set up manually
to know which server is responsible for it.
A user can interact with the cloud either via a web interface,
or the SSH protocol. Since each physical machine may run multiple
virtual machines, there is no guarantee that all the virtual
machine instances on any physical machine belong to the same user.
By requiring each virtual machine to monitor its own traffic, the
distinction between users is automatically made.
Implementation is the process of writing, testing,
debugging/troubleshooting, and maintaining the source code of
computer programs. This source code is written in a programming
language. The purpose of programming is to create a program that
exhibits a certain desired behavior. Coding requires expertise in
many different subjects, including knowledge of the application
domain, specialized algorithms and formal logic.
The proponents used PHP for the coding and the interface, and
for the system to be available online, the proponents uploaded it
to qsh.com. Upon being uploaded, errors were expected to emerge
since the codes must also be compatible with the technology that
the host website supports, further debugging was done until there
are no errors found.
This Section will focus on the process of replacing the existing
system with the proposed one by way of program flowchart and
Pseudocode. First a production of a program flowchart which depicts
the arrangement and approach of the program to solving the given
problem is necessary. A Pseudocode is further written to explain
and provide a deeper understanding of the flowchart.
4.7.1 Program Flow Chart
4.7.2 Pseudocode
Login
If login Succeed then
Splash Screen
Display Main DOBMS IDE
Select menu option
If option = DOBMS then
If DOBMS = New Records then
(Perform New DOBMS Operations)
ElseIf DOBMS = Submit then
(Perform Save Operations)
ElseIf DOBMS = Reset then
(Unload Info active window)
ElseIf DOBMS = Print then
(Print Select Report)
ElseIf DOBMS = Exit then
(Perform clean up Operations)
(Unload all windows)
(End)
End If
ElseIf option = Edit then
If Edit = DOBMS Info then
(Perform DOBMS Updates)
ElseIf Edit = Delete then
(Delete Selected Record)
ElseIf Edit = User Settings then
(Update User Profile)
End If
ElseIf option = View then
(Display Records)
ElseIf option = Help then
(Display How to)
End If
End If
ElseIf Login Fails then
If retry = yes then
Goto login
Else
End
End If
End If
4.8 CODINGThe source program is the set of coded instructions,
which is to be used for implementing the new web-based Bandwidth
Monitoring system. See the printed appendix for the source
codes.
Several factors played a major role when the choice of
programming language was being considered. These factors included
cryptographic security implementation, versatility, portability,
efficiency, conformity to object oriented programming models and
flexibility. PHP and MySQL seem to comply with those
requirements.
4.9 SYSTEM REQUIREMENTS
The system requirements are classified into software, hardware,
operational, personnel, and environmental requirements.
4.9.1 Software Requirements
Operating system such as
Windows 2000, XP, Vista or
Linux (RedHat, Fedora, or Free BSD)
Microsoft Data Access Component 2.0
MySQL Database Server
Web server
McAfee Antivirus or any other with up-to-date virus
definition
4.9.2 Hardware Requirements
Pentium Core 2 Duo Computer with the following
configurations
SVGA Card 2 GB RAM or more
500GB space in HDD and above
CDROM
Enhanced or windows keyboard
Serial mouse
Laserjet or inkjet printer
1000 VA UPS
4.9.3 Operational Requirements
5 Internet Ready Computers Centers
1 Executive Table and chair for the manning Personnel
Well cable trenched Office Apartment with IT Personnel
4.9.4 Personnel Requirements
The people involved in the development and maintenance of the
system are the following:
System Administrator
The system administrator maintains and operates the computer
system and/or network. The system administrator is usually in
charge with the installation, support, and maintenance of servers
or other computer systems. He is also in charge with the plan and
response to service outages and other problems.
The systems administrator could also do scripting or light
programming, project management for systems-related projects,
supervising or training computer operators, and being the
consultant for computer problems beyond the knowledge of other
staffs in the Information Technology Department.
The system administrator must have pertinent knowledge on
network and database administration.
Systems Programmer
The systems programmer is responsible for the efficient
performance of the computer systems that are being used for the
enrollment system. The systems programmer would not always write or
create programs for Projectcorp Nigeria Nigeria; programmers would
also perform other tasks such as act as technical advisors to other
operations personnel, continuously look for further improvements in
the system if there could still be any, and recommend conversion if
possible in order to optimize the performance of the system. The
systems programmer must have the knowledge on PHP and/or ASP.Net,
MySQL SQL server. The systems programmer must also be proficient in
Microsoft Visual Web Developer or the Microsoft Visual Studio.
Since there would also be a need to improve the interface of the
system, the programmer is also expected to be proficient in
Macromedia Dreamweaver, Fireworks, and Flashor any software that
have the same purpose like Adobe Photoshop or SWiSHmax.
Trainers
The system trainers would be the one to educate or teach the
users (IT Personnel and Administration) on how to use the system
properly. The trainers could be one of the IT personnel of
Projectcorp Nigeria that has the skills to efficiently relay the
instructions needed by the users and future users of the system.
Ideally, the programmers are the trainers of the users of the
system because of the pertinent knowledge of the system.
User
The users are those who will get the first hand encounter with
the Bandwidth Monitoring System. The users should be trained on how
to use the system and how to access it. The users should also be
informed of the different access levels that are present in the
proposed system. The users are expected to be computer literate
especially internet-wise.
4.9.5 Environmental Requirements
Dust free Air conditioned Office Apartment
Well-floored with tiles
Fire extinguishers etc
4.10 TESTING
The testing process of DOBMS was split into two major portions
where:
The first part of this process involves testing the compliance
of the application against the functional requirements.
The second part of the testing process is concerned with aspects
such as performance and efficiency.
4.10.1 Application Functionality Testing
A major portion of the application functionality was tested
whilst the system was being built. This involved the use of
structural or white box testing on completion of each functional
unit, by using the underlying knowledge of the code. The aim of
this approach was to test boundary and decision conditions within
the code. Furthermore, no formal documentation was produced for
this part of the testing process.
On completion of DOBMS, the black box testing method was applied
to develop a set of test cases. Usually, for specification based
testing methods some sort of formal specification is written.
However, for DOBMS no formal specification was provided because
writing a formal specification would have meant spending less time
on building the system.
For each functional unit categories, partitions and constraints
were identified and then written in a test specification language.
For instance, code for a user logging in can be seen in Appendix
A.
Each test frame contains set of values that need to appear in
test cases. However, the generated values are not in a format that
matches the systems requirements and therefore need to be
reformatted to produce actual sets of input values that are to be
included in the test case. Examples of test cases produced from the
Log in.frm are given in Table 4.1.
Table 4.1 testing the login page4.10.2 Performance Testing
This part of the testing process involved the use of a load
testing application to simulate server usage at different loads.
The aim was to ensure that DOBMS will have a good response time
during usage. Here, response time means the time it takes between
initial request and complete download of response i.e. rendering of
an entire web page.
It is possible to test the performance of DOBMS using testing
software like OpenSTA.
Because of the license requirement to download from the
internet, the developer of DOBMS use a simple way of testing on
different machine.
All tests were carried out by using the following specification
machine, with the DOBMS website and load testing tool present on
the same machine:
Processor: 2 GHz
Memory: 512 MB
Operating System: Windows XP
Overall, all the testing conducted to test the functionality of
the application led to a single conclusion that DOBMS is compliant
with the functional requirements detailed in the Requirements and
Analysis stage. It was also felt that DOBMS would perform
substantially better as compared to its performance during the
testing process mainly because of the following reason:
The machine on which DOBMS was hosted during testing cannot
achieve the same performance level as a highend web server because
the server would have a faster processor and a lot more memory.
Furthermore, during performance testing the load testing
application was also being run on the same machine as DOBMS, which
means an increased burden on the machine resources as compared to
normal circumstances.
4.11 CUTOVER PROCESS
The proponents would suggest a Parallel Conversion where the
computerized system will run simultaneously with the manual one for
a specific period of time.
After the parallel conversion, the system will then be subjected
to performance evaluation from the people who have used the system.
With the parallel conversion, the users will gradually be able to
get accustomed to the new system but continue to use the old one.
The gradual transition allows users to compare and contrast the new
system with the old. It also allows skeptical users to build their
confidence in the new system by comparing the results obtained with
both and verifying that the new system is just as effective and
efficient as the old.
4.12 DOCUMENTATION
This guide provides the would-be user a documentation of how the
system is to be installed and used. It also provides the would-be
software reviewer, a technical guide. See Appendix B for
details.
CHAPTER FIVE
5.0 SUMMARY, RECOMMENDATION, AND CONCLUSION
5.1 SUMMARY
This study has presented a network Bandwidth simulator - a
distributed simulation platform able to perform a wide range of
experiments related to network resource management. We believe
there is a lack of network simulation platforms for network
resource management where new algorithms or systems can be tested,
because most general simulation platforms are control and traffic
oriented, and usually centralized.
The initial objective of designing a very flexible and
configurable platform, while at the same time maintaining its
modularity and simplicity, was also achieved by the use of
client/server architecture.
At present, the simulation processes have been fully tested and
are operative. And we plan to use it for a lot of experiments
related to the researcher being carried out in our groups but we
are now developing several network reource management mechanisms to
be tested using the distributed network Bandwidth simulator.
These algorithms are still not fully implemented, so only simple
example and test simulations have been performed.
7.1FUTURE WORK
As a future works on the distributed network Bandwidth
simulators itself there are three defined lines to follow. First of
all we plan to develop more visual tools to make the network
topology definition easier and automate the generation of the
configuration files and the distribution of the simulation
processes over several machines and the starting of a simulation.
Secondly, we plan the development of an automatic tools to process
log files generated for every workgroup. This tool could generate
statistics and graphics, which are always interesting and could
also perform a merge of several, log files to extract more complex
results.
Finally, these log files could also be used to perform a debug
task of network management mechanisms and even debug the simulator
itself. This last point is a long-term idea but we think it could
be interesting to transform a simulation tool into a debugging tool
for network management algorithms.
REFERENCES
1. Sidor, D.J., 1998, "TMN standards: satisfying Today's Needs
while Preparing for Tomorrow, IEEE Communications Magazine,
(March).
2. Stallings, W., 1998 "SNMP and SNMP vz: The Infrastructure for
Network Management, IEEE Communications Magazine, (March).
3. Armitage G., MPLS: The Magic Behind the Myths, IEEE
Communications, Magazine, January 2000.
4. XIGO X., Hannan A., Bailey B., Ni L.M., "Traffic Engineering
with MPLS in the internet", IEEE Network Manazine, March 2000.
5. Andersson L., Doolan P., Feldman N., Fredette A., Thomas B.,
"LDP specification ", RFC 3036, WWW.ie6. Zergher, Bernad P.,
"Object oriented simulation with Hierarchical modular modules:
Intelligent Agents and Endomorphic systems", Bostom Massachusetts,
Academic Press, 1990.
7. Gajski, Daniel D.,Nikil, D. Dutt, Allen C-H Wu and steve Y-L
Lin, "High level Synthesis: Introduction to Chips and system
Design", Kluwer Academic Publishers, Boston Massachusetts,
1992.
8. Ripley, Brian D., "stochastic simulation", John Wiley Sons,
New York, New York, 1980
9. Cellier, Francois E. "continous system Modeling",
Springer-Verlag, New York, New York, 1991
10. Mead, carver and Lynn conway, "Introduction to VLSI system",
Adisson-Wesley publishing company Inc., Reading Massachusetts
1980
Blog Post Reports
Blog Post Authentication
Update
Run Out
Update
Master
File
Deleted
File
Blogspot Doc
Keyboard
Server
Security
