lbsq

Department of Computer Engg. Location-based spatial query processing in wireless

CHAPTER 1

INTRODUCTION

1.1 Introduction

We propose a scalable low-latency approach for processing LBSQs in broadcast

environments. Our approach leverages ad hoc networks to share information among mobile

clients in a peer-to-peer (P2P) manner. The rationale behind our approach is based on the

following observations:

when a mobile user launches a nearest neighbor (NN) query, in many situations, she

would prefer an approximate result that arrives with a short response time rather than an

accurate result with a long latency.

P2P approaches can be valuable for applications where the response time is an important

concern. Through mobile cooperative caching of the result sets, query results can be

efficiently shared among mobile clients.

The results of spatial queries often exhibit spatial locality. For example, if two MHs are

close to each other, the result sets of their spatial queries may overlap significantly.

1 .2 Purpose

User mobility and data exchange through wireless communication give LBSQs some

unique characteristics that traditional spatial query processing in centralize databases does not

address. Novel query processing techniques must be devised to handle these new challenges.

1. Mobile query semantics. In a mobile environment, a typical LBSQ is of the form “find the top-

three nearest hospitals.” The result of the query depends on the location of its requester. Caching

and sharing of query results must take into consideration the location of the query issuer.

2. High workload. The database resides in a centralized server, which typically serves a large

mobile user community through wireless communication. Consequently, bandwidth constraints

and scalability become the two most important design concerns of LBSQ algorithms [2].

Year 2010-11 1 Group No. 58

Centra

lized

Server

MH1MH2

MH3

MH4

MH-Mobile Host


3. Query Promptness and Accuracy. Due to users’ mobility, answers to an LBSQ will lose their

relevancy if there is a long delay in query processing or in communication. For example, answers

to the query “find the top-three nearest hospitals” received after five minutes of high-speed

driving will become meaningless.

1 .3 Scope

The scope of the project is to reduce the latency considerably in answering LBSQs. Our

approach is based on peer-to-peer sharing, which enables us to process queries without delay at a

mobile host by using query results cached in its neighboring mobile peers.

1.4 Definitions, Acronyms and Abbreviations

LBSQ - Location based special query

MH - Mobile host

P-TO-P- PEER TO PEER



1.5 References

Wikipedia

How Stuff Works

www.gaspricewatch.com.

www.dot.ca.gov/hq/traffops/saferesr/trafdata/...

IEEE Papers

1.6 Overview

This subsection should describe what the rest of the SRS contains and explain how the

document is organized.



CHAPTER 2

PROJECT PREREQUISITE

2 .1 History (Survey the history for the project under consideration)

Spatial query processing is becoming an integral part of many new applications.

Recently, there has been a growing interest in the use of location-based spatial queries(LBSQs),

which refer to a set of spatial queries that retrieve information based on mobile users’ current

locations[10].User mobility and data exchange through wireless communication give LB-SQs

some unique characteristics that traditional spatial query processing in centralized databases does

not address.

2.2 Comparison of Existing System

• Existing techniques cannot be used effectively in a wireless broadcast environment,

where only sequential data access is supported.

• It may not scale to very large user populations.

• In an existing system to communicate with the server, a client must most likely use a

fee-based cellular-type network to achieve a reasonable operating range.

• Third, users must reveal their current location and send it to the server, which may be

undesirable for privacy reasons



CHAPTER 3

SRS DOCUMENT

3.1. Introduction

3.1.1 Purpose

It is a user mobility and data exchange through wireless communication gives LBSQs

some unique characteristics that traditional spatial query processing in centralize databases does

not address. Novel query processing techniques must be devised to handle these new challenges.

The primary purpose of the LBSQs is to bring the desired information to the user in least

time. Spatial queries that retrieve information based on mobile user’s current location.

3.1.2 Document Conventions

Fonts: Ariel Black, Size: 11, for detailed descriptions.

Fonts: Ariel Black, Size: 11, bold for Protocols used in the system.

