PROJECT REPORT ON

DISTRIBUTED DATABASE ARCHITECTURE FOR GLOBAL ROAMING IN FUTURE MOBILE NETWORKS

By DAKHODE GAYATRI S. PATIL NIVEDITA B. KULKARNI PRANJALEE P. MEKHA SURAJ S.

DEPARTMENT OF COMPUTER ENGINEERING S.S.V.P.S.s B.S. DEORE COLLEGE OF ENGINEERING, DHULE- 424 005 2010 - 2011

PROJECT REPORT ON

DISTRIBUTED DATABASE ARCHITECTURE FOR GLOBAL ROAMING IN FUTURE MOBILE NETWORKS

By DAKHODE GAYATRI S. PATIL NIVEDITA B. KULKARNI PRANJALEE P. MEKHA SURAJ S. Guided by Mr.G.K.Patnaik

DEPARTMENT OF COMPUTER ENGINEERING S.S.V.P.S.s B.S. DEORE COLLEGE OF ENGINEERING DHULE- 424 005 2010 2011

II

S.S.V.P.S.s B.S. DEORE COLLEGE OF ENGINEERING DHULE-424 005 DEPARTMENT OF COMPUTER ENGINEERING

CERTIFICATE
Date :-

This is to certify that the project entitled DISTRIBUTED DATABASE ARCHITECTURE FOR GLOBAL ROAMING IN FUTURE MOBILE NETWORKS has been carried out by DAKHODE GAYATRI S., PATIL NIVEDITA B., KULKARNI PRANJALEE P., MEKHA SURAJ S. under the guidance of Mr. G. K. Patnaik in partial fulfillment of the degree of Bachelor of Engineering in Computer Engineering of North Maharashtra University, Jalgaon during the academic year 2010-2011. To the best of my knowledge and belief this work has not been submitted elsewhere for the award of any other degree.

Guide Mr. G.K.Patnaik

Examiner

Head of the Department Dr. H.D. Patil

Principal Dr. R.S.Jahagirdar

III

ACKNOWLEDGEMENT
We take this opportunity to express deep sense of gratitude and sincere thanks for the invaluable assistance that I have received, at the worthy hands of my guide Mr.G.K. Patnaik sir. I express my sincere thanks to our H.O.D. Dr.H.D. Patil sir for permitting us to the present this project and also to the entire staff members who have helped us directly or indirectly. We also express our thanks to our friends and well wishers for their underlying support shown during preparation of this project. Finally we would like to express our sincere gratitude toward our families for always being their when we needed them the most.

DAKHODE GAYATRI PATIL NIVEDITA KULKARNI PRANJALEE MEKHA SURAJ

IV

PAGE INDEX
Topic 1. ABSTRACT INTRODUCTION 1.1 INTRODUCTION 1.2 NEED OF SYSTEM 1.3 PROBLEM DEFINITION 1.4 EXISTING SYSTEM 1.5 ORGNIZATION OF REPORT ANALYSIS 2.1 PROJECT MANAGEMENT 2.2 REQUIREMENT ANALYSIS 2.2.1 SCOPE 2.2.2 VISION 2.3 RISK ANALYSIS 2.3.1 PROJECT RISKS 2.3.2 TECHNICAL RISKS 2.3.3 BUSINESS RISK 2.3.4 COST RISKS 2.3.5 PERFORMANCE RISKS 2.3.6 PREDICTABLE RISKS DESIGN 3.1 SOFTWARE REQUIREMENTS SPECIFICATION 3.2 PROPOSED SYSTEM 3.3 PRODUCT PERSPECTIVE 3.4 OPERATION 3.5 PRODUCT FUNCTION 3.6 DATABASE DESIGN 3.6.1 DATASTRUCTURE FOR DB0 3.6.2 DATASTRUCTURE FOR DB1 3.6.3 DATASTRUCTURE FOR DB2 3.6.4 DATASTRUCTURE FOR MOB 3.7 REQUIREMENTS 3.7.1 EXPECTED REQUIREMENTS 3.7.2 PERFORMANCE REQUIREMENTS 3.8 SOFTWARE SYSTEM CONSTRAINTS SYSTEM MODELING Page No. 01 02 02 03 05 06 07 09 09 10 10 10 11 11 12 12 12 13 13 14 14 14 16 16 16 18 18 18 18 19 19 19 19 20 21

