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