Fonts: Ariel Black, Size: 11, italic for references.

LBSQ- Location Based Spatial Query Processing

MH-Mobile Host

P2P- Peer to Peer

3.1.3 Intended Audience and Reading Suggestions

This document is for developers and testers of this system. It contains the detailed

analysis of the system along with the functional and non functional requirements. It gives the

entire view of the system. It contains overall description of the system, discussing in detail the

scope, operating environment, and external as well as internal interfaces, functionality of

different operations and security concerns and measures for the system. The flow goes as Overall

Description followed by external interface requirements followed by system features and finally

non functional requirement.

3.1.4 Product Scope



The system is capable of handling the entire Mobile Host (p to p) based on ad hoc

network. Primary purpose of the project is to reduce the latency considerably in answering

LBSQs. Our approach is based on peer-to-peer sharing, which enables us to process queries

without delay at a mobile host by using Query results cached in its neighboring mobile

peers. Our approach is based on peer-to-peer sharing. When a mobile user launches a nearest

neighbor (NN) query, would prefer an approximate result that arrives with a short response

time rather than an accurate result with a long latency. Query results can be efficiently shared

among mobile clients.

3.1.5 References

Wikipedia

How Stuff Works

www.gaspricewatch.com.

www.dot.ca.gov/hq/traffops/saferesr/trafdata/...

IEEE Papers

3.2. Overall Description

3.2.1 Product Perspective

LBSQs have certain unique characteristics that the traditional spatial query processing in

centralized databases does not address.

It has all the basic functionality along with basic security and privacy.

Characteristics of LBSQs that enable the development of effective sharing methods in

broadcast environments.

3.2.2 Product Functions

User should enter the valid query of the desired answer to be searched.

Mobile host will connect to each other through 3 ways by algorithmic approach.

After connection the MH (Mobile Host) will send the query to Server Database to get the

corresponding answer of the query. At this stage NN (Nearest Neighbor) algorithm will



be implement.

If the nodes are not in the range of the questioner then the second algorithm will be

implement that is Share based nearest neighbor (SBNN).

If there are two nodes which are having the same information of that query then third

algorithm will be implemented which reduces the redundancy.

Partial result can be extracted by applying these algorithm.

3.2.3 User Classes and Characteristics

Users: Different Users who want to search information on Mobile Technology.

3.2.4 Operating Environment

1. A mobile phone should be GPRS enabled.

2. Should be support J2ME.

3.2.5 Design and Implementation Constraints

1. Time is an important constraint for development.

2. Knowledge and technical know-how is limited.

Tools and databases to be used:

C #.

ASP.NET

Visual studio 2005 and above

Microsoft SQL Server 2005

Frontend language C#

3.2.6 User Documentation

List the user documentation components (such as user manuals, on-line help, and

tutorials) that will be delivered along with the software. Identify any known user documentation

delivery formats or standards.

3.2.7 Assumptions and Dependencies

Dependencies:

System will require a wireless broadband connection.



The procedure will be dependent on the installed version of J2ME (on every mobile

phone).

The speed of the internet will affect the performance.

Assumptions:

The system must have a well working mobile phones.

The system must have a properly functional version of J2ME installed.

3.3 External Interface Requirements

3.3.1 User Interfaces

A GUI, having a bar for queries followed by a GO button.

GUI also contains a status bar to show the current status of the queries.

It also has a tool bar containing icons for shortcuts like REFRESH, STOP, HELP,

HISTORY, FORWARD, BACK.

HELP icon will appear on every screen, error message display.

o Forward Button : When user clicks on the Forward Button the browser displays

the next page if that page resides in.

Back Button : When user clicks on the Back Button the browser displays the

previous page if that page resides in.

3.3.2 Hardware Interfaces

Processor: Pentium IV and above

Hard disk: Min 20Gb

Standard : Key board and Mouse

3.3.3 Software Interfaces

Application : Visual studio 2005 and above

Microsoft SQL Server 2005

