A Google Map Based Automated Tower Monitoring System

For Mobile Services

Submitted in partial fulfilment of the requirements

For the award of the degree of

Master of Business Administration

In
Software Enterprise Management

Under the guidance of

Dr. R. K. Singh

Project Manager, C-DAC Noida

Submitted by
Raj Mohan Dwivedi

Roll No: 02811809909

Centre for Development of Advanced Computing,

Noida
Affiliated to
Guru Gobind Singh Indraprastha University

1
 Kashmere Gate, Delhi - 110006
Certificate

This is to certify that the project report entitled “ A Google Map based Automated Tower

Monitoring System” done by Mr. Raj Mohan Dwivedi, enrolment No 02811809909 is

an authentic work carried out by him/her at CAIN TECHNOGIES (INDIA) PVT LTD

under my guidance. The matter embodied in this project work has not been submitted

earlier for the award of any degree or diploma to the best of my knowledge and belief.

Date:

Signature of the Internal Guide Signature of the Supervisor

Dr. R.K .Singh,

H.O.D., MBA (SEM) Name of the Guide Col. Vinod Batra

Designation: Senior Vice President

Organization Name & address

CAIN TECHNOLOGIES (I) PVT LTD,

D-49, Sector 2, Noida-201301, UP

2
Abstract

A Google Maps based Automated Tower Monitoring System is a software application which

uses Google Maps API to provide services to users to visualize and manage complex network

of the BTS Mobile towers. Automated Tower Monitoring System (ATMS) is a software

application automates the monitoring of passive infrastructure of the Towers (Base

Transceiver Stations), which is as much important as the active monitoring of Infrastructure

of the towers. The application provides the current status of parameters to be monitored in the

passive monitoring of the towers in real time.

GMAP based ATMS provides visualization of the complex network, by overlaying persistent

and real-time information such as circle, cluster and tower names and current status of

parameters in the passive monitoring on the geographical maps provided by Google so that

there could be a better analysis regarding location of towers and avail other useful services

offered by Google Maps.

Methodology of the work includes understanding the architecture of the existing system,

understanding the Model View Controller design pattern used in the application, providing

database connectivity and developing application logic and providing GMAP interface

through a web page following MVC design pattern.

3
 ACKNOWLEDGEMENT

I am extremely grateful to the management of the CAIN TECHNOLOGIES PVT LTD. for

granting me the opportunity to undergo my training in their esteemed organisation.

I would also like to thank Mr. Rajeev Gupta (President) and Col. Vinod Batra (Vice

President) Cain Technologies Pvt. Ltd. for giving me the opportunity to work on “A

GOOGLE MAP BASED AUTOMATED TOWER MONITORING SYSTEM FOR MOBILE

SERVICES”. I extend my professional gratitude to Mr. Rajat Gupta (Director) and Mr.

Rishabh Saini (GM-IT) for sharing their knowledge and guiding me towards the successful

completion of my report.

I am extremely grateful to the staff of Cain Technologies, Noida for their cooperation and for

supplying me valuable adequate information.

The constant source of inspiration and supervision at every stage of the study were my

Faculty Guide, Dr. R.K. Singh and Mr. Nidhish Shroti. It was an honour to work under them.

Without their able guidance, this endeavour would never have been successful.

Finally I wish to express my gratitude to all those who have extended a hand of cooperation

in successful completion of my project.

4
 Table of Contents
1. Introduction…………………………......……………………………………….7
1.1 About the Organization……………………………………………………..8
1.2 Objective of the Project.................................................................................12
1.3 Scope of the Project.......................................................................................12
1.4 Methodology of working...............................................................................12
2. Literature Overview.............…...........................................................................14
2.1 Overview of ATMS.......................................................................................15
2.2 Business Requirements of ATMS................................................................17
2.3 Architecture of ATMS..................................................................................20
2.4 Sequence Diagram of ATMS.......................................................................22
2.5 Google Maps…..............................................................................................23
2.7 AJAX.............................................................................................................26
3. Analysis…………………………………………………………………………38
3.1 Problem Identification..................................................................................39
3.2 Architecture of Proposed System................................................................40
3.3 Use Case Diagram.........................................................................................41
3.4 Schema Design...............................................................................................42
4. System Function Design......................................................................................44
5. Implementation....................................................................................................46
5.1 Tools and Techniques....................................................................................47
5.2 Methodology...................................................................................................48
5.3 Screenshots.....................................................................................................49
8. Conclusion..................................................................................................…......54
9. Recommendations................................................................................................56
10. Bibliography.......................................................................................................57

5
 List of Figures

Figures Page No

I Project Organization 11

II Methodology 13

III Architecture of ATMS 20

IV Sequence Diagram of AT MS 22

V AJAX Model 1 27

VI AJAX Model 2 29

VII Architecture of Existing System 39

VIII Architecture of New System 40

IX Use Case Diagram 41

X Schema Design 42

6
 Chapter 1
Introduction

7
1.1 About the organization

Cain Technologies (I) Pvt Ltd. (Cain Software Division)

Mission

To produce state of art simulation and modelling products through innovative R&D for

defence and other commercial domains harnessing our software expertise.

Vision

To be the leader in providing IT based products and solutions to services, government

agencies and other commercial institutions world over.

Goals