7 8

4.1 UML DIAGRAMS IMPLEMENTATION ISSUES 5.1 HARDWARE SPECIFICATIONS 5.2 SOFTWARE SPECIFICATIONS 5.3 TOOLS TESTING 6.1 TESTING 6.1.1 TEST PLAN 6.1.2 SAMPLE DATABASES CONCLUSION BIBLOGRAPHY APPENDIX POWER POINT SLIDES

21 28 28 28 28 29 29 30 31 37 38 39

VI

FIGURE INDEX
Fig. No 1.1 1.2 3.1 4.1 4.2 4.3 4.4 Figure 2-TIER SYSTEM STANDARD PCS ARCHITECTURE PROPOSED MULTITREE DATABASE ARCHITECTURE USE CASE DIAGRAM CLASS DIAGRAM SEQUENCE DIAGRAM COLLABORATION DIAGRAM Page No. 6 7 14 21 23 25 27

VII

TABLE INDEX
Table. Table Name No 3.1 DATASTRUCTURE FOR DB0 3.2 3.3 3.4 6.1 6.2 6.3 6.4 DATASTRUCTURE FOR DB1 DATASTRUCTURE FOR DB2 DATASTRUCTURE FOR MOB SAMPLE D/B FOR COUNTRY TABLE SAMPLE D/B FOR STATE TABLE SAMPLE D/B FOR CITY TABLE SAMPLE D/B FOR MOB TABLE Page No. 18 18 19 19 31 31 32 33

VIII

ABSTRACT
The future mobile network will support terminal mobility, personal mobility and service provider portability. A location independent Personal Telecommunication Number (PTN) technique is useful for implementing such a global mobile system. The service providers may be combined in future, then the number of users will be increasing tremendously. In this case, future mobile networks may introduce very large, centralized database. The proposed system is multi tree structure consisting of number of distributed database subsystems, each of which is a three level tree structure and is connected to others only through its root. This architecture effectively reduces the database loads as well as signaling traffic incurred by location registration and call delivery procedures. The proposed database architecture for location management can effectively support the anticipated high user density in the future mobile networks.

CHAPTER 1

INTRODUCTION
1.1 Introduction
The next-generation mobile network will be an integrated global system that will provide heterogeneous services across network providers, network backbones and geographical regions. Global roaming is a basic service of the future mobile networks where terminal mobility, personal mobility and service provider portability must be supported. A nongeographic personal telecommunication number (PTN) for each mobile user is desirable to implement these types of mobile freedom. With location-independent PTNs, users can access their personalized services regardless of terminal or attachment point to the network; they can move into different service providers network and continue to receive subscribed services without changing their PTNs. Another advantage of the flat PTN scheme is that it is much more efficient in terms of capacity than the location-dependent numbering scheme. However, using the location-independent numbering plan may introduce large centralized databases into a mobile system. To make things worse, each call may require an interrogation to the centralized databases, thus signaling traffic will grow considerably and call setup time may increase dramatically. The large centralized databases may become the bottleneck of the global mobile system, thus necessitating research into the design and performance of high-throughput database technologies as used in mobile networks to meet future demands[4]. Location management is one of the most important functions to support global roaming. Location management procedures involve numerous operations in various databases. These databases record the relevant information of a mobile

user, trace the users location by updating the relevant database entries and map the users PTN to its current location. In current cellular networks location tracking is based on two types of location databases : Home Location Register (HLR) and Visitor Location Register (VLR). In general, there is an HLR for each mobile network. Each mobile subscriber has a service profile stored in the HLR. The user profile contains information such as the service types subscribed, the users current location, etc. The VLR where a mobile terminal (MT) resides also keeps a copy of the MTs user profile. A VLR is usually collocated with a Mobile Switching Center (MSC), which controls a group of registration areas (RAs). Whenever an MT changes its RA, the HLR is updated to point to the new location, and the MT is deregistered from the old VLR. As an incoming call arrives, the called MTs HLR is queried to get the location of the serving VLR of the MT, then a routing address request message is sent to the MSC/VLR. The MSC allocates a Temporary Local Directory Number (TLDN) to the called MT and sends back the TLDN to the HLR, which in turn relays this information to the calling MSC. An MSC/VLR may not know the address of an MTs HLR, and a Global Title Translation (GTT) is needed to get the address of the MTs HLR.