Tools : Front end language C#

Services Needed : wireless broadcast environment



3.3.4 Communications Interfaces

The no. of mobile hosts.

Wireless broadband environment.

Java based application on mobile like browser.

Privacy assured as user not need to tell their existing location.

3.4 System Features

3.4.1 GO button.

3.4.1.1 Description and Priority

It is a very important feature of this system. It basically starts the connection with wireless when

clicked. It is of high priority and a must for the system.

3.4.1.2 Stimulus/Response Sequences

When user clicks on GO button, the browser finds the entered URL in the local cache.

If found it connects to the MH.

If not found, web browser tries to send GET HTTP command to root DNS server.

3.4.2 System Feature

3.4.2.1 Forward Button

This button provides user with the facility to see next page if it resides in the Mobile

memory.


When user clicks on the forward button the browser checks the entered queries into

memory, if found displays the content on the screen.

3.4.2.3 Functional requirement

A function that checks the entered query with the previously stored pages and if the

match found, display the contents of that page on the screen.

3.4.3 Backward Button




This button provides user with the facility to see previous page if it resides in the

memory.


When user clicks on the backward button the browser checks the entered query into

memory, if found displays the content on the screen.


A function that checks the entered query with the previously stored pages and if the

match found , display the contents of that page on the screen.

3.4.4 Refresh Button


This button provides user with the facility to reload the page if any discrepancies occur in

connections.


When user clicks on the refresh button the browser stops the rendering process.

It reconnects to the same query and reloads the contents again.


A function that stop rendering the contents, and reconnects to the same query and render

the contents again.

3.4.5 History Button


This button provides user with the facility to view the log of the pages previously visited.


When user clicks on the history button the browser access the files where history of the

pages is stored.

It displays the list of visited pages along with the day, date and time of the page visited.

3.4.5.3 Functional Requirements

Requires a data structures of file type to store the list of the pages visited.

Year 2010-11 10 Group No. 58


Requires a display function to display the list of pages visited along with day, date

and time of the visit.

3.4.5.4 Functional Requirements

System should reply to every query that is fired. In case system doesn’t get what the query

is about it will give a error. Partial result will be given as soon as possible. System should search

for nearest neighbor for the answer to make itself more effective. Redundancy will be minimized

by the system.

3.5 Other Nonfunctional Requirements

3.5.1 Performance Requirements

1. The response time of the system should be very low.

2. The system should be able to answer as many queries as possible without getting hang.

3. Fast retrieval of information.

3.5.2 Safety Requirements

1. System should be protected using an antivirus.

2. Regular backups will be taken.

3. Database server should be updated after every query.

3.5.3 Security Requirements

1. Privacy of Location of the user will be secured

2. Database will be secured by using services like dataware housing

3.5.4 Software Quality Attributes

Flexibility: The system should be flexible as it is a wireless based environment

Correctness: Answer of the query should be based on the location of the enquirer and should be

correct as per demanded.

Portability: The system can run on any mobile having a gprs connection.

Year 2010-11 11 Group No. 58


Availability: Everybody can easily log on to the system and communicate with the system.

Maintainability: data must be updated after every query fired on the system

CHAPTER 4SOFTWARE DESIGN SPECIFICATION

4.1 Introduction

Our approach is based on peer-to-peer sharing, which enables us to process queries

without delay at a mobile host by using query results cached in its neighboring mobile peers. We

demonstrate the feasibility of our approach through a probabilistic analysis, and we illustrate the

appeal of our technique through extensive simulation results.

4.2 Data design

Why data structures are important, and their effect on the performance of an algorithm.

To determine a data structure's effect on performance, we'll need to examine how the various

operations performed by a data structure can be rigorously analyzed. Finally, we'll turn our

attention to two similar data structures present in the .NET Framework: the Array and the List.

Chances are you've used these data structures in past projects.

The Queue and Stack. Like the List, both the Queue and Stack store a collection of data and are