To become one of India’s leading defence Software and Information Technology

development company, and maintain position by providing excellent quality performance and

perfection and expanding our business in the International Defence market, and use

professional expertise in providing the best solutions and products to the customers.

Products and Services

 War-games: War-game are being developed all over the world for defence forces for

the training/analysis purposes where the nature of simulation would be of planning,

8
 engagement or drill and to exercise commanders. War-game could be of tactical or

strategic in nature. Some of CRDC war gaming products which are under

development are as under:

 Company/Battalion level Infantry war games

 Division level war-game

 Logistics planner

 Strategic level Naval analysis war-game

 Tactical/Strategic level Air war-game

 Air Defence simulation

 Counter Insurgency Operations

 Management Information System (MIS)

 Decision Support System (DSS on MIS)

 Operation planning tool on Geographic Information System (GIS)

 Tactical Trainer for CIOPS

 VR Shooter level setups

 Policy Analysis tool (e.g. vulnerability analysis)

 Simulators

 EW Cockpit Simulator

 Weapon Simulators (Small Arms, Artillery and Tanks)

 Torpedo engagement simulator

 Modeling & Simulation

 Warhead fragmentation

 Fragment penetration

9
  Trajectory modelling

 Damage assessment

 Measure of performance models

 Tactical worth based on MOE (Measure of effectiveness)

 Error estimation

 Utility Vs Cost comparative models

 System Analysis

 Qualitative and Quantitative system analysis through system dynamics

 Force mix problems

 Resource Allocation problems

 Logistics planning

 Network Centric Warfare

 Simulated Test Range

 3D Generic Deployment Tool (e.g. AVD, VCD, BFSR, Communication towers)

 Candidate Assessment Tool (e.g. GTO)

 Arms/services specific tactical trainers

 Navigation tool

 Policy Analysis

 Stress vs. performance analysis tool (tank drivers, gunners, soldiers, pilots etc)

considering physiological and psychological intangibles (human behaviour modelling)

 Distributed Simulation and Networking

 Geographical Information System and 3D Graphics/ Visualization

 Telecom Services

10
Technology

The simulation/modelling environment consists of technologies that are complex in nature.

They have been designed and created to function as an integrated solution. By employing

these technologies, we can provide high quality state of the art world class products. We have

strengths in following technological domains:

 Artificial Intelligence

 Distributed Simulations (DIS, HLA)

 Decision Support through BBN, Fuzzy Logic, Rule Base, Cognitive Architectures.

 CI-OPS, War-games, Infantry strategy & tactics

 Software engineering process & tools

 Geographic Information Systems (GIS)

 Network Design & Programming on Unix

 Simulation Controller and System Health Monitoring

 Ensuring ‘Language’ and ‘platform’ independence

 3D Graphics & Visualization

 2D Maps & GIS Applications

 Agent Technologies

11
 Figure I
P

1.3 Objective of the Project

12
The objective of the project is to study the Automated Tower Monitoring System and to

integrate GMAP web mapping service into existing ATMS.

1.3 Scope of the Project

Scope of the project is to add GMAP interface to already existing ATMS which includes

• Study of existing Automated Tower Monitoring System (ATMS).

• Requirements Analysis of Integration of Google Maps into ATMS.

• Preparing the system design for the application.

• Implementation of basic functionalities to be required in the Google Map interface

using Google Map JavaScript API.

1.4 Functional Description

1.4.1 Study of ATMS

• Overview of Automated Tower Monitoring System

• Understanding architecture of the application.

• Understanding the system flow of the application.

1.4.2 Requirements Analysis of Adding Google Maps into existing ATMS

• Requirements classification.

• Conceptual modelling for the application.

1.4.3 Preparing system design for the application

• Designing system framework for the application.

• Designing system function for the application.

13
1.4.4 Implementation of basic functionalities

• Representation of Towers on the Google Maps

• Display of current status of the parameters to be monitored in the passive

infrastructure in the working of BTS Towers.

Study of
concepts
of existing
System

Analysis

Design of
GMAP
module

Coding

Figure II

14
 Chapter 2:
Literature review

15
2.1 Overview

ATMS is a software application developed for monitoring of Passive Infrastructure of the

BTS Towers. The basic aim of ATMS is to deliver smart and fast reporting mechanism for

optimized performance and logical analysis, thereby reducing the overall operating costs of

the BTS. ATMS enables Operators & Infrastructure providers to monitor and control the

BTSs in real-time.

Monitoring and control of BTS tower installed at remote location and working unmanned can

be monitored and controlled from control room. The RMC communicates with central

server(s), via short data messaging. Messages are sent on every defined alarm & event

conditions and based on data logging time interval from the remote units. By deploying many

such units, it becomes Distributed Control System controlled from central server. Alarm,

Event and other data logged at central server, option to escalate alarm conditions through

emails and SMS. Network Operation Indicator Services is a system that connects to the

passive equipments through GSM/ CDMA. Passive equipments is non-electronic

infrastructure which includes tower, shelter, air-conditioning equipments, generator, battery,

electrical supply, shelter and easements & pylons that account for nearly 75 percent of

network rollout costs. Monitoring of passive part is as essential as active infrastructure. This

system generates escalation messages based on criticality of faults. It recovers fault messages.

It provides immediate attention and rectification of problems. It is a manual intimation to