1.2 Need of system:

1) A location-independent PTN provides a basis for global roaming in the nextgeneration mobile networks where terminal mobility, personal mobility and service provider portability will be implemented. A mobile subscriber can retain its lifelong PTN regardless of its location and service provider [2]. 2) The multitree database architecture is much more robust than the one-root hierarchical architecture. In the proposed architecture, an MTs profile is stored in one of the root databases according to its current location. Thus, each root

database only maintains a small portion of the user profiles in the global mobile system. The crash of one root database will not disrupt the operation of other root databases and the recovery of the failed root database is much easier than in the one-root database architecture where all user profiles need to be recovered once the root is crashed. 3) The multitree database architecture is scalable which is crucial to support continuously increasing number of mobile subscribers in future mobile networks. When the capacity of a root database is saturated, a new DS is readily added. More importantly, the end-to-end delay in location registration and call delivery will not increase due to such an expansion in the mobile network. On the other hand, with the one-root structure, when the capacity of the root or a high-level database is saturated, more levels of databases need to be added in order to reduce the burden on the root or high-level databases. This will increase the delays in location registration and call delivery[4]. 4) The proposed multitree database system is easy to expand and maintain in the multioperator environment of a global mobile system. With the multitree architecture, each service provider can have its own DS and it is straightforward for a service provider to expand its service coverage by adding new DSs. It is also easy to operate and manage a DS when the DS is wholly owned by a single service provider. The one-root architecture, however, may not have such advantages. 5) No GTT is required in the proposed database architecture, where a signaling message is only sent from a database to another database in an adjacent level within the same subtree or from a DB0 to another DB0. Since a message sender always contains the address of the receiver in its database, no GTT is required. This greatly simplifies the implementation of the proposed architecture.

1.3 Problem Definition:

With the two-level HLR-VLR database architecture, the HLR needs to be accessed for each location update or call delivery. Due to an expected much higher user density in the future mobile networks, the updating and querying loads on the location databases will be very heavy and the two-level database architecture will become infeasible. In the forwarding strategy, a forwarding pointer is set up in the old VLR pointing to the new VLR of an MT to avoid a location update at the HLR as the MT changes its RA. When a call for the MT arrives, the HLR is queried first to determine the first VLR which the MT was registered at, and a forwarding pointer chain is followed to locate the MT in its current VLR. The forwarding strategy reduces location update signaling but increases the call setup delay. Thus, the length of the forwarding point chain needs to be limited. The forwarding scheme is effective only when the call arrival rate is low relative to the mobility rate for an MT. With the anchoring strategy location updates are performed at a nearby VLR (i.e. local anchor) for an MT to reduce signaling traffic between the HLR and the VLRs. The HLR maintains a pointer to the MTs local anchor. As an incoming call occurs, the HLR forwards the call to the local anchor, which in turn queries the serving VLR of the MT for a TLDN. The call delivery time is increased due to one extra database query to the local anchor[2]. With the caching strategy, an MTs location obtained from a previous call is cached and re-used for subsequent calls to that MT. After a cache entry of the MTs location information is created at a Signal Transfer Point (STP), if another call for the MT is received by the STP, the STP will forward the call to the VLR

as specified by the cache. If the MT is still in the same VLR, a hit occurs and the call is successfully delivered[2]. When an MT changes its location more often than receiving calls, the caching scheme may become inefficient in reducing cost. In the replication strategy an MTs location is replicated at selected local databases, so that calls to the MT originating from the service area of these replicated databases can be routed without querying the HLR. When the MT changes its location, all replicated databases need to be updated for the MT, thus incurring a high database update load and signaling traffic, especially for highly mobile users. In summary, each auxiliary strategy outperforms the IS-41 only under certain calling and mobility parameters. As the cell sizes become smaller to support an increasing user density and the number of mobile subscribers increases, even these augmentations will not be sufficient to meet the future demands of mobile networks.

1.4 Existing System

Two-level Hierarchical Strategy: In IS-41 and GSM MAP, the two-level strategies are proposed. A two-tier system of home and visited databases.

Fig.1.1: 2-tier system