data structures available in the .NET Framework Base Class Library.

A graph is a collection of nodes, with a set of edges connecting the various nodes. For example,

a map can be visualized as a graph, with cities as nodes and the highways between them as edged

between the nodes. Many real-world problems can be abstractly defined in terms of graphs,

thereby making graphs an often-used data structure.

4.2.1 Internal software data structure

Array, Lists.

Year 2010-11 12 Group No. 58


4.2.2 Global data structure

Class, Struct.

4.2.3 Temporary data structure

Union,Enum.

4.3 Architectural and component-level design

4.3.1 Program Structure

Use Case

Year 2010-11 13 Group No. 58

Compute the retrieval time

Broad cast the query

Return the point of interest Search for point of interest in verified nodes

Identify the nearest neighboring nodes

Compute the nearest path to reach source from each nodenode

Search nearest neighbors again in unverified region

<<includes>>

<<includes>>

<<extends>>

Node

<<includes>>

<<includes>>

Path_finder+String path

+String node_name+CalculatePath()

+ identifyNode()

POI_Finder+String node_name +int POI+Search_POI() +CalculateTime() +return_POI() +Find_node()

BPSQ_Main+ String node_name +int node_number +String query

+node_list()

+Find_neighbor() +query_forward()


Class Diagram

Year 2010-11 14 Group No. 58

1..*

1..* 1

Server +String query +String result

+int id+returnResult()

Client +String name +String query, +int id+broadcast(),+send_request,+get_response()

Nearest Neighbor+String node_name() +Int node_number +String: result + Find_node()

Compute retrieval time

If not

Compute nearest neighbor of verified nodes

Search for point of interest Return the point of interest

Broadcast the query

Identify the nearest neighboring nodes

Compute the nearest path to reach source node from every node


4.3.1.1 Architecture diagram / UML Diagrams

Activity Diagram

Year 2010-11 15 Group No. 58

Server +String query +String result

+int id+returnResult()

Client +String name +String query, +int id+broadcast(),+send_request,+get_response()

Default.aspx

Master_page.

aspx

Poi_node.aspx

Search_poi.aspx

Path_finder.aspx

Find_nodes.aspx

node.aspx


4.3.2 Description for Component

4.3.2.1 Component n interface description.

4.3.2.2 Component n processing detail

4.4 Software Interface Description

We are using Visual Studio 2008 and MS SQL Server 2005 with .NET framework 3.5 which provides

advanced and simple user interface for development.

4.4.1 User interface design

4.4.1.1 Description of the user interface

We are creating graphical interface in .NET using tools provided by .NET framework like

Forms, buttons, Login controls, validators etc.

Year 2010-11 16 Group No. 58


CHAPTER 5

PROJECT PLAN AND RISK ANALYSIS

5.1 Project task set

The waterfall model derives its name due to the cascading effect from one phase to the

other as is illustrated in Figure1.1. In this model each phase well defined starting and ending

point, with identifiable deliveries to the next phase.

Year 2010-11 17 Group No. 58


5.2 Functional decomposition

Functional decomposition refers broadly to the process of resolving

a functional relationship into its constituent parts in such a way that the original function can be

reconstructed (i.e., recomposed) from those parts by function composition. In general, this

process of decomposition is undertaken either for the purpose of gaining insight into the identity

of the constituent components (which may reflect individual physical processes of interest, for

example), or for the purpose of obtaining a compressed representation of the global function, a

Year 2010-11 18 Group No. 58


task which is feasible only when the constituent processes possess a certain level

of modularity (i.e., independence or non-interaction).

5.3 Software sizing

A function point is a unit of measurement to express the amount of business

functionality an information system provides to a user. The cost (in dollars or hours) of a single

unit is calculated from past projects. Function points are the units of measure used by the IFPUG

Functional Size Measurement Method. The IFPUG FSM Method is an ISO recognized software

metric to size an information system based on the functionality that is perceived by the user of

the information system, independent of the technology used to implement the information