managers in escalation matrix.

16
 Loss of Uptime = Loss Revenue

Below are the passive components which can be monitored:

• Energy parameters like:

o Electricity Supply (Voltage/Frequency): Mains/ DG/ Battery

o Energy Consumption: AC/DC

o Power Consumption: EB/DG

o Battery Run Time

o Ambient temperature/ BTS temperature/ Battery room temperature &

Humidity

o Diesel fuel level, Diesel Consumption & Efficiency

• Failures like:

o Battery Bank Failure/ Generator failure

o Air conditioner failure

o Shelter Door open/close

• Remote Controlling of:

o Air conditioner ON/OFF

o Generator ON/OFF

o PIU Restart

The Telecom operators are optimizing on the capital investments involved in cell site roll-out

by entering into sharing arrangements for the passive infrastructure and certain active

17
infrastructure elements. The infrastructure companies are competing for business from the

operators, and uptime of the tower is a critical differentiator for them. In future, however, the

infrastructure companies are believed to compete on the basis of additional value added

services like planning and managing infrastructure.

The biggest challenge that the infrastructure companies are facing is the energy situation at a

cell site. Effective management of various energy assets like the DG Sets, the EB Power, and

the Battery Back-up will be the key to successfully meeting the Service Level Agreements.

The Nestech Consortium Private Limited Network Scan for Telecom Operations Solution is

designed to address these challenges. Nestech unique approach is to deploy intelligent

analytics for predicting downtime and triggering O&M actions to address the same. The

solution offers significant leverage on the remotely collected data for intelligent operator-wise

analysis at various hierarchies.

Nestech Consortium Private Limited provides Automation of Tower Monitoring System

(ATMS) for optimizing overall equipment efficiency and reducing operating costs. The

ATMS Solution from Nestech is designed to gather performance parameter data from the

passive infrastructure usually found in wireless network sites. The System is designed to

enable operator or infrastructure companies to maintain network uptime, optimize energy

costs, reduce overall servicing costs and decrease revenue loss.

2.2 Business Requirements of ATMS

2.2.1 Monitoring of Towers

The screen(s) will display all outstanding faults to be recovered and thus require attention.

Depending on the details of the problem, action needs to be taken based on the nature of the

faults that have been reported and the appropriate action necessary for the fault should be

18
taken. The screen should be updated every minute and all the faults should appear on the

screen as soon as the information is received from the tower.

2.2.2 Data Collection System

All status updates will be received and delivered automatically by the NOC. In the event of

SIM failures, the feedback and escalation procedures will be done manually by NESTECH’s

field team. Records of all incidents will be maintained by the system and NESTECH shall be

able to provide appropriate reports to Quippo in a reasonable time when demanded.

2.2.3 Fault Monitoring

Based upon the fault information received from the towers, the NESTECH NOC will be

responsible for verifying the nature of the fault and taking appropriate action. Depending

upon the business rules, these faults would then have to be classified as on different severity

levels (like minor, major, chronic and catastrophic) based upon guidelines provided by

QUIPPO and escalated appropriately.

2.2.4 Alarm Escalation

Quippo will provide an escalation matrix for the different types of faults for each tower that

will be monitored. Quippo will be responsible for updating this matrix on a regular basis and

ensuring the validity of the same. All changes to the escalation matrix will have to be given to

NESTECH 48 hours in advance.

The NESTECH NOC will report and escalate the alarms to the concerned O&M personnel

based upon business rules that have been setup according to the escalation matrix provided by

Quippo. Repeated attempts to deliver the message will be done (up to 3 tries) before a failure

result is noted. NESTECH will provide complete reports of message deliveries and failures to

19
Quippo on a weekly basis. When a number fails, NESTECH NOC will try to manually

contact that number within 24 hours to check to see if the number is active and ascertain

possible reasons of failure. If the number is still unreachable, then NESTECH will report such

numbers on a daily basis on email to a designated contact within Quippo for further action

and correction if necessary.

2.2.5 Consolidating Tower Status

A single view of the entire network of towers should be available from which user would be

able to drill down to the single individual towers. Reports should also indicate the health of

the entire network with parameters such as the percentage of the towers with a high priority

fault, percentage of towers with a low priority fault, continuous occurring of certain types of

faults etc

2.2.6 Report Generation

Daily reports on the entire list of faults that happened during the day will be sent to the

appropriate people in Quippo. The format of the reports will be mutually decided to

understand if these reports need to be on a circle-by-circle basis or severity of the fault basis

etc. Similarly, higher level reports that indicate the health of the entire network will be sent

out to top management at the end of the month or on periodicity that is mutually decided

between the companies.

20
2.3 Architecture of ATMS

21
 Figure III

2.3.1 Presentation Layer

Presentation view is designed using Java Swings. The data input is in XML format which are

received from servlet.

22
This layer is compiled in a jar file which can be run on any machine, ruling out all platform

dependencies.

This Layer is fully tested on Windows, Linux and UNIX platforms, which makes this layer

compatible and provides flexibility to End user.

2.3.2 Business Layer

Business Layer comprises of Servlets. These are Java programming language classes that

dynamically process requests send from End user residing at the presentation layer as

mentioned above. In response to this request, response is a well constructed XML validated

on a specified schema. HTML pages will be bundled with web components during