Fig.1.2: Standard PCS Architecture.

1.5 Organization of report

The report is organized in a way to cover all important points that are required to make this report self explanatory. This report is divided into following sections.: Introduction Inception Elaboration Basic design Conclusion Bibliography Appendix In the software development lifecycle, we follow the analysis of the problem at hand is done first. This is followed by designing. Thus we start the analysis and requirement gathering followed by the designing. The system is modeled in

Unified Modeling Language. While handling with this software development, we go through different and distinct development stages. Firstly we go for planning in which manner software will run. Then we divide project in some modules. System design is a next in which we went through the software quality parameters. Further we do the main part of coding in which we do the form designing in VB.Net for entering the records. These forms are linked with the tables in Oracle where the data is actually saved. The tables are divided as Country, State, City and Mobile. The source and destination numbers are entered the Mobile table. The output of this table is the path between the source and the destination. This path includes the names, as entered, of the cities, states and countries of both the parties which are going to be involved in the conversation. This path is the final executable output. Afterwards, testing of the software is done. Testing includes giving different inputs and checking whether the path being drawn is correct.

CHAPTER 2

ANALYSIS
2.1

PROJECT MANAGEMENT

Project management involves the planning, monitoring and control of people, process and event that occurs as software evolved from a preliminary concept to an operational implementation.

MONTH July

WEEK 1 2 3 4

TASK Search for area of project. Search for project topic. Find specifications for project. Detail information about project. Finalize project topic. Define problem definition. Abstract solution, actual solution. Analyzing problem definition. Study of Software Metrics. Define scope and vision. Detailed analysis of project. UML design. Preparation of partial report. Slides for presentation. Study the techniques to develop code. Installation & configuration.

August

1 2 3 4

September

1 2 3

October

1 2 3

December January

1 1

2 3 4 February 1 2 March 1 2 3 4

Design layout of project & build module diagrams. Design of GUI. GUI coding. Hardware kit development. Modules implementation. Finalize all the modules. Deploy each module on system. Testing phase. Final project report & slides preparation.

2.2

Requirement Analysis

Requirement analysis bridges the gap between system engineering and software design. Requirement analysis is the most important task in Software Development Life Cycle.

2.2.1 Scope The proposed system attempts to provide the multi-tree database structure consisting of number of database sub-systems, each of which consists of a threelevel tree structure and is connected to others through root. By exploiting the localized nature of calling and mobility patterns, the proposed architecture effectively reduces the database loads as well as the signaling traffic incurred by location registration and call delivery procedures. It supports the anticipated high user density in future mobile networks.

10

2.2.2 Vision To develop a system that attempts to provide a robust solution to the problems like high user density, high query evaluation, traffic incurred by location registration and call delivery procedures.

2.3 Risk Analysis Before embarking in the project, it is necessary to review all the risks that might involve in it. These risks have been documented as before coding for the project was started. Majorities of the risk components lie under the following categories.: 1. Project Risks (PR) Project risks threaten the project plan. If the project risk becomes real, it is likely that project schedule will slip and that costs will increase. 2. Technical Risks (TR) Technical risks threaten the quality and timeliness of the software to be produced if they become reality, implementation may become difficult. 3. Business Risks (BR) Business risks threaten the viability of the software to be built. Business risks often jeopardize the project or the product.

2.3.1 Project Risks Sr. No. 1. Risks Will the project overshoot predefined deadlines? 2. Will the resources remain stable throughout? 3. Will the customer Low Marginal Low Marginal Likelihood Medium Impact Marginal

11

requirements remain same throughout the development of the project?

2.3.2 Technical Risks Sr. No. 1. Risk Is the support material for the development of this project is available such as research papers, documents of similar software? 2. Will the performance of project decreased in pick hours? Low Marginal Likelihood Low Impact Marginal

2.3.3 Business Risk Sr. No. 1. Risk Will the customer not be satisfied? Likelihood Medium Impact Disastrous

2.3.4 Cost Risks Sr. No. 1. Risk Is the final cost of the product above the estimated cost? Likelihood Low Impact Marginal

12

2.

Does the development cost of the project exceed the project budget?

Low

Marginal