system. The IFPUG FSM Method (ISO/IEC 20926 SOFTWARE ENGINEERING - FUNCTION

POINT COUNTING PRACTICES MANUAL) is one of five currently recognized ISO standards

for functionally sizing software.

5.4 Timeline chart

A project timeline chart is presented. This may include a time line for the entire project or

for each staff member.

Project breakdown

1) Effort estimate table

Task Effort

weeks

Deliverables Milestones

Analysis of existing systems & compare

with proposed one

4 weeks

Year 2010-11 19 Group No. 58


Literature survey 1 week

Designing & planning 1+2 weeks

o System flow 1 weeks

o Designing modules & it’s

deliverables

2 week Modules

design document

Implementation 9 weeks Primary system

Testing 3 weeks Test Reports formal

Documentation 1 weeks Complete project

report

formal

2) Phase Description / Work breakdown :

Phase Task Description

Phase 1 Analysis Analyze all the information on the selected topic

Phase 2 Literature survey Collect raw data and elaborate on literature surveys.

Phase 3 Design Assign the module and design the process flow

control.

Phase 4 Implementation Implement the code for all the modules and integrate

all the modules.

Phase 5 Testing Test the code and overall process weather the process

works properly.

Phase 6 Documentation Prepare the document for this project with conclusion.

Phase Task Name

Phase 1 Analysis Ashish Agarwal Anand Vachhani

Phase 2 Literature survey Nitin Aggarwal Manoj Patel

Phase 3 Design Anand Vachhani Manoj Patel

Phase 4 Implementation Anand Vachhani Nitin Aggarwal Manoj Patel

Phase 5 Testing Ashish Agarwal Nitin Aggarwal

Phase 6 Documentation Ashish Agarwal Manoj Patel

Year 2010-11 20 Group No. 58


3) Project plan / work breakdown:

Date

PhaseS

EP

/10

OC

T/1

0

NO

V/1

0

DE

C/1

0

JAN

/11

Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

Phase 6

5.5 Risk Analysis

Risk Analysis is one of the important concepts in Software Product/Project Life Cycle.

Risk analysis is broadly defined to include risk assessment, risk characterization, risk

communication, risk management, and policy relating to risk. Risk Assessment is also called as

Security risk analysis.

5.6 Test Plan

A test plan documents the strategy that will be used to verify and ensure that a product or

system meets its design specifications and other requirements. A test plan is usually prepared by

or with significant input from Test Engineers. Depending on the product and the responsibility of

the organization to which the test plan applies, a test plan may include one or more of the

following:

There are two test plans :

Year 2010-11 21 Group No. 58


1.Automated Testing

2.Manual Testing

Automated Testing:-

Design Verification or Compliance test - to be performed during the development or

approval stages of the product, typically on a small sample of units.

Manufacturing or Production test - to be performed during preparation or assembly of the

product in an ongoing manner for purposes of performance verification and quality control.

Acceptance or Commissioning test - to be performed at the time of delivery or installation of

the product.

Service and Repair test - to be performed as required over the service life of the product.

Regression test - to be performed on an existing operational product, to verify that existing

functionality didn't get broken when other aspects of the environment are changed (e.g.,

upgrading the platform on which an existing application runs).

A complex system may have a high level test plan to address the overall requirements and

supporting test plans to address the design details of subsystems and components.

Test plan document formats can be as varied as the products and organizations to which they

apply. There are three major elements that should be described in the test plan: Test Coverage,

Test Methods, and Test Responsibilities. These are also used in a formal test strategy.

Test coverage in the test plan states what requirements will be verified during what stages of the

product life. Test Coverage is derived from design specifications and other requirements, such as

safety standards or regulatory codes, where each requirement or specification of the design

ideally will have one or more corresponding means of verification. Test coverage for different

product life stages may overlap, but will not necessarily be exactly the same for all stages. For

example, some requirements may be verified during Design Verification test, but not repeated

during Acceptance test. Test coverage also feeds back into the design process, since the product

