Abstract

In this paper, we propose the Geographical Location Information (GLI) System. The GLI system provides a way to map geographical location of entities and identifiers on the Internet. It consists of three components; 1)servers that maintain geographical location information for each entity in databases, 2)agents that register entity geographical location information with servers, and 3)clients that issue entity/location queries. The server manages entries that consist of entity identifiers and geographical location information. A client can look up entity identifiers by specifying location as a key, and vice versa. The design 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 independent 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 towards 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 Internet is constantly increasing as their locations become more widely distributed and topology is ever changing. To access these entities in a practical way, it is necessary to obtain geographical location information of an entity connected to the Internet. In the TCP/IP network architecture, the IP address already provides a way to identify the topological location of a connected host. However, there has been no architecture or system 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 Location 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 identifiers 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 location information of the specified entities in real-time.

This paper is organized as follows. In Section 2, we discuss ways to integrate location information 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 evaluate 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 entities through the Internet by incorporating geographical location information. Namely, it is necessary to map identifiers on the Internet to geographical location. In this section, we discuss and present ideas on how to incorporate geographical location information into the Internet.

We use 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, processes, etc.

2.1 Information Types

There are various ways to represent geographical 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 Representation of Entities

Geographical location information is a barometer of the real world and there are various parameters to represent location information of an entity. These parameters include coordinate system, name, accuracy, speed, direction, and dimension.

In the real world, two major coordinate systems are used to represent the absolute location of entities on the earth. They are Latitude Longitude 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 represents a name of a given location or area classified hierarchically or traditionally (e.g., country, state, prefecture, city, street, etc.). Thus for practical use, it is usually necessary to translate absolute location coordinates into location names. Also, since the shape of the earth is not a perfect sphere, surveying schemes that incorporate datum that model specific limited areas need to be introduced. Each official national map is generally derived from the datum 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 information 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 datum Tokyo. Thus, datum is an important parameter 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 navigation system will function with an accuracy in the order of 10m diameters. Gas and water utility 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 information 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. Assuming that the length of the equator is 40,000 km,

order	bit length
1mm	36 bits
1cm	32 bits
1m	26 bits
10m	22 bits
100m	19 bits
1km	16 bits
10km	12 bits
100km	9 bits

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 and direction must be maintained for mobile entities. 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 introduced. An example would be to represent an entity's area with a center coordinate and a specified radius or a triangular or square area, etc. However, the dimensions determined by this scheme will introduce error and ignore shape of the entity. 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 information 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 propose a hierarchical representation structure of geographical 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 systems, 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 coordinate 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 location information service can use these tags to specify a certain area or coordinates.

Internet Identifiers

Various identifiers are used on the Internet to represent entities such as hosts, files, and processes. These include Internet addresses (IP address), domain names, and Uniform Resource Locators (URL).