2.3.5 Performance Risks Sr. No. 1. Risk Will the product not meet the specific standard? 2. Will the hardware fail to provide all the services? 3. Whether the performance of the project will be decreased if multiple clients will join? Medium Marginal Medium Marginal Likelihood Medium Impact Marginal

2.3.6 Predictable Risks Sr. No. 1. Risk Installed on non-compatible operating system 2. Power failure Low Marginal Likelihood Low Impact Marginal

13

CHAPTER 3

DESIGN
3.1 Software Requirements Specification
The Software Specification produces at a function and performance allocated to software as a part of system engineering are refined by establishing a complete information description, detail function and behavioural description in the indication of performance requirement and design constraint, appropriate validation criteria and other data pertaining to requirement. Both the software developers and customers conduct review of software requirement specification. The review is first conducted at macroscopic level and then detailed level. Once the review is completed, both customer and developer sign off a contract for software development.

3.2 Proposed System

Fig3.1: Proposed multitree database architecture [4].

14

The proposed database architecture for location tracking is a multitree structure, where each subsystem is a three-level architecture (Fig.3.1), referred to as a Database Subsystem (DS). Various DSs may represent networks operated possibly by different service providers. All these DSs are interconnected together via a fixed network, such as PSTN or ATM network, and communicate with each other only through their root databases. This architecture can support a multioperator environment which is expected in future mobile networks. In each DS, databases DB0 and DB2 may correspond to the HLR and the VLR in the two-level database system respectively. Each DB2 may control an RA where a user can roam freely without triggering registrations. Each DB2 is collocated with an MSC, which performs call processing on origination or termination of calls. A number of DB2s are grouped into one DB1 and several DB1s are connected to a single DB0. Each DB1 and DB0 also needs a switch, called the STP, which provides routing functionality for message exchange between various location databases. The DB0 maintains the service profile for each user currently residing in its service area and maintains an entry for each user in the global mobile system. The entry contains either a pointer to another DB0 where the user is residing or a pointer to the user record that contains a pointer to the DB1 with which the user is currently associated. Each DB1 has an entry for every currently residing user, storing a pointer to the DB2 the user is currently visiting. Every DB2 has a copy of the service profiles of the users currently roaming within its area. With this architecture, the frequency of queries to the higher level databases is greatly reduced due to the locality of calling and mobility patterns.

15

3.3 Product Perspective

The Distributed Database Architecture for Global Roaming in Future Mobile Network will help to reduce the increasing amount of load on databases when the service providers combine together and user density will increase tremendously.

3.3.1 System Interface Any of the Oracle 8i/9i/10g can be used to enter the data in the system. This data will be directly reflected into the front end.

3.4 Operation
The whole database is stored at server side which contains all the mobile subscribers. It will show the graphical path representation when the mobile user moves from one area to another area.

3.5 Product Functions

3.5.1 Data Input Data input is in the form of mobile numbers. The source and destination mobile numbers are entered through the forms designed.

3.5.2 Data Processing The entered data i.e. the mobile numbers of source and destinations are processed at different levels such as-1. DB0 2. DB1 3. DB2

16

3.5.6 Data Output The output is displayed in the form of visual graph on the screen.

3.5.7 Monitoring This project will conduct a number of self-monitoring activities on application and system software as well as hardware system to detect the system failure and database updation.

3.5.7 Recovery The system contains a large number of distributed database subsystems which are connected to each other through PSTN. The crash in one DS will not affect the function of other DSs; because the whole crashed DS will be replaced by another new DS so the other connected DSs will not get affected because of the crashed DS which in turn will not affect the database. So recovery is possible.

3.5.8 Reliability It contains a large number of distributed database subsystems connected to each other through PSTN. The crash in of a DS will not affect the function of other DSs; because the whole crashed DS will be readily replaced by another new DS so the other connected DS will not get spoiled due to the damaged DS. Hence the system is reliable.

17

3.6 Database Design

3.6.1 Data structure for DB0 The DB0 database is the root database. Hence it is considered as the database for Country. According to that, this database has been designed so that it contains the parameters as DB0_code (i.e. country_code) and DB0_name (i.e. country_name). DB0_code is the primary key.
Table 3.1: Data structure for DB0

Name country_code country_name

Null? Not Null

Type Varchar2(25) Varchar2(25)