application assembly.

Incoming messages/string from tower coming through bearbox hits on the Web Container

which further redirects it to servlet. This is the point where Business rules validation is

performed and logs into the database.

2.3.3 Database Layer

This is the basic database management system which holds the entire NOC data and its

backup for roll back and restore, and data analysis. It will comprise of following:-

(a) User details- Data pertaining to User Login details

(b) Alarm details- Alarm, Date, Time

(c) Fault details

• Static parameters

23
 • Dynamic parameters

(d) Escalation structure

• Escalation Matrix

• Escalation status

(e) Report Generation

• Report data

• Graphical analysis data

2.4 Sequence diagram

Figure IV

2.6 Google Maps

24
2.6.1 Introduction

Google Maps (formerly Google Local) is a web mapping service application and technology

provided by Google, free (for non-commercial use), that powers many map-based services,

including the Google Maps website, Google Ride Finder, Google Transit, and maps

embedded on third-party websites via the Google Maps API. It offers street maps, a route

planner for travelling by foot, car, or public transport and an urban business locator for

numerous countries around the world. According to one of its creators (Lars Rasmussen),

Google Maps is "a way of organizing the world's information geographically".

With the introduction of an easily pan able and searchable mapping and satellite imagery tool,

Google's mapping engine prompted a surge of interest in satellite imagery. Sites were

established which feature satellite images of interesting natural and man-made landmarks,

including such novelties as "large type" writing visible in the imagery, as well as famous

stadia and unique geological formations.

Like many other Google web applications, Google Maps uses JavaScript extensively. As the

user drags the map, the grid squares are downloaded from the server and inserted into the

page. When a user searches for a business, the results are downloaded in the background for

insertion into the side panel and map; the page is not reloaded. Locations are drawn

dynamically by positioning a red pin (composed of several partially-transparent PNGs) on top

of the map images.

A hidden IFrame with form submission is used because it preserves browser history. The site

also uses JSON for data transfer rather than XML, for performance reasons. These techniques

both fall under the broad Ajax umbrella. As Google Maps is coded almost entirely

in JavaScript and XML, some end users have reverse-engineered the tool and produced

25
client-side scripts and server-side hooks which allowed a user or website to introduce

expanded or customized features into the Google Maps interface.

Using the core engine and the map/satellite images hosted by Google, such tools can

introduce custom location icons, location coordinates and metadata, and even custom map

image sources into the Google Maps interface.

2.6.2 How does Google Map works?

Searching the Map

When users first navigate to the Google Maps web application, they see a broad map of the

United States along with a search box at the top of the window. When they type an address or

general location into the search field, Google sends the entry to its global servers and searches

for the closest location match. The corresponding location data is then retrieved from

TeleAtlas, the source of the map imagery in Google Maps. The application renders the

corresponding map from TeleAtlas into the main frame of the window and places a visual

pointer on the exact location that was searched.

Finding a Business

The search field in Google Maps also combines the powerful indexing of generic Google web

searches. Users can not only search for addresses and locations, but also businesses in

specific areas. When a user enters a type of business and a general location into the search

box, Google Maps searches the web for a matching entry. When the application locates an

appropriate business, it also searches for the company's address and then grabs the

corresponding map imagery.

26
Finding Directions

In addition to searching for locations or business, Google Maps enables users to find driving

or walking directions between two addresses of their choice. When users enter direction

mode, they can type two or more addresses into the search fields and then begin looking for

directions. Google's map servers store millions of potential route combinations, which are

then sorted through to find the fastest directions between the submitted locations. Once a

route has been determined, Google Maps displays an image of the entire trip and draws a line

along the selected route.

2.6.3 Google Map API

Google launched the Google Maps API in June 2005 to allow developers to integrate Google

Maps into their websites. It is a free service, and currently does not contain ads, but Google

states in their terms of use that they reserve the right to display ads in the future.

By using the Google Maps API, it is possible to embed Google Maps site into an external

website, on to which site specific data can be overlaid. Although initially only

a JavaScript API, the Maps API has since expanded to include an API for Adobe

Flash applications, a service for retrieving static map images, and web services for

performing geocoding, generating driving directions, and obtaining elevation profiles. Over

350,000 web sites use the Google Maps API, making it the most heavily used web application

development API.

The Google Maps API is free for commercial use providing that the site on which it is being

used is publicly accessible and does not charge for access. Sites that do not meet these

requirements can purchase Google Maps API Premier.

27
The success of the Google Maps API has spawned a number of competing alternatives,

including the Yahoo! Maps API, Bing Maps Platform, MapQuest Development Platform,

and OpenLayers.

2.7 AJAX (Asynchronous JavaScript and XML)

2.7.1 Overview

AJAX is the name given to a set of modern web application development technologies,

previously known as dynamic HTML (DHTML) and remote scripting. As defined by J.J

Garret, AJAX is not a new technology, it incorporates: standards based presentation using

XHTML and CSS (Cascading Style Sheets), dynamic display and interaction using the

DOM (Document Object Model), data interchange and manipulation, asynchronous data

retrieval using XMLHttpRequest, and JavaScript binding everything together.

The combination of these technologies makes AJAX to be unique and powerful on the Web.

Its power is becoming evident by web applications such as Google Suggest and Google Map.