All hosts connected to the Internet are assigned 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 specific 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 another network, it must be assigned a new IP address on the network. The Virtual Internet Protocol (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 mechanism classified by organization structure was introduced 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 between these Internet identifiers and geographical location information. As non-computer entities such as cars, people, and sensors will be accessible 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 specified 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 requests over the network to access location information. There are two methods for maintaining 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 numerous 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 location 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 environment 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 domain name classified by structure of geographical area. For example, city.kobe.jp represents Kobe City, Japan. Figure 2 shows that servers are placed in each area domain name classified by geographical area. Lines between domain names signify connections between servers. Each server maintains information on the higher level server and the lower level servers. For example, if an entity X in the setagaya.tokyo.jp domain looks up the location of an entity Y in the yokohama.kanagawa.jp domain, 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 request 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 according 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 Figure 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 geographical location. In this scheme, it is straightforward to look up an identifier of an entity by specifying location as the key. To look up location by specifying entity identifier, clients can query a relevant server or directly query the entity 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.

2.3 Information Update

Geographical location information of an entity may not be static and may change over time. Thus, it may become obsolete and inaccurate after a certain period of time. As a mobile entity increases its speed, its location information becomes less accurate. If location information is updated at fixed intervals, the information on entities moving faster will become obsolete sooner.

To update location information of an entity, 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 adjusted 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 temporarily stationary. It is necessary to identify its status, so we introduce the mobility factor parameter. 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 location 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 accuracy, there is little possibility that the entity actually 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 accuracy.

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 introduced that sets location information to such entities. 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 will depend on negotiation of users on each entity.

3.Prototype Design

In this section, we present the prototype design 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 location 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 specified entity
• Request the entities' identifiers (IP addresses) at a specified geographical location

The following functions are necessary to support the above queries.

• WIT: Who Is There?

Look up the entity identifier based on geographical 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 location, 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 translate GLI to GLI based on local area. Data type represents order of accuracy. Time represents the time when the GLI was fixed.

location	Latitude-Longitude-Altitude
velocity	North-East-Up
device	GPS, etc.
datum	WGS-84, OSGB-36, NAD-27, etc.
data type	C/A, RDGPS, Kinematic
time	time of fix

Information management

Servers manage GLI of entities. In our prototype, a single server architecture is used. Distributed servers will be considered in future versions.

Information injection

Entities generally obtain GLI from device connected 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 mobility 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 introduce three modules that cooperate with each other to maintain GLI.

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 injection. 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 managed on the server. The first field is the IP address, the entity identifiers for our prototype. The second and third fields are GLI. One represents the latest GLI, and the other represents the previous GLI. By preserving the two latest GLI values, it is possible to determine the mobile status of the entity. From the difference between two values, 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 considered 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 contains a 6 channel sensor and is made by Trimble Inc. GPS-dependent part is separately implemented 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 application program using TCP/IP. Communication between 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 different machine architectures use different byte orders. Figure 5 shows the software architecture of the prototype implementation.

The agent, server, and client of the GLI system 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.

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 obtains 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 communicates 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 GLIFILE and registers the GLI with the glis. Glic ends 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 GLI system.

Sender IP address
type	code

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.

• code

packet code defined for each 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 destined 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.

Server Address	4 bytes
Latest Location Information	36 bytes
Time of fix	4 bytes
Mobility Factor	2 bytes
Additional Information	64 bytes
Device	2 bytes
Datum	2 bytes
Surveying Location	2 bytes
Total	116 bytes

Agent Address	4 bytes
Latest Location Information	36 bytes
Time of fix	4 bytes
Previous fix location information	36 bytes
Time of previous fix	4 bytes
Additional Information	64 bytes
Device	2 bytes
Datum	2 bytes
Surveying Location	2 bytes
Total	148 bytes

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 optimization.

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 information.

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 experiment 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-marino and shark are fixed on the Ethernet. The entity named docile is moving in a car, and connected to shark on the cellular phone line using a modem.

Figure 8 shows a glic on shark requesting GLI of an entity named docile to the glis on san-marino.

Figure 9 shows a glic requesting the latest GLI of docile from the glic on shark.

Figure 10 shows a glic on docile sending a request to look up entities near a specified location to the glis on san-marino.

Figure 10: Request to search entities near a specified location from a glic on docile to the glis on san-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 environments and maintaining privacy of information within the GLI system.

6. Related Works

Research in practical applications for the Internet is attracting interest. Several applications, that were a result of development in mobile computing [3] and ubiquitous computing [4,5] areas, strive to simulate or map real world entities and even users on computer networks. It is important 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 everywhere 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 individuals 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 determined 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 computers. 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 location information is the Global Positioning System (GPS). GPS can survey location continuously 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 individuals 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 location information it can provide is very local and cannot be applied to a global area.

• The GPS can be used in a wide area environment. 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 supporting privacy of individual location information, and security issues, such as encryption of location information when transferred through a network [10, 11].

7. Conclusion

We proposed the Geographical Location Information System that provides a way to map geographical 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 implementation of the GLI system as application layer programs using TCP, and show that it is useful based on experimentation. The GLI system is independent of machine architecture, and has been tested on BSD/OS, SunOS, and NEWS-OS. We are experimenting with the GLI system by using many hosts on the Internet.

We are currently experimenting with our prototype GLI system to improve system performance 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.

[1] Fumio Teraoka, Keisuke Uehara, Hideki Sunahara, and Jun Murai: VIP: Protocol 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 Applications December 1994, Operating Systems Review, 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,", Communications of the ACM, July 1993.

[6] Roy Want, Andy Hopper, Veronica Falcao, and Jonathan Gibbons: The Active Badge Location System, ACM Transactions on Information Systems, 10(1):91-102, January 1992.

[7] Bill N. Schilit, Norman I. Adams, and Roy Want: Context-Aware Computing Applications, Proceedings of the Workshop on Mobile Computing Systems and Applications, Pages 85-90,Santa Cruz, CA, December 1994. IEEE Computer Society.

[8] Bill N. Schilit and Marvin M. Theimer: Disseminating Active Map Information to Mobile 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: Scalable, Secure, Mobile Computing with Location 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 Ubiquitous Computing Environment, Operating Systems Review, Volume 27, Number 5, December, 1993

Author Information

Yasuhito Watanabe is a graduate student of Graduate School of Media and Governance, Keio University. He may be reached at riho-m@sfc.wide.ad.jp.

Dr. Atsushi Shionozaki is with Sony Computer Science Laboratory Inc. He may be reached at shio@csl.sony.co.jp.

Dr. Fumio Teraoka is with Sony Computer Science Laboratory Inc. He may be reached at tera@csl.sony.co.jp.

Dr. Jun Murai is with Keio University. He may be reached at jun@wide.ad.jp.