3.6.2 Data structure for DB1 The DB1 database is the intermediate database. Hence it is considered as the database for State. According to that, this database has been designed so that it contains the parameters as DB0_code (i.e. country_code), DB1_code (i.e. state_code) and DB1_name (i.e. state_name). DB1_code is the primary key.
Table 3.2: Data structure for DB1

Name state_code state_name country_code

Null? Not Null

Type Varchar2(25) Varchar2(25) Varchar2(25)

3.6.3 Data structure for DB2 The DB2 database is the lowest level database. Hence it is considered as the database for City. According to that, this database has been designed so that it

18

contains the parameters as DB1_code (i.e. state_code), DB2_code (i.e. city_code) and DB2_name (i.e. city_name). DB2_code is the primary key.
Table 3.3: Data structure for DB2

Name city_code city_name state_code

Null? Not Null

Type Varchar2(25) Varchar2(25) Varchar2(25)

3.6.4 Data structure for Mob (Input) This database is used for location registration procedure. It is the first interface between the system and the user. A subscriber enters his/her PTN (i.e. mob_no) along with the current (i.e. home) location in the database. The mob_no is the primary key.
Table 3.4: Data structure for Mob

Name mob_no city_code

Null? Not Null

Type Number(12) Varchar2(25)

3.7 Requirements
3.7.1 Expected Requirements - It should provide the authentication. - User friendly and easy to use approach.

3.7.2 Performance Requirements - Large number of users can use the system at a time.

19

- Number of users will not affect the speed of location registration and call delivery processes.

3.8 Software System Constraints

Mobility Registration The software requires a changed location of a mobile subscriber to be updated manually.

20

CHAPTER 4

SYSTEM MODELING
4.1UMLDiagrams
A diagram is a graphical representation of the set of elements, most rendered as a connected graph of vertices and arcs. Diagrams can be classified as follows. :

4.1.1 User View It includes Use Case diagrams. A Use Case describes user view of the system. They are simple graphical description of how the system will be used by the user. The use cases are very simple to create and understand even by a non-technical person [3].

check for registration

check for availability centralized DB

connect call region1

verify registration region2 location found

making call

check for PTN

user 1 user 2

Fig 4.1 Use Case Diagram.

21

Whenever a call is to be connected between a caller/calling party and a callee/called party, some activities are performed. They are as follows. : - The callers local database is consulted for making a call. - This local database queries the centralized database for checking the registration of the callee. - Centralized database verifies the registration of the callee. - The called partys local database is queried for checking its PTN. - Thus the callees location is found. - Then the callees availability is checked. - If it is available, then the call is connected. Otherwise, the call is dropped.

22

4.1.2 Structural View It includes class diagrams. These are important diagrams developed during object oriented design phase. Class Diagram is a powerful technique in requirement analysis. It describes the types of objects that exist in the system and shows the relationship among international classes of the system. The class diagram can be used to show the attributes and operations of classes [3].
source PTN location registration procedure get the input()

centralized database region current node pointer update node location() roaming()

destination verification procedure region points update query table and node path() verify exiisting and praposed db evaluation()

4.2 Class Diagram.

This system contains three classes as shown above. Their atributes and operations performed by them are also shown in the above class diagram. These classes function as follows. :

23

- Source class It uses the PTN and the location registration procedure for getting the input. The input is nothing but the callers PTN (i.e. mobile number). The callers current location is automatically verified by querying the databases. - Destination class It uses the verification procedure to fix the location area. It updates the query tables when a subscriber changes its location. It also runs the verification procedure. - Centralized Database class This class actually contains three kinds of databases namely DB0, DB1 and DB2. It keeps the records of home locations and current locations of the suscribers. Using these records, it updates the node locations and provides the Roaming facility. It gives the freedom of moving anywhere (terminal mobility) using Global Roaming.

24

4.1.3 Behavioural View It includes Sequence Diagram. This diagram shows the description of how objects of a system interact over time. The sequence diagram displays the overall flow control in an object oriented program [3].

4.3 Sequence Diagram.

This diagram shows the sequence of queries generated during call origination procedure. : - First, the PTN (mobile number) is checked and verified. This query is generated by the source (caller) and processed by the centralized database. - Then a query is generated by the database for checking the location of the destination (callee).

25