And other well known examples are Gmail, and the new version of Yahoo Mail. The

popularity of AJAX changes the way web application works, which means we need to

recheck the software architecture we are using. In AJAX-based web application architecture,

the client side AJAX engine is the key to this model. User events trigger asynchronous calls

to the client side engine instead of a page request to the server. The server accepts the

asynchronous call and sends data or business logic to the client. The client side is then

responsible for locally rendering the application’s user interface required to present the data

and user interaction with the data. Such separation of the presentation layer and server-side

business logic provides meaningful benefit for software development and maintenance.

28
Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right,

coming together in powerful new ways. Ajax incorporates:

• Standards-based presentation using XHTML and CSS;

• Dynamic display and interaction using the Document Object Model;

• Data interchange and manipulation using XML and XSLT;

• Asynchronous data retrieval using XMLHttpRequest;

• JavaScript binding everything together

The classic web application model works like this: Most user actions in the interface trigger

an HTTP request back to a web server. The server does some processing — retrieving data,

crunching numbers, talking to various legacy systems — and then returns an HTML page to

the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as

fans of The Elements of User Experience know, what makes the Web good for hypertext

doesn’t necessarily make it good for software applications.

29
 Figure V

The traditional model for web applications (left) compared to the Ajax model (right)

This approach makes a lot of technical sense, but it doesn’t make for a great user experience.

While the server is doing its thing, the user is waiting. And at every step in a task, the user

waits some more.

Obviously, if we were designing the Web from scratch for applications, we wouldn’t make

users wait around. Once an interface is loaded, the user interaction should not come to a halt

every time the application needs something from the server. In fact, the user should not see

the application go to the server.

30
How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by

introducing an intermediary — an Ajax engine — between the user and the server. It seems

like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine —

written in JavaScript and usually tucked away in a hidden frame. This engine is responsible

for both rendering the interface the user sees and communicating with the server on the user’s

behalf. The Ajax engine allows the user’s interaction with the application to happen

asynchronously — independent of communication with the server. So the user is never

staring at a blank browser window and an hourglass icon, waiting around for the server to do

something.

31
 Figure VI

The synchronous interaction pattern of a traditional web application (top) compared with the

asynchronous pattern of an Ajax application (bottom)

Every user action that normally would generate an HTTP request takes the form of a

JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a

trip back to the server — such as simple data validation, editing data in memory, and even

some navigation — the engine handles on its own. If the engine needs something from the

server in order to respond — if it’s submitting data for processing, loading additional

32
interface code, or retrieving new data — the engine makes those requests asynchronously,

usually using XML, without stalling a user’s interaction with the application.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major

products Google have introduced over the last year — Orkut, Gmail, the latest beta version

of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on

the technical nuts and bolts of these Ajax implementations, check out these excellent analyses

of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features

that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies

similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-

world applications. This isn’t another technology that only works in a laboratory. And Ajax

applications can be any size, from the very simple, single-function Google Suggest to the

very complex and sophisticated Google Maps.

Ajax is an important development for Web applications, and its importance is only going to

grow. And because there are so many developers out there who already know how to use

these technologies, we expect to see many more organizations following Google’s lead in

reaping the competitive advantage Ajax provides.

Moving Forward

The biggest challenges in creating Ajax applications are not technical. The core Ajax

technologies are mature, stable, and well understood. Instead, the challenges are for the

designers of these applications: to forget what we think we know about the limitations of the

Web, and begin to imagine a wider, richer range of possibilities.

33
Partial Page Updating

You don’t have to update the data on an entire page. You can update only the portions of the

page that require it. This should mean no full page refreshes, less data to be transferred, and

an improved flow for the user experience. You don’t have to stutter from page to page.

Invisible Data Retrieval The longer you look at a web page, the greater its chance to go out of

date. With an Ajax application, even though on the surface the web page might not be told to

do anything, it could be updating itself behind the scenes.

Constant Updating

Because you’re not waiting for a page refresh every time, and because Ajax can retrieve data

under the covers, the web application can be constantly updated. A traditional software

application such as Word or Outlook will alter the menus it displays or the views it shows,

dependent on its configuration, or the data it holds or the situation or circumstances it finds

itself in. It doesn’t have to wait for a server or user to perform an action before it can

download new mail or apply a new template. Ajax techniques enable web applications to

behave more like Windows applications because of this.

Smooth Interfaces

An interface that doesn’t have to be changed is almost inevitably a user interface that is easier

to use. Ajax can cut both ways here in that you can use it to modify parts of the interface and

simply confuse users by changing the ground beneath their feet. In theory, by making subtle

alterations, you could aid the user’s passage through an interface or wizard and speed up the

process.

Simplicity and Rich Functionality

34
As shown in the previous examples, some of the most impressive Ajax applications are those

where you had to look for the Ajax functionality, such as Basecamp. If Ajax can be used to

make your applications simpler while improving the user’s experience, then that must be an

improvement.

Drag and Drop

Drag-and-drop functionality is one of the neatest features of most software applications, from

Windows Explorer to Windows Desktop. It doesn’t strictly qualify as Ajax functionality. It’s

something that’s been possible for a great many years in web applications, even before the

introduction of the XMLHttpRequest object. Most developers seem to opt for Flash or some

similarly heavyweight solution rather than using the JavaScript and DOM solutions. In the