may have to be designed to allow test access.

Test methods in the test plan state how test coverage will be implemented. Test methods may be

determined by standards, regulatory agencies, or contractual agreement, or may have to be

Year 2010-11 22 Group No. 58


created new. Test methods also specify test equipment to be used in the performance of the tests

and establish pass/fail criteria. Test methods used to verify hardware design requirements can

range from very simple steps, such as visual inspection, to elaborate test procedures that are

documented separately.

Test responsibilities include what organizations will perform the test methods and at each stage

of the product life. This allows test organizations to plan, acquire or develop test equipment and

other resources necessary to implement the test methods for which they are responsible. Test

responsibilities also includes, what data will be collected, and how that data will be stored and

reported (often referred to as "deliverables"). One outcome of a successful test plan should be a

record or report of the verification of all design specifications and requirements as agreed upon

by all parties.

Manual Testing:

It checks the testing operation like :

GO button : working properly (Yes) or (No)

REFRESH :working (yes) or (No)

STOP : working (yes) or (No)

FORWARD : (yes) or (No)

BACKWORD : working (yes) or (No)

Non-Functional Requirements

Run-Time

Requirements

Usability Describes the ease with which the system can be

learned or used.

A typical usability requirement might state:

1) Understandability

The interface elements should be easy to

understand e.g. menus.

Ambiguous naming should be avoided.

2) Learnability

The user documentation and help should be

Year 2010-11 23 Group No. 58


complete

The help should be context sensitive and

explain how to achieve common tasks

The system should be easy to learn

The system should allow users to install and

operate it with little or no training.

3) Operability

The interface actions and elements should be

consistent

Error messages should explain how to recover

from the error

Actions which cannot be undone should ask

for confirmation

The system be customizable to meet specific

user needs

There should be standard short-cut keys for

different functionalities. E.g. ctrl+s to save a

file.

The functionalities should be easy to

navigate.

4) Attractiveness

The screen layout and color should be

appealing.

5) Attractiveness

The screen layout and color should be

appealing.

Supportability Refers to the software’s ability to be easily modified or maintained to accommodate typical usage or change scenarios.

The system should provide user manual for

Year 2010-11 24 Group No. 58


guiding the user in using the system.

The system should provide online help for any user queries or problems.

Security Security refers to the ability to prevent and/or forbid access to the system by unauthorized parties.

Windows authentication is used for user authentication

Development-Time Requirements

Composeability Application components must be developed

more productive and obtain faster results

Build dynamic Windows based solutions

Communicate and collaborate more effectively within your software teams

Ensure quality early and often throughout the development process

Reusability Application components must be developed

more productive and obtain faster results

Build dynamic Windows based solutions

Communicate and collaborate more effectively within your software teams

Ensure quality early and often throughout the development process

Year 2010-11 25 Group No. 58


REFERENCE

Location-Based Spatial Query Processing in

Wireless Broadcast Environments

Wei-Shinn Ku, Member, IEEE, Roger Zimmermann, Senior Member, IEEE, and

Haixun Wang, Member, IEEE

IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. 7, NO. 6, JUNE 2008

[1] S. Acharya, R. Alonso, M.J. Franklin, and S.B. Zdonik, “Broadcast

Disks: Data Management for Asymmetric Communications

Environments,” Proc. ACM SIGMOD ’95, pp. 199-210, 1995.

[2] D. Barbara´ , “Mobile Computing and Databases: A Survey,”

IEEE Trans. Knowledge and Data Eng., vol. 11, no. 1, pp. 108-117,

Jan./Feb. 1999.

[3] N. Beckmann, H.-P. Kriegel, R. Schneider, and B. Seeger, “The

R*-Tree: An Efficient and Robust Access Method for Points and Rectangles,” Proc. ACM

SIGMOD ’90, pp. 322-331, 1990.

Year 2010-11 26 Group No. 58


Year 2010-11 27 Group No. 58

Documents

lbsq