- If the callees location is found, its registration is checked in the centralized database. Otherwise the call is dropped. - After checking registration, the call between the two parties is connected. - Finally the adjacent locations are verified for ensuring the uniqueness of the database entries.

26

4.1.4 Collaboration diagram: The collaboration occurrence notation is used to show the use of patterns. The degree of collaboration shows the amount of reusability of the modules. The details shown by this diagram also include the number of elements of different modules interacting with each other. This diagram also shows how the elements intract over time, just like the sequence diagram.

:source

:destination

1: 1.check for call procedure and PTN 2: 2.check for location

3: 3.if location found check for registration 4: 4.make call delivery 5: 5.verify adjacent locations

:centralized DB

Fig 4.4 Collaboration Diagram.

27

Chapter 5

IMPLEMENTATION ISSUES
5.1 Hardware Specifications Optimum configuration 1. 1 GB RAM 2. 160 GB Hard Disk 3. Intel Processor-IV

5.2 Software Specifications Operating System : Windows XP/Vista/7 Language : VB.net Database : Oracle 9i/10g

5.3 Tools Rational Rose 98 Enterprise Edition

28

Chapter 6

TESTING
6.1 Testing Software Testing is the process of confirming the functionality and correctness of software by running it. Software testing is usually performed for one of the two reasons.: 1. Defect detection 2. Reliability estimition White box testing is concerned only with testing the software product; it cannot guarantee that the complete specification has been implemented. Black box testing is concerned only with testing the specifications; it cannot guarantee that all parts of the implementation have been tested. The black box testing is the testing against the specifications and will discover faults of omission, indicating that part of specification has not been fulfilled. White box testing is the testing against the implementation and will discover faults of commission, indicating that part of the implementation is faulty. In order to fully test a software product, both black box testing and white box testing are required. The problem of applying software testing to defect detection is that software can only suggest the presence of flaws, not their absence (unless the testing is exhaustive). The problem of applying software testing to reliability estimation is that the input distribution used for selecting test cases may be flawed. In both of these cases, the mechanism used to determine whether program output is correct is often impossible to develop. Software is now unique unlike other physical processes where inputs are received and outputs are produced. Where software differs is in the manner in which it

29

fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways. Detecting all of the failure modes for software is generally infeasible. The key to software testing is trying to find the myriad of failure modes something that requires exhaustively testing the code on all possible inputs. Functional testing is a testing process that is black box in nature. It is aimed at examining the overall functionality of the product. It usually includes testing of all the interfaces and should therefore involve the clients in the process. System testing, the final stage of testing process, involves examination of the whole computer system, all the software components, all the hardware components and any interfaces. The whole computer based system is checked not only for validity but also to meet the objectives.

6.1.1 Test Plan Modules are to be built in incremental manner. Each module is then to be tested individually (unit testing). Testing is done to ensure that the modules meet their required specifications and performed up to the desired level. Then, modules are to be integrated. After integration, regression testing is to be performed to ensure that the integration does not introduce new bugs. Finally, when all modules are put in place, alpha testing is to be done to ensure that the system lives up its desired performance and satisfies the requirements. This plan was followed rigorously and bugs in the code and/or were traced and eliminated. The test cases used and the result obtained at the end of all test activities are given below in a tabular format for ease in comprehensions.

30

6.1.2 Sample databases As specified previously, the database contains four tables namely Country, State, City and Mob. The sample data in these tables are as follows. : 6.1.2.1 Sample database for Country table
Table 6.1: SampleDatabase for Country table

DB0_code DB0_1 DB0_2 DB0_3 DB0_4

DB0_name DB01 DB02 DB03 DB04

We may consider the countries as DB01 = India, DB02 = Australia, DB03 = Japan, DB04 = China.

6.1.2.2 Sample database for State table

Table 6.2: SampleDatabase for State table

DB0_code DB0_1 DB0_1 DB0_2 DB0_2

DB1_code DB0_1_1 DB0_1_2 DB0_2_1 DB0_2_2

DB1_name DB011 DB012 DB021 DB022

We may consider the states as

31

DB011 = Maharashtra, DB012 = Gujarat, DB021 = New South Wales, DB022 = Queensland.

6.1.2.3 Sample database for City table

Table 6.3: SampleDatabase for City table

DB1_code DB0_1_1