reassessment of user-interface creation techniques that Ajax has introduced, drag-and-drop

functionality can be used to manage front-end changes, and then these changes are submitted

via Ajax to the server. For example, you drag several items on the screen into new positions,

and then you log out. Later, when you come back, those items are located in the same

positions.

2.7.2 JavaScript

JavaScript is an essential piece of the Ajax package. JavaScript serves as the intermediary

between the browser (the client) and the server so that a web page can be dynamically

updated without refreshing the entire page. JavaScript was developed by Brendan Eich and

introduced in the 1995 release of Netscape 2.0.

Because JavaScript offered a means to add interactivity to HTML pages, it quickly became

popular and widely used. Different versions were developed both by Netscape and other

browser manufacturers, but eventually the JavaScript language was standardized by the

European Computer Manufacturer’s Association (ECMA) as ECMAScript. The ECMAScript

35
standard defines the core of the JavaScript language. Most browsers today support the third

edition of the ECMA-262 standard.

JavaScript is thus, a client-side scripting language. There is also a server-side version that is

used in Active Server Pages, a technology promoted by Microsoft. JavaScript enables

browsers to take decisions and process information. This is the key to interactivity. JavaScript

is the only scripting language currently supported by the popular web browsers. Netscape

Navigator only supports JavaScript, whereas Microsoft Internet Explorer supports both

JavaScript and VBScript. JavaScript can also be used on web servers for what's called server

side scripting as well.

Uses of JavaScript-

Validate forms at the client-side saving both the precious server resources and time.

• Create mouse over effects, change background colour of a document with a click of a

Button interactivity!

• Randomly display content without the involvement of server programs.

• Move HTML elements around pages.

• Change page contents dynamically.

• Load content in new browser windows and frames.

• Make online games.

JavaScript is based on Object Oriented Programming concept. Its syntax is quite similar to C,

C++ and Java. As it is based on Object Oriented Programming concepts, it is called as

“Object Based”. However, it is much easier to learn and implement.

Inserting Client Side JavaScript into an HTML Page

36
JavaScript is added to an HTML page using the SCRIPT tag. The script tags should be placed

inside the head tag of the document. If an older browser looks at a page containing script tags

it will ignore them, as older browsers are written to ignore tags they can't interpret.

JavaScript code should also be placed inside an HTML Comment tag set.

E.g. <! -- Code -->

When used with JavaScript the ending comment tag will also start with two slashes // which

is the JavaScript code for comment. This tells the JavaScript interpreter to ignore that

statement. This is a standard way for adding JavaScript to your HTML pages so that it works

properly for browsers that are JavaScript enabled and those that do not support JavaScript.

<HTML>

<HEAD>

<TITLE>Web Page containing JavaScript</TITLE>

<SCRIPT LANGUAGE="JAVASCRIPT">

<! -- hide JavaScript code from browsers that are not JavaScript enabled

(JavaScript Statements goes here)

//end hiding of JavaScript code -->

</SCRIPT>

</HEAD>

<BODY>

(HTML document goes here)

</BODY>

</HTML>

You may also put in a single line of code attached to an event. Events will be explained later.

The general syntax for this structure is:

37
<HTML_TAG Attribute="option" onEvent="JavaScript code statements go here">stuff in

between the opening and closing tag</HTML_TAG>

2.7.3 The Document Object Model (DOM)

The browser provides us with a series of objects. The browser window that the page is

displayed in is known as the window object. The HTML page displayed by your browser is

known as the document object. The document object is probably the most commonly used

object in client-side JavaScript. The HTML elements that you add to a page also extend the

object hierarchy. An example is the FORM element and the elements that reside inside the

form. This means that you can reference these objects, as illustrated in the HTML page

below:

window.document.forms [0]

It refers to the first form in the document. Forms are implemented as arrays in the DOM. If

there is more than one form on page the numbers will start at zero and go up.

window.document.Form1

It refers to the form by name Form1

window.document.Form1.FirstName.value

Refers to the value typed into the textbox named FirstName by the client, in the form named

Form1

<HTML>

<HEAD>

<TITLE>Simple Form</TITLE>

</HEAD>

<BODY>

<FORM NAME="Form1">

38
Name: <INPUT TYPE="TEXT" NAME="FirstName"><BR>

<INPUT TYPE="Button" VALUE="Submit Info" >

</FORM>

<FORM NAME="Form2">

Name: <INPUT TYPE="TEXT" NAME="LastName"><BR>

<INPUT TYPE="Button" VALUE="Submit Info" >

</FORM>

</BODY>

</HTML>

Objects located in the current document, in the current window can drop the reference to

those two objects. For example:

Forms [0]

It refers to the first form within this document

Form1

It refers to the form named Form1 in this document

Form1.FullName.value

It refers to the value typed, in the browser by the client, into the textbox named FullName, in

the form named Form1, in this document.

2.7.4 XML

XML is a very popular language for data exchange. It’s well suited for organizing data and

for sharing data because it allows you to classify data, create very specific rules for the format

of the data, and output the data to a variety of places. For example, the same data could be

used in a database, a web page, and a printed form. XML is not proprietary and is not limited

to any particular platform or device.

39
XML can be used to exchange, share, and store data. XML documents form a tree

structure that starts at "the root" and branches to "the leaves".

