Geographic Context Awareness

In this section, we will introduce the concept of geographical context-awareness, which is a kind of context-awareness of ubiquitous computing and plays a key role in integrating geographic information systems and ubiquitous computing.

4.1. Ubiquitous Computing and Geographic Context-Awareness

The context-awareness of ubiquitous computing environments aims at the adaptation to dynamic changes of environments. If no change occurs in the environment of mobile device, context-awareness would be meaningless. The changes of environment take place due to two reasons,

z changes of environments, and

z changes of location of mobile device itself.

The first type of changes is caused by changes of external context such as drops of temperature. However the second type is due to the movement, although the external environments remain constant. The first type of changes is gathered by sensors, while thesecond type of changes is determined by the current location and the geographic information around the current position. For this reason, the context changing by the movement of mobile nodes can be considered as geographic context. For example, the location information of the nearest gas station on high way to my car is a geographic context. While map data may be a typical type of geographic context, any kind of geographic information can be used to provide geographic context. And the context-awareness forthe second type of change is called geographic context-awareness in this paper.

4.2. Requirements for Implementing Geographic Context-Awareness

The most simple and naïveway to implement geographic context-awareness is to store the entire geographic information on the region where mobile devices will possibly move. Due to the hardware limitations of mobile devices, this approach is almost infeasible. For example, it may be possible to store a small fraction of a map on a country, but the entire map is too huge to be stored in a tiny mobile device. Consequently, the following constraints of mobile device should be carefully taken into account when we implement geographic context-awareness.

z communication overhead,

z hardware constraints of mobile device such as size of memory,

z egocentric mapping, and z heterogeneous environment.

4.3. How to get Geographic Context Information?

In this subsection, we will present several methods to get geographic contextual information introduced in the precedent section. In general the contextual information of a mobile node in ubiquitous computing can be acquired from

z sensors, z labels, or z other nodes

Sensors are the most typical way of gathering contextual information in ubiquitous computing environments. For example, temperature data can be easily taken by sensors. GPS belongs to this category to get location context data. Labels are the second method to acquire contextual information. The last method to acquire contextual information is to request other nodes.

RFID is a typical method to realize label. A small amount of geographic data such as UFID(Unique Feature Identifier) or location information can be easily stored in a RFID.

Although simple geographic information can be provided by labels, complex and large amount of geographic contextual information cannot be stored in a small label. In this case, two alternatives are possible as follows,

z server or other mobile nodes provide geographic contextual information, or z find geographic information by in-network query processing

Providing Geographic Context Information from Servers or other Mobile Nodes

The first method to provide geographic contextual information is to get it from a server or other mobile nodes. As mentioned in the precedent subsection, a scalability problem

arises if a centralized server provides such information to every node in real-time. Instead, two alternatives have been paid attention to overcome the scalability problem, which are a massive distribution of geographic context information to every small mobile devices and periodically broadcasting it to mobile nodes

Each node in massively distributed environment manages a small fraction of geographic context concerning its own environment for ubiquitous computing and sends it to its neighbor nodes in case of demands. For example, each vehicle on a road has its velocity data along the streets it has passed through, and it sends this data to other vehicles on their demands. If there is no vehicle found around a given vehicle having useful geographic contextual information or too many vehicles are around it, then a more complicated searching mechanism is required to find the vehicle that contains the useful information.

This mechanism will be explained in the next subsection.

While a centralized server may cause the scalability problem, broadcasting method is a promising approach to achieve the scalability even though it also relies on a centralized server. The server storing geographic contextual information periodically broadcasts it to mobile devices without causing scalability problem. Then each mobile device takes only its interesting information from the entire broadcasted data. For example, a broadcasting server transmits traffic information to all vehicles within the coverage area and each vehicle extracts only the traffic information around it.

This approach provides a high degree of scalability but has some weak points that the direction of transmission is one-way and the bandwidth of communication is relatively limited. To overcome this weakness, several hybrid methods are being studied, such as spawn protocol [8].

In-Network Query Processing

We can provide geographic contextual information by integrating distributed data over mobile devices and analyzing them as well as by stored data in a server. For example, we want to know the average temperature in a region where a number of mobile sensors are installed. Then we first gather the temperature data from the sensor nodes in the region and second calculate the average. This kind of operations requires the data from several devices and integration of data via wireless network. We call this type of operation in-network query processing, which handles of data spread over a number of devices connected via wireless network, instead of data stored in a centralized server.

Another type of in-network query processing is to find the node having useful information. For example, if we want to find the nearest ambulance to an accident place, we do not know the node with the information on the nearestambulance. In general, we first select a set of candidate mobile nodes by forwarding the query message to the neighbor nodes till this message will be arrived at the query region and second we examine the candidate nodes with care to find the nearest ambulance. The first step of processing is called routing phase, while the second step is called refinement phase. The performance of in-network query processing is mainly determined by the routing phase rather than the refinement phase.

In-network query processing often assumes ad-hoc network, which does not require the infrastructure network or P2P environment, where each node possesses an IP address on an infrastructure network. A number of researches have been done for in-network query processing for ad-hoc network or P2P environments. Unfortunately, few researches on in-network spatial or geographic query processing are found.