DB2_code DB0_1_1_1 DB0_1_1_2

DB2_name DB0111 DB0112 DB0121 DB0122 DB0211 DB0212 DB0221 DB0222

DB0_1_2

DB0_1_2_1 DB0_1_2_2

DB0_2_1

DB0_2_1_1 DB0_2_1_2

DB0_2_2

DB0_2_2_1 DB0_2_2_2

We may consider the cities as DB0111 = Mumbai, DB0112 = Dhule, DB0121 = Gandhinagar, DB0122 = Ahmedabad, DB0211 = Sydney, DB0212 = Canberra, DB0221 = Brisbane, DB0222 = Gold Coast.

32

6.1.2.4 Sample database for Mob table

Table 6.4: SampleDatabase for Mob table

DB2_code DB0_1_1_1

Mobile number 9400000001 9400000002

DB0_1_1_2 DB0_1_2_1 DB0_1_2_2 DB0_2_1_1 DB0_2_1_2 DB0_2_2_1 DB0_2_2_2

9400000003 9400000004 9400000005 9500000006 9500000007 9500000008 9500000009

6.1.3 Test Cases and Test Results There are four possibilities of connecting a call between two parties. : 6.1.3.1 Within same DB2 i.e. within same city Example: The caller and the callee, both are in Mumbai. Here, all the databases in the database hierarchy are same for both the parties. Hence, the path shown by the system is as follows.:

33

9400000001 9400000002 (Caller) (Callee)

6.1.3.2 In different DB2s (i.e. cities) under the same DB1 (state) Example: The caller is in Mumbai while the callee is in Pune. Here, only the DB2s are different for both the parties; remaining all the databases in the database hierarchy are same. Hence, the path shown by the system is as follows.:

9400000001 (Caller)

9400000003 (Callee)

34

6.1.3.3 In different DB1s (i.e. states) under the same DB0 (country) Example: The caller is in Mumbai, Maharashtra while the callee is in Gandhinagar, Gujarat. Here, the DB2s as well as the DB1s are different for both the parties; only the DB1 is same. Hence, the path shown by the system is as follows.:

9400000001 (Caller) 6.1.3.4 In different DB0s (i.e. countries)

9400000004 (Callee)

Example: The caller is in Mumbai, Maharashtra, India while the callee is in Sydney, New South Wales, Australia. Here, all the databases in the database hierarchy are different for both the parties. Hence, the path shown by the system is as follows. :

35

DS

DS DS PSTN nN

DS

DS

DS

In this way, all the databases in the database hierarchy are searched hierarchically till the called partys location is not found. Due to this nature of the 3-level architecture, the root database (DB0) has to be queried only when the callee is in other DB0 (i.e. country). Hence, up to 66% of the database loads can be reduced.

36

CHAPTER 7

CONCLUSION
A distributed multitree database architecture has been proposed for location management in a global mobile system, where the location-independent PTNs are employed to support seamless global roaming. To support the anticipated large number of mobile users in the future mobile system, T-tree is proposed to achieve high database throughput, so that the end-to-end delays in location registration and call delivery can meet the delay requirements in mobile networks. The proposed database architecture is scalable, robust and efficient. Compared to the existing two-level location database architecture, the proposed database architecture can support a much higher user density while reducing signaling load significantly. For performance evaluation, analysis model was developed. The proposed database architecture can effectively handle the anticipated high update and query rates to the location databases in future mobile networks. The proposed database access structures are also suitable for other large centralized databases in mobile networks, such as the authentication center and the equipment identity register.

37

BIBLIOGRAPHY
[1] I. F. Akyildiz, J. Mcnair, J. S. M. Ho, H. Uzunalioglu, and W. Wang, Mobility management in next-generation wireless systems, Proc.IEEE, vol. 87, August 1999, PP 13471384.

[2] K.Lenin, Distributed Database Architecture For Global Roaming In Future Mobile Network,The Indian Journal January-march 2010,PP.31-44. of Technical Education,vol.33,no.1,

[3] Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Low price edition, India, Pearson Education, sixth edition, 2001.

[4] Zuji Mao, Christos Douligeris: Distributed Database Architecture for Global Roaming in Next Generation Mobile Network, IEEE/ACM Trans.netw, Vol. 12, February 2004, PP 46-160.

38

39