The Design and Implementation of
the Geographical Location Information System
Yasuhito Watanabe Atsushi Shionozaki
Fumio Teraoka Jun Murai
Abstract
In this paper, we propose the Geographical Lo- cation Information (GLI) System. The GLI sys- tem provides a way to map geographical location of entities and identifiers on the Internet. It con- sists of three components; 1)servers that maintain geographical location information for each entity in databases, 2)agents that register entity geo- graphical location information with servers, and 3)clients that issue entity/location queries. The server manages entries that consist of entity iden- tifiers and geographical location information. A client can look up entity identifiers by specify- ing location as a key, and vice versa. The de- sign and implementation of a prototype system is also described. The prototype uses IP addresses as identifiers on the Internet. The effectiveness of the GLI system is shown through experiments based on our prototype. The GLI system is in- dependent of machine architecture, and has been tested on BSD/OS, SunOS, and NEWS-OS. We are presently experimenting with the GLI system by running it on the Internet.
1 Introduction
The Internet is now closer to everyday lives more than ever, as its popularity has increased dramatically. Research in this area is focusing to- wards more practical applications, which include the use of mobile computers and non-computer entities with network connectivity. As a result, the number of entities connected to the Inter- net is constantly increasing as their locations be- come more widely distributed and topology is ever changing. To access these entities in a practi- cal way, it is necessary to obtain geographical lo- cation information of an entity connected to the Internet. In the TCP/IP network architecture, the IP address already provides a way to iden- tify the topological location of a connected host.
However, there has been no architecture or sys- tem proposed that provides geographical location information of any entity accessible through the Internet, even though it is greatly needed. Thus
it is necessary to define the relationship between entity and its geographical location in the real world. This paper proposes the Geographical Lo- cation Information (GLI) System, which provides a way to map geographical location of entities and identifiers on the Internet. The prototype uses IP addresses as identifiers on the Internet. The system makes it possible to look up entity iden- tifiers based on physical location, and to look up location based on entity identifiers. Thus users can search for various entities of the real world through the Internet and obtain up-to-date loca- tion information of the specified entities in real- time.
This paper is organized as follows. In Section 2, we discuss ways to integrate location informa- tion into the Internet environment that provides a framework for our GLI System. The design of our prototype GLI System is described in Section 3, and its implementation in Section 4. We eval- uate our prototype system in Section 5. Section 6 describes related work. We conclude the paper with Section 7, and describe some directions for future work.
2 Location Information Integration
Our goal is to be able to access real world en- tities through the Internet by incorporating geo- graphical location information. Namely, it is nec- essary to map identifiers on the Internet to geo- graphical location. In this section, we discuss and present ideas on how to incorporate geographical location information into the Internet.
We use the the word, entity, in this paper to signify any physical object that can be found in the real world or on the Internet, such as cars, people, houses, parking lots, hosts, files, pro- cesses, etc.
2.1 Information Types
There are various ways to represent geograph- ical location information of various entities in real world situations and many types of entities also exist on the Internet. We describe various ways to represent location information in the real world
and different identifiers used to represent entities on the Internet.
Geographical Location Representa- tion of Entities
Geographical location information is a barom- eter of the real world and there are various pa- rameters to represent location information of an entity. These parameters include coordinate sys- tem, name, accuracy, speed, direction, and di- mension.
In the real world, two major coordinate sys- tems are used to represent the absolute location of entities on the earth. They are Latitude Lon- gitude Altitude (LLA), and XYZ Earth Center Earth Fix (XYZ ECEF). However, in general, these coordinates are not used in everyday lives, but people use a more simple expression that rep- resents a name of a given location or area clas- sified hierarchically or traditionally (e.g., coun- try, state, prefecture, city, street, etc.). Thus for practical use, it is usually necessary to trans- late absolute location coordinates into location names. Also, since the shape of the earth is not a perfect sphere, surveying schemes that in- corporate datums that model specific limited ar- eas need to be introduced. Each official national map is generally derived from the datums for that country, for example, NAD-27 is the datum used in North America, Tokyo is the datum used in Japan. There is also a datum known as WGS-84 that models the entire earth. If the location infor- mation determined from a device such as GPS in Tokyo is based on the datum WGS-84, it should be translated into coordinates based on the da- tum Tokyo. Thus, datum is an important pa- rameter that must be incorporated in a general purpose location information processing system.
The level of accuracy of location information provided by a system depends on hardware, user requirements, and usage. For example, a car nav- igation system will function with an accuracy in the order of 10m diameters. Gas and water util- ity systems need accuracy in the order of about 10cm. In geology or seismology, measurements must be accurate in the order of 1mm. Thus, when integrating geographical location informa- tion into a general purpose location information processing system, various levels of accuracy must be supported. The order of accuracy supported by data in computers will be determined by the bit length allocated for this information. Assum- ing that the length of the equator is 40,000km, Table 1 shows the bits required to support various orders of length units.
Some entities on the earth are fixed and others change location dynamically. A value for speed
Table 1: Bits required to support order of accu- racy
order bit length
1mm 36bits
1cm 32bits
1m 26bits
10m 22bits
100m 19bits
1km 16bits
10km 12bits
100km 9bits
and direction must be maintained for mobile en- tities. If the speed and direction of a mobile entity can be determined, its location can be represented more accurately.
Lastly, most physical entities in the real world have dimensions so a single coordinate may not provide sufficient information to represent it. To solve this problem, several simple schemes to specify the dimensions of an entity can be intro- duced. An example would be to represent an en- tity’s area with a center coordinate and a specified radius or a triangular or square area, etc. How- ever, the dimensions determined by this scheme will introduce error and ignore shape of the en- tity. A more exact scheme would be to specify the dimensions of an entity as an area surrounded by points specified by coordinates. However, the complexity of an entity’s shape will increase in- formation needed for its representation.
Geographical Location Hierarchy
In order to provide a more practical scheme for representing and accessing geographical location information from coordinates, a more organized representation scheme must be provided. We pro- pose a hierarchical representation structure of ge- ographical location as shown in Figure 1.
There are three levels of representations in the hierarchical structure: coordinate, area, and tag.
The coordinate is the most primitive of the three and is simply a value expressed by coordinate sys- tems, such as LLA and XYZ ECEF. Area is a two or three dimensional space that can be defined arbitrarily with points specified by coordinates.
Area can also be represented with a center co- ordinate and a specified radius or other shapes (triangle, square, sphere, etc.). For practical use, coordinates mapped to areas are represented by strings called a tag. Users of a geographical lo- cation information service can use these tags to specify a certain area or coordinates.
Coordinate Area Tag
Country
CityBuilding Parking Lots Car
Figure 1: Hierarchical representation structure of geographical location
Internet Identifiers
Various identifiers are used on the Internet to represent entities such as hosts, files, and pro- cesses. These include Internet addresses (IP ad- dress), domain names, and Uniform Resource Lo- cators (URL).
All hosts connected to the Internet are as- signed a 32bit IP address (in IP Version 4). An IP address consists of a network number and a host number. The network number identifies a spe- cific network on the Internet and the host number identifies a host in the network specified by the network number.
Since the IP address includes both network number and host number, if a host moves to an- other network, it must be assigned a new IP ad- dress on the network. The Virtual Internet Pro- tocol (VIP)[1] solves this problem. A VIP host is allocated an IP address and a VIP address. Since the VIP address is not immutable, hosts can move to another network even if its IP address changes.
Thus, the VIP address can be considered to be the true host identifier.
In the Internet, a hierarchical naming mecha- nism classified by organization structure was in- troduced to support a large number of hosts that are widely distributed. The mechanism used in this scheme is called the domain name system.
A domain name is a concatenation of subdomain names separated by periods.
To access data on the hosts connected to the Internet, the Uniform Resource Locator (URL) is used. A URL consists of a schemer (e.g., protocol name: http, ftp, gopher, etc. ), a hostname, a domain name, and a path name.
It is important to define the relationship be- tween these Internet identifiers and geographical
location information. As non-computer entities such as cars, people, and sensors will be acces- sible on the Internet, through hosts or directly from network interface devices attached to them, a more global identifier that can represent such entities will be needed. This will be discussed in a future paper.
2.2 Information Management
In order to look up geographical location of a specified entity or search for entities at a spec- ified physical location, it is necessary to collect information of such entities and manage it in databases. This database can be maintained on servers with many clients issuing query re- quests over the network to access location infor- mation. There are two methods for maintain- ing location information on servers: a centralized server scheme and a distributed scheme.
In a centralized server scheme, information is collected and maintained by a single server. An advantage of this scheme is that it is simple and that no extra processing for locating the server is necessary for clients. A disadvantage of this scheme is that it does not scale when there are nu- merous clients issuing many requests and is prone to failures of the server. Also, communication to the server from a topologically distant client can introduce long delays.
In a distributed management scheme servers are placed on the network according to a given standard and each distributed server manages lo- cation information of entities. An advantage of this scheme is that the load of each server can be reduced, because information is divided among servers. A disadvantage of this scheme is that a mechanism for determining which server a client should access is necessary.
In a large scaled widely distributed environ- ment such as the Internet, the distributed server scheme is more effective, however, users must be provided with information about the nearest server. Thus, a standard rule for server placement must also be determined.
Two types of servers placement schemes are discussed here: hierarchical server placement based area domain name or placement in equally divided cells.
The first scheme uses another type of do- main name classified by structure of geograph- ical area. For example, city.kobe.jp repre- sents Kobe City, Japan. Figure 2 shows that servers are placed in each area domain name clas- sified by geographical area. Lines between do- main names signify connections between servers.
Each server maintains information on the higher
World
JP US
Tokyo Kanagawa
Setagaya Shinagawa Yokohama Fujisawa
Figure 2: Server placement by area domain name
level server and the lower level servers. For ex- ample, if an entity X in thesetagaya.tokyo.jp domain looks up the location of an entity Y in the yokohama.kanagawa.jpdomain, first, X sends a request to the server for Tokyo. Next, the server for Tokyo forwards the request to the higher level server for JP. The server for JP forwards the re- quest to the lower level server for Kanagawa. The server for Kanagawa forwards the request to the lower level server named Yokohama. The server for Yokohama searches its database for Y accord- ing to the request and returns a reply to X. This scheme is useful when the domain name can be mapped to static geographical areas.
In the second scheme, servers are placed in equally divided cells of a mesh as shown in Fig- ure 3. There is a single server assigned to each cell. Each cell is numbered with location. Thus, an entity can select a server by calculating its ge- ographical location. In this scheme, it is straight- forward to look up an identifier of an entity by specifying location as the key. To look up lo- cation by specifying entity identifier, clients can query a relevant server or directly query the en- tity specified. In the figure, as an entity moves from area N4E4 to N2E2, its old entry is deleted at N4E4 and a new entry is registered with the server for N2E2.
N2E2 N2E3 N2E4
N3E2 N3E3 N3E4
N4E2 N4E3 N4E4
Figure 3: Server placement according to equally divided cells
2.3 Information Update
Geographical location information of an en- tity may not be static and may change over time.
Thus, it may become obsolete and inaccurate af- ter a certain period of time. As a mobile entity increases its speed, its location information be- comes less accurate. If location information is updated at fixed intervals, the information on en- tities moving faster will become obsolete sooner.
To update location information of an en- tity, the entity sends its information to a server through the network. In order to maintain the most up-to-date information, an entity should continue to send the latest information on itself.
However, this increases traffic. Therefore, update timing should be dynamically determined and ad- justed according to the dynamic characteristics of the entity. We introduce the two parameters:
mobility factor and update timing, that deal with mobile entities.
Since some entities move and others remain fixed, if an entity is not currently moving, it is difficult to judge whether it is fixed or just tem- porarily stationary. It is necessary to identify its status, so we introduce the mobility factor pa- rameter. A mobility factor value of 1 represents a mobile entity, and a value of 0 represents a fixed entity. In other words, if the mobility factor is 0, an entity does not issue updates unless its loca- tion changes, and if the mobility factor is 1, it is assumed that constant updates are sent to a server.
Each entity is supposed to have a parameter for order of accuracy and last fixed location. If the difference between the current location and the last location is smaller than the order of ac- curacy, there is little possibility that the entity ac- tually moved. However, if the difference is larger than the order of accuracy, it can definitely be concluded that the entity moved. So, an entity with mobility factor of 1 sends its updates when the difference between the current location and the last location is larger than the order of accu- racy.
2.4 Information Injection
Entities generally obtain geographical location information from a device such as GPS. Entities that are not equipped with such a device cannot determine its location. A function must be intro- duced that sets location information to such enti- ties. This information can be given or “injected”
by an entity which exists nearby and is equipped with such as device. It is, however, difficult to judge that an entity that injects its location is near such an entity. Thus, information injection
Table 2: GLI Parameters location Latitude-Longitude-Altitude velocity North-East-Up
device GPS etc.
datum WGS-84,OSGB-36,NAD-27, etc.
data type C/A,P,RDGPS, Kinematic, etc.
time time of fix
will depend on negotiation of users on each entity.
3 Prototype Design
In this section, we present the prototype de- sign of our Geographical Location Information (GLI) System considering the issues described in the previous section.
3.1 Design Overview
Our GLI prototype system manages host lo- cation information. Entities that are accessible through the system are hosts, and IP addresses are used as entity identifiers. Thus, the system provides a mapping host GLI and IP addresses.
As a result of such mapping, users are able to issue the following queries.
• Request the geographical location of a spec- ified entity
• Request the entities’ identifiers (IP ad- dresses) at a specified geographical location The following functions are necessary to sup- port the above queries.
• WIT:Who Is There?
Look up the entity identifier based on geo- graphical location
• WAY:Where Are You?
Look up geographical location based on the entity identifier
GLI Parameters
Table.2 shows the GLI parameters used in our prototype. Basic GLI parameters include loca- tion, velocity, device type, datum, and data type.
Location is expressed by a latitude, longitude and altitude coordinate. Velocity is expressed by a combination of speeds in three directions: north, east, and up. Device represents a type of device for determining location. Datum is used to trans- late GLI to GLI based on local area. Data type represents order of accuracy. Time represents the time when the GLI was fixed.
Information management
Servers manage GLI of entities. In our pro- totype, a single server architecture is used. Dis- tributed servers will be considered in future ver- sions.
Information injection
Entities generally obtain GLI from device con- nected to themselves. For entities without such devices, an inject function is introduced to inject location information from another entity. This prototype does not take into consideration how nearby the entity that makes the injection is to the entity which needs to have GLI injected.
Information update
A server collects information from entities.
Entities send information to a server through the network. Update timing is determined by mobil- ity factor and comparison of the last and current GLI, and order of accuracy.
3.2 Basic Structure
In the GLI system shown in Figure 4, we in- troduce three modules that cooperate with each other to maintain GLI.
Server
Client Agent
GLIQuery Request
GLIRegister Reply
GLI Query Reply
GLI Register Request Latest
GLIReply
Latest GLIRequest
Figure 4: Prototype Architecture
Agent
An agent runs on each entity, collects GLI, and registers it with the server. In addition, an agent receives requests from other entities to inject GLI, and returns GLI to the entity that needs an injec- tion. An agent also receives requests for its latest GLI from clients, and returns this information.
Server
A server manages GLI sent from agents in databases, receives query request from clients, and sends a reply back containing the result to the client.
Data sent from agents is managed in a database on the server. It is necessary for the database management scheme on the server to process continuous requests from agents quickly, especially since register requests of mobile entities are sent in short intervals to provide up-to-date information.
There are four data fields for each entry man- aged on the server. The first field is the IP ad- dress, the entity identifiers for our prototype. The second and third fields are GLI. One represents the latest GLI, and the other represents the previ- ous GLI. By preserving the two latest GLI values, it is possible to determine the mobile status of the entity. From the difference between two val- ues, the speed and the direction are calculated.
If an agent does not send an update request for long intervals, the GLI for that entity can be con- sidered accurate. The last field is for additional information. It consists of a string that includes information such as name of entity, type, etc.
Client
Clients provide an interface between the user and the GLI system. It issues user query requests (WAY, WIT) to the server, and returns the reply to the user. It may ask for the latest GLI of a specified entity by accessing the entity directly.
4 Implementation
In this section, our prototype implementation of the GLI system is described.
4.1 Hardware Structure
Our prototype implementation uses a Global Positioning System(GPS). The GPS used con- tains a 6 channel sensor and is made by Trim- ble Inc. GPS-dependent part is separately imple- mented in a module named gli update. This is the only module in our prototype that is device dependent.
This system has been implemented on BSD/OS 2.1 for IBM PC/AT compatibles, NEWS-OS4.2.1, and SunOS4.1.4.
4.2 Software Structure
GLI system is implemented as an applica- tion program using TCP/IP. Communication be- tween the server and a client, the server and an agent, and a client and an agent uses TCP (Transmission Control Protocol). XDR(eXternal Data Representation)[2] is used for data format.
Therefore, a problem does not arise when differ- ent machine architectures use different byte or- ders. Figure 5 shows the software architecture of the prototype implementation.
The agent, server, and client of the GLI sys- tem described in Section 3 are implemented as follows. The agent consists of two modules called glid and gli update. The server and the client are implemented as modules called glis and glic, respectively.
glis
glid
glid glic
GLIFILE GLIFILE
WRITE
READ REGIST_HI ASK_GLI
ANS_GLI
ASK_CUR_GLI ANS_CUR_GLI
ASK_INJ_GLI ANS_INJ_GLI (WIT,WAY)
(WAY) (WIT,WAY)
gli_update gli_
update
WRITE
READ
device
for determing location
Agent Agent
Server
REQ_TO_GLIS REQ_TO_GLID REP_FROM_GLIS REP_FROM_GLID
Client
REGIST_HI
Figure 5: GLI software architecture Modules are represented as square boxes with respective names (gli update, glid, glis, glic) in Figure 5. The rectangle surrounding glid, gli update, and GLIFILE denotes that these three exist within the same entity. gli update ob- tains GLI from a device such as a GPS or other entities. gli update receives information from the device and processes it for GLI. It also communi- cates with a glid on an inject entity. gli update writes the GLI determined to the file GLIFILE which can be referred by a glid. In an entity with a device for determining GLI, gli update obtains GLI and writes it to a GLIFILE. glid reads GLI- FILE and registers the GLI with the glis. glic sends query requests to the glis or a glid.
4.3 Packet Handling Packet Header
Figure 6 shows the common header for packets transferred in the the GLI system.
The description each fields is as follows:
• sender. . .IP address of the entity that sends this packet.
• type. . .packet type as shown in Table 3.
sender IP address
type code
0 31
Figure 6: Common header of each GLI packet
• code. . .packet code defined for each type.
Table 3: Packet Type Packet type Contents REQ TO GLID Request to glid REQ TO GLIS Request to glis REP FROM GLID Reply from glid REP FROM GLIS Reply from glis
Packet Codes
Request packets (REQ TO GLIS) are sent to the glis with two different codes. These include a query request (ASK GLI) such as WAY and WIT from a glic, and register and update message (REGIST HI) from a glid.
There is only one code for a reply packet from the glis (REP FROM GLIS). This is a reply des- tined for a glic (ANS GLI).
Request packets (REQ TO GLID) are sent to a glid from a glic or glid of another agent. These include a query request to look up the latest GLI from a glic (ASK CUR GLI) and a request to inject GLI from an agent equipped with a GPS (ASK INJ GLI).
The reply packets (REP FROM GLID) are used to return replies from a glid. These include the latest GLI sent back to a glic (ANS CUR GLI) and GLI to be injected by gli update (ANS INJ GLI).
Managed Data
Data of a packet sent from a glid to the glis (type = REQ TO GLID, code = REGIST HI ) for updating GLI is produced from data shown in Table 4.
The database function to be executed (add, update, or delete) is specified in flags.
The types of data entry made by a packet sent from a glid is shown in Table 5. It is managed in the database on the glis.
The data entries are implemented in a linear list. There are 148 bytes per entry and 64 entries in a list. A linear search is used to search this list. Faster search algorithms and schemes will be incorporated in future implementations for opti- mization.
Table 4: Data structure managed by glid Server Address 4bytes Latest Location Info 36bytes
Time of Fix 4bytes
Mobility Factor 2bytes Additional Info 64bytes
Device 2bytes
Datum 2bytes
Surveying Location 2bytes
Total 116 bytes
Table 5: Data type managed on glis
Agent Address 4bytes
Latest Location Info 36bytes
Time of fix 4bytes
Previous fix location info 36bytes Time of previous fix 4bytes Additional Info 64bytes
Device 2bytes
Datum 2bytes
Surveying Location 2bytes
Total 148bytes
The glic provides an interface between the user and the glis or the glid. If a request is of type to look up location of a specific entity, a glic sends a request packet with a corresponding IP address of the entity as the key to the glis. If a request is of type to query the latest GLI of a specific entity, the glic sends the request packet to the entity. If a request is of type to look up the closest entity located in a specific area, the glic sends a request packet with specific location as the key to a specific the glis. If a request is of type to search for a string, the glic sends request packet with a string as the key.
As a result, the glic receives a reply from the glis or a glid and displays the received informa- tion.
Request Packets sent from a glic to the glis or a glid (ASK GLI), (ASK CUR GLI) have flags.
These include a request to look up geographical location based on the entity identifier (WAY) and a request to look up entity identifier based on the geographical location (WIT).
5 Evaluation
Figure 7 shows our test environment. This ex- periment was held on a network consisting of an Ethernet and a cellular phone line with a single glis and entities (one of them is mobile) on which a client and an agent are running. Entities named san-marinoandsharkare fixed on the Ethernet.
The entity nameddocileis moving in a car, and connected tosharkon the cellular phone line us- ing a modem.
GLIS
san-marino
Ethernet
shark docile
GLID GLIC
PPP Cellular Phone
mobile (9600bps)
GLIC
GLIC
GPSfixed fixed
GLID GLID
Figure 7: Experimental Environment Figure 8 shows a glic on shark requesting GLI of an entity named docile to the glis on san-marino.
% glic -s san-marino -t docile [docile]
Latest Info:
Position: 35 18.321 N 139 30.652 E 29.74 m
Vel ENU: -11.30 1.63 -1.67
Time of fix: Thu 03:47:03.44 Prev fixed Info:
Position: 35 18.316 N 139 30.677 E 33.51 m
Vel ENU: -10.38 3.09 -0.79
Time of fix: Thu 03:46:59.94
Figure 8: Request to searchdocilefrom glic on sharkto glis onsan-marino
Figure 9 shows a glic requesting the latest GLI ofdocilefrom the glic onshark.
% glic -t docile [docile]
Latest Info:
Position: 35 18.338 N 139 30.490 E 9.38 m
Vel ENU: -11.83 1.00 -0.95
Time of fix: Thu 03:47:22.94
Figure 9: Request the latest information from glic onsharkto glid ondocile
Figure 10 shows a glic ondocilesending a re- quest to look up entities near a specified location to the glis onsan-marino.
As depicted in the figures, our prototype is effectively running, and we are able to look up GLI of fixed and mobile hosts.
From our initial experiment, we also learned the importance of server positioning in large scale
% glic -s san-marino -l 35.38 -o 139.42 [san-marino]
Latest Info:
Position: 35 23 19.432 N 139 25 39.166 E 39.59 m
Vel ENU: 0.00 0.00 0.00
Time of fix: Sat 07:57:38.31 Prev fixed Info:
Position: 35 23 19.432 N 139 25 39.166 E 39.59 m
Vel ENU: 0.00 0.00 0.00
Time of fix: Sat 07:57:38.31
Figure 10: Request to search entities near a spec- ified location from a glic ondocileto the glis on san-marino
environments and maintaining privacy of infor- mation within the GLI system.
6 Related Works
Research in practical applications for the In- ternet is attracting interest. Several applica- tions, that were a result of development in mobile computing[3] and ubiquitous computing[4, 5] ar- eas, strive to simulate or map real world entities and even users on computer networks. It is im- portant for such applications to obtain location information of entities in the real world.
Ubiquitous computing was proposed by Mark Weiser. In this concept computers exist every- where and they are invisible to users. People can use them without being aware of them.
In an ubiquitous computing environment, computers should be aware of the location of the users. One work dealing with this issue is the Active Badge Location System[6]. The Active Badge system provides a means of locating in- dividuals within a building by determining the location of the Active Badge worn by them. This small device transmits a unique infrared signal every 10 seconds. Each office within a building is equipped with one or more networked sensors that detect these transmissions. The location of the badge (and hence its wearer) can thus be de- termined from the information provided by these sensors.
There are other work and applications that use a system similar to the Active Badge[7, 8, 9]. One of them is Context-Aware Computing Applications[7], in which small computers called Parc Tabs similar to Active Badges that use infrared are used. Parc Tab users may move from one location to another to join and leave groups of people and interact with other comput- ers. Context-Aware Computing software adapts according to its location, and the group of people, hosts, and accessible devices nearby.
One of most popular devices for obtaining lo- cation information is the Global Positioning Sys- tem (GPS). GPS can survey location continu-
ously in all areas on the earth, at sea, on land, on an airplane, in a rocket, on a ship, etc. It can also determine velocity and direction of a moving entity, and provide a very accurate measurement of time. It is used in many applications in various fields.
However, even with the advent of these new concepts and devices, there are still many issues that must be solved. Some of these issues are listed as follows.
• The Active Badge location system is mainly intended for individuals. It maps both indi- viduals and their location. Any other entity is considered to be fixed. Thus, the system does not deal with all types of real world entities at the same level.
• The Active Badge and the Parc Tab are used in limited areas like buildings, so loca- tion information it can provide is very local and cannot be applied to a global area.
• The GPS can be used in a wide area en- vironment. However, it can only provide location information, and does not provide communication facilities. It is necessary for a computer connected to a network with a GPS device to process location information in a distributed environment.
Other work in this area focuses on support- ing privacy of individual location information, and security issues, such as encryption of lo- cation information when transferred through a network[10, 11].
7 Conclusion
We proposed the Geographical Location In- formation System that provides a way to map ge- ographical location of entities and identifiers on the Internet. The prototype of this system uses IP addresses as identifiers on the Internet. The system makes it possible to look up the entity identifiers based on geographical location, and to look up geographical location based on the entity identifiers.
We also presented the design and implemen- tation of the GLI system as application layer pro- grams using TCP, and show that it is useful based on experimentation. The GLI system is indepen- dent of machine architecture, and has been tested on BSD/OS, SunOS, and NEWS-OS. We are ex- perimenting with the GLI system by using many hosts on the Internet.
We are currently experimenting with our pro- totype GLI system to to improve system perfor- mance and to incorporate the GLI hierarchical
representation structure proposed in this paper.
Application software for the GLI system will also be developed.
Acknowledgments
We would like to thank Makoto Niimi, Keisuke Uehara and Noriaki Miyazawa of Keio University, and the members of the Mobile and Ubiquitous computing for the Internet (MAUI) Project at the Graduate School of Media and Governance, Keio Univ. We also thank the members of the WIDE Project.
References
[1] Fumio Teraoka, Keisuke Uehara, Hideki Sunahara, and Jun Murai: VIP: Proto- col Providing Host Mobility CACM, Vol.37, No.8, August 1994
[2] Sun Microsystems, Inc. : XDR: External Data Representation Standard RFC 1014, June 1987
[3] Mahadev Satyanarayanan: Workshop on Mobile Computing Systems and Applica- tions December 1994 Operating Systems Re- view, Volume 29, Number 2, April 1995 [4] Mark Weiser: ”Hot Topics: Ubiquitous
Computing” IEEE Computer, October 1993.
[5] Mark Weiser: ”Some Computer Science Problems in Ubiquitous Computing,” Com- munications of the ACM, July 1993.
[6] Roy Want, Andy Hopper, Veronica Falcao, and Jonathan Gibbons: The Active Badge Location System ACM Transactions on In- formation Systems, 10(1):91-102, January 1992.
[7] Bill N. Schilit, Norman I. Adams, and Roy Want: Context-Aware Computing Appli- cations Proceedings of the Workshop on Mobile Computing Systems and Applica- tions, Pages 85-90,Santa Cruz, CA, Decem- ber 1994. IEEE Computer Society.
[8] Bill N. Schilit and Marvin M. Theimer: Dis- seminating Active Map Information to Mo- bile Hosts IEEE Network, 8(5), pages 22-32, September/October 1994, IEEE Computer Society.
[9] Andy Harter, Andy Hopper: A Distributed Location System for the Active Office IEEE Network, Vol. 8, No. 1, January 1994
[10] Mike Spreitzer, Marvin M. Theimer: Scal- able, Secure, Mobile Computing with Loca- tion Information. Communications of the ACM, Vol.6, No.7, July 1993.27-27
[11] Mike Spreitzer and Marvin M. Theimer:
Providing Location Information in a Ubiq- uitous Computing Environment Operating Systems Review, Volume 27, Number 5, De- cember, 1993
Author Information
Yasuhito Watanabe is a graduate student of Graduate School of Media and Governance, Keio University. He may be reached at [email protected].
Dr. Atsushi Shionozaki is with Sony Com- puter Science Laboratory Inc. He may be reached [email protected].
Dr. Fumio Teraoka is with Sony Computer Science Laboratory Inc. He may be reached at [email protected].
Dr. Jun Murai is with Keio University. He may be reached [email protected].