XML has very simple syntax rules. XML with correct syntax is "Well Formed". Valid XML

also validates against a DTD.

XSLT is used to transform XML into other formats like HTML.

All modern browsers have a built-in XML parser that can read and manipulate XML.

The DOM (Document Object Model) defines a standard way for accessing XML.

The XMLHttpRequest object provides a way to communicate with a server after a web page

has loaded.

XML Namespaces provide a method to avoid element name conflicts.

XML DOM (Document Object Model)

The XML DOM defines a standard way for accessing and manipulating XML documents.

The XML DOM is platform and language independent and can be used by any programming

language like Java, JavaScript, and VBScript.

XSLT (XML Style sheet Language Transformations)

XSLT is the style sheet language for XML files. With XSLT you can transform XML

documents into other formats, like XHTML.

XML DTD (Document Type Definition)

40
The purpose of a DTD is to define what elements, attributes and entities is legal in an XML

document. With DTD, each of your XML files can carry a description of its own format with

it. DTD can be used to verify that the data you receive, and your own data, is valid.

XML Schema

XML Schema is an XML based alternative to DTD. Unlike DTD, XML Schemas has support

for data types, and XML Schema use XML Syntax.

Chapter 3:
Analysis

41
3.1 Requirements Analysis of Google Maps

• It will not replace the existing system but provides an alternative in respect of using

functionalities.

• Existing application does not provide any Geographical view of the location of the

towers.

• It does not provide any facility to visualize this complex network of BTS towers

making the application less interactive and hard to manage.

• Google Maps API can be used which will help in representation of towers on the

satellite images provided by Google Map.

• Rather than using a GIS package, using the freely available Google Maps API will

also help in keeping the development cost low.

3.2 Architecture of Proposed System

Architecture of existing Application-

42
 HTTP/XML JDBC
GUI Servlets/JSP NOC (Database
(Swings) (Appl. Server) Server)
Presentation Layer Application Layer Database Layer

Figure VII

Architecture after Integration of Google Maps into existing ATMS-

GUI Web
(Swings) Browser

NOC (Database
Application Layer Server)

AJAX INTERFACE

43
 XMLHTTPReque
st

Object

Google Map XML DATA

API

Figure VIII

3.3 Use Case Diagram

User Login

Administrator Managers

Customizing the
Interface

Browsing
44 the portal
Central Monitoring Local Monitoring

Team Team

Figure IX

3.4 Conceptual modelling

Tower

Site_Engineer

Tower_Current_Status

Cluster

Circle

Anchor_Tenant

45
 Figure X

Chapter 4:
System Design

46
4. System Function Design

4.1 Login

Various stakeholders of the system log in to the portal as different users of the portal. The

functionalities of the portal they can use will depend on the account through which they log

in. Categorization of the users has been done on the following basis-

• Administrator- Responsible for the controlling of the Network Operating Centre.

• Central Monitoring Team- Responsible for the monitoring of all the circles.

• Local Monitoring Team- Responsible for the monitoring of a particular circle.

• Top management officials in the Quippo concerned with the operation of ATMS.

47
4.2 Browsing the portal-

4.2.1 Interaction with the Map Interface-

Portal browsing involves the interaction of various users with the map interface for using

different functionalities provided by the Google Map API. The map interface has been

organized into three layers-

I. Layer 1- The Map Area shows the telecom circle names on the coloured polygons in the

country map of India. This is the basic interface for all the users except Local Monitoring

Team. Users can further zoom in to the clusters. When users select a circle, an Information

window is displayed showing the full information about that circle such as number of clusters

and total number of towers, number of live towers, number of critical towers, number of non

critical towers, number of non responding towers in that circle and the name of circle

manager.

II. Layer 2- The map displays the area corresponding to one circle and all cluster names are

overlaid on it. This is the default map interface for the local monitoring team. When users

select a particular cluster, an information window will pop up and displays basic information

such as total number of towers in the circle, number of live towers, number of critical towers,

number of non critical towers, number of not responding towers and the name of cluster

manager.

III. Layer 3- The map area displays all the towers on the map through markers. Towers will

be represented using colours on the following basis-

• Green markers- Live towers without any faults

48
 • Yellow markers- Towers having non critical faults

• Red markers- Towers having critical faults

• Grey markers- Towers which are non responding

• White markers- Towers which have no data

Users can interact with the map by panning and zooming using the mouse and graphical

interface controls. When a marker is selected, the information for that resource will be shown

in an information window that will pop up above the marker. Information window will

display the current status of all the parameters in the passive monitoring of the infrastructure

at the site. Also when the mouse is brought over a marker, a message box will open showing

site address and the site status whether running on DG, battery or mains.

Chapter 5

49
 Implementation

5.1 Tools and Techniques Used

Tools Used-

NetBeans IDE

Technology Used-

J2EE (Java Enterprise Edition) for server side programming

HTML, JavaScript for client side programming

50
GMAP JavaScript API for implementing the functionalities to be used in Google maps

Techniques used-

Model View Controller Design Pattern

- The business logic is implemented in the Model. It is developed through server side

programming.

- Presentation logic, i.e. Interface design is implemented in the view. View is responsible for

event handling on GUI components.

- Navigation controls are provided by controller. Controller is responsible for request

handling.

