## 3 System Overview  
The main goal of our study is to design a query evaluation system, which satisfies two requirements mentioned in Section 1. To this end, we use the resident domain concept so that moving objects (i) share the tasks of query evaluation with the server and (ii) send their location-updates to the server only when needed (Please see Section 1 for the details of the resident domain). Figure 2 shows a high-level overview of the system model. Similarly to the system model presented in the previous work [2, 6, 7, 17, 19, 20], the system model we consider consists of three major components: moving objects, clients, and the central server. * **Moving objects**: Each moving object \(o\), which is registered at the server (with its non-spatial attribute values) and is identified by its unique identifier, is capable of sensing its current location (e.g., equipped with a GPS receiver) and has some available (memory and computational) capability \(o.Cap\). We assume that each moving object \(o\) has heterogeneous capability \(o.Cap\), which indicates the maximum number of (qualified) spatial query ranges it can load and process at a time, and that \(o.Cap\geq\theta\), where \(\theta\) is a system parameter that indicates the minimum number of spatial query ranges \(o\) should be able to process; thus, a moving object with more powerful capability is assigned a larger resident domain together with a greater number of spatial query ranges. There are two types of location-update messages sent from moving objects to the server: \(RequestDomain\) and \(UpdateResult\). The former is for the purpose of receiving a new resident domain, whereas the latter is to let the server update the query result. For example, assuming the moving object \(o_{2}\) in Figure 2 is assigned the blue-dotted rectangle as its resident domain together with spatial query range \(q_{3}.R\), it sends the \(RequestDomain\) message to the server because it exits its resident domain. On the other hand, assuming the moving object \(o_{1}\) in Figure 2 is assigned  
Figure 2: System overview. the red-dotted rectangle as its resident domain together with spatial query ranges \(q_{1}.R\) and \(q_{2}.R\), it sends the \(UpdateResult\) message to the server because it crosses the boundary of \(q_{2}.R\). * **Clients**: Each geographically distributed client is able to issue multiple CM range monitoring queries over the moving objects registered at the server, and continually receives the up-to-date results of these queries from the server via wireless or high-speed wired connections. Clients do not directly communicate with moving objects; instead, they use the server as an intermediary. Each query \(q\) issued by a client is identified by its unique identifier and its spatial query range is assumed to be stationary or quasi-stationary. * **Central server**: The server maintains mainly two data structures: a _query table_ (hashed on query identifiers) and the GQR-tree. The query table stores, for each query \(q\), an identifier, a spatial query range \(q.R\), a set of non-spatial values \(q.V\), and the result. The following three main tasks are performed by the server. * **Query registration (or de-registration)**: When a new query \(q\) is issued (or \(q\) is terminated) by a client, the task of query registration (or de-registration) is performed, which consists of inserting \(q\) into (or deleting \(q\) from) the query table, updating the GQR-tree, and broadcasting the message (\(InsertQuery\) message or \(DeleteQuery\) message) to all the moving objects to notify them of these changes. * **Domain assignment**: The task of domain assignment is performed in response to the \(RequestDomain\) message sent by a moving object \(o\) that exits its resident domain. The server searches \(o\)'s new resident domain by traversing the GQR-tree. Then, the server assigns \(o\)'s new resident domain (together with several spatial query ranges) to \(o\).