5.2 Methodology of Implementation-

1. Understanding the Model View Controller design pattern used in the application

2. Starting the development using NetBeans IDE 6.1

3. Designing a web page in HTML 5.0 standard using CSS and following Document

Object Model, and registering for Using GMAP JavaScript API in the web page.

51
 4. Coding for database connectivity with the application to perform insertion,

modification and retrieval of data from database.

5. Developing Java Beans having setter and getter methods for efficiently storing and

retrieving data.

6. Coding business logic through JSP for implementing various functionalities

offered by the GMAP API for manipulating the maps such as-

• Adding content on the Google Map in the form of cluster names and tower

names through overlays.

• Providing Filtered display options through UI Events and MVC State

changes.

• Representation of tower by markers through overlays.

• Display of current Status of parameters in the passive monitoring through

information window using overlays.

7. Finally deploying web archive (war) file into the Apache Tomcat Application

Server.

5.3 Interfaces
These are the interfaces displayed directly when a user clicks on any of the options in the
menu.

Screen 1
Description-

52
 Screen 1: Home Page

Screen 2
Description-

When the option “View Circles” is clicked, a form opens.

53
When user selects a circle name in the dropdown list, circle area selected is displayed on the
Google maps.

Screen 3
Description-

54
When the option “View Current Status of Tower” is clicked, a form opens.

When user selects a circle name and a cluster name and tower name from drop down lists,
user is shown the location of tower on the page.

Screen 3: View Current Status

Screen 4

55
Description-

When the option “Insert New Tower Information” is clicked, a form opens.

When user selects cluster name in the dropdown list and inputs the latitude and longitude and
clicks on “submit” button, data is saved into the database.

Screen 3: Insert New Tower

56
Screen 5
Description

When the user clicks on “Delete Existing Tower Information”, a form opens
prompting user to enter circle name, cluster name and tower name. After user
clicks on “submit” button, tower information is deleted from the database.

Screen 5:

57
Screen 6
Description

When user clicks on ”Change Cluster of a tower”, a form opens asking

user to enter old circle and cluster and tower name and new circle and
cluster.

58
Chapter 6:
Conclusion

59
6. Conclusion

After the integration of GMAP interface into existing ATMS, the current application will

provide added functionalities at low costs and it will become more users friendly.

Also, the project helped the trainee in following ways-

• It provided an insight into the working of the real organizations.

• Trainee learnt the concepts involved with the development of a System in real world

scenario.

• Trainee learnt various technologies and tools used in the software development.

60
 Chapter 7:
Recommendations

61
7. Recommendations

1. Google Map JavaScript API Premiere can be used instead of free version of Google Map

API as it will enable the company to get paid for developing the application Google Map

based as it cannot charge if it uses free version of Google Map API.

2. Using the Google Map API Premiere will remove the limitation with free version of

Google Map API that there cannot be more than 500000 page views in a day. Monitoring

more than 4000 towers through the map may cross the limit of page views made to Google

Maps in a single day more than 500000 in a day and then users can no longer use the map for

the remaining day.

3. Using Premiere version of Google Map API will also remove another limitation that

application can not only be accessible on the intranet. For making this application only

accessible within intranet so that general public cannot use it, Google Map API Premiere

should be used.

62
Bibliography

[1] Jing Yuan Zhang, Hao Shi, “Geospatial Visualization using Google Maps: A Case

study on conference presenters”, Proceedings of Second International Multisymposium

on Computer and Computational Sciences, IEEE, 2007

[2] Gang Wang, Fuling Bian, Integrating HDRI into Google Maps with Ajax, 2007

[3] Yang, Jianhua Xu, Design and Implementation of Campus Spatial Information Service

Based on Google Maps, IEEE, 2009

[4] Gibbins Hussein, Buyya Rajkumar, Gridscape II: A Customizable and Pluggable Grid

Monitoring Portal and its Integration with Google Maps, Proceedings of the Fifth

International IEEE Conference on Grid and Cooperative Computing (GCC'06), IEEE

2006

[5] Hofstede Rick, Fioreze Tiago, SURFmap: A network monitoring tool based on the Google

Maps API, IEEE 2009

[6] Yao-Jan Wu, Yinhai Wang, Dalin Qian, A Google-Map-Based Arterial Traffic

Information System, Proceedings of the 2007 IEEE Intelligent Transportation Systems

Conference Seattle, WA, USA, Sept. 30 - Oct. 3, 2007

[7] Xiaojun Tan, Mu Zhou, Xiang Zuo, Yuyong Cui, Integration WebGIS with AJAX and

XML Based on Google Maps, First International Conference on Intelligent Networks and

Intelligent Systems, IEEE, 2008

63
[8] Wang Yan, Logistics Network System Based on the Google Maps API, IEEE 2010

[9] Kiwon Lee, Technical Architecture for Land Monitoring Portal using Google Maps API
and Open Source GIS, IEEE, 2009

[10] Zhang Jun, Anbao Wang, Useful Resources Integration Based on Google Maps,

Proceedings of 4th International Conference on Computer Science & Education, IEEE,

2009

[8] Google, “Google Map API”, www.google.com/apis/maps

[9] J. J. Garret, “Ajax: A new approach to web Applications”,

http://www.adaptivepath.com/publications/essays/archives/000385.php, 2005

64